AI 工程师晋升自评报告：让随机性工作在绩效评审中清晰可见

一位资深工程师走进晋升评定会议。他们上线了一个经过微调的重排序器（reranker），将检索质量提升了 8 个点。他们构建了评估框架（eval harness），将原本两周的 QA 周期缩短为一小时的 CI 门禁。他们编写了提示词（prompt）改动，带来了 2 个百分点的转化率提升。无论以何种合理标准衡量，他们都度过了决定性的一年。

他们没有获得晋升。这份绩效申请（packet）写出来读着就像是“我调了一些数字”。坐在旁边的同事上线了一个带有发布横幅、具备 QPS 和延迟指标以及周五演示的 CRUD 功能，结果反而获得了认可。委员会并非心怀恶意。它只是在用它所掌握的语汇，去评价一份没有将工作转化为该语汇的申请材料。

这种失败模式现在已经普遍到成为一种范式。AI 工程工作无法清晰地分解为评审委员会习惯评估的那些产出物。绩效模板是为以确定性方式交付的确定性系统编写的，而在 AI 技术栈中承担最具杠杆作用工作的工程师们正在为此付出代价。

绩效模板是为另一种工作而写的

标准的资深工程师绩效申请有三个核心支柱：一个带有发布日期的已上线功能，一个由你负责并带有 QPS 或 SLO 数字的系统，以及一个委员会可以验证的反事实（counterfactual）假设（“如果你没做这件事，X 就会出故障”）。它假设了一个工作可以清晰地转化为演示、仪表盘和事故处理的世界。

现在来看看 AI 工程师的一年：

• 重排序器（reranker）不是一个带有明确发布日期的功能。它在特性开关（flag）后分阶段上线，并经过了六周的逐步推进，因为没人敢信任带有概率性输出的一次性上线。它没有高光时刻。仪表盘只显示了一条略微上扬的平滑曲线。
• 评估框架（eval harness）不是一个带有 QPS 和延迟数字的系统。它是一个 CI 阶段的工具，团队之外没人直接使用。它没有生产环境的足迹。它的影响力体现在团队中其他每位工程师的交付速度上——而这恰恰是评审标准难以衡量的二阶杠杆作用。
• 提升转化的提示词（prompt）是由三个人在两个月内共同完成的。其中两人已经换了团队。如果有人费心去讨论归属权，对话往往会变成“大家都帮了忙”。
• 在概率性系统中，关于反事实的问题——“如果没有你，会发生什么？”——没有明确的答案。委员会期待得到一个数字。而诚实的回答是：“曲线会稍微低一些，低多少我们需要重新跑一次 A/B 测试才能估算出来。”

委员会在面对模糊性时，会采取委员会惯常的做法：默认采用申请材料所使用的框架。如果申请材料说“改进了检索质量”，委员会听到的就是“调了一些超参数”。如果材料说“负责评估框架”，委员会听到的就是“写了一些脚本”。这并不是因为工作微不足道，而是因为这份申请材料没能将工作转化为委员会通用的价值语汇。

将产出物定义为“系统”，而非“模型”

AI 工程绩效申请中最大的杠杆点在于对交付内容的定义。工程师习惯于称呼模型——重排序器、提示词、微调——因为这是他们投入时间的地方。而委员会在解析申请材料时，寻找的是系统。

比较：

• “我提高了评估覆盖率。”
• “我构建了评估框架，将提示词改动的流程从两周的 QA 周期缩短为一小时的 CI 门禁。”

工作是一样的。前者读起来像是日常维护。后者则是一个具有前后对比的系统，委员会可以将其与他们评审过的任何其他基础设施项目进行对标。

比较：

• “我改进了系统提示词。”
• “这次提示词改动需要从 17 条相互作用的指令中分离出其中一条，其效果仅在长上下文时显现——此前的每次尝试都动错了指令，导致上游指标出现回退。”

前者听起来像是一个拼写修复。后者则描述了一个其他工程师曾遇到过而你成功跨越的难度曲线。这才是评定委员会真正用来划分资深（Senior）与首席（Staff）职级的语言。

