别再纠结怎么写Prompt了，真正要造的是那条轨道
先说句扎心的话
最近OpenAI发了一篇叫《Harness Engineering》的文章，讲他们怎么用Codex搭了一个几乎全自动生成的仓库。我看完第一反应是：终于有人把这件事说透了。
说透的是什么？是大多数团队现在用AI写代码的姿势，根本就是错的。
你观察一下身边，大部分团队用Cursor、用Codex、用Claude Code，忙的事情是什么？是研究“怎么把Prompt写得更漂亮”，是收集“最佳Prompt模板”，是在群里转发“一句话让Claude写出满分代码”。我不是说这些没用，但你要明白一件事：这是在折腾工具的表面，不是在造系统。
OpenAI那篇文章里有句话说得很实在：他们最早踩坑，不是因为Codex不够强，而是因为环境定义得不够清楚。后来每次失败，他们问的不是“怎么再试一次”，而是“到底缺了什么能力，怎么把它做成agent能理解、能被强制执行的东西”。
差距就在这里。一个把AI当打字员的团队，和一个把AI当工人的团队，用的根本不是同一套心智模型。
我见过一个特别典型的失败案例。某个中等规模的团队，上了Cursor半年，产出的代码量翻了三倍。老板很开心，工程师也很开心。然后线上事故开始密集爆发，每周一次、每周两次、每周三次。复盘的时候发现，大部分事故的根因都不是agent生成了错的代码——代码本身单独看都挺工整的——而是agent把某个旧的、本来就有问题的模式复制扩散到了整个代码库。以前这个模式只在两三处出现，老司机知道绕着走；现在agent“学”会了这个模式，把它复制到了几十个地方，连带几十个地方一起出问题。
这个团队的问题不在于agent不够强，也不在于工程师不够资深，而在于他们没有把“这种模式不能再用了”这件事，固化成agent能感知、能被强制纠偏的机制。换句话说，他们没有harness。
搞清楚你到底在做什么
我看很多人聊AI编程，聊的都是下游的细节：哪个模型强、哪个IDE好用、哪个上下文工程技巧最新。这些都是战术问题。战术问题解决不了战略问题。
战略问题是什么？是当agent成为主要执行者之后，工程师的工作性质已经变了。
以前你的主产出是代码。一天能敲多少行有效代码，大致决定了你的价值。现在不是了。现在的主产出是约束、是反馈、是让下一次执行更正确的那套环境。OpenAI干脆把这个叫做“Harness Engineering”——驾驭工程。
Harness这个词翻译得有点拗口，但意思不复杂。你可以把它理解成马的缰绳、理解成货运的轨道、理解成流水线的夹具。它强调的不是那匹马有多快，而是那匹马必须跑在你设定的方向上、不能把你摔下来、跑完之后还能让下一匹马继续跑。
说白了，harness engineering就这一件事：把原本只存在于你脑子里的经验、边界、品味和验收标准，变成agent能看见、能执行、能被验证、能被沉淀的系统能力。
你品品这句话。过去我们说“老司机带新人”，靠的是口口相传、靠的是review里被骂几次就记住了、靠的是在Slack里翻一翻。这些套路在agent面前全部失效。为什么？因为agent没有记忆，没有面子，没有“上次被你骂过所以这次小心点”。它每一次都是新人。你想让它稳定产出，就必须把所有隐性规矩显性化。
这事儿以前也该做，只是过去你偷懒也能蒙混过关，因为人脑会帮你兜底。现在兜不住了。
再打个比方。你以前是老师傅，带三五个徒弟。徒弟犯错你骂一顿，骂完徒弟记住了，下次少犯。这种模式下，你的经验是靠“骂”在传递的，慢，但有效，因为徒弟会学。现在不是这样了，现在你面对的是无限多个刚上班的新人，每一个都不认识你、每一个都没被你骂过、每一个都得从头来。靠骂是传递不了经验的。你只能把经验做成“这里有道墙，撞上来自动弹回去”的东西。撞一百次还是弹回去，不需要你在场。这就是harness engineering和“写代码”的根本区别。
几件你必须做的脏活
我按OpenAI的实践，加上我自己的理解，把harness engineering拆成四件脏活。之所以叫脏活，是因为它们都不光鲜，不性感，不能发朋友圈秀，但没有这四样，你那些Prompt再漂亮都白搭。
第一件脏活：把约束做成可执行的东西，而不是一份文档。
OpenAI一开始也犯了个很常见的错误——写一份巨长的AGENTS.md，把所有规则都塞进去。结果呢？上下文被挤爆、内容迅速腐化、也没人能校验这份文档是不是还有效。后来他们改了路子：AGENTS.md只做目录，规则拆到docs/的结构化文档里，真正生效的是linter、CI和结构性测试。
这个转变非常重要。你要搞明白：文档不是约束，能阻止违反的才是约束。
一条“不要直接调数据库”的注释，和一个“调数据库就CI挂掉”的规则，不是一回事。前者是建议，后者才是约束。前者是给人看的，后者是agent一碰就知道痛的。
我见过太多团队搞AI编程搞不起来，根子就是这里。他们写了一堆“规范”，贴在Confluence上，agent当然视而不见——因为那根本不是系统能读懂的东西。
你要问自己一个问题：这条规则，如果违反了，谁会最先发现？ 如果答案是“靠review的人去看”，那它就不是约束；如果答案是“CI会挂、测试会红、linter会报”，那它才是约束。这两者的差别在于，前者依赖于注意力，后者依赖于系统。注意力会分心、会疲劳、会离职，系统不会。
更进一步说，一条活的约束至少要满足三件事：agent在生成代码之前能读到它、agent在生成代码之后能被它拦住、人看到失败信号之后能知道这条规则是什么意思。缺任何一条，这条约束都不算数。
第二件脏活：把验证路径设计得让agent自己能走完。
OpenAI这篇文章里另一个关键点是：他们把原本主要给人看的UI、日志、指标、trace，全都接到了agent能直接消费的地方。Codex能自己复现bug、自己验证修复、自己检查性能目标。
这其实就是反工业化的反面。过去工业化的反面是什么？是所有验证都要人来做。agent生成一段代码，扔给你，你跑一下、看一下、点几个链接、打开几个面板，然后判断行不行。这个流程的瓶颈永远是你。
真正的工业化，是把“行不行”这件事也交给系统去答。测试能跑、指标能读、日志能解析、性能能自动对比——所有这些，都是让agent在没有人盯着的时候也能自我验证。
你要学的一件事是：凡是只能靠人眼判断的环节，都是瓶颈；凡是瓶颈，都会被agent的吞吐反向压垮。
这条经验我个人踩过两次。一次是性能回归——以前性能好坏都是凭我跑一跑感觉一下，agent大规模上线之后，改动频率从一天几次变成一小时几十次，我再也跑不过来了。第二次是接口契约——以前我review时候能看出来“这里return的字段名不对”，现在根本看不过来，必须把接口schema做成CI强制校验。每一次瓶颈被暴露，都逼着我把一段判断力从脑子里搬进系统里。搬完之后才发现，原来这些判断力一直都值得被显性化，只是过去人肉凑合就过去了而已。
第三件脏活：把反馈回路建在重复问题爆发之前。
很多人对“反馈”的理解太浅了，以为就是给agent看错误日志。不对。反馈的本质是：偏差能被尽早发现，发现之后能被压回正确的轨道。
这里面分两层。第一层是实时反馈——测试挂了、静态分析挂了、structural check挂了，agent立刻知道。第二层是趋势反馈——某类问题是不是在反复出现？某个模块的技术债是不是在积累？某种写法是不是正在被错误地复制？
OpenAI的做法是搞“后台Codex任务”，定期扫描偏差、更新质量评分、直接发起针对性的重构PR。这就是典型的趋势反馈。它承认了一件事：全agent代码库一定会复制模式——好模式会被复制，坏模式也会被复制，熵一定会增加。
你如果指望靠每周五“大扫除”清理AI slop，那是靠资深工程师的英雄主义。这个办法一定不可持续。团队一扩大、项目一增多、资深工程师一休假，你就完蛋。
收垃圾必须是系统能力，不是人肉能力。记住这句话。
第四件脏活：把每一次经验沉淀成下次不用再交学费的资产。
这是最容易被忽视的一层，但可能是杠杆最高的一层。
你想想看，一个成熟工程师值钱在哪里？值钱在他踩过的坑。这些坑在他脑子里，离职了就带走了，招个新人要重新再踩一遍。agent时代放大了这个问题——因为agent比新人更“新”，它每次都是零经验上岗。
所以沉淀是个必答题。具体怎么做？一次问题解决之后，别只修这一次的bug，你要追问一句：这属于约束没做好、验证没做好、反馈没做好，还是沉淀没做好？然后强迫自己至少补一项资产——一份模板、一条CI规则、一个脚本、一个structural test、一个golden principle。
哪怕很小，只要它能让同一个坑下次不用再踩，就值得做。
沉淀还有一个被严重低估的价值——它能决定你的知识是属于个人还是属于组织。个人的知识，你一走就没了；组织的知识，存进系统里，下一个人来了立马能用。以前我们说“把自己做成不可替代的人”，其实是一种反组织效率的策略；在agent时代，更稀缺的是“能把知识沉淀成可复用资产的人”。这种人走到哪里，团队的整体能力都会涨一截。这种人，才是真正值钱的。
一个特别反直觉的观察
OpenAI那篇文章里有句话特别扎眼：他们的仓库首先是为Codex的可理解性而优化的。
注意这个表述。不是“可读”，不是“可维护”，是“Codex可理解”。
这背后的逻辑非常狠：以前我们写代码是给人看的，顺便机器也能跑；以后我们写代码是给agent读的，顺便人也能看懂。
你要反应过来这件事的含义。今天大部分团队的知识，都散落在Google Docs里、Slack对话里、会议纪要里、某个资深工程师的脑子里。这些地方agent看不见。
结果是什么？结果是agent的表现上限，直接被你“知识外泄”的程度卡住了。你有多少隐性知识没进到repo里，agent就差多少理解力。
我给你一个判断标准：知识是否是repo-local的、versioned的、discoverable的，决定了agent的表现天花板。
以后招工程师，你该问的问题不只是“你会写什么”，还要问“你会把什么固化进系统里”。前者是个人能力，后者是组织能力——后者才是AI时代真正稀缺的。
顺着这个逻辑往下想，你会发现连技术设计文档都得重写。以前的设计文档写得再华丽都没关系，反正是写给人看的，看不懂还可以找作者问。现在不行了，设计文档是agent读的，它不会找你问，它只会根据文档生成代码。所以那种纯解释性的长段落、那种“这里为了保持灵活性我们做了一些权衡”的模糊话术，agent消化不了。
agent需要的是什么？是目标和非目标、是模块边界、是依赖方向、是不变量、是数据边界、是验证路径、是观测点、是回滚策略，以及那句最关键的——哪些写法虽然能跑但不希望以后被复制。这是operational document，不是essay。文档的形态也必须跟着工程范式一起改。
判断力才是真正的稀缺资源
我再展开说一件事，OpenAI那篇文章里有个观察非常尖锐：他们发现瓶颈已经不是“有没有人能把代码写出来”，而是“有没有足够的人类注意力做QA、裁决和判断”。
这句话值得反复咀嚼。
过去的工程瓶颈在什么地方？在代码产能。一个团队能养活多大的系统，大致取决于这个团队一天能产出多少有效代码。所以我们做架构、做分工、做流程，核心目标都是“让更多的代码能被更快地写出来并且还不出事”。
现在代码产能这个瓶颈被agent打破了。你想要多少代码就有多少代码。新的瓶颈变成了什么？变成了判断力。谁来判断这段代码要不要合、这个设计对不对、这个改动会不会踩线、这个权衡在当前业务环境下是不是合理？
判断力是稀缺资源。稀缺资源必须被精细配置。
这就解释了为什么harness engineering会成为核心——因为它本质上是在做“判断力的预置和规模化”。你把一次判断做好了、固化成约束、固化成验证、固化成反馈，那下次一万次类似的场景都不需要你再判断一次。你的判断力被复用了一万倍。这就是杠杆。
反过来，如果你不做这件事，你的判断力就是一次性的。agent吞吐翻十倍，你的判断力就会被稀释十倍。稀释的结果就是你要么熬死自己，要么放弃把关——哪种结果都不好看。
所以我经常跟团队说一句话：在AI时代，“做了什么事”越来越不值钱，“把这件事变成系统以后就不用再做了”才值钱。 一次性劳动是耗品，可复用判断力是资产。你得想清楚自己在积累哪一种。
工程流程也得重写
这件事还有一个衍生结论——而且这个结论可能会让一些老派的人不舒服——吞吐量变化会反过来改写工程流程。
OpenAI那篇文章提到：他们的仓库采用更少的阻塞式merge gate、更短命的PR、用后续agent run修复flaky test。这些做法放在十年前，任何一个资深架构师都会拍桌子——这不是乱来吗？
但你仔细想想就明白了。过去流程之所以严格，是因为“修正很贵”——回滚成本高、重构成本高、找人复盘成本高。所以你要在PR阶段把一切堵住。
现在呢？修正变得很便宜。agent可以连夜跑、可以自动重构、可以批量改。贵的变成了“等待”——你堵在那里等review的每一分钟，都是在浪费agent的带宽。
流程不是神圣不可变的，流程应该服务于新的成本结构。
我不是说所有团队都该照搬这一套。OpenAI自己也强调，这依赖于他们特定的仓库结构、投入和纪律。但这个原则值得刻在脑子里：当下游的成本结构变了，上游的流程必须跟着变。
那些死守“每个PR都必须两人review、必须跑完所有测试才能合”的团队，不是在守质量，是在守习惯。守习惯的成本，未来会变成看不见的竞争差距。
最后的警告
说两句掏心窝子的话。
第一句：harness engineering不是coding的边角料，是在重新定义什么叫工程能力。
未来更稀缺的工程师，未必是手写代码最多的那个，而是最会设计“约束、验证、反馈、沉淀”这套系统的那个。他知道什么必须前置写清，他知道怎样让正确性可证明，他知道怎样让偏差尽早被发现，他知道怎样把一次经验固化成长期资产。
这种能力不是写Prompt能练出来的，是你一个项目一个项目踩过来、一次闭环一次闭环补出来的。
第二句：别再指望靠人肉兜底了。
agent吞吐上升以后，任何“靠资深工程师最后把关”的流程都会崩。你必须承认：纪律这件事，未来体现在scaffolding、tooling、abstractions和feedback loops里，而不是体现在某个具体的人有多靠谱。
你能不能活下来，取决于你能不能把自己从系统的关键路径上挪开，变成系统的设计者而不是瓶颈。
这事儿没有捷径。想明白了就开始做，做出一个闭环是一个闭环。别再在Prompt花招上浪费时间了，那条路走不通。
临了再啰嗦一句给那些团队负责人听。你们现在最该关心的不是“我们团队的AI编程渗透率是多少”，也不是“我们引入了哪些大模型”，而是“我们把多少判断力沉淀到了系统里”。前两个指标可以一夜暴涨，也可以一夜归零；最后那个指标是慢变量，是长期护城河，是未来决定组织效率的关键。
盯住慢变量，别被快变量骗了。这是我混了这么多年工程圈最大的体会。