18.4 制定计划与代码迭代
面向经管学生、研究者与从业者的 AI 智能体设计教材
用户确认设计文档后，用一条指令启动计划编写：
设计方案已经确认了，/writing-plans 帮我制定实施计划writing-plans 读取 docs/superpowers/specs/ 下的设计文档，扫描项目目录，确认哪些文件已存在、哪些需要新建。然后按模块边界把功能拆成独立任务。每个任务的执行时间控制在 2-5 分钟，包含具体的文件清单、代码片段和测试命令。计划保存到 docs/superpowers/plans/ 目录并 commit。下游的 subagent-driven-development 会直接读取这份 plan 文件，提取其中的 Task 清单和执行顺序。
任务拆分与依赖分析
以金融多源知识库项目为例，计划拆分为五个任务。任务之间的依赖关系决定了执行顺序：
| 任务 | 内容 | 依赖 | 可独立执行 |
|---|---|---|---|
| Task 1 | 数据源适配层（PDF 解析 + Excel 读取） | 无 | 是 |
| Task 2 | 向量索引服务（ChromaDB 集成） | 无 | 是 |
| Task 3 | 检索与问答 API | 无 | 是 |
| Task 4 | 前端查询界面 | Task 3 | 否 |
| Task 5 | 端到端集成测试 | Task 1-4 | 否 |
Task 1-3 互相独立，执行顺序灵活。Task 4 依赖 Task 3 提供的 API 端点。Task 5 需要全部前置任务完成后才能运行。
后端开发：文档解析模块
计划就绪后，用户启动代码迭代：
按计划开始开发吧，先从文档解析模块开始。/subagent-driven-developmentsubagent-driven-development 为 Task 1 派遣一个专属子代理。子代理拿到的上下文只包含 Task 1 的任务描述和文件清单，不继承主会话的历史记录。
子代理内置 test-driven-development，按 red-green-refactor 流程工作。具体步骤：
- Red——先写一个测试用例
test_pdf_adapter.py，定义 PDF 解析的输入输出格式。运行测试，确认失败。 - Green——编写
pdf_adapter.py的最小实现，让测试通过。 - Refactor——测试通过后，提取公共逻辑到
base.py，优化错误处理。重新运行测试，确认没有破坏已有功能。
子代理完成后，进入双阶段审查。主代理先派遣规格审查子代理，对照计划逐条检查：功能是否齐全、有无多做或少做、接口签名是否一致。规格审查通过后，再派遣质量审查子代理，检查测试覆盖、安全隐患和代码风格。
Agent-1 完成 Task 1 → 规格审查
├── BaseAdapter 抽象接口 → 通过
├── PdfAdapter 缺少元数据提取（计划要求） → 修复
└── 再次审查 → 通过
Agent-1 → 质量审查
├── 测试覆盖 88%
├── PDF 路径未做输入校验 → 修复
└── 再次审查 → 通过
→ Task 1 标记完成，启动下一个任务审查不通过时，原子代理执行修复，修复后重新审查，直到两个阶段都通过。这种”执行 → 审查 → 修复 → 再审查”的循环是迭代的核心。
前端模块走同一套流程——需求已在设计文档中明确，计划中也有对应任务，子代理按同样的链条执行。
前端开发：搜索界面
后端三个任务完成后，用户启动前端开发：
后端搞定了，现在做前端搜索界面。我想要简洁一点的风格。subagent-driven-development 为 Task 4 派遣子代理。前端组件设计如需专业配色和排版建议，可额外引入 ui-ux-pro-max Skill（https://github.com/nextlevelbuilder/ui-ux-pro-max-skill）。本章场景下，CLAUDE.md 中的 UI 规范已足够指导子代理完成界面开发。
子代理按计划中的界面设计要求实现前端组件，完成后同样走双阶段审查。
第一次跑完整个流程很少能一次通过。规格审查可能发现漏掉的功能点，质量审查可能指出安全隐患。这些都是正常的。关键不在于一次做对，而在于每轮审查都能精确定位问题、快速修复。三到四轮迭代后，代码质量会显著提升。
五个任务全部通过双阶段审查后，主代理还会派遣一个全局审查子代理，检查跨模块的接口对齐和数据流完整性。通过后，代码合入主分支。