23 篇博文 含有标签「engineering-management」

有一句特定的短语应该让每一位工程主管立刻叫停会议：“只要模型变强，这就没问题了。”说这句话的人通常信心满满，有时还会配上一张展示能力曲线向上弯曲的幻灯片，而这几乎总是标志着路线图悄然从一份计划变成了某种预测。

这种区别比听起来更重要。计划是你所控制的一系列事情：你将编写的代码、你将构建的集成、你将运行的测试。预测是对你无法控制的事情的押注 —— 在这种情况下，是一个尚不存在的模型，它由一个从未承诺过交付日期的供应商按其时间表发布。当你围绕 “上下文窗口将翻倍” 或 “到第三季度推理能力将足够好” 来规划功能时，你并没有消除问题中最难部分的风险。你只是把它转移到了别人的发布日程表上，并宣称已经完成了。

你的智能体集群（agent fleet）本周开启了 40 个拉取请求（pull requests）。你审查了其中涉及支付代码的 6 个请求，浏览了几个正好在你打开标签页时提交的请求，然后只要通过了 CI 测试，就将其余的全部合并了。如果有人问你的审查政策是什么，你大概会描述成类似上面的做法——但这根本不是政策。这只是一种“心情”（mood）。

数据表明大多数团队都处于同样的境地。最近一项针对流行开源仓库中智能体生成的拉取请求的大规模研究发现，61% 的请求完全没有任何审查记录；而在确实经过审查的请求中，大多数也仅由其他智能体进行审查。与此同时，产量仍在攀升：智能体现在生成 PR、文档、支持响应和工单的速度，已经超出了任何人类审查流程的设计初衷。审查所有内容是不可能的，而完全不审查则是玩忽职守。因此，团队在两者之间即兴发挥，既没有明确的规则，也没有衡量的覆盖率，更无法判断当前的审查力度是过于偏执还是草率鲁莽。

制造业在一个世纪前就解决了这个问题。20 世纪 20 年代，当西部电气（Western Electric）大量生产电话设备时，对每一个单元进行检查在经济上是不可能的，而运送未检查的批次又是不可接受的——于是贝尔实验室的统计学家们建立了“验收抽样”（acceptance sampling）：这是一门具有数学依据的学科，用于决定一批产品中需要检查多少、何时拒绝整批产品，以及供应商何时赢得了放宽检查的信任。它在二战期间演变为 MIL-STD-105 标准，随后成为 ANSI/ASQ Z1.4 和 ISO 2859-1，至今仍规范着港口如何验收一整箱货物。这与智能体集群的对应关系几乎是直截了当的，但在 AI 工程领域几乎没有人采用它。

你的 CODEOWNERS 文件编码了一个古老到没人记得当初为何制定的假设：代码变更（diff）的作者知道自己身处谁的领地。一名修改计费服务的工程师深知自己进入了计费业务的领地。他们有目的地将变更范围限制在自己团队的目录内，如果必须触碰其他团队的代码，他们会亲自或在 Slack 上打个招呼，在发出评审请求之前先进行沟通。基于路径的评审路由之所以奏效，是因为人类作者会预先为自己的变更选择路由。

Agent 不会这样做。如果要求一个 Agent “迁移所有弃用的日志调用”，它会在一个下午横扫整个代码库，并生成一个涉及 400 个目录的 diff。GitHub 尽职尽责地查询 CODEOWNERS，匹配每一个通配符（glob），并同时向 40 个团队发出评审请求。

没有人询问过这些团队是否想要这种变更。没有人预警过变更即将到来。而且请求批准的“作者”并不是一个可以随时抓来了解背景信息的同事——它是一个代表其他部门某人行事的机器人账号，而那个人甚至可能都不知道哪些团队收到了通知。

每一个工程组织的每一个年度规划周期都运行在同一个隐藏的等式之上：路线图雄心除以工程师产出等于人员需求。这一规律存在了太久，以至于已经没有人再去专门记录它。你评估工作量，除以一个团队一年内能交付的成果，余数就变成了招聘计划。财务部门围绕它制定预算，招聘团队围绕它建立人才库，而经理们则围绕它规划职业生涯。

