思考模型与策略参考

这是「GSD 全景代码解析」专题的第 34 篇。在本系列中，我们将逐层拆解 Get Shit Done (GSD) 这一 56K+ stars 的 Meta-Prompting 框架，从命令系统到工作流编排，从 Agent 设计到上下文工程，带你一览上下文驱动开发的工程全貌。

---

一、思考模型在 GSD 中的定位

在前三篇文章中，我们解析了 GSD 的上下文工程总览、上下文组装机制和参考文档体系。本章节的第四篇，我们将聚焦于一个容易被忽视但极其关键的维度——思考模型与策略参考。

GSD 的参考文档体系不仅包含技术规范（coding-standards.md、architecture-patterns.md），还包含大量元认知（Metacognition）文档——它们不直接告诉 Agent "写什么代码"，而是指导 Agent "如何思考"。这些文档构成了 GSD 的认知层基础设施。

1.1 思考模型文档全景

GSD 在 thinking/ 目录下维护了一组思考策略文档：

文档	职责	适用场景
thinking-models-*.md (5个)	定义不同推理模型的使用策略	模型选择、思考深度控制
tdd.md	测试驱动开发的策略规范	代码实现阶段的质量保障
questioning.md	问题提出与澄清策略	需求分析、缺陷排查
thinking-partner.md	AI 作为思考伙伴的协作模式	复杂决策、架构设计

这些文档共同构成了 GSD 的认知策略层（Cognitive Strategy Layer），让 Agent 不仅"能做事"，还"会思考"。

---

二、thinking-models-*.md：模型选择与思考深度控制

GSD 将思考模型文档拆分为 5 个文件，分别对应不同的认知策略维度。这种拆分遵循 GSD 的单一职责原则——每个文档只负责一种思考维度的策略定义。

2.1 五个思考模型文档的分工

flowchart TD
    subgraph TM[思考模型文档体系]
        direction TB
        TM1[thinking-models-overview.md
思考模型总览]
        TM2[thinking-models-reasoning.md
推理模型选择]
        TM3[thinking-models-creative.md
创造性任务模型]
        TM4[thinking-models-analysis.md
分析任务模型]
        TM5[thinking-models-debugging.md
调试任务模型]
    end

    TM1 --> TM2
    TM1 --> TM3
    TM1 --> TM4
    TM1 --> TM5

2.1.1 thinking-models-overview.md

总览文档定义了思考模型的分类框架和选择矩阵。核心思想是：不同认知任务需要不同类型的推理能力。

GSD 将 AI 模型按推理能力分为三个层级：

层级	代表模型	特点	适用任务
L1 - 快速响应	Claude 3.5 Sonnet, GPT-4o	低延迟、低成本、高吞吐量	代码补全、简单重构、文档生成
L2 - 平衡推理	Claude 3.5 Sonnet (Thinking), Gemini 1.5 Pro	中等延迟、良好推理	功能实现、代码审查、单元测试
L3 - 深度思考	o3, o4-mini, Gemini 2.5 Pro	高延迟、高成本、深度推理	架构设计、复杂算法、根因分析

2.1.2 thinking-models-reasoning.md

该文档聚焦于推理类模型（o3, o4-mini, Gemini 2.5 Pro）的集成策略。核心要点包括：

何时启用深度思考：

• 涉及多步骤逻辑推导的任务
• 需要权衡多个约束条件的架构决策
• 性能优化或算法选择场景
• 安全审查和合规检查

思考深度控制机制：

GSD 不简单地"用最强模型做所有事"，而是实现了自适应思考深度控制：

flowchart TD
    A[任务输入] --> B{复杂度评估}
    B -->|简单任务
确定性高| C[L1 快速模型]
    B -->|中等复杂度
需要推理| D[L2 平衡模型]
    B -->|高度复杂
不确定性高| E[L3 深度思考模型]
    C --> F[直接输出]
    D --> G[单次推理]
    E --> H{是否需要
多轮验证?}
    H -->|否| I[单轮深度推理]
    H -->|是| J[Chain-of-Thought
+ 自我验证]

思考预算管理：

深度思考模型的高成本要求严格的预算控制。GSD 的策略是：

1. 预设思考上限：每个任务分配最大思考 token 预算
2. 渐进式升级：先用 L1 尝试，失败再升级到 L2/L3
3. 思考缓存：相似任务的思考结果可复用
4. 人工介入阈值：超过预算时请求用户确认

2.1.3 thinking-models-creative.md

创造性任务（如 API 设计、UI 交互设计、命名）需要发散性思维。该文档定义了：

• 头脑风暴模式：要求模型生成多个备选方案，而非单一答案
• 约束内创新：在架构约束下寻找创造性解决方案
• 类比迁移：鼓励模型从其他领域借鉴设计模式

