Harness Engineering 入门指南：让 AI 稳定干活

大模型已经很会写代码了，但真正用起来以后，很多人会遇到一个尴尬问题：它能很快生成一大堆东西，却不一定稳定、可维护、符合项目约定。

第一次看起来很惊艳，第二次开始风格漂移，第三次改坏旧逻辑，第四次你发现自己在给 AI 生成的代码收拾现场。于是效率提升没有想象中那么大，问题从“我写代码慢”变成了“我审 AI 代码很累”。

Harness Engineering 要解决的就是这个问题。

它不是一个新框架，也不是某个插件，而是一种使用 AI Agent 的工程方法：人不再只是一行行写代码，而是设计环境、规则、工具和反馈回路，让 AI 在清楚边界里稳定做事。

一句话概括：

传统开发：人写代码，机器执行代码。
Harness Engineering：人设计规则和检查，AI 执行任务，工具验证结果。

这里的 Harness 可以理解成“安全绳”“缰绳”或“控制系统”。AI 很有力，但它需要路线、边界、检查点和人的最终判断。

为什么不能只靠提示词

很多人使用 AI 编程的第一阶段是提示词驱动：

帮我写一个登录接口。
帮我改一下这个 bug。
帮我重构这个文件。

这种方式适合小任务，但进入真实项目以后，很快会暴露几个问题。

第一，AI 看不到隐性知识。团队约定、历史决策、架构边界、踩坑经验，如果只存在于聊天记录、会议纪要或人的脑子里，对 AI 来说就等于不存在。它只能猜。

第二，AI 会模仿项目里的坏味道。如果仓库里已经有重复逻辑、混乱分层、随手打印日志、随意命名，AI 很可能把这些当成“本项目风格”继续复制。

第三，AI 生成越快，评审压力越大。编码速度上去了，但测试、检查、集成和产品验收没有同步升级，瓶颈就会转移到人身上。

第四，口头提醒不可靠。你可以反复告诉 AI“不要跨层调用数据库”，但它可能这次记住，下次忘记。真正可靠的是会自动失败的规则：测试失败、lint 失败、类型检查失败、构建失败。

Harness Engineering 的目标，就是把这些不稳定因素收进一个可管理的系统里：

隐性知识 -> 版本化文档
口头约定 -> 可执行检查
一次性提示 -> 可复用规则
人工盯梢 -> 自动反馈回路
随机生成 -> 受控交付

一个最小 Harness 长什么样

不用一上来就搭复杂平台。一个个人项目的最小 Harness，可以只有四样东西。

1. 一个 AGENTS.md

AGENTS.md 是写给 AI Agent 的项目说明书。它不需要很长，但要回答几个关键问题：

# AGENTS.md

## 项目是什么
这是一个 Zola 博客，文章在 content/articles/，主题在 themes/simple-pure/。

## 修改原则
- 不要编辑 public/，那是生成目录。
- 内容修改后运行 zola build。
- 主题修改要检查首页、文章页和归档页。

## 风格
- Markdown 标题清楚。
- TOML front matter 保持现有格式。
- 小改动优先，不做无关重构。

这类文件的价值是：你不用每次重新解释项目。下一次 AI 进来，先读规则，再动手。

2. 清楚的任务

不要只对 AI 说：

帮我优化一下博客。

更好的写法是：

目标：把 AI 分类下的 Harness Engineering 系列文章合并成一篇。

要求：
- 保留一个入口文章。
- 删除其它分篇，避免文章列表被刷屏。
- 新文章要让技术小白也能看懂。
- 修改后运行 zola build。

任务越清楚，AI 越不容易跑偏。重点不是写很长的提示词，而是把目标、范围和验收标准写明白。

3. 能自动失败的检查

文档只能提醒，检查才能约束。

比如博客项目至少可以有：

zola build
zola check

代码项目可以有：

npm test
npm run lint
cargo test
go test ./...

这些命令的意义不是证明 AI 很聪明，而是给 AI 一个清楚的反馈：哪里错了，错到什么程度，改完以后有没有恢复。

如果 AI 总是犯同一种错，不要只在聊天里提醒。更有效的做法是把错误变成检查脚本、测试用例或 lint 规则。下一次它再犯，机器会直接告诉它失败。

4. 简短的决策记录

真实项目里有很多“不这么做是有原因的”。

例如：

# 决策记录：不编辑 public/

public/ 是 Zola 构建产物。
源文件在 content/、templates/ 和 static/。
如果直接改 public/，下一次 zola build 会覆盖这些修改。

