Files

tursom f8f330c054 update

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>

2026-05-11 12:16:17 +08:00

6.2 KiB

Raw Blame History

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 计划文档模板

# 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 阶段：执行

执行原则

严格按照任务分解的 Wave 顺序 执行
每个 Wave 内任务并行执行
每个任务完成后：lsp_diagnostics + 验证步骤
每完成一个 Wave：运行一次 build + test
每完成一个 Wave：向你更新进度

执行偏差处理

情况	处理方式
执行中发现计划遗漏	暂停 → 报告偏差 → 等你决策
执行中遇到计划错误的假设	暂停 → 分析根因 → 提交方案变更请求
执行中发现更好方案	暂停 → 说明理由 → 等你决定是否改用新方案
执行一切顺利	继续推进，直到全部完成

变更请求格式

变更请求 #1：
- 原计划：[Wave X, Task Y]
- 发现的问题：[具体问题]
- 建议修改为：[新方案]
- 理由：[为什么不按原计划]
- 影响：[对其他任务的影响]
请确认是否批准此变更。

7. Plan Mode 与直接执行模式的选择

维度	直接执行	Plan Mode
开始前	直接开始编码	先出计划文档
用户参与	执行中提反馈	计划阶段先审核
变更处理	随时改	正式变更请求
范围控制	容易 scope creep	严格按计划执行
风险把控	走一步看一步	提前识别风险
适用场景	1 个文件的简单修改	2+ 文件、新功能、架构变更

8. 执行完成标准（通用）

所有执行任务完成后，必须逐条验证：

所有任务标记完成
项目构建通过（按项目实际工具填写命令）
项目测试通过（按项目实际工具填写命令）
LSP 诊断无新增错误
改动的代码通过了手动验证（见验证计划各条）

以上门禁全部通过才算任务完成。

6.2 KiB Raw Blame History Unescape Escape