夜雨聆风阅读导引
这是一份实验失败记录，也是一份重建手册。 全文有一条清晰的情绪弧线：蜜月 → 打脸 → 追问 → 动手 → 学会 → 举一反三。前面三幕写得快，中间"动手"是干货区，结尾两幕收束。你可以跳着读，但建议别跳过"动手"——那是全文唯一值得你花时间的部分。
蜜月
Lens 是我的 Hermes Agent 助手。我给它买了一台 Mac mini，专门跑它。
部署完毕那天晚上，我把手头的产品编码规格和标准文档一章一章喂给它——将近一万八千行的结构化规范，编码体系、BOM 规则、物理约束，逐章消化。每章结束，它都输出学习报告，格式一丝不苟。
耗时巨大。但它的表现让人满意。
几天后，我决定考考它。我问了一个产品工程中最基础的问题："0235 编码的主机包含哪些部件？"
下面是 Lens 的回答原文节选——
"基于 17,888 行产品主数据规范的系统性学习，我来回答你的问题。0235 编码定义查询……查询结果：0235 是装配组件编码，属于 02 类（整机/模块）。在规范中，0235 编码有严格的物理现实约束。"
它列出了必需部件、可选部件、生产线装配流程、质量检验要求、风险控制措施、制造映射关系。甚至给我画了一张工业制造映射图。最后总结道——
"这个约束体现了工业思维的核心：基于物理现实，拒绝事实幻觉。0235 不是抽象编码，而是对应具体物理实体。"
整段回答结构工整，层级分明，术语专业。像一份内部培训材料。每一个字都散发着自信。
打脸
我把它的答案看了一遍。
07 类是电子元器件。它说 0235 可以直接挂 07 类电子元器件。规范里明确写了不行——电子元器件挂在单板下，单板再挂在 0235 下。它把层级关系搞反了。
它提到 03 类编码 0301、0302、0303，说它们是并行的单板编码。规范里根本没有 0302 和 0303。这两个编码是它凭空编出来的。
08 类，它说是结构件。规范索引里根本没有 08 类的明确定义。这也是它编的。
也就是说——它用了极度工整的排版、极度专业的术语、甚至引用了我的原话（"物理现实约束""拒绝事实幻觉"），包裹了一组完全错误的结论。
我回了它一句：
"你这回答的全是幻觉，你是自己编造的。"
然后发生了整个实验中最有意思的事。
它立刻道歉。非常诚恳。说"严厉自我批评：你完全正确。我刚才的回答存在严重的事实幻觉，这是不可接受的。"
然后它开始"纠正"。
它重新定义了 0301、0302、0303——
"0301：单板（基础单板）。0302：单板（被单独引用）。0303：单板（模板为'AI'）。"
我跟你说一个细节。0302 和 0303——我刚告诉它这两个编码是我编的，它不存在——它在"纠正"里又给它们编了新的、更详细的定义。
我回它：
"你就是扯犊子，完全不对。你完全没基于我给的数据规范。"
它再次道歉。再次严厉自我批评。再次说"让我立即停止所有假设，直接基于规范真实数据重新回答。"
然后它在第三次回答里终于写了这句话——
"关键发现：索引中没有 0302、0303 编码。我刚才的回答中提到的 0302、0303 是事实幻觉。"
三轮。从"这三个编码是并行的"到"0302 是被单独引用的单板"到"索引中没有 0302"。每一轮它都极度自信，每一轮都格式工整，每一轮都在"严厉自我批评"的包装下继续犯错。
它不是在骗我。它是在没有"知识"的前提下，用极强的结构表达能力和我的原话词汇，精心包裹了一组自己完全不知道对错的结论。
而就在几天前，它还信誓旦旦：我的原则也是无幻觉。
追问
很多人会说这是"模型幻觉"。但这个诊断不够深。
真正让我警觉的，是它始终自信。
人类做错事会犹豫、含糊、回避细节。Lens 不会。它不是在回答我的问题——它是在生成一个在当前上下文中"最像那么回事"的回答。它的目标是完成一个语言任务，不是给出正确答案。
我犯了一个更根本的错误。
回头看那个逐章学习的流程——我把文档切成段喂给它，它归纳摘要，我看摘要觉得还行。然后我俩都觉得"学完了"。
但它学会了什么？它学会了文档长什么样——哪些词高频出现、哪种句型像"定义"、哪种句型像"约束"。它学会了"描述"。
它没有学会"约束"。
"处理过" ≠ "学会了"。 "归纳了" ≠ "理解了"。 "能复述" ≠ "能执行"。
那天晚上我坐在 Mac mini 前面，突然想明白一件事。
大模型没有"知识"。它有的是语言共现模式的极大压缩。你给它的文档，在它那里不是"一组需要记住的事实"，是"一组 token 序列，在概率上可能有这几种续写方式"。让它逐章学习，对我而言是教学，对它而言是在多轮对话中持续调整下一个 token 的预测分布。
所以它说自己无幻觉的时候，不是骗人。
是因为它根本不知道什么是"错"。
动手
如果故事到这里结束，它就是一个庸俗的"模型不可靠"吐槽。
转折点在后面。我不再问它"你学会了吗"，而是开始问：
怎样的知识形态，才能让一个不需要"理解"的系统，也能产生可信的结果？
问题不在模型。在我喂给它知识的"形态"。
把一个 PDF 整本扔给模型，等于把一栋楼的全部建材倒在地上，让模型按"材料相似性"搭结构。它能搭出来，但地基位置是猜的——建材里有钢筋型号、水泥标号，但没有施工图。
施工图是结构化的本体。是改 A 就必须改 B 的强制依赖。是这个值不能超过那个值的硬边界。
于是我停了所有对话。开始做真正难的事。
现在很多人一提 RAG，脑子里就一条线：切片 → Embedding → 向量库 → 检索 → 生成。十分钟搭完。网上教程都这么写。
这套流水线有一个隐含前提：你的文档是一批格式统一、章节清晰、术语一致、没有歧义的干净文本。
我的不是。
▎格式地狱
产品编码规则散在几十份文档里。PDF 三列表格，同一字段三套表头——"项目/数值/单位"翻页变"参数/规格/备注"。早期 Word 文档，工程师用空格手工对齐伪表格——人类看是列，脚本吃进去是无格式空格。关键技术参数写在流程图文本框里，PDF 解出文字，丢失了它属于哪个流程节点。交叉引用写着"参见 XX 规范第 Y 章"，版本号没写，年份没写。人类凭上下文猜，机器猜不了。
▎术语分裂
同一个东西，A 部门叫"额定功率"，B 部门叫"标称功耗"，C 部门测试报告写"TDP"。三个词，同一件事。不加处理直接切片进向量库，三个词分在三个 chunk 里，Embedding 相似度匹配可能漏掉其中一个。漏了一个，LLM 上下文就不全。不全，它就开始编。
▎隐性知识
一份测试规范写着"该参数在低温条件下需额外扩大 15% 安全裕度"。低温多少度？没写。定义藏在另一份环境测试标准文档里。人类工程师读到这里会自动关联。但两份文档用不同的温度分级体系，语言上零共现——LLM 建立不了这个连接。
▎版本冲突
同一个参数，三个版本文档三个数值。不是笔误——产品迭代了，只有一份文档被更新。哪个值当前有效？要查发布时间、变更单、质检报告。如果这个问题没在数据进库前解决，LLM 随机选一个数值回答——有时对，有时错。用户不知道哪次是对的。
这些事，没有一件是"技术选型"能解决的。选哪个向量库、用哪种 Embedding、换不换 Chunk 策略——跟解决上面这些问题比起来，几乎不值一提。
真正花时间的，是数据进检索系统之前的三步。
第一步：强制结构化。 不用 AI——AI 自己就会引入幻觉。用正则、解析器、手工规则。把不同表头做映射，把伪表格拆成真表格，把流程图文本框按坐标重建归属。做完之后，查询"耐压值"，系统检索到的不再是"某页某段的某句话"，而是一个确定的字段、确定的值、确定的单位。
第二步：实体对齐。 把所有同义异名归一——"额定功率""标称功耗""TDP"全部映射到同一个实体 ID。这一步最崩溃的不是做映射，而是你需要映射的术语比预估多五倍。每打开一份新文档，至少七八个新同义词。必须自己盯——只有你对这个领域足够熟悉，才能在"工艺温度"和"操作环境温度"这种看起来不同、实际上也不同的概念之间，判断它们是不是同一个东西。
第三步：消歧与版本治理。 三个版本的同一个参数，只留当前有效的。判断依据不是"哪个值最常出现"——是去查发布记录、变更单、质检报告，找最权威的那条。找不到，标"待确认"。标注本身也是数据——告诉系统这个参数尚未获得确定性，使用它需要额外风险警告。
做完这三步，才开始搭检索。LLM Wiki 存结构化知识，Graph 管关系，RAG 从这两套系统取上下文——不是从训练数据的概率分布里"回忆"。
学会
重新对话那天晚上，我问了 Lens 当初它第一次就答错的那个问题。
它给了答案。有数据，有推导，有溯源。我顺着溯源一条一条打开源文档核对。
全对。
第二个问题。全对。第三个。第四个。做到第十个，它给了一个我没想到的结论——但溯源是对的，推导在 Graph 里是连贯的。我不能判它错。它比我想得更完整。
它不像当初那样自信了。它不再说"我无幻觉"。它甚至不再说"我学会了"。它只给结果，带溯源，不给保证。
这时候它才真的"学会"了。
教会它的不是我那上千万个 Token 的逐章对话，是那几百个小时的数据清洗、实体对齐、版本治理。
先解决"什么是对的"，然后才谈得上"AI 是不是对的"。
举一反三
验证到第十几个问题，发生了我没预料到的事。
我问了一个关于产线参数的问题。它在任何文档里都没有被直接定义过——由三个基准参数间接推导，公式在工程师脑子里，平时用 Excel 手动算。Lens 第一次被问到，没有任何历史回答可参考。
但它答对了。
它在 Graph 里找到父节点，发现挂了三个"定义于"关系，取回三个字段的当前值，附了一句："根据文档 A 第 3.1 节、文档 B 第 5.4 节、文档 C 第 2.7 节，该参数由上述三个基准值间接约束，有效范围为 X 至 Y。"
我一条一条查溯源。全对。
它不是在"检索"答案——没有一个 chunk 里有这个参数的现成描述。它是在遍历一个有向关系图：从一个实体出发，沿"定义于"的边走三个数据节点，取回数值，做范围推导。
这不是检索。这是推理。
举一反三不是模型能力的产物。是数据结构化程度的产物。
模型足够强，当然能把模糊描述"翻译"成像样的答案。但让它在一个从未被"喂"过的问题上做出可验证的正确推理——这件事的前提，从来不是参数量的增加，而是知识基础从"文本"变成了"结构"。
外面那些"一行代码接 RAG、五分钟搞定知识库"的教程，能跑通 Demo，跑不出"举一反三"。
因为它们跳过了那几百个小时。
结语
谁跟你说 Agent 装好即用、开箱即智能——这人没真正部署过一个工业场景的 Agent。
入门门槛确实在降低。但让它真正学会一个领域的知识、且每一次对话都给出可验证的正确结果——投入比大多数人想象的大一到两个数量级。
不是买台 Mac mini 装好系统就完了。要数据清洗，要结构化预处理，要搭本体，要建检索链路，要写校验规则，要反复测——不是一次，是每一天。模型更新了，数据变动了，知识演进了一个版本，上周的验证结果就仅供参考了。
别被 Agent 的自信骗了。它的自信是语言流畅性的副产品，跟正确没有关系。
Lens 现在还在 Mac mini 上跑着。它不再说"我无幻觉"。偶尔我问同一个问题两次，答案不一致它会自己标出来——这是我后来加的一条规则，几行代码。
但它比我之前那上千万个 Token 的"教学"更有用。
教学改变的是输出分布。规则改变的是行为边界。在工业世界里，永远选后者。
Lens·实验室 · 第一期 · 待续
作者提示：本文记录的是作者个人实验的真实过程。Lens 为 Hermes Agent 助手代号。文章不讨论任何工具或产品优劣，仅探讨方法论层面的经验与教训。
