我们怎么"学会用好 AI"？

前段时间 ，OpenAI 的一篇博文让技术圈沉默了几秒。

一组数据写在那里：3 个工程师，5 个月，100 万行生产级代码——零行是人手写的。

完成同等体量的工作，市面上至少需要 30 人的工程团队，光人力成本一年就是几百万。这 3 个人，省掉了 27 个人的工资，还把交付周期砍掉了 80%。

这 3 个人没用什么秘密模型。他们用的 AI，你我都能用。

那他们做对了什么？

答案只有一句话：他们不写代码，他们设计让 Agent 写代码的环境。

这个方法有个正式的名字，叫 Harness Engineering。

你大概有过这种体验

问它一个问题它可以头头是道，让它写一个函数几秒钟就搞定。

但如果你想让 Agent 做更复杂的事情，比如独立完成一个完整功能，或者一步到位生成一份高品质内容……

做出来的东西似是而非——结构混乱，细节悬空，关键环节缺失。

这是 AI 能力不行吗？

不是。OpenAI 那 3 个人用的是同款模型。Stripe 用同款 Claude，每周自动完成 1,300 多个代码合并。模型是一样的，差别在于会不会用。

三个时代，我们怎么"学会用好 AI"

回头看过去两年，人们学会使用 AI 的过程，经历了三个阶段。

▍2024 年：提示工程时代

大家发现问法很重要。把问题措辞得好，回答质量明显更高。整个互动是"一问一答"的模式，我们在乎的是那一次回复的质量。

▍2025 年：上下文工程时代

光靠一次好提示不够了。在 Agent 运行前先给它"喂"相关资料和背景信息，质量明显提升。这个阶段能搞定大纲策划、知识问答、头脑风暞……但要独立完成一个完整的高品质任务？还是做不到。

▍2026 年：Harness Engineering 时代

工程师们不约而同发现了同一件事——给 Agent 创建一个适合运行的环境，比优化单次提示或者喂更多资料，更能让它完成复杂任务。

这个"环境"包括：告诉 Agent 这是什么项目、在哪些地方不许犯错、每一步做完之后怎么验证结果、多个 Agent 怎么互相检查。

这就是 Harness Engineering。

有一个类比很好理解这层关系：

没有操作系统，CPU 也能算——但你没法在裸机上跑任何稳定的应用。Harness 之于 AI Agent，就是操作系统之于 CPU。

四根支柱，撑起"生产级 Agent"

Harness Engineering 的核心，可以提炼为四根支柱。每一根都对应一个你真实遇到过的问题。

支柱一：给 Agent 一张"项目地图"

每次开启新的 AI 会话，都得重新解释一遍"我这个项目用的是什么技术、哪些文件不能动、测试怎么跑"？

Harness Engineering 的解法是：把这些信息写成一份配置文件，放在项目目录下，Agent 每次启动自动读取。

在 Anthropic 体系里叫 CLAUDE.md，在 OpenAI 体系里叫 AGENTS.md。你可以理解为"写给 AI 看的项目说明书"。

OpenAI 的实践教训：超过 100 行反而让 Agent 迷失，不知道哪条和当前任务有关。正确做法是 100 行以内的导航地图，指向详细文档的存放位置，Agent 按需跳转查阅。

更重要的是，这份文件不是一次性写完就束之高阁的。Harness Engineering 命名者 Mitchell Hashimoto（HashiCorp 联合创始人）分享过一条经验——他的配置文件里，"每一行规则都对应过去一个真实的 Agent 犯错"。

Agent 犯错 → 分析原因 → 写成规则 → 加入配置文件 → 下次永不再犯

这是一种越用越聪明的增量式积累。

支柱二：用规则约束 Agent，而不是靠它"自觉"

很多人在配置文件里写"不要执行删除整个文件夹的命令"——有用，但效果是"建议"级别的。Agent 大概率会遵守，但"大概率"在安全性面前是不够的。

Harness Engineering 的解法叫 Hooks（钩子）：在 Agent 执行某个操作的前后，自动触发一段检查程序。通过就放行，不通过就直接拦截——Agent 没有"忽略"的余地。

CLAUDE.md 是建议，Hooks 是法律。 这句话是 Harness Engineering 里流传最广的一句话。

更有意思的是，高级的 Hooks 可以调用另一个 AI 来做检查——用 AI 约束 AI。普通关键词检查发现不了"看起来正常但实际上会造成数据泄露的日志语句"，但专门做安全审查的 AI 可以从语义层面识别这类风险。

还有一个反直觉的结论：越多约束，Agent 反而做得越好。 明确限定技术栈、命名规范、调用路径，Agent 在这个收窄的范围内反而更容易找到正确答案。约束不是限制创造力，而是把创造力引到有价值的方向。

支柱三：让 Agent 知道"做得对不对"

Agent 在黑暗中工作是危险的。它不知道这一步做得对不对、下一步该怎么调整。

Harness Engineering 的解法是设计反馈循环——每个阶段的产出，都要有验证机制。

可以很简单：代码写完自动跑测试、文件修改后自动做格式检查。也可以很复杂：专门部署一个独立的"评审 Agent"，从批评者的角度对产出发起质疑，推动迭代改进。

Anthropic 用受 GAN（生成对抗网络——让两个模型互相博弈来提升质量的技术）启发的三 Agent 架构开发了一款小游戏，结果如下：

时间和成本高了一个量级，但产出从 demo 变成了产品。

支柱四：主动清理 Agent 制造的"技术债"

Agent 写的代码多了，代码库会越来越乱——临时的变量名、重复的函数、被遗弃的试验性代码。这叫技术债（可以理解为：为了赶进度埋下的"以后再清理"的混乱，积累越多越难维护）。

OpenAI 的解法是：让 Agent 定期充当"清洁工"，专门扫描代码库里的低质量产出，按照预先设定的质量标准自动清理。更精妙的是，他们把团队的"代码品味"编码成了自动检查规则，每一次 Agent 提交代码都会被自动校验。

品味捕获一次，强制执行无限次。

这个，你能学吗？

很多人看到这里会问：这是不是只有大厂工程师才玩得转的东西？

不是。

从最小可行的 Harness 开始，你只需要做两件事：

① 建一个 CLAUDE.md 文件 写上"这个项目是做什么的、用什么技术、哪些文件不能动、怎么跑测试"——5 分钟的投入，能避免 90% 的低级重复错误。

② 遇到 Agent 犯错，把规则写进去 不要只是重新提示——分析一下为什么犯错，把规则写进配置文件，让这个错误永远不再发生。

这就是 Harness Engineering 的最小实践单元。复杂的 Hooks、多 Agent 协作、GAN 式架构，那是进阶内容——先把基础的做稳，已经能甩开大多数人。

你不需要先学会编程再学这个。 Harness Engineering 的核心是"设计 Agent 的工作环境"，这是一种工程思维，不是具体的代码语法。懂 AI 工具怎么用、懂任务拆解、懂验证结果——这些比会写代码更重要。

Harness Engineering 的价值不只在 AI 编程——它是让任何 AI Agent 从"玩具级问答"进化到"生产级产出"的通用方法论。