范式选型决策树

前面讲了"是什么、为什么"，本章解决"我这会儿到底该用哪个"。给你一棵能顺着走下来的决策树和几张速配表。

一、主决策树：从"要不要用"开始

你要做的事：
│
├─ 一次性脚本 / 玩具 Demo / 黑客松？
│    └─ 是 → 直接 Vibe Coding，别加流程（过度工程是反模式）
│
└─ 要长期维护 / 多人协作 / 进生产？
     │
     ├─ 是全新项目（绿地）
     │    └─ 企业级、需合规、要治理 → Spec Kit
     │       快速出原型、小团队      → Kiro
     │
     └─ 改存量系统（棕地）/ 高风险模块（认证、金额、权限）
          └─ OpenSpec（变更隔离、可审计、不破坏老代码）

走到这里，你已经选完了规划层。接下来叠验证与执行：

规格定了之后：
│
├─ 涉及正确性 / 边界 / 回归？  → 叠加 TDD（把验收标准变成测试）
├─ 多代理 / 长流程协作？        → 叠加 Claude Team + superpowers workflow
├─ 代理总拿错信息 / 越聊越蠢？  → 叠加 上下文工程（写 AGENTS.md / Rules / Skills）
└─ 想让 AI 长时间稳定自动执行？ → 叠加 Harness Engineering（先建安全闸门）

二、单点问题速配表

不确定自己卡在哪？按症状直接对号入座：

你遇到的症状	大概率病因	先查这章
项目越改越乱、改 A 坏 B	缺规格，边界漂移	SDD
说不清"这次到底做成啥算完"	验收标准没显式化	SDD
AI 代码看着对，一跑就错	没有可执行约束兜底	TDD
测试全绿但功能是空的	测试造假	组合实战·坑1
AI 老忘我之前定的规矩	约束没入库 / 上下文被淹	上下文工程
多轮对话后 AI 明显变笨	上下文污染	上下文工程
不知道该先想还是先写	缺流程	协作与工作流
不敢给 AI 自动执行权限	缺安全闸门	执行工装工程

三、按"任务体量"选重量

一个实用判断：返工成本 vs 沟通成本。

任务体量	建议组合	大致开销
改几行 / 一次性	纯 Vibe	几乎零
单功能、单人	轻量 spec + TDD	小
中大型、多人	SDD(Spec Kit) + TDD + 上下文工程	中
存量高风险	SDD(OpenSpec) + TDD + Harness	较大
自动化研发体系	全套 + Harness	最大

💡 原则：能用轻的用轻。流程是为质量服务的，不是仪式——给 20 行改动开一整套 spec→plan→tasks 就是反模式（见最佳实践）。

四、团队成熟度路线图

如果要带团队一步步升级，建议按这条路径走，每步都在补上一步的短板：

第1级  规范 AGENTS.md          让约定入库（哪怕没有别的）
   ↓
第2级  引入 TDD                给 AI 产出加一道客观验证
   ↓
第3级  上 SDD（选一个框架）     把"最易返工的决定"前置说清
   ↓
第4级  上下文工程               让代理在长流程里不迷路
   ↓
第5级  superpowers 工作流       把 planning→review 固化
   ↓
第6级  Harness Engineering      搭闭环执行 + 安全闸门（最后、最难）

不要一步跳到第 6 级——Harness 建设成本最高，前面几级没铺好时它跑不稳。

五、三剑客快速回看

选规划层框架时，一张表回忆要点（详见 SDD）：

框架	气质	一句话选型
Spec Kit	治理、组织化	要合规、多人、标准化 → 选它
OpenSpec	安全、可审计	改老代码、控风险 → 选它
Kiro	快、自动化	做原型、小团队 → 选它

六、本章小结

• 先判"要不要加流程"，再按绿地/棕地选规划层，最后按需叠验证 / 协作 / 上下文 / 环境。
• 症状对号入座比死记概念更快；能轻则轻。
• 团队升级走成熟度路线图，别一步到位上 Harness。

七、下一步

• 选完范式后挑工具：AI 编码工具链选型；组织层推广：团队落地与治理
• 落地"上下文/规则"具体文件：落地构件
• 一页速查全书：快速参考卡片