三阶段工作流：Plan Mode → 并行子 Agent → 物理验收标准
本文是「Claude 企业级工程实战手册」专栏第 08 篇。为什么无引导开发成功率只有 1.15%？三阶段工作流如何系统性解决这个问题。
数学告诉我们的真相
在复杂开发任务中，功能重构往往涉及 20 步以上的微观修改。假设每步决策正确率 80%：
无引导的直接开发，全链路一次性成功概率仅约 1.15%。
三阶段工作流通过建立确定性的流程约束，将 20 个模糊决策压缩为局部的、经过审查的确定性动作，使每步置信度逼近 100%。
工作流全景
阶段一：Plan Mode（只读静态探索）
└─ 输出：影响文件列表、架构设计、Schema 变更、测试蓝图
│
[ 人工白盒审查与蓝图微调（Ctrl+G）]
│
▼
阶段二：并行子 Agent 协作执行
└─ 子 Agent 在隔离上下文中并行工作，防止上下文污染
│
▼
阶段三：物理成功标准验收
└─ 拒绝"Looks Done"，必须提供真实的 pytest stdout 输出
阶段一：Plan Mode（执行前必做）
何时触发
涉及超过 3 个文件的任务，必须先进入 Plan Mode。
触发方式
# 方式一：快捷键
Shift + Tab # 切换到 Plan Mode
# 方式二：命令行启动
claude --permission-mode plan
# 方式三：对话内触发
/plan
Plan Mode 的工作机制
Plan Mode 下 Claude 只有 Read 权限，不触动任何磁盘写操作。它会分析代码并输出《实现计划蓝图》：
【实现计划蓝图】
任务：为 payment_service.py 添加双因素认证
影响文件（7 个）：
1. src/services/payment_service.py → 主逻辑修改
2. src/models/user.py → 新增 totp_secret 字段
3. src/schemas/auth.py → 新增 2FA 验证 Schema
4. src/api/auth_router.py → 新增 /auth/2fa 端点
5. alembic/versions/xxxx_add_totp.py → 数据库迁移
6. tests/test_payment_service.py → 新增测试用例
7. tests/test_auth_router.py → 新增端点测试
关键决策点：
- 2FA 实现方式：TOTP（推荐）还是 SMS？
- TOTP 库选择：pyotp（推荐）vs python-otp
- 密钥存储：加密存储在 DB vs 使用 KMS
预计风险：
1. 数据库迁移需要在低流量时段执行
2. 现有用户需要引导绑定 2FA 设备
预计变更量：约 380 行代码，15 个测试用例
人工审查（Ctrl+G）
按 Ctrl+G 在编辑器中打开计划文件，进行白盒调整：
[人工批注]
关于关键决策点 1：使用 TOTP（已确认）
关于关键决策点 3：密钥存储改为用 AES-256-GCM 加密后存 DB，
不用 KMS（成本考虑）。具体实现参考 src/utils/crypto.py。
关于预计风险 2：本期暂不做用户引导，只做后台实现。
前端流程下一期单独做。
带批注的计划发回 Claude，批准执行。
阶段二：并行子 Agent 协作
何时使用
- 大规模重构（>10 个文件）
- 批量生成测试用例
- 多模块同步变更
使用方式
# 在 Claude Code 中触发子 Agent
请为 src/services/ 下的所有服务文件分别生成完整的单元测试。
每个服务文件对应一个独立的测试文件。
每个服务的测试由独立的子 Agent 负责，并行执行，互不干扰。
子 Agent 的隔离价值
❌ 没有子 Agent（串行）：
主会话上下文 = 任务 + Agent A 日志 + Agent B 日志 + Agent C 日志 + ...
→ 上下文持续膨胀 → 注意力衰退 → 后期输出质量下降
✅ 有子 Agent（并行隔离）：
子 Agent A 上下文 = 任务 A（独立）
子 Agent B 上下文 = 任务 B（独立）
主会话上下文 = 任务 + A 摘要 + B 摘要（保持精简）
阶段三：明确物理成功标准
模糊定义 vs 工程化定义
❌ 模糊定义（不可接受）
"请修复登录页面的 Bug"
"帮我完成支付功能的重构"
✅ 工程化定义（必须这样写）
"请重构 src/services/payment_service.py 中的锁调度逻辑。
完成后在终端执行 pytest tests/test_payment_service.py -v，
验证结果必须输出 '12 passed, 0 failed'。
请提供完整的 stdout 输出作为交付凭证。"
成功标准模板
# 在任务描述末尾始终附加：
SUCCESS_CRITERIA_TEMPLATE = """
完成后请执行以下验证步骤：
1. 运行测试：`pytest {test_path} -v`
预期结果：{expected_test_result}
2. 运行 Lint：`ruff check {src_path}`
预期结果：无错误输出
3. 运行类型检查：`mypy {src_path}`
预期结果：无类型错误
请将以上三个命令的完整 stdout 输出作为交付凭证附在回复末尾。
"""
# 使用示例
task = f"""
请重构 src/services/payment_service.py 中的并发锁调度逻辑。
具体要求：[具体要求]
{SUCCESS_CRITERIA_TEMPLATE.format(
test_path="tests/test_payment_service.py",
expected_test_result="12 passed, 0 failed",
src_path="src/services/payment_service.py"
)}
"""
常见验收信号
| 任务类型 | 验收信号 |
|---|---|
| Bug 修复 | pytest tests/xxx.py -v → N passed, 0 failed |
| API 开发 | pytest tests/test_api.py -v + curl 真实请求成功 |
| 数据库迁移 | alembic upgrade head → Done |
| 代码重构 | ruff check src/ → 无错误 + 测试通过 |
| 性能优化 | 基准测试输出（before/after 对比） |
完整流程示例
# 1. 进入 Plan Mode
claude --permission-mode plan
# 2. 描述任务（不要急着执行）
用户：为 UserService 添加邮箱验证功能，包括发送验证邮件和验证 Token
# 3. Claude 输出计划蓝图，人工审查
# 4. 批准执行
用户：计划看起来不错，但第3点改成用 Celery 异步发送邮件而不是同步。
其他没问题，请开始执行。
# 5. Claude 开始执行，完成后验收
用户：请执行以下命令并给我看输出：
pytest tests/test_user_service.py -v
# 6. 查看真实输出，验收通过
专栏导航 · Claude 企业级工程实战手册
⬅️ 上一篇：07. Claude Code Hooks 安全栅栏：PreToolUse 高危拦截 + PostToolUse 自动格式化 ➡️ 下一篇：09. Claude Code Agent Skills 升级：从 Slash 命令到带 YAML Frontmatter 的结构化技能包
本专栏共 14 篇，系统覆盖 Claude 模型选型 / Prompt 工程 / Claude Code 工作流 / API 高级用法 / MCP / RAG / AI 安全合规全链路。欢迎收藏：Claude 企业级工程实战手册
