前言

先说一个我身边真实发生过很多次的场景。

同一个部门，同一个订阅账号，同一个模型。A 组说：「这玩意儿一天顶我三天，我们的积压 Bug 清空了。」B 组说：「就是个高级搜索引擎吧，写出来的代码根本跑不起来，改它还不如我自己写。」

看到这种反差，第一反应通常是：是不是 A 组用了更贵的模型？ 或者 是不是 B 组的人不会写提示词？

这两个猜测，大多数时候都错了。真正的差别在一个很少被提起、但已经成为行业分水岭的东西上——Harness（脚手架）。而围绕它做的工程工作，就叫 Harness Engineering。

一、先把这个词翻译明白

Harness 这个英文单词，原意是马的挽具——就是套在马身上、把马和马车连起来的那一整套皮带、缰绳、轭。

这个比喻精确得让人拍案叫绝：

• 马，是力量的来源。一匹好马跑得快。
• 但一匹没有套挽具的马，你没法用它拉货。 它跑它的，你站在原地。
• 挽具本身不产生一丝一毫的力气，可是有没有它，决定了这匹马的力量能不能变成「货送到了」。

把这个比喻搬到 AI 上：

• 马 = 大模型（Model）：真正的智力来源。
• 挽具 = Harness：模型之外，你亲手搭建的那一整圈东西——它能看见什么、能动手做什么、做完之后谁告诉它对错、哪些事情必须先问人。

再换一个工科味道更重的比喻：模型是发动机，Harness 是整辆车。变速箱、方向盘、刹车、仪表盘、油箱、后视镜——这些都不产生动力，但一台放在地上空转的发动机，运不了任何东西。

所以：

Harness Engineering，就是设计和搭建「模型周围那一圈东西」的工程实践。

二、Harness 到底包含哪几块？

上面那张图里的六块，是任何一套像样的 Harness 都会有的。我一块一块解释，每块都配一个生活化的例子。

1. 工具（Tools）—— 让它能「动手」

模型天生只会做一件事：输出文字。它不会打开文件、不会执行命令、不会查数据库。

工具就是你给它接上的一双手：读文件、写文件、执行终端命令、调用公司内部 API、查订单系统。

类比：你雇了一个非常聪明的新人，但你把他锁在一间只有纸和笔的空房间里。他能给你写出漂亮的方案，但他碰不到你的系统。「给工具」，就是把他放出来，给他一台连上内网的电脑。

2. 上下文（Context）—— 决定它「看得见」什么

模型不认识你的公司。它不知道你们的代码规范、不知道那个字段为什么叫 is_valid_v2、不知道上周架构评审的结论。

上下文就是你在每次让它干活之前，塞给它的那一沓资料。

类比：新人入职第一天，你是直接说「去把订单模块优化一下」，还是先给他系统架构图、编码规范、和最近三个月的故障复盘？结果天差地别。

这里有个反直觉的点，后面「常见误区」里会讲：塞得越多，未必越好。

3. 记忆（Memory）—— 跨会话记住结论

默认情况下，模型是彻底失忆的。这次对话说好的事情，下次开一个新窗口，它完全不记得。

记忆层就是把「我们团队用 4 空格缩进」「这个项目禁止用反射」这类结论持久化下来，每次自动带上。

类比：一个每天早上失忆的员工 vs. 一个有笔记本的员工。后者第二周就开始变得好用了。

4. 护栏（Guardrails）—— 什么能做，什么必须先问人

AI 会犯错。护栏决定的是：当它犯错的时候，代价有多大。

• 读文件？随便读，出不了事。
• 改一个测试文件？让它改，反正有版本控制。
• 删数据库、往生产环境发布、执行付款？必须停下来，等人点头。

类比：新人可以随便看文档，但公章不能给他。这不是不信任，这是任何一个成熟组织的基本盘。

5. 反馈回路（Feedback Loop）—— 让它听得见「回声」

这是六块里最容易被忽略、但威力最大的一块。

模型写完代码之后，如果没人告诉它「编译失败了」，它就会一直以为自己写对了。它会自信地把一堆跑不起来的东西交给你。

反馈回路就是把编译器的报错、单元测试的结果、程序的日志，自动送回给模型，让它看到自己捅的娄子，然后自己去修。

类比：教一个人投篮。如果他每次投完你就把灯关了，他永远不知道球进没进，练一万次也没用。反馈回路，就是那盏灯。

这也解释了一个常见现象：AI 在有完善测试的项目里效果好得惊人，在没有测试的老项目里像个憨憨。不是模型变笨了，是灯关着。

6. 可观测性（Observability）—— 看得见它做了什么

它中间调了哪些工具、读了哪些文件、为什么选了这个方案？出问题的时候，你能不能回放整个过程？

类比：仓库的监控录像。平时没人看，但丢了货的那天，它是唯一能救你的东西。

这一块看起来最「没用」，却直接决定了你敢不敢把重要的事情交给它——以及万一出了事，你能不能说清楚发生了什么。

三、把它转起来看一遍

单独讲六块还是抽象。我们看一次完整的「转动」：

用大白话复述这张图：

1. 你说「把登录的那个 Bug 修了」。
2. Harness 自动把相关代码、编码规范、之前的报错记录，打包给模型。（你没有手工复制粘贴，是它自动做的。）
3. 模型判断：应该改 AuthService.cs 第 42 行。
4. Harness 检查护栏：改一个源文件，允许，直接执行。（如果它想执行 DROP TABLE，这里就会停下来问你。）
5. 改完，Harness 自动跑测试。
6. 3 个测试挂了。这个失败信息被自动送回给模型，它带着证据再来一轮。

