本文记录了我在日常开发中，如何将一次次与AI打磨技术方案时的设计决策，沉淀为结构化的“设计规则知识库”，并以此驱动代码生成与测试闭环。这不是理论推演，而是真实跑通的工作流。

---

一、被忽视的日常：那些只在聊天记录里闪光的设计决策

在引入AI辅助编程后的很长一段时间里，我一直有一种感觉：我和AI最宝贵的交流，不是它替我写出来的某段代码，而是我们一起把方案改来改去的那几轮对话。

比如有一次做订单模块扩展，AI 最初给出的方案新建了一套数据结构，我跟它说：“别新建了，复用现有的 OrderContext 对象，加一个字段标识状态就行，这样上下游都不用改。” 它很快理解并调整了方案。这个决策后来被证明极其正确，减少了大量适配工作。

但问题来了——下一次开新需求时，这个经验完全消失了。 我需要重新把同样的约束再讲一遍，有时候甚至需要翻出之前的聊天记录来提醒它。我才意识到：那些真正体现工程师经验和业务理解的设计决策，一直被锁死在一次性的对话流里，从来没有被“资产化”。

这其实就是经典文章《AI软件工程范式革命的思考》里提到的那个最难的关口：隐性知识蒸馏。

于是我开始有意识地设计一套工作流，核心思想很简单：

每一次和AI打磨技术方案的对话，都是一次“隐性知识”的涌现。如果能用一种极低成本的方式，将这些知识在当下立刻结构化地沉淀下来，并且在未来的开发中自动生效，那我们就等于建起了一条属于自己的认知产线。

这条链路在 Trae 里基本跑通了，沉淀下来的规则也长成了可以展示的样子。下面我就把这个方法的门道完整分享出来。

---

二、我的开发闭环：文档驱动 + 实时沉淀

先交代一下我当前的AI开发模式，这是沉淀能够发生的基础。

我使用的是 Trae CN 这款工具，在“Go开发智能体”的自定义指令加持下工作。开发流程可以总结为文档驱动开发，大致分四步：

1. 输入需求文档：将产品需求文档（PRD）直接提供给AI。
2. 打磨技术方案：AI 生成初版技术方案，我反复提出修改意见，直到方案符合团队规范、业务约束和我的架构偏好。这个方案最终会持久化为一个 Markdown 文件（如 design/order_extension_design.md）。
3. 方案驱动编码：AI 严格基于最终定稿的技术方案生成代码，基本能一次到位。
4. 单元测试闭环：AI 同时生成并执行单元测试，集成测试暂时仍由我手动完成。

这套流程的效果很显著——代码质量和一致性明显提升，返工减少。但最让我头疼的是第2步里那些修改意见的流失。每次我说“别用分布式锁，用乐观锁”、“这个查询要从 token 里取用户ID，别查库”时，背后都是一条有价值的设计规则，但它们就像沙子一样从指缝间漏掉了。

于是，我在第2步和第3步之间，嵌入了设计决策沉淀节点，把整个闭环变成了这样：

需求文档 → AI生成方案 → 多轮讨论修改 → 方案定稿
                    ↓ (每次修改时并行触发)
                 自动提取并沉淀设计规则
                    ↓
           写入 design-kb/design_rules.md
                    ↓
           AI基于定稿方案+规则库生成代码
                    ↓
           单元测试/集成测试验证

关键变化就是：每次方案修改，都是一次知识沉淀的机会。

---

三、沉淀方法：如何让AI在当下立刻把规则“吐”出来

方法是：在每一次方案修改发生的当下，立刻让AI把这一个修改背后的设计规则提取出来，并写入持久化文件。 我把它叫做“实时废气回收”——就像工业生产中，废气在排出的瞬间就被回收装置捕获，而不是等整个车间都弥漫了再去打扫。

具体操作上，我没有去期待AI原生具备这种能力，而是通过改造智能体的提示词，把它变成了一项“本能”。下面是我嵌入到智能体中的核心指令片段（精简版，去掉了隐私相关部分）：

