tursom
f8f330c054
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
229 lines
6.2 KiB
Markdown
229 lines
6.2 KiB
Markdown
# Plan Mode 工作流
|
||
|
||
> 先计划、后执行。每次非平凡任务必须经过 P → R → A → E 四阶段闭环。
|
||
> 建立日期：2026-05-09
|
||
|
||
---
|
||
|
||
## 1. 触发方式
|
||
|
||
### 方式 A — 显式触发
|
||
|
||
```
|
||
ulw plan <需求描述>
|
||
```
|
||
|
||
### 方式 B — 隐式触发
|
||
|
||
以下条件任一满足时自动进入 Plan Mode：
|
||
- 涉及 2+ 个文件的改动
|
||
- 涉及架构决策
|
||
- 涉及跨服务修改
|
||
- 涉及新的业务流程
|
||
|
||
---
|
||
|
||
## 2. 四阶段工作流
|
||
|
||
```
|
||
P 阶段 (Plan) ──→ R 阶段 (Review) ──→ A 阶段 (Approve) ──→ E 阶段 (Execute)
|
||
│ │ │ │
|
||
│ 我出计划 │ 你审反馈 │ 你签字审批 │ 我执行
|
||
│ 结构化文档 │ 逐条过 │ 无遗留问题 │ 按计划推进
|
||
└───────────────────┴────────────────────┴────────────────────┴──────────
|
||
```
|
||
|
||
---
|
||
|
||
## 3. P 阶段：计划制定
|
||
|
||
### 3.1 产出物
|
||
|
||
计划文档，写入 `.sisyphus/plans/{task-name}.md`，包含 6 个章节：
|
||
|
||
| 章节 | 内容 |
|
||
|------|------|
|
||
| 1. 需求理解 | 我对需求的重新表述 + 待确认疑问 |
|
||
| 2. 范围界定 | In Scope / Out of Scope 清单 |
|
||
| 3. 技术方案 | 架构决策、修改文件、技术路线 |
|
||
| 4. 任务分解 | 按 Wave（并行批次）拆分的任务列表，每任务含：文件、改动描述、依赖 |
|
||
| 5. 风险点 | 潜在风险、回滚方案、需要关注的点 |
|
||
| 6. 验证计划 | 如何验证每个改动正确 |
|
||
|
||
### 3.2 内部流程
|
||
|
||
```
|
||
P0: 需求澄清（如有歧义 → 提问）
|
||
P1: 探索代码库（explore agent 并行搜索相关代码、模式、依赖）
|
||
P2: 复杂架构 → 咨询 Oracle（技术方案评审）
|
||
P3: 撰写计划文档（上述 6 个章节）
|
||
P4: 输出给用户审核
|
||
```
|
||
|
||
### 3.3 执行完成标准（通用门禁）
|
||
|
||
```
|
||
- [ ] 所有任务标记完成
|
||
- [ ] 项目构建通过（按项目实际工具：go build / npm run build / cargo build / 等）
|
||
- [ ] 项目测试通过（按项目实际工具：go test / npm test / pytest / 等）
|
||
- [ ] LSP 诊断无新增错误
|
||
- [ ] 改动的代码通过了手动验证（见验证计划各条）
|
||
```
|
||
|
||
---
|
||
|
||
### 3.4 计划文档模板
|
||
|
||
```markdown
|
||
# Plan: {任务名称}
|
||
|
||
## 1. 需求理解
|
||
{我对需求的重新表述}
|
||
|
||
## 2. 范围界定
|
||
### In Scope
|
||
- {list}
|
||
### Out of Scope
|
||
- {list}
|
||
|
||
## 3. 技术方案
|
||
{架构图/决策说明/文件清单}
|
||
|
||
## 4. 任务分解
|
||
|
||
| Wave | Task ID | 描述 | 文件 | 依赖 | 预期产出 |
|
||
|------|---------|------|------|------|----------|
|
||
| 1 | T1 | ... | ... | 无 | ... |
|
||
| 1 | T2 | ... | ... | 无 | ... |
|
||
| 2 | T3 | ... | ... | T1,T2 | ... |
|
||
|
||
## 5. 风险点
|
||
| 风险 | 概率 | 影响 | 缓解措施 |
|
||
|------|------|------|----------|
|
||
| ... | 高/中/低 | ... | ... |
|
||
|
||
## 6. 验证计划
|
||
| 验证项 | 方法（按项目实际工具填写） | 预期结果 |
|
||
|--------|---------------------------|----------|
|
||
| 编译 | {go build / npm run build / cargo build / ...} | exit 0 |
|
||
| 单元测试 | {go test / npm test / pytest / ...} | 全部通过 |
|
||
| Lint/类型检查 | {golangci-lint / tsc / mypy / ...} | 无新增问题 |
|
||
| 手动验证 | {按功能描述执行的操作步骤} | 符合预期 |
|
||
```
|
||
|
||
---
|
||
|
||
## 4. R 阶段：审核反馈
|
||
|
||
### 角色分工
|
||
|
||
- **你**：逐章节审阅计划，给出修改意见，指出遗漏，调整优先级
|
||
- **我**：根据反馈更新计划文档，对每条反馈回应（接受/解释/替代方案），方案重大变更则重新咨询 Oracle
|
||
|
||
### 你说话的格式
|
||
|
||
```
|
||
plan 反馈：
|
||
1. [章节名] 第X条：建议改为...
|
||
2. [风险] 漏掉了YY场景
|
||
3. [任务分解] Wave 2 应该先于 Wave 1
|
||
```
|
||
|
||
### 我回应的格式
|
||
|
||
```
|
||
计划更新 v2：
|
||
[章节] 已修改：...
|
||
[章节] 已采纳反馈：...
|
||
[章节] 关于第X点，我的考虑是... 是否保持原方案？
|
||
```
|
||
|
||
### 轮次
|
||
|
||
不限，直至你满意。
|
||
|
||
---
|
||
|
||
## 5. A 阶段：审批通过
|
||
|
||
### 触发词
|
||
|
||
你说以下之一即表示审批通过：
|
||
|
||
```
|
||
plan 通过
|
||
审核通过
|
||
批准执行
|
||
Plan Approved
|
||
```
|
||
|
||
### 审批门禁（前置条件）
|
||
|
||
- [ ] 所有疑问已澄清
|
||
- [ ] 需求理解无误
|
||
- [ ] 技术方案没有明显漏洞
|
||
- [ ] 任务分解完整（没有遗漏步骤）
|
||
- [ ] 验证计划合理
|
||
|
||
审批后，计划文档进入**锁定状态**。执行阶段严格按计划推进。
|
||
|
||
---
|
||
|
||
## 6. E 阶段：执行
|
||
|
||
### 执行原则
|
||
|
||
1. 严格按照任务分解的 **Wave 顺序** 执行
|
||
2. 每个 Wave 内任务**并行**执行
|
||
3. 每个任务完成后：`lsp_diagnostics` + 验证步骤
|
||
4. 每完成一个 Wave：运行一次 build + test
|
||
5. 每完成一个 Wave：向你更新进度
|
||
|
||
### 执行偏差处理
|
||
|
||
| 情况 | 处理方式 |
|
||
|------|----------|
|
||
| 执行中发现计划遗漏 | 暂停 → 报告偏差 → 等你决策 |
|
||
| 执行中遇到计划错误的假设 | 暂停 → 分析根因 → 提交方案变更请求 |
|
||
| 执行中发现更好方案 | 暂停 → 说明理由 → 等你决定是否改用新方案 |
|
||
| 执行一切顺利 | 继续推进，直到全部完成 |
|
||
|
||
### 变更请求格式
|
||
|
||
```
|
||
变更请求 #1：
|
||
- 原计划：[Wave X, Task Y]
|
||
- 发现的问题：[具体问题]
|
||
- 建议修改为：[新方案]
|
||
- 理由：[为什么不按原计划]
|
||
- 影响：[对其他任务的影响]
|
||
请确认是否批准此变更。
|
||
```
|
||
|
||
---
|
||
|
||
## 7. Plan Mode 与直接执行模式的选择
|
||
|
||
| 维度 | 直接执行 | Plan Mode |
|
||
|------|----------|-----------|
|
||
| 开始前 | 直接开始编码 | 先出计划文档 |
|
||
| 用户参与 | 执行中提反馈 | 计划阶段先审核 |
|
||
| 变更处理 | 随时改 | 正式变更请求 |
|
||
| 范围控制 | 容易 scope creep | 严格按计划执行 |
|
||
| 风险把控 | 走一步看一步 | 提前识别风险 |
|
||
| 适用场景 | 1 个文件的简单修改 | 2+ 文件、新功能、架构变更 |
|
||
|
||
---
|
||
|
||
## 8. 执行完成标准（通用）
|
||
|
||
所有执行任务完成后，必须逐条验证：
|
||
|
||
- [ ] 所有任务标记完成
|
||
- [ ] 项目构建通过（按项目实际工具填写命令）
|
||
- [ ] 项目测试通过（按项目实际工具填写命令）
|
||
- [ ] LSP 诊断无新增错误
|
||
- [ ] 改动的代码通过了手动验证（见验证计划各条）
|
||
|
||
**以上门禁全部通过才算任务完成。**
|