2.1.4 thinking-models-analysis.md

分析类任务（代码审查、性能分析、依赖分析）强调结构化思维：

• 分层分析法：从宏观架构到微观实现逐层展开
• 对比分析模板：Before vs After、方案 A vs 方案 B
• 影响面评估：变更的涟漪效应分析

2.1.5 thinking-models-debugging.md

调试任务需要假设-验证循环：

flowchart LR
    A[观察现象] --> B[提出假设]
    B --> C[设计验证]
    C --> D{验证结果}
    D -->|假设成立| E[定位根因]
    D -->|假设不成立| F[修正假设]
    F --> B
    E --> G[实施修复]
    G --> H[回归验证]

该文档特别强调了避免确认偏误——不要只验证"认为的"根因，还要主动寻找反例。

2.2 思考类模型的集成实践

GSD 在 Agent 配置中通过 model 字段指定思考模型，并通过 thinking 字段（或类似的扩展配置）控制思考行为：

---
name: gsd-architecture-advisor
description: |
  架构设计顾问，负责高层次的系统设计决策。
model: o3
thinking:
  depth: deep          # shallow / medium / deep
  budget_tokens: 8000  # 思考预算
  show_working: true   # 是否展示思考过程
allowed-tools:
  - Read
  - Grep
  - Browser
---

关键设计决策：

1. 模型与任务匹配：Planner 和 Architect 使用 L3 模型，Executor 使用 L2，简单工具调用使用 L1
2. 思考过程透明化：show_working: true 让 Agent 的思考过程可见，便于审查和调试
3. 思考结果持久化：复杂推理的中间结论写入 reasoning/ 目录，供后续 Agent 复用

---

三、tdd.md：测试驱动开发的 GSD 实践

TDD（Test-Driven Development）在 GSD 中不是"可选项"，而是默认工作模式。tdd.md 文档将 TDD 原则转化为 AI Agent 可执行的具体策略。

3.1 TDD 在 GSD 中的核心地位

GSD 的工作流设计体现了"测试先行"的哲学：

flowchart TD
    subgraph TDD[TDD 工作流]
        direction TB
        A[需求/规格] --> B[编写测试]
        B --> C{测试编译?}
        C -->|否| D[创建桩代码]
        D --> B
        C -->|是| E[运行测试
预期失败]
        E --> F[实现功能]
        F --> G[运行测试
预期通过]
        G --> H{全部通过?}
        H -->|否| I[调试修复]
        I --> G
        H -->|是| J[重构优化]
        J --> K[回归测试]
    end

3.2 TDD 策略的三个层次

tdd.md 将 TDD 实践分为三个层次，对应不同的自动化程度：

3.2.1 L1 - 单元测试先行（Unit-First）

最基础的 TDD 实践，要求 Agent 在实现每个函数/方法之前先编写单元测试：

规范要求：

• 每个 public 函数必须有对应的测试用例
• 边界条件必须覆盖（空值、极值、异常输入）
• 测试命名遵循 should_xxx_when_yyy 格式
• 使用 Given-When-Then 结构组织测试代码

Agent 执行模板：

## TDD 执行清单

对于每个待实现的功能点：

1. [ ] 阅读规格说明，提取验收标准
2. [ ] 编写失败测试（Red）
3. [ ] 运行测试确认失败原因符合预期
4. [ ] 编写最小实现使测试通过（Green）
5. [ ] 检查是否有重构机会（Refactor）
6. [ ] 重复步骤 2-5 直到功能完整

3.2.2 L2 - 集成测试驱动（Integration-Driven）

针对模块间协作的 TDD 实践。Agent 在编写单元测试之前，先定义模块间的契约测试：

• API 契约测试：验证接口输入输出符合 OpenAPI/GraphQL Schema
• 事件契约测试：验证消息队列的事件格式和顺序
• 数据库契约测试：验证迁移脚本与实体定义的一致性

3.2.3 L3 - 验收测试驱动（ATDD/BDD）

最高层次的 TDD，从用户故事出发编写验收测试：

flowchart LR
    A[用户故事] --> B[验收标准]
    B --> C[自动化验收测试]
    C --> D[实现功能]
    D --> E[验收测试通过]
    E --> F[交付]

GSD 的 gsd-verifier Agent 在验证阶段会检查：

• 验收测试是否覆盖所有用户故事
• 单元测试是否覆盖所有代码路径
• 集成测试是否验证所有外部依赖

3.3 TDD 与 AI Agent 的特殊考量

AI Agent 执行 TDD 时有几个特殊挑战，tdd.md 文档给出了针对性策略：

挑战 1：Agent 可能"看到"实现后写测试

