从让AI写代码到为AI设计系统：重新理解Harness Engineering与系统原语

发表于 | 分类于

从让AI写代码到为AI设计系统：重新理解Harness Engineering与系统原语

今天我想跟你聊一个正在发生的、但大多数人还没看清的变化。

这个变化不是“AI能不能写代码”——这个问题已经没有悬念了。真正的变化是：当AI已经能写代码的时候，人类工程师到底应该干什么？

过去两年，关于AI编程的讨论几乎都集中在一个维度上：AI的代码写得好不好？能不能通过测试？能不能替代初级程序员？这些问题当然重要，但它们都指向同一个隐含假设——编程的核心是“写代码”，谁写得更快更好，谁就赢了。

但如果你真正在一线用AI做过工程，你会发现一个完全不同的真相：AI写代码的能力已经不是瓶颈，瓶颈是你给AI搭建的工作环境。 同样一个Claude或GPT，在一个设计良好的系统里能输出惊人的生产力，在一个混乱的代码库里则会制造灾难。

这就引出了一个全新的工程学科，有人把它叫做 Harness Engineering——驾驭工程。今天这篇文章，我就来给你拆解这个概念，以及它背后一整套关于“人机协作”的新思维框架。

一、真正的变化：从“写代码”到“设计系统”

让我先给你讲一个真实的场景。

一个资深工程师，用AI助手在一个老项目里加一个新功能。他给AI写了一段很清晰的需求描述，AI也很快生成了代码。但生成出来的代码用了项目里早已废弃的旧API，引入了三个不必要的依赖，还创建了一个跟现有架构风格完全不搭的新模块。

代码能跑吗？能跑。测试能过吗？能过。但任何一个了解这个项目的人看一眼就知道：这不对。

问题出在哪？不是AI的能力不行，而是AI根本不知道这个项目的“潜规则”——哪些API已经废弃了、团队偏好什么样的架构风格、哪些依赖是被明确禁止的、模块之间的边界应该画在哪里。

这些东西，在传统软件工程里，存在于资深工程师的脑子里。新人入职靠口口相传，靠code review时被老人敲打，靠在项目里摸爬滚打三个月慢慢“悟”出来。

大多数人以为AI编程的挑战是“让AI写出更好的代码”，其实真正的挑战是让AI获得那些从来没被写下来的知识。

这就是 Harness Engineering 的核心命题：把隐性知识变成显性规则，把个人经验变成系统环境。

你不是在训练AI，你是在建设一个让AI能正确工作的“工厂”。AI是工厂里的机器，而你是设计工厂流水线的工程师。机器的能力固然重要，但流水线的设计决定了最终产出的质量。

这个类比非常关键，让我展开说说。

二、从手艺到工厂：软件工程的第二次工业革命

软件工程的历史上有一个长期的张力：它到底是一门手艺（craft），还是一种工业生产（manufacturing）？

敏捷开发运动（Agile）强调“个体与互动高于流程与工具”，整个文化崇尚工匠精神——好的程序员就是好的手艺人，写出优雅的代码就是最高追求。这种文化有它的道理，在过去几十年里也确实催生了伟大的软件。

但AI的到来正在改变这个等式。

想象一下：如果你有一个极其高效但完全没有“品味”的助手，能以你十倍的速度写代码，但完全依赖你给它的指令和环境来决定写什么样的代码——这时候，你的工作重心自然会从“亲手写代码”转移到“设计这个助手的工作环境”。

这正是软件工程正在经历的转变：从手艺模式（craft mode）转向工厂模式（factory mode）。

但这里有一个极其重要的澄清：工厂模式不意味着人类被降级了，恰恰相反，人类在升级。

在手艺模式里，一个高级工程师的时间分配可能是这样的：60%写代码，20%做设计，10%做review，10%做沟通。在工厂模式里，这个分配会变成：10%写代码（甚至更少），30%做系统设计，30%做review和质量把控，30%做规则制定和环境建设。

人类从“生产线上的操作工”变成了“生产线的设计师”。这是向上移动，不是被挤出去。