## 设计决策自动沉淀能力（核心）
每当用户提出对技术方案的具体修改要求，并且你在响应中给出了修改后的方案后，必须执行：
1. 自动分析本次修改背后的“架构或业务设计规则”。
2. 如果该规则尚未存在于 `design-kb/design_rules.md` 中，则追加写入一条新规则。
3. 格式严格为 Markdown 表格的一行：
| 场景ID | 触发条件 | 决策动作 | 理由 | 例外情况 |
| DSN-XXX | ... | ... | ... | ... |
4. 如果文件不存在，创建并写入表头。
5. 回答末尾必须附上“✅ 已沉淀设计规则至 design-kb/design_rules.md”。

有了这条指令，我的智能体在每一次被要求修改方案时，都会自动把提取出的规则追加到文件里。我只需要在 Trae 中新建对话，按正常方式跟它讨论方案，沉淀就会静默发生（完全自动还不太行，需要我在对话中输入“沉淀隐形知识”这样的指令）。

刚开始的一两天，沉淀出的规则可能比较浅，但经过几轮修正和补充，很快就形成了有体系的知识库。：

# 设计规则知识库

| 场景ID | 触发条件 | 决策动作 | 理由 | 例外情况 |
|--------|----------|----------|------|----------|
| DSN-001 | 需要对已有功能进行扩展时 | 优先复用现有数据结构和接口，避免新增冗余结构 | 保持代码一致性，减少维护成本 | 现有结构完全无法满足需求 |
| DSN-002 | 高频调用的查询操作 | 优先从请求上下文（如token）直接获取数据，避免缓存穿透到数据库 | 减少数据库压力，提升性能 | 必须实时获取最新数据 |
| DSN-003 | 存在重复代码的多个方法 | 提取公共函数，统一逻辑 | 减少代码重复，方便维护 | 逻辑差异较大，提取反而增加复杂度 |
| DSN-004 | 需要在多个方法间传递复用数据 | 设计Context对象封装，用专门的标识字段记录查询状态 | 避免重复查询，代码更清晰 | 数据量很小，不值得封装 |
| DSN-005 | 方法需要修改传入的对象 | 倾向于值传递+返回新对象的方式，避免指针直接修改 | 防御性编程，避免意外副作用 | 对象很大，拷贝开销过高 |
| DSN-006 | 涉及缓存写操作（新增/更新） | 先写数据库，再删除缓存，最好延时双删 | 确保缓存一致性，避免并发问题 | 无 |
| DSN-007 | 数据库查询可以忍受一定延迟 | 将非核心查询改从从库执行 | 减轻主库压力 | 必须实时读取最新数据 |
| DSN-008 | 新增关键业务逻辑 | 添加详细注释说明设计理由 | 便于后续维护和理解 | 无 |
| DSN-009 | 判断是否已经执行过某个操作 | 用专门的标识字段记录，不要通过结果值推断 | 逻辑更清晰，避免错误判断 | 无 |
| DSN-010 | 功能分阶段实现时 | 明确本期范围，非本期功能标记TODO | 范围清晰，避免过度设计 | 无 |

每一条规则背后，都是一次真实的对话和业务场景。它们不是泛泛而谈的最佳实践，而是这个项目、这个团队、这套业务下的具体约束。

---

四、闭环的真正形成：让规则在开发中自动“发声”

沉淀只是第一步。如果规则躺在文件里吃灰，那前面的工作就全白费了。要让知识真正活起来，必须让它在后续的开发中自动介入。

我通过两个机制实现了这一点：

1. 智能体启动即加载规则库

在 Trae 的自定义指令中，我在智能体行为准则的开头加了一句：

在每次对话开始时，首先读取并理解 `design-kb/design_rules.md` 中的所有规则，并在后续设计和编码中严格遵守。

这样一来，每次我新开一个需求设计会话时，AI 就已经带着之前积累的全部项目经验上岗了。它会在生成方案之初就自动规避那些我们反复踩过的坑，比如不会再去新建冗余的数据结构，不会在高频查询里傻傻地去查库。

2. 规则驱动测试用例生成

沉淀出的规则不仅能指导设计，还能作为测试用例的生成依据。比如 DSN-002（高频调用从token取数据），我只需要对AI说一句：

