从 Vibe Coding 到 Spec Coding 再到 Harness Engineer：AI 编程的三次范式跃迁

2024 年，Vibe Coding 让人人都能「用嘴写代码」；2025 年，Spec Coding 让 AI 编出的代码真正可用；2026 年，Harness Engineer 让人类从「写代码的人」变成「驾驭 Agent 的人」。三次范式跃迁，不是工具升级，而是人机协作关系的根本重构。

一、全景：三次跃迁的底层逻辑

在 AI 编程的演化链上，每一次跃迁都在回答同一个问题的不同层面：人类和 AI 之间，谁负责什么？

阶段	核心理念	人类角色	AI 角色	典型产出质量
Vibe Coding	想到哪写到哪，氛围感驱动	提需求 + 验收	猜意图 + 写代码	Demo 级
Spec Coding	规格先行，结构化驱动	定义「做什么」+ 审查规格	按规格实现 + 自验证	生产级
Harness Engineer	构建运行时约束系统	设计 Agent 运行环境	在 Harness 内自主执行	工程级

这不是替代关系——它是层叠关系。Spec Coding 不会消灭 Vibe Coding（快速原型仍然需要它），Harness Engineer 也不会消灭 Spec Coding（规格仍然是核心输入）。每一层都解决了上一层无法回答的问题。

二、Vibe Coding：人人都是程序员的美丽幻觉

2.1 什么是 Vibe Coding

Vibe Coding 这个词由 Andrej Karpathy 在 2024 年初提出，用来描述一种全新的编程方式：

你不写代码，你用自然语言描述你想要的东西，AI 帮你生成代码。你甚至不需要看懂代码——只要结果「感觉对了」，就继续往下走。

核心工作流极其简单：

描述需求 → AI 生成代码 → 看效果 → 不满意就再描述 → 循环

这种方式的魅力在于零门槛。一个不会编程的产品经理，可以在 30 分钟内让 AI 搭出一个看起来像模像样的 Web 应用。

2.2 Vibe Coding 的致命缺陷

但「看起来能用」和「真正能用」之间，隔着一道深渊。

歧义是最大的敌人。 当你说「加一个用户管理功能」，AI 需要自己猜测：

「用户」是内部管理员还是终端用户？
「管理」是 CRUD 还是包含权限体系？
密码用什么加密？Session 还是 JWT？
删除是软删除还是硬删除？

这些「沉默的决策」，AI 每一个都在替你做。有些猜对了，有些猜错了。系统越复杂，猜错的概率越高，修复的成本也越高。

Vibe Coding 的其他典型问题：

范围蔓延：没有明确边界，AI 容易过度实现或遗漏关键点
幻觉（Hallucination）：AI 编造不存在的 API、错误的用法
不可审查：没有 spec 和 plan，团队无法在实现前对齐预期
不可复现：换一个 prompt 措辞，得到完全不同的实现
技术债指数级增长：每一轮「看起来能用」的修补都在累积隐患

2.3 Vibe Coding 的正确定位

Vibe Coding 并非一无是处。它的最佳场景是：

快速验证一个想法是否可行（Proof of Concept）
一次性脚本、数据处理、临时工具
学习新框架时的探索性编程
个人项目、Hackathon、Demo 展示

一句话总结：Vibe Coding 是 AI 编程的「素描」，不是「施工图」。

三、Spec Coding：从「猜你想要什么」到「照规格施工」

3.1 为什么行业集体转向 Spec

2025 年，一个共识浮出水面：AI Coding Agent 效果不好，往往不是因为模型太弱，而是因为指令含糊不清。

证据无处不在：

GitHub 开源了 Spec Kit（7.7 万星），把 spec → plan → task → implement 结构化
OpenAI 的 Symphony 架构要求每个 issue 绑定 SPEC.md 作为契约
Anthropic 在 Claude Code 里内置了 Plan Mode——本质就是轻量版 spec
AWS 推出了 Kiro，以 spec 为核心驱动 Agent 开发

整个生态不约而同地收敛到同一个结论：在写代码之前，先把「做什么」定义清楚。

3.2 Spec Driven Development（SDD）的核心流程

SDD 不是一个工具，而是一种方法论。核心分为四步：

Specify（定义做什么）→ Plan（规划怎么做）→ Tasks（拆解任务）→ Implement（逐个实现）

第一步：Spec —— 只写「做什么」，不写「怎么做」

Spec 是功能层描述，刻意保持技术无关。一份好的 spec 用非技术语言写清：功能目的、使用场景、需求边界、验收标准。

## 功能：社交登录
用户可以使用 Google 和 GitHub 账号登录系统。

