知识库要先对齐领域，不是先上 RAG

RAG 解决「找出可能相关内容」，不保证 AI 拿到做完整判断所需的知识集合；固定结构提供的是知识覆盖约束，最大风险是过期文档的可信误导。

给 AI 建知识库，很多团队的第一反应是把历史文档全部塞进向量库，需要时检索几段交给模型。RAG 很有用，但它不该是复杂系统知识建设的第一步。

理由一句话说清：检索解决的是「从资料中找出可能相关内容」，它不天然解决「AI 是否已经拿到了做出完整工程判断所需的知识集合」。ai-agent-book

检索解决不了完整性问题

把几千篇非结构化文档放进同一个索引，三个问题会同时出现。ali-architect-agent

颗粒度不一致。一篇完整方案、一次会议纪要、一段接口说明、一张截图下的注释，都可能成为检索单元，知识密度差异极大。命中一个片段看起来相关，不代表它涵盖了这个问题真正重要的边界。

语义相似不等于工程相关。用户说「订单取消」，检索可能找到退款、履约、营销、风控里大量相似描述，却找不到「状态机不可跳转」「某个消息主题仍有历史消费者」「这个接口只有聚合服务能调用」这类决定方案正确性的约束——因为这些约束的措辞和问题本身不相似。

Top K 给不出结构保证。返回的若干文档可能来自不同时间、不同业务范围，甚至互相矛盾。模型拿到的是一堆碎片，不是一条完整链路。上下文越来越长，注意力反而更分散。

所以 RAG 的问题不在「召回不够多」，而在它很难独立承担知识建模的职责。把大量低结构、低密度的资料统一检索，得到的往往是一座更容易搜索、但依然杂乱的文档仓库。

固定结构给的是覆盖约束

换成结构化知识库，第一个要定的是以什么为边界。答案是领域：每个知识库只服务一个稳定的业务领域，不把多个领域的内部规则混在一起，彼此通过引用关联。

一个领域知识库至少要有五类内容：

这样的结构不是为了目录整齐，而是为了给 AI 一条确定的阅读路径：先读元语避免概念混淆，再读场景确定业务如何落到技术系统，遇到一致性或兼容问题回到原则，需要理解历史原因再查实践。

换个说法更清楚：固定结构提供的是「知识覆盖约束」——它告诉 AI，解决一个业务问题至少要理解哪些方面；而 RAG 只能告诉 AI，这里有一些可能相关的资料。前者是骨架，后者是扩展检索能力。骨架没立起来，检索再快也很难让 AI 获得稳定的系统理解。

这不意味着放弃 RAG。它适合做长尾资料发现、历史文档定位、开放式问答和证据补充。当结构化知识缺某个细节时，用检索找到原始文档，再把经过确认的结论回写进结构化知识——检索是补证手段，不是知识本体。

最大的风险是可信的过期

知识库建设有一个容易被低估的风险：不是缺少文档，而是文档过期后以「看起来很可信」的方式误导 AI。

一份写于两年前、当时完全正确的方案，今天读起来依然通顺、依然专业、依然像是权威结论——但它描述的系统可能早就改了。模型没有能力分辨「这条知识的最后确认时间」，它会一视同仁地采信。

所以维护必须进流程，而且要两种机制互补：

日常增量维护。把知识更新和代码变更联动起来：代码或配置发生变化时，用钩子或 CI 根据 Diff 识别可能受影响的 API、对象、数据库、消息和配置知识，生成待更新候选项，并校验结构完整性。但不能走向另一个极端——任何代码变更都自动覆盖知识。对 API 契约、数据库语义、消息 Schema、状态机、历史兼容和安全策略这类高风险知识，自动化只负责发现变化、生成候选、阻止遗漏，语义确认仍然要人来做。工具守住「代码变了，知识不能完全不变」的底线，人判断「它到底意味着什么」。

周期性校准。日常维护保证及时性，但它覆盖不到跨系统、历史性和高风险的盲区。这类盲区往往在特定时机集中暴露——大促保障、重大故障复盘、系统性梳理。把这些时点的产出当作校准知识库的高价值资料，比日常增量更能补齐结构性缺口。

还有一条让知识库「活着」的必要条件：每条重要知识要能看到来源、最后确认时间、适用范围、当前状态和负责人。没有这几项，知识库迟早变成另一座无人维护的文档墓地——而且这次它还会主动误导 AI。

维护还有一个更硬的手段：用命中数据决定淘汰，而不是定期凭印象清理。 做法是给知识条目埋点——借 AI 编程工具自带的钩子，在每次读文件或文本搜索后跑一个脚本，判断访问的是不是知识目录，从返回内容里提取条目锚点，累加命中次数与最近读取时间（同一条目短时间内只计一次，脚本出任何异常静默退出，绝不影响正常读写）。统计结果给出命中排行和从未被读到的「僵尸条目」，定期审计时逐条复核：过时的删掉，有用但检索不到的补关键词，常命中的补充完善甚至晋升。有个细节值得学——那个团队特意把知识层排除在代码图谱之外，迫使 AI 只能通过读文件和文本搜索访问它们，埋点才真正生效 tencent-800-rules。

配套的是一条单向晋升链：记忆 → 文档 → 规则，而不是直接写成规则。一条经验反复验证成为稳定约定后，晋升进模块文档并删除原条目；同类问题反复出现，说明记忆没防住，才考虑升级为规则。规则每次会话都加载、每多一条就稀释其他规则，而记忆按需检索、没命中时不占注意力——那个团队一次全量审计把 148 条记忆精简到 24 条，大部分不是丢弃而是找到了更合适的位置；13 条进化记录里，只有 3 条最终升级为规则。而且AI 只能提建议，进化记录先进待审阅区，由人逐条决定 tencent-800-rules。

人的位置变了

这套做法最终改变的是人的角色。

以前，工程师是系统知识的唯一检索器：查仓库、画链路、写方案，再把结论交给 AI 去实现。现在，调研、检索、链路推理、代码核查、方案生成可以由 AI 独立完成，人的介入点从「替 AI 收集所有资料」转为「裁决事实缺口和承担关键决策」。

但这条转变有个必须守住的边界：当出现业务取舍、跨团队接口承诺、数据口径、合规要求或高风险变更授权时，AI 应当停止猜测并发起明确的问题，而不是自行补全。一份方案里「待确认项」不是不完整的证据——恰恰相反，无法通过现有资料证实的内容被显式登记，才说明方案没有把推断伪装成事实。

自检两个问题：你的知识库里，有多少条目能说出最后确认时间？模型回答「不确定」时，它有没有一个明确的出口，把问题交回给人？

代价与边界

结构化知识库不是免费的。代价有三笔：前期投入——把架构师脑子里的隐性知识挖出来写成结构化文档，是重人力活；维护成本——两种维护机制都要持续运转，还要有人对高风险变更做语义确认；适用范围——它适合边界稳定、知识密度高的领域，业务本身还在剧烈变化的早期阶段，固化结构反而会成为负担。

判断要不要做，看一个问题：你的系统里，有多少关键约束是「代码里看不出来、只有待过的人知道」的？如果答案是「很多」，那么知识断裂就是 AI 表现不稳定的主因，这套投入值得。如果答案接近「几乎没有」——系统简单、边界清晰、代码即事实——那 RAG 加一份好的入口文档就够了。