当算力编写代码时的员额规划

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

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

本文探讨的是，当招聘一名主任工程师（Staff Engineer）与购买 40 万美元的推理资源成为达成同一目标的竞争项时，人员编制计划会变成什么样——以及为什么核心的规划问题已经从“这需要多少名工程师”转向了“我们的决策和审核能力是多少，什么样的推理预算能使其达到饱和”。

规划仪式假设产出随人头数增长

传统的产能规划是那个以“打字”为核心约束条件的时代的产物。工程师工时是稀缺投入，因此每一个规划抽象概念——每个 Sprint 的故事点、每个项目的全职人力（FTE）、人均综合成本——都是人类能产出多少代码的代理指标。FTE 计算之所以存在，正是因为财务部门需要以可量化的单位来衡量劳动力投入，从而进行前瞻性预测：输入历史 FTE 数据，输出明年的薪资和福利支出。

Agent 从两个方向同时打破了这种代理关系：

• 生产不再稀缺。 一名运行着编码 Agent 集群的工程师可以产生相当于一个小团队的 Pull Request（PR）量。来自 Faros AI 对 10,000 多名开发者的遥测数据显示，AI 采用率高的团队合并的 PR 数量比同行高出 98%。
• 吸收现在变得稀缺。 同一项研究发现，PR 审核时间增加了 91%，PR 大小增加了 154%。代码产出的速度超过了组织负责任地接纳它们的速度。
• 组织层面的产出持平。 尽管个人层面的产量激增，但组织的 DORA 指标——部署频率、交付周期、变更失败率——并没有显示出明显的改善。

将这三项发现结合起来，结论令人不安：在一个受限于“吸收能力”的系统中增加生产能力（无论是人头还是 Agent），产出的是库存，而不是吞吐量。规划仪式一直在错误的资源上耗费精力。

新的核心约束是审核，而非生产

如果 Token 可以产生任意数量的代码，那么决定你明年产出的真正问题是：你的组织能够验证、集成并为多少机器生成的工作成果负责？

称之为你的吸收能力（Absorption Capacity）。它由人员编制电子表格中没有对应列的要素组成：

• 拥有足够背景知识的资深工程师，他们不仅能审核代码的正确性，还能根据架构意图审核 Agent 的产出。一项 2025 年的研究发现，资深工程师审核 AI 生成建议的时间为 4.3 分钟，而审核人类编写的代码仅需 1.2 分钟——单位审核速度变慢正是因为无法对“作者”进行质询。
• 无需召开委员会就能对设计方案拍板的决策者。Agent 在模糊不清时会处于闲置状态；每一个未解决的产品问题都会导致整个 Agent 集群停滞。
• CI、预发环境（Staging）和可观测性基础设施，让你能够在没有人类追踪每一条路径的情况下信任合并结果。LinearB 的基准测试发现，AI 生成的 PR 等待审核人领取的时间长了 4.6 倍——这种排队是纯粹的吸收债（Absorption Debt）。

这里有一个目前还没有基准参考的比例：单位 Agent 集群吞吐量所需的审核员人数。每个大规模运行 Agent 的组织都在通过实践发现自己的比例，通常是通过观察 PR 队列的堆积情况。一些团队发现一名强大的审核者可以吸收三到四名重度使用 Agent 的工程师的产出；而一旦工作涉及到共享基础设施，另一些团队发现这个比例接近一比一。这个数字取决于代码库的模块化程度、测试覆盖率，以及有多少架构上下文存在于可评审的文档中而非人们的大脑里。唯一不变的是，这个比例——而非人头数——才是你明年产出的天花板。

为什么财务部门仍将讨论局限在“人头数”框框里

一个显而易见的回答是：如果推理现在是生产投入，那就直接为其制定预算。这种做法之所以未能顺利推行，是因为这两类支出存在于不同的财务范畴中。

人头数是资本化的组织知识。它伴随着招聘申请流程、薪酬职级体系、审批链以及可预测的年度成本。财务部门对此拥有一套使用了上百年的工具。推理则是运营成本（Opex），其行为类似于有自己“想法”的云服务账单——由用量驱动、非线性增长，且默认没有上限。德勤（Deloitte）记录了一家医疗保健企业，其每月 8-10% 的 Token 增长在六个月内复合成超过 600 万美元的计划外年化成本。2026 年出现的首席财务官（CFO）框架都指向了同一种焦虑：决定如何使用 Token 的人并不是为账单负责的人。

