没上线新功能的 AI 工程师该如何写晋升材料

你团队中晋升理由最充分的 AI 工程师，其晋升材料（Promotion Packet）看起来却可能是空洞的。两个季度的努力，影响力图表却是一条平线。曾经在每次模型切换时都会飙升至 12% 的评估回退率（Eval-regression rate），现在稳定在 4%。财务部门差点就要介入调查的每月 4 万美元成本飙升从未发生，因为有人在网关中加入了预算守卫（Budget Guard）。本会导致公司状态页（Status Page）挂彩的 P0 级事故从未发生，因为紧急开关（Kill-switch）被触发，将流量导向了之前的 Prompt 版本。

这种材料在“已发布功能 X”一栏无话可说。定级委员会面对两个并排坐着的工程师：一个是这半年发布了两个显性功能的工程师，另一个是默默承担了让这些功能成为可能的负载的工程师。委员会一如既往地给发布功能的工程师打了高分。那位基建型（Infra-shaped）工程师要么拿了一个不应得的“符合预期”评分并在一个季度内辞职，要么学会用委员会真正能听懂的语言来撰写材料。

本文讨论的是第二种选择。这是一套关于如何在影响力存在于“负空间（Negative Space）”时撰写 AI 工程晋升案例的理论——那些从未发生的事故、从未兑现的成本、从未影响到用户的回退——以及为什么针对 SaaS 时代功能发布制定的定级准则，现在是运行生产环境 AI 的公司中最大的组织 Bug。

你无法放入材料的影响力形态

定级委员会懂得打分的每个传统影响力框架在 y 轴上都有一个正增量。收入增长了、延迟降低了、新产品界面上线了、采用率攀升了 14%。做这些工作的工程师带着图表走进房间，图表走势良好，委员会点头认可。

AI 工程师的图表却是平的。或者更准确地说，如果没有他们的工作，图表本会达到一个从未见过的高度，而委员会看不见那条缺失的替代时间线。看看一名承担季度工作负载的 AI 工程师的实际工作组合：

• **评估回退率（Eval regression rate）**从每次模型切换的 12% 降至 4%。委员会看到的是平稳的评估通过率。工程师看到的是：团队现在可以进行两倍频率的模型升级，每个产品发布都有已知的基准测试，以及由于“模型变差”导致的客户可见事故数归零。
• **每个活跃用户的成本（Cost per active user）**在功能复杂度增长 3 倍的情况下保持不变。委员会看到的是一条平坦的单元经济效益线。工程师看到的是：缓存、Prompt 压缩、模型路由和 Prefill 优化，其中每一项原本都会导致每月 1 万美元的账单增长，而所有这些都在三个新功能发布的背景下，在这半年内一并交付。
• **事故数（Incident count）**维持在每季度一次。委员会认为没有任何变化。工程师看到的是：Prompt 部署的自动回滚、限制异常 Agent 在执行破坏性操作前的单工具影响半径上限（Blast-radius cap）、以及在供应商宕机时让团队甚至未曾察觉的熔断器。
• **尾部延迟（Tail latency）**在流量翻倍的情况下维持在 2.1 秒的 p99。委员会认为没有改进。工程师看到的是：重写重试策略、连接池调优、对最热门端点的流式优先（Streaming-first）重构，所有这些都防止了竞争对手在那个季度公开遭遇的延迟悬崖。

这种模式是一致的。工作在叠加，所吸收的负载在扩大，对于没做这些工作的其他人来说，替代时间线明显变得更糟，而幻灯片上的图表却是一条平线。将“平线”解读为“无所作为”就是定级中的 Bug。

反事实是唯一诚实的影响力衡量单位

在工程晋升流程之外，成熟领域已经有了衡量此类工作的正确称呼。反事实影响力（Counterfactual impact）：即实际发生的情况与如果没有干预会发生的情况之间的差异。公共卫生领域用它评估疫苗，经济学用它评估政策，运筹学用它评估流程改进。其核心观点是，预防性工作无法通过直接观察来衡量，因为根据定义，被预防的事物并不存在于数据中。

