Harness Engineering：AI 编程的“第三范式”，是程序员的救命稻草还是裁员预警？

三年前，程序员用 AI 补全代码，觉得多了个聪明的助手。两年前，Vibe Coding 兴起，大家开始觉得写代码像是在跟 AI 蹦迪，主打一个氛围感。

而现在，硅谷正在流行一个更激进的范式——程序员彻底退出驾驶座，转而去设计整条公路。

这个范式叫 Harness Engineering。

什么是 Harness Engineering？

这个词最早由 HashiCorp 创始人 Mitchell Hashimoto（Terraform 的作者）提出。他在分享自己的 AI 采用旅程时，把第五阶段命名为 "Engineer the Harness"。

简单来说，它不是让你去写 Prompt 调优，而是让你去设计一个“强约束、可观测、可评估、可反馈、可回退”的编码环境。

我用个“醉酒实习生”的故事来给你拆解一下。

想象一下，你手下有一个干活极快、但脑子不太清醒且偶尔酗酒的实习生（这就是现在的 AI Agent）。

如果你只是口头吩咐他：“去给我盖个房子”，他可能半小时就盖好了，但你推门一看，承重墙是歪的，马桶装在了天花板上。你教他改，他一边点头一边又把厨房给拆了。

传统的做法（第一、二范式）：你盯着他干活，他写一行你改一行，或者你不停地跟他吵架（Prompt Engineering），试图用语言感化他。累得半死，效率极低。

Harness Engineering（第三范式）：你一句话都不跟他废话。你直接在工地上焊死了一个钢结构框架。

这个框架规定了：

1. 每一块砖只能放在特定的槽位里（强约束）。
2. 只要砖放歪了 1 厘米，红灯就会闪烁（可观测）。
3. 每天下班前，有个自动测量仪会给墙壁打分，不及格就推倒重来（可评估、可反馈）。
4. 如果他把承重墙拆了，系统会自动恢复到昨天的进度（可回退）。

你没搬一块砖，但因为你设计的这个“钢架子”（Harness）足够牛逼，那个醉酒的实习生竟然奇迹般地盖出了一座五星级酒店。

这就是 Harness Engineering：程序员不再写代码，而是去设计那个让 AI 无法犯错的“约束环境”。

它是怎么运作的？（举个栗子）

很多人觉得这不就是“写测试”吗？其实核心差异在于：你的工作重心从“修代码”变成了“修环境”。

想象你要写一个“用户注册并发送欢迎邮件”的功能：

• 传统做法：你跟 AI 说：“帮我写个注册接口，成功后发邮件。” AI 写完了，你发现它没校验邮箱格式，或者邮件服务挂了也没处理。你开始一行行改它的代码，改得满头大汗。
• Harness 做法：
  1. 你先焊死“钢架子”：写好三个必过的测试用例（非法邮箱拦截、数据库回滚、邮件队列校验）。
  2. 定好“硬规矩”：定义严格的 TypeScript 类型，规定年龄必须是正整数，不准用过时的库。
  3. 把 AI 扔进去：它会疯狂尝试，撞到你设下的“南墙”（测试失败）就自动回头。
  4. 修支架，不修代码：如果 AI 还是写错了，你不要去改它的代码，你要反思：是不是我的测试用例漏掉了边界情况？是不是我的类型定义太松了？

你不断加固这个“钢架子”，直到 AI 只能顺着你预设的唯一正确路径把活干完。你全程没看代码实现，你只负责当那个“出题人”和“监工”。

为什么现在提这个？

这个概念的兴起，是因为大家发现 Prompt（提示词）是有极限的。

你写 1000 行提示词告诉 AI “不要写 bug”，它还是会写。因为语言是模糊的。

但 Harness（环境/支架）是硬性的。

• 它是你的测试用例（Test Cases）。
• 它是你的类型检查（Type Checking）。
• 它是你的 CI/CD 流水线。
• 它是你的日志监控。

当 Claude Code 或 Cursor 这种 Agent 越来越强，限制它们发挥的不再是它们的智商，而是你给它们提供的“工地”够不够标准。

管理能力的“逆袭”

前 Stripe CTO David Singleton 最近有个招聘观点挺有意思。@SaitoWu 转述说，他现在优先招那些当过 manager 但想回来写代码的人。

原因很直觉——manager 天生擅长拆解任务、设定 KPI、判断什么时候该介入、什么时候该放手。

这简直是程序员的“职场回旋镖”。

以前大家觉得 manager 就是动动嘴皮子，现在发现，当你的下属变成了一个 24 小时待命、但偶尔会一本正经胡说八道的 Agent 时，你那点带团队练出来的“管理直觉”，突然成了驾驭 AI 最核心的能力。

纪律派的当头棒喝

但在我们急着把键盘扔了之前，@calsys456 从 Common Lisp 社区扔出了一盆冷水。

他描述了一个近乎变态的工程纪律：注释怎么写、文档怎么排版、CI 检查规范，都有严格到像素级的要求。

然后他说了一句让我停下来想了很久的话：

“君视臣如草芥，臣视君如寇仇。”

LLM 怎么对待你的代码，取决于你怎么对待自己的代码。

如果你的代码库本身就是一团乱麻，没有结构、没有规范，那你建的 Harness 环境就是建在沙子上的。Agent 不会凭空创造秩序——它只会放大你现有系统的质量，不管是好的还是坏的。

所以，Harness Engineering 的门槛不是学会“不写代码”，而是你得先深刻理解什么是“好工程”，才有资格去设计那个约束环境。

结语

Harness Engineering 不是让程序员消失，而是逼我们回答一个一直在逃避的问题：

你的价值到底在“写代码”这个动作里，还是在“理解问题、设计系统、做出判断”这些能力里？

如果答案是前者，那确实该恐惧了。毕竟按照现在的进化速度，国内两年内出现大面积裁员可能真不是危言耸听。

如果答案是后者——恭喜，你一直在为这个时代做准备，只是你自己不知道而已。

（不才，我正准备去给我的 Agent 焊个更结实的“钢架子”，结果写着写着发现，我自己才是那个最需要被约束的“酗酒实习生”。🤣）