规约清晰了但产出还是漏东西：隐性知识的外化

你的规约结构完整，验收标准明确，文档测试也通过了。但 Agent 的产出中仍然出现了你意想不到的问题：它用了一个早已被团队弃用的库，触碰了一个已知有 bug 的 API 端点，或者在一个对性能极其敏感的路径上使用了最简单但最慢的实现方式。

这些问题的根源不在规约的清晰度，而在规约的完备性。团队中存在大量未文档化的隐性知识，这些知识从未被写进任何文档，但每个有经验的团队成员都知道。

隐性知识的典型类型包括：

架构决策的历史原因。"这个模块为什么用了事件驱动而非 RPC？因为两年前我们遇到过级联故障，事后决定解耦。" 这个决策的原因没有写在代码里，也没有写在架构文档里，它存在于参与过那次事故的工程师的记忆中。Agent 看到代码中混用了两种通信模式，可能会"统一"为其中一种，恰好选了我们已经决定弃用的那种。

模块的脆弱点。"这个服务在并发超过 200 时会出现数据库连接池耗尽，需要在调用方做限流。" 这个约束从未被形式化为 API 契约的一部分，但团队中每个写过集成代码的人都知道。Agent 写出的集成代码在功能测试中表现完美，到了压力测试才暴露问题。

特定客户的特殊处理。"客户 X 的数据格式有一个已知的异常：日期字段可能是空字符串而非 null。我们的解析器专门为此加了一个兼容层。" 这个信息存在于某次事故的 postmortem 文档中，但从未被关联到数据解析模块的规约里。

系统性地外化隐性知识需要主动的信息采集过程。一种有效的做法是在规约编写阶段加入结构化的提问：这个模块有哪些已知的坑？有哪些约束没有写在代码或文档里？如果一个新人来做这个任务，你会特别提醒他什么？这些问题的答案需要被捕获并写入规约的 context 或 invariants 字段。

隐性知识的外化是一个持续的过程。每次 Agent 的产出暴露了一个未被文档化的隐性知识，这条知识就应该被捕获并沉淀到规约体系中。随着时间推移，规约会越来越完整，Agent 踩到未知地雷的概率会越来越低。这是演进原则在规约层面的具体体现。