在工程晋升中，反事实往往被视为可疑的。“我们怎么知道如果没有你，事故就一定会发生？”这是定级委员会对这种框架感到不安的委婉表达。答案与流行病学给出的答案相同：仔细构建反事实，将其锚定在可比单元上，并量化差距。

对于 AI 工程晋升叙述，可比单元通常就在眼前：

• 公司内没有获得同样投入的其他功能。 如果推荐团队的评估回退率是 11%，而你的是 4%，这个差距就是反事实。如果搜索团队这半年的事故数是 6 次，而你的是 1 次，这个差距就是反事实。委员会不需要一个虚构的平行宇宙——他们需要一个已经在用来校准其他工程师的同行团队。
• 你团队前一阶段的指标。 如果在开展这项工作之前，每个活跃用户的成本每季度增长 18%，而现在持平，那么预测曲线就是反事实。引导委员会完成回归分析：“这是之前的趋势。这是如果不干预趋势会将我们带向的地方。这是我们实际落地的位置。差值是每月 5.2 万美元，折合年化 62.4 万美元。”
• 同类公司的外部基准。 如果三家竞争对手在同一时期公开披露了 AI 事故，而你没有，这就是委员会可以自行验证的反事实。

这里的纪律是将每一项都作为明确的对比写进材料，而不是隐含的陈述。“评估回退率降至 4%”不是影响力陈述。“与同行团队平均 11% 的水平相比，评估回退率降至 4%，这在本半年减少了约 8 次面向客户的模型退化”才是影响力陈述。前者是隐形的。后者正是委员会用于“发布功能型”工程师的框架，只是指向了预防损害，而不是交付功能。

基础设施作为复利杠杆，并附带凭证

业绩包（packet）中的第二个招式是停止将基础设施工作仅仅定性为基础设施。将其定性为其影响范围内每一个已发布功能的先决条件，并列出这些功能的名称，以及它们各自依赖该基础设施工作的具体方式。

负责发布的工程师写道：“发布了新的对话导出功能。”而负责支持的工程师在业绩包中不应只写“构建了易于导出的流式处理原语（streaming primitives）”。而应该写：“构建了易于导出的流式处理原语，它是对话导出功能、分析师摘要视图和批量数据 API 按期发布的基础。如果没有这项工作，对话导出的发布日期预计将推迟 4–6 周，分析师摘要视图需要单独的流式实现，而批量数据 API 则会因为另一个团队的路线图而受阻。”

这不是在套近乎，而是在准确地归因承重依赖项（load-bearing dependency）。评定委员会的本能是把功劳归于发布者，因为发布公告上写的是发布者的名字。业绩包的任务是展示三个发布共享一个基础，而这个基础只有一位作者。

评估（eval）和可观测性的叙事也应以同样的方式呈现。将评估套件定性为让下一季度的功能发布更快的护城河，并用具体的预测来证明。“我构建的评估套件将从提示词（prompt）更改到放心部署的平均时间从 11 天缩短到了 2 天。下一半年度计划中的三个产品发布在原计划中各预算 11 天；实际成本将各为 2 天。这意味着下一半年度节省了 27 个工程日用于功能开发，相当于多发布了一个本无法实现的功能。”评定委员会喜欢这样的数字。秘诀在于你在进去之前必须先算好账。

熔断开关（kill-switches）和回滚自动化也是同样的招数。“回滚自动化将平均恢复时间从 47 分钟缩短到 4 分钟。按照我们目前的事故率，这相当于在本半年度避免了约 6 小时的停机时间。根据我们的毛利率和活跃用户数，这保护了价值 $X 的收入。”要么你写出这些计算过程，要么委员会默认写下一行平淡的影响描述。这笔账得由你来算。

