大概十年前，我刚升做技术总监时，最引以为傲的管理手段是“代码统计”。

我会看着Git的提交记录，看谁写的行数多，看谁解决的Bug多，看谁加班最晚。

那是一种简单粗暴但有效的“计件工资”时代。

那时候的逻辑是：产出 = 键盘敲击次数。

然而，自从团队全面引入了AI辅助编程（Copilot、Cursor等），这套KPI体系直接崩塌了。

一个初级工程师，配合AI，一天能写出以前一周的代码量，而且Bug率极低。

一个资深架构师，花了一整天思考架构、重构设计，只提交了50行代码。

如果还按代码行数给绩效，那个初级工程师就是明星，资深架构师就是混子。

更可怕的是，如果大家为了刷数据，利用AI生成一堆冗余的、看似正确实则难以维护的“垃圾代码”，那我们的技术债会像滚雪球一样爆炸。

当AI做了80%的脏活累活，我们剩下的20%，该如何定价？

这不仅关乎公平，更关乎我们鼓励什么样的工程师文化。

一、 告别“计件思维”：代码行数是毒药

首先，必须明确一条铁律：

在AI时代，代码行数（LOC）不再是绩效指标，甚至可以是负指标。

以前写一万行代码可能意味着工作量饱和。

现在，利用AI写一万行代码，可能意味着你“懒得思考”。

优秀的工程师应该利用AI去精简逻辑，把一千行的代码重构成一百行。

新的考核方向：不是“写了多少”，而是“删除了多少”，以及“维持了多少复杂度的系统”。

二、 新的考核维度：从“生产力”到“鉴别力”

既然AI是“超级实习生”，那么工程师的价值就体现在“管教实习生”的能力上。

我们需要引入几个全新的维度：

1. Prompt工程与问题拆解能力

AI很聪明，但它需要明确的方向。 我们要考核：工程师是否能将一个模糊的业务需求，精准拆解为AI能理解的任务序列？

• 差的工程师： “帮我写个订单模块。” -> AI生成一堆不可用的垃圾。

• 好的工程师： 拆分成数据库Schema、API接口定义、异常处理逻辑，一步步引导AI生成高质量代码。 这体现的是架构思维。

2. 代码审查的敏锐度

当AI写出80%的代码时，工程师的角色就从“创作者”变成了“编辑”和“审计”。

我们要考核：工程师从AI生成的代码里，抓出了多少个潜在的Bug？发现了多少个安全漏洞？或者是拒绝了AI多少次愚蠢的建议？

在AI时代，Catch Bug的能力比Fix Bug的能力更值钱。

3. 技术债的控制

AI非常喜欢写“能跑就行”的代码（比如用硬编码代替配置，或者忽略边界条件）。

绩效评估中必须加入“可维护性”的权重。

如果你的模块因为AI的滥用导致半年后没人看得懂，无论当时上线多快，绩效都要打折。

三、 从“产出量”转向“业务影响力”

以前我们评价一个功能，看的是“按时上线率”。

在AI辅助下，开发速度变得廉价且同质化。大家都能很快做出来。

这时候，拼的是什么？是“做正确的事”。

新的考核指标：业务价值交付。

• 工程师是否利用省下来的时间，主动去优化了用户体验？

• 是否深入业务一线，发现了真正的痛点，并用AI方案解决了它？

• 还是说，只是利用AI把以前三天的工作压缩到半天，然后用剩下两天半去摸鱼？

我们要奖励“用省下来的时间创造更大价值”的人，而不是奖励“用省下来的时间发呆”的人。

四、 警惕“刷分者”：防范AI带来的虚假繁荣

就像搜索时代的SEO优化一样，AI时代也会出现“AIO（AI Optimization）”绩效刷子。

比如，为了提高提交活跃度，故意把简单的功能拆成无数次提交；

或者为了显示代码量，让AI生成冗余的注释和文档。

管理者必须擦亮眼睛。

回归到本质：面试时的谈话，日常Review时的交流，对系统复杂度的把控。

有些东西是AI目前还伪造不出来的：那就是眼神里的光芒和对系统的整体认知。

如果一个工程师讲不清楚自己写的模块逻辑，哪怕全是AI生成的，也是不合格的。

五、 结语：评价“灵魂”，而非“躯壳”

写了20年代码，我越来越觉得，代码只是思想的载体。

以前，我们需要花费大量精力去打磨这个载体（语法、规范、实现细节）。

现在，AI帮我们把载体打磨得飞快。

所以，绩效评估的焦点，终于可以回归到“思想”本身。

我们评价的不再是那个打字的机器，而是那个指挥AI的灵魂。

未来的顶级工程师，是那些懂得“在什么时候按回车，在什么时候按删除，在什么时候关掉AI自己动手”的人。

当我们建立了一套公平的绩效体系，让每个人都能在AI的加持下获得成就感，下一步我们要做的，就是让这种创新成为常态。

不再怕犯错，不再怕试错，让组织像AI训练一样，在不断的迭代中进化。

下一篇预告： 第二十三篇 构建“实验型”文化：鼓励试错与快速迭代的容错机制