别再卷提示词了！决定 AI 写代码成败的，其实是 Harness

你好，我是郭震！

最近我用 AI 写代码越来越多，感受也越来越明显：AI 不是不能写代码，而是很容易在真实项目里“写偏”。

一个简单页面、一个小接口，它可能很快搞定；但只要任务稍微复杂一点，比如牵涉多个文件、历史代码、测试命令、业务边界，它就开始不稳。

我之前也踩过这个坑。

所以今天这篇，我想重新把 Harness 这个概念讲清楚。

1 AI 写代码为什么总翻车

很多人第一反应是：是不是模型不够强？

当然，模型能力会影响结果，但我越来越觉得，很多翻车并不是模型问题，而是任务环境太松。

比如你只说“帮我优化一下登录页”。这句话对人来说还能靠经验补全，但对 AI 来说，里面有一堆空白：优化什么？只改样式还是改逻辑？

这些空白如果不提前固定，AI 就会开始猜。

如下图所示，一张图看懂 AI 写代码最常见的 6 个翻车原因：

所以我现在看 AI 编程，已经不只看“模型会不会写”，更看“有没有一套东西限制它怎么写”。这套东西，就是 Harness。

2 Harness 到底是什么

一句话理解：Harness 不是提示词，而是 AI 编程的工程夹具。

提示词像是开场白，告诉 AI 你要做什么；Harness 更像工作台，把需求、上下文、工具、验证、复盘这些东西固定住。

它的目标不是让 AI 输出更漂亮，而是让 AI 的行为更可控。

如下图所示，一张卡片看懂 Harness 到底固定了什么：

这五层不用背概念，按实际工作理解就行。

任务层负责说清楚目标和边界；

上下文层负责告诉 AI 该看哪些文件；

工具层负责固定读、搜、测、改这些动作；

验证层负责判断能不能交付；

记忆层负责把失败经验变成下次的模板。

如下图所示，这是 AI 编程 Harness 的五层架构：

3 从零怎么搭第一版

如果你是第一次做，不要一上来就搞平台。第一版越简单越好，先放一个 AI-HARNESS.md 就够了。

里面先写 5 件事：项目怎么启动，核心目录在哪里，哪些文件不能乱动，常用测试命令是什么，每类任务怎么验收。

如下图所示：

我建议第一版这样写：

项目入口：启动、构建、测试命令 
仓库地图：核心目录、关键模块、常用入口 
权限边界：允许修改什么，禁止修改什么 
验证方式：每类任务必须跑哪些检查 
交付格式：变更摘要、验证结果、剩余风险 
失败记录：AI 过去容易犯错的地方

这份文档不用长，但一定要真实。

4 一个任务怎么跑

我现在比较推荐的节奏是：先写任务卡，再补上下文，然后让 AI 小步修改，接着跑验证，最后人工 Review 和复盘。

重点是“小步”。不要让 AI 一次改十几个文件，尤其不要让它顺手重构。一次只解决一个明确问题，改完马上验证。这样即使错了，也能很快知道错在哪里。

如下图所示，这是一个任务从需求到交付的完整闭环：

如果验证失败，也不要急着让 AI “重新写一遍”。更好的做法是问：失败暴露了 Harness 哪一块没写清楚？是上下文缺文件，还是权限边界没说？

最后总结一下

AI 写代码总翻车，不一定是模型不行。很多时候，是我们只给了它一个需求，却没有给它一套工程环境。

Harness 的价值就在这里：它让 AI 少猜一点，让人少返工一点，让代码改动更容易验证。对个人来说，它能让 AI 编程从抽卡变成流程。

一句话总结：提示词决定 AI 怎么开始，Harness 决定 AI 能不能交付。

全文约 1635 字，5 图，如果你觉得这篇文章对你有帮助，也欢迎给我一个三连点击：点赞、转发和在看；如果可以，再帮我点一个星标。谢谢你看到这里，我们下篇再见。