（这是本文内容的隐喻，慢慢体会）
过去一年，关于向量库驱动的RAG在AI Agent软件开发中的角色，业界争论激烈，大体可归纳为三种立场。
第一种立场：RAG 应该被彻底替代。理由很直接——向量化会破坏文档的层级结构，语义召回会引入噪声，而 Agent 无法被强制约束去遵守检索到的内容。这一派认为，确定性路由与结构化规约才是正路。
第二种立场：RAG 不可替代。理由是 Spec Engineering 存在根本性局限——组织记忆天然缺失、信息孤岛无法消除、Spec 永远覆盖不了所有决策背景。这一派认为，RAG 弥补的是 Spec 永远无法完整覆盖的知识空隙。
第三种立场：双引擎协同。这一派试图调和前两者——Spec 提供"硬规则"，RAG 提供"软上下文"，各司其职、互为补充。具体表述通常是：Spec Engineering 提供强约束和确定性，RAG 提供动态知识库和灵活上下文，两者结合构成"双引擎"模式，既提供结构化约束，又融入丰富的历史与外部知识，从而提升代码生成的可靠性与智能化水平。
这三方都有道理，但都说得还不够精准。
本文的立场接近第一种，但更精确，也更"不识趣"。
我并非没有看到第二、第三种立场的合理性——恰恰相反，我认真对待它们，因为它们指出的问题都是真实的：组织记忆确实分散在项目管理系统、缺陷管理系统、决策记录、事故复盘和公司wiki里；最佳实践确实在快速演进；跨项目借鉴确实需要某种"灵活性"。
但正因为认真对待，我才必须指出下一个问题：这些问题的存在，恰恰说明RAG 是被"请"来救火的，而不是被"选"来当主力的。双引擎论听起来平衡，但在工程上，它常常沦为一句体面的话："我们的Spec做得不够好，所以需要RAG来兜底。"
把话说得再直白一点："双引擎"不是一种架构，而是一种妥协。本文要论证的是——在AI Agent研发环境中，Spec-First不是"更好"的选项，而是"更正确"的架构选择；RAG 可以靠边站，且应该靠边站。
一、先承认：后两种立场看到了真实的问题
在反驳之前，必须诚实。如果假装"组织记忆缺失"是伪命题，这篇文章就失去可信度。让我先把双引擎论的价值说清楚：
真实痛点一：组织记忆是分散的。关键的设计决策、技术选型的理由、踩过的坑，散落在禅道、ADR、RFC、PR讨论、事故复盘、公司wiki的历史里。它们很难被完整地结构化进Spec——一旦试图全部纳入，Spec会膨胀到无法维护。
真实痛点二：知识在动态演进。行业标准在更新（OWASP 排名在变）、安全威胁在实时出现（Log4j 式 0-day）、框架最佳实践在迭代（去年的"最佳实践"今年可能已过时）。Spec是时间点的快照，而知识是一条流。
真实痛点三：跨项目借鉴需要语义关联。"我们三年前做过类似的数据管道，那个方案评价如何？"、"隔壁团队做身份认证时踩过什么坑？"这类问题无法通过目录导航回答，需要某种跨域的语义理解。
这三个痛点是真的。我们承认。但承认痛点，不等于承认RAG是解药。
二、但"双引擎"的开药方式，开错了
2.1 把"能力不足"当成了"不可能"
"信息孤岛无法消除"——这是一个断言，而不是一个事实。历史决策散落在各处，是组织治理不力的证据，而不是 Spec 无法覆盖的证据。
如果组织严格遵守这条纪律——每一条架构决策必须落成带 ID 的 ADR；每一个"为什么"必须写进 Spec的 context字段；每一个例外决策必须显式记录版本号与适用范围——那么信息孤岛就不存在了，它们被纳入了 Spec体系的"决策记录层"。
这需要前期投入。但代价换来的是：永久消除一整类上下文污染与检索失败。这笔账，值得算。
2.2 "知识演进"不是向量检索的理由，而是版本管理的理由
"最佳实践在演进，Spec追不上"——这个论点默认 Spec是一个缓慢的、靠人工批准的系统。但 Spec可以像代码一样被版本控制，也可以像代码一样被自动化流程推动：
-
安全漏洞发布时，自动触发相关 Spec 条款的更新流程； -
新框架版本发布时，自动生成适配规约的草稿； -
被验证的组织级最佳实践，自动进入"产品层"Spec 的候选区。
这不是科幻。Google的Style Guide自动化、Amazon 的Operational Excellence 框架，走的都是这条路。把"动态"的需求用结构化的方式解决，而不是用向量化这管"万能胶水"去粘合一切不确定性。
2.3 跨项目借鉴的正确形态，是案例库，不是相似度
"跨项目语义检索"被高估了。实际工程中，这类需求出现的频率远低于想象；而当它真的出现时，最相关的东西往往不是语义相似的文档，而是明确标注适用条件的结构化案例：
---id: CASE-AUTH-003name: ”RBAC vs ABAC 选型实录”applies_when:- organization_size: ”> 100”- permission_complexity: ”high”conclusion: ”ABAC 更合适”tradeoff:- gains: ”更精细的权限控制”- costs: ”系统复杂度与性能开销上升”lesson: ”权限规则少于 50 条时，RBAC 足够”---
这不是 RAG检索，这是结构化的决策案例库。它解决的问题更精准：不是"找相似的"，而是"找适用条件匹配的"。
2.4 双引擎最致命的问题：一致性被撕裂
如果 Spec 说"禁止在权限模型中使用通配符"，而 RAG从一份过时的最佳实践文档里检索出"用通配符可以简化配置"——那么 Agent很容易就拿到了两个相互矛盾的"上下文"。
LLM会选哪一个？大概率选"看起来更相关"的那一个，而那恰好可能是错的。这种冲突在 Spec-Only 的系统里根本不会发生，因为只有一个声音。
双引擎论者的回答往往是："让Spec优先。" 但这个"优先"本身就是事后补救——两个矛盾的声音已经进入了上下文窗口，污染已经发生。更干净的架构，是从一开始就只有一个声音。
三、向量检索的三个根本局限：不是"待改进"，而是"宿命"
3.1 嵌入是有损压缩
向量化本质上是一个信息压缩过程：把一段文本压成一个稠密向量。有调研显示，在特定领域（如医疗诊断）的评估中，嵌入向量里能够复现全量语义准确性的维度占比极低。这意味着向量化从一开始就丢掉了部分精确信息——它不是"不够好"，而是"原理上就有损"。
3.2 向量衰减：语义空间会随时间漂移
这是业界近两年才充分认识的问题：在一月份训练的嵌入模型，到了年中检索关于近期信息时，准确率会出现两位数的百分比下降。不是因为知识库没更新，而是因为语义空间本身在漂移——新知识的语义维度与旧训练数据不兼容。
后果是：你需要持续重新嵌入整个知识库；不同时期的知识可能出现"鬼影重合"（两条实际不同的知识，在新语义空间中相似度极高）；你永远没有一个"当前版本"的概念，只有"概率上更相关"。
对比 Spec 的版本管理：当前版本是 v2.3，就是 v2.3，永不歧义。
3.3 多步检索的误差累积
Agentic RAG 为了提升召回率引入查询改写、多步检索、重排。代价是误差的指数级累积：如果每一步的准确率是 85%，五步之后的累积准确率是 $0.85^5 \approx 44%$——比抛硬币好不了多少。
与其赌五步检索的"44%"，不如用一步目录路由的"99%"。
3.4 一个值得警惕的工业界观察
有工业界报告指出：RAG 系统的失败案例中，大部分失败发生在检索层，而不是生成层。换句话说，模型没问题，是"找到的东西不对"。这不是"换个更好的嵌入模型"能解决的——它是整个方法论在确定性任务上的结构性缺陷。
四、四者对比：谁在主干道，谁在替补席
这里有一个容易被忽略的依赖链：上下文工程的前提是"知道该喂什么"——这个"知道"来自哪里？来自 Spec 路由。没有路由的上下文工程，会退化为盲注；而有了路由，检索就变成了确定性的选择问题，向量根本不需要出场。
五、Spec-First + Harnessed Context：正确的架构
这套架构的关键动作只有三个：
-
路由即检索： stage /component /version /scope /risk五个字段足以定位"该读哪份规约、哪个检查单、哪份模板"——这是确定性选择，不是语义赌博； -
证据束（evidence bundle）：输出的是一个带 ID 的、封闭的、可校验的片段集，外加"允许引用的 ID 白名单"——Agent 的产物必须引用白名单内的 ID； -
质量闭环：计算型校验（ID 完整性、Lint、契约测试）优先，推断型评审（架构适配性）谨慎使用——把"模型可能做错"变成"错了能被拦下来并自纠"。
六、那么，RAG 到底放在哪里？
RAG也不是一无是处，所以我说：RAG没有下岗，它靠边站。具体来说，它有三个合法的临时位置：
位置一：Spec 体系尚未建成的过渡期。大多数组织今天就在这个状态里——没有完整的 Spec 体系，Agent 需要某种知识来源。这时候用 RAG，是务实的。但必须清楚：这是过渡，不是终局。
位置二：组织级知识迁移期。历史决策从散落状态向结构化案例库迁移需要时间。迁移完成之前，RAG 可以作为"临时索引"辅助人工整理。
位置三：人工审核的辅助检索。当人类专家在评审高风险决策时，RAG可以作为一种"发散性参考"——但它的输出只能作为人的输入，不能直接作为 Agent 的上下文。
但启用 RAG必须满足三条铁律：
-
触发条件严格：只有 Spec路由明确失败时才允许调用——路由字段缺失、且人工判断确有知识缺口； -
结果必须过Harness：RAG产出的证据同样要过引用合法性校验与适用范围检查，与 Spec路径一视同仁； -
冲突时 Spec无条件优先：RAG建议与 Spec约束矛盾时，拒绝 RAG结果，记录为例外，并反向改进Spec。
更关键的一条判断：RAG的调用频率，是Spec体系健康状况的指标。如果一周调用超过两三次，问题不在RAG，而在Spec——说明该补的条款没补，该建的案例库没建。正确反应不是调优top-k，而是回头修Spec。
七、对三种常见异议的回应
异议一："Spec 永远不完整，所以必须靠 RAG。"
回应：把"能力不足"包装成"原理使然"，是这类论证最常见的偷换。Spec 不完整，是因为知识治理投入不足——ADR 纪律没建立、决策记录没归档、案例库没维护。这是组织问题，不是技术问题。用 RAG 补治理的洞，等于用止痛药代替手术。
异议二："Spec 更新太慢，追不上知识演进。"
回应：这取决于你如何设计 Spec 系统。把 Spec 当静态文档，它当然慢；把它接入自动化更新流程（漏洞情报触发、框架发布触发、最佳实践评审触发），它就不慢。问题不在 Spec，在使用者的想象力。
异议三："跨项目借鉴需要灵活的语义检索。"
回应：大多数"跨项目借鉴"真正需要的不是语义相似度，而是显式的知识转移流程——A 项目的决策如果对 B 项目有参考价值，应该写进 B 项目的 Spec 或案例库，而不是指望 B 项目的 Agent 自己去"撞运气"发现相似性。知识转移是流程问题，不是检索问题。
结论：真正的成熟是做出选择
如果这篇文章让你觉得"太极端"，请再读一遍第二部分——我们承认了双引擎论指出的所有真实痛点。但我们拒绝用"平衡"来逃避判断。
工程上最贵的不是做错选择，而是不做选择。双引擎论的最大问题，是它让组织永远停留在"两个都要"的舒适区里，永远不用回答那个尖锐的问题：我们的 Spec体系，到底建好了没有？
本文的立场很明确：
在一个有良好 Spec体系的研发环境中，RAG不是"必要的补充"，而是"设计缺陷的补丁"。如果你离不开 RAG，问题不在 RAG，而在你的 Spec体系还不够好。
这不是"两害相权取其轻"。这是一个组织终于明白确定性胜于灵活性、结构胜于模糊、版本管理胜于概率检索时，自然会做出的选择。
RAG靠边站，不是下岗。它站在替补席上，提醒我们两件事：第一，知识治理不能偷懒——你欠 Spec的债，迟早要还；第二，真正的成熟不是兼容并蓄，而是有勇气做出选择，并坚持足够长的时间去验证它。
