AI Spark 知识库

外观

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

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

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

目录 ​

  1. TL;DR
  2. 理念
  3. 三个命令
  4. 动态智能体池
  5. ADR 学习循环
  6. CLAUDE.md 规范
  7. 上下文管理
  8. 适用场景
  9. 成本概览
  10. 延伸阅读

TL;DR ​

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

与 /plan 模式的区别：

  • 研究由并行运行的专业智能体完成，而非单个智能体顺序执行
  • 验证独立于规划（无确认偏差）
  • 每个重要决策都生成 ADR，自动解决未来决策
  • 执行在 git 工作树中生成每任务智能体，按任务提交，全程处理直到合并 PR

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

理念 ​

非规定性 AI 优先 ​

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

新项目的良好开场提示：

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

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

不打补丁，不走弯路 ​

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

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

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

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

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

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

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

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

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

为何需要独立验证？ ​

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

三个命令 ​

/plan-start — 五阶段规划 ​

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

阅读 PRD，在任何智能体工作之前将问题归纳为 3 个桶：

  • 缺失需求（不明确的验收标准、未说明的边缘情况）
  • 模糊需求（多种有效解释）
  • 合规问题（安全、数据隐私、API 合约）

展示带利弊的选项，记录决策。非 PRD 工作（重构、基础设施、bug 修复）可跳过。

若 UI 变更在范围内，扩展到设计分析：界面清单、状态目录（空/加载/已填充/错误）、交互规格、动画模式、无障碍访问（ARIA）、设计 Token 更新。

阶段 2：技术分析 （1-2 个探索智能体 + 交互式）

首先检查现有 ADR 和 PATTERNS.md。若 3+ 个已确认 ADR 匹配决策 → 无需询问即自动解决。否则：

  • 生成探索智能体进行有针对性的代码库研究
  • 展示带选项和建议的架构决策
  • 为重要决策创建 ADR 文档（参见 ADR 学习循环）
  • 更新 PATTERNS.md

阶段 3：范围评估 （自动 + 用户批准）

对智能体池应用触发规则（参见动态智能体池）。展示带每个智能体理由的建议团队。用户可在研究开始前添加或移除智能体。

层级智能体数量标签
00单独（内联研究）
11-3专注
24-6标准
37-9全面
410+全谱系

阶段 4：研究与计划创建 （动态团队）

  • 层级 0：内联研究，无智能体
  • 层级 1+：在后台并行生成已批准的智能体，主控通过 TaskOutput 循环监控
  • planning-coordinator（Opus）将所有报告综合为最终计划
  • 提交计划文件、ADR 和创建产物

输出：docs/plans/plan-{name}.md + docs/adr/ADR-XXXX.md + docs/plans/metrics/{name}.json

自动转换：无未解决歧义 → 自动启动 /plan-validate

/plan-validate — 两层验证 ​

第一层：结构验证 （内联，即时）

无需智能体的机械检查：

  • 计划格式和完整性（所有必填章节存在）
  • 任务排序和依赖链（无循环依赖）
  • 文件存在性检查（列出要修改的文件确实存在）
  • ADR 一致性（计划与其 ADR 一致）
  • CLAUDE.md 规则合规性

第二层：专业审查 （基于触发，0-8 个智能体）

智能体触发条件模型
security-reviewer认证、支付、PII、RBAC、新 APIOpus
db-migration-reviewer新表、列、索引、迁移Opus
performance-reviewer新解析器、查询、路由、新依赖Sonnet
design-system-reviewer新 UI 组件、视觉样式Sonnet
ux-reviewer新页面、表单、交互Sonnet
cross-platform-reviewerWeb + 移动端，或共享包Sonnet
native-app-reviewer移动端界面、原生 UI 包Sonnet
integration-reviewer新服务、库、OTEL 配置Opus

对于简单计划不会自动选择智能体。支付功能可能触发 4+ 个。

自动修复阶段

每个问题必须解决——不可跳过。分类：

  1. 与现有 ADR 决策匹配的问题 → 自动解决
  2. 与已确认 PATTERNS.md 条目匹配的问题 → 自动解决
  3. 可从第一性原理解决的问题 → 自动解决
  4. 残余问题 → 人工决策 → 新规则 → 下次自动解决