这类记录很短，但能防止 AI 把历史坑再踩一遍。对个人开发者来说，它也是写给几天后的自己看的。

为什么 AI 会把项目越写越乱

AI 很擅长模仿。如果项目里好模式很多，它会模仿好模式；如果坏模式很多，它也会照着坏模式继续写。

这就是 AI 时代的熵管理问题。

熵可以简单理解成混乱度。一个项目刚开始通常很清楚：文件少、规则少、每个人都知道怎么改。后来功能越来越多，重复逻辑、临时补丁、过期文档、半成品脚本慢慢堆起来，项目就变乱了。

AI 会让这个过程变快。过去一个坏写法可能只被人复制一两次；现在 Agent 一次任务就可能在十个文件里复制它。

所以使用 AI 编程时，要定期做三件事：

• 删掉过期文档和废弃代码。
• 把重复出现的规则写进 AGENTS.md 或项目文档。
• 把重复出现的错误变成测试、lint 或检查脚本。

不要等“以后有空再整理”。AI 写得越快，整理越要靠近发生现场。

反馈回路比提示词更重要

很多人使用 AI 的方式是：

我说一句，AI 做一次。
做错了，我再说一句。

这能用，但不稳定。更好的方式是让 AI 进入一个反馈回路：

读任务 -> 修改 -> 运行检查 -> 读错误 -> 修复 -> 再检查 -> 人类验收

这里最关键的是运行检查和读取错误。AI 不需要靠猜来知道哪里错了，工具会告诉它。

这也是 Ralph Loop 这类 Agent 编排实验想表达的东西：不是让 AI 无限自由发挥，而是让它在一个循环系统里持续前进。每一步都有任务、工具、结果和停止条件。

普通人不一定需要自己写一个 Ralph Loop。你只要在每次任务里要求：

改完以后运行项目检查。
如果检查失败，先根据错误信息修复。
最后告诉我改了什么、检查结果是什么。

这已经是一个很轻量的 Harness。

Harness 不只适合写代码

Harness Engineering 的本质不是“让 AI 写代码”，而是“让 AI 在规则和反馈中完成复杂工作”。

所以它也可以用于翻译、写作、资料整理和内容生产。

比如批量翻译技术文章时，直接把原文丢给 AI，结果往往不稳定：术语前后不一致，长文容易漏段，风格忽上忽下。

更像 Harness 的做法是：

• 先写术语表。
• 再写翻译风格规则。
• 长文按章节分块。
• 每块翻译后做一致性检查。
• 最后统一审校标题、术语、引用和格式。

这和写代码的思路完全一样：人定义好结果，AI 负责执行，检查机制负责发现偏差。

它不能替人做什么

Harness Engineering 不是魔法。它能减少随机性，但不能替你决定什么是对的。

测试可以发现“按钮点了没反应”，但不一定知道“这个按钮该不该存在”。Lint 可以发现代码风格问题，但不懂产品取舍。AI 可以提出很多方案，但哪一个适合当前用户、当前预算、当前团队，仍然要人判断。

所以人的角色不是消失，而是上移：

• 少做重复输入。
• 多定义目标和边界。
• 少盯每一行代码。
• 多设计检查和验收方式。
• 少反复口头提醒。
• 多把规则固化到项目里。

越是依赖 AI，越需要人把问题讲清楚。

一个普通人可以怎么开始

如果你只是个人开发者，或者只是想让 AI 帮你稳定做事，不需要一上来就搭复杂系统。可以从下面这个最小清单开始：

1. 在项目根目录写一个 AGENTS.md，说明项目结构、禁区、常用命令和完成标准。
2. 每次给 AI 任务时，写清楚目标、范围、不要做什么、做完怎么验证。
3. 给项目准备至少一个能跑的检查命令，例如 zola build、npm test 或 go test ./...。
4. AI 重复犯错时，不要只在聊天里提醒，把规则写进文档或变成自动检查。
5. 定期清理过期文档、重复代码和临时方案，避免 AI 继续模仿坏模式。
6. 最后由人验收方向：需求是不是对，取舍是不是合理，结果是不是值得上线。

这就是 Harness Engineering 的核心。

不是把 AI 当成神奇按钮，也不是把自己变成 AI 的监工，而是搭一个小系统：让 AI 有路可走，有规则可守，有错误可改，有人负责最后判断。

参考

• OpenAI: Harness Engineering: Harnessing Codex in an Agent-First World
• 本文由原 Harness Engineering 系列文章压缩整理而来，保留核心观点，减少博客时间线占用。