“请基于 design-kb/design_rules.md 中的 DSN-002 规则，为本次生成的查询接口编写一个测试用例，确保没有直接查库。”

AI 就会自动生成一个 mock 了 token 解析、断言了方法调用链的单元测试，验证这条规则是否被遵守。这就把之前文章里所说的“确定性的强迫接触”（外部裁判）和隐性知识蒸馏无缝衔接起来了：规则是蒸馏出来的，测试是规则长出来的，而测试又是代码是否符合规则的外部裁判。

我目前的单元测试闭环已经在这个框架下运行得很顺畅，集成测试也正在向这个模式对齐。

---

五、效果与反思：从人肉雕花到认知资产

自从这套沉淀机制稳定运行以来，我能明显感觉到几个变化：

1. 重复沟通成本断崖式下降。以前每开一个新需求，我都要重新跟AI强调一堆团队约定和架构偏好，现在AI直接基于规则库出方案，基本只需要微调业务层面的差异。
2. 代码质量更加稳定。DSN-006（缓存一致性）这条规则沉淀后，我再也没在代码里见过裸的缓存写操作；DSN-001（复用优先）则大幅减少了项目中冗余结构体的数量。
3. 新成员或协作者的认知对齐变得容易。这个 design_rules.md 本身就成了活的架构决策记录（ADR），甚至比一堆Wiki文档更贴近实际代码。

当然，也有几个目前还解决得不够好的点，值得坦诚分享：

• 沉淀的粒度控制：有时候AI会把一些过于琐碎的修改也沉淀成规则，导致规则表膨胀。我现在的做法是定期审视和合并，但还没完全自动化。
• 跨会话的文件写入权限：在 Trae 的一些智能体模式下，自动写文件偶尔会受限，需要手动确认。这导致有时候沉淀会中断，我正在寻找更稳定的触发方式。
• 隐性知识的耗尽与补充：沉淀是基于过往错误的，但当项目遇到全新类型的业务挑战时，规则库是空白的，仍然需要工程师先做出第一次决策。

但总体而言，这套方法切实地在解决一个长期痛点：如何让软件工程中每一次“人教AI”的珍贵瞬间，都变成组织的永久资产。

---

六、给想落地这套方法的同行几个建议

如果你也在用 AI 辅助编程，也想把隐性知识沉淀做起来，下面这几条来自我的真实教训或许有用：

1. 不要追求完美的自动化，先从“半自动”开始。 如果AI暂时无法自动写文件，就让它输出结构化的规则文本，你手动复制到规则文件里。这个过程本身就有价值，而且能让你清晰地感受到自己在积累什么。
2. 规则库要场景化，不要陈述化。 “我们应该尽量复用代码” 这种废话没有意义，有效的格式是 “触发条件 + 决策动作 + 理由”，就像我上面表格里那样。AI 能精确匹配场景，才会真正生效。
3. 每一次修改方案，都立刻触发沉淀，不要拖。 事后总结基本等于不总结。
4. 让规则长出测试。 这是价值最大的一步。当一条规则能自动生成校验它的测试用例时，你就真正把隐性知识变成了强制约束，而不只是参考建议。
5. 规则库本身需要维护。 定期清理过时的规则，合并相似的规则，确保它的精炼度。可以把这件事也安排给AI，在每周的某个对话里让它做一次规则健康度检查。

---

七、结语

这一整套方法走到现在，我最大的体会是：我们与AI协作编程时，最大的浪费不是AI写出的代码不够好，而是我们在教AI的过程中，把最宝贵的经验随手丢弃了。

隐性知识蒸馏不是一个宏大遥远的概念，它就发生在你每一次对AI说“别这么做，那样做”的时候。如果你能用一种极低成本的方式，把这些瞬间抓住、沉淀、复用，那么你建的就不只是一个能写代码的AI Agent，而是一条能持续进化的认知产线。

我相信，半年后回看，这个文件可能比任何一个代码文件都更能代表这个项目的真正智力资产。

如果你也在做类似的尝试，欢迎交流；如果你还没开始，明天那个最让你头疼的架构决策修改，就可以是第一条。