计划-验证-执行流水线

用户1208

5月29日修改

一个完整的开发工作流，仅需 3 个命令：用动态研究团队制定计划，用独立的专业审查员验证，用并行智能体执行。每次运行通过 ADR 学习循环改进下一次，逐步减少人工干预。​

阅读时间：约 25 分钟前置条件：子智能体、任务工具、工作树、基本 ADR 概念相关：「计划驱动开发」、「智能体团队」、「规格优先」​

1.
TL;DR​

2.
理念​

3.
三个命令​

4.
动态智能体池​

5.
ADR 学习循环​

6.
CLAUDE.md 规范​

7.
上下文管理​

8.
适用场景​

9.
成本概览​

10.
延伸阅读​

TL;DR

代码块

/plan-start    → 五阶段规划：PRD 分析 + 动态研究团队 + ADR​
/plan-validate → 两层审查：结构检查 + 触发型专业智能体​
/plan-execute  → 工作树 + TDD + 并行执行 + PR + 合并 + 清理​
​

与 /plan 模式的区别：

•
研究由并行运行的专业智能体完成，而非单个智能体顺序执行​

•
验证独立于规划（无确认偏差）​

•
每个重要决策都生成 ADR，自动解决未来决策​

•
执行在 git 工作树中生成每任务智能体，按任务提交，全程处理直到合并 PR​

每个命令之间运行 /clear 以重置上下文并避免压缩开销。

理念

非规定性 AI 优先

告诉 Claude 要实现什么，绝不告诉如何实现。一旦你规定了实现细节，你就是在用自己的知识作为上限，而非以 Claude 的能力作为起点。​

新项目的良好开场提示：

代码块

我应该如何最有效地使用你来构建这个平台？

让 Claude 提出架构方案。你的工作是验证决策，而非指令式指挥。​

不打补丁，不走弯路

对流水线中每个智能体的硬性规则：

我们构建最先进的软件。始终选择最佳架构、最健壮的模式和行业标准方法。​

构建时间和精力与架构决策无关。绝不将实现复杂性纳入方案评估。正确的解决方案始终是最佳解决方案。​

执行检查清单（实现前应用）：

我是否在使用向后兼容标志、shim 或遗留模式？

遵循当前官方文档的新项目会这样做吗？

我是在迁移旧模式而非学习新模式吗？

我是在修补一个组件，而修复应属于系统层面？

如有任何回答为是：停止，在正确层面修复。

为何需要独立验证？

没有参与编写计划的验证者不受其假设的束缚。研究表明，带对抗性框架的多智能体审查比自我审查发现的问题明显更多。平均一个计划在独立团队的挑战下产生约 18 个问题——约 95% 可从现有 ADR 和第一性原理自动解决。​

三个命令

/plan-start — 五阶段规划

阶段 1：PRD 与设计分析（交互式，无智能体）

计划-验证-执行流水线​