这种准则是：为从未评审过 AI 工作的人编写绩效申请。不要假设他们知道“上线重排序器”意味着一套离线评估框架、一个在线 A/B 测试、一个特性开关、一套回滚方案、一份成本分析以及一个生产监控方案。把这些列出来。每一项都是委员会已经懂得如何评估其价值的产出物。

用 A/B 测试的严谨性量化反事实

委员会对于反事实的直觉——“如果没有你，会发生什么？”——比表面上看起来更敏锐。他们不是在要求假设，而是在要求一个可证伪的对比。产品团队每个季度都使用 A/B 测试来回答这个问题。AI 工程师也应该以同样的标准要求自己。

薄弱版本：“新的重排序器提升了检索质量。”

强力版本：“该重排序器在特性开关后进行了为期三周的 50/50 分流测试，与旧模型对比。检索质量提升了 8.2 个点（Hit@1 从 62.7% 提升至 70.9%），样本量 N=2.3M 次查询，p < 0.001。同期下游转化率提升了 1.4 个百分点。我们在全量上线前又保持了 90/10 的实验两周，以确认长尾延迟没有退化。”

强力版本读起来是工程实践。薄弱版本读起来则像是一种直觉。同样的工作，在委员会眼中的可信度相差三个数量级。

同样的严谨性也适用于评估结果。“覆盖率提升了”不应该出现在资深工程师的绩效申请中。“针对合规内容切片的评估覆盖率从 41 个案例增加到 1,820 个案例，涵盖了我们此前未能察觉的 14 种失败模式；其中三种模式在上个季度的 CI 中拦截了原本会随旧框架上线的回归问题”，这才是一句合格的资深工程师绩效描述。

当反事实确实模糊时——“我们不知道如果不做会发生什么”——请明确说明并给出界限。“我们对提示词改动没有清晰的反事实对比，因为我们在没有保留组的情况下上线了它，但在改动当周，转化曲线打破了之前的趋势，且期间没有其他并发上线；最保守的归因是 60% 的提升，最慷慨的是 100%，我采用的是中间值。”委员会尊重那些能够直面不确定性的工程师。他们不信任那些隐藏不确定性的工程师。

显化二阶杠杆作用

评估框架 (eval harness) 是一个典型案例。它在 CI 中运行，阻碍合并，并生成一个除了团队之外没人会看的仪表盘数字。按照所有传统的衡量标准，它是隐形的工作。但按照真正重要的标准——团队交付安全 AI 变更的速度——它是整个季度最核心的支撑成果。

工程师们经常埋没这类工作。他们在子列表里提到这个框架。他们列出它所促成的四个项目，就好像这些项目与它无关。他们让委员会以为这个框架是凭空出现的，或者是某人在空闲时间顺便做的。

翻译：

• 埋没：“我还构建了一些团队正在使用的评估基础设施。”
• 显化：“我构建的评估框架是今年接下来的四位工程师项目的先决条件。其中三个项目——安全分类器升级、长上下文路由和客户支持代理——都在他们自己的晋升材料 (packets) 中明确提到，是这个框架让他们的工作成为可能。如果没有它，这些项目中的每一个要么会在没有质量关卡的情况下发布，要么会因为被该框架取代的手动 QA 周期而推迟。”

第二种表述指明了一个杠杆链条，委员会可以通过阅读其他材料来核实。它还创造了一个正向反馈循环：下游每一位在自己的材料中感谢该框架的工程师，现在都成了为你作证的自发证人。

同样的逻辑也适用于 Prompt 库、黄金追踪测试集 (golden-trace test suites)、归因看板、模型路由层，以及 AI 团队为自己构建的任何其他平台化工作。如果你构建了公司内其他所有 AI 项目都依赖的东西，你的材料应该把这作为头条新闻，而不是脚注。

标明其他工程师遇到的难度曲线

AI 工作中的一个常见模式是，最终落地的变更往往是第七次尝试，而前六次都以不同的方式失败了。写着“交付了变更”的材料低估了这项工作。写着“在先前六次尝试触动了相邻杠杆并导致上游指标退化后，分离出了正确的干预措施”的材料，则告诉了委员会这项工作属于什么难度等级。

