我最近注意到一个挺有意思的现象：团队里用AI编程工具最积极的那几个人，代码变更量差不多是其他人的3倍，但需求交付速度并没有快3倍。仔细看了一下，有些人的单个bug修复，diff比需求本身还长。

这不是个例。当你跳出"AI提效"的叙事，认真看AI代码助手在项目中留下的痕迹时，会发现一个被忽略的问题——AI有天然的过度编辑倾向，而且这种倾向正在悄悄地侵蚀代码库的健康度。

AI的"讨好型人格"

先说一个可能很多人没太注意的事：AI代码助手本质上是有讨好倾向的。

你让AI修一个空指针异常，它不光改了那行判空逻辑，还顺手调整了方法签名，给相关变量补了类型注解，甚至把异常处理的模式也给重构了。每一步看起来都合理，每一步单独拎出来都是"改进"，但加在一起，你只是为了改一个判空，变了三十行代码。

AI为什么这样？因为它的训练体系中，"提供有价值的回答"是一个核心信号。对AI来说，只改一行和改三十行，哪个更像"用心回答"？更关键的是，你问AI"还有没有可以改进的地方"，它几乎不可能说"没有了，当前代码已经很好"——它会找出所有能优化的点，然后一股脑全给你改掉。

每次聊性能优化，话题总是很快滑向具体的技术手段：懒加载、代码分割、图片压缩、Tree Shaking、虚拟列表……这些当然有用，但我想说一个可能让不少人不太舒服的判断——当你在做这些"优化"的时候，大概率已经晚了。 真正决定性能天花板的，不是你用了多少优化手段，而是系统架构在最初就给你画了多高的天花板。

性能问题从来不是前端单方面的问题。但很多团队把它当成了前端的问题，于是前端工程师就像一个装修工人，在毛坯房里拼命贴墙纸——墙纸再好看，承重墙没打好，房子一样不牢。

优化手段的天花板

先承认一个事实：常规的性能优化手段确实能解决一部分问题。一个从没做过任何优化的项目，加上代码分割和懒加载，首屏时间砍一半不稀奇。图片做个WebP转换、加个CDN，LCP直接降几百毫秒。这些是低垂的果实，摘了就是摘了，没人否认。

但问题是，这些优化有上限。你的首屏要从3秒优化到1.5秒，代码分割和懒加载就够了。但如果你要从1.5秒到800毫秒，甚至到500毫秒以内，单靠前端手段就力不从心了。因为剩余的耗时大头不在前端——它在网络请求、在服务端处理、在数据组装、在协议开销。

有个现象我一直觉得很有意思：很多技术Leader当了Leader之后，比当个体贡献者时更忙了。

这不正常。

如果你的管理是有效的，你应该比以前更闲才对——因为你把事情分出去了，别人在做。但现实是，大部分Leader的日常是这样的：早上站会听进度，上午review代码，下午排需求优先级，晚上还要处理线上问题。忙得脚不沾地，但回头一看，团队离了你好像啥也干不了。

你以为这是"能者多劳"，其实这是一个信号：你根本没在管人，你还在管事。

管事和管人，不是同一件事的两种叫法

我见过不少刚做管理的朋友，聊起来都说"我在带团队"。但你仔细看他们的工作内容：拆任务、派活、盯进度、review产出、解决技术卡点……这些是管事还是在管人？

都是管事。

区别很简单：管事关注的是"事情有没有做好"，管人关注的是"人有没有成长"。前者是项目管理的范畴，后者才是团队管理的核心。

这个区分听起来像废话，但大部分技术Leader从来没认真想过这个问题。因为在工程师的世界观里，把事情做好就是一切。升Leader之后，自然也觉得"把团队的事情管好"就是管理。

大部分技术Leader在招人时都有个朴素的信念：能力越强越好，人越聪明越好。但在真实的团队管理中，我发现一个反直觉的现象：很多时候，团队出问题不是因为能力不足，而是因为认知跨度太大。

什么是认知跨度？就是团队成员在技术理解、业务认知、工作方式上的差距。这个差距小的时候是良性竞争，大了就是团队撕裂。

一个真实的场景

金融科技行业里有种很常见的情况：你招了一个大厂出来的P7，技术很强，对代码质量要求高，喜欢讨论架构。但你的团队主力是P5，关注的是怎么快速把需求做出来。

前两周还好，P7会主动做code review，提重构建议。一个月后矛盾就出来了：P7觉得"这代码没法维护，得重写"，P5觉得"功能都正常，改它干嘛"。三个月后，P7要么离职，要么就闭嘴了。

这不是谁对谁错的问题。这是认知跨度的问题。

认知跨度的三个维度

在技术团队里，认知跨度体现在三个地方：

技术深度的跨度。有人觉得"能跑就行"，有人觉得"必须优雅"。前者关注的是业务价值，后者关注的是技术品味。放在同一个项目里，一个想快速迭代，一个想精雕细琢，怎么配合？