Kent Beck——极限编程（XP）的创始人，软件工程界的教父级人物——最近说了一句话，我觉得非常到位。他说：“我现在90%的代码都是AI写的，但我花在思考架构和设计上的时间比以前多了三倍。”

这不矛盾。当执行层面被自动化之后，设计层面的重要性反而被放大了。一个好的架构设计，在AI的放大效应下，能产生十倍的生产力提升；一个糟糕的架构设计，在AI的放大效应下，会产生十倍的混乱。

划重点：AI不是取代人类工程师，而是把工程师的杠杆率大幅提高了。杠杆率越高，支点的位置就越重要。而支点，就是你设计的系统。

三、AI的过度设计倾向：加法容易，减法难

现在让我们进入一个更具体的问题：当你让AI参与系统设计时，会发生什么？

答案可能出乎你意料：AI有一种强烈的过度设计倾向。

这不是bug，这是AI生成模型的本质特征。大语言模型的训练目标是“生成合理的、全面的回答”。当你问它“设计一个用户认证系统”时，它会把它见过的所有“好的实践”都堆上去——OAuth2.0、JWT、多因素认证、角色权限系统、会话管理、令牌刷新、安全审计日志……

每一项单独拿出来都是合理的。但对于一个只有三个开发者、服务五百个用户的内部工具来说，这就是灾难性的过度设计。

我把这个现象叫做 “AI的加法本能”。AI天然倾向于往系统里加东西，因为在它的训练数据里，“全面”通常是被奖励的，“简单”则往往不够引人注目。没有哪篇技术博客会因为“我们什么都没加”而获得点赞。

但任何有经验的工程师都知道：好的设计，核心能力是做减法。

Dieter Rams说“好的设计是尽可能少的设计”（Good design is as little design as possible）。这句话在软件工程里同样成立，甚至更加成立——因为软件系统的复杂度增长不是线性的，而是指数级的。每多加一个组件，系统的交互路径就多出好几条，未来的维护成本就多出好几倍。

所以，在人机协作的新范式里，人类review的核心价值不是“检查AI写的代码对不对”，而是“把AI想加的东西砍掉”。

这是一个认知上的重大转变。传统的code review是“找到遗漏的东西，补上去”——你漏了错误处理，你忘了边界条件，你没考虑并发。但AI时代的review恰恰相反：AI什么都考虑到了，你的工作是判断哪些不需要考虑。

一个优秀的 Harness Engineer 做review时，最常说的话不是“你漏了什么”，而是“这个不需要”、“删掉这层抽象”、“这里不用这么复杂”。

让我给你一个具体的例子。假设你让AI设计一个配置文件的读取模块。AI可能会给你生成这样一套东西：一个抽象的ConfigProvider接口、一个FileConfigProvider实现、一个RemoteConfigProvider实现、一个ConfigCache缓存层、一个ConfigValidator验证层、一个ConfigMerger合并层……

而一个有经验的工程师看了会说：我们现在只需要从一个JSON文件里读配置。 一个函数，二十行代码，搞定。等哪天真的需要远程配置了，再加不迟。

这就是 YAGNI 原则——You Aren’t Gonna Need It。在AI时代，这个原则比任何时候都更重要，因为AI让“加东西”的成本变得极低，但过度设计的代价并没有降低。

划重点：AI让你能更快地搭建复杂系统，但“能搭建”不等于“应该搭建”。人类的核心判断力在于知道什么时候说“够了”。

四、系统原语：AI放大效应的基石

现在我要引入今天最重要的一个概念：系统原语（System Primitives）。

什么是系统原语？简单说，就是你系统里最基础的构建模块——你的数据模型是怎么定义的、模块之间是怎么通信的、错误是怎么处理的、状态是怎么流转的。这些底层的设计决策，就是你系统的“原语”。

为什么这个概念在AI时代特别重要？因为AI有一个特性：它会忠实地放大你的原语——不管是好的还是坏的。

让我用一个类比来解释。假设你在盖一栋大楼。原语就相当于你选择的建筑材料和基本结构方式——是用钢结构还是砖混结构，是框架体系还是剪力墙体系。AI相当于一个超级施工队，能极快地按照你的图纸把楼盖起来。

