代码成本崩塌后的工程管理

我担任工程总监已经三年多了，但至今仍不断听到并读到那些我称之为“老规矩”的说法一遍又一遍地被反复提及：总监不应花时间写代码，好工作需要时间，要保护团队免受业务部门的干扰，在真正下定决心之前先争取团队共识等等。

起初，我还以为这些说法的提出者都是出于善意。后来，我们在我所在的组织中引入了大语言模型，代码生成的成本大幅下降，于是我也开始重新审视每一条规则背后的假设。

令人惊讶的是，大约有一半的“老规矩”建立在一些早已行不通的假设之上，而另一半则建立在根本不存在问题的假设之上——而且其中有些假设如今比以往任何时候都更加重要。

以下是我过去一年中整理出的一份精简版笔记。Gemini 4 在编辑过程中提供了很大帮助。

我们实际上所知道的

生成合理代码的成本已经大幅下降，而且这一趋势不会逆转。几乎所有的其他说法，要么尚未得到验证，要么本身就是错误的。

人工智能工具让工程组织的效率大幅提升——但这种提升尚未经充分验证。

代码评审、文档编写以及入职培训都已经过时——这种说法是错误的。

用一半的人力就能完成同样的开发路线图——这只是一个赌注，而非事实。

如果你以这些狭隘的假设为基础来重塑管理实践，那么你确实会取得成功。但如果你以更宽泛的假设来重构管理实践，你就是在拿他人的职业生涯做赌注，并把这当作一个结论。

聚焦于对假设的审计

每一种管理实践都建立在某种特定的假设之上。速度追踪依赖于将产出作为衡量工作量的可用代理；六个月的入职培训则基于学习语法的速度较慢这一假设；以共识为导向的架构则建立在变革成本高昂这一假设之上；人员规模规划则基于产出随人数增加而相应增长这一假设，诸如此类不胜枚举。

对于每一种实践而言，关键不在于它有多古老，而在于它究竟建立在什么假设之上。

如果某项实践的基础是编写代码的成本，那么就该对其进行审查，因为这项成本早已发生了变化。如果某项实践的根基在于人类如何协作、建立信任、分配注意力或验证正确性，那么无论这个仪式看起来多么陈旧，其本质并没有任何改变。

听起来似乎显而易见，但我认为很多人往往凭直觉来判断：凡是显得现代的，就一直保留下来；凡是显得老旧的，就干脆抛弃。这样的做法往往导致团队放弃了真正有用的摩擦，却依然沿用那些毫无意义的流程，因为实践的年代与实践的有效性其实是两个毫不相关的问题。

证据往往比噪音更小

对任何一个人——包括你自己的团队成员——只要报告了巨大的速度提升，却只提到了这一点，就要保持怀疑态度。我所熟悉的那些收益，往往在新建项目、模板化代码以及陌生领域中表现得尤为明显；而在工程师早已熟悉、能够轻松驾驭的系统中，这些收益却逐渐消退，甚至完全逆转。

我非常期待在2025年第四季度之后开展的数据和研究，届时，新一代的模型将问世，它们的能力彻底超越了那些旧版模型和研究所依赖的基础技术。

然而，实际感受到的速度与真实测量的速度之间的差距，本身也成了一种管理问题。如果你的工程师感觉速度更快，却仍然以同样的产量交付了更多缺陷，那么你就会做出错误的人员配置、错误的计划，甚至向业务部门设定无法实现的期望。

在一家采用人工智能的组织中，首要任务就是通过精准的监控手段，坦诚地告诉你，自己是否真的实现了加速。

廉价事物的脆弱代理

速度、拉取请求数量以及已关闭工单，这些指标从来都不完美。它们之所以能存续下来，是因为它们所近似的目标——即编写代码所需的工作量——其实极其稀缺，因此噪声始终控制在可接受的范围内。

如今，被代理的对象已经变得廉价。这不仅让这些指标变得不那么完美，反而会带来真正的误导：因为提高这些指标的最廉价方式，就是增加工作量；而工作量正是你的组织不再缺乏的东西。

