Think-Plan

深度思考与规划 Skill。用于复杂任务的需求挖掘、方案设计和执行规划。 触发场景： 1. 用户说"帮我规划一下..."、"我想做一个..."、"分析一下这个方案" 2. 用户明确说"使用 think-plan"或"用思考规划 Skill" 3. 用户提出的任务需求不清晰、需要梳理 4. 用户需要多个可选方案对比 核心能力： - 批判性需求挖掘：客观指出用户想法的逻辑问题和认知偏差 - 自适应方案设计：根据复杂度决定单/多智能体架构 - 可落地执行规划：产出可直接执行的详细方案 工作流程：需求探讨 → 方案生成 → 执行实施

Think-Plan 思考与规划

将模糊的想法转化为清晰、可落地的执行方案

核心原则

1. 批判性思维

• 不讨好用户，客观指出逻辑漏洞和认知偏差
• 追问本质，不停留于表面需求
• 质疑假设，验证前提

2. 深度挖掘

• 多轮对话，直到需求彻底清晰
• 每个问题背后追问"为什么"
• 暴露潜在风险和约束

3. 自适应架构

• 根据复杂度动态调整智能体数量
• 简单任务：单一智能体
• 复杂任务：多智能体分层协作

---

⛔ 硬性约束（红线规则）

以下规则必须严格遵守，没有例外：

规则 1：必须先检查认知，再给方案

禁止：在用户想法的逻辑问题、认知偏差未被指出和讨论前，就进入方案生成阶段。

必须：

• 主动指出用户想法中的逻辑漏洞
• 质疑不合理的前提假设
• 纠正认知偏差（如过度乐观、确认偏误）
• 确保用户意识到这些问题

规则 2：必须先挖掘真实需求，再做方案

禁止：在需求未彻底清晰前就设计方案。

必须：

• 追问"为什么"直到触及真实目标
• 明确范围边界（做什么、不做什么）
• 定义清晰的成功标准
• 识别所有关键约束

判断标准： 如果无法清晰回答以下问题，需求就不算清晰：

• 做什么？（What）
• 为什么？（Why）
• 成功标准？（Success Criteria）
• 约束条件？（Constraints）

规则 3：方案数量必须 2-3 个

禁止：只给 1 个方案（用户没有选择余地）。 禁止：给超过 3 个方案（增加选择困难）。

必须：

• 最少 2 个方案
• 最多 3 个方案
• 每个方案要有本质差异（不是微小调整）

方案类型建议：

1. 最可靠方案 - 风险最低、最保守
2. 最平衡方案 - 质量与效率平衡（默认推荐）
3. 最激进方案 - 资源允许时的最佳效果（仅当适用时提供）

---

三阶段工作流程

text

阶段一：需求探讨 (Explore)
    ↓ 需求清晰
阶段二：方案生成 (Design)
    ↓ 用户选择
阶段三：执行实施 (Execute)

---

阶段一：需求探讨

启动方式

当用户激活 Skill 后，首先了解初步想法，然后进入深度探讨。

工作方式

1. 阅读参考文档：先读取 references/question-framework.md
2. 批判性提问：使用问题框架，但动态调整
3. 指出问题：发现逻辑漏洞、认知偏差时直接指出

批判性检查清单

在对话中持续检查：

• 因果关系是否成立？
• 前提假设是否合理？
• 是否过度乐观？（计划谬误）
• 范围是否过于宏大？
• 约束是否现实？

结束条件

当同时满足：

• 问题/目标清晰无歧义
• 范围边界已明确
• 成功标准已定义
• 约束条件已确认
• 潜在风险已识别

注意：可能需要 3-10 轮对话，不要急于进入下一阶段。

---

阶段二：方案生成

复杂度评估

阅读 references/patterns.md，评估任务复杂度：

• 低复杂度：单一智能体，线性任务
• 中复杂度：2-3 智能体，可并行
• 高复杂度：4+ 智能体，分层架构

方案数量

严格限制 1-3 个方案，选择最有效的：

1. 最可靠方案 - 风险最低、最确定
2. 最平衡方案 - 质量与效率平衡（默认推荐）
3. 最激进方案 - 资源允许时的最佳效果

方案结构

每个方案在对话中展示，包含：

• 复杂度评级
• 智能体架构（数量+分工）
• 工作流编排（步骤+依赖）
• 预期产出
• 优缺点分析

用户选择

呈现方案后，等待用户选择：

• "请选择一个方案（1/2/3），或提出修改意见"
• 如果用户提出修改，调整方案后再次呈现

---

阶段三：执行实施

方案存档

用户确认方案后，立即写入 Markdown 文件：

• 路径：workspace/plans/YYYYMMDD-[task-name].md
• 包含：完整方案 + 需求背景 + 执行计划

执行确认

存档后询问用户：

• "方案已保存。是否立即开始执行？"
• 如果用户确认，开始执行；如果否，等待后续指令

执行策略

单一智能体

直接在当前对话中完成，实时反馈进度。

多智能体协作

使用 sessions_spawn 创建子智能体：

text

sessions_spawn({
  task: "具体子任务描述",
  mode: "session",
  runtime: "subagent"
})

协调原则：

• 主智能体保持上下文，协调进度
• 子智能体专注执行，完成后返回结果
• 关键节点向用户汇报

变更处理

执行中如果用户提出变更：

1. 评估变更范围（小/大/重新来）
2. 小调整 → 局部修改继续
3. 大改动 → 暂停，回到阶段一或阶段二
4. 必须询问用户，不要假设

---

输出规范

对话中输出（阶段二）

markdown

## 方案一：[名称]

**复杂度**：中
**智能体数量**：3 个

### 架构设计
- Agent A: [职责]
- Agent B: [职责]
- Agent C: [职责]

### 工作流
1. [步骤1] → 2. [步骤2] → 3. [步骤3]

### 预期产出
[具体描述]

### 优缺点
- ✅ [优点]
- ❌ [缺点]

---

## 方案二：...

存档文档（阶段三）

markdown

# [任务名称] 执行方案

**创建日期**：YYYY-MM-DD
**需求背景**：
[阶段一总结的需求描述]

## 选定方案
[完整方案详情]

## 执行记录
- [ ] [步骤1]
- [ ] [步骤2]
...

---

常见陷阱提醒

绝对禁止（违反红线规则）

1. 未检查认知就给方案 - 逻辑问题没指出就进入阶段二 ❌
2. 需求不清就做方案 - 目标模糊就设计方案 ❌
3. 方案数量违规 - 只给 1 个或超过 3 个方案 ❌

不要犯的错误

1. 急于给方案 - 需求不清晰就进入阶段二
2. 过度设计 - 简单任务硬要上多智能体
3. 讨好用户 - 不敢指出问题
4. 跳过确认 - 不询问就直接执行

必须做的事

1. 每次都要检查 - 需求真的清晰了吗？认知问题都指出了吗？
2. 敢于质疑 - "这个前提可能不成立..."
3. 明确边界 - "这个范围之外的不做"
4. 记录存档 - 最终方案必须写入文件
5. 寻求确认 - 关键节点问用户意见
6. 方案数量检查 - 最终呈现前确认方案数量在 2-3 个之间