PLAN MODE 技能

触发条件

当用户使用 /plan 命令时，必须进入 PLAN MODE。

核心原则

第一产出永远是计划，不是代码。

在用户明确批准前，禁止：

• 写最终实现代码
• 修改文件
• 执行命令
• 做任何破坏性操作

工作流

收到 /plan 请求后，按以下顺序输出：

一、任务理解

简洁说明：

• 用户要解决什么问题
• 预期交付物
• 成功标准
• 已知约束
• 仍不明确的点

二、当前上下文

分析可见信息：

• 相关模块/文件/目录
• 依赖项与配置
• 接口或数据流
• 现有实现模式
• 可能受影响的逻辑
• 潜在风险点

三、缺失信息 / 关键假设

• 列出缺少但影响判断的信息
• 列出已采用的默认假设
• 仅在必要时提出最多 3 个关键问题

四、实施计划

给出 3-8 步计划。每步说明：

• 做什么
• 为什么
• 影响哪里
• 预期产出

五、影响范围

列出涉及：

• 文件、模块、配置
• 接口、数据结构
• 测试、文档

六、风险点

指出：

• 最易出错处
• 可能回归点
• 兼容性/性能/安全/维护成本风险
• 是否有更小范围替代方案

七、验证方案

说明如何确认成功：

• 功能验证
• 测试策略
• 边界场景
• 回归检查
• 用户可见行为变化

八、待确认事项

只列真正影响实施路径的决策点，并给出推荐方案。

九、停止并等待批准

输出计划后必须停止。

只有收到以下批准语句后才进入执行阶段：

• "执行"
• "开始实现"
• "按这个计划做"
• "approved"
• "go"

输出格式模板

## 任务理解
...

## 当前上下文
...

## 缺失信息 / 关键假设
...

## 实施计划
1. ...
2. ...
3. ...

## 影响范围
- ...

## 风险点
- ...

## 验证方案
- ...

## 待确认事项
- ...

## 下一步
等待用户批准后再执行。

执行切换规则

用户批准后切换到 EXECUTION MODE：

1. 严格按批准计划实施
2. 发现重大偏离时先暂停说明
3. 小调整可说明后继续
4. 持续同步进展，不重复整份计划

信息不足时

优先基于现有上下文做合理假设并明确写出。只有在确实影响方案选择时，才提出少量关键问题。