# 第 7 章 六步工作法：AI 辅助编程的核心流程

## 本章目标

- **O1** 能够追踪“拆解与指令”“编码与验收”“分支与更新”之间的前向与反馈路径（产物：六步里程碑记录）
  - 证据: 六步里程碑记录画出“拆解与指令”“编码与验收”“分支与更新”的前向路径和返回路径
- **O2** 能够构造六步里程碑记录，注明每轮输入、判断和回写证据（产物：六步里程碑记录）
  - 证据: 六步里程碑记录为每一环写明输入、判断、输出和负责人
- **O3** 能够用六步法把一项工作推进到可追溯里程碑而非提交次数（产物：六步里程碑记录）
  - 证据: 产物保留六步记录和至少一个与验收证据对应的版本点

## 学习路径

- **初学者**: 本章迁移任务是：能够用六步法把一项工作推进到可追溯里程碑而非提交次数。先按图中的“反馈闭环”关系完成六步里程碑记录的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够用六步法把一项工作推进到可追溯里程碑而非提交次数。提交六步里程碑记录后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 六步里程碑记录
- **图解类型**: six-step-cycle
- **关系语义**: 三环先沿前向路径产生结果，再由返回路径把观察写回；没有回写就不构成闭环。
- **核心概念**: 拆解与指令 · 编码与验收 · 分支与更新

![第 7 章六步里程碑记录教学图](/learning/diagrams/zh/chapter-07.svg)

沿前向与返回两条路径检查六步里程碑记录，确认结果确实改变下一轮输入。

图先从“拆解与指令”前向经过“编码与验收”到“分支与更新”，再以虚线返回起点。前向箭头产生结果，返回箭头承载观察和修正；若结果没有回写到下一轮输入，流程只是单程而不是闭环。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 7.1 为什么需要一套流程

假设你刚安装好 AI 编码工具，想试试它的能力。你输入："帮我做一个记事本应用。"

AI 开始生成代码。文件一个个创建，代码一行行输出。看起来很不错——界面美观，功能齐全。

但当你仔细看的时候，发现了问题：数据存在浏览器的 localStorage 里，但你原本想存在服务器上；使用的技术栈不是你团队在用的；有些代码看起来很复杂，但你只需要简单的功能。

这就是"没有流程"的后果。AI 很强大，但如果不对齐目标，它做出的东西可能完全不是你要的。

为什么？因为模型不能访问你没有提供或没有授权工具读取的项目事实。团队技术栈、数据位置和规模目标若未进入上下文，它只能补全缺失信息；生成结果也许能运行，却没有证据说明符合真实约束。

一套好的流程，能确保 AI 始终在正确的方向上工作。它不限制 AI 的能力，而是把 AI 的能力引导到正确的方向。

从第二部分的"心智跃迁"到这里，方法论开始落地。六步工作法，就是这条引导 AI 的核心轨道。

### 7.2 六步总览：拆解 → 下发指令 → 编码 → 验收 → 分支判断 → 更新图纸

六步工作法将一次 AI 编码任务分解为六个步骤，形成一个闭环：

<!-- code-example:chapter-07-E1 mode:pseudocode -->
> **示例类型：伪代码。** 伪代码，不可直接执行。它只表达判断顺序，实施时必须补齐真实接口、权限与错误处理。
```text
拆解 → 下发指令 → 编码 → 验收 → 分支判断 → 更新图纸
                                                    ↓
                                                 回到"拆解"（下一个里程碑）
```

每个步骤都有明确的目标和产出：

| 步骤 | 做什么 | 产出 |
|------|--------|------|
| 拆解 | 把功能需求拆成小任务（里程碑） | 里程碑清单 |
| 下发指令 | 告诉 AI 当前要做什么（含验收标准） | 清晰的指令 |
| 编码 | AI 执行编码 | 代码文件 |
| 验收 | 检查代码是否符合要求 | 验收结论（PASS / NEEDS_FIX / REBUILD） |
| 分支判断 | 根据验收结论决定下一步 | 下一步行动 |
| 更新图纸 | 把新发现写进蓝图 | 更新的蓝图 |

### 7.3 每一步的详细拆解与产出物

第一步：拆解。

做什么：把你要实现的功能拆解成若干个小任务，每个任务称为一个"里程碑"。

