看不见 AI 工作的绩效评估模板

你最强的 AI 工程师在这个周期里整理了一个 eval 集、校准了一个评判提示词、并且砍掉了两个最终被证明任务形状不匹配的功能。这些工作没有一条能够塞进评估模板里。于是校准会议要么夸大该工程师最不在乎的产物——PR 数量、设计文档、值班时长——要么编织一段散文来给一个框架根本无法支撑的高评级辩护。无论哪种方式,评分标准和现实正朝着不同的方向拉扯,而这位工程师心里有数。

这套模板是为确定性软件而写的。它奖励那些你能数得过来的东西:发布了多少行代码、拥有多少服务、解决了多少个事故、值班了多少个小时。而 AI 路线图是被另一种形状的工作推进的:整理一个有代表性的 eval 切片;在模型漂移下守住一个行为包络;拒绝发布一个任务形状不适合模型的功能;耐心地缩小评判提示词和人类意图之间的差距。这些工作几乎都不产出评分标准所擅长计算的那种产物。

抽象地说这不是新问题——每一波工程浪潮都有不适合上一版模板的工作。新的地方在于速度。在这个周期里建出了最受欢迎功能的 AI 工程师,和砍掉了两个本来会发布得很糟糕的功能的 AI 工程师,按评分标准的账面记法,可能产出几乎相同的绩效证据,而这套框架没办法告诉你该提拔哪个。

评分标准是为另一种形状的工作而写的

大多数工程阶梯本质上问三个问题,只是用不同的语言包装:你拥有的系统有多复杂、你发布了多少、你带了多少人。其隐含的物理模型是:工作产物是代码、代码进入生产环境、生产环境的行为足够确定,以至于"能用"和"不能用"是有意义的二分类。

AI 功能工作打破了这条链条上的每一个假设。

工作产物不是代码——而是一个行为包络:一个能代表用户真实行为的 eval 集;一个对照该包络给输出打分的评判;一段把模型行为拉进包络的提示词;以及一个在模型漂移时守住底线的发布闸门。代码只是其中最小的一部分,而且常常是下个季度新模型一来就最有可能被删掉的那部分。

"能用"也不是二元的。一个功能可以通过它的 eval 套件,却在 eval 集没覆盖到的某个切片上悄悄退化。一个功能可以因为评判校准漂移、而非底层行为变化,而 fail 掉 eval 套件。一个功能可以在团队当时一致认可的可接受分数下发布,一个月后在用户面前却变得不可接受。评分标准里指不出一条"测试通过"的线。

AI 功能工作里的带新人也不像是把代码库教给别人。它更像是教别人把混淆矩阵当作产品问题来读;识别出"切片 A 上的回归是可接受的,因为切片 A 只占 0.3% 的流量";以及凭直觉感觉到一个评判提示词什么时候开始奖励错误的东西。这些技能没有一条出现在评分标准里,而且其中大多数都很难通过 code review 传递。

诚实的总结:一套基于发布支付服务训练出来的评分标准,被拿来评价一个主要产物是一个校准过的评判的人。类目对不上,校准会议无处安放这种工作。

同行反馈看不到 eval 质量

大多数公司填补评分标准空白的方式是同行反馈——三到五位同事各写一段,讲讲这位工程师做得好的地方和可以成长的地方。其假设是:同事既然和工程师一起工作过,就有资格对工作质量发言。

对于确定性软件来说,这大体上成立。同事能读 PR、评估架构、判断代码质量、注意到缺少测试。他们有能力 review 这份工作,因为这份工作以他们被训练能够读懂的产物形式呈现出来。

对于 AI 功能工作,同行往往没有能力 review 这份工作,而且不知道自己没能力。读别人的 eval 集需要分得出有代表性的样本和粉饰过的样本的区别。读别人的评判提示词需要看得出评判会奖励的口头习惯。读别人的 kill 决策需要重建那次任务形状分析,以理解为何砍掉它是合理的。一个能自信地编辑提示词、但从未构建过 eval 的同行,无法评价 eval 质量,就像一个会用数据库的人无法评价索引设计一样。

你最终拿到的是可被 review 的替代物。同行会写沟通能力、响应及时、设计讨论里的帮助、愿意结对——这些他们能观察到的东西。真正的产物——eval 覆盖率、评判校准、提示词考古——只会得到一句类似"为团队负责 AI 质量故事"的笼统语句,经不起任何推敲。

结果是一种悄悄的倒错:同行最喜欢其 AI 工作的工程师,往往是关于 AI 工作沟通最多的那个,而不是 AI 工作最严谨的那个。沟通是真实的价值,理应被奖励,但它不应该是一份绩效材料里唯一的 AI 信号。

校准会议漂移,因为经理在拿组织看不见的努力打分

校准会议是同一段位的经理们把下属拿出来对比、把评级强制拟合到分布上的那个会议。它也是评分标准错配最明显、并且被遮掩过去的地方。

AI 功能那个经理带着一份证据是 eval 覆盖率曲线、评判校准 delta、记录下来的行为包络、上线前被砍掉的功能的报告走进会议。他/她为高评级辩护,因为他/她能看见这份工作,知道它的代价。屋里其他经理——管平台、管基础设施、管产品表面的——没办法评估这些证据。他/她们只能看那段散文听起来是否有说服力。

