OpenAI前不久宣布，SWE-bench Verified已经不再适合用来评估前沿编码能力。一个专门为衡量代码能力设计的基准，被AI冲破上限之后反而失去了意义。这件事本身不意外——当某个维度变得可优化，它迟早会被优化到偏离初衷。真正有意思的是，这个逻辑不只适用于AI，它几乎完美地映射了工程团队考核的困局。

我们比历史上任何时期都拥有更多的工程度量手段——代码量、PR数、故事点、交付率、代码覆盖率、线上故障数、响应时长……每个团队都在量，每个管理者都在看，但几乎没有谁敢说，自己的考核体系真的反映了团队的工程能力。

原因很简单：你量的全是噪音。

当度量变成目标

古德哈特定律讲了两百年了，但工程团队似乎永远不会吸取教训。或者更准确地说，不是不懂，是没得选。

当你把代码量作为考核维度，团队就会产出更多代码——但不是更好的代码，而是更多的代码。冗余的逻辑、重复的实现、可以三条线搞定非要写三十行的函数，全都冒出来了。当你把PR数作为活跃度指标，开发者就会把一个功能拆成五个PR提交。每个PR的diff都很短，看起来review很快，但实际上增加了集成成本和上下文切换。当你把故事点完成率作为交付效率，敏捷估算就变成了一场心照不宣的通货膨胀——这个需求本来3个点能做完，报5个点吧，万一有 unforeseen 的情况呢？

这不是团队在偷懒，也不是谁在恶意钻空子。这是理性个体面对激励体系的理性选择。你的考核体系在说什么，你的团队就会优化什么。问题是，你考核的维度和你真正想要的成果之间，往往有着一道巨大的鸿沟。

我见过一个团队，代码覆盖率指标定在80%。所有人都在拼命写测试，覆盖率的数字确实上去了。但仔细看那些测试——大量只测了happy path的壳子，断言检查的是"函数返回了结果"，而不是"函数返回了正确的结果"。覆盖率80%，有效测试大概不到30%。更讽刺的是，为了凑覆盖率去写的那些无意义测试，后来成了重构时的负担——改一行业务代码，要改二十行测试代码，开发体验反而更差了。

度量本身没有罪，罪在于把度量当成了目标。一旦某个数字和绩效挂钩，它就不再是观察的工具，而是行动的指挥棒。而指挥棒永远只能指一个方向，工程价值却是多维的。

最有价值的工程活动，恰好最难量化

这可能是绩效主义最深的盲区。

一个资深工程师最具价值的贡献是什么？是在需求评审时指出了方案的设计缺陷，让团队避免了三周的开发浪费。是.code review时发现了一个并发场景下的竞态条件，阻绝了一个可能导致资金错账的线上事故。是在技术选型时否决了一个看似时髦但和业务场景完全不匹配的方案，省下了未来半年的重构成本。

但这些东西在你的考核体系里，一项都看不到。

需求评审提出反对意见？在有些人眼里这叫"不配合"，叫"消极"。发现并阻止了事故？事故都没发生，怎么证明你阻止了？万一你是过度紧张呢？否决了一个方案？方案还没落地就被毙了，没有结果数据，谁说得清你的判断是对是错？

这些工程活动中最有价值的部分——判断力、预见性、风险识别——恰恰是不可量化的。它们的价值体现为"没有发生的事情"：没有返工，没有事故，没有技术债雪崩。而一个以量化指标为核心的考核体系，根本无法看见这些"不存在的价值"。

结果就是，考核体系系统性地低估了一种人，又系统性地高估了另一种人。

被低估的是那些"堵枪眼"的人。他们凭借经验和判断力，在问题还没发生时就将其消弭于无形。在考核表上，他们的表现平平——需求按时交付，没什么亮点，也没出什么问题。他们看起来是在"正常工作"，实际上是在持续地为团队规避风险、降低成本。

被高估的是那些"救火英雄"。同样是线上事故，一个团队平时做足了防御，事故很少发生，考核数据平平。另一个团队疏于预防，事故频发，但每次都有人站出来英勇救火，加班加点恢复服务，年终PPT上全是"攻坚克难"的故事。在大部分考核体系下，后者得分更高。

这套逻辑荒谬吗？荒谬。但它在无数团队里每天都在上演。

个人最优解，团队最差解

绩效体系的设计者通常有一个隐含假设：如果每个人都在自己的维度上做到最优，团队自然就会最优。

这是博弈论里最经典的反例。

故事点完成率挂钩个人绩效，会发生什么？每个人都优先挑容易做、可量化的需求，那些真正重要但复杂的需求被无限期搁置。代码review深度挂钩review数量，会发生什么？每个人都在追求review的速度，"看起来没问题"替代了"我确认这段代码在所有边界条件下都是安全的"。个人代码产出挂钩晋升，会发生什么？没有人愿意写公共基础设施，因为基础设施的代码算在谁头上？没有人愿意帮别人debug，因为帮别人解决问题产不出自己的代码。

