从让AI写代码到为AI设计系统：Harness Engineering的心理学
一、织布机前的卢德分子
1811年的英格兰诺丁汉，一群愤怒的纺织工人在夜色中砸毁了工厂里的织布机。他们自称“卢德分子”，以一个据说名叫内德·卢德的人物为精神领袖。历史课本通常把这个故事讲成一则关于“反对技术进步”的寓言——愚蠢的工人试图阻挡不可阻挡的工业革命。
但如果你仔细阅读那段历史，会发现一个被忽略的细节：那些砸机器的工人，并不是最差的纺织工。恰恰相反，他们是最好的。
他们是手工织布的大师，花了十年甚至二十年时间掌握了一门精湛的手艺。他们愤怒的真正原因不是“机器比我快”，而是“我花了一辈子积累的判断力、手感和经验，突然之间似乎不再被需要了”。
两百年后，我在一间科技公司的会议室里听到了几乎一模一样的话。一位有着十五年经验的高级工程师，看着屏幕上AI生成的代码，说了一句让我至今难忘的话：“它写的代码能跑，但它不知道为什么要这样写。”
这句话里藏着一个关于我们这个时代最重要的洞察——关于AI、关于工程、关于人类经验的价值。
二、从“写代码”到“设计笼子”
2024年到2026年之间，软件工程领域发生了一件微妙但深刻的事情。表面上看，大家都在讨论AI能不能替代程序员。但真正发生的变化，比这个问题本身有趣得多。
让我用一个类比来说明。
假设你经营一家餐厅。以前，你最重要的资产是一位天才厨师——他知道每道菜的火候、调料的比例、食材的搭配。现在，你拥有了一台无比强大的烹饪机器人。它可以同时处理一百道菜，速度是人类的十倍，而且永远不会累。
问题来了：你还需要那位天才厨师吗？
答案是：你比以前更需要他。但不是让他继续炒菜，而是让他设计菜谱、制定标准、定义什么叫“好吃”。
如果没有厨师的经验和判断，机器人会严格按照某个菜谱执行——哪怕那个菜谱有问题。它会在所有一百道菜里同时犯同一个错误。更可怕的是，它犯错的速度和规模，远超任何人类厨师。
这就是软件工程领域正在发生的事情。工程师的核心工作，正在从“写代码”转向“为AI设计系统”。不是被AI取代，而是角色发生了根本性的转变——从手艺人变成了系统设计师。
有人给这种新的工程范式起了一个名字：Harness Engineering——驾驭工程。
这个词本身就很有意味。Harness，既是名词“缰绳”，也是动词“驾驭”。它暗示着一种关系：AI是一匹力量惊人的马，但方向、边界和目的地，需要人来定义。
三、经验的诅咒与祝福
我有一位朋友是急诊室的医生。有一次我问他：“你觉得你工作中最重要的技能是什么？”
他想了很久，然后说：“知道什么时候不需要担心。”
他解释说，急诊室每天会涌进各种各样的病人，表现出各种各样的症状。一个年轻的住院医生可能会对每一个异常指标都紧张万分，开出一堆检查和治疗。但一个经验丰富的急诊医生，会在几秒钟内判断出哪些情况是真正危险的，哪些只是虚惊一场。
这种判断力没有写在任何教科书里。它是上万个病例在脑海中留下的模式识别能力——一种隐性知识。
软件工程中充满了这样的隐性知识。为什么这个模块要用这种设计模式而不是另一种？为什么这个接口要暴露这三个参数而不是五个？为什么那段看起来可以优化的代码偏偏不能动？
答案往往不在代码注释里，不在设计文档里，甚至不在任何人的脑子里以清晰的语言存在。它存在于整个团队的集体记忆中，存在于无数次代码审查的讨论中，存在于上线后被三个凌晨的故障电话教训出来的本能反应中。
Harness Engineering的核心，就是把这种隐性知识变成显性知识。把经验变成环境。
这听起来简单，做起来极难。因为隐性知识之所以是隐性的，恰恰是因为拥有它的人往往不知道自己拥有它。就像你很难向别人解释你是怎么骑自行车的——不是因为你不会骑，而是因为你会骑得太好了，以至于那些关键的平衡调整已经变成了无意识的本能。
但这正是工程师新角色的关键所在。你需要把“我就是知道这里不能这样做”翻译成AI能理解和遵守的明确规则、约束和边界。
每一次你对AI说“不，不要这样做”，每一次你在代码审查中否决了AI的建议，本质上你都在执行一次从隐性到显性的翻译。而真正的Harness Engineering，是把这些零散的翻译系统化、结构化，变成一个AI可以在其中正确工作的“环境”。
四、手艺与工厂
1908年，亨利·福特推出了T型车的流水线生产模式。在此之前，每一辆汽车都是由一组技艺精湛的工匠从头到尾手工打造的。一个优秀的汽车工匠需要掌握金属加工、发动机调试、底盘组装等十几种技能，培养一个这样的工匠需要五到十年。
流水线改变了一切。把复杂的整车制造分解成简单、标准化、可重复的步骤，每个工人只需要掌握其中一个环节。生产效率提高了几十倍，汽车价格从富人的奢侈品变成了中产阶级的日常交通工具。
但这里有一个被忽略的重要事实：流水线并没有让工匠消失。它让工匠升级了。
那些最优秀的汽车工匠没有去流水线上拧螺丝。他们变成了流水线的设计者——定义每个工位的标准、设计质量检测流程、优化整体生产节拍。他们的手艺经验没有消失，而是被编码进了整个生产系统中。
软件工程正在经历一模一样的转变。
过去二十年，写代码被视为一种“手艺”。我们推崇“代码工匠精神”，赞美优雅的算法、精妙的设计模式、简洁的代码风格。一个优秀的程序员，就像一个优秀的手工匠人，以作品的品质为荣。
AI正在把这种“手艺模式”推向“工厂模式”。代码的生成——就像福特时代的零部件制造——正在被自动化。但代码生成只是软件工程的一部分，就像拧螺丝只是造汽车的一部分。
真正的工程师正在“上移”，而不是“出局”。
他们从“写代码的人”变成了“定义代码应该怎么写的人”。从“在流水线上操作的工人”变成了“设计流水线的工程师”。这不是降级，而是升级。但它确实要求一种完全不同的技能组合——更多的系统思维，更多的抽象能力，更多的将隐性知识显性化的能力。
这种转变让很多人感到不安，这是完全可以理解的。就像诺丁汉的那些织布大师一样，当你花了十年磨练一种技艺，突然被告知这种技艺的执行部分可以被机器完成时，你很难不感到一种存在层面的威胁。
但历史一次又一次地告诉我们：真正有价值的不是某种具体的手艺动作，而是那些驱动手艺动作的判断力、经验和品味。这些东西不会因为执行方式的改变而贬值——恰恰相反，当执行变得越来越廉价、越来越快速时，判断力和品味的相对价值反而会飙升。
五、加法的诱惑
查理·芒格讲过一个关于建筑的故事。
有人问一位著名的建筑师：“设计一座伟大建筑的秘诀是什么？”建筑师回答：“知道什么东西不该放进去。”
这个回答揭示了一个深刻的道理，而这个道理在AI时代变得前所未有的重要。
AI在生成代码时有一个系统性的偏差：它倾向于过度设计。 给它一个简单的需求，它会返回一个带有三层抽象、两个设计模式和一个框架的解决方案。这不是因为AI“想”炫技，而是因为它的训练数据中充满了复杂的代码——那些被写进教科书、发布到开源社区、在技术博客上被讨论的代码，往往都是复杂度较高的代码。
简单的代码很少被人写文章讨论，就像没有人会为“今天又是平静的一天”写新闻报道一样。
结果是，AI有一种内在的“加法倾向”。遇到问题，它的本能反应是添加——添加一个新的抽象层、添加一个新的中间件、添加一个新的配置选项。它很少说“不，这里什么都不需要加”。
我见过一个真实的案例：一个团队让AI重构一个只有两百行的工具函数。AI返回了一个完整的“框架”——带有插件系统、配置文件解析器、中间件管道和一个命令行界面。从技术角度看，每一个组件都写得很好。但整体来看，它把一个简单的问题变成了一个复杂的问题。
原来两百行就能解决的事情，现在需要一千五百行和一个使用手册。
这就是为什么人类审查在AI时代的核心价值不是“加法”而是“减法”。
你的工作不是在AI的输出上继续添加东西，而是删掉不需要的东西。不是问“还缺什么？”，而是问“什么是多余的？”不是把代码变得更复杂，而是确保它保持简单。
这需要巨大的勇气和判断力。因为删除总是比添加更难——删除意味着你需要真正理解什么是本质的、什么是装饰性的。添加只需要“看起来有用”就行，删除则需要“确定不需要”。
安托万·德·圣-埃克苏佩里说过：“完美不是没有东西可以添加，而是没有东西可以删除。”在AI时代，这句话应该挂在每个工程师的显示器上方。
六、地基的隐喻
1986年1月28日，“挑战者号”航天飞机在发射后73秒爆炸，七名宇航员全部遇难。后来的调查发现，事故的原因是一个小小的橡胶O型圈——在低温下失去了弹性，导致固体燃料助推器的密封失效。
一个价值几美分的零件，摧毁了一个价值十二亿美元的航天器。
这个悲剧揭示了一个关于复杂系统的基本真理：系统的可靠性取决于它最基础的组件。 再先进的航天技术、再精密的飞行控制系统，都无法弥补一个基础密封件的失败。
在软件工程中，这些最基础的组件被称为“系统原语”（System Primitives）——你在其上构建一切的基石。它们可能是你的错误处理模式、你的数据验证逻辑、你的认证框架、你的API设计规范。
这里有一个关键洞察：AI会放大你的系统原语——无论好坏。
如果你的基础原语是干净的、一致的、经过深思熟虑的，AI会在这个坚实的地基上高效地构建。它会复用你的模式，遵循你的规范，生成与现有代码和谐一致的新代码。
但如果你的基础原语是混乱的、不一致的、充满历史遗留问题的，AI同样会忠实地放大这些问题。它会在一个摇摇欲坠的地基上快速堆砌更多的砖块，让整个建筑更快地走向崩溃。
而且——这是最可怕的部分——AI放大问题的速度，远远快于人类工程师发现和修复问题的速度。
想象一下：一个有问题的基础模块被AI在一天之内复用到了五十个新功能中。等你发现那个基础模块有问题时，你面对的不是一个bug，而是五十个bug——而且它们散布在整个代码库的各个角落。
这就是为什么在AI时代，系统原语的质量变得如此关键。在过去，一个有点问题的基础组件可能只会导致缓慢的技术债务积累。在AI时代，同样的问题会导致指数级的债务爆发。
好的原语就像好的地基：你不会注意到它们，直到地基出了问题，你才会意识到上面的一切都建在它之上。
七、真正的抽象与假装的抽象
在数学中，有一个概念叫“抽象泄漏”——一个抽象层本应隐藏的复杂性，在某些情况下“泄漏”出来，迫使使用者不得不理解它试图隐藏的东西。
好的系统原语和糟糕的系统原语之间的区别，往往就在于此。
让我讲一个故事。我认识一位工程师，他在一家电商公司工作。他们的系统里有一个叫做 BaseService 的类，每一个业务服务都继承自它。这个类有一百多个方法，涵盖了日志记录、数据库连接、缓存管理、错误处理等等功能。
听起来很合理，对吧？把所有公共功能放到一个基类里，所有服务都能复用。
问题是，这个“抽象”实际上是一个伪装成抽象的垃圾桶。每当有人不知道某个功能该放哪里时，就把它塞进 BaseService。几年下来，这个类变成了一个什么都做、什么都不精的庞然大物。更糟糕的是，因为所有服务都依赖它，任何对它的修改都可能影响整个系统。
这就是“假装的抽象”——它看起来像在简化事情，实际上在制造更多的问题。
当这个团队开始使用AI来生成新的服务代码时，灾难发生了。AI忠实地继承了 BaseService，在每个新服务中调用了那一百多个方法中的各种组合。很快，新代码和旧代码一样混乱——而且数量增长得更快。
与此形成对比的是另一家公司。他们的基础原语非常简洁：一个统一的错误类型、一个标准的请求-响应接口、一组明确的数据验证规则。每一个原语都只做一件事，而且做得很好。
当这个团队使用AI时，AI生成的代码自然而然地遵循了这些简洁的模式。新代码和旧代码一样清晰、一样可预测。
真正的抽象简化了思考。假装的抽象只是把复杂性换了个地方藏起来。
如何判断一个原语是真正的抽象还是假装的？有一个简单的测试：如果你需要了解一个抽象的内部实现才能正确使用它，那它就不是一个好的抽象。 好的抽象就像一扇门——你只需要知道推还是拉，不需要了解门铰链的力学原理。
在AI时代，这个标准变得更加严格。因为AI不像人类工程师那样拥有上下文和直觉来“绕过”一个有缺陷的抽象。人类可以看到 BaseService 的一百个方法，凭经验知道“这几个方法可以用，那几个方法千万别碰”。AI不会。它会公平地使用所有一百个方法，包括那些“千万别碰”的。
所以，清理你的系统原语，在AI时代不再是一个“等有空再做”的改善项目。它是你能否成功使用AI的前提条件。
八、验证的胜利
2009年，美国航空公司1549号航班从纽约拉瓜迪亚机场起飞后不久，两个引擎同时被鸟群击中失去动力。机长切斯利·萨伦伯格在短短208秒内做出了一系列决策，最终将飞机安全迫降在哈德逊河上，机上155人全部生还。
这个故事被称为“哈德逊河上的奇迹”，萨伦伯格机长被誉为英雄。但如果你仔细研究这个事件，会发现一个有趣的细节：萨伦伯格之所以能做出正确的决策，不是因为他比其他飞行员更聪明或反应更快，而是因为航空业有一套极其严格的验证回路。
每一个飞行操作都有对应的检查清单。每一个异常情况都有标准的应对程序。机长和副驾驶之间有交叉验证的机制——一个人操作，另一个人确认。即使在那208秒的极端压力下，萨伦伯格和副驾驶斯基尔斯仍然在执行他们训练了无数次的验证流程。
奇迹不是即兴发挥的结果，而是系统化验证的产物。
在AI辅助编程中，我们面临一个类似的问题。很多人和公司把赌注押在“更强大的AI模型”上——他们相信，只要AI足够聪明，就能生成完美的代码。这就像相信只要飞行员足够优秀，就不需要检查清单一样。
事实是：验证回路比更强的模型更重要。
一个中等能力的AI模型配合严格的验证回路，会比一个顶级AI模型在没有验证的情况下工作得更好。原因很简单：再强大的模型也会犯错，而且犯错的方式往往是不可预测的。你无法通过让模型“更聪明”来消除所有错误——但你可以通过系统化的验证来捕获大部分错误。
什么是好的验证回路？至少包含三个层次：
第一层是自动化测试——让机器验证机器。这是最基础的，包括单元测试、集成测试、类型检查、静态分析。AI生成的每一段代码都应该在提交前通过这些自动化检查。
第二层是模式匹配——让规则验证结构。检查AI生成的代码是否遵循了既定的架构模式、命名规范、依赖规则。这不是检查“代码能不能跑”，而是检查“代码是不是在正确的轨道上”。
第三层是人类审查——让经验验证判断。这是最高层次的验证，关注的是那些无法被自动化工具捕获的问题：设计决策是否合理？抽象层次是否恰当？这段代码是否在解决正确的问题？
这三个层次缺一不可。只有自动化测试，你会错过设计层面的问题。只有人类审查，你会因为速度太慢而跟不上AI的产出。只有模式匹配，你会捕获形式上的偏差，但错过实质上的错误。
最好的工程团队不是那些使用最强AI模型的团队，而是那些建立了最严格验证回路的团队。
这里面有一个深刻的反直觉：在一个大家都在追求“更强模型”的时代，真正的竞争优势可能不在于你用了什么模型，而在于你用什么机制来验证模型的输出。就像在航空业，竞争优势不在于飞行员的天赋，而在于检查清单和训练系统的严谨程度。
九、Bug是未写下的规格说明
1962年7月22日，美国发射了“水手1号”探测器，目标是飞越金星。火箭升空后不久就严重偏离航线，地面控制中心被迫在发射后293秒启动自毁程序。
后来的调查发现，原因是制导程序中的一个极其微小的错误：一个上划线符号被遗漏了。在Fortran语言中，这个符号表示一个平滑函数。没有了它，程序把雷达数据中的正常噪声当成了真实的速度变化来处理，导致了错误的航向修正。
一个符号，价值一千八百万美元（在1962年）。
但这个故事更深层的教训不是“要小心打字错误”。它是：这个bug揭示了一条从未被明确写下来的规则——“制导程序中的平滑函数必须使用上划线符号标记”。
在bug发生之前，这条规则存在于程序员的脑子里，存在于团队的口头约定中，存在于“大家都知道”的假设中。但它从未被写成一份明确的规格说明。
每一个bug，本质上都是一条未被写下的规格说明。
这个洞察在AI时代有着特殊的意义。当AI为你生成代码时，它依赖的是你给它的规格说明——无论是明确的提示词、代码注释、类型定义，还是隐含在现有代码模式中的约定。AI不知道那些你“大家都知道”但从未写下来的规则。
所以，每当AI生成的代码出现bug，你不应该只是修复bug本身。你应该问自己一个更深层的问题：“这个bug揭示了什么我认为理所当然但从未明确表达的知识？”
然后，把这个知识写下来——变成一条测试、一个类型约束、一段文档、一个代码检查规则。让它从隐性变成显性，从“大家都知道”变成“系统能验证”。
这是一个持续的过程。你永远不可能一次性把所有隐性知识都写下来，就像你永远不可能一次性发现所有bug一样。但每一次bug修复都是一次知识显性化的机会。
一位我非常敬佩的工程经理有一个习惯：每当团队修复了一个bug，她不仅要求修复代码，还要求回答两个问题——“这个bug教会了我们什么？”以及“我们如何让这类bug不可能再发生？”
第一个问题让团队学习。第二个问题让系统学习。
在AI时代，第二个问题尤其重要。因为AI不会从bug中学习——至少不会在你的上下文中学习。它明天可能会犯和今天一模一样的错误。唯一能“记住”教训的，是你构建的系统——你的测试、你的规则、你的约束、你的原语。
修bug不是终点，写下那条缺失的规格说明才是。
十、边界的定义者
有一个关于米开朗基罗的著名故事（可能是虚构的，但它传达的道理是真实的）。
有人问米开朗基罗：“你是怎么雕出大卫像的？”
他回答：“大卫一直在那块大理石里面。我只是去掉了不属于他的部分。”
无论这个故事是真是假，它完美地描述了Harness Engineering时代工程师的新角色。
你不再是代码的“作者”。你是系统的“边界定义者”。
你的工作不是生成代码——AI可以做到这一点，而且速度和数量远超人类。你的工作是定义代码生成的边界：什么可以做，什么不能做，什么必须做，什么不值得做。
这种角色转变是深刻的，它改变了工程师日常工作的几乎每一个方面。
过去，你花80%的时间写代码，20%的时间思考设计。现在，这个比例可能需要反过来——甚至更极端。你可能花90%的时间在思考、定义、验证上，只花10%的时间在直接的代码操作上。
这让很多工程师感到不适。写代码有一种立即的满足感——你打出一行行字符，看到它们变成可运行的程序，就像画家在画布上看到色彩逐渐呈现。而“定义边界”是一种更抽象、更间接的工作，它的成果不那么直观，反馈循环也更长。
但这正是更高层次的工程实践。就像一个城市规划师和一个砌砖工人之间的区别——不是谁更有价值的问题，而是视野和影响范围不同。
一个优秀的“边界定义者”需要回答这些问题：
“这个系统的不变量是什么？” ——无论AI怎么生成代码，什么条件必须始终为真？用户数据必须加密？API响应必须在200毫秒内返回？每个操作必须有审计日志？这些是不可协商的边界。
“这个领域的陷阱在哪里？” ——基于你的经验，你知道哪些看似合理但实际上会导致问题的做法？浮点数精度问题？时区处理的边缘情况？并发环境下的竞态条件？这些陷阱需要被编码成明确的规则和检查。
“什么是足够好的？” ——这可能是最重要也最难回答的问题。AI可以无限制地优化、重构、添加功能。知道什么时候说“够了，这已经足够好了”，需要对业务目标、技术约束和用户需求的深刻理解。
米开朗基罗看到了大理石里的大卫，因为他知道大卫应该是什么样子。同样，一个优秀的工程师能定义系统的边界，因为他知道系统应该是什么样子——以及，同样重要的，不应该是什么样子。
十一、关于那些恐慌的标语
每隔几个月，社交媒体上就会出现一轮新的恐慌。“AI将在X年内取代所有程序员！”“学编程已经没有意义了！”“软件工程已死！”
让我分享一个历史视角。
1995年，互联网开始商业化时，有人预言：“五年内，所有实体店都会关门。”三十年过去了，亚马逊确实改变了零售业，但实体店并没有消失——它们进化了。
2012年，深度学习取得突破时，有人预言：“放射科医生将在五年内被AI取代。”十四年过去了，放射科医生不仅没有被取代，他们在AI辅助下的诊断准确率比以前更高了。
每一次技术革命，都会伴随着两种声音：一种说“一切都会改变”，另一种说“什么都不会改变”。真相，一如既往，在两者之间——而且往往比任何一种极端预言都更有趣。
AI不会取代工程师，就像自动驾驶不会取代交通规划师。 它会改变工程师做的事情，但不会消除对工程师的需求。恰恰相反，当代码生成变得廉价时，那些决定“生成什么代码”和“如何验证生成的代码”的人会变得更加重要。
面对这些恐慌性的标语，保持冷静的方法其实很简单：看做法，不要看说法。
那些喊着“AI将取代一切”的人，他们自己在做什么？他们在雇佣工程师来构建和维护AI系统。那些声称“编程已死”的公司，他们的招聘页面上挂着多少个工程职位？
行动永远比言论更能说明真相。
而且，值得注意的是，那些对新技术最恐慌的人，往往是那些最不了解技术实际运作方式的人。真正在用AI写代码的工程师，对AI的能力和局限性有着清醒得多的认识。他们知道AI能做什么（生成大量样板代码、处理常见模式、快速原型开发），也知道AI不能做什么（理解业务上下文、做出架构决策、处理真正新颖的问题）。
最好的态度不是恐慌也不是忽视，而是好奇心驱动的务实主义。
十二、普通团队的操作系统
到目前为止，我们讨论的很多概念可能听起来有些抽象。那么，对于一个普通的工程团队——没有谷歌的资源、没有OpenAI的人才密度——来说，这一切意味着什么？
让我描述一个我见过的最有效的实践框架。我称之为“三层操作系统”。
第一层：原语治理。 每个季度花一天时间，团队一起审视自己的系统原语。这不是一个宏大的架构重构项目，而是一个简单的健康检查。问三个问题：我们的基础模式还一致吗？有没有新的“假抽象”偷偷溜进来了？AI在使用这些原语时表现如何？
这就像定期体检——不是等到病了才去医院，而是定期确认一切正常。
我见过一个团队把这个做成了一个简单的看板。每个系统原语一张卡片，上面标注着“健康/需要关注/需要重构”三种状态。每次季度审查，大家一起更新这些状态。简单、直观、有效。
第二层：知识显性化。 建立一个持续的机制，把团队的隐性知识转化为AI能理解的显性规则。
具体来说：每次代码审查中，如果有人说了“这里不应该这样做”或“我们通常是那样处理的”，就把这条知识记录下来。每周花三十分钟，把这些零散的记录整理成明确的规则——可以是代码检查工具的新规则，可以是架构决策记录，可以是AI提示词模板中的新约束。
关键是把这个做成一个习惯，而不是一个项目。不需要一次性把所有知识都整理完，只需要每周比上周多一条明确的规则。
一位团队负责人告诉我他的做法：他在代码审查工具里加了一个标签叫“隐性知识”。每当审查者发现自己在解释一个“大家都应该知道”的规则时，就打上这个标签。每周五下午，他花半小时把这些标签汇总，选出最重要的一两条，转化成正式的团队规范。
六个月后，他们的AI代码审查通过率从47%提高到了82%。不是因为他们换了更好的AI模型，而是因为AI终于“知道了”那些以前只存在于人脑中的规则。
第三层：验证闭环。 为AI的每一种使用场景建立对应的验证机制。
这听起来复杂，但实际上可以从很小的地方开始。比如：AI生成的每段代码都必须通过现有的测试套件？好，这是最基础的验证。AI生成的每个新API端点都必须有对应的集成测试？很好，这是第二层验证。AI生成的每个架构变更都必须经过一位高级工程师的审查？完美，这是第三层验证。
关键不是一步到位建立一个完美的验证体系，而是为每一种AI的使用方式都建立至少一个对应的验证步骤。然后逐步加强。
一个实用的技巧是“红灯/绿灯”清单。对于AI生成的每一段代码，有一份简短的清单列出“绿灯条件”（必须满足才能合并）和“红灯条件”（出现任何一个就需要人工审查）。这份清单不需要很长——五到十条就够了——但它能捕获大部分常见问题。
这三层操作系统没有什么神奇之处。它不需要昂贵的工具、特殊的培训或天才的团队成员。它需要的只是纪律性和持续性——每天做一点，每周改进一点，每月回顾一次。
最好的系统不是最聪明的系统，而是最持久的系统。
十三、真正的竞争优势
让我以一个我最近在读的历史故事来结束这篇文章。
19世纪末，美国铁路行业经历了一段疯狂的扩张期。几乎每一家铁路公司都在拼命铺设更多的铁轨——更长的线路、更多的车站、更远的目的地。他们相信，谁拥有最多的铁轨，谁就赢了。
但最终胜出的不是拥有最多铁轨的公司。而是那些建立了最好的调度系统、最可靠的时刻表和最高效的货物转运网络的公司。铁轨是基础设施，但调度系统才是让铁轨产生价值的东西。
类比到今天：AI模型是铁轨，而你的工程系统——你的原语、你的验证回路、你的知识体系——是调度系统。
每家公司都可以使用同样的AI模型。GPT、Claude、Gemini，这些模型对所有人开放。真正的竞争优势不在于你使用什么模型，而在于你如何把组织的经验和知识转化为AI可以执行的系统。
让我把这个说得更具体一些。
公司A和公司B使用同一个AI模型来辅助开发。公司A的工程师只是简单地把需求描述扔给AI，然后手动检查输出。公司B花了几个月时间，把团队十年积累的工程经验——架构原则、常见陷阱、设计模式、质量标准——编码成了一套完整的约束系统和验证流程。
六个月后，公司A的工程师仍然在每段AI生成的代码上花大量时间做人工检查和修改。公司B的工程师已经能够信任AI生成的80%的代码，把精力集中在那些真正需要人类判断的20%上。
这不是技术差距，而是系统差距。是经验被编码的程度差距。
这也解释了为什么那些经验最丰富的团队，在AI时代的潜在优势最大。不是因为他们的个人技能更强——在代码生成速度上，没有人能和AI竞争。而是因为他们拥有最多的隐性知识可以被显性化、被编码、被系统化。
一个有十年经验的团队，脑子里装着数以万计的“这样做行得通/这样做行不通”的教训。如果他们能把这些教训转化成AI可以理解和遵循的规则——测试、类型约束、架构模板、验证检查——他们就拥有了一个其他团队无法轻易复制的竞争优势。
因为经验不是可以购买的。你可以购买最新的AI模型，但你不能购买十年的工程教训。你能做的，是把这些教训变成系统——让它们不仅仅存在于人的脑海中，而是融入到AI工作的每一个环节里。
尾声：回到那些织布工
让我回到文章开头的那些诺丁汉织布工。
历史最终证明，他们的恐惧是有道理的——但也是错位的。他们确实失去了“手工织布”这份具体的工作。但纺织业并没有消亡，反而经历了空前的繁荣。而那些适应了新现实的人——那些学会了操作机器、设计织物图案、管理生产流程的人——过上了比手工织布时代更好的生活。
同样的故事正在软件工程领域上演。“手写代码”这个具体的动作正在被部分自动化。但软件工程——设计系统、定义边界、验证质量、将人类经验编码为可执行规则——这个更宏大的事业，才刚刚迎来它最激动人心的篇章。
AI不是来取代工程师的判断力的。它是来放大工程师的判断力的。
前提是，你得先有判断力可以被放大。而这种判断力——来自经验、来自教训、来自无数次失败和成功的积累——恰恰是AI最无法替代的东西。
亨利·福特说过一句被广泛引用的话：“如果我问人们想要什么，他们会说更快的马。”
在AI时代，很多人想要的是“更快的代码生成器”。但真正需要的，是更好的系统来驾驭代码生成的力量——更清晰的原语、更严格的验证、更深刻的边界定义。
不是更快的马，而是更好的道路。
这就是Harness Engineering的本质。不是关于AI有多强大，而是关于我们如何驾驭这种力量。不是关于谁能生成最多的代码，而是关于谁能把最多的智慧编码进系统中。
而这种智慧，永远需要人来提供。