---
title: 第 4 章 统一工作流：Plan → Execute → Verify → Review → Reuse
seo:
  title: "AI 编程标准闭环工作流指南"
description: "详细介绍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

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

```markdown
# 目标
实现订单 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 |
| **同类缺陷反复出现** | 测试 / 静态规则 / 评测集 | 高风险缺陷进入发布门禁 |
| **研究结论不可追溯** | 证据表与来源编号 | 成为产品决策模板与知识库 |