AI Coding 工作流
我如何把 AI 纳入真实的软件开发闭环。不是 Cursor 按钮说明书。
本页是 AI Coding 栏目的唯一阶段总地图。不讲 Prompt 全文，不放文件模板，也不做项目实战。
什么时候用？
当你要把一个真实开发任务放进闭环，而不是单独让 AI 写一段代码时。
新项目从需求进入。老项目从读代码进入，不重做架构。这不是漏了一步，分叉见文末。
目标
形成可重复的总流程（不必每次从零重读）：
需求 → 拆解 → 架构 → Context → Rules → Spec
→ 实现 → 测试 → Review → Debug / 回归 → 交付核心原则：
AI 可以提高代码生产速度，但不能替代开发者对需求、架构、质量和最终结果负责。
完整闭环
1. 明确需求
2. 拆解任务
3. 架构
4. Context
5. Rules
6. Spec
7. 实现
8. 测试
9. Review
10. Debug / 回归
11. 交付重构不在主链上。没有新的 Spec，就不重构。
1. 明确需求
解决： 要解决什么问题？给谁用？怎样算有用？
验收标准和「不做什么」留到 Spec，这里不写成任务说明书。
AI 最容易「自作主张扩 scope」。问题没说清时，生成再快也是在制造返工。
人： 决定业务上该不该做。
AI： 不决定。可以帮你把含糊的描述问清楚，不能替你拍板。
2. 拆解任务
解决： 这一次只推进哪一刀，做完怎样能看出来？
读懂相关调用链
→ 改一个接口 / 一张表 / 一个页面
→ 再处理下一刀- 一次只推进一类改动
- 每步有可观察的结果（编译过、用例过、页面能点）
- 先最小闭环，再谈优化
拆解是工程能力，不是 Prompt 技巧。拆得清楚，AI 才稳。
人： 砍 scope，决定这一刀的边界。
AI： 可以列草案。采用哪一刀，人定。
3. 架构
解决： 系统准备怎么解决？发生在写代码之前。
只定系统边界，例如：
- 模块边界
- 技术栈
- 有哪些接口、哪些数据
- 系统级约束（分层、状态只能怎么走）
不写这一次的字段校验，不写测试命令。那些属于 Spec。
人： 拍板。模块是否被拆碎、是否过度设计、是否引入不必要的依赖，都不能外包。
AI： 可以列选项。不能定架构。
老项目跳过本步。扫描到的结构是现状，不是一份新设计。跳过不等于没做架构，而是不重新设计。见文末。
做法示例在 Cursor 新项目实战，本页不展开。
4. Context
解决： AI 需要知道这个项目现在是什么？
项目结构、技术栈、模块关系、已有的数据与接口、当前事实。不是「这一次要改什么」。
人： 提供事实，或删掉扫描里的猜测。
AI： 老项目里可以按你的范围扫描。扫出来的内容，人确认后才算 Context。
概念：Context & Rules。
文件放哪、章节怎么写：项目落地包。本页不复制模板。
5. Rules
解决： AI 在这个项目里必须遵守什么？所有任务都适用，不是只约束这一次。
例如修改边界、分层、数据库和 API 不能擅自改、不确定就停。具体条文只维护在仓库规则里。
人： 定规则，并保证它来自这个项目的真实习惯，而不是一本理想手册。
AI： 遵守。不另写一套规范。
模板只在 项目落地包。
6. Spec
解决： 这一次要实现什么，做到什么程度才算完成？
Spec 是当前任务的冻结约定。人确认之前，不许改代码。
先分清四个词：
| 回答 | |
|---|---|
| Context | 项目现在是什么 |
| Rules | 所有任务都要遵守什么 |
| Spec | 这一次做什么 |
| Prompt | 这一轮怎么让 AI 执行 |
Prompt 用完可以扔。Spec 要留下。Prompt 不能代替 Spec。
确认时只看五件事：做什么、范围、做到什么、验收、不做什么。用不到的不写。不在这里建规格体系，也没有单独的 Spec 页。
人： 确认并冻结。
AI： 可以起草。未确认时只改措辞，不改代码。
示例将写在两篇实战里，不在本页造例子：
7. 实现
解决： 按已经冻结的 Spec 把代码写出来。
Spec 已确认
→ AI 按 Spec 改代码
→ 人看 Diff，跑起来验证尽量避免：
一句话「帮我实现某某」
→ AI 直接大改几十个文件AI 按 Spec 实现，不按一句自然语言自由发挥。
人： 收口。范围、风格、是否允许动 Spec 之外的文件，人定。
AI： 写代码、补代码、按 Spec 生成测试草稿。
这一轮怎么提问：Prompt Pattern · 实现。
8. 测试
解决： 结果是否符合 Spec 的验收标准？
能自动化的尽量自动化。没有现成测试时，至少固定一条人工验收路径。
优先看主路径和 Spec 里写明的失败路径。「测试绿了」不等于「业务对了」，尤其在 AI 大量生成代码时。
没被 Spec 点名的行为有没有被带坏，放到下一步的回归里看。本步不另写测试理论。
人： 定测什么、判测试能不能抓住风险。
AI： 可以写用例或命令草稿。
提问方式：Prompt Pattern · 测试。
9. Review
解决： 这次 Diff 能不能留下？
AI 做初检，人做最终判断。重点看：
- Diff 本身
- 有没有超出 Spec
- 有没有违反 Rules
- 有没有破坏没点名的原有行为
- 有没有明显的质量问题
写完代码才发现模块边界被破坏：在这里否决。这不是第二次架构设计，不要回到第 3 步重写一份架构。
AI 发现的问题不一定是真的；AI 没发现也不代表没有问题。
人： 最终判断，决定改不改。
AI： 扫 Diff，标出可疑点。
做法与 Prompt 只在 AI Code Review。本页不复制。
10. Debug / 回归
解决： 测试或 Review 已经指出的问题，怎样最小地修好；没点名的行为是否还在。
没有失败、也没有要守住的旧行为，就不进入 Debug。
复现
→ 缩小范围
→ 看日志 / Diff / 调用链
→ 形成假设
→ 最小验证
→ 再改可以让 AI 辅助读栈、猜可疑点，但不要跳过复现。「再让 AI 整段重写」往往比定点修引入更多未知。
老项目尤其要证明：Spec 没有点名的行为与改前一致。这是回归，不是把系统重新测一遍。
人： 决定是否修、修到哪为止。
AI： 协助定位。不宣布「已经好了」。
提问方式：Prompt Pattern · Debug。没有单独的 Debug 页。
11. 交付
解决： 这次能不能收工？
对照 Spec 勾验收，并确认「不做」没有被偷偷扩大。
至少再看一眼：
- Diff 里没有无关文件
- 说得清改了什么、为什么、怎么验
复盘只记对下次有用的：哪类上下文一给就稳，哪类任务不能一次丢给 AI，哪次误报或漏报值得记住。
没有新的 Spec，就不重构。AI 很擅长「看起来更优雅」的重写；值不值、风险大不大，人判断。不在这里写发布、CI/CD 或版本流程。
人： 对最终结果负责。
AI： 不负责宣布完成。
新项目和老项目怎么走
主链相同的是后半段。入口不同。
新项目从需求开始，并且要做架构：
需求 → 拆解 → 架构 → Context → Rules → Spec → 实现 → 测试 → ReviewContext 由人按已知目标写成项目事实。
老项目从已有代码开始，不重新设计架构：
代码 → 理解 → Context → Rules → Spec → 实现 → 测试 → ReviewContext 从代码、表、接口里抽出，人删掉猜测。架构步骤整段跳过：记录现状，不产出新设计。读者若在老项目实战里看不到「架构」一节，是有意跳过，不是漏写。
两者汇合之后才是同一条：
Context → Rules → Spec → 实现 → 测试 → Review → Debug / 回归 → 交付展开见 Cursor 新项目实战 与 Cursor 老项目实战。
人机分工（面试可直接说）
| 环节 | 更偏谁 |
|---|---|
| 需求 | 人 |
| 任务拆解 | 人（可让 AI 列草案） |
| 架构 | 人。老项目跳过，不重新设计 |
| Context | 人确认事实。老项目可让 AI 扫描 |
| Rules | 人 |
| Spec | 人冻结。AI 可起草 |
| 实现 | AI 按 Spec 写，人收口 |
| 测试 | 人定测什么；草稿可 AI |
| Review | AI 初检 + 人终审 |
| Debug / 回归 | 人 |
| 是否重构 | 人。没有新 Spec 就不重构 |
| 最终交付 | 人 |
和「会用 Cursor」的差别
| 会用工具 | AI Coding 工作流 |
|---|---|
| 会提问、会补全 | 有固定闭环与验收 |
| 生成得多 | 改得准、回得了滚 |
| 依赖某一款 IDE | 方法可迁移到别的工具 |
| 出问题再问 AI | 先复现、再定点、再让 AI 辅助 |
| 一句话就开始写 | 先有 Spec，再按 Spec 实现 |
工具会换。这条闭环和「谁拍板」才是可迁移的。
我的判断
工作流的价值不在步骤名称，而在强制一件事：
每一步都知道谁拍板、用什么验收、AI 准许动到哪里。
做到这一点，AI 才是工程放大器；做不到，只是更快地制造技术债。