自动转换：所有问题已解决 → 自动启动 /plan-execute

/plan-execute — 执行至合并 PR ​

单个命令处理一切：

  1. 工作树创建 — 从当前分支创建隔离分支
  2. TDD 脚手架 — 为标记为 TDD（测试驱动开发）的任务先写失败测试
  3. 基于层级的并行执行 — 检测独立任务，生成每任务智能体，按任务提交
  4. 漂移检测 — 若实现偏离计划则标记
  5. 质量门控 — 并行测试 + 集成冒烟测试（GraphQL 探测、容器日志扫描、计划定义的冒烟命令）
  6. PR 前文档更新 — PRD 对账 + 计划归档（在工作树中）
  7. PR 创建和合并 — squash 合并，干净的提交消息
  8. 合并后指标 — 执行数据提交到指标文件
  9. 工作树清理 — 移除分支和工作树

若质量门控失败：由专用调试智能体最多自动修复 3 次。仍然失败 → 通知人工。

动态智能体池 ​

智能体不硬编码在 CLAUDE.md 中。它们在调用时定义——描述、触发标准和模型选择嵌入在生成它们的计划阶段中。这使 CLAUDE.md 保持轻量，同时让每个智能体对其角色有完整上下文。

研究池（/plan-start） ​

智能体触发条件模型
code-explorer始终Sonnet
arch-researcher多层变更（2+ 层）Sonnet
database-analyst任何 DB schema 变更Sonnet
security-analyst认证、支付、PII、RBACOpus
test-analyzer非简单功能Sonnet
cross-platform-specialist需要移动端兼容性Sonnet
native-app-specialist任务涉及移动端/UISonnet
design-system-researcherUI 变更在范围内Sonnet
dependency-researcher添加新包Sonnet
devops-specialistDocker、环境变量、CI/CDSonnet
integration-researcher新服务、库、OTELOpus
planning-coordinator始终（当 2+ 个智能体时）Opus

关键设计选择：

  • Opus 仅用于高风险角色（安全、集成、协调）
  • Sonnet 用于标准研究（质量好、成本低）
  • planning-coordinator 仅在选择 2+ 个智能体时生成——它负责综合，不负责研究

验证池（/plan-validate） ​

参见上方第二层表格。这些是与研究池不同的智能体——验证者不受创建过程的偏见影响。

ADR 学习循环 ​

每个重大架构决策都生成一个 ADR。随时间推移，ADR 积累为减少人工干预的机构记忆。

触发 ADR 的条件 ​

始终创建 ADR 的情况：

  • 多种有效交互模式之间的选择（覆盖层 vs 页面、抽屉 vs 模态框）
  • 现有约定中没有的新动画或过渡模式
  • 平台差异决策（Web vs 移动端行为）
  • 引入新模式的加载状态策略
  • 认证策略、DB schema 方法、服务边界决策
  • 具有架构影响的新依赖选择

不创建 ADR 的情况：

  • 由已批准来源或现有约定决定的决策
  • 已确立模式内的细微布局选择
  • 显而易见的状态目录条目（标准的空/加载/错误状态）

成熟度级别 ​

Plain
1 个 ADR  → 观察中   — 已追踪，尚不具规范性
2 个 ADR  → 涌现中   — 作为推荐默认值呈现，带先例上下文
3+ 个 ADR → 已确认   — 规划时自动解决（无需人工输入）
            → 候选晋升为 CLAUDE.md 硬性规则

循环过程 ​

Plain
/plan-start 阶段 2     →  ADR 创建
                               ↓
                        PATTERNS.md 更新
                               ↓
/adr-review（定期）    →  检测 ADR 间的模式
                               ↓
                        提议 CLAUDE.md 晋升
                               ↓
未来 /plan-start       ←  已确认规则自动解决决策

每 10-15 个计划运行 /adr-review 以批量分析模式并提议 CLAUDE.md 添加内容。

复利效应：有 20 个计划的项目能自动解决约 80% 的架构决策。人工输入只关注真正的新颖决策。

CLAUDE.md 规范 ​

硬性限制：120 行 ​