这个等式悄然失效了。在一个高度依赖 Agent（智能体）的组织中，工程产出的边际单位不再是另一名资深新员工——而是 Token 加上吸收这些 Token 产出内容的审核带宽。NVIDIA 现在给工程师分配的 Token 预算大约相当于其基本工资的一半，而 Jensen Huang 曾表示，如果一名年薪 50 万美元的工程师每年消耗的 Token 少于 25 万美元，他会感到“深感忧虑”。无论你是否认真对待这个具体的比例，结构性的核心点依然成立：公司现在可以通过两扇不同的门将资金转化为可运行的代码，而年度计划却只为其中一扇门保留了填写框。

你的下一次定级会（calibration meeting）存在一个没人愿意点破的衡量问题。委员会面前的材料显示，一名工程师在这半年提交了 340 个 PR，而另一名只提交了 90 个。五年前，这种差距意味着某些实质性的东西。而今天，它主要告诉你的是谁拥有更好的 Agent 工具链，谁的团队拥有更宽松的审查文化，以及谁对合并生成代码的容忍度更高。幻灯片上的数字衡量的是机群（fleet）。而委员会本应评估的是人。

这并非某种未来才会发生的虚构趋势。行业分析估计，在认真采用 Agent 的公司中，AI 编写的代码已占提交代码的 30% 左右；一项针对 300 名工程师的纵向研究发现，在采用 Agent 后，团队生成的 Pull Request 数量增加了 98%。你的评审流程从“前 Agent 时代”继承下来的每一项产出指标——代码行数变化、合并的 PR 数量、Story points、速率（velocity）——现在都是人类判断力和机器吞吐量的混合衡量，两者之间没有明确的归因界限。定级委员会正在比较这些混合数字，就好像他们仍在衡量人一样。

你最高产的工程师刚刚递交了辞呈。你对这套流程已经烂熟于心：移交工单、记录部署流程、交接值班轮换、安排知识分享会议。这份离职核查清单经过了数十年的完善，涵盖了公司认为其拥有的一切资产。

以下是 2026 年的核查清单所遗漏的内容：那位工程师的家目录（home directory）中包含一个经过 18 个月调校的个人 CLAUDE.md 文件、十几个编码了如何处理最棘手子系统的自定义技能（skills）、存储了智能体积累的关于代码库难点事实的记忆文件，以及经过数百次尝试和错误校准的座架（harness）设置。这些都不在代码仓库中，也不会随账号一起移交。

在他们的最后一天，IT 部门停用了笔记本电脑，数月积累的智能体配置——这正是他们的智能体能独立交付功能而其他人的智能体却在挣扎的区别所在——在无人察觉的情况下蒸发了。

关于通宵编码智能体（coding agents）的宣传非常诱人：你睡觉，智能体集群干活，你醒来时 PR 已经处理完毕。但现实情况往往更微妙且代价更高。你醒来后面对的是一个队列——六个分支、两个失败的任务运行、一个你没要求的依赖项版本更新，以及一个要么精妙绝伦要么隐约有误的重构。智能体的确生成了代码。但呈现在你桌面上的交付物并不是代码，而是一个分诊（triage）问题，且大多数团队都没有处理它的工作流。

数据显示这并非少数人的抱怨。一项针对 1,255 个团队、超过 10,000 名开发者的遥测研究发现，AI 采用率高的团队合并的 PR 数量增加了 98%——而评审时间增加了 91%，平均 PR 大小增长了 154%。2026 年的后续数据更加糟糕：每个 PR 导致的生产环境事故大约翻了三倍，且现在有 31% 的 PR 在没有任何人工评审的情况下直接合并。当智能体开始值夜班时，瓶颈并没有消失。它转移到了上午 9 点，集中在你一天中的前 90 分钟，并有了一个名字：早晨评审队列。

一份打磨精良、长达八页的设计文档（design doc），在有人读到其中的任何文字之前，就曾代表着某种意义。这种产物的存在本身就是证据：有人花了两个星期思考失效模式，与自己争论权衡利弊，并预判了评审者会提出的质疑。文档是思考的凭证。评审者仅凭打磨程度就能进行初步筛选，因为这种“精良感”很难造假，成本极高。

