第 4 章统一工作流：Plan → Execute → Verify → Review → Reuse

详细介绍AI编程标准闭环工作流体系，涵盖各阶段划分、核心概念区分、高质量任务输入模板与验证恢复规则，帮助团队建立稳定可复现的工程流程。

效率差距不在于会不会聊天，而在于是否形成稳定、可观察、可恢复的闭环。两套工具的命令不同，但工程方法可以统一。

4.1 标准七段闭环

阶段	人类负责	Agent 负责	可见证据
1. Define	明确目标、边界、验收、约束和责任人	读取上下文、暴露假设、提出最小澄清	任务 Brief / Issue / SPEC
2. Plan	审阅范围，删除不必要复杂度	分析影响面、拆步骤、识别风险和命令	计划、文件清单、测试清单
3. Prepare	选择分支、环境、权限和依赖	检查 Git 状态、规则文件、环境准备	分支 / worktree / 环境日志
4. Execute	批准可接受动作、处理业务决策	读写文件、运行工具、迭代修复	Diff、命令输出、中间产物
5. Verify	判断结果是否满足真实目标	运行测试、构建、浏览器、数据与异常验证	测试结果、截图、日志、指标
6. Review	做架构、风险、可维护性与发布判断	总结改动、风险、回滚、生成 PR 文案	Review 结论、PR、未决项
7. Reuse	决定哪些经验值得固化	更新规则、Skill、Hook、模板与评测集	版本库中的可复用资产

4.2 先区分 Plan、Goal 与 Spec

概念	时间尺度	载体	何时使用	常见错误
Plan	当前会话 / 当前任务	会话中的实施计划	陌生代码、多文件修改、路径不确定	计划很详细但没有验收标准
Goal	较长运行周期	/goal 的结果与完成条件	需要持续运行、阶段性监督、自动继续	把模糊愿望直接设成长目标
Spec	跨会话、跨角色、可版本化	SPEC.md / RFC / PRD + 验收	中大型功能、多人协作、长期追踪	写成百科全书，和实现状态脱节

组合方式：先用 Plan 澄清当前路径；需要跨时段执行时把清晰结果转成 Goal；需要多人、跨会话和可追溯时，把稳定决策固化成 Spec。

4.3 一条高质量任务 Brief

跨工具通用任务输入模板：

# 目标
实现订单 CSV 导出，并能处理 10 万行数据。

# 范围
只改后台导出接口与前端下载入口；不改权限模型，不引入新队列。

# 输入与参考
- SPEC: docs/specs/order-export.md
- 现有模式: src/features/customer-export/

# 约束
- 不新增生产依赖
- 不读取或修改生产数据
- 必须兼容现有审计日志

# 验收
- 正常、空数据、无权限、超大数据四条路径通过
- pnpm test / typecheck / build 通过
- 给出回滚步骤和 PR 描述

4.4 什么时候必须先计划

改动横跨三个以上模块，或你无法明确指出正确入口。
涉及数据库、认证、权限、支付、发布、基础设施、第三方 API 或客户数据。
任务来自模糊业务语言，需要先把成功标准翻译成可验证行为。
需要多人或多个 Agent 并行，必须先定义边界、依赖和合并顺序。
你希望复用方案或让他人评审，而不仅是拿到一段可运行代码。

4.5 会话卫生：上下文不是越多越好

症状	原因	处理
开始引用旧需求	不同任务混在同一长会话	新建聊天或 `/clear`；从 SPEC 和 Git 状态重建上下文
连续几轮补丁仍跑偏	原始目标或架构假设错误	停止执行，重新进入 Plan；不要在错误方向上继续微调
规则反复丢失	关键要求只在聊天说过一次	写入 AGENTS.md / Skill / Hook
大文件和日志淹没上下文	没有先筛选证据	先生成索引、摘要和查询，再读取必要片段
多个 Agent 互相覆盖	共享目录和分支	使用 worktree；约束每个 Agent 的可写文件集

4.6 验证优先：把“看起来完成”改成证据

模糊要求	可验证改写
“做一个页面”	本地可打开；加载、空、错误、无权限四种状态可复现；关键交互可操作；响应式布局无明显破损
“优化性能”	指定接口 P95 从基线降到目标；给出测量脚本、样本量、环境和前后数据
“修好登录问题”	登录、刷新、过期、退出、无权限和多标签页路径通过；没有新增敏感日志
“整理周报”	生成 Markdown 与飞书文档；来源可追溯；发送前预览；失败输出错误与重试方法
“研究竞品”	限定时间窗口、样本、证据类型；事实与推断分离；最终落到决策与实验

4.7 失败恢复：设计可回滚，而不是祈祷一次成功

任务前记录 Git 状态，创建分支、checkpoint 或可恢复快照。
数据库只生成迁移和回滚脚本，不在不受控环境直接执行生产变更。
外部系统写操作先 dry-run，再在测试目标运行，最后人工批准正式执行。
长任务分里程碑，每个里程碑都有可运行状态和证据，不让所有结果堆到最后。
一旦发现计划的基础假设错误，停止并重新规划，不要靠更多补丁掩盖。

4.8 复用飞轮：错误只允许发生一次半

发现	最小沉淀	升级条件
Agent 猜错项目命令	规则文件写入唯一命令	多个项目都需要时升级为组织模板
每次都漏跑同一验证	Skill / checklist	必须 100% 执行时升级为 Hook / CI
外部系统参数重复解释	Command / Skill 参数化	跨团队使用时封装为 Plugin / MCP
同类缺陷反复出现	测试 / 静态规则 / 评测集	高风险缺陷进入发布门禁
研究结论不可追溯	证据表与来源编号	成为产品决策模板与知识库

第 4 章 统一工作流：Plan → Execute → Verify → Review → Reuse

第 4 章统一工作流：Plan → Execute → Verify → Review → Reuse