从 Vibe Coding 到 Harness 工程

2026-05-24

2025 年 2 月，Andrej Karpathy 在 X 上发了一条帖子，给一种新的编程方式起了个名字：vibe coding。

描述很直白，完全沉浸在 vibe 里，接受 AI 的补全建议，不看生成的代码长什么样，遇到报错粘回 AI 让它自己修。他甚至说，你不再是一个程序员，只是一个"提需求的人"。

The Verge、Ars Technica 都做了报道，开发者社区里有人欢呼编程民主化，有人担忧生成代码的质量。

但一年多后回头看，vibe coding 这个词最大的价值可能不是它描述的现象，而是它标记了一个阶段的结束。

Vibe Coding 做对了什么

Karpathy 不是第一个用 AI 写代码的人，但他是第一个给这个体验命名的人。命名本身就是贡献，它让人们意识到编程的方式已经变了。

在 vibe coding 之前，AI 辅助编程的工具已经存在：GitHub Copilot 的 Tab 补全、ChatGPT 的代码生成。但这些工具的使用方式还是"人的工作流 + AI 辅助"。Vibe coding 翻转了这个关系，AI 成了主笔，人成了提要求的那个。

这个翻转的意义不在于它多高效（虽然很多时候确实高效），而在于它重新划定了"什么人可以编程"的边界。非程序员可以用自然语言描述需求，得到一个能跑的东西。这不是将来时，是 2025 年就已经发生的事。

但问题也随之而来

Vibe coding 的运作方式建立在两个隐含假设上：

  1. 生成的代码只要能跑就行
  2. 错了也不怕，粘贴回去让 AI 再改

这两个假设在原型阶段完全成立。做一个个人项目、搭一个 demo、验证一个想法——vibe coding 是很好的工具。

但到了团队协作、生产部署、长期维护的场景，这两条都站不住。能跑的代码不等于正确的代码，更不等于可维护的代码。 不读报错意味着 AI 可能在同一个 bug 上反复打转。不看代码意味着无法判断生成的代码有没有引入安全问题、性能问题、或团队约定之外的模式。

这不是 vibe coding 的错。它本就不是为生产环境设计的。但行业在快速从"用 AI 做个东西看看"进入"用 AI 做的东西上线跑"，这就引出下一个问题：怎么验证 AI 生成的东西是不是对的？

Cursor 的三段论

2026 年 2 月，Cursor 联合创始人 Michael Truell 发表了一篇博客，把 AI 辅助编程的演进分成三个阶段：

阶段模式时间
第一代Tab 自动补全~2023–2024
第二代同步 Agent 对话2024–2025
第三代自主云端 Agent2026+

Vibe coding 本质上是第二代的体验描述，人与 AI 在同一会话里来回交互，AI 理解上下文、跨文件修改、自己排查错误。Cursor 给出的数据很直观：2025 年 3 月，使用 Tab 补全的用户数还是 Agent 用户的 2.5 倍；一年后逆转，Agent 用户是 Tab 的 2 倍，Agent 使用量增长了 15 倍以上。

但 Truell 的判断是：第二代也不会持续太久。正在到来的第三代的特征是 Agent 在云端独立运行，不依赖人类的实时交互，可以同时执行多个任务，人类从手把手带一个助手变成同时管理多个 Agent。

这个判断引出了一个核心问题：当 Agent 可以在没有人类监督的情况下独立行动，如何知道它在正确地工作？

Harness Engineering 登场

答案就是 harness 工程。

Harness 这个词在软件工程里不是新东西，test harness（测试套具）是一个经典概念。但在 AI Agent 的语境下，它的含义发生了根本变化。

LLM 评测的 harness（比如 EleutherAI 的 lm-evaluation-harness）是一只"自动阅卷机"：加载模型，拼接 prompt，推理，和标准答案比对，出分。一次性的，单轮的，纯文本的。

