上个月参加一个技术峰会，茶歇的时候跟几个做工程管理的同行聊天。去年大家讨论的还是"AI写代码到底行不行"，今年画风变了——几乎每个人都在说"用了之后怎么管"。

这个转变挺微妙的。行不行是个技术问题，怎么管是个组织问题。技术问题总有答案，组织问题往往没有。

Cognition的十亿美金说明了什么

前两天看到一条消息，Cognition的年化收入运行率突破了10亿美元。去年Devin刚出来的时候，圈内争议很大——有人说这是编程革命，有人说就是个高级autocomplete。一年过去，市场用真金白银投了票。

这个数字的意义不在于"AI能写代码"——这件事GitHub Copilot两年前就证明了。它的意义在于，有人愿意为"AI替代一部分工程人力"这件事付大价钱。注意，不是辅助，是替代。辅助工具你买license，替代人力你买的是headcount。

这两件事的管理含义完全不同。工具你用就行了，替代你得管。而大部分工程管理制度，是基于"代码由人来写"这个前提设计的。现在这个前提开始松动了。

第一个冲击：绩效评估失灵了

我了解过一个场景。一个工程师用Cursor和Copilot配合，代码产出量大约是同事的两倍。但code review的时候，leader发现一个问题：代码质量参差不齐。不是说写得不对——都能跑，测试也过——而是风格和团队习惯不太一样。有些变量命名跟团队规范不一致，有些设计模式不是团队常用的那种。

这个leader跟我说了一句挺实在的话："我不知道该怎么评价他。按产出看，我应该给他打高绩效；按代码质量看，我又不放心让他独立负责核心模块。"

这不是个案。我后来跟好几个做技术管理的朋友聊过，大家都遇到了类似的困境。一个常见的坑是：有人的AI产出太快，code review跟不上了。以前每天review两三百行，现在一天可能冒出上千行。review的人精力有限，慢慢就变成了走过场——"看一眼大概没问题就过了"。结果呢？bug悄悄多了起来，线上事故频率上去了，大家才意识到review质量已经塌了。

更有意思的是另一个方向的坑。有个leader发现团队里有人用AI写代码效率很高，就在周会上表扬了他。结果第二周，另外三个人也开始大量用AI输出，但没掌握好prompt技巧，生成了一堆看起来正确但逻辑有漏洞的代码。review的人根本看不过来，一个hidden bug在生产环境跑了两周才被发现。

你看，鼓励也不是，不鼓励也不是。这就是管理制度没跟上工具变化的典型症状。

第二个冲击：人才梯队断裂了

传统工程师的成长路径是：写好代码 → 解决更复杂的问题 → 承担更大责任 → 晋升。这条路的第一步是"写好代码"。

现在这一步被AI接过去了。一个初级工程师配合AI，可以产出接近中级的代码量。但他的架构判断力、系统设计能力、对业务的理解，还是初级水平。

这就出现了一个奇怪的错位：产出是中级的，能力是初级的。你怎么给他定级？怎么给他规划成长路径？

更深层的问题是：如果初级阶段被AI跳过了，那未来的高级从哪来？就像一个人从小用计算器，算术能力不一定差，但数感可能确实会弱一些。我认识的一个技术负责人在团队周会上提过这个问题，原话是："如果新人入职第一年不经历大量写基础代码的阶段，他的基本功扎不扎实？"没人能回答他。

这个问题目前确实没有好的答案。大部分团队还没走到这一步——但如果AI编码的渗透速度跟过去两年一样快，可能两三年内就会变成一个普遍问题。

第三个冲击：组织分工过时了

传统的工程团队按职能分工：前端、后端、测试、数据。AI时代，一个人加上AI可以覆盖多个职能。我了解过几个创业团队的做法——他们把工程团队缩小了一半，但每个人都变成了"AI增强型全栈工程师"，不再区分前端后端。

听起来很美，但有个前提条件：全栈能力需要业务理解力来支撑，而这不是每个人都具备的。实际操作下来，往往是少数"AI增强型超级工程师"承担了80%的产出，剩下的人变成了"AI代码的reviewer"——这个角色既没有技术挑战性，也没有成就感。

有个创业团队试过这个模式，产品团队从12人缩到6人。前两个月效率确实提升了，但第三个月出了状况。超级工程师开始抱怨工作强度太大，剩下的人觉得自己在做低价值工作。最后他们又加回了两个人，但角色定义变了——这两个人不写代码，专门做AI输出的质量把控和prompt模板沉淀。

说白了，这就是一个新角色——"工程AI教练"。不要求你自己代码写得好，但你得知道怎么让AI写出好代码。这个岗位现在没有标准的JD，市面上也招不到现成的人，但它可能在未来几年变得很常见。

管理制度跟不上工具变化

19世纪工厂引入蒸汽机的时候，管理方式还是手工作坊那一套——计件工资、师傅带徒弟、没有标准化流程。后来花了差不多二十年，才慢慢发展出流水线、标准化作业、现代人力资源这些制度。

不是工厂主不想变，是变化太快，来不及想清楚该怎么调整。软件工程的管理制度——绩效考核、职级定义、招聘标准、团队编制——也是上一个时代的产物，基于"代码由人来写"的前提。这个前提正在被改变，但大部分公司的管理制度还假装AI不存在。

绩效考核表没变，职级描述没更新，招聘面试还是考算法题。真正在适应这个变化的人，往往是个体——某个工程师自己摸索出了一套AI协作方法，但他的leader不知道，公司不知道，团队也不知道。

这个信息差本身就是一个管理问题。

有个问题我最近一直在想：如果明年你的团队里有一个人代码产出是别人的三倍，但其中70%是AI写的，你给他打绩效的时候，到底算好还是不好？

可能答案不在于代码，在于判断力——什么时候该让AI干，什么时候该自己来，什么时候AI的输出看起来对其实不对。这种判断力的差距，可能是未来工程师之间最大的分水岭。但怎么在绩效评估里度量判断力，这个问题我自己也还没想明白。

前几天一个朋友跟我说，他刚提了晋升，带的团队有八个人，三个在用AI编码工具。他的困惑不是"AI好不好用"——他早就知道好用——而是"我怎么评估一个用AI的人和一个不用AI的人"。他想了很久，说了一句："也许以后工程师最重要的能力不是写代码，是知道什么时候不该让AI写。"我不知道这句话对不对，但它描述的那个困境，大概是真实存在的。