Appearance
范式全景图：一张地图看懂所有理念
新手最大的困惑不是"某个理念太难"，而是"这些理念到底是同一类东西吗？谁替代谁？"。本章把它们放回同一张工程地图。
一、先把名词"翻译成人话"
很多文章一上来就丢缩写，很容易掉队。我们先把这些名字逐个翻译一遍：
| 名称 | 全称 / 来源 | 更容易理解的说法 | 一句话解释 |
|---|---|---|---|
| Vibe Coding | 社区流行说法 | 凭感觉和 AI 一来一回把东西做出来 | 先做出来再说，适合原型，不适合复杂系统 |
| TDD | Test-Driven Development | 先写测试，再写实现 | 用测试反向约束代码行为 |
| SDD | Spec-Driven Development | 先把需求 / 边界 / 验收标准写成规格，再驱动开发 | 规格驱动，"按图纸施工" |
| OpenSpec | 社区开源框架 | 轻量规格驱动框架 | 把 spec 直接放进代码仓库管理 |
| Spec Kit | GitHub 开源工具箱 | 规格驱动工具链 | 把 spec、plan、tasks 串成可执行流程 |
| Claude Team | 对 Anthropic 案例的归纳 | 团队级人机协作范式 | 把 AI 当协作参与者，而不是补全插件 |
| superpowers | obra/superpowers 项目 | 给代理配一整套开发超能力 | 用固定 workflow 串起 planning、subagent、TDD、review |
| Context Engineering | 社区 / GitHub 官方用法 | 给 AI 组织上下文的方法论 | 不是给更多信息，而是给更相关的信息 |
| Harness Engineering | OpenAI 提法 | 面向代理的执行环境工程 | 给代理搭一套能运行、验证、修复、回归的闭环环境 |
⚠️ 术语提醒：
SDD在社区里一词多义。默认指 Spec-Driven Development（规格驱动）；但在 superpowers 这类工作流里，SDD也可能指 Subagent-Driven Development（子代理分工）。本教程默认把前者写作 SDD，后者会明确写全，避免混淆。
二、关键认知：它们不在同一层级
很多争论吵不清楚，是因为大家在拿不同层级的东西互相比较。它们大多不是互斥关系，而是分层组合关系。
把它们按"解决什么问题"分成四层：
text
┌─ 探索层 ────────────────────────────┐
│ Vibe Coding（先做出来） │
└──────────────┬──────────────────────┘
↓
┌─ 规格与规划层 ──────────────────────┐
│ SDD · OpenSpec · Spec Kit │ ← 定义"要做什么"
└──────────────┬──────────────────────┘
↓
┌─ 执行与协作层 ──────────────────────┐
│ TDD · Claude Team · superpowers │ ← 保证"怎么做对、怎么协作"
└──────────────┬──────────────────────┘
↓
┌─ 上下文与环境层 ────────────────────┐
│ Context Engineering · Harness │ ← 保证"拿对信息、稳定闭环执行"
└─────────────────────────────────────┘三、一张总览表：每个理念在回答什么问题
| 名称 | 它主要回答的问题 | 所在层次 | 最适合的场景 | 主要短板 |
|---|---|---|---|---|
| Vibe Coding | 能不能先做出来？ | 探索层 | Demo、原型、探索 | 容易失控 |
| TDD | 代码行为是否正确？ | 验证层 | 模块实现、回归保护 | 不擅长定义系统意图 |
| SDD | 我们到底要构建什么？ | 规格层 | 中大型功能、多人协作 | 容易被做重 |
| OpenSpec | 怎么把规格落到仓库里？ | 规划层 | 存量项目、持续迭代 | 需持续维护 |
| Spec Kit | 怎么把规格驱动变成工具链？ | 流程层 | 团队级落地 | 上手成本更高 |
| Claude Team | 怎么让 AI 真正融入团队？ | 协作层 | 跨角色协同、复杂推进 | 依赖团队习惯 |
| superpowers | 怎么把 planning 到 review 串成 workflow？ | 执行层 | 想把 AI 工作流模板化的团队 | 对纪律要求高 |
| Context Engineering | 怎么让代理一直拿到正确上下文？ | 上下文层 | 长流程、多轮、多代理协作 | 做不好会污染上下文 |
| Harness Engineering | 怎么让代理稳定闭环执行？ | 环境层 | 长时任务、自动化研发体系 | 建设成本最高 |
四、一条"补位链"：为什么需要一整套
这些理念不是让你从中"选一个"，而是每一个都在补前一个的短板：
text
Vibe Coding 太快 → 需要 SDD 把意图讲清楚
SDD 太抽象 → 需要 OpenSpec / Spec Kit 把规格落地入库
规格写了还不够 → 需要 TDD 把行为变成可执行约束
写完测试还不够 → 需要 Claude Team / superpowers 协作推进
协作还不够 → 需要 Context Engineering 保证拿对上下文
上下文还不够 → 需要 Harness Engineering 搭完整执行闭环成熟团队通常组合使用，而不是只选一个。这正是 组合落地实战 一章要展开的内容。
五、新手最易误解的三点
- "是不是文档越多越规范？" —— 否。好的规格是轻量、结构化、入库的，只沉淀最容易返工的决定，而不是写几十页没人看的文档。
- "AI 来了 TDD 是不是过时了？" —— 恰恰相反，AI 越强，TDD 越重要（详见 TDD）。
- "这些是不是互相竞争、要选一个？" —— 大多不是。它们处在不同层级，是组合拳。
六、本章小结
- 这些理念分处探索 / 规格 / 执行 / 环境四层，不是同一类东西，别横向硬比。
- 它们是一条补位链：后一个补前一个的短板。
- 记住 SDD 的一词多义，读其他资料时先确认它指"规格驱动"还是"子代理驱动"。