275 lines
7.4 KiB
Markdown
275 lines
7.4 KiB
Markdown
|
|
---
|
|||
|
|
name: subagent-driven-development
|
|||
|
|
description: 在当前会话中执行有独立任务的实现计划时使用
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 子代理驱动开发
|
|||
|
|
|
|||
|
|
通过为每个任务派发新的子代理来执行计划,每个任务完成后进行两阶段审查:先规格符合性审查,再代码质量审查。
|
|||
|
|
|
|||
|
|
**核心原则:** 每个任务新子代理 + 两阶段审查(规格然后质量)= 高质量,快速迭代
|
|||
|
|
|
|||
|
|
## 何时使用
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
有实现计划?
|
|||
|
|
↓ 是
|
|||
|
|
任务大多独立?
|
|||
|
|
↓ 是
|
|||
|
|
→ 子代理驱动开发
|
|||
|
|
|
|||
|
|
否则 → 手动执行或先头脑风暴
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**优势:**
|
|||
|
|
- 同一会话(无上下文切换)
|
|||
|
|
- 每个任务新子代理(无上下文污染)
|
|||
|
|
- 每个任务后两阶段审查:先规格符合性,再代码质量
|
|||
|
|
- 快速迭代(任务之间无人工等待)
|
|||
|
|
|
|||
|
|
## 流程
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
读取计划,使用 Task 系统创建任务
|
|||
|
|
↓
|
|||
|
|
每个业务 Task:
|
|||
|
|
├── 派发 Implementer 子代理
|
|||
|
|
│ ├── 阅读任务需求
|
|||
|
|
│ ├── 遵循 TDD
|
|||
|
|
│ ├── 实现功能
|
|||
|
|
│ ├── Git commit
|
|||
|
|
│ └── 更新 Task metadata
|
|||
|
|
│
|
|||
|
|
├── 派发 Spec Reviewer 子代理
|
|||
|
|
│ ├── 独立阅读代码
|
|||
|
|
│ ├── 逐条验证需求
|
|||
|
|
│ └── 检查遗漏或多余功能
|
|||
|
|
│ ↓ 问题? → Implementer 修复 → 重新审查
|
|||
|
|
│
|
|||
|
|
├── 派发 Code Quality Reviewer 子代理
|
|||
|
|
│ ├── 审查代码质量
|
|||
|
|
│ └── 分类问题:关键/重要/次要
|
|||
|
|
│ ↓ 问题? → Implementer 修复 → 重新审查
|
|||
|
|
│
|
|||
|
|
└── 主窗口:TaskUpdate status=completed
|
|||
|
|
↓
|
|||
|
|
还有更多任务?
|
|||
|
|
↓ 是 → 下一个 Task
|
|||
|
|
↓ 否 → 校验 Task 执行
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 子代理派发模板
|
|||
|
|
|
|||
|
|
### Implementer 子代理
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Task tool (general-purpose):
|
|||
|
|
description: "实现 Task N: {Task标题}"
|
|||
|
|
prompt: |
|
|||
|
|
你正在实现一个具体的开发任务。
|
|||
|
|
|
|||
|
|
## 任务信息
|
|||
|
|
|
|||
|
|
{Task JSON 的完整 description 内容}
|
|||
|
|
|
|||
|
|
## Task metadata 更新规范(必须遵守)
|
|||
|
|
|
|||
|
|
在执行过程中,你必须持续通过 TaskUpdate 更新 metadata:
|
|||
|
|
|
|||
|
|
1. 开始任务时:
|
|||
|
|
TaskUpdate taskId={id} metadata={"started_at": "{当前时间}"}
|
|||
|
|
|
|||
|
|
2. 每次修改文件后:
|
|||
|
|
TaskUpdate taskId={id} metadata={"files_modified": ["file1.py", "file2.py"]}
|
|||
|
|
|
|||
|
|
3. 遇到错误时(必须记录,包含解决方案):
|
|||
|
|
TaskUpdate taskId={id} metadata={"errors_encountered": ["错误描述 - 解决方案"]}
|
|||
|
|
⚠️ 如果你无法解决某个问题而选择跳过或简化,必须如实记录
|
|||
|
|
|
|||
|
|
4. 运行测试后:
|
|||
|
|
TaskUpdate taskId={id} metadata={"test_results": "5/5 passed"}
|
|||
|
|
|
|||
|
|
5. 提交代码后:
|
|||
|
|
TaskUpdate taskId={id} metadata={"git_commit": "{hash}", "commit_message": "{msg}"}
|
|||
|
|
|
|||
|
|
## 执行要求
|
|||
|
|
|
|||
|
|
- 遵循 TDD:先写测试,再实现
|
|||
|
|
- 每个有意义的变更都要提交
|
|||
|
|
- 自审:完成后检查实现是否完整
|
|||
|
|
- 如实记录:不要隐瞒错误或跳过的内容
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Spec Reviewer 子代理
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Task tool (general-purpose):
|
|||
|
|
description: "审查 Task N 的规格符合性"
|
|||
|
|
prompt: |
|
|||
|
|
你正在审查一个实现是否符合其规格。
|
|||
|
|
|
|||
|
|
## 被请求的内容
|
|||
|
|
|
|||
|
|
{Task JSON 的完整 description 内容}
|
|||
|
|
|
|||
|
|
## 实现者声称构建的内容
|
|||
|
|
|
|||
|
|
{Implementer 子代理的返回报告}
|
|||
|
|
|
|||
|
|
## 关键:不要信任报告
|
|||
|
|
|
|||
|
|
实现者的报告可能不完整、不准确或过于乐观。你必须独立验证。
|
|||
|
|
|
|||
|
|
**要:** 阅读实际代码,逐行比较,检查声称但未实现的部分
|
|||
|
|
**不要:** 相信报告,信任完整性声明
|
|||
|
|
|
|||
|
|
## 输出格式
|
|||
|
|
|
|||
|
|
- ✅ 符合规格
|
|||
|
|
- ❌ 发现问题:[具体列出,带 file:line 引用]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Code Quality Reviewer 子代理
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Task tool (general-purpose):
|
|||
|
|
description: "审查 Task N 的代码质量"
|
|||
|
|
prompt: |
|
|||
|
|
你正在审查代码更改的生产就绪性。
|
|||
|
|
|
|||
|
|
## 实现内容
|
|||
|
|
|
|||
|
|
{Implementer 报告}
|
|||
|
|
|
|||
|
|
## 需求/计划
|
|||
|
|
|
|||
|
|
{Task description}
|
|||
|
|
|
|||
|
|
## 审查清单
|
|||
|
|
|
|||
|
|
- 代码质量:关注点分离、错误处理、类型安全、DRY
|
|||
|
|
- 架构:设计决策、可扩展性、性能、安全
|
|||
|
|
- 测试:测试真实逻辑、边界覆盖、集成测试
|
|||
|
|
- 生产就绪:向后兼容、文档、无明显bug
|
|||
|
|
|
|||
|
|
## 输出格式
|
|||
|
|
|
|||
|
|
### 优点
|
|||
|
|
[具体说明做得好的地方]
|
|||
|
|
|
|||
|
|
### 问题
|
|||
|
|
- 关键(必须修复):[Bug、安全问题]
|
|||
|
|
- 重要(应该修复):[架构问题、测试缺口]
|
|||
|
|
- 次要(可以改进):[代码风格]
|
|||
|
|
|
|||
|
|
### 评估
|
|||
|
|
可以合并?[是/否/修复后可以]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 示例工作流
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
你: 我正在使用子代理驱动开发执行此计划。
|
|||
|
|
|
|||
|
|
[调用 TaskList 获取所有任务]
|
|||
|
|
[找到第一个 pending Task]
|
|||
|
|
|
|||
|
|
Task 1: Hook 安装脚本
|
|||
|
|
|
|||
|
|
[派发 Implementer 子代理,包含完整任务 description]
|
|||
|
|
|
|||
|
|
Implementer: "开始之前 - hook 应该安装在用户级还是系统级?"
|
|||
|
|
|
|||
|
|
你: "用户级 (~/.config/vibe/hooks/)"
|
|||
|
|
|
|||
|
|
Implementer: "好的。现在开始实现..."
|
|||
|
|
[稍后] Implementer:
|
|||
|
|
- 实现了 install-hook 命令
|
|||
|
|
- 添加了测试,5/5 通过
|
|||
|
|
- 自审:发现遗漏了 --force 标志,已添加
|
|||
|
|
- 已提交
|
|||
|
|
- metadata 已更新
|
|||
|
|
|
|||
|
|
[派发 Spec Reviewer]
|
|||
|
|
Spec Reviewer: ✅ 符合规格 - 所有需求满足
|
|||
|
|
|
|||
|
|
[派发 Code Quality Reviewer]
|
|||
|
|
Code Reviewer: 优点:测试覆盖好。问题:无。通过。
|
|||
|
|
|
|||
|
|
[TaskUpdate taskId=1 status=completed]
|
|||
|
|
|
|||
|
|
Task 2: 恢复模式
|
|||
|
|
|
|||
|
|
[派发 Implementer 子代理]
|
|||
|
|
|
|||
|
|
Implementer:
|
|||
|
|
- 添加了 verify/repair 模式
|
|||
|
|
- 8/8 测试通过
|
|||
|
|
- 已提交
|
|||
|
|
|
|||
|
|
[派发 Spec Reviewer]
|
|||
|
|
Spec Reviewer: ❌ 问题:
|
|||
|
|
- 遗漏:进度报告(规格说"每 100 项报告一次")
|
|||
|
|
- 多余:添加了 --json 标志(未请求)
|
|||
|
|
|
|||
|
|
[Implementer 修复问题]
|
|||
|
|
Implementer: 移除了 --json 标志,添加了进度报告
|
|||
|
|
|
|||
|
|
[Spec Reviewer 再次审查]
|
|||
|
|
Spec Reviewer: ✅ 现在符合规格
|
|||
|
|
|
|||
|
|
[派发 Code Quality Reviewer]
|
|||
|
|
Code Reviewer: 问题(重要):魔法数字(100)
|
|||
|
|
|
|||
|
|
[Implementer 修复]
|
|||
|
|
Implementer: 提取了 PROGRESS_INTERVAL 常量
|
|||
|
|
|
|||
|
|
[Code Reviewer 再次审查]
|
|||
|
|
Code Reviewer: ✅ 通过
|
|||
|
|
|
|||
|
|
[TaskUpdate taskId=2 status=completed]
|
|||
|
|
|
|||
|
|
...
|
|||
|
|
|
|||
|
|
[所有业务 Task 完成后]
|
|||
|
|
[校验 Task 自动执行]
|
|||
|
|
[验证 design.md + metadata → 生成快照 → 标记完成]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 危险信号
|
|||
|
|
|
|||
|
|
**永远不要:**
|
|||
|
|
- 跳过审查(规格符合性或代码质量)
|
|||
|
|
- 带着未修复的问题继续
|
|||
|
|
- 并行派发多个实现子代理(冲突)
|
|||
|
|
- 让子代理读取计划文件(提供完整 description 代替)
|
|||
|
|
- 跳过 metadata 更新(校验 Task 需要这些信息)
|
|||
|
|
- 忽略子代理问题(在让他们继续之前回答)
|
|||
|
|
- 接受规格符合性的"差不多"(审查者发现问题 = 未完成)
|
|||
|
|
- **在规格符合性 ✅ 之前开始代码质量审查**(顺序错误)
|
|||
|
|
- 在任一审查有未解决问题时进入下一个任务
|
|||
|
|
|
|||
|
|
**如果子代理提问:**
|
|||
|
|
- 清晰完整地回答
|
|||
|
|
- 如需要提供额外上下文
|
|||
|
|
- 不要催他们进入实现
|
|||
|
|
|
|||
|
|
**如果审查者发现问题:**
|
|||
|
|
- Implementer(同一子代理)修复
|
|||
|
|
- 审查者再次审查
|
|||
|
|
- 重复直到通过
|
|||
|
|
- 不要跳过重新审查
|
|||
|
|
|
|||
|
|
**如果子代理任务失败:**
|
|||
|
|
- 派发修复子代理,带具体指示
|
|||
|
|
- 不要手动修复(上下文污染)
|
|||
|
|
|
|||
|
|
## 集成
|
|||
|
|
|
|||
|
|
**必需的工作流 skills:**
|
|||
|
|
- **brainstorming** - 创建设计文档(design.md)
|
|||
|
|
- **writing-plans** - 创建此 skill 执行的计划(plan.md)
|
|||
|
|
|
|||
|
|
**子代理应使用:**
|
|||
|
|
- **test-driven-development** - 子代理为每个任务遵循 TDD
|