Agent 评测的 harness 完全不一样。Agent 会调用工具、操作文件系统、执行代码、发起网络请求，可能跨越几十步才完成一个任务。 评测它不是在评测一段输出文本，而是在评测一系列行动的结果。

以 SWE-bench 为例：每个评测任务是一个真实的 GitHub Issue，harness 为每个 Issue 构建独立的 Docker 镜像（还原仓库的精确状态），agent 在容器里分析和修复问题，生成补丁，harness 应用补丁并运行项目的真实测试套件，测试通过了就算解决。这是目前最成熟的 agent harness 实现，也是 HuggingFace 和各大模型厂商用来排名的标准后端。

Cursor 在 2026 年 4 月发表了一篇专门的文章，详细介绍了他们自己的 agent harness。他们的定义包含四层：

  • 上下文窗口管理 — 决定什么信息放入 prompt、什么信息裁掉
  • 工具调用系统 — 文件编辑、搜索、终端执行等操作的编排
  • 评估套件（CursorBench） — 内部基准，覆盖各种 Coding 场景
  • 线上 A/B 测试 + Keep Rate 追踪 — 每次改动是否提升了 Agent 生成代码的保留率

他们对这个工作的态度值得注意。原文说："我们构建 Cursor agent harness 的方式，和构建任何雄心勃勃的软件产品一样，痴迷地堆叠小优化。"

Harness 正在成为和模型训练同等重要的工程领域。 模型能力是生产力的一个乘数因子，harness 是另一个。Cursor 的判断是，harness 的持续改进对 Agent 表现的影响，可以媲美一次从 GPT-3.5 到 GPT-4 的模型升级。

Vibe 与 Harness 不是二选一

回到 Karpathy 最初的帖子。Vibe coding 的核心是"放手"，信任 AI，减少干预。Harness 工程的核心是"兜底"，验证 AI 是否做了正确的事。

这两者不是对立的。它们是同一个工作流的上下游：

Vibe coding（发散探索）→ Agent 产出 → Harness（收敛验证）→ 度量 → 方向修正 → 回到 Vibe

没有 vibe，需要手动写每一行代码，效率低下。没有 harness，无法判断 AI 生成的东西能不能上线、会不会出问题。

对于个人项目，可能只需要前者。对于团队和生产环境，少了哪一个都不行。

2026 年及以后

几个正在发生的趋势。

评估从面向任务转向面向目标。 SWE-bench 家族的最新成员叫 CodeClash，定位是"将模型作为目标导向的开发者而非任务执行者来评估"。这意味着评测正在从"能否完成这个 Issue"走向"能否像一个真实开发者一样自己发现问题、拆解问题、解决问题"。

Keep Rate 正在成为比基准分数更重要的指标。 基准分数告诉开发者 Agent 在静态数据集上的表现，Keep Rate 告诉开发者 Agent 生成的代码在实际项目中是否真的被保留了下来。这是"实验室表现"和"生产表现"的差距。

环境工程成为新瓶颈。 Cursor 在构建云端 Agent 时发现了一个事实：环境质量是输出质量的最大决定因素。Agent 的代码在 CI 里通过了，但换个环境就挂了。给 Agent 配一个完整、稳定、可复现的开发环境，这件事的难度和复杂度远超预期。他们称之为"给 Agent 做 IT 运维"。

更会建 harness 的团队比更会 vibe 的开发者更有价值。 当 Agent 可以独立完成任务，人的角色从"写代码"变成了"定义问题、设定标准、审查产物"。

回到开头。Karpathy 说 vibe coding 时，他描述的是一个现象。一年后回头看，这个现象的意义可能不在于"编程门槛降低了"，这一点早就被 Copilot 证明了。它的意义在于标记了一个转折点：行业从"AI 能不能写代码"进入了"AI 写的代码能不能信任"。要从第一个问题走到第二个问题，答案就是 harness 工程。

参考

https://blog.logfun.xyz/blog/feed.xml