为什么这一步如此重要？因为 AI 的上下文窗口是有限的。一个复杂的任务如果一次性交给 AI，它会在多个功能之间跳来跳去，导致代码耦合度高、错误难以定位。拆解的核心目的不是"把大事化小"，而是把风险隔离——每个里程碑独立完成、独立验收，即使某个里程碑出了问题，也不会影响其他部分。

好的拆解是什么样的？以一个"记事本应用"为例，可以拆解为：

- 里程碑 1：创建项目脚手架（项目结构、配置文件）
- 里程碑 2：实现笔记列表页面（显示所有笔记）
- 里程碑 3：实现笔记编辑页面（创建和编辑笔记）
- 里程碑 4：实现笔记删除功能
- 里程碑 5：添加搜索功能

拆解的原则：

1. 每个里程碑应小到能在一次专注工作循环内完成；具体时长由团队、代码库和风险决定。若无法在开始前说清输入、产物与验收方式，就继续拆分。
2. 每个里程碑应可独立验收。做完后能立刻测试。
3. 里程碑之间应有依赖顺序。先做基础功能，再做上层功能。

如何与 AI 协作：

> 帮我把"记事本应用"拆解成若干个可以独立实现和验收的里程碑。为每项列出输入、产物、依赖、停止条件和验证命令；若时长只能猜测，请标成估算而不是事实。

第二步：下发指令。

做什么：针对当前要做的里程碑，向 AI 下达明确的指令。

为什么指令质量重要？清晰的输入、约束和验收标准能减少模型自行补全需求的空间，但不能保证代码正确。模糊的指令（"实现用户登录"）会留下大量未决项；更具体的指令应明确认证机制、会话期限、错误语义和安全边界，并仍需通过测试与人工复核。验收驱动开发的核心是"先定验收标准，再让 AI 出码"。

好的指令包含什么？

<!-- code-example:chapter-07-E2 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```text
我们要实现里程碑2：笔记列表页面。

需求：
- 显示所有笔记的标题和更新时间
- 按更新时间倒序排列
- 点击笔记进入编辑页面
- 支持分页，每页10条

技术约束：
- 使用 Next.js App Router
- 数据通过 API 接口获取（接口已在里程碑1中实现）
- 使用 Tailwind CSS 做样式

验收标准：
- 页面能正常加载并显示笔记列表
- 分页功能正常
- 点击笔记能跳转到编辑页面
```

指令的四个要素：

1. 要做什么——当前里程碑的目标；
2. 需求细节——功能的具体要求；
3. 技术约束——必须遵守的技术约定；
4. 验收标准——如何判断任务已完成。

第三步：编码。

做什么：AI 根据你的指令生成代码。你在这个步骤中观察 AI 的工作，但不干预。

这个阶段你要做什么：

- 观察 AI 生成的文件是否符合预期；
- 如果 AI 理解有偏差，在它完成当前文件后指出；
- 不要打断 AI 的编码过程去修改细节——等验收阶段集中处理。

常见问题：

- AI 写的代码用了我没听说过的库怎么办？先记下来，在验收阶段评估。如果这个库满足需求且不带来额外负担，可以接受。
- AI 写了超出当前里程碑的代码怎么办？温和地提醒它："这个功能在后面的里程碑中实现，先完成当前的任务。"

第四步：验收。

做什么：检查 AI 生成的代码是否符合要求。这是六步中最容易被跳过、但也最重要的一步。

