你把全部文档喂给 AI,它还是答错了-夜雨聆风

你把全部文档喂给 AI,它还是答错了

工程师 AI 知识库三部曲 · 第一篇本篇讲清楚一件事：为什么好的文档存放处，不一定是好的 AI 知识库。

先看一个瞬间

你让 AI 评估一次改动能不能上线。它翻完了你的全部文档，回答：”测试已通过，可以发布。”

你多问了一句：哪个测试，什么时候跑的？

追下去发现，它只是看到仓库里存在一个测试文件。没跑过，也不知道上次跑通是哪年。但在它嘴里，”文件存在”变成了”测试通过”。如果你没多问那一句，这个结论就进了上线判断。

第一反应是骂 AI 幻觉。先别。文档里每一句话，写下的时候都是真的；AI 也没编造任何内容——它只是把所有句子当成了同等可信。问题不在它读到了什么，在它没读到的那部分：这句话是谁确认的，验证到哪一步，现在还作不作数。

文档保存了结论，没保存结论的含金量。

先回答一个问题：人读同样的文档，为什么不出这个错？

因为你脑子里有一杆秤。看到两年前的设计方案，你自动打折：”这篇老了，先去代码确认。”看到接口文档和源码冲突，你不用想就知道信源码。看到”理论上支持重试”，你听得出”理论上”三个字在发虚。

这杆秤不在文档里。在你的工龄里。

也就是说，你的文档库从来就不完整——它一直依赖一个隐形的配套系统才能被正确使用：老员工脑子里的判断力。新人读文档会被坑，AI 读文档会胡说，原因是同一个：他们没有那杆秤。AI 没有发明这个问题，只是把它暴露得无处可藏。

把账本交给一个不认识任何签名的会计，他只能假装每张单据都有效。

那杆秤上刻的是什么？拆开看，三样东西。

一是来源的层级。源码比正式文档可信，正式文档比设计方案可信，设计方案比聊天记录可信——人脑里有这个顺序，冲突时默认信上家。普通文档没有，需求、设计方案、代码事实、AI 自己的总结全混在一个文件夹里，AI 看了只能假装它们一样重。

二是时效。两年前的设计方案和昨天刚确认的接口文档，在 AI 眼里权重一样。「这条结论，现在还作不作数」——文档里从来没有任何字段承载这件事。

三是验证的刻度。「读过代码」「追过调用链」「跑通了测试」「生产环境看到过」，四个等级，中间隔着的全是事故。开头那次，就是 AI 把读过文件偷换成了测试已通过，而文档里没有任何标记拦得住它。

所以同样一句话，放在普通文档里和放在工程知识库里，长得不一样：

普通文档：「订单超时后会自动关闭。」

工程知识库：「订单超时后会自动关闭。（来源：OrderTimeoutJob 源码，已追到代码路径；定时配置在 apollo，运行时未验证；2026-05 复核）」

第二种写法多出来的那半句，就是 AI 和你自己未来能不能放心使用这条知识的全部依据。

普通文档记的是说明，AI 知识库记的是判断——这条知识，到底还能不能信。

用一个公式说：知识 = 结论 × 可信度。我们一直只存了第一个因子。第二个因子存在老员工脑子里，人一离职，它就清零。

如果你已经在动手建，有几个我自己踩过的，先说出来。

最容易踩的是让 AI 总结直接进正式知识页。AI 快，但它会把推断写成事实——等于往水源里掺了看起来无害的脏水，之后每一次引用都在扩散污染。正确做法是先进候选区，人确认后再合入。不是不信 AI，是知识库一旦有脏源头，你不知道它污染了多少下游。

第二个是结构膨胀。今天加个 dashboard，明天加个新模板，后天给每个模块建好空目录。三个月后你拥有一个庞大、精美、过期的骨架——没有人想动它，因为没有人知道它现在到底代表什么状态。

还有一个反直觉的：文档数量不是健康指标。”我们 wiki 有 800 篇”不代表 AI 能用好它。800 篇没有来源、没有置信度，AI 读了照样胡说——而且因为引用了你的文档，胡说得更有说服力，更难被发现。

不用急着建目录、装插件、挑工具。先记住一个判断标准——一个知识库对 AI 可用，意味着它至少回答了四个问题：

满足这四条，哪怕只有十个文件，它就是一个能工作的工程知识库。不满足这四条，八百篇文档也只是一个更大的、AI 读了照样会答错的文件夹。

话说回来，要给每条结论都标来源、标验证状态、标复核时间，听起来够烦的。多数文档确实不值得这么伺候。但你只要在一个地方吃过亏——一条没人敢删也没人敢信的旧结论，每次上线前都要专门解释一遍它到底还算不算数——你就会知道这几个字段值多少钱。

下次写完一篇文档，只问自己一句：三个月后的你，凭什么信它？

不用新系统，不用新工具。

打开你们被引用最多的一份文档——架构说明也好，接口规范也好，上线 runbook 也行。找到其中最关键的三到五条结论，给每条写清楚三件事：这条结论从哪来、验证到了哪一步、上次什么时候确认的。

格式随意。你不需要一套系统——你需要的是开始做那个区分：「我们相信这件事」和「我们能验证这件事」，不是同一回事。

这三到五行，就是你的第一个 validation ledger 的种子。它承载了普通文档从来不承载的东西：结论背后的含金量。

等它有了十行、二十行，你就准备好了。

种子种下了。下一篇讲怎么长：用 7 个文件、一个真实任务，在一周内把 validation ledger 跑成完整的知识库闭环——包括可以直接粘贴给 Claude Code / Codex 的搭建提示词。

本文方法论来自我在真实项目中维护工程知识库的实践，仍在持续演化中。涉及你自己系统的具体结论，请永远回到源码、测试和运行日志验证。