软件工程的重心正在悄悄迁移
一个有意思的现象
我最近注意到一件有意思的事。过去三十年，软件工程这个学科一直有一个隐含的假设：工程能力的上限，大致等于工程师写代码的速度和质量。我们讨论编程语言、讨论设计模式、讨论架构、讨论review制度，几乎所有的讨论都围绕着同一个核心：如何让人写出更多、更好、更可靠的代码。
这个假设正在松动。
过去一年，我身边最好的团队开始花越来越多的时间做一件看起来不像“工程”的事：他们不再主要写代码，而是在搭建一种让agent能稳定产出代码的环境。他们写测试、写linter、写CI规则、写结构化文档、写可观测性管道。他们做的每一件事，都不是在直接产出功能，而是在定义一个系统——在这个系统里，agent能够被引导、被约束、被验证、被纠偏。
这件事一开始看起来很奇怪。如果agent已经能写代码，为什么还要花这么多时间去准备它的工作环境？为什么不直接让它写？
但如果你观察得久一点，你会发现这些团队的产出比那些只是“让agent写得更多”的团队高得多。它们不是更快，而是可持续地更快。
这个观察很重要。它指向一个我花了很长时间才想明白的结论：软件工程的重心，正在从“写代码”迁移到“设计让代码被正确地写出来的系统”。
我知道这句话听上去像一句话术，像某种被反复说过的“范式转移”口号。但它不是。它是一个有具体后果的判断，一个会改变你接下来每天做什么、关心什么、积累什么的判断。真正被迁移的不是某种技术栈，也不是某套工作流，而是“工程能力”本身在什么样的活动里被培养、被体现、被兑现。
这种迁移在历史上发生过几次。一次是从汇编到高级语言——那次迁移让工程能力的重心从“熟悉机器指令”变成了“熟悉抽象结构”。一次是从本地部署到云和分布式系统——那次迁移让工程能力的重心从“一台机器的优化”变成了“一整套服务的编排”。每一次迁移都让上一代最擅长的那批人突然发现，自己的竞争力不再完全适用，必须重新学一次。
我有理由相信，我们现在正处在类似的节点。
为什么过去的直觉失效了
过去我们对生产力的直觉大致是这样的：一个工程师一天能写多少行代码，就决定了他一天能创造多少价值。这个直觉不完全对，但它大致成立——因为代码产能确实是大多数软件项目的主要瓶颈。
然后agent来了，这个直觉突然失效了。
一个使用agent的工程师，代码产能可以是原来的十倍、二十倍。但很少有团队真的跑出了十倍的产出。大部分团队跑出的是三倍、两倍，甚至更糟——一开始快，过几个月反而慢了下来。有些团队的bug率、技术债、重复工作量反而在上升。
为什么？
因为产能从来不是真正的瓶颈，我们只是以为它是。真正的瓶颈，是判断力。
想一想传统软件工程里“判断力”承担了多少工作。一个资深工程师在review一段代码的时候，他不是在“检查有没有语法错误”——那种事linter就能做。他真正在做的，是判断这段代码有没有违反团队的隐性约定、会不会把某种坏模式传播下去、有没有踩到某个只有在某种特定场景才会出问题的坑、长期看会不会变成技术债。
这种判断力是极其稀缺的，而且它只存在于少数人的脑子里。过去之所以没成为瓶颈，是因为代码产能更稀缺——判断力虽然也稀缺，但供给勉强够用。agent把代码产能拉高了一个数量级，判断力立刻变成了最紧的那根线。
这是一个非常经典的瓶颈迁移。它提醒了一件很重要的事：你一旦解除了某个瓶颈，系统的真正瓶颈就会显形，而那个新的瓶颈通常藏在一个你原本没怎么认真对待的地方。
这也是为什么“AI时代是不是要失业”这个问题问得不太对。它问的方向不对。真正该问的问题是：当代码产出变得便宜，什么东西变贵了？答案是判断力。判断力变贵之后，怎么分配和规模化这种稀缺资源？这才是更有意义的问题。
顺着这条线想下去，你就会意识到软件工程学科接下来很多年的真正议题，大概率会围绕“判断力的规模化”展开。怎么把一个人的判断力固化成代码？怎么把一个团队的共识固化成自动化的检查？怎么让agent在做决策时能访问到组织积累下来的那些“这种情况下应该这样做”的先例？这些问题从2020年的角度看会显得奇怪——那时代码产能还是瓶颈，没人会专门花精力“规模化判断力”——但从2026年的角度看，它们就是这个学科最中心的问题。
一个新词：harness
OpenAI最近写了一篇文章，给这种新的工程实践起了个名字，叫harness engineering。我觉得这个词起得很好。
harness这个词的本义是马具——那些把一匹马的力量转化成有方向、可控、可持续劳动的装置。缰绳、挽具、车辕、轭。如果只有一匹马，没有这些东西，马的力量是发散的，甚至是危险的。加上harness，马才变成了一个可用的生产力单位。
agent在某种程度上很像一匹马。它有力量，有速度，但没有方向，没有自控，也没有记忆。你要让它真正为你干活，就必须给它一套harness——那套能把它的原始能力转换成可用产出的系统。
harness engineering就是在设计这套系统。它包括什么？OpenAI自己把它拆成了几层：约束、工具、反馈、记忆。我觉得可以用更抽象一点的语言概括：你要告诉agent“不该做什么”，要给它“能做什么”的手段，要让它“做了之后能知道做对没有”的信号，还要让它“这次做错了下次能改进”的机制。
这听起来像常识。但有趣的地方在于，这件事过去根本不需要做。过去的工程师自带harness——他们的经验、他们的品味、他们上次被骂过的记忆，构成了一套隐性harness。这套harness装在他们脑子里，你看不见，但它一直在工作。
agent没有这套harness。你想让它工作，必须把harness外化成系统——变成代码、变成规则、变成测试、变成文档、变成流水线。
这就是harness engineering最本质的那件事：把原本存在于人脑中的隐性harness，外化成系统可执行的显性harness。
这个动作听起来平淡，但它触及了一个非常深的问题：大多数工程师的竞争力是从哪里来的？仔细想一下，你会发现它不是来自他们“知道”什么——知识在互联网时代早已免费了——而是来自他们“会判断”什么。他们知道什么时候该规范化、什么时候该hack、什么时候应该重构、什么时候不要动。这种判断往往讲不清楚，也没法完整地写下来。它存在于一种只有经验能锻炼出来的直觉里。
harness engineering要求你做一件过去几乎没人认真做过的事：把直觉写下来。 不是写成“设计原则”这种不会被执行的纸面规则，而是写成能拦住错误、能推动纠偏、能被系统反复执行的形态。这件事的难度，远大于大多数工程师的预期。也正因为它难，它才成为新的能力分水岭。
它在改变什么
这种迁移一旦发生，会连带改变很多东西。我挑几个最重要的讲。
首先，它改变了“好代码库”的定义。
过去我们说一个代码库好，通常是说它“对人友好”——结构清晰、命名合理、注释得当、新人看得懂。现在开始有一种新的标准在出现：一个好的代码库首先是agent能独立理解并推理的代码库。
这个标准听起来和“对人友好”差不多，但实际上要求更严格。人可以靠口头沟通、靠私下问、靠经验脑补来弥补文档缺失；agent不行，它只能看见仓库里写着的东西。所以那些“只存在于某个资深工程师脑子里”的知识、“只在Slack里讨论过”的约定、“只在某次设计评审上口头说过”的边界——这些对人来说勉强够用的知识，对agent都是空白。
推论是很明确的：知识是否是repo-local的、versioned的、discoverable的，决定了agent的表现天花板。
其次，它改变了工程的主产物。
过去工程师的主产物是代码。现在agent可以写代码了，你的主产物开始往另一个方向迁移——往上游迁移，迁到约束上。
这个变化不是说代码不重要了。代码当然还重要。但代码变成了某种“下游产物”，是系统的输出，而不是系统本身。真正的系统是你搭起来的那个harness——它决定了下游产出什么样的代码。
一个工程师的杠杆率，越来越取决于他能不能让自己的工作“被写一次就能被使用无数次”。一条好的CI规则能拦住一万次错误。一个好的structural test能阻止某种坏模式的扩散。一份好的架构文档能让agent在下一次需要做类似决策时不用重新推理。这些都是可复用资产。
相反，亲自修一个bug、亲自review一个PR，这些是一次性劳动。它们在agent时代的性价比正在快速下降。
第三，它改变了思考的单位。
如果你还在思考“怎么把这个prompt写得更好”，你就还在“一次性生成”的心智模型里。agent的本质不是一次性生成器，它是一个循环——它推理、调用工具、观察结果、再推理。真正产生效果的单位不是一条prompt，是一个loop。
这个区别很大。一条prompt是静态的，一个loop是动态的。你在设计loop的时候，你不是在告诉agent“做这件事”，你是在设计“它做错了会怎么被发现、怎么被纠正、怎么被提醒下次别再这样”。这种思维方式接近于control theory，而不是prompt engineering。
第四，它改变了流程的逻辑。
以前的工程流程是为“修正很贵”的世界设计的。因为一旦一段代码合进了主干、出了问题，回滚成本、影响面、排查成本都很高，所以我们有了两人review、阻塞式merge gate、完整的回归测试门禁。这些流程的存在是合理的——它们对应着一个特定的成本结构。
agent时代的成本结构变了。修正变得很便宜——agent可以连夜跑，可以批量重构，可以自动修复flaky test。相比之下，“等待”变贵了——每一次阻塞式review都在消耗agent的带宽，消耗整个系统的吞吐。
所以你会看到一些先行的团队开始做看起来“违反直觉”的事：更短命的PR，更少的阻塞式门禁，更多的“先合再修”。如果你还停留在前一个成本结构里，你会觉得这是在放弃质量。但如果你理解了新的成本结构，你会意识到这不是放弃质量，而是把质量的维持工作从“入口处的一次检查”转移到了“持续的后台纠偏”。这是两种不同的质量观，它们服务于不同的世界。
一个有用的推论
这里有一个推论，我觉得非常重要，虽然OpenAI那篇文章没有直接说：未来最稀缺的工程师，可能不是那个手写代码最快的人，而是那个最会设计harness的人。
这两种人在过去的评价体系里看起来差不多，因为过去大部分工程师都不得不自己写代码。但在未来，当agent承担了主要的代码产出之后，这两种能力会分化得非常厉害。一个能把判断力固化成系统的工程师，和一个只会把判断力用在一次性劳动上的工程师，长期的杠杆率差距会是指数级的。
举个类比。古代的商人，最值钱的能力是会不会讨价还价、会不会砍价、会不会挑货；工业时代的商人，最值钱的能力是会不会设计供应链、会不会管库存、会不会做分销体系。同样是“商人”，但这两种人面对的问题完全不一样。
软件工程正在经历类似的分化。我们这个时代的“会讨价还价”是“会写代码”；我们这个时代的“会设计供应链”是“会设计harness”。这两种能力不是互斥的——你还是要会写代码，就像商人还是要懂货——但真正决定你长期价值的，是后者。
这件事的难度
我想诚实地说一句：harness engineering是很难的，比大多数人以为的难。
它难，不是因为技术复杂，而是因为它要求你把那些你自己都没意识到的隐性判断，一条一条翻出来写成规则。这件事情对资深工程师来说尤其反直觉——他们的竞争力之一恰恰是这些隐性判断，现在你要他们把竞争力显性化、组织化、变成组织能力。心理上很难接受。
它还难在另一个地方：它不是一次性的工作。agent和业务都在演化，你的harness必须跟着一起演化。一条今天写下来的CI规则，三个月后可能就过期了。所以harness engineering不是“搭完就完事”，而是“持续搭建并持续维护”。
但正是因为它难，才值得做。简单的事情护城河浅，难的事情护城河深。一个团队如果能认真做harness engineering，它会获得一种几乎不可被快速复制的能力——不是因为别的团队学不会，而是因为别的团队意识不到这件事的重要性。等他们意识到的时候，你已经领先了太多。
如果只带走一件事
如果让我用一句话总结我对这件事的理解，我会说：我们正在见证软件工程的重心，从“把代码写出来”迁移到“把让代码被正确写出来的系统搭起来”。
这不是一个温和的升级，而是一次心智模型的换轨。过去我们关心的是“你能不能写代码”；未来我们关心的会是“你能不能设计一个让别人（和agent）写出正确代码的环境”。前者是工匠的能力，后者是建筑师的能力。
一个工匠一生能盖多少房子，取决于他的手艺。一个建筑师一生能盖多少房子，取决于他能把多少人的手艺组织起来。这两种人的规模上限，差了不止一个数量级。
软件工程未来最有价值的人，会是那些想清楚了这件事、并且愿意把时间投到看起来“不像写代码”的地方的人。他们不会在朋友圈秀每天敲了多少行代码，他们会在安静地搭建那些让整个团队、整个仓库、整个agent舰队都能跑得更稳的轨道。
这些轨道不性感，但它们决定了所有跑在上面的东西能跑多远。
一点提醒
最后我想加一个提醒，因为这类文章太容易被误读。
我说“工程重心正在迁移”，不是在说“写代码不重要了”。恰恰相反——要设计好harness，你必须对代码有非常深的理解。你必须知道什么模式会演变成什么问题、知道什么抽象是真抽象什么是假抽象、知道什么边界值得守什么边界其实无关紧要。一个从未认真写过代码的人设计不出好的harness，就像一个从未真正懂马的人设计不出好的马具。
我说的“迁移”，是指时间和注意力的重新分配。未来一个好工程师花在“自己写代码”上的时间会变少，花在“设计让agent写出好代码的系统”上的时间会变多。这种变化是缓慢的、不均匀的，而且会先在前沿团队里发生，再逐步扩散。如果你在一个传统团队，你可能会在很长一段时间里还是主要写代码。但越早开始把一部分注意力转向harness，你的长期杠杆率就越高。
这件事不需要你辞职创业，不需要你推翻整个流程，不需要你背叛过去的经验。它需要的只是一个轻微但持续的倾斜：每当你做完一件事，花一点时间问自己一个问题——这件事，有没有可能被写成一条规则、一个测试、一份文档、一个脚本，让下次不需要我再做一遍？
如果有，就动手把它写下来。一次一次地写，写的东西越多，你就越接近那个未来最稀缺的工程师形象。
很多重要的变化看上去都像这样：不是哪一天突然翻天覆地，而是从某一个角度看，一切都已经不一样了。