AI Coding 正在重写软件工程：从 Vibe Coding 到 Harness EngineeringAI Cod

AI Coding 正在重写软件工程：从 Vibe Coding 到 Harness Engineering

一篇看懂 Vibe Coding、TDD、SDD、OpenSpec、Spec Kit、Claude Team、superpowers、Context Engineering、Harness Engineering 之间关系的全景文章。

先说结论

过去的软件工程，核心问题是“如何把代码写出来并写正确”；
今天的 AI Coding，核心问题已经慢慢变成了：

如何把需求讲清楚
如何把上下文组织好
如何把验证闭环搭起来
如何让代理在正确的环境里持续稳定地产出

这也是为什么最近一年，开发圈突然冒出很多“有名字的方法论”：

Vibe Coding
TDD
SDD
OpenSpec
Spec Kit
Claude Team
superpowers
Context Engineering
Harness Engineering

很多人第一次看到这些词，会有一种混乱感：它们都像是在讨论 AI 编程，但又不像同一类东西。

这篇文章的目标，就是把这几个名字放到一张工程地图里，讲清楚：

它们分别解决什么问题
它们处在开发流程的哪一层
它们彼此之间到底是替代关系，还是组合关系
一个团队真正落地 AI Coding 时，应该如何把它们串起来

说明：这篇文章只讨论“命名开发范式 / 工作流”，不展开 Prompt、MCP、Skills、Rule 这些基础构件。它们更像积木，不是本文要讨论的方法论品牌。

术语提醒：SDD 在社区里经常一词多义。本文默认把 SDD 写作 Spec-Driven Development；如果特指多个子代理分工执行，我会写成 Subagent-Driven Development，避免混淆。

零、先把这些名字翻译成人话

很多文章一上来就直接丢缩写，读者如果不是天天泡在 AI Coding 圈里，很容易第一段就掉队。
所以在进入正文之前，我们先把这些名字逐个“翻译成人话”。

一张表看懂这些名词

名称	全称 / 来源	直译	更容易理解的中文说法	一句话解释
`Vibe Coding`	社区流行说法	氛围式编程 / 感觉流编程	凭感觉和 AI 一来一回把东西做出来	先做出来再说，适合原型，不适合复杂系统
`TDD`	`Test-Driven Development`	测试驱动开发	先写测试，再写实现	用测试反向约束代码行为
`SDD`	`Spec-Driven Development`	规格驱动开发	也常被通俗写成“规范驱动开发”	先把需求、边界、验收标准写成 spec，再驱动后续开发
`OpenSpec`	社区开源框架名	开放规格	轻量级规格驱动框架	把 spec 直接放进代码仓库里管理
`Spec Kit`	GitHub 开源工具箱	规格工具箱	规格驱动开发工具链	把 spec、plan、tasks 串成一条可执行流程
`Claude Team`	本文的归纳说法	Claude 团队式协作	团队级人机协作范式	把 AI 当成团队协作中的参与者，而不是补全插件
`superpowers`	`obra/superpowers` 项目名	超能力	给 AI 代理配一整套开发超能力	用固定 workflow 把 planning、subagent、TDD、review 串起来
`Context Engineering`	社区 / GitHub 官方文章用法	上下文工程	给 AI 组织上下文的方法论	不是给更多信息，而是给更相关的信息
`Harness Engineering`	OpenAI 提法	Harness 可译作工装 / 执行框架 / 试验台	面向代理的执行环境工程	给代理搭一套能运行、验证、修复、回归的闭环环境

几个最容易误解的词

1. `Spec` 到底是什么意思？

Spec 是 Specification 的缩写。
在软件工程里，它不是“随手写两句说明”，而是对需求、边界、约束、验收标准的结构化表达。

所以 SDD 更准确的翻译，其实是：

规格驱动开发

但在中文技术社区里，很多人也会把它说成：

规范驱动开发

这两种翻法都有人用。
如果追求准确，规格驱动开发 更贴近英文原意；
如果面向大众表达，规范驱动开发 更容易让人一下子理解它强调“先把标准写清楚”。