如果你的基本结构设计是合理的，AI会飞速地把一栋好楼盖起来。但如果你的基本结构有问题——比如承重设计不合理——AI也会飞速地把一栋危楼盖起来。而且因为AI盖得太快了，等你发现问题的时候，可能已经盖了二十层了。

在没有AI的时代，糟糕的原语造成的伤害是线性的——因为人写代码的速度有限，问题暴露得也快。但在AI时代，糟糕的原语造成的伤害是指数级的——因为AI会以极高的速度在错误的基础上不断堆砌。

所以，选择正确的系统原语，在AI时代变成了一项关键的战略能力。

让我给你举几个好原语和坏原语的对比：

好的原语：明确的错误类型体系。 比如你定义了一套清晰的错误分类——NetworkError、ValidationError、AuthenticationError——每种错误都有明确的处理方式和传播规则。AI在这套体系下生成的代码会自动遵循你的错误处理模式，每个新模块都会正确地抛出和捕获对应类型的错误。错误处理的一致性在整个系统里自动传播。

坏的原语：万能的BaseService基类。 你定义了一个巨大的BaseService，里面塞了日志、缓存、权限检查、事务管理、事件发布……所有service都继承它。AI会忠实地让每个新service都继承这个BaseService，哪怕某个service只需要其中5%的功能。结果就是整个系统里每个模块都背着一个巨大的、不必要的依赖包袱，而且任何对BaseService的修改都会波及所有模块。

这引出了一个重要的区分：好的原语 vs. 假的抽象。

好的原语有几个特征：

  1. 概念清晰：它代表一个真实的领域概念，而不是一个技术上的便利。比如“用户权限”是一个好的原语，“AbstractManagerFactoryProvider”不是。
  2. 组合性强：好的原语可以像乐高积木一样自由组合。比如Unix的管道哲学——每个命令做一件事，通过管道组合起来做复杂的事。
  3. 边界明确：好的原语有清晰的输入输出契约，内部实现可以随时替换。
  4. 名实相符：原语的名字准确地描述了它做的事情，不多不少。

而假的抽象恰恰相反：

  1. 概念模糊：说不清楚它到底代表什么，只是“把一些东西包在一起”。
  2. 泄漏严重：使用者经常需要了解内部实现才能正确使用它（Leaky Abstraction）。
  3. 过度泛化：试图用一个抽象覆盖太多场景，结果哪个场景都不好用。
  4. 层次错位：在错误的层次做了抽象，导致简单的事情变复杂。

划重点：在AI时代，选择系统原语就像选择基因——AI会忠实地复制和表达你的基因，不管是好基因还是坏基因。投入时间在原语设计上，是杠杆率最高的工程投资。

五、验证循环比更强的模型更重要

现在让我给你说一个很多人忽略的真相：在实际工程中，改善验证循环的收益，几乎总是大于升级到更强模型的收益。

这是一个反直觉的结论。我们的直觉是：如果AI写的代码有bug，那应该用一个更聪明的AI。就像考试考差了，应该请一个更好的家教。

但现实中的数据告诉我们一个不同的故事。

假设你有一个AI编程助手，生成代码的首次正确率是70%。也就是说，每生成10段代码，有7段是对的，3段有问题。

方案A：升级到一个更强的模型，首次正确率提升到85%。
方案B：保持当前模型，但加入一个自动化的验证循环——类型检查、单元测试、集成测试、静态分析——让AI在提交前自己跑一遍，发现问题自己修。

在真实的工程环境中，方案B几乎总是更优的选择。为什么？

第一，验证循环的收益是可叠加的。 一层验证（类型检查）可能把错误率从30%降到15%。再加一层（单元测试）降到5%。再加一层（集成测试）降到1%。每一层都是独立的安全网，效果是乘法叠加的。而模型能力的提升，从70%到85%，你花了巨大的算力成本，但错误率只从30%降到了15%——跟加一层验证的效果一样。

第二，验证循环提供确定性保障。 模型的能力提升是概率性的——它“通常”写得更好，但你永远不知道哪次会翻车。而验证循环提供的是确定性的——类型检查通过了就是通过了，测试跑过了就是跑过了。在工程中，确定性的保障远比概率性的提升更有价值。

