| name | thinking |
| version | 1.4.0 |
| status | implemented |
| description | 专家推理阶段 - 模拟专家视角分析问题
谁最懂？TA会怎么说？添加安全专家、性能专家视角
第一性原理：识别基本事实，从零构建，质疑假设
ToT 强化：量化评分 + 自动回溯检测
v1.4: 新增 thinking_methods 和 thinking_mode 字段
|
| tags | ["phase","thinking","expert-reasoning","first-principles","tree-of-thoughts"] |
| requires | {"tools":["Bash","Read","Write","Grep","Glob"]} |
THINKING
Preamble
{{include: ../_shared/preamble.md}}
Overview
THINKING 阶段是 agentic-workflow 的核心推理阶段，通过模拟领域专家视角深入分析问题，并运用第一性原理从基本原则向上构建。
核心思维模式：
- 不问"你怎么看"，而是问"这个问题谁最懂？TA会怎么说？"
- 穷尽一切方案之前，禁止说"无法解决"
- 主动出击，端到端交付
- 第一性原理：从基本事实出发，质疑一切假设，从零重新构建
求是借鉴的四个动作：
- 调查研究：先拿第一手事实，再谈判断
- 矛盾分析：找主要矛盾，别被次要矛盾拖走
- 群众路线：把代码、测试、日志、历史和用户反馈汇总后再判断
- 持久战略：长期任务先判断阶段，再决定局部攻坚点
三类 THINKING 工作流与 thinking_mode：
| 工作流 | thinking_mode | thinking_methods |
|---|
| 新项目启动 | investigation_first | 调查研究, 矛盾分析, 群众路线, 持久战略 |
| 复杂问题攻坚 | contradiction_analysis | 调查研究, 矛盾分析, 集中力量, 实践认知, 批评自我批评 |
| 方案迭代优化 | mass_line_iteration | 群众路线, 矛盾分析, 实践认知, 批评自我批评 |
Entry Criteria
进入 THINKING 阶段的触发条件：
- 用户提出需要深度分析的问题
- 出现"谁最懂"、"专家"、"分析"等关键词
- 需要理解底层逻辑或顶层设计
- 涉及安全、性能等专项分析
- PUA 激励触发（失败时自动进入）
Exit Criteria
THINKING 阶段结束前必须满足：
1. 选择了 2-3 个与任务直接相关的专家角色（不是固定模板）
2. 每个专家视角有具体结论（不是泛泛 "需要注意安全"）
3. 输出了标准 THINKING Result 格式（Status + Confidence + 推荐行动）
4. 给出了调查结论、主要矛盾、阶段判断和局部攻坚点
Iron Law: NO PLANNING WITHOUT THINKING CONCLUSIONS FIRST
退出 THINKING 阶段的条件：
- 完成所有专家视角的分析（动态选择，非固定3角色）
- 得出明确的推理结论
- 识别出关键风险点和优化点
- 提供可执行的建议
Core Process
Step -1: 多路径探索 — 轻量 Tree of Thoughts（仅 M/L/XL 复杂度）
对标 Tree of Thoughts (arXiv 2305.10601)：在深度分析之前，先做一次宽度为 3 的浅层 BFS，避免过早锁定单一路径导致局部最优。
触发条件：复杂度 M/L/XL，或存在多种可行方向，或架构/技术选型类问题。
跳过条件：复杂度 XS/S，或问题方向已高度明确（无争议）。
## 多路径探索（2层轻量 BFS）
### Layer 1：3 个候选方向
**Branch A**: [一句话描述方向A]
- 核心思路：[简要说明]
- 优点：[2点]
- 主要风险：[1点]
- 可行性评分：[0-10]
**Branch B**: [一句话描述方向B]
- 核心思路：[简要说明]
- 优点：[2点]
- 主要风险：[1点]
- 可行性评分：[0-10]
**Branch C**: [一句话描述方向C — 建议来自第一性原理，忘掉现有方案从零构建]
- 核心思路：[简要说明]
- 优点：[2点]
- 主要风险：[1点]
- 可行性评分：[0-10]
### Layer 2：选择最优分支
→ **选择 Branch [X]**（评分 [N]/10，因为 [1句话理由]）
**回溯条件**：如果 Step 0 深度分析后发现 Branch X 存在致命缺陷，
立即回溯选择 Branch [Y]，不要强行继续错误路径。
量化评分标准（ToT value function，arXiv 2305.10601）：
| 维度 | 权重 | 0-10 评分标准 |
|---|
| 技术可行性 | 40% | 0=不可能, 5=需大量改造, 10=现有栈直接支撑 |
| 完整性 | 30% | 0=仅覆盖边缘, 5=覆盖核心, 10=核心+边界+异常全覆盖 |
| 风险 | 30% | 0=失败不可逆, 5=失败代价中等, 10=可快速回滚 |
加权总分计算（必须输出数值）：
Score(Branch) = 可行性×0.4 + 完整性×0.3 + 风险×0.3
选择规则：
- 最高分 Branch 进入 Step 0 深度分析
- 如两个 Branch 分差 ≤1.0，两个都保留到 Step 0 做并行分析后再选
Step -0.5: 回溯检测 (Backtrack Gate)
在 Step 0 第一性原理分析完成后，立即执行回溯检测。
如果 Step -1 选择的 Branch 在深度分析后暴露致命缺陷，必须回溯。
回溯触发条件（满足任一则回溯）：
| # | 条件 | 示例 |
|---|
| 1 | 深度分析发现不可绕过的技术约束 | 依赖库不支持目标平台 |
| 2 | 安全专家判定存在不可缓解的安全风险 | 设计上必须暴露私钥 |
| 3 | 第一性原理分析推翻了 Branch 的核心假设 | 假设的用户行为不成立 |
回溯执行流程：
IF 致命缺陷被发现:
1. 记录: "[BACKTRACK] Branch X 被放弃，原因: {一句话}"
2. 切换到 Step -1 的次优 Branch Y
3. 从 Step 0 重新开始深度分析
4. 如果 Branch Y 也失败 → 回到 Step -1 生成新 Branch D
注意: 最多回溯 2 次，超过则输出 BLOCKED 状态
Step 0: 第一性原理分析 (First Principles Thinking) [NEW]
什么时候用：复杂问题、重大决策、创新方案、方向不明确时
第一性原理核心问题：
1. 基本事实是什么？（不可辩驳的真相）
2. 假设有哪些？（需要逐一质疑）
3. 从零构建会怎样？（忘掉现有方案）
三步法：
3.1 识别基本事实 (Identify Axioms)
从用户需求中提取不可辩驳的事实：
- 用户真正想要解决的核心问题是什么？
- 技术约束是什么？（语言、平台、团队技能）
- 业务边界在哪里？（预算、时间、发布期限）
输出：基本事实清单 (Axioms List)
3.2 质疑假设 (Challenge Assumptions)
对每个隐含假设追问：
- 这个假设是真的吗？
- 如果没有这个假设会怎样？
- 这个假设在什么条件下成立？
常见被质疑的假设：
- "必须用 XX 技术栈"
- "这个库一定是最优选择"
- "用户知道他们想要什么"
- "现有架构不能改变"
3.3 从零构建 (Build from Scratch)
忘掉现有方案，从基本原则推导：
- 这个问题最简单可工作的解决方案是什么？
- 如果从零开始，我会怎么设计？
- 行业最佳实践是否适用于这个场景？
输出：从零方案 (From-Scratch Solution)
第一性原理检查清单：
- [ ] 是否识别了基本事实（Axioms）？
- [ ] 是否列出了隐含假设并逐一质疑？
- [ ] 是否尝试了从零构建？
- [ ] 最终方案是否优于从零方案？
Step 0.5: 调查研究 — 把事实先收齐
借鉴 investigation-first 的思路，在下判断前先把第一手材料集中起来：
- 读代码、测试、日志、git history
- 汇总用户反馈和当前约束
- 明确哪些是事实，哪些只是推测
输出：
## 调查结论
- 现状是：...
- 关键约束是：...
- 主要未知项是：...
- 已知可依托基础是：...
Step 0.75: 矛盾分析 — 找主要矛盾
借鉴 contradiction-analysis 的思路，把调查到的事实按冲突关系重新组织：
- 列出当前最突出的对立面
- 找出哪个矛盾最能解释其他问题
- 判断主要矛盾的主要方面
输出：
## 主要矛盾
- [A] vs [B]
- 矛盾性质：[对抗性/非对抗性]
- 最值得突破的切入点：...
Step 1.5: 群众路线 — 多源汇聚再验证
借鉴 mass-line 的方法，把分散的信息源集中起来再返回验证：
- 来源不限于用户，还包括测试、代码库、日志、历史记录
- 不要闭门造车，也不要机械照搬单一来源
- 把多个来源的意见系统化后再给出结论
输出：
## 多源反馈
- [信息源1]：...
- [信息源2]：...
- 各源之间的矛盾之处：...
- 共同指向的问题：...
Step 1.75: 持久战略 — 判断阶段与局部攻坚点
借鉴 protracted-strategy 的思路，把 THINKING 的结论转换成阶段判断：
- 判断当前是战略防御、战略相持还是战略反攻
- 识别一个最小的局部攻坚点
- 明确什么时候该进入 PLANNING / EXECUTING
输出：
## 阶段判断
- 当前阶段：...
- 局部攻坚点：...
- 转入下一阶段的条件：...
Step 1: 识别问题领域与动态选择专家角色
1. 分析问题本质，确定涉及的领域
2. 根据任务领域动态选择 2-3 个最相关的专家角色（不要固定使用全部角色）
3. 专家角色库（根据任务选择最相关的）：
- security_expert: 安全专家 — 涉及认证、加密、输入验证时
- performance_expert: 性能专家 — 涉及高并发、大数据、响应时间时
- senior_engineer: 资深工程师 — 代码质量、可维护性、重构时
- architecture_expert: 架构师 — 系统设计、模块划分、技术选型时
- dba_expert: 数据库专家 — 涉及 schema 设计、查询优化、数据迁移时
- devops_expert: 运维专家 — 涉及部署、CI/CD、容器化时
- ux_expert: 用户体验专家 — 涉及 UI/UX、可用性、交互设计时
- domain_expert: 领域专家 — 涉及特定业务逻辑（金融、医疗、电商等）时
选择原则：只选与当前任务直接相关的 2-3 个角色，不要为凑数选不相关的角色。
核心问题：
- 底层逻辑是什么？（Bottom-up 推导）
- 顶层设计在哪里？（Top-down 分解）
- 边界条件和约束是什么？
- 第一性问题：这个问题的基本事实是什么？哪些假设可以被挑战？
Step 1.5: 假设挑战追问 [NEW]
在进入专家视角分析之前，先挑战问题的基本假设：
苏格拉底式追问框架：
## 假设挑战
针对用户/问题提出的 [核心假设]，逐一追问：
### 假设识别
**用户假设**: [表述]
**挑战问题**:
1. "为什么这个假设是真的？"
2. "什么证据支持这个假设？"
3. "有没有相反的证据？"
4. "这个假设在什么条件下不成立？"
### 反面思考
**如果这个假设是错的，会怎样？**
- 影响1：[描述]
- 影响2：[描述]
### 替代假设
**可能的替代假设**:
- 假设B: [替代方案]
- 假设C: [另一种视角]
### 结论
当前假设的可信度: [高/中/低]
需要验证的关键点: [列表]
自我质疑追问：
不是问"用户怎么想"，而是问：
1. **我自己在假设什么？**
- 我假设 [X] 是真的
- 这个假设基于什么？
- 如果 X 是假的呢？
2. **我的分析框架有什么盲点？**
- 什么是我没有考虑到的？
- 什么样的证据会改变我的结论？
- 我的专业背景如何影响我的判断？
3. **我跳过了什么？**
- 什么问题太难我没有深入？
- 什么反馈我下意识忽略了？
- 什么可能性我认为是"显然"的？
第一性原理 + 假设挑战 组合：
## 组合分析框架
### 第一性问题
- 基本事实是什么？
- 不可辩驳的真相是什么？
### 假设挑战
- 我假设了什么？
- 这些假设可被挑战吗？
- 替代假设是什么？
### 从零重构
- 如果忘掉所有假设，从零开始会怎样？
- 行业最佳实践真的适用于此吗？
- 有没有完全不同的方式？
Step 2: 安全专家分析 (Security Expert)
安全专家视角分析：
1. 威胁建模
- 攻击面分析
- 信任边界划分
- 数据敏感度评估
2. 安全风险识别
- 输入验证漏洞
- 权限控制缺陷
- 加密与密钥管理问题
- 依赖项安全
3. 防御建议
- 安全编码实践
- 纵深防御策略
- 监控与告警方案
Step 3: 性能专家分析 (Performance Expert)
性能专家视角分析：
1. 性能瓶颈识别
- CPU/内存密集型操作
- I/O 阻塞点
- 网络延迟热点
- 数据库查询效率
2. 可扩展性评估
- 水平扩展 vs 垂直扩展
- 缓存策略
- 异步处理可行性
- 负载均衡需求
3. 优化建议
- 算法复杂度优化
- 资源池化
- 连接复用
- 批处理策略
Step 4: 综合推理与结论
综合多专家视角，形成最终推理：
1. 问题本质归纳
- 核心矛盾是什么
- 关键变量有哪些
2. 方案对比分析
- 各方案的优劣
- 风险与收益
3. 推荐行动方案
- 优先级排序
- 实施路径
- 验证标准
PUA 激励引擎
主动执行原则: 穷举方案是主动步骤，不是失败后的补救
穷举 3 方案结构化流程
每个分析结论必须经过 3 方案验证：
FOR EACH 关键决策/方案 IN 分析结果:
# 检查是否已穷举 3 方案
IF 方案数量 < 3 THEN
触发穷举流程:
1. **方案A (当前方案)** - 描述、优缺点、适用场景
2. **方案B (替代方案)** - 搜索业界最佳实践，开源社区方案
3. **方案C (第一性原理方案)** - 从零构建，忘掉现有方案，从基本原则重新推导
# 穷举检查清单
- [ ] 是否考虑了不同的技术栈选择？
- [ ] 是否考虑了不同的架构模式？
- [ ] 是否考虑了 BUY vs BUILD？
- [ ] 是否考虑了成本？（开发成本、运维成本）
- [ ] 是否考虑了时间？（开发时间、交付时间、响应时间）
- [ ] 是否考虑了运维复杂度？（部署难度、监控需求、故障恢复）
- [ ] 是否从第一性原理角度重新审视？（假设被质疑了吗？从零构建尝试过吗？）
输出穷举对比表:
| 维度 | 方案A | 方案B | 方案C |
|------|-------|-------|-------|
| 实现复杂度 | | | |
| 开发成本 | | | |
| 运维成本 | | | |
| 开发时间 | | | |
| 扩展性 | | | |
| 风险 | | | |
| 第一性原理验证 | | | |
END
END
先做后问清单:
BEFORE 请求用户确认:
- [ ] 已自行搜索验证
- [ ] 已读源码确认
- [ ] 已构建最小验证
THEN: 请求帮助
主动出击原则:
AFTER 完成基本分析:
- [ ] 是否考虑了端到端场景？
- [ ] 是否考虑了边界条件和异常？
- [ ] 是否考虑了监控和可观测性？
- [ ] 是否考虑了失败恢复？
- [ ] 是否考虑了安全加固？
- [ ] 是否考虑了性能优化？
AskUserQuestion Format
{{include: ../_shared/ask-user-question.md}}
Boil the Lake
{{include: ../_shared/boil-the-lake.md}}
Completion Status Protocol
THINKING 阶段的完成状态协议：
| 状态 | 含义 | 触发条件 |
|---|
| DONE | 完成 | 完成所有专家视角分析，得出明确结论 |
| DONE_WITH_CONCERNS | 带担忧完成 | 存在未解决的技术风险，但不影响整体方向 |
| BLOCKED | 阻塞 | 缺少关键上下文，无法继续推理 |
| NEEDS_CONTEXT | 需要更多信息 | 需要用户提供额外信息才能继续 |
状态转换规则
Entry: [触发 THINKING]
↓
Process:
├── Step 1: 识别问题领域 ← BLOCKED (无法确定领域)
├── Step 2: 安全专家分析
├── Step 3: 性能专家分析
└── Step 4: 综合推理
↓
Exit: [Completion Status]
├── DONE → 进入下一阶段
├── DONE_WITH_CONCERNS → 记录担忧，进入下一阶段
├── BLOCKED → 等待用户提供上下文
└── NEEDS_CONTEXT → 使用 AskUserQuestion 请求信息
输出格式
THINKING 阶段结束时，必须输出：
## THINKING Result
### 状态
- **Status**: [DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT]
- **Confidence**: [0-100%]
### 专家视角摘要
- **Security**: [安全专家结论]
- **Performance**: [性能专家结论]
- **Senior Engineer**: [工程师视角结论]
### 调查与矛盾
- **调查结论**: [已核实的事实]
- **主要矛盾**: [A vs B]
- **阶段判断**: [战略防御 / 战略相持 / 战略反攻]
- **局部攻坚点**: [最小可验证切口]
### 核心推理
[问题本质 + 关键发现]
### 推荐行动
1. [优先级 1]
2. [优先级 2]
3. [优先级 3]
### 风险与担忧（若有）
[未解决的风险或技术债务]