2. `Harness` 为什么这么难翻？

Harness 在英文里本义是“马具、安全带、束具”，核心含义是“把东西套住、固定住、控制起来”。
在软件工程语境里，它经常出现在：

test harness
evaluation harness
agent harness

所以 Harness Engineering 如果硬翻，会很别扭。
更容易理解的方式是把它解释成：

为代理搭建执行工装
为代理搭建验证与回路环境
为代理设计可运行、可观测、可修复的执行框架

它强调的重点不是“写 prompt”，而是“搭环境”。

3. `Claude Team` 是不是一个官方固定术语？

严格说，不是。
它更像我在这篇文章里对 Anthropic 官方案例的一种归纳命名，用来指代“团队级地使用 Claude / Claude Code 进行协作”的那种范式。

也就是说，TDD、SDD 这类词是相对经典的方法论名词；
而 Claude Team 更接近一种“可被识别的人机协作风格”。

4. `superpowers` 为什么叫这个名字？

它字面意思就是“超能力”。
这个项目想表达的是：不是只给 AI 一个聊天框，而是给它一整套可复用的软件开发超能力，比如：

brainstorming
计划编写
子代理分工
TDD
code review
branch finish

所以它叫 superpowers，本质上是在表达“给代理装上完整开发能力包”。

一、为什么 AI Coding 时代突然出现这么多“有名字的方法论”？

因为 AI 编程已经不再只是“让模型补几行代码”。

早期大家谈 AI Coding，重点通常是：

哪个模型更强
哪个提示词更准
哪个 IDE 更顺手

但一旦 AI 真正进入真实项目，问题马上会升级：

为什么模型写出来的第一版总是“看着像对的，但细节不对”？
为什么小 Demo 很顺，但一进大仓库就开始飘？
为什么多人协作、多轮会话、跨模块改造时，AI 表现明显下降？
为什么 AI 很擅长生成代码，却不擅长持续稳定地把任务做完？

答案是：代码生成本身，只是整个工程闭环里最便宜的一步。

真正昂贵、也真正决定交付质量的，是下面这些事情：

意图是否被正确定义
需求是否被结构化沉淀
测试是否能形成约束
上下文是否足够且相关
工具是否接得正确
代理是否有验证与回退机制

也正因为这样，AI Coding 的讨论重点，开始从“模型是否聪明”转向“系统是否可靠”。
而这些新范式，本质上就是对这个问题的不同回答。

图 1：AI Coding 范式总览

flowchart LR
    A[Vibe Coding<br/>先做出来] --> B[TDD<br/>先定义行为]
    B --> C[SDD<br/>先定义规格]
    C --> D[OpenSpec / Spec Kit<br/>规格入库]
    D --> E[Claude Team<br/>人机协作推进]
    E --> F[superpowers<br/>流程固化]
    F --> G[Context Engineering<br/>精准上下文]
    G --> H[Harness Engineering<br/>闭环执行环境]

这张图不是严格的时间线，也不是替代链，而是一条“工程成熟度升级线”：

从“先做出来”
到“先验证”
到“先定义意图”
到“把意图沉淀为资产”
到“把 AI 纳入团队协作”
到“把工作流和执行环境一起工程化”

二、这些名字其实不在一个层级上

很多争论之所以吵不清楚，是因为大家在拿不同层级的东西互相比较。

比如：

TDD 更偏验证方法
SDD 更偏规格方法
OpenSpec 和 Spec Kit 更偏规格落地框架
Claude Team 更偏团队协作范式
superpowers 更偏执行工作流
Context Engineering 更偏上下文组织方法
Harness Engineering 更偏代理执行环境设计

图 2：这些范式分别处在哪一层

