夜雨聆风
AI Coding 正在重写软件工程:从 Vibe Coding 到 Harness Engineering
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 编程，但又不像同一类东西。
这篇文章的目标，就是把这几个名字放到一张工程地图里，讲清楚：
-
1. 它们分别解决什么问题 -
2. 它们处在开发流程的哪一层 -
3. 它们彼此之间到底是替代关系，还是组合关系 -
4. 一个团队真正落地 AI Coding 时，应该如何把它们串起来
说明：这篇文章只讨论“命名开发范式 / 工作流”，不展开
Prompt、MCP、Skills、Rule这些基础构件。它们更像积木，不是本文要讨论的方法论品牌。术语提醒：
SDD在社区里经常一词多义。本文默认把SDD写作Spec-Driven Development；如果特指多个子代理分工执行，我会写成Subagent-Driven Development，避免混淆。
零、先把这些名字翻译成人话
很多文章一上来就直接丢缩写，读者如果不是天天泡在 AI Coding 圈里，很容易第一段就掉队。所以在进入正文之前，我们先把这些名字逐个“翻译成人话”。
一张表看懂这些名词
|
|
|
|
|
|
|---|---|---|---|---|
Vibe Coding |
|
|
|
|
TDD |
Test-Driven Development |
|
|
|
SDD |
Spec-Driven Development |
|
|
|
OpenSpec |
|
|
|
|
Spec Kit |
|
|
|
|
Claude Team |
|
|
|
|
superpowers |
obra/superpowers
|
|
|
|
Context Engineering |
|
|
|
|
Harness Engineering |
|
|
|
|
几个最容易误解的词
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 范式总览
这张图不是严格的时间线，也不是替代链，而是一条“工程成熟度升级线”：
-
• 从“先做出来” -
• 到“先验证” -
• 到“先定义意图” -
• 到“把意图沉淀为资产” -
• 到“把 AI 纳入团队协作” -
• 到“把工作流和执行环境一起工程化”
二、这些名字其实不在一个层级上
很多争论之所以吵不清楚，是因为大家在拿不同层级的东西互相比较。
比如：
-
• TDD更偏验证方法 -
• SDD更偏规格方法 -
• OpenSpec和Spec Kit更偏规格落地框架 -
• Claude Team更偏团队协作范式 -
• superpowers更偏执行工作流 -
• Context Engineering更偏上下文组织方法 -
• Harness Engineering更偏代理执行环境设计
图 2：这些范式分别处在哪一层
一旦把层级放对，这些名字之间的关系就清楚了：
-
• 它们大多不是互斥的 -
• 真正成熟的团队，通常不会只选一个 -
• 它们更像“不同层的组合拳”
三、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 的核心流程是：
-
1. 先写失败测试 -
2. 再写实现让测试通过 -
3. 最后重构
也就是经典的 Red -> Green -> Refactor。
在 AI Coding 时代，这套方法多了一层非常关键的意义：
它把模糊的人类需求，变成了 AI 必须通过的可执行约束。
为什么 TDD 在 AI Coding 里更重要？
因为你跟模型说：
-
• “做个登录功能”，它会写代码 -
• “先写测试，覆盖密码错误、账号锁定、Remember Me、会话过期、多端冲突”，它才会被拉回工程现实
换句话说，TDD 的价值从“提升开发纪律”，升级成了“给 AI 定义行为边界”。
图 3：TDD 在 AI Coding 中的作用
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 的核心产物
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 关注的流程
-
1. 先写出目标和意图 -
2. 再沉淀为规格 -
3. 再生成 plan -
4. 再拆成 tasks -
5. 再交给代理执行
OpenSpec 和 Spec Kit 的区别
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
简单说：
-
• 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 式的人机协作
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，它的核心链路大致如下：
-
1. brainstorming -
2. using-git-worktrees -
3. writing-plans -
4. subagent-driven-development或executing-plans -
5. test-driven-development -
6. requesting-code-review -
7. finishing-a-development-branch
图 6：superpowers 的核心 workflow
为什么 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 正确上下文
它的本质是什么？
一句话：
让代理把注意力放在对的地方，而不是让它看更多东西。
这也是为什么今天很多高质量 AI Coding 团队，会特别重视：
-
• 仓库中的结构化规范 -
• 会话切分 -
• 文件选择 -
• 上下文压缩 -
• 任务分层 -
• 记忆与知识沉淀
十一、Harness Engineering：代理时代真正的工程，开始于环境设计
先解释名字。Harness Engineering 里最难理解的是 Harness。如果按字面翻译，它接近“马具、束具、安全带、工装”这类东西，核心含义都是“把系统套起来、接起来、控制起来”。放到软件工程里，它更接近“执行框架”或“验证工装”的意思。
所以 Harness Engineering 不是在说“怎么写更强的提示词”，而是在说：怎么给代理搭一整套可运行、可观测、可验证、可修复的执行环境。
如果说前面的范式主要在解决：
-
• 怎么想清楚 -
• 怎么协作 -
• 怎么组织上下文
那么 Harness Engineering 解决的是最后、也最难的一公里：
代理怎样才能稳定、可靠、长时间地把事情做完？
OpenAI 在 2026 年 2 月 11 日公开提出 Harness Engineering，并用一句话概括其核心：
Humans steer. Agents execute.
这背后代表的是一套非常重要的新工程观：
-
• 人不再手写每一行代码 -
• 人开始更多地设计环境、指定意图、建立反馈回路 -
• 代理不只写代码，还能启动应用、观察日志、读取指标、验证修复、回应 review、继续迭代
Harness Engineering 的几个关键点
-
1. 让应用对代理可读日志、页面、trace、指标、测试结果，都要让代理看得见。 -
2. 让仓库成为 system of record知识不能散落在聊天、Wiki、脑海中。对代理来说，仓库里没有，就等于没有。 -
3. 把 review、test、validation 编码进系统不是让 AI 写完就停，而是让它在验证系统里反复修正。 -
4. 让约束比指令更重要通过 lint、结构测试、taste invariants 等机制约束代理，而不是只靠大段提示词。
图 8：Harness Engineering 的闭环
它为什么重要？
因为一旦 harness 搭好，代理就不再只是聊天窗口里的助手，而会逐渐变成一个能在真实工程环境里持续执行任务的系统角色。
这也是 AI Coding 未来最重要的升级方向之一。
十二、把 9 个名字放在一起看：它们分别在回答什么问题？
|
|
|
|
|
|
|---|---|---|---|---|
Vibe Coding |
|
|
|
|
TDD |
|
|
|
|
SDD |
|
|
|
|
OpenSpec |
|
|
|
|
Spec Kit |
|
|
|
|
Claude Team |
|
|
|
|
superpowers |
|
|
|
|
Context Engineering |
|
|
|
|
Harness Engineering |
|
|
|
|
十三、一个真实项目里，这些范式应该怎么组合？
真正成熟的 AI Coding 团队，通常不会只选一个名字。更现实的做法，是把它们按阶段组合起来。
推荐组合路径
-
1. 先用 Vibe Coding做低成本探索快速验证点子，尽快看到第一版成型结果。 -
2. 一旦要进入正式开发，就切到 SDD把需求、边界、验收标准写清楚。 -
3. 用 OpenSpec或Spec Kit把规格入库让上下文从聊天变成仓库资产。 -
4. 实现阶段坚持 TDD把行为定义成可执行约束。 -
5. 执行时用 Claude Team或superpowers推进前者偏团队协作，后者偏流程固化。 -
6. 通过 Context Engineering保证代理拿到对的上下文不让代理在噪音里迷路。 -
7. 成熟阶段引入 Harness Engineering把 AI Coding 从“助手模式”升级到“闭环执行模式”。
图 9：更现实的 AI Coding 组合路径
这条链路里，每一个名字都在补前一个名字的短板：
-
• 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：开发者角色变化
这并不意味着工程师会被替代。恰恰相反，这意味着：
软件工程的门槛没有消失，只是从“手工编码”转移到了“系统设计与质量控制”。
十六、写在最后：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
正文插图建议
-
1. Vibe Coding一节配“灵感到原型”的插图左侧自然语言需求，右侧快速生成的页面和代码。 -
2. OpenSpec / Spec Kit一节配“规格变成仓库资产”的插图突出proposal、design、tasks、spec delta。 -
3. Claude Team / superpowers一节配“团队与多代理协作”的插图体现 brainstorming、plan、review、subagent。 -
4. Context Engineering / Harness Engineering一节配“代理执行闭环”的插图包含日志、trace、测试、自动修复、验证通过。
参考资料
-
• OpenSpec 官方网站 -
• Spec Kit Documentation -
• Spec-driven development with AI: Get started with a new open source toolkit – GitHub Blog，2025-09-02 -
• How Anthropic teams use Claude Code – Claude，2025-07-24 -
• superpowers GitHub 仓库 -
• How to build reliable AI workflows with agentic primitives and context engineering – GitHub Blog，2025-10-13 -
• Harness engineering: leveraging Codex in an agent-first world – OpenAI，2026-02-11 -
• Test Driven Development – Martin Fowler