为什么验收不可跳过？因为流畅、像样的生成并不能证明逻辑正确。模型依据上下文预测 token 分布；只有贪心解码每步取最高概率 token，采样则从分布中选择（见 [Transformers 生成策略](https://huggingface.co/docs/transformers/generation_strategies)）。所以它的代码可能看起来"对"，但逻辑错误、边界情况、安全隐患不是一眼能看出来的。验收不是不信任，而是工程的基本规范——就像你不会不检查就签收快递。本章的验收对象是代码；当里程碑的变更影响模型行为（提示词、模型、采样参数、上下文）时，代码检查接不住模型输出的质量——模型输出质量的评估见第 23 章。

验收检查清单：

1. 功能检查——功能是否按验收标准实现了？
2. 代码检查——代码风格是否一致？有没有明显的质量问题？
3. 边界检查——有没有处理异常情况（空数据、错误输入等）？
4. 安全检查——有没有明显安全问题（如 SQL 注入、XSS 等）？
5. 蓝图检查——代码是否符合项目架构的约定？

如何验收：你可以自己看代码，也可以让 AI 帮你检查。一个有效的方法是让 AI 做自检：

> 验收当前里程碑的代码。检查：1. 功能是否全部实现；2. 代码质量是否合格；3. 边界情况是否处理；4. 是否存在安全隐患；5. 是否符合项目架构。

第五步：分支判断。

做什么：根据验收结论决定下一步。

验收后有三种结论：

- PASS：代码符合要求。行动：提交代码到 git，进入下一个里程碑。提交信息示例：`feat: 实现笔记列表页面`。
- NEEDS_FIX：有小问题需要修复。行动：向 AI 描述问题，让它修复，然后重新验收。示例："列表页的分页按钮样式不对，应该用圆形按钮而不是方形。修复后重新验收。"
- REBUILD：偏离蓝图太多。行动：按第 10.4 节先区分个人未共享分支与共享提交、保存需要保留的工作并核验目标，再选择安全恢复路径，随后重新下发指令。示例："这个实现用了我不熟悉的状态管理库；我会按已核验的恢复路径回到干净里程碑，再用更简单的方案重做。"

判断标准：

| 信号 | 该 REBUILD？ |
|------|-------------|
| 修改了不该改的核心代码 | 是 |
| 引入了不必要的复杂技术 | 是 |
| 单个文件膨胀严重（超过 300 行） | 考虑 |
| 有多个小问题但核心逻辑正确 | NEEDS_FIX |

为什么 REBUILD 比 NEEDS_FIX 更重要？很多新手看到 REBUILD 会犹豫——“好不容易写了这么多，回滚了不就白做了？”但 AI 的生成成本与人的审查成本并不对称；第 7 章这里保留信号表供流程中速查，完整总成本计算与适用边界见第 7.5 节。

第六步：更新图纸。

做什么：如果在实现过程中有新的发现（比如发现了更好的技术方案、原来的设计有漏洞），把这些发现写进蓝图。

为什么要更新蓝图？蓝图是 AI 的"工作记忆"——每次对话重置后，AI 通过蓝图重建对项目的理解。如果蓝图过期了，AI 就会基于错误的信息做决策。所以蓝图不是一次性的文档，而是持续更新的活文档。

什么时候更新蓝图：

- 发现了更好的技术方案；
- 原来的设计有遗漏或错误；
- 新增了之前没考虑到的需求；
- 某个里程碑的拆分方式需要调整。

### 7.4 一个完整示例：笔记应用的分页功能

让我们用一个完整的例子来演示六步工作法。

场景：给笔记列表页添加分页功能。

第一步：拆解。这是一个小功能，不需要进一步拆解。整个功能就是一个里程碑。

第二步：下发指令。

<!-- code-example:chapter-07-E3 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```text
在当前笔记列表页添加分页功能。

需求：
- 每页显示10条笔记
- 页面底部显示分页控件（上一页、下一页、页码）
- 切换页面时不需要刷新整个页面

技术约束：
- 后端API已支持page和size参数
- 使用现有的UI组件库
- 分页组件放在页面底部

验收标准：
- 分页控件正常显示
- 点击页码能正确切换
- 第一页时"上一页"按钮禁用
- 最后一页时"下一页"按钮禁用
- 总页数正确显示
```

第三步：编码。AI 生成了分页组件和相关逻辑。你观察到它使用了项目中的现有组件。

第四步：验收。你检查发现分页功能正常，但"第一页时上一页按钮禁用"这个边界情况没有处理。

第五步：分支判断。结论是 NEEDS_FIX。你告诉 AI 修复这个边界情况。AI 修复后重新验收，通过。结论变为 PASS。

第六步：更新图纸。你发现了一个之前没考虑到的情况：当笔记数量很少（比如只有 3 条）时，分页控件不应显示。把这个发现更新到蓝图中。

然后进入下一个里程碑。

### 7.5 修补还是重建：把总成本算完整

下面是一组教学假设，不是客户实测或行业基准：当前失败仅限尚未发布的独立里程碑，已验收基础可恢复，需求与接口已明确；统一以人民币计价，人力暂按每小时 200 元折算。已经花掉的时间是沉没成本，两条路径都从此刻计算增量成本。

| 成本项 | 局部修补 | 受控恢复后重建 |
|:---|---:|---:|
| 保护需保留的工作、核对恢复点 | 0.5 小时 × 200 = 100 元 | 0.5 小时 × 200 = 100 元 |
| 定位纠缠逻辑／重写边界与指令 | 2 小时 × 200 = 400 元 | 1 小时 × 200 = 200 元 |
| 修改或生成的工具费用 | 20 元 | 40 元 |
| 人工审查、回归与集成验证 | 1.5 小时 × 200 = 300 元 | 1.5 小时 × 200 = 300 元 |
| 从现在起的总成本 | 100 + 400 + 20 + 300 = 820 元 | 100 + 200 + 40 + 300 = 640 元 |

在这些假设下，重建少花 180 元，原因是减少了理解混乱逻辑的工作，绝非生成免费。应先列出必须保护的文件与状态，按第 10.4 节核验恢复路径，再决定；任何路径都必须支付审查与验证成本。

这个结论随条件改变：如果旧模块承载隐含业务规则、数据迁移或复杂外部状态，重建需要额外恢复、补齐用例和协调上线，其总成本可能反超修补。相反，一个已定位、边界清楚的缺陷往往适合 NEEDS_FIX。把不确定项及其上限写出来，不能为证明重建划算而省略保护已有工作、停机或验收开销。第 8 章把这笔账作为纪律依据，第 10 章负责落实恢复动作，均不另造第二套算例。

### 【实操】用六步工作法完成一个小功能

题目：为一个已有的用户列表页添加"按姓名搜索"功能，完整走一遍六步工作法。

引导（每步应该做什么）：

1. 拆解：评估这个功能能否作为一个独立里程碑（能——它不依赖其他未完成功能）。如果觉得它太大，拆成"搜索 API 参数"+"搜索框 UI"+"结果实时刷新"三个子任务。
2. 下发指令：写出包含四要素的指令——目标（添加搜索功能）、需求（输入关键词按姓名模糊搜索、实时刷新）、技术约束（后端 API 已支持 search 参数、使用现有组件库、防抖 300ms）、验收标准（输入关键词能正确筛选、无结果时显示空状态、清除搜索恢复完整列表）。
3. 编码：让 AI 执行，只观察不打断。
4. 验收：用五维清单检查（功能/代码/边界/安全/蓝图）。特别注意边界——搜索关键词为空、只匹配到一条、包含特殊字符时是否正常。
5. 分支判断：验收 PASS 则提交（`feat: 用户列表支持按姓名搜索`）；NEEDS_FIX 则修复后重新验收；REBUILD 则回滚重建。
6. 更新图纸：把搜索功能的 API 契约、防抖约定写进蓝图。

验收要点（供讲师/自评使用）：

- 学员的指令是否包含全部四个要素？
- 学员是否在编码阶段保持了"只观察"？
- 学员的验收是否覆盖了边界情况？
- 学员的分支判断是否果断、符合经济账？
- 学员是否在完成后更新了蓝图？

---

<!-- cognitive-load-checkpoint -->
## 暂停整理：先完成本章最小闭环

先只写出“拆解与指令”与“编码与验收”之间的一条关系，并把它填进六步里程碑记录。确认这一步有输入、判断和证据后，再加入“分支与更新”；三项尚未连通时，不进入独立练习。

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-07.md`，写上版本、决定、证据和缺项。

对unknown误判执行分解、下发、编码、验收、分支判断、文档更新六步，逐步记录输入、产物和实际结果。

<!-- chapter-artifact-requirement -->
### 本章必交产物：六步里程碑记录

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 六步里程碑记录画出“拆解与指令”“编码与验收”“分支与更新”的前向路径和返回路径
- O2: 六步里程碑记录为每一环写明输入、判断、输出和负责人
- O3: 产物保留六步记录和至少一个与验收证据对应的版本点

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

先保存失败样本，委派仅修改分类逻辑，保留期望不动；运行基线和候选检查；按证据判断PASS或NEEDS_FIX；记录版本、限制与下一步。不得把未运行的检查写成通过，也不因流程齐全就声称已交付客户。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；六步里程碑记录、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [Git 官方参考](https://git-scm.com/docs) — Git project, 2026-09-17. 版本、分支、提交与恢复操作须按实际仓库状态验证。