flowchart TB
    subgraph L1[探索层]
        V[Vibe Coding]
    end

    subgraph L2[规格与规划层]
        SDD[SDD]
        OS[OpenSpec]
        SK[Spec Kit]
    end

    subgraph L3[执行与协作层]
        TDD[TDD]
        CT[Claude Team]
        SP[superpowers]
    end

    subgraph L4[上下文与环境层]
        CE[Context Engineering]
        HE[Harness Engineering]
    end

    V --> SDD
    SDD --> OS
    SDD --> SK
    OS --> TDD
    SK --> TDD
    TDD --> CT
    CT --> SP
    SP --> CE
    CE --> HE

一旦把层级放对，这些名字之间的关系就清楚了：

它们大多不是互斥的
真正成熟的团队，通常不会只选一个
它们更像“不同层的组合拳”

三、Vibe Coding：最快的起点，也是最容易失控的起点

先解释名字。
Vibe 这个词本意是“氛围、感觉、 vibe”。放到编程语境里，Vibe Coding 指的不是一套严谨的方法学，而是一种社区流行的开发姿势：你先凭感觉把需求丢给 AI，在一来一回的对话里把产品“怼出来”。它强调的是流畅感、速度感和即时反馈，而不是前期规划的严密性。

也正因为它特别符合很多人第一次接触 AI Coding 的体验，Vibe Coding 才会这么快火起来。

你给 AI 一句话：

帮我做一个待办清单应用，带搜索、筛选和本地存储。

几分钟后，它真的给你做出来了。
页面能跑、交互也像回事、甚至还有一点动画。那种“像魔法一样”的体验，就是 Vibe Coding 最迷人的地方。

GitHub 在 2025 年 9 月 2 日介绍 Spec Kit 的文章里，专门把 Vibe Coding 拿出来做对照：它非常适合快速原型，但一旦走进严肃项目和存量代码库，就容易暴露问题。

`Vibe Coding` 的优点

启动快，几乎没有门槛
适合验证点子、做 Demo、做原型
对非专业开发者尤其友好
能快速形成第一版可讨论对象

`Vibe Coding` 的问题

需求边界容易漂移
隐含假设往往没有被显式写出来
代码结构可能“看起来完整”，其实缺少长期演化能力
一旦进入复杂项目，很容易出现局部修得快、整体越来越乱

它适合什么，不适合什么？

适合：

活动页
原型验证
黑客松
低风险内部工具

不适合：

长期维护的中大型业务系统
高耦合存量项目
合规、权限、金额、风控等高风险模块

一句话总结：

Vibe Coding 很适合探索，但不适合直接承担复杂系统的长期演化。

插图建议

可配一张“半小时做出 Demo”的工作台图
左侧是自然语言需求，右侧是快速生成的页面和代码
风格建议：轻快、明亮、强调“灵感瞬间变成产品”

四、TDD：AI 时代最被低估、却重新变得更重要的方法

先解释名字。
TDD 是 Test-Driven Development 的缩写，中文就是 测试驱动开发。这里最关键的不是“有测试”，而是“驱动”这两个字: 测试不是代码写完以后补上去的附件，而是反过来驱动实现设计的起点。

很多人以为 AI 来了以后，TDD 会过时。
恰恰相反，AI 越强，TDD 的价值越大。

原因很简单：

大模型擅长“补全”
工程系统需要“验证”

传统 TDD 的核心流程是：

先写失败测试
再写实现让测试通过
最后重构

也就是经典的 Red -> Green -> Refactor。

在 AI Coding 时代，这套方法多了一层非常关键的意义：

它把模糊的人类需求，变成了 AI 必须通过的可执行约束。

为什么 TDD 在 AI Coding 里更重要？

因为你跟模型说：

“做个登录功能”，它会写代码
“先写测试，覆盖密码错误、账号锁定、Remember Me、会话过期、多端冲突”，它才会被拉回工程现实

换句话说，TDD 的价值从“提升开发纪律”，升级成了“给 AI 定义行为边界”。

图 3：TDD 在 AI Coding 中的作用

flowchart LR
    A[自然语言需求] --> B[测试用例]
    B --> C[代码实现]
    C --> D[自动验证]
    D --> E[重构与回归]

TDD 的价值

行为先于实现
可以显著降低“AI 乱扩展功能”的概率
适合接入 lint、typecheck、unit test、integration test
特别适合和自动修复循环配合

