我发现AI编程时代真正稀缺的不是代码，是判断力的轨道
你肯定听说过一句话——“AI来了，程序员要失业了”。这句话火了三年，讲的人不少，信的人也不少。但真正在工程一线的人都知道，这件事比这句话复杂得多。
今天我想跟你讲一个非常有意思的故事，以及一个你听完之后可能会重新理解“工程能力”这四个字的概念。这个概念叫Harness Engineering——姑且翻译成“驾驭工程”。它来自OpenAI今年二月发的一篇技术博客，但这件事的意义远不止一家公司的内部实践。我认为，它揭示了AI时代软件工程整个学科的重心迁移。
一、先讲个有意思的故事
先说故事本身。OpenAI有一个团队，用了大约五个月的时间，搭建了一个几乎完全由Codex——就是他们内部的代码生成agent——写出来的仓库。从应用代码到测试，从CI配置到文档，从可观测性到部署脚本，整套东西基本上都是agent产出的。人呢？人不直接写代码，人负责“指挥”。
这个团队估计，他们的整体速度，大约是“人手写代码”时代的十分之一的工作量。换句话说，同样的功能量，他们用了一成的人力就搞定了。
他们在文章里甚至写了一句特别提气的话——“Humans steer. Agents execute.”——人来掌舵，agent来执行。
你第一反应可能是：哇，这是不是说AI真的可以取代程序员了？别急，故事的关键不在这里。
故事的关键在于：他们一开始搞得很烂。 真的很烂。早期agent的产出乱七八糟，Bug频出，代码风格各异，到处都是“模式复制”——agent把一段看起来还行但其实有问题的代码疯狂复制到几十个地方。团队每周五要花20%的时间专门清理agent生成的“AI slop”——就是那种看着不错、细看有问题的垃圾代码。
然后他们开始反思：为什么agent表现这么不稳定？
这里有一个非常关键的转折。他们没有把锅甩给“模型不够强”，也没有说“这活儿agent干不了”。他们问的问题是——我们到底缺了什么能力，才让agent干不好？
这个问法一换，一切都不一样了。
这里有一个非常有意思的认知切换。以前人看到AI代码写不好，第一反应是“模型不行”，觉得要换模型、要等下一代模型更强。这种思路把所有希望寄托在模型身上，工程师只是“等待升级”的旁观者。OpenAI这群人换了个问法——不是问模型行不行，是问我们给模型的环境行不行。这一问，主动权就回到了自己手上。
这是我在这篇文章里看到的最聪明的地方。它不是技术细节的聪明，是思考方式的聪明。
二、核心发现：瓶颈已经变了
OpenAI通过这个项目得出一个非常有洞察力的结论。我再给你提炼一层——
过去我们做软件工程，瓶颈主要在“写代码”。团队能多快交付、能做多大系统，基本取决于工程师能写多少行有效代码。所以我们发明了各种加速写代码的工具：更好的IDE、更好的语言、更好的框架、更好的库。一切都围绕“让代码被更快地写出来”。
现在agent把“写代码”这件事的成本降到了接近零。那瓶颈跑到哪里去了？
跑到判断力那里去了。
想一想传统软件工程里，人的“判断力”承担了多少工作。一个资深工程师review代码的时候，他真正在判断的不是语法错误——那种事linter就能做——他在判断的是：这段代码有没有违反团队的隐性约定？会不会把某种坏模式扩散出去？踩没踩到那种“平时看不出问题但特定场景会炸”的坑？从长期看会不会变成技术债？
这些判断过去是够用的，因为代码产能本身就是瓶颈，判断力虽然稀缺但供给勉强跟得上。agent把代码产能翻了十倍之后，判断力立刻变成了最紧的那根线。
OpenAI在文章里用了一个词：他们最想最大化的稀缺资源，是人的时间和注意力。
这个表述特别精准。不是“人的能力”，是“人的注意力”。能力已经被agent放大了，放大之后剩下需要小心分配的，是那一点点珍贵的注意力。
这就引出了Harness Engineering这个新概念。
顺着这个逻辑你会想到一个有意思的问题——如果判断力变成了新的瓶颈，那一个工程师、一个团队最该优化的，就不是“我们今天写了多少代码”，而是“我们把多少判断力固化下来、不再依赖于某个人的脑子”。前者是工作量，后者是资产。这两者的差别就像“打工”和“建厂”的差别。打工赚的是当天的钱，建厂赚的是之后每一天的钱。
三、Harness Engineering 到底是什么
Harness这个词来自“马具”——就是缰绳、挽具、轭、车辕这些东西。单独一匹马是有力量的，但那股力量是发散的、甚至危险的。给它装上harness，马才变成了可用的生产力——力量被约束、方向被确定、状态被监控。
软件工程里的harness是同样的逻辑。agent本身是一股很大的力量，但这股力量天生缺方向、缺记忆、缺自纠偏。你需要一套系统来把它的力量转化成可用、可复用、可持续的产出。这套系统就是harness，设计这套系统的工程叫Harness Engineering。
那Harness Engineering具体在设计什么？我来给你提炼最关键的四件事：
第一件事：约束。 告诉agent什么不能做。但是——这里是最容易搞错的地方——文档不是约束，能阻止违反的才是约束。 你写一份“不要直接调数据库”的规范贴在Confluence上，那叫建议。你配一条“调数据库就CI挂掉”的规则，那才叫约束。前者依赖注意力，后者依赖系统。注意力会分心会疲劳，系统不会。
OpenAI自己就吃过这个亏。他们一开始写了一份巨长的AGENTS.md，想把所有规则塞进一份说明书。结果呢？上下文被挤爆、内容迅速腐化、校验不了谁还有效。后来他们改成AGENTS.md只做目录，规则拆到结构化文档里，真正起作用的是linter、CI和structural test。这才跑通了。
第二件事：验证。 告诉agent它做得对不对。关键是要让agent自己能走完验证路径。怎么做？把原本给人看的UI、日志、指标、trace接到agent能直接消费的地方。让Codex自己能复现bug、自己验证修复、自己对比性能目标。你只要有一个只能靠人眼判断的环节，那就是瓶颈；而瓶颈一定会被agent的吞吐反向压垮。
第三件事：反馈。 让偏差尽早暴露。这不只是“跑测试”这么简单。OpenAI搞了一个特别聪明的动作——他们设置了后台Codex任务，定期扫描代码库偏差，更新质量评分，自动发起针对性的重构PR。收垃圾从“资深工程师英雄主义”变成了“系统能力”。
这件事为什么重要？因为全agent代码库一定会复制模式，好的模式会被复制，坏的模式也会被复制。熵一定增加。如果你不把“降熵”做成系统，就只能靠人拼命救火，迟早累死。
第四件事：沉淀。 把一次经验变成资产。这是四件事里杠杆最大的一件。你想想看，一个bug修完之后，你做了什么？大部分人就修完了事。但一个会做Harness Engineering的人会问一句——这件事属于约束没做好、验证没做好、反馈没做好，还是沉淀没做好？ 然后他会强迫自己至少补一项资产：一个CI规则、一条linter rule、一个structural test、一份golden principle。
哪怕很小。只要它能让同一个坑下次不用再踩，就值得做。
我要特别说一句——这四件事的顺序不是随机的，是有递进关系的。约束告诉系统“不该做什么”，是第一层护栏；验证告诉系统“做对了没有”，是第二层护栏；反馈让偏差能被自动捕捉并修正，是第三层护栏；沉淀把这次的经验变成下次的先验，是第四层护栏。前三层在“这一次”工作，第四层在“下一次”工作。只有四层都做到位，你的系统才算真正“会自我成长”。大多数团队只做了第一层甚至半层——写个规范贴在wiki上，然后就没有然后了。这是典型的“半截Harness”，上去就翻车。
四、类比一下你就明白了
到这里你可能还觉得这些东西有点抽象。我给你打个类比——
你可以把过去的程序员想成一个工匠。工匠的价值在于他的手艺——他能雕多好、多细、多快。一个工匠一生能做多少东西，取决于他自己的双手。
现在agent相当于给这个工匠配了无限多的学徒。学徒手艺惊人，但没经验、没规矩、不认识这家作坊的老规矩。工匠面前有两个选择——
选择A：工匠继续当工匠。自己做得飞快，一个人顶过去五个人，但因为学徒帮不上忙，瓶颈还是他自己的双手。
选择B：工匠升级成总工程师。他不再亲自雕，而是设计一套“学徒使用手册+质检流水线+错题本”，让无限多个学徒都能按这套系统干活。他自己动手的时间少了，但系统输出的东西多了十倍、百倍。
Harness Engineering就是选择B。它要求工程师从“做代码”升级到“做系统的系统”——做一个让agent能持续产出正确代码的系统。
这个升级不是一朝一夕的事，它要求工程师改变自己的工作重心，改变自己的能力结构，甚至改变自己的成就感来源。你不能再靠“我今天写了多少行代码”获得满足感，你得靠“我今天沉淀了多少可复用资产、堵住了多少潜在偏差”获得满足感。
这一点对资深工程师尤其不容易。他们过去的竞争力很大一部分就来自于那些“只在脑子里”的隐性判断——显性化了之后，等于把自己的护城河主动填平。心理上是很难过这道坎的。
但是——时代会逼着所有人过这道坎，早过比晚过好。
五、为什么这件事特别反直觉
讲到这里我想插一段，因为Harness Engineering这件事有一个非常反直觉的地方，很多人卡在这里就过不去了。
反直觉在哪里？在于——做Harness Engineering，短期看上去是在“浪费时间”。
你想啊，工程师A天天在敲代码、交功能，老板看得见、同事看得见、产品经理看得见，朋友圈也方便发。工程师B呢？他每天在写CI规则、调整项目结构、重构agent的工作流、沉淀质量检查清单。他这一周可能一行业务代码都没写，但他把团队下一个月的返工量降了一半。
短期看，A的工作可见性高、显性产出多；B的工作可见性低、当下好像没干啥。如果团队的评价体系还停留在“看谁交付了多少feature”，B就会被严重低估。
但长期看，时间一拉长，B创造的价值是指数级的。因为A做的是“一次性劳动”——他这周写的代码，下周可能还得让别人review、改、维护；而B做的是“结构性劳动”——他沉淀下来的规则、流程、自动化，会在之后每一次类似场景里都发挥作用。
这个事情的难点不在技术，在组织认知。很多团队讲起来都支持Harness Engineering，但评价体系还是按旧的逻辑在运转——周报里看交付量、OKR里看feature数。这种组织就算有人想做Harness Engineering，也会被逼回去做一次性劳动。
所以我给团队负责人的建议是——如果你想让Harness Engineering在你的团队里真的发生，你必须亲自把“沉淀资产”写进评价指标。 不然没人愿意去做那些“当下看不见回报”的事。这是组织层面的闭环，不能只靠工程师的自觉。
有意思的是，一旦这个闭环建立起来，你会发现团队里最擅长Harness Engineering的那批人，往往不是代码敲得最快的人。他们是那些思考深、有耐心、愿意把一件事琢磨透然后系统化的人——而这种人过去在“交付KPI”的压榨下，反而一直是被边缘化的。
Harness Engineering的兴起，可能会让这类人重新成为团队里最有价值的人。
六、给你几条可操作的建议
讲到这里，你可能会想：“这个道理我懂了，那我具体该怎么做？”
我提炼三条可直接上手的建议——
第一条：每次出问题之后，问自己那个四选一的问题。 约束、验证、反馈、沉淀，这次出问题到底是哪一层没做好？然后哪怕只补最小的一片——一条规则、一个测试、一份checklist——也去补。积少成多。三个月下来，你会发现你的系统变成了一个会自己变强的东西。
第二条：开始前先写非目标，而不是只写目标。 大部分人做需求、做设计，只写“我们要做什么”；更有经验的做法是同时写“我们明确不做什么，以及哪些写法虽然能跑但不希望以后被复制”。前者指方向，后者划边界。边界对agent时代格外重要，因为agent不会自动识别边界——它只知道哪里有例子就去那里学。你不划，它就自由发挥。
第三条：把repo当成你们团队的知识的唯一来源。 那些只在Slack、Google Docs、会议口头共识里的知识——对人勉强够用，对agent全是空白。agent看不见的知识，就等于不存在。所以你有多少隐性知识没进到repo里，你的agent表现上限就被卡在哪里。把知识repo-local化、versioned化、discoverable化，这是AI时代的组织基本功。
我再追加一条更进阶的建议——
第四条：审视自己的技术设计文档是给人看的还是给agent看的。 大部分工程师写的设计文档都还是“essay风格”：长段落、叙事、讲权衡、讲故事。这种风格给人读还行，给agent读就是灾难——agent不会抓中心思想，它只会按你写下来的内容去执行。agent时代的技术设计文档应该更像“操作手册”：目标和非目标要分清，模块边界要明确，依赖方向要画出来，不变量要列清单，数据边界要划出来，验证路径要指明，观测点要标注，回滚策略要写出来，最后还要加上那句最关键的——哪些写法虽然能跑但不希望以后被复制。
这种文档写起来比散文累得多，但每一条都是能被agent直接消费的“指令”，不是“建议”。文档的形态也必须跟着工程范式一起变。
七、最后一层：能力的分化
我想在最后留一个思考给你。
如果Harness Engineering真的成为未来工程能力的核心，那会发生什么？
会发生一件事——工程师群体会出现一次快速的能力分化。
一部分人还会停留在“我用Cursor写代码很快”这个层面。他们的生产力确实会比不用AI的时候高，可能高到三倍五倍。但他们还是在做“一次性劳动”——写代码、修bug、review PR。这些劳动的单位价值会随着agent能力提升而持续下降。
另一部分人会转向“设计让agent工作得好的系统”。他们的产出单位价值会越来越高，因为他们做的每一件事——每一条CI规则、每一个structural test、每一份约束文档——都能被复用无数次。一件事写一次，帮你拦一万次偏差，这叫资产。一次性做完的事叫耗品。
这两种人的长期杠杆率差异会是指数级的。不是2倍、5倍，是10倍、100倍。
这就是AI时代工程能力的真正分水岭。它不是“用不用AI”的分水岭——那个问题已经过时了——它是“有没有能力设计agent的工作系统”的分水岭。
结语
如果让我用一句话总结这整篇文章，我会这么说——在AI时代，“做了什么事”越来越不值钱，“把这件事变成系统以后就不用再做了”才值钱。
一次性劳动是耗品。可复用判断力是资产。过去这两种东西的价值差没那么大，因为人的时间是主要瓶颈，大家不得不做大量一次性劳动。agent打破了这个限制之后，这两种东西的价值差一下就拉开了。
Harness Engineering最深的含义，就是教会一个工程师如何把自己的判断力从“一次性”变成“可复用”。懂这件事的人，未来十年会越走越轻；不懂这件事的人，会发现自己越做越累、却越做越不值钱。
这不是一篇吓唬人的文章，这是一篇提醒你“时间窗口还开着”的文章。这个窗口不会永远开着。但你现在开始想清楚、开始动手，还来得及。
当你愿意花一点时间把那些“原本只能靠自己盯着”的判断搬出脑子、搬到系统里，你就已经站在了正确的那一侧。