团队全面接入AI编码工具三个月了。表面上看，大家都在用Copilot、Cursor，代码产出量几乎翻倍。但最近我开始有一种不安：这种繁荣是真的吗？

事情起因是上周的代码审查。一个资深同事的代码，风格和架构都挺好，但AI生成的痕迹很重。另一个年轻同事，产出数字不太好看，但每段代码都看得出是思考过的。

我突然意识到，自己犯了一个管理错误：把工具使用量当成了能力指标。

用得最多，不等于用得最好

大部分团队在推广AI工具时，管理者都会看一个数字：采纳率。多少人用了？用了多少次？代码生成占比多少？

这些指标容易量化，向上汇报也好听。但它们掩盖了一个事实：用得多不代表用得好。

我的观察是，团队在使用AI工具时，大致分成了三类人：

第一类：喂料型。把需求描述扔给AI，拿到结果复制粘贴。代码能跑就行，不深究实现逻辑。这类人看起来产出很高，但代码质量和架构一致性埋了不少隐患。

第二类：对话型。会反复调整prompt，审查AI的每一行输出，根据自己的理解做修改和取舍。产出速度不一定最快，但代码质量稳定，出了问题能自己排查。

第三类：架构型。把AI当执行层，自己做设计决策。先用AI快速验证思路，再决定哪些该保留、哪些要重写。这类人产出效率最高，但更关键的是，他们对系统的理解在持续加深。

第一类和第三类的差距，不在工具使用频率上，而在决策密度上。

决策密度：被忽视的关键指标

什么是决策密度？简单说，就是在一次与AI的交互中，工程师做了多少个有意义的技术判断。

喂料型的人，一次交互可能只做了一个决策——"看起来能用，提交"。对话型和架构型的人，同样一次交互可能做了十几个决策：这里应该用策略模式而不是硬编码、这个边界条件AI没考虑到要补上、这段代码虽然能用但放在这一层不合适……

决策密度高的人，AI是放大器，把他的能力放大了十倍。决策密度低的人，AI是替代品，正在慢慢取代他的工作。

这个区别在短期内看不出来。代码行数差不多，功能都能交付。但半年以后，架构理解力和独立解决问题的能力，会拉开巨大差距。

传统绩效指标的失效

这是管理者需要正视的问题：传统的绩效衡量方式，在AI时代正在失效。

完成任务数？AI让所有人都能完成更多任务。代码量？AI让代码量变得没有意义。交付速度？大家都在加速。Bug数？AI生成的代码可能让Bug更隐蔽，不是更少了。

我最近试着调整评估维度，重点关注三件事：

第一，判断力。AI输出的代码有明显问题时，他能不能发现？发现了能不能改好？如果AI给了一个"看起来对"但其实有隐患的方案，他会直接采用还是会质疑？

第二，架构视野。AI能写函数级别的代码，但做不了模块级别的架构决策。一个工程师是不是还清楚自己写的代码在整个系统中的位置？还是已经退化成了"AI写什么我就提交什么"？

第三，提问质量。会问问题的人，从AI那里得到的价值远高于不会问的人。问题的精准度直接决定了AI输出的有效度。一个能问出"这个场景下用观察者模式还是发布订阅模式更合适"的人，和一个只会问"帮我写一个事件系统"的人，差距不是一般的大。

谁在增值，谁在贬值

说实话，这些观察让我重新审视了团队里每个人的状态。

有些人以前我觉得技术扎实、可以放心交付，但现在发现他在AI工具面前的适应力并不好——不是不会用，而是使用方式停留在"喂料"层面，自己的判断力在退化。

有些人以前我觉得还行、不算突出，但AI工具反而放大了他的优势——他本来就善于思考和提问，AI给了他一个高效的执行层之后，产出质量跃升了一个台阶。

AI不改变人的本质，但会放大原有的差距。善于思考的人借助AI飞得更高，不善于思考的人用AI掩饰得更深。

管理者该做什么

我的做法是，开始有意识地在1on1里加入几个观察：

让他讲讲最近用AI解决的一个技术问题，重点听他怎么描述自己的角色——是"我让AI做了什么"还是"AI给了我几个方案，我选了这个因为……"

让他review一段AI生成的代码，看他能发现多少问题。

让他描述某个模块的设计思路，看他是不是还理解全局，还是只了解自己负责的那几个函数。

这不是考试，是了解每个人在AI时代的真实状态。然后针对性地给反馈，帮他往更高决策密度的方向发展。

说到底，AI工具的普及让"谁更值钱"这个问题变得更复杂了。以前看技术深度，以前看经验年限，以前看交付速度。现在这些标准都还在，但多了一个维度：你是AI的主人，还是AI的附庸。

作为管理者，我们需要更新自己的评估框架。不然真正值钱的人可能被低估，表面繁荣的人可能被高估。等到潮水退去，才知道谁在裸泳。