TDD 的边界

但 TDD 也不是万能的。

它非常擅长回答：

这个函数应该返回什么
这个模块在什么输入下应该如何工作

但它不擅长回答：

我们为什么要这样设计系统
这个需求边界到底是什么
多个模块之间的职责如何划分

所以，TDD 非常重要，但它更像验证层，不是规划层。
这就引出了 SDD。

五、SDD：AI 时代真正该先写的，往往不是代码，而是规格

先解释名字。
SDD 是 Spec-Driven Development 的缩写，更准确的翻译是 规格驱动开发，在中文社区里也常被通俗说成 规范驱动开发。这里的 Spec 不是泛泛的“说明文档”，而是对需求目标、业务边界、异常流程、验收标准、技术约束的一种结构化描述。

如果用一句更接地气的话解释，SDD 的意思就是：先把事情写清楚，再让 AI 和代码围着这份“写清楚的东西”去执行。

SDD 是 AI Coding 时代非常核心的一条主线。

如果说 TDD 关注的是“代码行为是否正确”，
那 SDD 关注的是“我们到底要构建什么”。

这听起来像一句很抽象的话，但在真实项目里，它非常具体：

需求边界是什么？
这次变更影响哪些模块？
哪些是必须做，哪些是这次不做？
验收标准是什么？
出错边界和异常流程是什么？

在没有 SDD 的情况下，这些东西往往散落在：

聊天记录
脑海记忆
Jira 描述
会议纪要
PR 评论

这正是 AI Coding 在复杂项目里最容易出问题的地方。
因为对代理来说，看不见，就等于不存在。

`SDD` 解决的核心问题

让需求不再只存在于对话里
让规格成为仓库里的资产
让多人、多轮、多代理都能共享同一份意图
让代码、测试、文档围绕同一份规格演化

`SDD` 的本质

一句话概括就是：

先定义意图，再让代码围绕意图生长。

如果你想把它说得更像面向大众读者的一句话，也可以写成：

SDD（Spec-Driven Development），也就是规格驱动开发或通俗所说的规范驱动开发，是 AI 原生时代一种非常重要的新开发范式。它不再默认“先写代码、边写边想”，而是要求团队先把需求、边界、约束和验收标准沉淀成 spec，再让实现、测试和 review 围绕 spec 展开。

常见误区

很多团队一听到“规格驱动”，马上会想到厚厚的文档、瀑布流程、低效率审批。
这恰恰是 AI 时代最应该避免的误解。

今天的 SDD，真正好的形态不是“文档越多越好”，而是：

轻量
结构化
和代码库一起版本化
能被人读，也能被代理读

这也正是 OpenSpec 和 Spec Kit 变得重要的原因。

六、OpenSpec：把 SDD 变成仓库里的轻量规划层

先解释名字。
OpenSpec 可以拆成两个词来理解：

Open：开放、轻量、工具无关
Spec：规格、规范、需求约束

所以它不是某个单一 AI 工具，而更像一个 开放的规格驱动框架。它想做的事情是：把原本散落在聊天、文档、脑海里的 spec，变成代码仓库里的正式资产。

OpenSpec 是最近 AI Coding 社区里最有代表性的轻量 SDD 实践之一。

OpenSpec 官网上最有代表性的几句主张是：

Review intent, not just code
Specs live in your code
轻量、迭代、面向真实代码库

它不是让你写一份又大又全的文档，而是让你在每次变更发生时，留下几类非常具体、非常有用的中间产物：

proposal.md：为什么要改
design.md：准备怎么改
tasks.md：拆成哪些执行步骤
spec delta：相对旧系统，这次需求到底变了什么

图 4：OpenSpec 的核心产物

flowchart LR
    A[新需求 / 新变更] --> B[proposal.md<br/>为什么改]
    A --> C[design.md<br/>怎么改]
    A --> D[tasks.md<br/>拆解任务]
    A --> E[spec delta<br/>需求变化]
    B --> F[代码实现]
    C --> F
    D --> F
    E --> F