第三，验证循环产生有用的反馈信号。 当验证失败时，错误信息本身就是一条宝贵的线索，告诉AI“哪里不对、怎么不对”。AI可以利用这个信号来修正自己的输出。而“用更强的模型”则没有这种反馈机制——它只是“希望”一步就做对。

这就像教育领域的一个经典研究发现：频繁的小测验比偶尔的大考更能提高学习效果。 原因类似——小测验提供了即时反馈，让学习者能及时纠正错误，而大考只是一个最终评估。

所以，Harness Engineering 的一个核心原则是：与其追求完美的AI，不如构建完善的验证循环。

一个实用的验证循环通常包括这些层次：

  1. 静态分析：类型检查、lint规则、代码风格检查。成本最低，反馈最快。
  2. 单元测试：验证单个函数或模块的行为是否正确。
  3. 集成测试：验证模块之间的交互是否正确。
  4. 契约测试：验证API的输入输出是否符合规范。
  5. 人类review：验证设计决策是否合理，是否符合项目的整体方向。

注意这个层次结构：越往下，成本越高，越不应该频繁使用。越往上，成本越低，应该尽可能自动化。 好的Harness Engineering是让AI在提交到人类review之前，先自己跑完前四层验证。这样到达人类手里的代码，至少在技术层面已经是基本正确的了，人类只需要关注设计层面的判断。

划重点：不要迷信“更强的模型”，要投资“更好的验证循环”。在工程中，多层薄保障的叠加效果远优于单层厚保障。

六、每个Bug都是一条未被写下的规范

这是 Harness Engineering 里我最喜欢的一个观点，也是最具洞察力的一个框架。

当AI写出一段有问题的代码时，大多数人的第一反应是：“AI搞错了。”然后修掉bug，继续前进。

但一个真正理解Harness Engineering的工程师会问一个不同的问题：“为什么AI会搞错？它缺少了什么信息？”

答案几乎总是：因为有一条规则、一个约束、一个偏好，从来没有被明确地写下来。

AI用了一个废弃的API？——因为“这个API已废弃”这条信息只存在于某个工程师的脑子里，从来没有被标记在代码里或者写进文档里。

AI创建了一个不符合项目风格的模块结构？——因为“我们项目的模块应该这样组织”这条规则从来没有被明确制定过，只是一种团队的默契。

AI引入了一个不该用的依赖？——因为“我们不用这个库，因为它有已知的安全漏洞”这条信息只在去年的某次会议上口头提过。

看到了吗？每一个AI的“错误”，本质上都是一条未被写下的规范。 AI只是把你系统中的信息缺口暴露了出来。

这就像一面镜子。在没有AI的时代，这些缺口被人类的“默契”和“经验”所弥补，所以你感觉不到它们的存在。但AI没有“默契”，它只看你明确告诉它的东西。所以它会毫不留情地踩中每一个信息缺口。

理解了这一点，你对AI犯错的态度就会发生根本性的转变：AI的每个错误，都是一次完善系统规范的机会。

具体来说，当你发现AI犯了一个错误时，正确的做法不只是修掉这个bug，而是要走完一个完整的闭环：

  1. 修复当前的错误（短期）。
  2. 找到根因：AI缺少了什么信息？（分析）。
  3. 把这条信息显性化：写进配置文件、lint规则、架构文档、API规范、或者AI的prompt/context里（长期）。
  4. 验证AI在同样的场景下不会再犯（确认）。

我把这个叫做 “Bug驱动的规范完善”（Bug-Driven Specification）。

这个过程有一个惊人的副作用：你的系统文档和规范会变得越来越完善。 不是因为有人刻意去写文档（我们都知道没人爱写文档），而是因为每次AI犯错，你都不得不把一条隐性知识显性化。

三个月后，你会发现你的项目拥有了前所未有的完善规范——所有的API约定、架构原则、编码规范、禁止事项，都被明确地记录了下来。而这些规范不只是对AI有用，对新加入团队的人类工程师同样有巨大价值。

