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

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

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

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

以前的标准为什么不灵了

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

AI 改变了这个前提。

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

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

什么是 AI Native

过去两年，大多数公司做的事情是"AI+"——在已有产品上叠加一层 AI 能力。搜索加个对话框，客服加个机器人，IDE 加个 Copilot。本质上，产品架构没变，AI 只是一个插件。

AI Native 完全不同。它不是"给产品加 AI"，而是"用 AI 重新定义产品"。

区别在哪里？

• AI+ 产品：传统搜索引擎 + AI 摘要 = 还是搜索引擎
• AI Native 产品：Perplexity = 答案引擎，搜索这个概念本身被重新定义了

前者是增量优化，后者是范式转移。

AI Native 的三个核心特征

1. 交互范式的重构

传统软件的交互模型是命令式的：用户点击按钮、填写表单、执行操作。每一步都需要用户理解系统的抽象模型。

AI Native 产品的交互模型是意图式的：用户表达目标，系统理解意图并执行。用户不需要知道系统内部有多少模块、多少步骤。

加州大学尔湾分校做过一个跟踪了20年的调查，记录人们盯着电脑屏幕时每次切换注意力的时间间隔。结果是这样的：

2004年，150秒。2012年，75秒。2016年，47秒。2025年，还是47秒。

更有意思的是另一组数据：一旦注意力断了，重新回到专注状态，平均需要25分26秒。

也就是说，一个工程师一天能进入心流状态的次数大概就那么五六次，每次被打断后要浪费近半小时才能重新进入状态。那么问题来了——每天早上那个雷打不动的站会，打断了几次？

大部分站会已经变了味。

站会最初的设想很好：快速同步，暴露阻塞，15分钟搞定。但现实中，大多数团队的站会已经退化成了一场轮流汇报。

每个人说三句话——昨天做了什么、今天打算做什么、有没有阻塞。说完了，其他人该摸手机摸手机，该走神走神。轮到Leader问"还有什么问题吗"的时候，全场沉默。

这不是同步，这是仪式。一种管理者用来确认"大家都在"的仪式。

如果信息不通，该修的是管道，不是开会。

有个场景你一定不陌生：一个技术很强的Leader，手下的活几乎都过他的手。白天开会，晚上写代码，周末review。团队成员反而很闲，等着他分配任务，等着他把方案定好。

这个人累得半死，团队成长停滞，业务推进缓慢。但他自己觉得挺充实——"至少事情没掉地上。"

这种场景太常见了。而且有个规律：越是优秀的IC（个人贡献者），转型管理者时越容易掉进这个坑。

优秀为什么会变成陷阱

做IC的时候，你的价值等于你解决问题的能力。代码写得好、架构设计得巧、线上问题处理得快——这些是你被认可的原因。

转成管理者后，评价体系变了。你的价值不再是"你做了什么"，而是"你的团队产出了什么"。之前让你闪光的能力，现在可能正在拖你的后腿。

因为太擅长解决问题，你会本能地冲上去："算了，我来吧。"每一次"我来"，你就少了一次观察团队、思考方向的机会。更糟的是，团队会习惯等你兜底，主动性和成长空间都被你"优秀"地压死了。

说白了，做IC时，优秀是你的加速器；做管理者后，同样的优秀可能变成团队的限速器。

真正的转变不是做更多，而是学会不做

我观察过一些转型比较成功的技术管理者，发现他们有一个共同点：不是技术变差了，而是对"成就感来源"做了迁移。