专为人工智能设计的指标，解决的恰恰是错误的问题。我认为，接受率和提示词数量，本质上只是以全新形式出现的同一错误。而那些经久不衰的做法，往往更古老、也更艰难：为业务目标和系统健康度量成果，并将代码量视为一项需要被合理化的成本，而非一味追求的产出。

早在大语言模型出现之前，优秀的工程师们就已经提出了这样的观点。那时，这些理念的确成立；如今，它们同样可以被付诸实践——只不过以前没有人能争辩说，编写更多代码才是真正的难点。

“正确”仍然需要时间（至少目前是这样）

“好工作需要时间”这一规则，如今被清晰地拆分为两部分。

时间消耗已然大幅缩减。搭建服务、生成测试、在不同框架间进行转换、撰写迁移的第一稿——如今这一切都变得异常迅速，而任何以这些成本为基础制定的时间表，都理应被压缩。

正确性时间也分成了两部分

如今，人工智能系统比任何人工审核员都更快地检查并修正代码，而假装并非如此，只会损害公信力。一方面，机械化的验证正在走向崩溃。

凡是能够以机器可验证的方式表达“正确”的内容——比如类型、测试、合约、lint 规则、不变式、金丝雀指标——都可以被纳入考量。智能体会运行测试循环，读取失败信息，修复差异，并以远超人工审核员的速度再次执行测试。

如果你的正确性就存在于这一层，那么你的检查时间实际上正在不断缩短，并且还会持续下降。

不过，请留意是什么让这一层变得如此高效。之所以如此高效，是因为有人早已将“正确”的含义记录下来，以一种机器可以评估的形式呈现出来。

规范本身完成了这项工作，而校验器则负责解读这些规范。

语义验证则另当别论。代码是否真正实现了业务所需的政策？这种权衡是否符合你的监管合规要求？在这一领域，“正确”往往深藏于人类的头脑之中，也沉淀于制度的历史之中。

而人工智能对人工智能的校验，则存在一个结构性问题：校验器会与生成器共享训练数据、偏见以及盲点。这两个层面都会因相同的原因而陷入同样的困境。

自我审核可以发现拼写错误，却无法捕捉到那些被共同理解的误解。

我相信，接下来有三个重要的结果，也是这篇帖子的核心所在：

单位成本下降，总工作量却在上升。廉价的校验催生了更多的生成，而更多的生成又需要更多的校验。随着工作量的增加，校验工作量也在不断攀升，即便每一次校验的成本都在不断降低。

净日历时间变得模糊不清，事件轨迹也随之转变：低级错误减少，而系统性错误却增多——因为如今，高流量的合理输出，往往也能通过高流量的合理审核。

边界是一个战略性变量。你有多少正确性是可以由机器校验的，这一比例并不是一成不变的。它取决于你的规范、合约以及不变式。拥有强大规范的团队，能够充分享受廉价校验带来的好处；而那些规范较弱的团队，其生成的代码，往往仍由当初生成它的那台机器进行审核。

如今，投资于可被机器校验的正确性，已成为组织所能投入的最高杠杆式基础设施建设之一——因为它决定了你究竟能够利用这股浪潮的多少。

校验中最缓慢的环节，从来都不是校验本身，而是责任归属。有人签字，有人承担错误所带来的后果：事件复盘、监管机构、客户。签字时间并不会被压缩，因为这并非信息处理过程。

这是风险接受的过程，而法律与信任体系会将此责任分配给相关人员。

因此，校验依然决定了系统的吞吐量。真正推动变化的，是约束条件的位置：从校验速度，到规范质量，再到特定人类愿意主动承担结果的责任。

初级管道仍然是一个未解之谜

没有人知道该如何培养工程师，以适应这样的工作环境。

长期以来，你对高级工程师的评判，都是通过完成那些如今已被人工智能所接管的任务来形成的：修复小错误、编写模板化代码、陷入困境又最终走出困境——这些工作不仅仅是任务，更是孕育评判能力的实践。

如果由机器来承接这些实践，那么培养高级工程师的管道就会中断，而且由于延迟而彻底崩塌，因此你可能要等到三到五年后才察觉到这个问题。

当然，也有许多合理的应对方案。例如：对生成的代码进行结构化审核、刻意开展无辅助练习、在测试与校验工作中轮岗、更早接触真实的系统……