标明难度并不意味着夸大困难。它意味着写下一句校准委员会可以用来区分“工程师转动了一个旋钮”与“工程师在一个大多数干预都会使情况变糟的系统中诊断出了非显性交互”的话。后者在任何工程领域都是高级 (Senior) 与 Staff 工程师的区别信号。AI 工作往往具有这种特征——系统交互密集，故障模式是涌现的，而且在衡量之前，错误的干预通常与正确的干预难以区分。

几个效果良好的具体表述：

• “三位队友曾尝试过此操作并回滚；先前的失败对于确定到底应该在哪个维度上采取行动具有启发性。”
• “该 Prompt 有 17 条指令在长上下文长度下相互作用；隔离出哪一条指令负责，需要对评估集进行逐条指令的消融实验 (ablation)。”
• “微调需要策划一个包含 4000 个示例的数据集，其中每个示例都由领域专家标注，因为显式的合成数据方法在我们的对抗性探测下失败了。”

这些句子每一句都只有一行。每一句都将一个条目从“做了这件事”转变为“跨越了定义职级的难度门槛”。

经理的那一半职责

如果校准委员会从未见过 AI 工作被校准，任何工程师都无法从委员会手中救回一份材料。在任何房间里，第一个被提拔的 AI 工程师不仅是在校准他们自己，也是在为后续每一位 AI 工程师校准委员会的词汇。他们的材料成为了基准。如果它将工作描述为“调整了一些数字”，那么下一份使用系统化和反事实语言的材料在与先前的描述对比时，会被视为水分。

放任这种情况发生的经理，其高级 AI 工程师不会得到晋升，下一位 AI 工程师也不会得到晋升，最终两位都会流失到那些校准委员会已经做好功课的公司。

经理的职责是预先简要告知委员会。不是在校准会议本身——到那时就太晚了——而是在几周前编写评定标准 (rubric) 期间，在讨论“我们如何谈论这类工作”的过程中。简报很短：

• AI 工作是在 feature flag 后增量交付的；发布日期是一个爬坡过程，而不是一个横幅时刻。
• 评估框架是平台工作，应像对待任何其他平台贡献一样给予积分。
• 随机系统中的反事实是 A/B 测试的解读，而不是功能“已发布/未发布”的二元对立——应根据实验设计的严谨性而不是结论的确定性来评判它们。
• Prompt 和微调的作者身份通常是共享的；应像现有的标准对待共享代码库所有权那样对待它。

如果经理没有做这些铺垫工作就走进校准会议，那是在要求委员会在社会压力下、针对一份不符合模板的材料实时发明评定标准。委员会将退回到模板。工程师将为此付出代价。

组织层面的觉醒

为确定性系统编写的职业阶梯评价标准系统地低估了 AI 工程工作的价值。这种工作是真实存在的，其杠杆效应巨大。但产出物并不符合现有模板。在面对模糊性时，评审委员会往往会默认套用模板。没能完成语境转译的工程师会被低定职级。而那些被低定职级的工程师会流向已经更新了评价标准的单位。

这种套利是真实存在的，且正在发生。更新了定级话术的公司能留住最优秀的 AI 工程师。而不更新的公司只能眼睁睁地看着人才流向已经做出改变的对手。晋升材料是直接的载体，但更深层的失败在于评价标准的设计——而更深层的机会在于，工程组织能在人员流失数据显现之前，花时间更新评价标准。

如果你是等待晋升的工程师，请写出一份委员会能读懂的材料。如果你是经理，请提前向评审会通气。如果你身处评审席，请提出你的评价标准中尚未涵盖的问题：对于一个已经上线、没有 QPS 指标、被其他工程师所依赖、且优化了概率分布（而非仅仅交付了一个功能）的产出物，正确的衡量尺度是什么？在 2026 年能回答这个问题的团队，将留住那些核心工程师。而没能回答的团队，则是在进行一场尚未预约、且代价无法估量的离职面谈。