### 验收标准
- Given 新用户，When 点击「Sign in with Google」并授权，Then 重定向到 Dashboard 并获得有效 Session
- Given 已绑定 Google 的用户，When 用相同邮箱通过 GitHub 登录，Then 两个账号关联到同一 Profile
- Given 用户取消授权，When 回到登录页，Then 显示友好错误提示而非白屏

关键洞察： 把功能描述和技术实现分离，可以显著降低 LLM 的不确定性。Spec 不仅是文档——它就是测试计划，Agent 可据此验证实现。

第二步：Plan —— 注入开发者的专业判断

Plan 是技术层：告诉 Agent 如何把 spec 落地。

## 技术方案
- 使用 NextAuth.js + App Router，遵循已有认证模式
- Session 策略：JWT，存储于 HttpOnly Cookie
- 数据模型：扩展现有 User 实体，新增 provider、providerAccountId 字段
- 测试策略：认证流程单测覆盖率 ≥ 90%
- 性能约束：登录接口响应 < 100ms（P99）

第三步：Tasks —— 分而治之

把 Plan 拆成小而有序的任务，每个任务满足：可在一次 Agent Session 中完成、产出可验证的变更并附带测试。

第四步：Implement —— Agent 逐个执行

Agent 按任务列表顺序实现。此时它拿到了所需的一切上下文，不需要再猜。

3.3 Spec Coding 的三个成熟度层级

层级	名称	特点
L1	Spec-First	先写 spec 再编码，功能完成后 spec 归档
L2	Spec-Anchored	Spec 与代码共存于仓库，随代码持续演化
L3	Spec-as-Source	Spec 成为主工件，改 spec 即改系统

大多数团队从 L1 起步就能获得显著收益。L3 是更前沿的方向——spec 成为「可执行的规格说明」。

3.4 Spec Coding 解决了什么，没解决什么

解决了：

歧义问题——Agent 不需要再猜
可审查性——团队可在实现前对齐预期
可复现性——相同 spec 产出一致结果
质量底线——验收标准就是测试用例

没解决：

Agent 运行时的故障恢复
多 Agent 协作的编排与状态管理
上下文窗口的动态管理
安全防护与人工审批流程
跨会话的记忆持久化

换句话说，Spec Coding 解决了「告诉 Agent 做什么」的问题，但没有解决「Agent 如何可靠地运行」的问题。

这正是 Harness Engineer 登场的理由。

四、Harness Engineer：AI 时代的新工种

4.1 什么是 Harness

2026 年，一个新术语在 AI 工程领域迅速升温：Harness。

OpenAI 和 Anthropic 正式采用了这个术语。Martin Fowler 撰文阐述。arXiv 上出现了形式化定义。

Harness 不是 Agent。它是管理 Agent 如何运行的软件系统。

Philipp Schmid 用了一个精妙的计算机类比：

计算机概念	AI Agent 对应
CPU（原始处理能力）	LLM（模型推理能力）
RAM（有限工作记忆）	上下文窗口
操作系统	Harness
应用程序	Agent

Harness 就是 Agent 的操作系统——管理上下文、初始化序列、标准工具驱动程序。Agent 是运行在其上的应用程序。

4.2 Harness 的六大核心组件

组件	职责	类比
工具集成层	通过标准协议连接外部 API、数据库、代码执行环境	设备驱动程序
内存与状态管理	多层记忆——工作上下文、会话状态、长期记忆	内存管理 + 文件系统
上下文工程	动态策划每次模型调用中出现的信息	进程调度器
规划与分解	引导模型通过结构化任务序列推进	任务调度器
验证与防护	格式校验、安全过滤、自我纠正循环	防火墙 + 权限系统
模块化与可扩展	可独立启用、禁用或替换的可插拔组件	内核模块

4.3 真实世界中的 Harness

这不是理论——Harness 已经在生产环境中运行：

Claude Code 就是一个 Harness：读代码库、管理文件系统、编排子 Agent、跨会话记忆、安全防护。开发者专注任务，Harness 管其余一切。
OpenAI Codex 团队构建超大规模代码库时以 Harness 为主要接口——上下文工程、架构约束、定期清理 Agent 是核心实践。
Cursor 的 Rules、Skills、MCP 工具链——本质上就是一套轻量级 Harness：通过 .cursor/rules/ 定义行为约束，通过 Skills 注入领域知识，通过 MCP 打通外部工具。

4.4 Harness Engineer：一种全新的工程师角色

当 AI Agent 承担了越来越多的编码工作，一个新的职业角色自然浮现——Harness Engineer。

Harness Engineer 不是传统意义上的程序员，也不是纯粹的产品经理。他们的核心技能是：

1. 上下文工程（Context Engineering）

不再是写一个静态 prompt，而是设计动态的信息策划系统：什么信息在什么时候进入 Agent 的上下文窗口，什么信息该被剪裁掉，什么信息需要持久化到长期记忆。

