引用古典是 load-bearing 的 UX 选择

风水蓝图 是一个多伦多建筑评估工具。输入地址、楼层、朝向、户型，~2 秒返回一份 CAD 风格的报告：综合分、五个维度分、一段中文「大师批注」、一张以目标位置为中心标注最近 8 项要素（湖、地铁、医院、高速、墓地、高楼…）的静态地图。

它所在的品类——风水 app——有一个近乎普世的信任问题：没人相信屏幕上那个分。

我 scope 这个项目的时候，以为信任问题是个视觉问题。这个品类满是金边卷轴、紫红水墨、龙凤纹样，读起来像神婆小册子。所以最显然的动作是把输出做成工程制图——米色蓝图纸、等宽数字、带 DRAWING NO. / SHEET / CONFIDENCE 的图框。这一步确实有用。但它没解决信任问题，只是绕过了一个糟糕的视觉套路。

真正让信任发生位移的东西要小得多，跟设计几乎无关：报告里每一条化煞建议都指向一个古典出处。

【补靠山】玄武空虚 — 后方 200m 内无高楼或山丘 出处：《阳宅十书》“宅以山为靠”

就这一行 《阳宅十书》"宅以山为靠"，做的活比整套工程蓝图视觉身份都重。这篇讲为什么。

「风水作为产品」通常长什么样

刷一下现存的风水站，体验大致是：

1. 选你的出生年份 + 一个方位
2. 站点产出一段通用文字，告诉你「你是」五行里的哪一个
3. 没有地图、没有可追溯、跟具体位置没有锚定
4. 解读读起来和星座没区别

这个品类的用户预期是 vibes + authority cosplay。站点看起来很贵、文字很花、找不到回到出处的路。如果你本来就不信，你抓不到任何 surface。

这是任何把「软知识体」包成产品的常见失败模式。同样的形状还出现在：

• 自信满满地输出一段没有任何 schema 的占星 app
• 「AI 性格测试」站点报告「你的原型」，但没有任何构念效度
• 营养 app 含混地说「研究表明……」，从不点名一篇论文

形状是一样的：拿一个本来有真实内部结构的知识体，扔进一台美学搅拌机，输出自信的文字、却没有任何 anchor。第一眼读起来很权威，第二眼读起来立刻廉价。

押注：反着来

风水蓝图我押了反方向：

• 规则引擎是无依赖的 TypeScript package（packages/rules-toronto）。它接受一份归一化的「场地读数」，输出维度分 + 检测到的 defects。纯函数，55 个测试，同输入永远同输出。
• 引擎每个模块都对应一本古典文献。二十四山 → 《青囊奥语》（杨筠松）+ 《天玉经》。五行生克 → 《尚书·洪范》+ 《黄帝内经》。楼层 → 五行 → 《河图》。煞气分类 → 《阳宅十书》+ 《阳宅撮要》+ 《鲁班经》。四象格局 → 《葬书》（郭璞）+ 《雪心赋》。
• 叙述器只能描述引擎算出来的东西。它无法发明一个 finding；它只能把已有的分渲染成中文文字，渲染过程中把出处带出来。

这条流水线的输出读起来是这样（节选）：

本宅坐西北向东南（坐山315°「乾」，向首135°「巽」）。坐属金，向属木，金克木 — 主气场流通不畅。 出处：《八宅明镜》“乾巽相对，金木相战” … 【镇阴气】2km 内 ≥2 处医院/墓地，阴气积聚 化解：每日开窗纳阳、玄关红色摆件、盐灯 出处：《阳宅十书·避煞篇》

读这段的人不需要信风水也能看懂正在发生什么：一条规则触发了，它指向了一段文字，那段文字是一本真实存在的书。整个交互从 「信任这个算法」 移到了 「信任那个读对了参考书的制图员」。

这个脚注做的，是单凭视觉设计做不到的信任工作。

这不只是「外面套一层皮」

你可以反驳：这就是同一个通用风水 app，外面绑了几个引用而已。这个反驳是错的，原因是结构性的。

古典引用只有在 触发的规则 = 引文描述的规则 时才保得住诚实。如果引擎报「玄武空虚」但引文写「白虎抬头」，整个框架第一眼就崩了。所以引用是对引擎的一种纪律约束：每一条规则要么能干净地对应到一段文字，要么不能上线。

落实到代码上，这改变了我写引擎的方式。几个例子：

• 最早有个 “general bad vibes” defect，聚合了好几条信号。找不到一段单独的古典文字匹配它——破了引用不变式。最终要么拆成各自溯源的小规则、要么砍掉。我拆了。
• 四象分析最初把青龙和白虎合并成「左右平衡」，因为这样计算更简单。但 《葬书》 是分开命名的，且开的方子不同；合并破坏了引用对应。我把它们重新分开。
• 我本来想加一条 “楼层越高越好，上限 30 加分” 的乘子，找不到经文支撑。我删了。换成 《河图》 老老实实的楼层-五行映射。

引用要求最后变成了对规则集的一个 schema check，跟类型系统对代码的 schema check 是同一类东西。产品因此有了一个更小、更可辩护的引擎。

这能推广

我觉得这底下有一个更广的模式：

当你把一个软知识体包成产品，用户的信任程度，正比于他审计你的成本能多便宜。引用是一个 audit primitive。脚注是一个 audit primitive。「这是数据集里的这一行」是一个 audit primitive。自信的文字加零审计 primitive，是信任的反面。

它可以推广到：

• 研究摘要工具应该链接到原文里那一段，而不是只链接到论文
• LLM 文档问答产品应该 pin 住文档里那一句话的具体 span，而不是只引用文档标题
• 营养 app 应该点名研究、cohort 大小、年份，而不是说「研究表明……」
• 法律信息工具应该引到条款编号，而不是「法律规定……」

它们都是同一个形状：把用户的审计成本压到接近零，即使底下的知识本身可争议，信任也会爬上来。信任不是 confidence 的函数，是 怀疑者推翻你需要多便宜 的函数。

代价

这不是免费的。三条具体代价：

1. 引擎比我想要的小。我不得不砍掉无法溯源的规则。其中有些规则按某种 vibes 标准下「让报告更准」。它们没上线。
2. 叙述器被约束。它不能写「我感觉……」、「这给人一种……」，因为引擎不计算感觉。文字比品类的家族风格更冷。这砍掉了真实的温度。
3. 古典溯源得手工做，至少在现阶段。我读了相关段落，决定哪条规则对应哪段。LLM 大概也能做，但仍然需要人工校准，避免幻觉式的伪引用——那会是产品承诺的反面。

这笔交易我还是会再做一次。产品最独特的特征最后是个 UX 选择，不是模型选择。

下次我会看什么

如果再做一个软知识品类的产品，我会在最前面问的问题是：

审计的单位是什么，给用户看它要多便宜？

风水的审计单位是一段古典文字。研究工具是论文里的一句话。Marketplace 是 链上的那笔 transaction。AI 分诊是 决定路由的那个分。

我一再看到（也犯过一次）的错误是：先设计输出，再去找审计单位。输出是容易的。审计才是难的。先把 audit primitive 立住，输出会自己围着它写出来。

— S.

完整说明见 英文版。