解决方案：强制隔离。要求 Agent 在读取实现文件之前先完成测试编写，或通过工作流强制分离"测试编写阶段"和"实现阶段"。

挑战 2：Agent 编写的测试质量不稳定

解决方案：测试审查机制。引入 gsd-test-reviewer Agent 专门审查测试用例的完整性和有效性。

挑战 3：TDD 的"小步快跑"与 Agent 的"批量生成"冲突

解决方案：迭代式 TDD。不要求严格的"一个测试一个实现"，而是允许 Agent 在理解需求后批量生成测试套件，再批量实现。

---

四、questioning.md：问题提出与澄清策略

questioning.md 是 GSD 中最体现 Meta-Prompting 思想的文档之一。它不教 Agent 如何回答，而是教 Agent 如何提问。

4.1 为什么 AI Agent 需要学会提问

传统观念认为 AI 应该"有问必答"，但 GSD 的实践表明：一个好的问题比一个好的答案更有价值。

• 模糊需求是软件项目失败的首要原因
• 过早优化源于对问题域理解不清
• 过度工程来自假设了不存在的约束

questioning.md 的目标是：在 Agent 投入大量计算资源之前，先通过提问澄清问题的本质。

4.2 问题提出策略框架

flowchart TD
    A[接收任务/需求] --> B{信息是否完整?}
    B -->|是| C[直接执行]
    B -->|否| D[分类缺失信息]
    D --> E[目标澄清]
    D --> F[约束澄清]
    D --> G[上下文澄清]
    D --> H[验收标准澄清]
    E --> I[生成澄清问题]
    F --> I
    G --> I
    H --> I
    I --> J[向用户/上级 Agent 提问]
    J --> K[更新 Context]
    K --> B

4.2.1 目标澄清（Goal Clarification）

确保理解"为什么要做"，而不仅是"做什么"：

• "这个功能的最终用户是谁？"
• "解决的核心痛点是什么？"
• "成功的衡量标准是什么？"
• "不做这个功能会有什么后果？"

4.2.2 约束澄清（Constraint Clarification）

识别显性和隐性约束：

• "有性能指标要求吗？（QPS、延迟、内存）"
• "是否需要向后兼容？"
• "技术栈是否有限制？"
• "时间/资源预算的上限是多少？"

4.2.3 上下文澄清（Context Clarification）

了解任务在更大图景中的位置：

• "这个功能依赖哪些尚未完成的部分？"
• "是否有相关的历史决策需要了解？"
• "团队是否有相关的编码规范或架构原则？"

4.2.4 验收标准澄清（Acceptance Criteria Clarification）

明确"完成"的定义：

• "需要哪些测试覆盖？"
• "需要更新文档吗？"
• "需要代码审查吗？谁来审查？"
• "部署/发布流程是什么？"

4.3 澄清问题的艺术

questioning.md 不仅提供了问题清单，还定义了提问的元规则：

规则 1：先假设，后验证

不要问"该怎么做？"，而是问"我的理解对吗？"

❌ "这个 API 应该怎么设计？"
✅ "我计划将 API 设计为 RESTful 风格，使用 JWT 认证，这个方向对吗？"

规则 2：提供选项，而非开放问题

开放问题容易得到模糊回答，选项式提问能加速决策：

❌ "用什么数据库？"
✅ "考虑到读写比例和数据一致性要求，我倾向于 A) PostgreSQL B) MongoDB C) Redis + 持久化存储。您的建议是？"

规则 3：一次一问，串行澄清

避免一次性抛出 10 个问题让用户 overwhelmed。GSD 建议采用迭代式澄清：

sequenceDiagram
    participant A as Agent
    participant U as 用户/上级 Agent

    A->>U: 问题 1：关于目标
    U->>A: 回答 1
    A->>U: 问题 2：关于约束（基于回答 1）
    U->>A: 回答 2
    A->>U: 问题 3：关于验收标准
    U->>A: 回答 3
    A->>A: 综合所有信息，形成执行计划

规则 4：记录澄清结果

所有澄清问答必须记录到 clarifications.md 或更新到 STATE.md，防止信息在 Agent 间传递时丢失。

---

五、thinking-partner.md：AI 作为思考伙伴

thinking-partner.md 是 GSD 中最具哲学深度的文档。它定义了一种新的协作范式：不是把人当作 AI 的监工，也不是把 AI 当作人的工具，而是让 AI 成为人的思考伙伴。

5.1 从"工具"到"伙伴"的范式转换

flowchart LR
    subgraph Old[传统范式]
        direction TB
        O1[人：思考者] --> O2[AI：执行者]
    end

    subgraph New[GSD 范式]
        direction TB
        N1[人：决策者
方向把控] --- N2[AI：思考伙伴
逻辑推演]
        N2 --- N3[共同产出
最优解]
        N1 --- N3
    end

    Old -->|进化| New