划重点：不要把AI的错误看成AI的问题，把它看成你的系统信息缺口的暴露。每修复一个AI的bug，就完善一条系统规范。长期来看，这是在建设一个越来越完善的“知识库”。

七、从“写代码的人”到“定义边界的人”

到这里，我想你已经能看出来一个更大的图景了：人类工程师的角色定义正在发生根本性的变化。

传统上，我们用“写代码”来定义工程师。一个好工程师就是一个能写出好代码的人。面试考算法，评绩效看代码产出，晋升看技术方案的深度。

但在AI时代，这个定义正在松动。如果AI能写出90%质量可接受的代码，那“写代码的能力”就不再是核心竞争力。这不是说写代码不重要了——就像你仍然需要识字才能做编辑，你仍然需要懂代码才能做好工程师——但它不再是定义你价值的核心要素。

那什么是？

我认为，未来工程师的核心能力是定义边界。

这里的“边界”包含多个层次：

系统的边界：哪些模块应该存在，它们之间的职责如何划分，数据如何流动。这就是架构设计。在AI时代，这项能力的重要性被急剧放大，因为AI会忠实地在你画好的边界内工作——边界画对了，AI的产出就是对的。

规则的边界：什么能做，什么不能做。哪些模式是被鼓励的，哪些是被禁止的。这些规则越明确，AI的行为就越可预测。在传统开发中，这些规则大多是隐性的；在AI时代，它们必须被显性化。

质量的边界：什么程度的代码质量是可以接受的，什么是不可以的。这不是一个二元判断，而是一个需要根据场景灵活调整的标准——对一个核心支付模块和一个内部管理后台，你的质量标准不应该相同。人类需要做的是为不同的场景设定合适的质量阈值。

复杂度的边界：系统可以有多复杂。这是前面说的“做减法”能力的延伸。你需要不断地判断：这个复杂度是必要的还是多余的？这个抽象层是解决了问题还是制造了问题？这个功能是现在需要的还是“将来可能需要”的？

决策的边界：哪些决策AI可以自主做，哪些需要人类参与。这是一个元层面的边界设定。比如，AI可以自主决定一个函数的内部实现，但不可以自主决定是否引入一个新的外部依赖。AI可以自主修复一个单元测试的失败，但不可以自主修改公共API的签名。

定义这些边界，需要的不是“写代码快”的能力，而是对系统全局的理解、对业务需求的判断、对技术取舍的经验、以及对复杂度的直觉。

这些，恰恰是AI最不擅长的，也是资深工程师最擅长的。

划重点：未来的工程师不是“写代码的人”，而是“定义边界的人”。你的工作是画框，AI的工作是在框内填色。框画得好，整幅画就好。

八、如何面对铺天盖地的焦虑口号

好，让我们暂时从技术层面退一步，聊聊心态。

过去两年，你一定听过无数让人焦虑的口号：

“不会用AI的程序员将被淘汰！”
“AI编程将取代80%的开发者！”
“未来只需要10%的工程师！”
“不学AI，就会失业！”

每一条都引人注目，每一条都制造焦虑，但坦率地说——每一条都是过度简化的、不负责任的判断。

让我给你一个看待这些口号的框架。

首先，区分“任务自动化”和“岗位消失”。 AI确实在自动化编程中的很多具体任务——写样板代码、写测试、做代码转换、修简单bug。但“自动化某些任务”和“消灭整个岗位”之间有巨大的差距。ATM机自动化了柜台取款，但银行柜员并没有消失——他们的工作内容变了，从点钞变成了理财咨询。同样的逻辑适用于工程师。

其次，理解“生产力悖论”。 历史上，每一次自动化工具的出现，最终都增加了而不是减少了对相关技能人才的需求。Excel没有消灭会计，反而让更多人需要处理数据。网页编辑器没有消灭网页设计师，反而创造了整个Web行业。同样的，AI编程工具大概率会扩大对软件工程能力的整体需求——因为当写代码变得更容易，更多的问题就会被用软件来解决，从而需要更多的人来设计、审核和维护这些系统。

