子代理驱动开发

通过 delegate_task 子代理执行计划（2阶段审查）

子代理驱动开发

概述

通过为每个任务调度新的子代理来执行实现计划，并配合系统化的两阶段审查流程。

核心原则：每个任务用新子代理 + 两阶段审查（先验规范，再验质量）= 高质量 + 快速迭代。

使用场景

在以下情况使用此技能：

• 你已有一份实现计划（来自 writing-plans 技能或用户需求）
• 任务之间相互独立
• 质量和规范合规性很重要
• 你希望在任务之间有自动化的审查

对比人工执行：

• 每个任务都是全新上下文（不会因为累积状态造成混乱）
• 自动化审查流程，及早捕获问题
• 所有任务都有统一的质检
• 子代理可以在开始工作前提问

执行流程

1. 读取并解析计划

读取计划文件。一次性提取所有任务及其完整文本和上下文。建立待办清单：

# 读取计划
read_file("docs/plans/feature-plan.md")

# 创建包含所有任务的待办清单
todo([
    {"id": "task-1", "content": "创建 User 模型并添加 email 字段", "status": "pending"},
    {"id": "task-2", "content": "添加密码哈希工具函数", "status": "pending"},
    {"id": "task-3", "content": "创建登录接口", "status": "pending"},
])

关键：只读取一次计划。一次性提取所有内容。不要让子代理自己读计划文件——直接把完整任务文本放在上下文中。

2. 单任务工作流

对计划中的每个任务：

步骤 1：调度实现者子代理

使用 delegate_task 并提供完整上下文：

delegate_task(
    goal="实现任务 1：创建 User 模型，包含 email 和 password_hash 字段",
    context="""
    计划中的任务：
    - 创建文件：src/models/user.py
    - 实现 User 类，包含 email (str) 和 password_hash (str) 字段
    - 使用 bcrypt 进行密码哈希
    - 包含 __repr__ 方法用于调试

    遵循 TDD 流程：
    1. 先在 tests/models/test_user.py 中写失败的测试
    2. 运行：pytest tests/models/test_user.py -v（验证测试 FAIL）
    3. 写最小化实现代码
    4. 运行：pytest tests/models/test_user.py -v（验证测试 PASS）
    5. 运行：pytest tests/ -q（验证没有回归）
    6. 提交：git add -A && git commit -m "feat: add User model with password hashing"

    项目上下文：
    - Python 3.11，Flask 应用位于 src/app.py
    - 现有模型位于 src/models/
    - 测试使用 pytest，从项目根目录运行
    - bcrypt 已在 requirements.txt 中
    """,
    toolsets=['terminal', 'file']
)

步骤 2：调度规范合规审查

实现者完成后，验证是否符合原始规范：

delegate_task(
    goal="审查实现是否与计划中的规范一致",
    context="""
    原始任务规范：
    - 创建 src/models/user.py，包含 User 类
    - 字段：email (str)，password_hash (str)
    - 使用 bcrypt 进行密码哈希
    - 包含 __repr__ 方法

    检查项：
    - [ ] 规范中的所有需求都已实现？
    - [ ] 文件路径与规范一致？
    - [ ] 函数签名与规范一致？
    - [ ] 行为符合预期？
    - [ ] 没有添加额外内容（没有范围蔓延）？

    输出：PASS 或需要修复的具体规范缺口列表。
    """,
    toolsets=['file']
)

如果发现规范问题：修复缺口，然后重新运行规范审查。只有在完全符合规范后才继续。

步骤 3：调度代码质量审查

规范合规通过后：

delegate_task(
    goal="审查任务 1 实现的代码质量",
    context="""
    待审查文件：
    - src/models/user.py
    - tests/models/test_user.py

    检查项：
    - [ ] 遵循项目约定和代码风格？
    - [ ] 错误处理得当？
    - [ ] 变量/函数命名清晰？
    - [ ] 测试覆盖率足够？
    - [ ] 没有明显的 Bug 或遗漏的边界情况？
    - [ ] 没有安全问题？

    输出格式：
    - 严重问题：[继续前必须修复]
    - 重要问题：[应该修复]
    - 次要问题：[可选]
    - 结论：APPROVED（通过）或 REQUEST_CHANGES（需修改）
    """,
    toolsets=['file']
)

如果发现质量问题：修复问题，重新审查。只有在批准后才继续。

步骤 4：标记完成

todo([{"id": "task-1", "content": "创建 User 模型并添加 email 字段", "status": "completed"}], merge=True)

3. 最终审查

所有任务完成后，调度一个最终集成审查者：

delegate_task(
    goal="审查整个实现的一致性和集成问题",
    context="""
    计划中所有任务已全部完成。审查整个实现：
    - 各组件是否协同工作？
    - 任务之间是否有不一致？
    - 所有测试是否通过？
    - 可以合并了吗？
    """,
    toolsets=['terminal', 'file']
)

4. 验证并提交

# 运行完整测试套件
pytest tests/ -q

# 查看所有变更
git diff --stat

# 最终提交（如需要）
git add -A && git commit -m "feat: complete [feature name] implementation"

任务粒度

