4.0 KiB
4.0 KiB
方案审核阶段 Prompt 模板
目标
每个子代理审核其他两个方案,发现问题、提出改进建议,最终达成综合方案。
交叉审核矩阵
┌─────────────┬───────────────┬───────────────┬───────────────┐
│ 审核者 │ 审核方案A │ 审核方案B │ 审核方案C │
├─────────────┼───────────────┼───────────────┼───────────────┤
│ Agent A │ — │ ✓ │ ✓ │
│ Agent B │ ✓ │ — │ ✓ │
│ Agent C │ ✓ │ ✓ │ — │
└─────────────┴───────────────┴───────────────┴───────────────┘
审核子代理 Prompt
你是一个代码审核专家。请审核以下两个技术方案,并提供专业的评审意见。
## 原始需求
{requirements_summary}
## 待审核方案
### 方案 1
{solution_1_content}
### 方案 2
{solution_2_content}
## 审核维度
请从以下维度进行审核:
### 1. 完整性
- 是否覆盖了所有需求?
- 有没有遗漏的功能点?
- 边界条件是否考虑周全?
### 2. 可行性
- 技术方案是否可行?
- 有没有技术风险?
- 依赖是否稳定可靠?
### 3. 可维护性
- 代码结构是否清晰?
- 是否易于理解和修改?
- 是否有足够的文档?
### 4. 性能
- 是否满足性能要求?
- 有没有性能瓶颈?
- 是否有优化空间?
### 5. 安全性
- 是否有安全风险?
- 敏感数据如何处理?
- 权限控制是否完善?
## 输出格式
```markdown
# 方案审核报告
## 审核: [方案1名称] vs [方案2名称]
### 方案1 评审
#### 优点
1. [优点1]
2. [优点2]
#### 缺点
1. [缺点1]
2. [缺点2]
#### 改进建议
1. [建议1]
2. [建议2]
#### 评分 (1-10)
- 完整性:
- 可行性:
- 可维护性:
- 性能:
- 安全性:
- **总分**:
---
### 方案2 评审
[同上结构]
---
## 对比结论
### 更推荐哪个方案?
[选择] 及原因
### 两个方案可以融合的点
1. [融合点1]
2. [融合点2]
### 需要额外关注的风险
1. [风险1]
请客观、专业地进行审核。
## 审核结果收集
每个审核子代理输出保存到:
- `.planning/dev-workflow/reviews/review-A.md` (A审核BC)
- `.planning/dev-workflow/reviews/review-B.md` (B审核AC)
- `.planning/dev-workflow/reviews/review-C.md` (C审核AB)
## 综合方案生成
主代理收集所有审核意见后,生成综合方案:
你是一个技术决策者。请基于以下信息,生成一个综合最佳方案。
原始需求
{requirements_summary}
三个初始方案
{all_solutions}
三份审核意见
{all_reviews}
任务
- 分析每个方案的优缺点
- 提取各方案的亮点
- 融合成一个综合方案
- 确保综合方案覆盖所有需求
- 说明融合决策的理由
输出格式
# 综合技术方案
## 方案概述
[综合方案的核心思路]
## 融合决策
| 决策点 | 选择来源 | 理由 |
|--------|---------|------|
| [决策1] | 方案A | [为什么选A] |
| [决策2] | 方案B | [为什么选B] |
## 技术选型
[最终确定的技术栈]
## 架构设计
[综合后的架构]
## 核心模块
[综合后的模块设计]
## 文件结构
[最终的文件结构]
## 开发计划
[开发步骤]
## 风险与应对
[识别的风险和应对策略]
## 为什么这个方案最好
[总结综合方案的优势]
请做出明智的决策,生成最优方案。
## 状态更新
```json
{
"phases": {
"3": {
"status": "completed",
"data": {
"reviews": ["review-A.md", "review-B.md", "review-C.md"],
"final_solution": "final-solution.md"
}
}
}
}