2. 约束设计（Constraint Design）

为 Agent 设定清晰的行为边界：哪些操作可以自主执行，哪些需要人工审批，遇到歧义时的降级策略是什么，错误恢复的重试逻辑如何设计。

3. 工具编排（Tool Orchestration）

决定 Agent 可以使用哪些工具、以什么顺序使用、工具之间的数据如何流转。这包括 MCP 协议配置、自定义工具链搭建、子 Agent 委派策略。

4. 规格治理（Spec Governance）

维护从 constitution → spec → plan → tasks 的完整规格体系，确保规格与代码的一致性，建立规格的版本化和演化机制。

5. 质量闭环（Quality Loop）

设计验证链——不只是最终测试，而是在 Agent 执行的每一步都嵌入验证点：代码生成后的静态检查、API 契约的一致性校验、安全扫描、性能基线对比。

4.5 从 Framework 到 Harness 的范式迁移

2026 年的一个重要趋势：模型正在吸收传统多 Agent Framework 约 80% 的能力（Agent 定义、消息路由、任务生命周期）。

剩下的 20%——持久性、确定性重放、成本控制、可观察性、错误恢复——正是 Harness 提供的。

Framework 层不是在消失，而是在分裂：智能进模型，基础设施进 Harness。

这意味着团队的核心问题从「该用哪个 Framework？」变成了「我们的 Harness 长什么样？」

五、三次跃迁的实践路径

5.1 从 Vibe Coding 到 Spec Coding 的迁移

如果你今天还停留在 Vibe Coding 阶段，最小启动路径是：

先用 Plan Mode：在 Cursor 或 Claude Code 中养成「先 plan 后写」的习惯——这就是轻量版 SDD
写第一份 spec：挑一个中等复杂度的功能，按 spec → plan → tasks → implement 走一遍
工具辅助：用 Spec Kit（specify init . --ai cursor-agent）生成完整的 spec 目录结构
迭代：第一份 spec 一定是粗糙的，但修正一份 spec 远比修正一坨乱码容易

5.2 从 Spec Coding 到 Harness Engineer 的迁移

当你的 Spec Coding 流程稳定后，开始构建 Harness：

Constitution 先行：为项目建立「宪法」—— 质量标准、测试要求、安全底线、架构原则
Rule 体系：用 .cursor/rules/ 或 CLAUDE.md 定义 Agent 行为约束
Skills 注入：把团队的领域知识封装成可复用的 Skills
MCP 打通：通过 MCP 协议连接团队的内部工具、API、数据库
验证链路：在每个关键节点嵌入自动化验证——不是事后补测试，而是构建在流程中

5.3 不同阶段的适用场景

场景	推荐阶段	理由
Hackathon / Demo	Vibe Coding	速度优先，不需要长期维护
个人工具 / 一次性脚本	Vibe Coding	复杂度低，歧义有限
团队功能开发	Spec Coding	需要对齐预期，需要可审查
多模块 / 跨域改造	Spec Coding	歧义多、影响面大
生产系统持续演进	Harness Engineer	需要 Agent 运行时的可靠性保障
多 Agent 协作	Harness Engineer	需要编排、状态管理、故障恢复

六、更远的未来

三次跃迁揭示了一条清晰的演化方向：

人类的角色正在从「编写代码」上移到「编写约束」。

Vibe Coding 时代，人写 prompt，AI 写代码
Spec Coding 时代，人写 spec，AI 按 spec 实现
Harness Engineer 时代，人设计运行环境，AI 在环境中自主运作

再往前看，可能的下一步是 Harness-as-Code：Harness 本身也由 AI 根据高层意图自动生成和优化。到那时，人类的核心价值将进一步收缩到最本质的东西——定义「为什么要做」和「什么不能做」。

但无论技术如何演化，一个根本规律不会变：系统的质量上限，永远取决于人类表达意图的精确程度。 从 Vibe Coding 到 Spec Coding 到 Harness Engineer，本质上都是在提升这个精确度——只是维度从「描述功能」扩展到了「设计系统」。

参考资源

资源	说明
GitHub Spec Kit	GitHub 官方 SDD 工具包
Anthropic: Building Effective Agents	Anthropic 官方 Agent 构建指南
OpenAI Codex	OpenAI 代码 Agent，Harness 工程典型案例
Martin Fowler: AI Harness	架构大师对 Harness 模式的阐述
Cursor Rules & Skills	Cursor 的轻量级 Harness 实践

写于 2026 年 3 月。AI 编程范式仍在快速演化——本文观点基于当前行业共识，随时可能被下一次跃迁重新定义。

从 Vibe Coding 到 Spec Coding 再到 Harness Engineer：AI 编程的三次范式跃迁