第三，关注“哪些能力变得更重要”，而不是“哪些岗位会消失”。 这是一个更有建设性的思考方向。我前面已经分析过了：系统设计能力、边界定义能力、做减法的能力、规范制定能力——这些都在变得更重要。如果你在这些方面持续提升自己，你就不需要为那些口号焦虑。

第四，记住 Amara 定律。 Roy Amara说过：我们往往高估技术的短期影响，低估技术的长期影响。AI编程的短期影响可能没有口号说的那么剧烈——大多数公司的AI采用速度远比你想象的慢。但长期来看，它对工程师角色的重塑可能比任何人想象的都更深远。所以既不需要恐慌性地转型，也不要掉以轻心。

我的建议是：把焦虑转化为好奇心。 不要问“AI会不会取代我”，问“AI能帮我做什么我以前做不了的事”。不要问“我该不该学AI工具”，问“哪个AI工具能让我在当前的工作中产生最大的杠杆效应”。

焦虑是消耗性的，好奇心是建设性的。

划重点：面对AI焦虑口号，最好的心态不是恐慌，也不是否认，而是保持清醒的分析能力。看穿过度简化的判断，关注真正重要的能力转移。

九、给普通团队的实战操作系统

理论说够了，让我给你一套可以落地的实操框架。

不是每个团队都是Google或OpenAI，不是每个工程师都需要从零构建AI基础设施。对于大多数“普通团队”来说，Harness Engineering的落地可以分为这样几个阶段：

第一阶段：规范显性化（1-2周）

这是起点，也是杠杆率最高的一步。

把你们团队脑子里的隐性知识写下来。具体包括：

  • 架构决策记录（ADR）：我们为什么选择了这个技术栈？为什么用这种模块结构？这些历史决策的原因是什么？
  • 编码规范：命名规则、文件组织方式、错误处理模式、日志规范。不要写一百页的文档，写最关键的二十条规则就够了。
  • 禁止事项清单：哪些库不能用，哪些API已经废弃，哪些模式是被禁止的。这张清单通常很短，但极其重要。
  • 模块边界说明：每个主要模块的职责是什么，它依赖哪些其他模块，它暴露哪些接口。

写这些东西的目标不是给人看的文档（虽然它对人也有用），而是给AI看的上下文。你需要把这些规范放到AI能读到的地方——项目的README、架构文档、AI工具的配置文件（比如Cursor的.cursorrules、GitHub Copilot的指令文件）。

第二阶段：构建验证循环（2-4周）

有了规范，下一步是让验证自动化。

  • 类型系统强化：如果你用TypeScript，把strict模式打开。如果你用Python，引入mypy或pyright。类型检查是成本最低、收益最高的验证手段。
  • lint规则定制：把你的编码规范变成可以自动检查的lint规则。不要只用默认规则，加入你们团队特有的规则。比如“不允许直接使用console.log”、“所有异步操作必须有错误处理”。
  • 测试模板：为常见的模块类型创建测试模板，让AI生成新模块时自动生成对应的测试。
  • CI/CD集成：确保每次AI生成的代码都要经过完整的CI流水线。不要因为“是AI写的”就跳过任何检查步骤。

第三阶段：建立反馈闭环（持续）

前面说了“Bug驱动的规范完善”，这里是落地方法：

  • 每次AI犯错，花5分钟做根因分析：不只是修bug，还要找到“AI为什么犯这个错”的原因。
  • 把根因转化为规则：如果是缺少上下文信息，补充到文档里。如果是缺少约束，加一条lint规则。如果是缺少验证，加一个测试用例。
  • 定期回顾：每两周花30分钟回顾最近AI犯的错误，看看有没有模式——如果同一类错误反复出现，说明你的某条规范还不够清晰，或者某个验证层还有缺口。

第四阶段：优化人机分工（持续）