5.2 人机协作的思考模式

thinking-partner.md 定义了三种人机协作思考模式：

5.2.1 模式一：苏格拉底式追问（Socratic Inquiry）

AI 通过连续追问帮助人深入思考问题本质：

• "你为什么会这样假设？"
• "这个方案的反面是什么？"
• "如果去掉这个约束，会怎样？"
• "一年后回头看，这个决策还重要吗？"

适用场景：架构决策、技术选型、优先级排序

5.2.2 模式二：并行探索（Parallel Exploration）

人和 AI 分别独立探索解决方案，然后交叉验证：

flowchart TD
    A[问题定义] --> B[人：方案 A]
    A --> C[AI：方案 B]
    B --> D[方案对比]
    C --> D
    D --> E[联合评审]
    E --> F[融合最优解]

适用场景：算法设计、性能优化、复杂 Bug 排查

5.2.3 模式三：认知外包（Cognitive Offloading）

将低层次认知任务外包给 AI，人专注于高层次决策：

认知层级	人的职责	AI 的职责
战略层	目标设定、价值判断	信息收集、趋势分析
战术层	方案选择、风险评估	方案生成、影响分析
执行层	关键节点审核	详细实现、测试验证

适用场景：日常开发、代码审查、文档编写

5.3 思考伙伴的角色边界

thinking-partner.md 明确界定了 AI 思考伙伴的能力边界：

AI 擅长：

• 逻辑推演和模式识别
• 大规模信息检索和综合
• 多方案对比和量化分析
• 无偏见的假设检验

AI 不擅长（需要人介入）：

• 价值判断（"这个值得做吗？"）
• 情境感知（"团队目前能承受这个变更吗？"）
• 长期后果预测（"这个设计决策三年后的影响？"）
• 创造性突破（"有没有完全不一样的思路？"）

5.4 实践建议

文档最后给出了一组实践建议：

1. 明确思考目标：开始对话前，先定义"我们今天要解决什么思考难题？"
2. 分阶段思考：复杂问题拆分为"理解→分析→综合→决策"四个阶段
3. 显式化思维过程：要求 AI 展示推理链条，而非只给结论
4. 保留怀疑权：对 AI 的每个结论保持健康的怀疑，主动寻找反例
5. 记录思考轨迹：将高质量的思维过程保存为团队知识资产

---

六、思考模型文档的协同效应

单独看每个思考模型文档都有价值，但 GSD 的真正力量在于它们的协同效应：

flowchart TD
    subgraph CL[认知层]
        direction TB
        Q[questioning.md
澄清问题]
        TM[thinking-models-*.md
选择思考方式]
        TP[thinking-partner.md
协作思考]
        TDD[tdd.md
验证思考]
    end

    Q --> TM
    TM --> TP
    TP --> TDD
    TDD --> Q

    style Q fill:#e1f5fe
    style TM fill:#e8f5e9
    style TP fill:#fff3e0
    style TDD fill:#fce4ec

协同工作流示例：

1. 需求阶段：questioning.md 指导 Agent 澄清模糊需求
2. 设计阶段：thinking-models-reasoning.md 选择深度思考模型进行架构设计，thinking-partner.md 启用苏格拉底式追问
3. 实现阶段：tdd.md 驱动测试先行的编码过程，thinking-models-debugging.md 指导问题排查
4. 审查阶段：thinking-models-analysis.md 结构化代码审查思维

---

七、小结

本文解析了 GSD 认知策略层的四大核心文档：

1. thinking-models-*.md：通过五级文档实现模型选择与思考深度的精细控制，让"合适的模型做合适的事"
2. tdd.md：将 TDD 从人工实践转化为 Agent 可执行的标准工作流，分 L1/L2/L3 三个层次适配不同场景
3. questioning.md：定义了问题澄清的策略框架和提问元规则，让 Agent 学会"在行动前思考"
4. thinking-partner.md：提出 AI 作为思考伙伴的协作范式，定义了苏格拉底式追问、并行探索、认知外包三种模式

这些文档的共同特点是：它们不直接产出代码，而是塑造 Agent 的"认知习惯"。在 GSD 的架构中，这种元认知能力比任何具体技能都更重要——因为它决定了 Agent 如何面对未知、如何处理模糊、如何在信息不完整时做出合理决策。

正如 thinking-partner.md 开篇所言："最好的 AI 编程助手不是知道最多答案的那个，而是最懂得与你一起提出好问题的那个。"

---

下一篇预告： 第 35 篇《Git 集成与提交规范》——解析 GSD 中 Git 工作流的自动化策略、提交信息规范、分支管理策略以及与 CI/CD 的集成实践。