Harness Engineering即控制论

01 前言去年有幸获赠2本书其中一本是《控制论和科学方法论》读书过半我就发了条朋友圈因为我当时觉得自己发现了一件不得了的事情。不得了自然是有些夸张了但是我的确因为这一想法而兴奋良久当时我认为AI 编程就是控制论在编码世界的一个工程实现。奈何我在网络并没有搜到相关言论以至于我对自己的这一想法产生了怀疑。直到3月份看到OpenAI发表的文章《Harness engineering: leveraging Codex in an agent-first world》以及硅谷工程师George的分析文章《Harness Engineering Is Cybernetics》甚是惊喜。1948 年维纳出版了《控制论或关于在动物和机器中控制和通信的科学》一书它是通过信息传递来实现目的性行为的理论关注系统如何通过接收外界和内部的信息来调整自身状态以达到预定目标。而今天AI“输入-输出-修正”的回路与维纳笔下的逻辑何其相似我们热谈的AI 编程到底是不是控制论的一个工程实现呢看清来路或许能更清醒地面对潮头的喧嚣。02 Harness EngineeringHarness Engineering这个词缘起于 2026 年 2 月 11 日 OpenAI 发布了一篇文章《Harness engineering: leveraging Codex in an agent-first world》https://openai.com/zh-Hans-CN/index/harness-engineering/这篇文章有一些亮眼的数据3个工程师、5个月内、1500个PR、100%AI编写完成了一个100万行代码、已投入使用的的系统。他们预估与手工编写相比他们节省90%的时间。文章的核心理念是人类掌舵智能体执行人类绝不动手编写一行代码。当然这里和我们平时开玩笑“码奸”背叛了码农在革码农的命并不是相同含义并不是不需要人类编码而是工程师的工作中心发生了变化负责为AI设计环境、明确意图、构建反馈回路。文章还介绍他们实践Harness Engineering过程中踩的一些坑我读后收益匪浅这里概括的介绍一下。2.1 给目录而不是整本说明书不要尝试用一个巨大的 AGENTS.md 文件来指导AI来完成代码生成因为它会挤占上下文、不能体现规则的重要等级、导致规则难以维护……正确做法是将 AGENTS.md 控制在约 100 行仅作为索引目录AI需要时再根据目录找到深层知识也就是我们所说的渐进式披露PSSKILL不就是这个样子吗同样的道理不要写过长的SKILL.md。2.2 规则要沉淀到仓库代码仓库是 AI 唯一能看到的世界AI没有办法看到人类大脑中的想法也无法知道编码环境之外的任何内容。因此我们平时所有的设计决策、架构约定、团队共识都必须以版本化的 Markdown、代码或可执行计划的形式提交到仓库否则AI会像一个迟到三个月入职的新员工对这些信息一无所知。2.3 务必要有架构约束仅靠一个文本或者Prompt没有办法约束AI生成完全符合要求的代码AI只有在架构确定的环境中效率才是最高的。我们可以通过脚本、流水线等校验生成的代码是否满足架构约束防止出现架构漂移。需要注意的是在规则中应该明确哪些地方需要限制哪些地方不需要限制比如生成的代码必须分为gateway、domain、dao三层至于某一层或者某一块的具体实现允许AI自由发挥。2.4 构建AI可观测的系统AI的代码生产效率远远高于人类这时候人的评审反而成了效率的瓶颈因此最好的方式是AI可以自己发现错误、修复错误、验证修复。例如将日志、监控等信息通过文件、MCP等方式暴漏给AI让AI可以自己闭环掉开发——测试——修复。2.5 等待成本高于纠错成本这里一条我是存疑的因为在很多场景比如金融支付业务安全稳定比快更重要。文中提到PR 生命周期应尽量短不要因为偶发性失败而阻塞因为AI的代码产出速度远远超出人类的PR速度纠错成本低等待成本高。2.6 让AI自动清理垃圾代码AI生成新代码时会参考已有代码因此一次坏的实现会被多次复制架构可能快速漂移。这个如果靠人来手动处理会耗费极大的时间和精力因此需要将黄金原则编码到仓库中并运行后台 Codex 任务定期扫描偏差、发起重构 PR——持续小步迭代还债远好过等到累积到一个大债务再去解决。2.7 人类的建议要沉淀到仓库中代码审查中的评论、重构 PR 和用户反馈中体现出了人类对代码实现的要求这些信息如果只停留在口头或聊天记录中就无法影响未来AI的输出因此必须将这些信息提取为规则写到文档中或者编码进工具才能让人类的要求持续的约束AI而不是随着时间流逝而消失。03 控制论题目中还有另外一个关键词——控制论我去年才接触《控制论和科学方法论》这本书它并不厚正文只有215页但是所描述的理论框架却无比强大这里有一个很有说服力的例子钱学森将维纳的控制论思想引入到工程系统中出版了《工程控制论》一书而该书是“两弹一星”工程在控制与制导领域的重要理论工具书。当然本文的重点并不是介绍控制论Cybernetics因此我以较短的篇幅将控制的核心介绍清楚以便于进行后续的讨论。控制的核心可以用一句话概括通过信息的获取与反馈对系统进行调节和控制以实现特定目标的科学。这里提到了三个关键词我们逐个讲解。3.1 关键词——信息信息这个词我们无比熟悉但是到底什么是信息却难以言明。在控制论和信息论的视野下信息的本质可以作如下解释。信息是“消除不确定性”的东西。举个例子我写的这篇文章是不是好文章读到这里你并不知道它可能干货满满也可能是AI水文。但是旁边同事告诉你“这篇文章太棒了你一定要读完”这时不确定性就减少了你就获得了信息。信息是我们在适应外部世界、并将这种适应反作用于外部世界的过程中同外部世界进行交换的内容本身。宇宙倾向于从有序走向无序熵增而获得信息的过程就是减少系统无序性、克服熵的过程。在迷雾中开车随时可能走错方向熵增突然手机导航提醒前方100米左转信息你左打方向盘控制让车子保持在正确的路上。信息这一概念明确了那么这些概念也明确了知道——人获得信息的过程传递——信息源和接受者两个系统之间的联系即一个事物对其他事物的影响……3.2 关键词——控制在讲控制之前我们需要先讲一下可能性空间这也是控制论和系统论的研究开始的地方。依然用一个例子来讲可能性空间我和你的关系。我们并不是从出生开始就注定成为同事这里面有非常多可能性但是由于条件或者纯粹机遇的关系比如你从小受到良好的教育学习一直不错而我可能恰好高考运气爆表蒙对了好几道选择题于是我们都进入了不错的大学工作时你因为“有鹅选鹅”、而我可能纯粹因为深圳离家近都选择腾讯于是咱们成为同事。你看在我们刚出生时我们的关系有各种可能陌人生、朋友、同事……由于各种条件或者纯粹的机遇我们的关系才沿着某一个特定的方向发展下去。如果我们进一步思考假如有上帝上帝有没有办法通过一些手段干预让我们成为同事的概率变大呢这就是我们要讨论的控制。控制的本质是为了达到既定目标通过克服不确定性对系统施加影响的过程。通过以上案例我们也知道作为控制对象的两个共同点1被控制的对象必须存在多种发展的可能性2人可以在这些可能性之间通过一定手段来选择。而AI生成的代码仓库完全具备这两个特点。书中有一个例子来讲控制能力分析这个本文没有太大关系但当时读到这里我非常震撼实在忍不住分享出来不感兴趣可以跳过12个小球能否用天平称3次找出唯一的、轻重未知的那个小球 这是一个数学问题我记得某次数学竞赛中做过当时费了好大劲来得到答案那么我们如果用控制能力来分析我们来看下多简单 未称之前每个小球都可能是废品废品有轻重两个状态可能性空间为12*224 天平每称一次控制能力为3左边重、右边重、一样重即可能性空间缩小为原来的1/3 称三次控制能力为3*3*3272724因此可以解决问题。3.3 关键词——反馈反馈是指将系统的输出信息返送到输入端与期望目标进行比较并根据其中的“偏差”来调节系统下一步行为的过程。反馈分为正反馈和负反馈正反馈和负反馈之间的主要区别在于对变化的响应正反馈会放大变化负反馈会减少变化。正反馈比较罕见有时候被称为恶性循环例如体温过高导致代谢加快产生更多热量体温进一步升高出现失控。这里强调一下负反馈因为负反馈扩大了系统的控制能力。我们的身体处处有着负反馈为了达到我们身体健康这一目标血糖升高则分泌胰岛素降低血糖血液变热则血管扩张、汗腺排汗……简单来说反馈就是让系统具备“自省”和“自我修正”的能力让系统从“死的东西”变成了“活的系统”具备“自省”和“自我修正”的能力。3.4 小结读到这里相信你尽管还不能完全掌握控制论但是已经等感受到控制遵循的逻辑循环[ 设定目标 ] → [ 感知偏差 ] → [ 施加干预 ] → [ 消除偏差 ]这和我们使用AI何其相似写Prompt给AI设定目标AI执行我们验收不满意出现偏差则修改Prompt或者SKILL/RULE文件施加干预让AI消除偏差以完成我们设定的目标。04 Harness Engineering 和控制论4.1 业界观点George在 X 上发布的长文《Harness Engineering Is Cybernetics》文中提到这种模式他见到三次一次是离心调速器带配重的飞球机构会感知转速再自动调节阀门工人没有消失但工作内容变了从亲手拧阀门变成设计调速器一次是Kubernetes声明一个期望状态控制器会检测容器的状态一旦两者偏离它就会根据声明做出调整比如重启、扩容、缩容……工程师的工作也从手动操作转向编写容器的描述文件一次是Harness EngineeringOpenAI 工程师不再手写代码而是设计环境、搭建反馈回路、把架构约束编码进去然后由 Agent 来写代码。而以上三种模式就是今天所讲的控制。博客中的一个观点令我印象深刻代码库过去实际上一直是有反馈回路的但只限于低层级例如编译器校验语法……而更上层即架构层面的决策、质量判断等问题只有靠人判断、修正而AI则可以让这个反馈回路闭合识别问题并修复问题。然而真正的难题是把人类独有的知识变成AI可读的东西大多数情况的失败并非 AI 能力不够而是知识一直锁在人的大脑里。过去人们总是跳过编写规则直接写代码因为他们要为此付出代价可能要在很久以后但到了 AI 时代付出的代价会被成倍放大因为AI代码生产效率实在是太高了。所以人不需要在实现上写代码战胜机器而要在评估上胜过它定义什么是正确、看出哪里偏了、判断方向对不对。4.2 我的观点我深信Harness Engineering就是控制论控制论除了可以作为两弹一星的指导工具同样也是AI编程的指导工具下图是一个控制过程那么在AI场景对应如下目标即需求需要Agent完成什么事达到什么效果控制器即AI被控系统软件代码传感器各种QA校验工具目标AI发展实在是太快了在不同阶段为了用好AI流行过Prompt Engineering 核心问题是”怎么把一句话说清楚问题”后来的Context Engineering 在Prompt Engineering 的基础上还需要告诉AI完成该任务需要知道哪些知识、可以这么做……但是这些阶段要解决的核心问题依然是怎么让模型在做决策时手里有足够的信息。那么从控制论角度我们如何和AI描述目标呢我认为要讲清楚三件事。需要做什么关于如何描述需求实际上业界早已经有方法学来解决这个问题比如软件方法中推荐使用UML表示法来表示。在AI兴起之前接到一个需求进行领域建模是一件自然而然的事使用用例规约描述系统对外表现是什么样子的即需要交付什么样的价值使用类图、序列图、状态机等描述系统是内部结构是怎么样子的。但是随着AI的兴起兴许是大模型的强大让人浮躁很多人认为人无需再进行痛苦的思考我可以向大模型许愿。但我们要明白大模型并非全知全能它更像是一个执行力极强的员工。其所有知识终归源于人类即便表现出创造力也是在人类引导下的“再创造”。因此我认为过去的方法学并没有死去相反它变得更加重要。因为大模型是基于已有的知识训练对于流行的、被普遍接受的形式恰恰是给AI讲清楚需求的最好手段。因此我给出一个暴论领域建模并不会消失相反会扮演更重要的角色。需要怎么做我们需要告诉AI需要知道什么知识为AI提供解决问题所必需的事实、数据、知识。我们说需求是目的地但是到达目的地有无数条路这些路有的直接有的弯曲。如果弯曲的路多了那么代码就难以维护。a)用框架和规范降低可能性空间因此我们需要告诉 AI 规范使用什么框架、遵循什么代码规范、使用什么编码风格……来降低代码代码生成的可能性空间将Agent生成代码的可能性为从M降低为m。举一个简单例子我让AI写一个冒泡排序AI 有一万种写法不同语言、不同库、不同变量命名风格……也就对应可能性空间为M但是如果我告诉它必须用C写AI 生成的代码的可能性空间就小了一些我如果告诉 AI 必须使用C、只能基于基础库实现、使用大驼峰命名、遵循为公司C代码规范那么生成代码可能性空间就更小了也就是生成的代码更确定了。毫无疑问我们Agent能力范围之内 m 越小越好即尽量优雅、规范的代码实现有人会说反正都是AI维护代码代码的好坏有什么影响呢这就不得不提到另一个概念核爆炸、癌细胞生长、传染病的流行现象表面上看毫无影响但是控制论给出了统一的名字自繁殖系统。在一定条件下某变量的值越大变量的值增加越快自繁殖系统一旦存在无论一开始他对周围环境影响多小最后都将产生巨大的、不可忽视的影响比如核爆炸。假如AI首次写了一个烂代码后面的实现大概率会参考该烂代码编写当到一定程度后AI也没有办法控制了。过去我所在的部门建设了大量的规范和标准化框架、组件一旦这些基建接入AI无疑是让 AI “听话”的利器。b)合理的流程规划实现控制力累积将一个大任务拆分为一个个小任务会让代码生成效果更好这已经是共识。但是为什么呢我们同样可以用控制论来解释。首先我们知道AI虽然强大但不是万能的换句话说AI作为控制器其控制能力有限并不能100%满足我们的要求。那如何扩大Agent的控制能力来达到预定目标呢答案是通过负反馈调节。来看一下老鹰抓小鸡的例子我们把老鹰额动作看作是一些里俯冲的连续每一次向目标俯冲看作是对自己的控制。老鹰的控制力优先并不能一次就达到目标抓到兔子兔子也会跑不是只能逐步向目标接近。第一次俯冲可能性空间由M缩小到M1发现距离目标较远调整方向发起第二次俯冲第二次俯冲可能性空间由M1缩小到M2发现距离目标较远调整方向发起第三次俯冲第三次俯冲可能性空间由M2缩小到m通过三次俯冲老鹰的总控制能力为(M/M1)*(M1/M2)*(M2/m)(M/m)达到了抓到兔子的目标。同样在AI生成代码时由于AI控制能力有限我们需要不断的通过反馈让AI进行调节通过多次控制能力的积累生成代码的可能性空间就由 M 缩小到 m 了也就生成满足我们要求的代码了。用什么工具人之所以强大因为人会使用工具。人靠自身做不到的事情但是使用工具就可以。同样我们也需要给带提供工具并且告诉AI这些工具能做什么以及做了之后的结果为模型提供与外部世界交互的能力。我们再来聊一下控制论中的共轭控制。我们直接让AI生成满足我们要求的代码可能就像老鹰俯冲一次就抓到兔子一样困难除了流程规划来实现控制能力的累积还有一种手段就是共轭控制。我们无时无刻都在使用共轭控制只是我们不自知我们通过一个经典的例子来解释曹冲称象使用船和石头称出大象的重量假设L把大象的体重变成石头的重量A称出石头的重量L-1把石头的重量变换成大象的体重那么我们把L-1AL称作与A共轭的控制方法把原来无法完成的事转变成了可以控制的A过程从而去完成。这个过程非常简单却应用非常广泛而在现代化的自动控制设备中L和L-1分别称为感受器和效应器人基于感受器采集的各项指标操作按钮控制机器生产。对应AI生成代码L感受器则基于各种输入收集代码生成的各项参数给AI分析AI通过参数或者调用不同工具控制选择L-1效应器各种MCP、SKILL脚本则将各种参数转换为代码让AI使用工具完成原来不能完成的事。4.3 传感器控制循环中之所以能够自矫正就是因为有传感器在持续的收集信息然后不断的计算和目标之间的差距那么AI生成代码代码的传感器是什么呢我认为有如下两类业务无关的传感器这是我自己造的词换一种说法可能更好理解就是这里有一段代码你不用了解这段代码是做什么的但是你知道这段代码不对为什么呢因为语法不对编译不过这就是业务无关而检测这种错误的组件、流水线等就称为业务无关的传感器。在上文中已经提到我们要保证仓库的代码整洁因此这些和业务无关的检测组件一定要接入到整个 AI 生产代码的过程中比如代码规范、安全规范、语法检测、部署失败日志等等。AI 在完成代码生成任务后需要运行这些检测组件然后根据检测组件出具的报告修复代码。业务相关的传感器不知道你是否和我一样曾经迷茫这样一个问题我们给AI的输入到底应该详细到什么程度。我还是以《代码千行不如架构图一张程序员如何培养业务思维做有价值的需求》中的例子要实现扣款用例你可以这样告诉 AI基本路径 1. 服务商收银系统提交消费信息 2. 系统提示学生刷脸 3. 系统验证刷脸学生账号签约状态 4. 系统请求XX支付扣款 5. 系统保存扣款结果 6. 系统返回扣款单信息 扩展路径 3a. 学生账号未签约 3a1. 系统通知家长签约 4a. 扣款账户余额不足 4a1. 系统校验垫资条件 4a1a. 不满足垫资条件 4a1a1. 转到5 4a2. 系统请求XX支付扣款 4a3. 系统通知家长还款你也可以这样告诉AI前置条件 存在已经完成签约的学生账户 后置条件 扣款凭证已经关联一笔扣款成功的支付订单 涉众利益 家长--担心由于忘记充值账户内余额不足而导致孩子无法吃饭 餐厅老板--担心卖出饭但是没有收到对应的款项 系统提供商老板--担心出现大量垫资未还的欠款产生坏账造成资金损失 基本路径 1. 服务商收银系统提交消费信息 2. 系统提示学生刷脸 3. 系统验证刷脸学生账号签约状态 4. 系统请求XX支付扣款 5. 系统保存扣款结果 6. 系统返回扣款单信息 扩展路径 3a. 学生账号未签约 3a1. 系统通知家长签约 4a. 扣款账户余额不足 4a1. 系统校验垫资条件 4a1a. 不满足垫资条件 4a1a1. 转到5 4a2. 系统请求XX支付扣款 4a3. 系统通知家长还款 字段列表 1. 消费信息消费金额商户订单号 2. 扣款单信息扣款金额是否垫资支付订单号 业务规则 1. 单学生账户最多同时存在3笔欠款 2. 垫资只针对消费金额小于30元的订单 3. 每个学校有垫资上限垫资上限学生数*3*30*10% 质量需求 1. 扣款从收到请求到结束在5秒内完成 设计约束 1. 收款系统使用XX支付这里有一个非常有意思的点我们写第二个规则所花费的时间一定是多于第一个但是如果将这两个用例规约作为Prompt 提供给 AI 生成代码很可能效果是一样的因为AI很“聪明”尤其是迭代老项目时它极有可能基于已有的代码实现推测出来这个用例应该是什么样子。于是我们难免会想既然详尽的 Prompt 未必比简单的效果更好即便略好一点却需耗费大量时间打磨为何还要如此费劲我认为这是因为短视造成的只着眼于代码生成而忽略测试、维护。简单的Prompt也许也能生成正确代码但是它缺少一个标准一个可以让AI知道生成代码对不对的标准这个对不对不是指语法而是指是不是100%满足业务规则。回忆一下人接到一个需求一定要和产品确认细节为什么要确认下这些细节呢因为我们开发完了要进行测试确认自己实现的逻辑是对的绝对不会基于一个糊涂的需求靠猜测实现上线。既然我们要求产品给出清晰明确的需求为什么我们给AI提需求时就要模糊呢。所以答案也就很明确了我们给出的业务规则一定要写到 AI 可检测、可验证为止。我们可以预想一下假如测试、规范检查、语法检测、UAT这些反馈回路全部嵌入到 AI 的执行循环内部AI 每生成一段代码就自动验证并修复这将和人工 Review 后手动修改有着天壤之别——错误的发现和修复从数小时缩短到了数分钟。现在矫枉过正了吗我们常常听到一些吐槽例如吐槽强迫研发使用AI编写代码、吐槽所有的流程都在强行AI、吐槽引入AI后提效非常有限或者说比原来更慢了等等短期来看也许吐槽的很有道理但假如我们坚持“长期主义”呢扯个大旗在《毛选》中有关于“矫枉过正”和“矫枉必须过正不过正不能矫枉”的讨论而在控制论中针对矫枉过正有一个专门的术语——滞后书中有一个例子一根铁丝我们施加一定力会变弯松手后并不会完全变直而是要适当的往相反的方向施加一个力也就是要“矫枉过正”。那什么时候矫枉过正呢控制论中的突变理论介绍了矫枉过正和飞跃现象之间的矛盾如果质变中经历的中间过渡态是不稳定的那么他就是一个飞跃的过程如果中间过渡态是稳定的那么他就是一个渐变的过程。例如水的沸点是100摄氏度但实际上由液态变为气态需要略高于100摄氏度这就是因为它是一个飞跃的过程水汽化时并不能停留在一个稳定的状态要么液态、要么气态。当质变以飞跃方式进行时可能需要矫枉过正。而研发模式的升级我认为将会是一个飞跃的过程之所以现在我们仍然需要需要参与编码一个非常大的原因就是缺乏传感器和基建仍然需要人来串流程比如需要人来验证UI是否正确、需要人来告诉AI代码不符合代码规范因此在有些场景我们仍然感觉 AI 完成的很吃力但这不是 AI 能力不行而是我们并没有为 AI 提供友好的环境……未来的某一天当我们的传感器建设的完善到一个临界值AI编程再也不需要人来串流程了我相信所有人会立刻抛弃原有个开发模式就像我们迅速抛弃传统 IDE 去拥抱Cursor一样。当然这是我浅薄的理解并没有经过精密的推导供大家批判。05 对我的影响前面对控制论做了简介讲了OpenAI的提出的Harness Engineering以及一篇比较火的对Harness Engineering分析的帖子总结了我的一些思考这些内容对我的影响是巨大的。5.1 它证明了一件事在我看到openai的文章之前我一直有一个怀疑AI能否大规模地构建和维护复杂、可靠的软件例如金融支付系统。之前我倾向于 AI 只能独立完成较小规模的软件而大规模软件一定需要人的参与其形式是 AI 和人共同来完成代码开发AI只能生成一部分无法100%生成代码。而这边文章用实际案例证明了这是可行的尽管仍然面临一些挑战。5.2 它纠正了一个错误我经常吐槽每次让 AI 完成一件事我要写详细的规则描述更让我苦恼的不是写完就完事了每次 Agent 犯了一个错我就要回去调整、测试、出错、调整……这个循环反复了几十次之后规则文件变成一个成百上千行的文档里面有方法、规范、禁止……曾经我一度认为这完全就是在浪费时间这属于买椟还珠对于程序员来说写代码才是正事曾经我一度认为先把Cursor的Tab提示用好了再说程序员一定要接触代码。然而现在我意识到这种想法完全是错误的写规则文件并不是浪费时间那就是 AI 时代程序的工作本身。5.3 它改变了一个观念之前在我的观念中程序员和AI要么是替代关系要么是协作关系。替代关系有观点认为 AI 会完全替代程序员程序员将会被大量裁员。我时常认为这种观点太极端了或者太乐观了他们过于乐观的认为 AI 可以完成程序员能做的所有事但是我又时常认为他是正确的因为大模型发展实在是太快了也许有一天他真的能够替代程序员。协作关系还有一些人认为程序员和 AI 是协作关系他们认为AI一定不能100%生成代码或者说很长一段时间内不能100%生成代码而不能生成的这一部分就需要人来编写程序员既扮演者指挥者的角色也扮演着协作者角色和 AI 共同来完成一个软件的代码实现我之前更倾向于这种观点。但是这两篇文章改变我之前的观念现在我认为他们是管理与执行的关系AI 可以生成100%的代码但并不意味着程序员一定会被替代。程序员掌舵方向、意图、判断智能体执行写代码、重构、测试、合并这种关系和协作关系相比有着微妙的区别程序员需要站在更高的层级或者说每个程序员都必须拥有架构师的水平因为程序员的工作内容发生变化已经从拧阀门的人变成了设计调速器的人——不再是代码的生产者而是环境的架构师、反馈回路的设计者、质量标准的编码者。程序员的核心价值不再是实现而是评估。古法编程Harness Engineering编写代码设计环境调试bug明确意图代码审查构建反馈回路编写测试将工程判断编码成机器可读的规则重构代码校准传感器与执行器06 尾巴软件方法、领域建模、架构……这些“最佳实践”我们喊了数十年但实践的并不好因为即使代码写的很粗放债务依然积累的很慢直到很久很久之后的一个时间点爆发也许这个时间点到我们离职都不一定爆发惰性让我找各种借口拖延可以“先上线、后优化”。然而AI时代债务的累积速度是远超想象AI可以全天候的参考已有代码复制同样的错误一次坏的实现会被无数次的重复因为“你没写下来的规矩AI永远不知道”。因此我们一定要将业务规则写下来AI的输出是不确定但是代码可以被确定性的验证我们不需要比机器写得更快但是我们一定要高效评估它的产出。而这有一个前提我们必须建设完善的基础设施可以检验语法、可以安全扫描、可以单测、可以集成测试……也许你会吐槽原来我可以上来就写代码现在你要我建模、写规则、写工具这不是浪费时间吗。不是这本就是AI时代程序的本质工作时代变了我们做的事也变了。面对AI浪潮我是迷茫的因为我并不知道最终它将会对我产生怎样的影响我现在做的探索、尝试也许很快就过时失去价值也许将来的某一天模型已经强到不需要那么多系统层面的约束呢或许吧但是也许真到了那一天程序员也就不存了。但是我仍然乐此不疲的进行各种尝试至少现在我们仍然是离AI最近的群体。回到导语中的那个问题如果一个程序员为 AI 写规则文档所花费的时间比写代码还多这对吗对因为AI时代程序员的本职工作就是设计让 AI 正确写代码的环境而不再是正确的写代码。蒸汽时代到来后船夫再也不需要去划桨了不是因为他们不会而是因为这件事已经没有任何意义了。参考资料《Harness engineering: leveraging Codex in an agent-first world》https://openai.com/zh-Hans-CN/index/harness-engineering/《Harness Engineering Is Cybernetics》https://x.com/odysseus0z/status/2030416758138634583《控制论和科学方法论》- 金观涛 / 华国凡