这就是囚徒困境的工程版本。每个人都做出了对自己最有利的选择，但汇聚到团队层面，整体产出反而下降了。

在金融业务场景下，这种错位尤其明显。金融系统对稳定性和合规性的要求极高，这意味着最有价值的工作往往是无形的风控和防御——权限隔离、数据校验、异常处理、合规检查、审计日志。这些工作不会产生任何用户可见的功能，在需求列表里也不占优先级，但少了它们，系统就是一颗定时炸弹。然而在以"可见产出"为核心的考核体系下，做这些事情的人和做新功能的人相比，毫无竞争力可言。

我了解到一个做法，某团队把"线上事故减少率"作为考核维度。听起来很合理对吧？但执行下来发现，事故减少了不是因为系统变健壮了，而是因为大家不愿意报事故了。小问题私下修掉，能不提单就不提单，真捂不住的大事故才不得不走流程。数据上看事故率在下降，实际上透明度在恶化，团队的信任基础在瓦解。

换一个维度，换一个说法，同一个陷阱。

来自上方的KPI和来自下方的表演

考核体系的另一个结构性问题，是信息的不对称。

制定考核维度的人——通常是技术管理者或HR——看到的和一线工程师经历的，完全不是同一个世界。管理者关心的是季度交付速率、资源利用率、团队稳定性这些可汇总的数字。工程师面对的是具体的代码纠缠、历史包袱、不合理的deadline、跨团队的依赖阻塞。两者的坐标系就不在同一个参照系上。

于是，绩效评估变成了一场精心编排的表演。

每到考核季，所有人都开始写"述职报告"。这份报告与其说是自我评估，不如说是一份营销文案。如何把日常工作包装成"项目攻坚"，如何把被动响应包装成"主动规划"，如何把碰巧赶上的红利包装成"战略远见"——这些才是真正决定绩效得分的技能，跟工程能力没半点关系。

更微妙的是，善于自我包装的人往往考核得分更高，而默默做事的人反而吃亏。这不是管理者的偏见——在信息不对称的情况下，谁呈现的信息更清晰、更有叙事感，谁就更容易被"看见"。但"被看见"和"有价值"之间，并没有等号。

我听过一个很刻薄但很精准的说法：绩效考核和代码quality有个共同点——都是garbage in, garbage out。输入的是失真的自我评估和片面的管理者印象，输出的自然是扭曲的绩效结果。但代码至少还有测试用例兜底，绩效结果却是直接作用于人的真金白银和职业发展。

度量可以有，主义不行

说到这里，可能有人觉得我在反对所有度量。不是。

工程团队需要度量。交付周期、部署频率、故障恢复时间、系统可用性——这些数据是团队健康度的信号灯，是发现问题的诊断工具。DORA指标也好，SLA也好，它们作为观察手段是很有价值的。

问题出在"主义"二字。当度量从"观察工具"升级为"评价标准"，从"帮助团队改进"变成"给团队打分"，性质就彻底变了。观察工具允许你有盲区，评价标准不允许。所以你会拼命让指标好看，而不是让系统真的好。

我观察到一个有意思的现象：越是成熟的技术组织，越倾向于把度量数据和绩效评价做切割。度量数据对全员透明，用于团队改进的讨论，但不直接用于个人考核。个人的评价更多依赖同行反馈、管理者判断和长期结果——这些"模糊"的方法反而比精确的指标更接近真实。

模糊不等于随意。一个整天和团队待在一起的技术管理者，对每个人的能力和贡献有直观的判断，这种判断当然有偏差，但偏差的方向是随机的，不会像量化指标那样系统性地扭曲激励。而量化指标的偏差是系统性的，方向是确定的——它永远在鼓励你优化指标本身，而非指标背后的价值。

回到开头那个SWE-bench的例子。当AI的代码能力被一个benchmark推到了上限，benchmark失效了，但AI的编码能力并没有因此失去意义。同样的道理，当你的团队考核指标被"优化"到了好看的程度，数字失效了，但团队的工程能力才是那个真正根本的东西。

也许真正该问的问题不是"怎么设计更好的考核体系"，而是"我们是否需要一个统一的标准来评价本质上不可比较的工作"。架构决策和需求交付，风险预防和技术攻坚，知识传承和代码产出——它们是不同维度的事情，硬要放进同一个评分框架里，结果必然是削足适履。

接受工程价值的不可完全量化，不是放弃管理，而是诚实地面对现实。在这个现实之上建立的管理方式，比在虚构的精确度上建造的指标大厦，要可靠得多。

至少，它不会让团队花力气去优化那些数字，而不是优化那些真正重要的事情。