thinking

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]

### 风险与担忧（若有）
[未解决的风险或技术债务]