AI 工程化落地实践地图

这份指南聚焦 AI 如何进入真实的软件工程流程，而不是停留在零散提示词层面。它不是工具清单，而是一张交付地图：从需求边界、Manifest契约、实施门禁、审计证据到数据闭环，说明团队如何把 AI 编码纳入可治理的工程系统。

如何使用这份地图

先判断你当前的不稳定点在哪里：

• 需求说不清，AI总是自由发挥：从 AI-TDD Manifest 开始。
• 公开知识问答不稳定，引用和索引不可追溯：从 RAG系统指南 开始。
• 任务拆分混乱，执行阶段频繁返工：看 BMAD / Speckit 工作流。
• 代码看似完成，但验收证据不足：看 交付门禁与交付确认。
• 团队想把协作过程沉淀成可训练资产：看 Coding Mentor数据闭环。

---

核心模块一：RAG公开知识入口

RAG解决的问题不是”模型能不能回答”，而是”公开入口能否只基于可追溯、可索引、可审计的站内知识回答”。

这份指南覆盖三个层次：先确定边缘架构、三存储分层和增量索引闭环，再进入分块、混合检索、意图识别和当前页总结实现，最后用质量评测、安全门禁和发布证据决定能否打开公开 /chat 入口。

推荐阅读：

• 构建RAG系统指南：架构、检索实现与质量门禁

这份指南适合在你已经有公开内容、文档站或知识库，并希望把”Ask”入口纳入工程化发布门禁时阅读。

---

核心模块二：AI-TDD Manifest级验收驱动

AI-TDD解决的问题不是”AI能不能写代码”，而是”AI写出来的东西是否对齐人类真正想要的边界”。

核心思路是：在实现开始前，先把自然语言需求转成机器可读的Manifest契约，明确 MUST、NEG、OUT、TRACE、EVD、ACC/E2E、FAIL/EDGE、CMD、ART 和 TASK 等核心 namespace。然后让AI在这个契约内生成实现，并通过准入门禁和交付门禁确认状态。

推荐阅读：

• AI-TDD：以Manifest为核心的验收驱动开发方法

这篇文章是本指南的深水区，适合在你已经遇到需求漂移、测试覆盖不等于需求覆盖、AI实现越界、验收证据不足等问题时阅读。

---

核心模块三：BMAD / Speckit工作流

BMAD和Speckit更关注交付过程的组织方式：如何从需求拆解进入计划、如何让任务包可执行、如何在实施前明确边界、如何在完成后留下审计证据。

AI-TDD Manifest可以看作这个流程里的”验收契约层”。BMAD / Speckit负责组织工作流，AI-TDD负责把验收边界变成可检查的机器契约。

适用场景：

• 多步骤需求需要拆成可执行任务包。
• 需要在AI实现前确认范围、约束与验收条件。
• 需要把计划、实现、测试、审计和交付证据串起来。

---

核心模块四：交付门禁与证据链

AI工程化交付不能只看”代码生成了”或”测试通过了”。真正可交付的结果需要回答：

• 哪些需求被验证了？
• 哪些负向约束没有被违反？
• 证据来自哪个命令、哪个报告、哪个产物？
• 当前结果是否复用了旧证据？
• 人类是否完成最终确认？

AI-TDD Gate、TRACE rows、EVD/ART/CMD 证据链和交付确认门禁共同构成交付门禁。它们的目标不是增加流程负担，而是避免 AI 生成的结果在最后一公里出现不可追溯的漂移。

---

延伸模块：AI Coding Mentor

如果说 AI-TDD 解决的是”一次交付如何不漂移”，那么 AI Coding Mentor 关注的是”团队如何持续评估、指导和训练 AI 编码系统”。

推荐作为延伸阅读：

• AI Coding Mentor 系列
• 从交付到训练：如何把AI编程协作变成Coding Mentor数据闭环
• 从工程实战到训练数据：AI工程化自动产出SFT数据的系统化方法

---

推荐采用路径

1. 先选一个小功能，写最小AI-TDD Manifest。
2. 为每个 MUST 添加至少一个验收测试或验证命令。
3. 为关键风险添加 NEG 负向断言和 OUT 范围边界。
4. 在实施前运行准入检查，确认新增验收项处于预期RED状态。
5. 让AI在Manifest约束下实现，再运行交付门禁。
6. 把失败原因、人工修正和验收证据沉淀为团队资产。