OpenSpec 为什么适合 AI Coding？

因为它把一次模糊聊天，变成了一组结构化中间产物。
而这正是代理最需要的东西。

对人来说，它降低了审阅成本。
对 AI 来说，它降低了理解成本。

你不再只是说：

帮我加一个登录记住我功能。

而是把意图拆成：

为什么这个功能要做
哪些页面和服务会受影响
哪些异常场景必须覆盖
拆成哪几步执行最安全

这类上下文一旦入库，就能跨会话、跨成员、跨工具复用。

OpenSpec 更适合谁？

有存量项目的团队
经常做跨模块改造的团队
想让 AI 参与真实生产而不是只做玩具 Demo 的团队

七、Spec Kit：GitHub 把规格驱动开发做成了一整套工具箱

先解释名字。
Spec Kit 直译就是 规格工具箱。这个名字其实很形象：它不是单一文档模板，也不是一个只能聊天的 AI 产品，而是一套围绕 spec 组织起来的工具和流程集合。

如果说 OpenSpec 更像一个轻量框架，
那么 Spec Kit 更像 GitHub 对 SDD 的系统化表达。

GitHub 在 2025 年 9 月 2 日公开介绍 Spec Kit 时，强调的是一件事：

让团队从随机的 prompt 式开发，走向稳定的 spec 驱动开发。

Spec Kit 特别强调几个关键词：

Intent-driven development
Multi-step refinement
Brownfield modernization
from vibe-coding to AI-native development

这说明它的目标不是“帮你多写点文档”，而是把规格驱动开发变成一条可执行、可重复、可组织化的链路。

`Spec Kit` 关注的流程

先写出目标和意图
再沉淀为规格
再生成 plan
再拆成 tasks
再交给代理执行

OpenSpec 和 Spec Kit 的区别

维度	OpenSpec	Spec Kit
定位	轻量 spec-driven framework	GitHub 风格的 spec-driven toolkit
气质	简洁、通用、工具无关	流程更完整、组织化更强
适用	想低成本开始 spec 化	想把 spec 驱动变成团队级工作方式
强项	轻、快、好上手	流程完整、适合系统化落地

简单说：

OpenSpec 更像轻量实践
Spec Kit 更像成体系工具链

它们不是谁替代谁，而是同一条 SDD 主线上的两个典型代表。

八、Claude Team：当 AI 不再只是工具，而开始像团队成员

先解释名字。
Claude Team 不是一个像 TDD 那样定义非常严格的经典术语，它更像一种归纳说法。这里的重点不在 Claude 这个模型名字本身，而在 Team 这个词：AI 不再只是某个工程师私人的补全工具，而开始进入团队分工、协作、评审和推进流程。

Claude Team 不是一个像 TDD 那样定义非常严格的经典术语。
这篇文章里，我用它来概括 Anthropic 在 2025 年 7 月 24 日展示出来的那种典型工作方式：

把 AI 真正纳入团队协作，而不是只把它当成一个补全插件。

Anthropic 官方案例里有几个特别值得注意的信号：

不只是工程师在用，设计、法务、市场、数据团队也在用
很多任务不是“直接开干”，而是先 brainstorming，再进入实现
复杂问题强调 step-by-step，而不是 one-shot
AI 不只是写代码，还在推进完整流程

这说明了什么？

说明 AI Coding 的重点，已经从“我让模型写一段代码”，慢慢变成了：

如何让 AI 参与问题定义
如何让 AI 参与方案整理
如何让 AI 参与执行推进
如何让不同角色共享同一套产物

图 5：Claude Team 式的人机协作

flowchart LR
    A[人类定义目标] --> B[AI 协助澄清与整理]
    B --> C[AI 推进实现与验证]
    C --> D[人类审查与判断]
    D --> E[继续迭代]

Claude Team 范式的核心

人负责方向、边界、判断、验收
AI 负责探索、生成、整理、执行、首轮验证
团队共享的不再只是对话，而是沉淀下来的流程资产