接下来发生什么,决定了这位 AI 功能工程师能不能拿到一份公允的评估。诚实的版本:AI 功能经理学会把证据翻译成对评分标准友好的产物——"领导了一项让回归事故下降 40% 的质量计划"、"主导了模型迁移的跨团队对齐"、"推动了 LLM 功能评估框架"。这种翻译不是假话。它也不是实际发生的事情。实际的工作是和三千条 trace 坐在一起,发现评判在那些需要干脆答案的问题上奖励了犹豫的回答。评分标准里没有任何一行对应这件事。

不那么诚实的版本:AI 功能经理学会了夸大版的故事行得通、原汁原味的故事行不通,然后开始拿组织其他部分根本不承认的努力来打分。门槛悄悄发生分歧。三个周期之后,处在 N 级的 AI 功能工程师所产出的证据,无法把一个非 AI 工程师送到 N 级——不是因为他/她的工作不够真实,而是因为评分标准从一开始就没让这种工作算数。等组织注意到这道鸿沟时,纠正的代价往往落在 AI 工程师身上,他/她们因此失去了用框架拒绝看见的工作所赢得的位置。

出路不是在翻译上更卖力。出路是把评分标准修了。

模板要看见这份工作需要补的内容

评估模板是一份政策文件。你要求什么就奖励什么,你不要求的就慢慢消失。如果模板可以被有意识地修订——不是作为一次性的特例,而是作为永久的扩展——那么以下这些条目必须存在。

**Eval 所有权和质量。**不是"这位工程师有没有写 eval",那是个谁都能过的勾选框。真正的问题是:他/她拥有的 eval 集是否能代表生产流量;他/她包含进去的失败 case 是否对应着用户可见的回归;切片是否能孤立出领导层在意的行为;另一位工程师能否在不重建上下文的情况下,用这个套件去诊断一个真实事故。这是提示词工程里对应"端到端拥有系统"的那条线。这是防止已发布质量漂移的工作。

**提示词和评分标准的溯源。**当工程师改动了提示词,你能否从产物里看出原因、当时还有哪些备选、那次迭代里学到了什么?当工程师改动了评判 rubric,你能否还原改动背后的校准数据?提示词考古——能像读 code history 一样读别人的提示词历史的能力——是 AI 工作里的版本控制纪律,做得好的工程师,即便在中级,也在做领导级别的工作。

**模型迁移领导力。**一次模型迁移相当于 AI 领域的数据库迁移:沉默的回归、长尾的边缘 case、不对称的下行风险,而且大部分工作在出问题之前是看不见的。那位悄悄带领团队跨过三次模型升级、没有出现一次用户可见事故的工程师,做了承重的工作,值得在评分标准里单独占一行,与"发布功能"那行分开。

**有数据支撑的 kill 决策。**这位工程师在这个周期里砍掉的两个功能,帮你省下了你本来会后悔的发布。如果你的评分标准只奖励发布的功能,你就构造了一个惩罚 AI 团队最重要判断力的框架。给 kill 决策留一条线,带上支撑它们的证据——eval 套件说不行、任务形状不合适、行为在现有模型上无法挽回——这是把"拒绝"作为一种胜任力来奖励的方式。

**持续质量的看护。**发布后的前六周通常是 AI 功能悄悄退化的时候——eval 漂移、评判漂移、模型升级带来的提示词腐烂、违反 eval 集隐含假设的流量变化。那位把发布后的质量当作持续工作而非已关闭工单的工程师,正在做把演示变成持久产品的工作。需要有一行给这件事。

你会发现这些条目并不要求新的证据——它们要求评分标准去问那些工程师本就在产出的证据。产物本来就存在。模板只是没有任何位置来接收它们。

领导力视角

那个建筑师式的领悟令人不舒服:你为发布 AI 功能而搭起来的团队,正在被一个还不会看见他/她们的框架衡量。每一个评分标准维持不变的周期,这道鸿沟都在拉大。那些能把工作翻译进遗留模板的工程师得到了晋升。那些做着最深的 AI 工作、却不能或不愿翻译的工程师被低估了。你的 AI 组织内部的门槛悄悄地从工程其他部分的门槛上偏移开来,而你直到有人离开、工作崩掉才会发现。

这件事不会通过雇一个"AI 评分标准顾问"或者在现有模板上加一个四点 AI 附录解决。它的解法是把评分标准当成一个产品表面,跟随它所衡量的工作以同样的速度迭代。第一次带着新条目走进校准会议时,讨论会更难——没有 AI 报告人的经理会反弹,评分标准的语言需要修订,每个级别的门槛需要重新锚定。这种困难,正是评分标准终于开始做它的本职工作。

评分标准不是敌人。假装 AI 工作能塞进旧位置的那一版评分标准才是敌人,而它能存活下来,只因为替代方案让人不舒服。明确命名这份工作的那一版评分标准,才是让做这份工作的人被看见、被支付、被晋升的那一版。这是唯一能撑过第一个周期的版本。