name: plan-code-workflow description: “用于中等至复杂任务的计划/编码工作流。定义了何时使用计划模式与编码模式。自动应用于非简单的实现任务。” user-invocable: false
计划/编码工作流
两种主要工作模式：计划 和 编码。
任务复杂度评估
| 复杂度 | 特征 | 策略 |
|---|---|---|
| 简单 | 简单语法，单一API，<10行代码 | 直接回答 |
| 中等 | 单个文件中的非简单逻辑，局部重构 | 使用计划/编码工作流 |
| 复杂 | 跨模块设计，并发，多步骤迁移 | 必须使用计划/编码工作流 |
通用规则
- 进入计划模式时，简要重述：模式、目标、关键约束、当前状态
- 在计划模式中，必须先阅读相关代码，然后才提出修改建议
- 仅在模式切换或约束发生重大变化时重述
- 不要单方面引入超出范围的新任务
- 当用户说“实现”、“执行”、“继续”、“开始编码”时 → 立即切换到编码模式
计划模式（分析 / 对齐）
-
自上而下分析，找到根本原因，而不仅仅是修补表面症状
-
列出关键决策点和权衡
-
提供 1–3 个可行的选项，每个选项包括：
- 方法概述
- 影响范围（涉及的模块/接口）
- 优缺点
- 潜在风险
- 验证方法
-
仅在缺少信息会阻碍进展时提出澄清性问题
-
避免提供本质上相同的计划
退出条件
- 用户明确选择一个选项，或
- 某个选项明显更优（解释推理，主动选择）
一旦条件满足 → 直接进入编码模式
编码模式（执行计划）
-
主要内容必须是具体的实现，而不是继续规划
-
在提供代码之前，简要说明：
- 将修改哪些文件/模块
- 每次修改的目的
-
优先采用 最小化、可审查的更改：
- 局部代码片段/补丁优于完整文件
- 标记关键更改区域
-
说明如何验证：
- 要运行的测试/命令
- 如果需要，起草新的测试用例
-
如果发现重大问题 → 暂停，切换回计划模式
输出应包括
- 进行了哪些更改，在何处
- 如何验证
- 已知限制或后续待办事项