因此，规划讨论默认回到了财务部门可以管控的手段上。路线图雄心被转化为人员需求，并不是因为“人头”是正确的衡量单位，而是因为“人头”是易于理解的单位。与此同时，真正的产能杠杆——推理预算以及围绕它的审核结构——隐藏在“云成本”中，既不受监管也缺乏计划。

解决方法并不是让推理支出看起来像人头费。而是赋予它同样的规划地位：

• 按角色和资历建模的 Token 支出列，就像现在的福利建模方式一样。一名协调 Agent 的主任工程师与一名在监督下工作的初级工程师在推理使用特征上有着本质的不同。
• 财务部门可以审查的成本模型：每个工作流的平均 Token × 工作流数量 × 每个 Token 的成本，并根据模型组合进行调整——且每季度重新预测，因为单价和消费模式的变化都很快。
• 为每个智能体化项目设定明确的业务指标。如果工程团队无法说明在大规模情况下，每个单位产出的 Agent 工作流成本是多少，那么它就不适合被列入预算——这应与你对待任何资本支出的纪律一致。

预算项目现在成了替代品——有时如此

这种转变的挑衅版本是直接的对比：一名全额成本为 450,000 美元的 Staff Engineer，对比 400,000 美元的推理成本加上你现有的审核能力。以此框架来看，规划变成了一个投资组合问题，而不再是一个招聘问题。

但这种替代只有在特定条件下才成立，假装并非如此会导致组织最终空有一张 Token 账单和停滞不前的路线图：

• 当工作定义明确、可由现有测试和审核者验证且可并行化时，推理可以替代人力——例如迁移、覆盖率扩展、集成胶水代码，以及那些已被充分理解的长尾工单。
• 在特定情况下，人力是无法被替代的——当工作是决定要构建什么、解决模糊性、对结果负责或跨季度承接上下文时。没有任何 Token 预算能产生一个可以承担责任的人。
• 在边界处，两者是互补关系而非替代关系：你每增加一美元的推理投入，都会消耗审核和决策能力，而这些能力是通过资深人才购买的。如果只购买推理而不考虑吸收能力，你买下的只是积压的任务（Backlog）。

这也是为什么市场数据看起来相互矛盾。PwC 的数据显示，受 AI 影响最大的公司，其薪资和生产力增长最快；而 2026 年初，新的软件工程职位发布同比下降了 15%，其中初级和中级职位承担了大部分降幅。两者其实是同一种现象：组织正在用生产型人力置换推理成本，同时竞相争夺那些能扩大吸收能力的人才。

如何制定明年的计划

如果你正在这个周期起草计划，符合新约束条件的模式大概如下：

1. 首先评估你的吸收能力。 计算在每个领域中能够真正审核智能体规模（Agent-scale）输出的工程师人数，衡量你当前的 PR 响应延迟，并诚实地面对决策瓶颈所在。这个数字——而非路线图的雄心——才是你真正的天花板。
2. 预算推理投入以使其饱和，而非超越它。 从吸收能力反推 Token 预算。如果你的审核者已经排起了长队，更多的 Token 只会为你增加库存。相反，应将边际成本花在吸收能力上：测试基础设施、更好的规格说明、以及智能体可以理解的架构文档。
3. 证明每一个招聘需求的合理性，说明它缓解了哪种约束。 “我们需要三名工程师”不再是一个计划。“我们需要一名 Staff Engineer 来扩大支付领域的审核能力，并投入 30 万美元的推理预算来使我们现有的平台能力达到饱和”才是一个计划。一些招聘需求在审查下会转化为运营支出（Opex）；那些幸存下来的需求将是为了判断力、所有权和上下文——这些是 Token 无法产出的投入。
4. 给予推理预算项目与招聘计划相同的审查节奏。 季度重新预测、每个工作流的单位经济效益，以及明确的责任人。不受约束的 Token 预算并非敏捷，而是一个你意外运行的人力计划。

未来几年陷入困境的组织，不会是那些在推理上投入过多或过少的公司。相反，是那些继续假设“生产力是瓶颈”来进行规划的组织——在招聘人手以求更快打字的同时，他们的审核队列已悄然成为了事实上的路线图。年度规划的仪式依然存在，但其中的方程式必须改变。产出不再随人头数扩展，而是随你对机器产出所能施加的判断力而扩展——而这正是值得为之规划的能力。