这种相关性如今已经消失了。一个智能体（agent）不到一小时就能生成一份内容详尽、结构严谨、图表丰富的 RFC——甚至还包含一个“已考虑的备选方案”章节，而这些方案实际上根本没人真正考虑过。产物保留了下来，但它承载的信号却消失了。大多数工程组织仍在运行一套隐性基于旧有写作成本而设计的评审流程。

“你昨天做了什么？”是每一场站会的第一个问题。对于一个通宵运行智能体集群（agent fleets）的团队来说，这已经变成了一个无法如实回答的问题。字面上的答案是：我写了三个提示词（prompts），然后回家睡觉，醒来发现有 11 个 PR，其中 4 个我还没看。那个正在陈述进展的人并不是故意撒谎。是这种仪式在替他们撒谎，因为它建立在一个不再成立的假设之上——即工作单元是一个人类在办公时间内串行地、一次只做一件事。

这个假设是起到承重墙作用的。它支撑着燃尽图、Sprint 承诺、速率值、“受阻 / 进行中 / 已完成”列，以及“谁在什么时候告诉谁什么”的整个协作流程。抽掉这个假设，这些产物并不会优雅降级。它们会继续产生看似权威但毫无意义的数字。一个团队可以拥有漂亮的燃尽图和绿色的 Sprint 状态，而其实际吞吐量有一半发生在午夜到凌晨 6 点之间，这些工作不归属于任何人，没人审计，也没有体现在任何仪式中。

几十年来，从初级工程师到高级工程师的晋升之路都要经过一堆枯燥乏味的工作。你修正了错误信息中的拼写错误。你为别人编写的函数编写了单元测试。你在凌晨 2 点追踪一个贯穿四层调用栈的空指针，并从切肤之痛中学会了防御性检查存在的意义。没有人专门设计这种课程。它的出现是因为廉价、低风险的任务恰好是培养判断力所必需的任务。

这套课程正在被删除。过去用来培训初级工程师的工作——样板代码、初稿、琐碎的 Bug 修复、测试脚手架——现在成了我们交给智能体（Agent）的工作，因为它们廉价且高效。我们在优化掉繁杂工作的同时，却没有意识到它也是课堂。结果是技能阶梯缺失了底部的横木：我们顶部依然有高级工程师，底部有 AI，而中间原本形成中级判断力的鸿沟却在不断扩大。

这不是一个通过发布更多入门级职位需求就能解决的招聘问题。这是一个学习问题。那些曾经起到教学作用的任务消失了，而剩下的任务——审查智能体的输出、分解模棱两可的问题、决定 不 构建什么——都是我们过去认为人们必须赢得资格才能去做的难题。如果你想在 2032 年拥有高级工程师，你就必须刻意去制造那些过去纯属偶然产生的经验。

最近我交流的一个团队花了三个工程师周的时间，将平均 Prompt 从 4,000 Token 削减到了 2,600 Token。他们以此为荣 —— 纯 35% 的降幅，实打实的数据，幻灯片里漂亮的图表。然后有人反向算了一笔账：这笔节省每月大约为 1,800 美元。而他们投入的三个工程师周，折算成全额薪酬成本大约是 25,000 美元。按照这个月度消耗率，这笔优化大约需要 14 个月才能回本 —— 这还是假设 Prompt 永远不变、模型永远不降价，且那些工程师没有更有价值的东西可做的情况下。

然而，这些假设一个都没成立。下个季度 Prompt 改了两次。他们使用的模型本身就降价了 40%。而那些工程师那个月没能发布的特性，恰恰是最大客户一直询问的功能。

你的团队采用编程 Agent 的那个季度，发生了两件没人会放在同一张幻灯片上的事情。吞吐量上升了 —— 更多的 PR、更多的合并代码、更多的工单被关闭。然而，你最资深的三位工程师却变慢了。这种慢不是因为偷懒，而是因为“溺水”。他们自己的提交量枯竭了，日历被评审任务填满，一对一面谈的主旋律也从“这是我交付的内容”变成了“我花了一整周时间在帮别人排障”。

这就是“资历倒挂”。那些本该通过 AI 获得更多杠杆效应的人，反而被它埋没了。这既不是动力问题，也不是工具差距，而是 Agent 改变工作形态后的结构性后果：它们让生成变得廉价，而让验证变得昂贵。验证正是你无法交给初级人员或其他 Agent 的那一项任务。