写代码的成本突然暴跌，这事对工程师来说像捡了金矿，但对工程管理者而言，却是一场对过往信条的无情拆解。当了三年工程总监，我一直听到那些被反复念叨的“老规矩”：技术负责人不该亲自写代码、好的工作需要时间、要替团队挡住业务需求的打扰、在做出承诺前必须达成共识。这些信条听起来都对，但也正因为太对，我们很少去想它们到底是站在什么地基上。

直到我们在组织内引入大语言模型，代码产出的成本肉眼可见地塌了下去。那一刻我开始把每条管理实践都拆开，看它背后依赖的那个假设还在不在。结果让人有点发怵：大概一半的老规矩，它们的假设已经碎了；而另一半，不仅没碎，反而比过去更关键。

打开网易新闻 查看精彩图片

这个审视的过程并不复杂，只是很少有人愿意干。任何管理动作都拴着一个默认的预设——速度跟踪假定产出量能代表真实努力，新人六个月上手因为语法本身就慢，靠共识设计架构是因为变更成本高得吓人，按人头做规划默认产量跟人数成正比。当写代码本身不再是瓶颈，你再回头看这些预设，有些瞬间就站不住了。但那些关于人怎么协作、怎么建立信任、怎么分配注意力、怎么验证正确性的东西，完全没变，不管这些规矩看起来有多“传统”。

尴尬的是，很多团队已经在凭着感觉做取舍：看着像新派做法的就留下，看着像旧规矩的就扔掉。这么一折腾，真正碍事的流程没丢，却把有用的摩擦力给拆了。管理实践的年龄跟它的有效性，是两个毫无关系的变量。如果有人——包括你自己团队的成员——只跟你汇报速度提升了多少，而对其他闭口不谈，你最好多留个心眼。从我目前观察到的真实情况看，明显的收益集中在从零开始的新项目、脚手架代码，以及工程师不熟悉的领域。一旦进入对系统已经滚瓜烂熟的人手里，这些增益就开始缩水，甚至倒过来拖慢节奏。

所以我现在最期待的是2025年第四季度之后的数据和研究，那一波新模型的能力把旧报告的基准直接掀翻。但在那之前，被感受到的速度和能被测出来的加速之间那层落差，本身就是管理要解决的大问题。如果你的工程师都觉得变快了，可最终交付的东西并没有变多，还带着更多缺陷，那你的人员配置、项目计划和给业务方的承诺，会全部踩空。在我看来，当一个组织开始引入AI工具时，第一件事不是让大家用起来，而是先建立起足够诚实的测量手段，看清楚自己到底是不是真的变快了。