这不是“AI 替代团队”，而是“AI 成为团队工作流的一部分”。

九、superpowers：把 brainstorming、计划、子代理、TDD、Review 串成强制工作流

先解释名字。
superpowers 字面意思就是 超能力。这个项目之所以取这个名字，是因为它想表达的不是“再多一个 prompt 模板”，而是“给 AI 代理整套可复用的软件开发超能力”。

superpowers 是近一年很值得关注的一个名字。

obra/superpowers 仓库把自己定义为：

an agentic skills framework & software development methodology that works

它最有意思的地方在于，它不是只给你一堆零散技巧，而是把一条完整的软件开发链路固化成了默认 workflow。

根据仓库 README，它的核心链路大致如下：

brainstorming
using-git-worktrees
writing-plans
subagent-driven-development 或 executing-plans
test-driven-development
requesting-code-review
finishing-a-development-branch

图 6：superpowers 的核心 workflow

flowchart LR
    A[brainstorming] --> B[using-git-worktrees]
    B --> C[writing-plans]
    C --> D[subagent-driven-development]
    D --> E[test-driven-development]
    E --> F[requesting-code-review]
    F --> G[finishing-a-development-branch]

为什么 `superpowers` 值得单独讲？

因为它解决的不是“AI 会不会写”，而是：

什么时候先想
什么时候拆计划
什么时候并行给子代理
什么时候跑 TDD
什么时候必须 review
什么时候才算真正结束

它把 AI Coding 从“临场发挥”变成了“流程驱动”。

它适合什么团队？

已经明确想把 AI 纳入标准开发流程的团队
需要多人、多代理并行推进的团队
希望把 planning、review、收尾都模板化的团队

十、Context Engineering：AI Coding 真正的分水岭，不是更会写 Prompt，而是更会给上下文

先解释名字。
Context Engineering 直译就是 上下文工程。这个名字的重点在 Engineering，也就是它不是一个小技巧，而是一门需要系统设计的方法: 你要决定给代理什么信息、不给什么信息、在哪个阶段给、用什么结构给、如何持续维护这些上下文资产。

很多人提到 AI Coding，第一反应还是 Prompt Engineering。
但到了 2025 年下半年，越来越多团队把关注点转向了 Context Engineering。

GitHub 在 2025 年 10 月 13 日的文章里，把这件事讲得非常清楚：

问题不是给 AI 更多信息，而是让 AI 始终聚焦于正确的信息。

这句话听起来很朴素，但它其实是 AI Coding 从“偶尔有奇效”走向“稳定可复用”的关键分水岭。

`Context Engineering` 在做什么？

给代理正确而不是过量的上下文
避免无关信息污染会话
把经验沉淀成可复用的 context 资产
让不同阶段只拿到该阶段真正需要的信息

常见失败场景

很多团队以为模型不够强，其实真正的问题是：

它拿错了文件
它没看到关键设计约束
它被无关信息挤满了上下文窗口
它沿着一次错误理解持续扩写

图 7：错误上下文 vs 正确上下文

flowchart LR
    A[海量无关信息] --> B[上下文污染]
    B --> C[代理偏航]

    D[相关 spec / 约束 / 目标文件] --> E[聚焦上下文]
    E --> F[稳定执行]

它的本质是什么？

一句话：

让代理把注意力放在对的地方，而不是让它看更多东西。

这也是为什么今天很多高质量 AI Coding 团队，会特别重视：

仓库中的结构化规范
会话切分
文件选择
上下文压缩
任务分层
记忆与知识沉淀

十一、Harness Engineering：代理时代真正的工程，开始于环境设计

先解释名字。
Harness Engineering 里最难理解的是 Harness。如果按字面翻译，它接近“马具、束具、安全带、工装”这类东西，核心含义都是“把系统套起来、接起来、控制起来”。放到软件工程里，它更接近“执行框架”或“验证工装”的意思。

所以 Harness Engineering 不是在说“怎么写更强的提示词”，而是在说：怎么给代理搭一整套可运行、可观测、可验证、可修复的执行环境。