随着验证循环的完善，你会越来越清楚地看到：哪些任务AI可以自主完成，哪些需要人类参与。

  • 绿色区域：AI可以完全自主完成的任务（比如：写单元测试、实现明确规范的CRUD接口、做代码格式化和重构）。对这些任务，尽可能自动化，减少人类干预。
  • 黄色区域：AI可以初步完成、人类需要review的任务（比如：实现新功能、修改公共接口、处理复杂的业务逻辑）。对这些任务，建立高效的review流程。
  • 红色区域：需要人类主导的任务（比如：架构决策、原语设计、规范制定、跨团队协调）。这些是人类的核心价值区域，不要试图让AI替代。

这个分类不是固定的——随着你的验证循环越来越完善、规范越来越清晰，很多黄色区域的任务会逐渐变绿。

划重点：不要想一步到位，分阶段推进。规范显性化是起点，验证循环是核心，反馈闭环是持续改善的引擎。最终目标是建立一个越来越高效的人机协作系统。

十、真正的竞争优势在哪里

让我用一个更大的视角来收束今天的讨论。

很多人问：在AI时代，工程团队的竞争优势是什么？

最直觉的回答是“使用最好的AI模型”或者“雇最聪明的工程师”。但如果你理解了今天的讨论，你会意识到这两个答案都不够好。

AI模型是公共资源——GPT、Claude、Gemini，任何人都能用，你能用的模型你的竞争对手也能用。模型的能力差异在快速收敛，今天模型A比模型B强10%，下个月可能就反过来了。所以，模型不构成持续的竞争优势。

聪明的工程师固然重要，但个人的聪明是不可规模化的。一个天才工程师的知识和经验存在于他的脑子里，他离职了就带走了。而且在AI时代，原始的编码能力带来的优势正在缩小。

真正的竞争优势在于：谁能最快地把组织的经验转化为AI可以执行的系统。

让我解释这句话。

每一个组织都有独特的经验积累——对业务领域的理解、对用户需求的洞察、对技术选型的经验、对踩过的坑的记忆。这些经验目前主要存在于人的脑子里、会议记录里、零散的文档里、Slack的聊天记录里。

如果你能把这些经验系统化地提取出来，转化为：

  • 清晰的系统原语
  • 明确的架构规范
  • 自动化的验证规则
  • 结构化的上下文信息

那么AI就能利用这些经验来产生高质量的输出。这相当于你把整个组织的智慧“编码”到了你的工作环境中。

而这正是 Harness Engineering 的终极目标。

想象两个竞争的公司，同样用GPT-5来做开发。A公司的工程团队花了三个月把他们的架构经验、编码规范、领域知识全部系统化了，AI在他们的环境里能自主完成70%的开发任务，而且质量一致。B公司还是老模式，AI只是工程师个人的“代码辅助工具”，每次使用都需要工程师手动提供大量上下文。

半年后，A公司的开发效率是B公司的五倍。不是因为A公司用了更好的AI，而是因为A公司建设了更好的Harness。

这就像工业革命时期：最终赢得竞争的不是拥有最好蒸汽机的工厂，而是建设了最好生产线的工厂。蒸汽机是通用技术，生产线是独特的竞争优势。

同理，AI模型是通用技术，你的Harness是独特的竞争优势。

十一、写在最后

让我总结一下今天的核心框架。

如果只能记住三句话，请记住这三句：

第一，AI改变的不是“谁写代码”，而是“工程师的核心价值在哪里”。 价值不再在于写代码本身，而在于设计让AI正确工作的系统——包括原语、规范、边界和验证循环。

第二，好的系统原语 + 完善的验证循环 > 更强的AI模型。 不要追逐最新最强的模型，要投资构建最好的工作环境。模型会不断变化，但好的工程体系会持续累积价值。

第三，最大的竞争优势不是AI本身，而是谁能最快地把组织经验转化为AI可执行的系统。 这是Harness Engineering的终极命题，也是未来工程团队的核心能力。

软件工程正在经历一次深刻的范式转移。这次转移不是让工程师失业，而是让工程师的角色升级——从“写代码的人”变成“设计系统的人”，从“执行者”变成“架构师”，从“手艺人”变成“工厂设计师”。

在这个转变中，保持冷静的分析能力、持续学习的好奇心、以及对复杂系统的深刻理解，比任何具体的AI工具都更重要。

工具会变，原则不变。

这就是Harness Engineering想告诉你的事。