最近看到一篇文章,看完之后沉默了很久。

一个做了十年的技术负责人,维护着一个还算健康的开源项目,有测试、有CI、代码规范也都在。因为带娃,时间碎片化,他想试试那些号称能革命的Agentic AI工具。

两周时间,AI帮他写了一万两千行代码,删了五千行旧代码。速度快得惊人,远超他过去几个月的产出。一开始他是震撼的,甚至有点失眠,真的开始相信"程序员要完了"。

但故事在这里急转直下。

你知道那种感觉吗?就是你突然发现,你手里这个东西,虽然它还能跑,测试也过,CI也绿,但你就是……不想碰它了。不是说它有多少bug,而是你看着它,心里那股骄傲感没了。你不再信任它,也不想维护它。

他最后把代码库回滚了,几乎全部推倒重来。

这不是一个"AI不行"的故事。恰恰相反,这是一个"AI太行了"的故事。

前期真的很爽。CRUD、前后端联动、测试生成,AI都干得漂亮。风格贴合你的规范,review起来就像在review一个还不错的初级工程师。如果只看"功能能不能跑"和"局部代码质量",AI甚至是优秀的。

但问题在于,代码库是会长大的。

当系统规模起来之后,AI开始迷失在上下文里。同名的逻辑越来越多,每次修改要碰十几二十个相关引用,它开始搜不准、定位不对、判断不清。更可怕的是,它会反复尝试、反复失败,但从不承认失败,永远一副"我知道我在干什么"的样子。

这还不是最致命的。

最致命的是命名开始失真。

AI不在乎命名是否准确,它只在乎"听起来合理"。变量名、函数名,每一个都像模像样,但语义和真实行为已经脱钩了。你isolated review的时候看不出来,等你从系统视角一看,整个就是一团语义上的迷雾。

这不是技术债,这是认知债。

我想起一个做工程的朋友说过的话:代码不只是要能跑,它得让你觉得"值得继续存在"。AI可以像初级工程师一样勤奋,但它不会像资深工程师一样在乎"这个系统还值不值得活下去"。

所以这个故事的价值,不在于给"AI能不能取代程序员"这个问题一个答案,而在于它很诚实地指出了一件事:AI放大的不是生产力,而是系统复杂度。

当你没有强判断力,你会被带飞。当你没有系统感,你会被炸库。当你没有审美,你会生成一堆"看起来对、实际上烂"的工程。

有意思的是,这个工程师以为自己没有在瞎搞,他严格review每一行代码,但他失败的原因,恰恰是——他把AI当成了合作者,而不是参考工具。他让AI承担了系统级的一致性责任,但AI根本扛不住这个。

AI真正适合的位置,可能是:分析现有代码,生成文档和示例,在小函数级别辅助你,给你模糊的参考,而不是直接往你的代码库里写完整的功能模块。

说到底,这不是一个技术问题,这是一个位置问题。

夜已经深了,我写这些的时候,其实心里也在想,我们这些做内容的、做产品的、做任何创造性工作的人,会不会也在某一天,面对同样的困境?AI帮你写稿、帮你想选题、帮你排版,速度快得惊人,但某一天你突然发现,你对自己的作品,没有那股劲儿了。

那股"我愿意为它负责"的劲儿。

这可能才是我们真正需要守住的东西。不是速度,不是产出,而是那个"我在乎它"的瞬间。