如果说前面的范式主要在解决：

怎么想清楚
怎么协作
怎么组织上下文

那么 Harness Engineering 解决的是最后、也最难的一公里：

代理怎样才能稳定、可靠、长时间地把事情做完？

OpenAI 在 2026 年 2 月 11 日公开提出 Harness Engineering，并用一句话概括其核心：

Humans steer. Agents execute.

这背后代表的是一套非常重要的新工程观：

人不再手写每一行代码
人开始更多地设计环境、指定意图、建立反馈回路
代理不只写代码，还能启动应用、观察日志、读取指标、验证修复、回应 review、继续迭代

Harness Engineering 的几个关键点

让应用对代理可读
日志、页面、trace、指标、测试结果，都要让代理看得见。
让仓库成为 system of record
知识不能散落在聊天、Wiki、脑海中。对代理来说，仓库里没有，就等于没有。
把 review、test、validation 编码进系统
不是让 AI 写完就停，而是让它在验证系统里反复修正。
让约束比指令更重要
通过 lint、结构测试、taste invariants 等机制约束代理，而不是只靠大段提示词。

图 8：Harness Engineering 的闭环

flowchart LR
    A[目标与约束] --> B[代理执行]
    B --> C[运行应用 / 读日志 / 看测试]
    C --> D[自动修复与再验证]
    D --> E[通过后进入审查]

它为什么重要？

因为一旦 harness 搭好，代理就不再只是聊天窗口里的助手，
而会逐渐变成一个能在真实工程环境里持续执行任务的系统角色。

这也是 AI Coding 未来最重要的升级方向之一。

十二、把 9 个名字放在一起看：它们分别在回答什么问题？

名称	它主要回答的问题	所在层次	最适合的场景	主要短板
`Vibe Coding`	能不能先做出来？	原型层	Demo、原型、探索	容易失控
`TDD`	代码行为是否正确？	验证层	模块实现、回归保护	不擅长定义系统意图
`SDD`	我们到底要构建什么？	规格层	中大型功能、多人协作	容易被做重
`OpenSpec`	怎么把规格落到仓库里？	规划层	存量项目、持续迭代	需要持续维护
`Spec Kit`	怎么把规格驱动变成工具链？	流程层	团队级落地	上手成本更高
`Claude Team`	怎么让 AI 真正融入团队？	协作层	跨角色协同、复杂推进	依赖团队习惯
`superpowers`	怎么把 planning 到 review 串成 workflow？	执行层	想把 AI 工作流模板化的团队	对纪律要求高
`Context Engineering`	怎么让代理一直拿到正确上下文？	上下文层	长流程、多轮、多代理协作	做不好会污染上下文
`Harness Engineering`	怎么让代理稳定闭环执行？	环境层	长时任务、自动化研发体系	建设成本最高

十三、一个真实项目里，这些范式应该怎么组合？

真正成熟的 AI Coding 团队，通常不会只选一个名字。
更现实的做法，是把它们按阶段组合起来。

图 9：更现实的 AI Coding 组合路径

flowchart LR
    A[Vibe Coding<br/>验证想法] --> B[SDD<br/>澄清意图]
    B --> C[OpenSpec / Spec Kit<br/>规格入库]
    C --> D[TDD<br/>行为约束]
    D --> E[Claude Team / superpowers<br/>协作推进]
    E --> F[Context Engineering<br/>精准上下文]
    F --> G[Harness Engineering<br/>闭环执行]

这条链路里，每一个名字都在补前一个名字的短板：

Vibe Coding 太快，所以需要 SDD
SDD 太抽象，所以需要 OpenSpec / Spec Kit
规格写了还不够，所以需要 TDD
写完测试还不够，所以需要团队协作和流程化执行
协作还不够，所以需要正确上下文
上下文还不够，所以需要完整执行环境

十四、哪些名字最容易被忽略，但最值得补充？

如果你准备写一篇关于 AI Coding 方法论的文章，只讲 OpenSpec / Claude Team / SDD / Harness / TDD 还不够，我建议至少补上下面几个名字：

