Prompt Engineering 已死？Harness Engineering 才值钱
- 作者：Bougie
- 创建于：2026-06-24
- 更新于：2026-06-24
# 一个让我彻底放弃"优化 prompt"的下午
去年年底，我花了两周时间调一个代码生成的 prompt。不是那种随便写写的 prompt，是真的认真调：试了各种角色设定、输出格式、chain-of-thought 指令、加了一堆"think step by step""你不只是一个 coder，你是 senior engineer"这类当时觉得很有道理的话术。
调出来之后效果确实好。做那个特定任务——把 Swagger 文档转成 TypeScript 类型定义——准确率从 60% 飙升到 90% 以上。我当时还挺得意的，觉得自己终于掌握了"和 AI 协作"的诀窍。
然后项目变了。我们不用 Swagger 了，改用自研的 API 描述格式。我把新格式的示例丢进 prompt，加了几条规则，心想应该问题不大。
翻车了。
准确率直接掉回 60%。不是稍微下降，是几乎回到原点。我又花了三天调 prompt，加更多示例、换措辞、加约束条件、改 system prompt……折腾一圈，效果好一点，但远没有回到之前 Swagger 那个任务的水平。
那一刻我意识到一个问题：我花了三周时间调的那个 prompt，它的"好效果"到底有多少是来自 prompt 本身，有多少是来自我给它提供的上下文——那些 Swagger 文档示例、TypeScript 类型规范、我们团队的编码约定？
我没办法确定。但我能确定的是，当上下文变了，那些我精心雕琢的 prompt 措辞几乎没有迁移能力。
从那以后我就不再痴迷调 prompt 了。不是说 prompt 完全没用，但把它当成核心竞争力来打磨，我觉得方向错了。
# OpenAI 那帮人怎么用 AI 写 100 万行代码的
让我换一个话题聊聊。我之前看到 OpenAI 发的一篇文章，讲他们怎么用 AI 工具做 Codebase 的规模化开发。他们不是靠给 AI 发一条神级 prompt，然后期待 AI 自己搞定一切。
他们做了 88 个 AGENTS.md 文件。
这个数字让我愣了几秒。88 个。想象一下，你不是写一条 prompt 让 AI 去完成任务，而是写了 88 份文档来定义不同 agent 的角色、职责、工作流程、相互关系、错误处理机制。这是 prompt 吗？某种程度上是吧——这些文件确实会被读进 context。但它更像是工程规范，是团队把"如何用 AI 协作"这件事系统化之后的产物。
他们在做的事情，本质上不是在优化 prompt 的措辞，而是在设计一套 harness——一套让 AI 稳定工作的基础设施。
我后来琢磨这件事，觉得关键区别在于：prompt 是让 AI 知道"做什么"，harness 是让 AI 知道"在什么环境里做""做到什么程度算完成""出了问题怎么回到正确状态"。这不是微调的粒度问题，是完全不同的设计思路。
后来我又看到一些关于 Anthropic 内部研究的数据——他们让 132 个工程师用 Claude Code 做日常开发任务。结论很有意思：工具、环境、工作流程的设计对 AI 辅助效果的影响，远大于 prompt 的质量差异。
换句话说，给这 132 个人一人发一条"完美 prompt"，效果提升可能远不如给他们配一套好用的 harness——lint 规则、测试框架、代码审查流程、错误恢复机制。
我自己的经验也印证了这一点。当我把精力放在设计 prompt 上的时候，效果的上限很容易碰到——因为 prompt 能传递的信息量是有限的，而且模型对 prompt 措辞的敏感度很高，不同模型还不一样。但当我去设计 harness——比如强制 AI 每次改代码都要跑对应的测试，比如让 AI 的输出格式必须符合我预先定义的 schema，比如在 CI 里加一层自动检查——效果提升是系统性的，不是一个任务好了另一个任务差。
# 我见过的 prompt 崇拜者，最后都怎么样了
我认识几个 prompt 调得很认真的人。不是那种"写几个示例就完事"的用法，是真的会把 prompt 迭代版本存档、记录每次调优的效果差异、写 prompt 设计原则文档的那种认真。
其中有一个人，我叫他老张吧。老张在 2023 年到 2024 年初的时候靠调 prompt 做了不少事情，确实出活。但他后来来找我聊，说他觉得 AI 辅助效率没有继续提升，甚至有点瓶颈了。
我问他怎么调 prompt 的。他说他的方法是：任务失败了就改 prompt，加更多约束、更多示例、更多指令。
这个思路有一个问题——prompt 不是万能的。它的容量有限，模型对长 prompt 的利用率会下降，而且当你把所有东西都塞进 prompt 的时候，prompt 本身就变成了一个难以维护的负担。
老张后来慢慢转变了，开始在 harness 上投入。他把原本放在 prompt 里的规则搬到代码里——比如 linter 规则、测试用例、类型检查。他发现 AI 的表现反而更稳定了，因为它不是在"读规则"然后"试着遵守"，而是直接在一个有约束的环境里输出，系统会自动过滤不合规的输出。
prompt 能做的，harness 能做。Harness 能做的，prompt 不一定能做。
# 为什么我认为 prompt engineering 这个概念被高估了
说一个可能会得罪人的观点：prompt engineering 这个概念，从一开始就有一点被过度神化了。
它被包装成一种"黑科技"——你需要学习技巧，掌握咒语，理解模型的"脾气"，才能让 AI 听话。这种叙事对于卖课的和搞自媒体的是好事，因为它制造了一个门槛，让你觉得"别人能写出好 prompt 是因为他们掌握了什么秘诀"。
但真相是，prompt 的作用是有限的。它本质上是一种信息传递机制：你给模型一段文字，模型基于这段文字和它的训练数据生成输出。prompt 写得再好，它能传递的信息量是有限的，模型的推理能力是有上限的，而且不同的模型对 prompt 的敏感度差异很大——你在 GPT-4 上调出来的完美 prompt，丢到 Claude 3.5 上效果可能完全不一样。
真正让 AI 可靠工作的，不是你在 prompt 里写了什么巧妙的指令，而是你在多大程度上控制了整个上下文：你给它的信息是否完整、一致、可验证？它的输出有没有被校验？它犯错的时候有没有恢复机制？它能不能访问正确的工具和数据？
这些都不是 prompt 能解决的问题。这些是 harness 要解决的问题。
Harness 是什么？我自己的定义是：任何让 AI 在特定环境中稳定、可预测工作的系统性约束。它可以是一个 CI 流程，可以是一组 lint 规则，可以是一套 agent 协作协议，可以是强制输出必须符合的 schema，可以是错误处理的 fallback 逻辑。
一个好的 harness 不会让你惊喜——它会让你觉得 AI 做事是正常的、可预期的。而 prompt 好坏的区别往往是：有时候 AI 会给你惊喜，更多时候 AI 会给你惊吓。
# 聊聊 vibe coding 这件事
插一句题外话，关于 vibe coding。
我注意到这个概念最近挺火的。简单说就是：你不用想太多代码怎么写，就用自然语言描述你想要什么，让 AI 生成，你试试，跑通就完事。
谷歌的工程负责人 Osmani 公开反对这种做法。他的观点我基本同意：从工程角度，vibe coding 会积累技术债，你可能三个月后看不懂自己写的代码，更糟的是你不知道代码里埋了多少 bug。
但我比 Osmani 更悲观一点。我觉得 vibe coding 的问题不只是技术债，还有一个更根本的问题：你没办法 scale。一个简单的任务你可以 vibe coding，两百个任务你还 vibe coding 吗？你怎么保证两百个任务生成的东西是一致的、可集成的、符合同一个架构规范的？
你需要一个 harness。
可能是一个代码生成规范文档，可能是强制 AI 遵守的编码标准，可能是自动化的代码审查流程，可能是某种 agent 协作框架。没有这些基础设施，你 vibe coding 出来的代码库会变成一盘散沙，维护成本会指数级上升。
我不是说 vibe coding 完全是错的。对于探索性的一次性任务，或者你对质量要求本来就不高的场景，它完全没问题。但如果你在做正经的工程开发，把 AI 辅助建立在 vibe coding 的基础上，长期来看是会出问题的。
# Harness Engineering 是什么感觉
我试着描述一下从 prompt 思维切换到 harness 思维之后，我的工作方式发生了哪些变化。
之前的我：拿到一个任务，先想怎么写 prompt。加示例、加指令、加约束，prompt 越写越长，测试 prompt 占了越来越大的工作量。
现在的我：拿到一个任务，先想需要什么 harness。这个任务需要 AI 输出符合什么格式？AI 的输出需要被什么系统消费？AI 出错了怎么办？怎么验证 AI 的输出是对的？
举一个具体的例子。之前我要让 AI 帮我生成 API 文档，我会花很多时间设计 prompt——怎么描述文档格式、怎么让 AI 生成示例、怎么控制生成内容的长度。但效果总是不稳定，AI 有时候会自己发挥，格式对不上预期。
后来我换了一个思路：我先定义一个 JSON schema，这个 schema 描述了文档的完整结构，字段名、类型、必填项都定死。然后我让 AI 的输出必须符合这个 schema，并且在 CI 里加了一个自动校验步骤，如果 AI 生成的 JSON schema 校验失败就打回重跑。
结果呢？prompt 变得很简单——几乎不需要描述文档格式，只需要说"生成符合这个 schema 的文档"。因为格式约束已经不在 prompt 里了，在 harness 里。prompt 只负责告诉 AI 做什么，harness 负责保证 AI 怎么做是对的。
这是 harness 思维的核心：把约束从 prompt 里搬出来，放到系统里。prompt 越简单越好，越通用越好，具体的规范应该由 harness 来强制执行。
# 我现在的做法
我不是说你完全不需要写 prompt。但我的经验法则是：prompt 只需要描述意图，harness 才需要描述约束。
意图是很通用的——"帮我重构这个函数""把这个数据转成 CSV""写一个登录页面"。这些意图用简单的自然语言描述就够了，不需要技巧，不需要 magic phrase，不需要精心雕琢的句式。
约束是很具体的——"输出必须是 TypeScript""类名必须符合 PascalCase""错误处理必须覆盖这三种情况""所有函数必须有 JSDoc"。这些约束应该写在代码里，写在 lint 规则里，写在 schema 里，而不是堆在 prompt 里。
当我按照这个原则工作，我发现几件事：
第一，prompt 不需要迭代了。以前我调一个 prompt 要花好几天，现在我几乎不改 prompt——改了效果也不一定好，问题往往不在 prompt 上。
第二，AI 的输出更稳定了。因为约束是系统强制的，不是靠 prompt 指令让 AI 自觉遵守的，系统不会因为模型心情不好就跳过检查。
第三，切换任务、切换模型的时候，改动成本低了很多。prompt 是通用的，harness 是定制的——换模型只需要确认 harness 还生效，不需要重新调 prompt。
当然，harness Engineering 也是有成本的。你需要花时间设计 harness，需要维护它，需要在它失效的时候修复它。但这个成本是值得的，因为它解决的是系统性问题，而不是个案问题。
# 写在最后
Prompt Engineering 这个概念这几年很热，我理解为什么。它简单、好教、能讲出很多"技巧"和"秘诀"。但如果你认真用 AI 工具做过工程开发，你会发现 prompt 能解决的问题很有限，真正让你事倍功半的往往不是 prompt 的质量，而是整个系统设计。
Harness Engineering 更像是传统软件工程的延伸。它不性感，没有 prompt 技巧那么多可以炫耀的东西，但它解决的是真实问题。
我不是来教你怎么做的。我只是把这两年的观察和感受写出来，你自己判断有没有道理。
如果你现在花很多时间调 prompt，建议你想一想：你在调的是什么？是 prompt 还是 harness？如果是 harness 没做好，你可能永远在调 prompt 的路上。