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

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

课程讲解

7.1 为什么需要一套流程

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

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

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

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

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

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

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

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

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

示例类型：伪代码。 伪代码，不可直接执行。它只表达判断顺序，实施时必须补齐真实接口、权限与错误处理。

拆解 → 下发指令 → 编码 → 验收 → 分支判断 → 更新图纸
                                                    ↓
                                                 回到"拆解"（下一个里程碑）

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

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

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

第一步：拆解。

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

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

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

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

拆解的原则：

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

如何与 AI 协作：

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

第二步：下发指令。

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

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

好的指令包含什么？

示例类型：参考。 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。

我们要实现里程碑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 生成策略）。所以它的代码可能看起来”对”，但逻辑错误、边界情况、安全隐患不是一眼能看出来的。验收不是不信任，而是工程的基本规范——就像你不会不检查就签收快递。本章的验收对象是代码；当里程碑的变更影响模型行为（提示词、模型、采样参数、上下文）时，代码检查接不住模型输出的质量——模型输出质量的评估见第 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 一个完整示例：笔记应用的分页功能

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

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

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

第二步：下发指令。

示例类型：参考。 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。

在当前笔记列表页添加分页功能。

需求：
- 每页显示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 契约、防抖约定写进蓝图。

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

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

---

暂停整理：先完成本章最小闭环

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

独立练习

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

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

本章必交产物：六步里程碑记录

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

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

查看参考反馈（先独立作答）

参考反馈

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

自评与下一步

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