1. `Vibe Coding`

因为它是整个讨论的参照物。
很多新范式，本质上都在回答同一个问题：

我们怎样从“做出一个 Demo”进化到“交付一个可维护系统”？

2. `Spec Kit`

因为它是 GitHub 公开推出的 Spec-Driven Development 工具链，是 SDD 这条线非常有代表性的落地方向。

3. `superpowers`

因为它把 brainstorming、worktree、plan、subagent、TDD、review、branch finish 串成一条强制 workflow，代表了“流程驱动 AI Coding”这一支。

4. `Context Engineering`

因为它正在从“高级技巧”变成“AI 工程基本功”。

5. `Subagent-Driven Development`

因为很多人看到 SDD 会默认理解成 Spec-Driven Development，但在 superpowers 这样的工作流里，Subagent-Driven Development 也是另一条非常值得注意的支线。
写文章时，最好把这两个意思分开说清楚。

十五、对团队和个人来说，最重要的变化是什么？

很多人以为 AI Coding 的核心变化是：

模型更强了。

但如果把这几个范式连起来看，你会发现更重要的变化其实是：

代码会越来越便宜
清晰意图会越来越贵
正确上下文会越来越贵
验证闭环会越来越贵
团队协作和知识沉淀会越来越贵

也就是说，未来开发者的核心价值，正在从“亲手写出全部代码”，慢慢转向：

定义问题
设计边界
审查结果
组织上下文
设计验证系统
搭建代理执行环境

图 10：开发者角色变化

flowchart LR
    A[传统开发者<br/>写代码] --> B[AI 时代开发者<br/>定义意图]
    B --> C[组织上下文]
    C --> D[审查结果]
    D --> E[设计验证与环境]

这并不意味着工程师会被替代。
恰恰相反，这意味着：

软件工程的门槛没有消失，只是从“手工编码”转移到了“系统设计与质量控制”。

十六、写在最后：AI 不是在替代软件工程，而是在逼软件工程升级

如果只看表面，Vibe Coding、OpenSpec、Claude Team、Harness Engineering 这些词像是一串新潮黑话。
但如果把它们放回工程语境里，你会发现它们其实都在指向同一件事：

AI 不是在替代软件工程，它是在逼软件工程升级。

升级的方向不是更复杂，而是更清晰：

更清晰的需求
更清晰的规格
更清晰的边界
更清晰的验证
更清晰的上下文
更清晰的团队协作方式

未来真正有竞争力的团队，未必是“提示词写得最花”的团队，
而更可能是下面这种团队：

能把需求迅速结构化
能把知识沉淀进仓库
能让 AI 接入真实工作流
能用测试和评估系统约束代理
能把 AI 从“聊天助手”升级为“可治理的工程能力”

如果说过去软件工程师最重要的能力是“写出代码”，
那么未来软件工程师越来越重要的能力，可能会是：

写清楚意图、设计好系统、搭好验证闭环，并让 AI 在这个系统里稳定工作。

可直接用于配图的文案建议

封面标题候选

AI Coding 正在重写软件工程
从 Vibe Coding 到 Harness Engineering
AI 编程的 9 种命名开发范式

封面图提示词

未来感软件工程工作台，屏幕中同时出现 spec、tests、agent workflow、logs、pull request、architecture diagram，蓝绿色科技感，专业、克制、工程化，适合技术公众号头图，16:9

正文插图建议

Vibe Coding 一节配“灵感到原型”的插图
左侧自然语言需求，右侧快速生成的页面和代码。
OpenSpec / Spec Kit 一节配“规格变成仓库资产”的插图
突出 proposal、design、tasks、spec delta。
Claude Team / superpowers 一节配“团队与多代理协作”的插图
体现 brainstorming、plan、review、subagent。
Context Engineering / Harness Engineering 一节配“代理执行闭环”的插图
包含日志、trace、测试、自动修复、验证通过。

AI Coding 正在重写软件工程：从 Vibe Coding 到 Harness Engineering