经理的翻译问题

即使有一份完美的业绩包，编写它的工程师也无法让自己晋升。评定是一个同行评议的过程，业绩包要经过经理的筛选，经理必须在一群其他经理面前为其辩护。如果经理无法将非功能性的影响转化为房间里其他人能听懂的语言，无论业绩包里写了什么，它都会在评定中夭折。

在这个房间里，经理的工作比负责功能发布的工程师的经理更难。对于发布者，经理指向发布，全场点头。对于 AI 基础设施工程师，经理必须引导全场理解反事实框架（counterfactual frame），针对“我们怎么知道”进行辩护，并每次都重新锚定评定标准。做得好本身就是一种领导力，无法做到这一点的经理不应该领导 AI 团队。出错的代价并非理论上的：AI 项目赖以承重的工程师是最容易被挖走的，因为每个其他的 AI 团队都在招聘这种人才。让一名贡献公平的工程师获得“符合预期”评级的经理，实际上是在给竞争对手写推荐信。

通常能在评定室中奏效的翻译模式如下：

1. 以反事实开头。 “如果没有这项工作，我们这一半年度的情况会是 X。” X 是具体的：一个特定的事故、一个特定的成本线、或者一个本会推迟的特定功能发布日期。
2. 对标同行团队。 “没有进行这项投资的 Y 团队，本半年度遇到了 X 问题。” 委员会已经根据 Y 团队的工程师进行评定了；现在他们也要根据 Y 团队的结果进行评定。
3. 量化依赖图谱。 “委员会已经归功于其他工程师的三个功能都依赖于这项工作。” 发布工程师的影响力不会被削弱。支持工程师的影响力被正确地累加到总额中。
4. 预测下一半年度的杠杆作用。 “这项投资具有复利效应。下一半年度的路线图中有 N 个功能会因为这项工作而发布得更快。” 业绩包不仅是回顾性的；它还为工程师在下一个周期将获得的功劳设定了预期。

如果经理带着这四个排练好的招式进去，评定结果通常会反转。如果他们只说“我认为他们做了非常出色的基础设施工作”，则不会。

评定标准才是 Bug

更深层的问题是，这一切都不是工程师的错，也不是经理的错。大多数公司使用的职级评定标准是在“发布功能”意味着“编写构成用户可见产品表面的代码”的时代编写的。在 AI 时代，这已不再成立。用户可见的产品表面只是堆栈顶层的一个薄壳——评估套件、可观测性、成本防护、提示词管理、模型路由、熔断开关、回滚自动化——这些才是承担大部分工作量的部分。维护该堆栈的工程师是表面能够保持可靠的原因。将他们视为二等公民，仅仅因为他们的工作无法转化为发布公告，是组织层面的定价错误。

最早修正评定标准的公司将最终赢得所有人都在争抢的 AI 工程师。信号并不微妙：当一个 AI 组织的评定周期结束，而在下一季度离职的工程师是负责评估和基础设施的人员时，评定标准就是原因，评定标准也是解决方案。当发布是瓶颈时，以“已发布功能”作为代理指标是可接受的。在生产级 AI 中，发布不是瓶颈——保持事物的可靠性、可评估性和在预算范围内才是。评定标准应该反映这一点，任何规模化运营 AI 的领导团队都应该将修正评定标准视为与任何技术决策同等重要的第一季度优先级。

对于正在阅读本文、即将进入评定周期且没有功能可以展示的工程师来说：工作并非因为不重要而不可见。它不可见是因为业绩包写错了，评定标准也错了。这两者都不是对工程师能力的判决。业绩包是一个写作练习，它有一个已知的答案：反事实影响、同行团队对比、依赖图谱、远期杠杆。算好账，做好对比，指名道姓地列出依赖你的功能，并预测你下一半年度将产生的杠杆作用。平直的线条并不代表平庸的影响。它是一个需要不同 Y 轴的图表。