每个任务 = 2-5 分钟的专注工作。

粒度过大（错误示例）：

• "实现用户认证系统"

粒度合适（正确示例）：

• "创建 User 模型，包含 email 和 password 字段"
• "添加密码哈希函数"
• "创建登录接口"
• "添加 JWT token 生成"
• "创建注册接口"

红灯规则——禁止事项

• 没有计划就动手实现
• 跳过审查（规范合规或代码质量任一）
• 带着未修复的严重/重要问题继续
• 向同一文件发起多个实现子代理
• 让子代理自己读计划文件（直接在上下文中提供完整文本）
• 跳过场景上下文（子代理需要理解任务在整个计划中的位置）
• 忽略子代理的问题（在让他们继续之前先回答）
• 对规范合规接受"差不多就行"
• 跳过审查循环（审查发现问题 → 实现者修复 → 重新审查）
• 让实现者自我审查替代真正的审查（两者都需要）
• 在规范合规通过之前就开始代码质量审查（顺序错误）
• 当任一审查有未解决的问题时进入下一个任务

问题处理

子代理提问时

• 清晰、完整地回答
• 必要时提供额外上下文
• 不要催促他们马上开始实现

审查者发现问题

• 由实现者子代理（或新的子代理）修复
• 审查者再次审查
• 重复直到批准
• 不要跳过重新审查

子代理任务失败

• 调度一个新的修复子代理，具体说明哪里出了问题
• 不要在控制器会话中手动修复（避免上下文污染）

效率说明

为什么每个任务用新子代理：

• 防止累积状态导致的上下文污染
• 每个子代理获得干净、专注的上下文
• 不会因为之前任务的代码或推理而产生混淆

为什么两阶段审查：

• 规范审查及早捕获建造不足/过度的问题
• 质量审查确保实现质量良好
• 在问题跨任务累积之前捕获它们

成本权衡：

• 更多子代理调用（每个任务：实现者 + 2个审查者）
• 但在早期捕获问题（比后期调试累积问题更便宜）

与其他技能的集成

与 writing-plans 配合

此技能用于执行由 writing-plans 技能创建的计划：

• 用户需求 → writing-plans → 实现计划
• 实现计划 → subagent-driven-development → 可工作的代码

与 test-driven-development 配合

实现者子代理应遵循 TDD：

• 先写失败的测试
• 实现最小化代码
• 验证测试通过
• 提交

在每个实现者的上下文中包含 TDD 说明。

与 requesting-code-review 配合

两阶段审查流程本身就是一个代码审查。对于最终集成审查，使用 requesting-code-review 技能的审查维度。

与 systematic-debugging 配合

如果子代理在实现过程中遇到 Bug：

• 遵循 systematic-debugging 流程
• 找到根因后再修复
• 写回归测试
• 恢复实现

工作流示例

[读取计划：docs/plans/auth-feature.md]
[创建包含 5 个任务的待办清单]

--- 任务 1：创建 User 模型 ---
[调度实现者子代理]
  实现者："email 需要唯一吗？"
  你："是的，email 必须唯一"
  实现者：已实现，3/3 测试通过，已提交。

[调度规范审查者]
  规范审查者：✅ PASS — 所有需求已满足

[调度质量审查者]
  质量审查者：✅ APPROVED — 代码整洁，测试良好

[标记任务 1 完成]

--- 任务 2：密码哈希 ---
[调度实现者子代理]
  实现者：没有问题，已实现，5/5 测试通过。

[调度规范审查者]
  规范审查者：❌ 缺失：密码强度验证（规范要求"最少 8 个字符"）

[实现者修复]
  实现者：已添加验证，7/7 测试通过。

[再次调度规范审查者]
  规范审查者：✅ PASS

[调度质量审查者]
  质量审查者：重要问题：幻数 8，建议提取为常量
  实现者：已将 MIN_PASSWORD_LENGTH 提取为常量
  质量审查者：✅ APPROVED

[标记任务 2 完成]

... （继续处理所有任务）

[所有任务完成后：调度最终集成审查者]
[运行完整测试套件：全部通过]
[完成！]

记住

每个任务用新子代理
每次都要两阶段审查
先过规范合规
再过代码质量
永远不要跳过审查
及早捕获问题

质量不是偶然。是系统化流程的结果。

进一步阅读（需要时加载）

当编排涉及显著的上下文使用、长审查循环或复杂验证检查点时，加载以下参考资料获取特定原则：

• references/context-budget-discipline.md — 四层上下文降级模型（PEAK / GOOD / DEGRADING / POOR）、随上下文窗口大小缩放的读取深度规则，以及静默降级的早期预警信号。当运行将明显消耗大量上下文时加载（多阶段计划、多个子代理、大型产物）。
• references/gates-taxonomy.md — 四种典型关卡类型（Pre-flight、Revision、Escalation、Abort）及其行为、恢复方法和示例。在设计或审查任何有验证检查点的工作流时加载——明确使用词汇表，使每个关卡都有定义的入口、失败行为和恢复规则。

两份参考资料均改编自 gsd-build/get-shit-done（MIT © 2025 Lex Christopherson）。