AI 辅助开发的工程化闭环
AI 可以提高开发速度，但“生成代码更快”不是工程效率的完整定义。真正需要优化的是从问题进入团队，到代码上线并留下可维护知识的整个周期。
我更倾向于把 AI 看作一个不具备最终决策权的工程协作者：它可以读取上下文、拆解任务、提出方案、编写代码和补充测试，但每个阶段都必须产生可检查的交付物，并通过对应的质量门禁。
问题定义 ↓需求拆解 ↓架构与影响分析 ↓小步实现 ↓测试与自动验证 ↓人工审查 ↓文档与经验沉淀这个闭环的重点不是让 AI 完成更多步骤，而是让错误更早暴露，让每一步都能回溯。
先建立三个基本约束
Section titled “先建立三个基本约束”1. AI 输出不是事实
Section titled “1. AI 输出不是事实”模型可能误读代码、忽略隐含约束，也可能给出语法正确但不符合业务语义的实现。需求、接口、数据结构和测试结果必须以仓库、运行环境和业务规则为准。
因此，任务中需要明确区分：
- 已确认事实：代码、Schema、接口文档、可复现的运行结果
- 工作假设：为了继续分析而暂时采用的判断
- 待确认问题：缺少信息且可能改变方案的事项
如果三者混在一起，AI 很容易把推测扩写成“确定结论”。
2. AI 不能绕过工程边界
Section titled “2. AI 不能绕过工程边界”现有代码库已经包含模块边界、命名规则、错误处理、测试方式和交付流程。AI 的实现应该先适配这些约束，再考虑引入新抽象。
典型边界包括：
- 不修改任务范围以外的模块
- 不覆盖无法解释的现有改动
- 不伪造接口、配置、数据或测试结果
- 不在缺少验证时宣称任务完成
- 涉及权限、资金、数据迁移时提高审查等级
3. 自动验证不能替代人工判断
Section titled “3. 自动验证不能替代人工判断”编译通过只能说明类型和语法满足要求，测试通过也只覆盖已经写进测试的行为。业务正确性、架构合理性、异常路径和长期维护成本仍然需要人工判断。
比较可靠的分工是：
AI：扩大分析和实现吞吐量工具：提供确定性的验证结果人：承担业务、架构和发布决策阶段一：把需求转换为任务契约
Section titled “阶段一：把需求转换为任务契约”直接把一句业务描述交给 AI，通常会得到一个范围过大的方案。第一步应该先形成任务契约，让“完成”具有可判断的含义。
一份最小任务契约至少包含：
Goal要解决的具体问题。
Current Behavior当前系统如何工作，问题如何复现。
Expected Behavior完成后哪些可观察行为发生变化。
In Scope本次允许修改的模块和流程。
Out of Scope明确不处理的相关问题。
Acceptance Criteria可以通过测试或人工检查确认的结果。
Constraints兼容性、性能、安全、数据和发布时间约束。AI 在这个阶段适合做三件事：
- 找出描述中的模糊词和隐藏前提。
- 将目标拆成可以独立验证的行为。
- 列出需要从代码或业务方确认的问题。
例如，“优化订单处理性能”不是可执行任务。它至少需要继续确认瓶颈位置、目标指标、数据规模、允许改变的一致性边界，以及是否涉及上下游系统。
阶段二：先读代码，再做架构方案
Section titled “阶段二：先读代码，再做架构方案”AI 很容易基于通用经验给出一个“理论上正确”的设计，但项目真正需要的是符合现有系统形状的方案。
在提出改动前，应先完成以下调查：
- 找到入口、核心调用链和数据所有权
- 阅读相邻模块的实现与测试
- 确认仓库已有的公共组件和基础设施
- 检查配置、数据库 Schema 和外部依赖
- 查看工作区是否存在其他未完成修改
调查完成后，方案至少回答：
| 问题 | 需要说明的内容 |
|---|---|
| 修改什么 | 文件、模块、接口和数据结构 |
| 为什么这样改 | 与现有模式和需求约束的关系 |
| 影响什么 | 调用方、存储、消息、缓存和部署 |
| 如何验证 | 单元测试、集成测试、构建或人工流程 |
| 如何回退 | 开关、兼容路径、数据恢复或版本回滚 |
当任务较复杂时，可以将调查和实现分开：先由多个 Worker 分别分析调用链、测试覆盖和风险，再由 Coordinator 汇总结论并决定唯一方案。并行的价值在于扩大读取范围，而不是同时生成多套互相冲突的代码。
阶段三：将实现切成可验证的小步
Section titled “阶段三：将实现切成可验证的小步”AI 一次修改越多，审查成本和误改概率越高。实现阶段应优先选择能够独立解释、独立验证的小批次。
一个常见顺序是：
- 补充或修改数据模型。
- 实现核心领域逻辑。
- 接入调用方和外部边界。
- 补齐异常处理与可观测性。
- 更新测试和文档。
每一步都应保持两个属性：
- 局部完整：当前改动本身具备清晰目的，不依赖大量后续代码才能理解
- 可验证：存在对应的测试、类型检查、构建命令或运行观察点
AI 生成代码时，还需要限制它的自由度。比“帮我实现这个功能”更有效的约束是：
沿用现有 Repository 和错误类型。只修改列出的模块。不要增加新的运行时依赖。保持现有公开接口兼容。先写失败测试，再实现最小改动。约束越具体，模型越不需要通过猜测填补上下文。
阶段四：让测试覆盖风险，而不是覆盖代码行
Section titled “阶段四：让测试覆盖风险，而不是覆盖代码行”AI 很适合生成测试骨架和边界案例，但它也会倾向于验证自己的实现细节。测试设计应从风险出发，而不是从当前代码结构反推断言。
可以按以下顺序考虑：
- 业务不变量：金额守恒、状态流转、权限边界、幂等约束
- 失败路径：超时、重复消息、部分成功、外部依赖不可用
- 兼容行为：已有调用方、历史数据和旧配置
- 正常路径：最常见的成功流程
- 实现细节：只有确实属于契约时才固定
对于消息和分布式流程，测试不能只验证“消息被发送”。还应覆盖：
- 重复消费是否安全
- 顺序变化是否影响结果
- 失败重试是否产生副作用
- 消息字段演进是否兼容
- 数据落库与事件发布之间是否存在一致性缺口
自动验证清单
Section titled “自动验证清单”根据项目技术栈选择确定性的命令：
格式化与静态检查类型检查或编译目标模块单元测试跨模块集成测试生产构建数据库迁移检查关键页面或 API 冒烟测试AI 必须报告实际执行了哪些命令、结果是什么、哪些检查因为环境原因没有运行。不能用“理论上应该通过”代替验证。
阶段五：把 Code Review 作为独立任务
Section titled “阶段五：把 Code Review 作为独立任务”让同一次对话中的 AI 在完成代码后简单确认“没有问题”，价值有限。更可靠的方式是切换到审查视角，重新从 diff 和需求契约开始检查。
Review 应优先寻找：
- 行为回归和遗漏的异常路径
- 跨模块契约不一致
- 并发、事务、幂等和数据一致性问题
- 权限扩大、敏感信息泄露和不安全默认值
- 无法证明必要的新抽象或依赖
- 只覆盖正常路径的测试
- 与验收标准不一致的实现
可以要求 AI 按严重程度输出发现，并为每个问题提供文件位置、触发条件和实际影响。没有发现问题时，也需要说明剩余测试缺口和无法消除的风险。
人工审查则重点确认：
- 需求和业务规则是否被正确理解。
- 方案是否符合系统长期演进方向。
- 测试是否覆盖真正重要的失败模式。
- 是否允许该变更进入发布流程。
阶段六：把结果沉淀为可复用上下文
Section titled “阶段六：把结果沉淀为可复用上下文”如果每次任务都让 AI 重新探索相同规则，效率提升会很快遇到上限。完成开发后，应将稳定信息沉淀到适合的位置。
不同内容应进入不同载体：
| 内容 | 适合的位置 |
|---|---|
| 构建、测试和提交方式 | 仓库开发说明 |
| 模块边界与依赖原则 | 架构文档或 ADR |
| API 和数据契约 | Schema、接口文档 |
| 常见故障与处理步骤 | Runbook |
| 可复用任务步骤 | Agent Skill 或脚本 |
| 阶段性决策与复盘 | Blog 或 Changelog |
只沉淀已经验证且预计长期有效的信息。临时调试结论、未经确认的猜测和特定会话细节不应该变成永久规则。
一个可执行的任务循环
Section titled “一个可执行的任务循环”实际使用时，可以将完整流程压缩为以下循环：
1. Restate 用自己的语言重述目标、范围和验收标准。
2. Inspect 从代码、测试和配置中收集事实。
3. Plan 给出改动点、风险和验证方式。
4. Implement 小步修改，并保持每一步可解释。
5. Verify 执行测试、检查和生产构建。
6. Review 重新阅读 diff，寻找回归与遗漏。
7. Report 说明完成内容、验证结果和剩余风险。
8. Distill 将稳定经验写入文档、测试或自动化规则。如果任务在任何阶段出现新事实，应回到前一步修正方案，而不是为了维持原计划继续堆叠代码。
常见失败模式
Section titled “常见失败模式”先生成大量代码，再寻找问题
Section titled “先生成大量代码，再寻找问题”这会把需求不确定性转化成大面积代码修改。更好的顺序是先缩小问题和接口，再生成最小实现。
用更长的 Prompt 代替真实上下文
Section titled “用更长的 Prompt 代替真实上下文”Prompt 无法替代代码、日志、Schema 和测试。应该让 AI 读取可信来源，而不是在描述中复制一个可能已经过期的系统模型。
只让 AI 写测试，不检查测试语义
Section titled “只让 AI 写测试，不检查测试语义”模型可能生成永远通过的断言、重复实现逻辑的测试，或者通过 Mock 避开真正的集成边界。测试代码同样需要 Review。
把一次成功经验直接升级为全局规则
Section titled “把一次成功经验直接升级为全局规则”特定项目中的有效做法不一定适用于所有仓库。规则应说明适用范围，并允许被新的事实修正。
用 AI 速度掩盖变更规模
Section titled “用 AI 速度掩盖变更规模”生成 20 个文件可能只需要几分钟，但理解和维护这些文件仍然需要真实成本。工程吞吐量最终受审查与验证能力限制。
提交前检查清单
Section titled “提交前检查清单”- 目标、范围和非目标是否明确
- 关键结论是否来自代码或可验证资料
- 方案是否沿用现有模块边界
- 每个改动是否能解释其必要性
- 业务不变量与失败路径是否有测试
- 所有声称通过的命令是否真实执行
- 是否重新检查了完整 diff
- 是否说明未验证项和剩余风险
- 稳定经验是否沉淀到正确位置
AI 辅助开发的核心不是把人从流程中移除，而是重新分配人的注意力：让模型承担高吞吐量的读取、生成和初步分析，让自动化工具提供确定性反馈，让工程师集中处理业务语义、系统边界和发布决策。
当需求、实现、验证和审查形成闭环后，AI 才从“更快的代码生成器”变成可以进入长期工程体系的生产力工具。