CLAUDE.md 中的每一行在每次请求时都会消耗上下文。一个 300 行的 CLAUDE.md 是在每个提示词之前运行的开销。设置并执行硬性限制。

值得在 CLAUDE.md 中占一行的内容：

  • 第一性原则（覆盖智能体偏好的硬性规则）
  • 已确认的 ADR 模式（3+ 次出现）
  • 智能体无法从代码库推断的项目特定约定
  • 指向子文件的指针

不应放在 CLAUDE.md 中的内容：

  • 设计系统、环境配置、架构文档的完整内容
  • 适用于不到 10% 任务的规则
  • 解释和理由（将其写在 ADR 中）

指针策略 ​

不将所有上下文加载到 CLAUDE.md，而使用指针：

Markdown
## 上下文文件（仅在相关时加载）
- @docs/DESIGN_SYSTEM.md    — 当 UI 变更在范围内
- @docs/ARCHITECTURE.md     — 当触及服务边界
- @docs/ENV_CONFIG.md       — 当修改 Docker 或环境变量
- @docs/ADR_PATTERNS.md     — 在规划阶段

智能体只加载其任务所需的内容。后端任务不会加载设计系统。上下文保持干净。

定期修剪 ​

每 10-15 个计划与 /adr-review 一起审查 CLAUDE.md。晋升已确认的模式，删除已通过代码库约定变得显而易见的规则，修剪任何未被引用的内容。

上下文管理 ​

步骤之间使用 /clear ​

在 /plan-start、/plan-validate 和 /plan-execute 之间运行 /clear。每个命令都是自包含的——磁盘上的计划文件是交接产物，而非内存上下文。

不使用 /clear：上下文在所有阶段积累，压缩触发更早，智能体从先前阶段继承无关上下文，Token 成本显著增加。

为何有效 ​

每个命令从磁盘读取其输入（计划文件、ADR、代码库）。没有需要在步骤之间保留在上下文窗口中的状态。步骤之间清理的规范是使流水线在大型项目中不因上下文限制而中途崩溃的原因。

适用场景 ​

适合使用此流水线的情况 ​

  • 功能涉及多个文件和层次（API + DB + UI）
  • 安全敏感的变更（认证、支付、PII）
  • 复杂的数据库迁移
  • 新的外部服务集成
  • 任何规划错误代价高昂的情况
  • 决策历史重要的团队项目

不适合使用的情况 ​

  • 拼写错误修复、简单重构（使用标准 /plan 模式）
  • 需求未知的探索性原型开发
  • 时间压力下的紧急修复（改用双实例规划）
  • 涉及 ≤2 个文件且无架构决策的变更

层级 0 快捷方式 ​

对于小型但非简单的变更，仍然运行流水线，但系统会检测到层级 0 范围并跳过智能体生成——研究内联进行，验证仅限第一层，执行为单智能体。相同命令，更低开销。

成本概览 ​

阶段成本驱动因素大致范围
/plan-start 层级 0仅内联研究$0.10-0.30
/plan-start 层级 1-22-6 个 Sonnet 智能体$0.50-2.00
/plan-start 层级 37+ 个智能体 + Opus 协调者$2.00-8.00
/plan-validate0-8 个智能体$0.20-3.00
/plan-execute每任务智能体 + 质量门控$0.50-5.00
典型功能（层级 2）完整流水线$2-10

随 ADR 覆盖率增长，成本复利下降：所需智能体更少，验证问题更少，执行更快。

定期使用 /plan-metrics 查看历史成本趋势并校准估算。

延伸阅读 ​

  • 「计划驱动开发」 — 原生 /plan 模式，更轻量的替代方案
  • 「双实例规划」 — 更简单的双实例模式
  • 「智能体团队」 — 原生并行协调（实验性）
  • 「任务管理」 — 跨会话协调的 Tasks API
  • 「规格优先开发」 — CLAUDE.md 作为规格合约
  • 「ADR 编写智能体」 — 独立 ADR 生成
  • 「计划挑战者智能体」 — 对抗性计划审查

来源：飞书 · AI Spark 知识库 ｜ 原文（最新版）：https://lcnniolukk80.feishu.cn/wiki/OBhCwsOXRiiuJxkXUkDcvs2Bnge ｜ 归档：2026-06-04