上周跟一个做技术管理的朋友吃饭，聊到一个让他头疼的事。

季度绩效评估，团队里有人用 AI 工具写了以前三倍量的代码，需求交付速度飞快。按传统标准，这绝对是高绩效。但他总觉得哪里不对。

"代码是写了挺多，但上线后 bug 也比以前多了。而且有些代码，他自己都说不清楚为什么这么写。"

这不是个案。当 AI 编码工具把"写代码"这件事的门槛拉到极低，传统的工程师绩效评估框架，基本上已经失效了。

以前的标准为什么不灵了

过去评估工程师，核心维度无非几个：代码质量、技术难度、问题排查能力、架构贡献。这些都建立在一个前提上——代码是人写的，写得好不好直接反映能力。

AI 改变了这个前提。

现在一个中级工程师借助 AI 工具，一天能产出以前三天的代码量。代码看着像模像样，命名规范、注释齐全、测试也有。但你仔细看，会发现有些实现绕了远路，有些边界条件没覆盖，有些设计决策——根本没有决策，AI 给了什么就用了什么。

产出的量上去了，但产出中"人"的含量变了。

这不是说产出多就是坏事。问题在于，你没法用同一把尺子去量"人做了多少"和"AI做了多少"。就像你给每个人配了挖掘机，然后按挖土量评绩效，那开挖掘机开得猛的人一定排第一——但你真正需要的是知道谁的施工方案最合理。

产出翻倍，但翻的是谁的值

我见过一个场景。一个工程师用 AI 工具两天重构了一个老模块，代码量翻了三倍，看着很漂亮。上线后连续出了两个线上问题。复盘发现，重构过程中丢掉了两个隐藏的业务规则，老代码里用一种很别扭的方式处理了某个边界 case，AI 不知道这个背景，直接"优化"掉了。

这位工程师能力不差，但他没搞明白老代码为什么那么写就动手了。速度快了，判断力没跟上。

另一个工程师，同一个迭代只完成了计划工作量的 60%。但他在需求评审时指出了两个逻辑矛盾，避免了一次无效开发；主动发现了一个核心链路的容错机制缺失，顺手补上了；还在 code review 里拦住了三个 AI 生成的潜在问题。

如果只看产出量，前者应该拿高绩效。但谁对团队的价值更大？

AI 时代，"资深"到底意味着什么

以前说一个人是高级工程师，潜台词是"代码写得最好的人"。现在得换一种定义——"最会做判断的人"。

AI 能写代码，但不能替你做判断。选择做什么、不做什么、用什么架构、哪些 AI 生成的代码有问题——这些是人的事。判断力才是 AI 时代工程师的核心竞争力。

所以绩效评估的逻辑要变：不是看你产出了多少，而是看你做了多少有效判断。

一个工程师如果一天写了 2000 行代码但没做什么决策，和一个工程师写了 500 行但每个设计选择都有明确理由，后者的价值密度更高。前者是 AI 的搬运工，后者是 AI 的指挥官。

几个可以落地的改变

第一，把"代码量"类指标从考核中拿掉。

如果以前还有人在看代码行数、commit 数量，现在可以彻底放弃了。AI 时代用代码量评估工程师，就像用字数评估作家——完全没意义。一个写了 300 字的精准方案，可能比 3 万字的废话文档价值高 100 倍。

第二，code review 从"查代码"变成"查理解"。

以前 review 看的是代码规不规范、有没有 bug。现在更重要的一件事是：这段代码你是不是真的理解？能不能解释每个关键决策的理由？说不清楚，说明这段代码不是"你的"，只是"你提交的"。我了解到有些团队开始做"代码答辩"——工程师定期讲解自己提交的核心代码，不是讲代码本身，而是讲决策过程。这个思路不错。

第三，加入"负向贡献"评估维度。

AI 时代最大的风险不是产出慢，而是产出太快但质量不过关，给系统埋了一堆隐患。一个工程师如果用 AI 快速完成了 10 个需求，但引入了 5 个线上隐患，他实际上是在给团队制造技术债。这种"快"是一种负向贡献——后面的人要花时间给他擦屁股。绩效评估中应该有这个维度的体现。

第四，重新定义"产出"。

产出 = 交付的业务价值 - 引入的技术债务。以前这个公式里的"技术债务"权重不大，因为人写代码的速度有限，债务积累也有限。现在 AI 把生产速度提上去了，债务积累的速度也同步加快了。一个迭代的"净产出"可能并没有看起来那么多。

一个粗略但有参考价值的框架

传统指标问题替代方向代码量 / commit 数AI 可以无限放大不看需求完成数不区分复杂度和决策含量看决策密度：这个需求涉及几个有质量的技术决策代码质量评分AI 生成的代码看着规范但可能缺乏深度设计看系统健壮性：上线后的故障率、回滚率技术难度AI 降低了实现难度的感知看隐患识别能力：code review 中发现过多少真实问题工作年限 / 职级AI 拉平了部分经验差距看判断力表现：在关键决策点的选择质量

1on1 里该聊什么

绩效沟通方式也要调。对于 AI 工具用得好的成员，你可能需要的不是激励，而是校准。

AI 工具用得顺手的人容易陷入"产出幻觉"——代码写得快，自己也分不清哪些是真正的贡献，哪些是 AI 的产物。久了容易高估自己的实际产出价值。

我建议在 1on1 中问一个很直接的问题：如果关掉 AI 工具，你还能以同样的速度完成吗？

这不是质疑，是帮他区分"真实能力"和"工具加持"。真正能力强的人，AI 是放大器；能力不够的人，AI 只是遮羞布。

另一个好问题：最近有没有主动拒绝过一个需求，或者拒绝过一段 AI 生成的代码？

能回答"有"的人，通常有更强的判断力。因为他知道什么不该做、什么不应该直接用。在 AI 时代，"不做什么"比"做什么"更能体现一个人的水平。

说到底

AI 没有改变绩效管理的本质——评估一个人对团队和业务的真实贡献。但 AI 改变了"贡献"的表现形式。

以前贡献 = 写出好代码。现在贡献 = 做出好决策 + 确保代码真的好。

如果你的绩效评估体系还在用两年前的标准，那你评估的不是"这个工程师在 AI 时代的真实价值"，而是"这个工程师使用 AI 工具的熟练程度"。这两件事完全不是一回事。

工具熟练度可以培养，判断力才是真正的稀缺资源。你的绩效体系应该奖励稀缺的那个。

AI 让"写代码"变得廉价，但让"知道该写什么代码"变得前所未有的重要。绩效评估如果不跟着调整，你就是在用马车的考核标准来评估汽车司机——看着速度挺快，但你根本不知道谁在真正开车。