关键在第 6 步。没有第 6 步的系统，是个聊天机器人；有第 6 步的系统，才是个能干活的东西。

四、为什么这件事值得单独当一门工程来做

来看这张对比图——注意，两边用的是完全相同的模型：

这就是文章开头 A 组和 B 组的差别。

我想强调一个容易被误解的因果关系：

模型能力决定了天花板，Harness 决定了你实际能摸到天花板的多少。

现在业界的普遍观察是：主流大模型之间的差距，远远小于「Harness 搭得好」与「Harness 搭得差」之间的差距。换更贵的模型，可能带来 10% 的提升；把反馈回路接上，可能带来 300% 的提升。

这句话还有一层更实际的含义：

买 License 只是第一步，而且是最便宜、最不重要的那一步。

真正的投入，在于让 AI 能安全地接触你的系统、能自动拿到反馈、能记住你们的规矩。这部分工作是工程建设，需要有人花时间去做，不是签个采购合同就能到位的东西。很多团队「上了 AI 却没效果」，卡的就是这一步——钱花了，路没修。

五、怎么判断一套 Harness 好不好？

不需要看懂任何代码，问出下面这六个问题，答案会非常说明问题：

问题	说明 Harness 很好	说明还停留在「聊天机器人」阶段
AI 是怎么拿到代码的？	「它直接连着仓库，自己找。」	「我们复制粘贴给它。」
它写完之后，谁验证？	「它自己跑测试，跑不过自己改。」	「人肉看，看不出来就先合了。」
它能不能碰生产环境？	「不能，有明确的审批闸门。」	「……应该不能吧？」
出了问题能查吗？	「有完整记录，能回放。」	「查不到，聊天记录早没了。」
团队约定它知道吗？	「写在仓库里，每次自动带上。」	「每个人自己在提示词里重复一遍。」
换个人来还能用吗？	「能，配置都在仓库里。」	「只有小张会用，他有一套自己的话术。」

最后一行尤其关键。

如果 AI 的效果高度依赖某一两个「会念咒」的人，那说明手里握着的是个人技巧，不是组织能力。个人技巧会随着人员流动一起蒸发，组织能力不会。

Harness Engineering 的本质，就是把个人技巧沉淀成团队资产。

六、想做好，从这几件事开始

这几件事按投入产出比排序，第一件通常半小时就能做完，收益却能持续几个月。

1. 给项目写一份「说明书」文件

在仓库根目录放一份专门给 AI 看的说明（比如 CLAUDE.md、AGENTS.md，或者 README 里专门一段），写清楚：怎么编译、怎么跑测试、有哪些不能碰的禁区、团队的约定是什么。

这一步等于把「每次都要口头解释一遍」的东西固化下来，同时也就解决了上面那个「换个人来还能不能用」的问题。

2. 先把测试跑通

让 AI 能用一条命令跑起测试，就等于帮它把灯打开。哪怕只有几个最基本的冒烟测试，效果都远好过没有。

如果项目现在连测试都跑不起来，那这就是所有工作里最该先做的一件——不是为了 AI，本来也该做。

3. 一次只给一件事

不要说「把整个模块重构一下」。说「把 OrderService 里的这 3 个方法改成异步，保证现有测试全过」。

边界越清晰，Harness 能塞给它的资料就越准，它跑偏的概率就越低。

4. 检查它的「过程」，不要只检查「结论」

它说「已修复」不算数。要看它跑没跑测试、改了哪些文件、有没有绕过什么。这是新时代最值钱的一项技能：审阅比生产更重要。

5. 先建护栏，再放权限

顺序不能反。在还没搞清楚「哪些操作不可逆」之前就把权限全开，等于给新人配了公章还不做审批。

6. 别指望一次问对，要建立回声

与其反复琢磨怎么把提示词写得完美，不如花同样的时间去搭一条「它能立刻知道自己错没错」的通路。前者是技巧，后者是工程；技巧带不走，工程能沉淀。

七、四个常见误区

误区 1：换个更强的模型就好了

前面说过了。在 Harness 缺失的情况下，更强的模型只会更自信地给你一个跑不起来的答案。

误区 2：上下文塞得越多越好

不对。塞进去 50 个文件，真正相关的只有 2 个，模型的注意力会被稀释，反而更容易跑偏。

类比：你问同事一个问题，他甩给你一份 800 页的手册说「都在里面」。这不叫帮忙。

Harness Engineering 里很大一部分工作，是做减法——精准挑出该给的那几份材料。

误区 3：越自动越好，最好完全不用人管

在护栏还没建好之前追求全自动，风险不是「效率低」，而是「出事的时候没有刹车」。放权是个渐进过程，不是开关。

误区 4：搭一次就一劳永逸

Harness 是活的。工具会变、规范会变、模型会升级。它更像 CI/CD 流水线——需要持续维护，而不是一个一次性项目。

总结

• Harness 是模型之外的那一整圈东西：工具、上下文、记忆、护栏、反馈回路、可观测性。
• 模型是发动机，Harness 是整车。 光有发动机运不了货。
• 六块里最被低估的是反馈回路：让 AI 听得见自己犯错的回声，是从「玩具」跨到「生产力」的关键一步。
• 判断做得好不好，最简单的一个标准是：换个人来，还能不能用？
• 起步最划算的三件事：写好项目说明书、把测试跑通、先建护栏再放权限。

搭好了 Harness，下一个问题自然就来了：既然它能自己动手、自己验证，那我们能不能干脆把整件事情交给它？

这就是下一篇要聊的话题——什么是 Agentic Engineering