企业官网建设流程全解析

Superpowers 的子代理驱动开发（Subagent-Driven Development，SDD）是让 AI 编程又快又稳的方法论：给计划里每个任务派发一个全新子代理（fresh subagent），任务完成后先查规格符合度、再查代码质量，并用最小可用模型控成本。本文带你从零跑通 SDD 全流程。

一、核心理念：3 行读懂 SDD 为什么快又稳

• fresh subagent per task：每个任务一个干净的子代理，不继承主会话的历史上下文，避免污染；主代理只负责「调度」，保持自身上下文清爽。
• 双阶段评审：每个任务交付后先过 spec 关（做对没做对、有没有多做/漏做），再过 quality 关（写得干不干净、测试够不够）。
• 最小模型原则：用最便宜、能胜任的模型干每类活，机械任务用快模型，架构评审才上最强模型。

核心公式：Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration

二、SDD 在真实会话里长什么样

上图是启用原生任务管理后的 Claude Code 会话：顶部是任务依赖图（Dependency Flow），中间是任务总览表（标注了 Blocked By 依赖），底部 TaskList 实时显示每个任务 pending / in_progress / completed 状态。这正是 SDD 的「执行底座」——任务依赖被强制执行，代理无法跳步或抢跑。

三、准备工作：worktree 隔离 + 台账防丢进度

SDD 开工前做三件准备（对应 SKILL.md 的 Setup 章节）：

1. 隔离工作区：用using-git-worktrees建独立 worktree，绝不在 main/master 上直接开工。
2. 建台账（ledger）：运行scripts/sdd-workspace PLAN_FILE生成该计划专属目录.superpowers/sdd/<plan名>/，维护一个progress.md。
   • 台账记录的是状态而非推理。会话一旦触发上下文压缩（compaction）代理会「失忆」——真实案例里，没有台账的控制器把已完成任务重新派发了一整轮，这是最贵的一次失败。台账 +git log就是你的恢复地图。
3. 通读计划：读一遍计划文件，记下 Global Constraints，并扫一遍任务间是否互相矛盾，把结论写进台账。

四、核心循环：每个任务一个 fresh subagent

SDD 主循环逐任务执行，共 5 步：

1. 派发 implementer 子代理

• 派发前先记录 BASE（git rev-parse HEAD），评审和修复回合都要用到。
• 运行scripts/task-brief PLAN_FILE N把任务全文抽成单个 brief 文件，让 brief 成为唯一需求来源，而非把计划全文塞进 prompt。
• 派发 prompt 只写：任务定位一句话、brief 路径、前序任务接口/决策、你已消解的歧义、报告文件路径。精确数值只出现在 brief 里。
• 用 implementer-prompt.md 模板。子代理自己实现、写测试、提交、自检，且永不派发自己的子代理（评审是控制器的活）。

2. 处理 4 种报告状态

永远不要无视升级，也不要用「不变的参数」硬逼同一模型重试。

3. 双阶段评审：先 spec，后 quality

• 运行scripts/review-package PLAN_FILE BASE HEAD把「提交列表 + stat + 完整 diff」打包成一个文件交给评审（diff 永不进入你的上下文）。
• 评审输入是三个文件：同一个 brief、报告文件、评审包，外加 Global Constraints。
• 评审顺序严格固定：Part 1 规格符合度（Missing / Extra / Misunderstood），Part 2 代码质量（代码、测试、结构）。
• 用 task-reviewer-prompt.md 模板，必须给出两个结论：spec ✅/❌ 与 task quality Approved/Needs fixes。

4. 修复循环 + 5 轮熔断

评审发现 spec ❌ 或 Critical/Important 问题时进入修复循环，每个任务最多 5 轮：

• 第 1–3 轮：resume 原 implementer（它上下文还在，最懂代码）。
• 第 4–5 轮：换更强模型的 fresh implementer 接手——「能活过 3 次 resume 的循环，通常说明原 implementer 看不见自己的问题」。
• 每轮都以一次范围收窄的 re-review收尾（scripts/review-package+ re-review-prompt.md），只验证 finding 是否解决、修复有没有引入新破坏。
• 熔断：第 5 轮后仍有 open finding 就停止派发，由你逐条裁定——「可争 → parked；真实且承重 → 裁定最小改动并带入下一任务」。

5. 标记任务完成

评审干净（或 open finding 都已在熔断点 parked+裁定）后，往台账追加：Task <N>: complete (commits <base7>..<head7>, review clean)，然后TaskUpdate标记完成，进入下一任务。只要还有未修复且未裁定的 Critical/Important，绝不允许进入下一任务。

五、模型选型：让每个角色用最便宜的模型

关键洞察是轮数比单价更重要（turn count beats token price）——最便宜的模型在多步工作上常多花 2–3 倍轮数，总成本反而更高。

⚠️ 派发子代理时务必显式指定 model——漏写会静默继承会话里最贵的那个模型，直接让这套选型失效。

可选的模型路由机制（把mechanical/standard/frontier映射到具体模型）详见 docs/model-routing-flow.md。

六、三个关键脚本一览

任务格式（Goal/Files/AC/Verify +json:metadata）的完整字段见 task-format-reference.md。

七、最终评审与收尾

全部任务完成后：

1. 用MERGE_BASE（分支起点）跑review-package生成整个分支的评审包。
2. 用最强模型派发最终代码评审（code-reviewer.md），并让它看台账里的 deferred-minor 与 parked 行，决定哪些必须修。
3. 若最终评审仍有 finding：只派发一次修复子代理（带全部 finding），再跑一次 re-review，残余 finding 走熔断裁定。没有第二次修复波。
4. 最终评审干净后，删除本计划的 workspace，用finishing-a-development-branch收尾。

八、SDD vs 并行执行：3 大优势

九、常见误区（官方「反合理化」清单）

完整对照表见 SKILL.md 的 Common Rationalizations 章节。

快速上手清单

1. 用writing-plans把需求拆成 2–5 分钟粒度的任务（每个带 Goal/Files/AC/Verify）。
2. 用using-git-worktrees建隔离工作区。
3. 对每个任务循环：task-brief → 派发 implementer → 处理报告 → review-package → 双阶段评审 → 修复循环 → 标记完成。
4. 全部完成后跑最终评审，收尾分支。