谷歌砍掉3.6万行代码后，程序员集体破防

2024年，谷歌内部一个实验项目让工程师们吵翻了天——有人用AI重写代码库，直接删掉3.6万行旧代码，运行速度反而快了15%。反对者骂这是"技术洁癖"，支持者说"早该这么干"。

这场争论的核心不是AI多厉害，而是一个被忽视的老问题：代码写得越"务实"，后期死得越惨。

01 谷歌的"代码瘦身"实验

事情发生在谷歌的Chromium项目。团队用大型语言模型（LLM，即通过海量文本训练的人工智能系统）重构了浏览器内核的部分模块。结果出人意料：代码量从4.2万行压到6000行，内存占用下降，测试通过率反而更高。

项目负责人Chen Zhou在内部邮件里写了一句得罪人的话：「我们过去十年写的不是代码，是技术债的欠条。」

这话捅了马蜂窝。资深工程师Mark Mentovai公开反驳：「删代码容易，删的是业务逻辑还是冗余封装？三个月后bug爆发谁来背锅？」

两边的争吵持续六周，最后谷歌高层拍板：实验继续，但限定在非核心模块。这个妥协本身就很说明问题——连谷歌这种技术储备的公司，也不敢全押AI重构。

02 "务实"代码的三宗罪

为什么删代码会引发这么大的反弹？因为大多数程序员都被"务实"坑过。

第一宗罪：复制粘贴式解决问题。Stack Overflow（程序员问答社区）上找个答案，改改变量名就上线。当时省了两小时，半年后需求变更，发现这段代码和另外十七个地方耦合在一起，改一处崩一片。

第二宗罪：过度防御性编程。为了"以防万一"加层层判断，为了"方便扩展"留一堆接口。结果代码像俄罗斯套娃，每个函数都包裹在五层抽象里。新同事看三天看不懂，老员工自己过两个月也懵。

第三宗罪最隐蔽：用忙碌掩盖思考。写200行能解决的，硬要拆成10个文件、20个类，美其名曰"架构清晰"。实际是逃避对问题本质的理解——把简单问题复杂化，显得工作饱满。

谷歌的实验之所以刺痛人，是因为它证明了：这些"务实"的代码，AI一眼就能看穿是垃圾。

03 代码质量和KPI的死亡螺旋

程序员不是天生爱写烂代码。问题出在考核机制上。

国内某大厂的技术负责人跟我聊过，他们团队曾推行"代码行数统计"，结果季度末所有人疯狂拆分函数，一个打印日志的操作能拆出三个文件。后来改成"需求交付数"，大家又抢着接简单需求，复杂重构没人碰。

谷歌的情况稍好，但也好不到哪去。Chromium项目 contributor（代码贡献者）超过8000人，每年提交数十万笔修改。在这种规模下，"能跑就行"是理性的生存策略——认真重构的人，绩效可能还不如快速堆功能的人。

AI介入后，这个平衡被打破了。LLM不怕读烂代码，也不怕大规模替换。它像一面照妖镜，把"务实"背后的懒惰照得清清楚楚。

04 重构派和保守派的真正分歧

回到谷歌的争论。双方吵的不是技术，是风险承担方式。

Mark Mentovai的担心有数据支撑：2023年微软用AI辅助重构Azure（云计算平台）的部分服务，结果上线后出现时区处理bug，影响全球客户长达11小时。事后复盘发现，AI把一段处理夏令时的逻辑"简化"掉了，测试用例恰好没覆盖这个边界条件。

但Chen Zhou也有话说。他统计了被AI重构的模块，后续三个月的bug率比人工维护的模块低40%。「不是AI不会犯错，是人类写的代码错更多，只是分布得更隐蔽。」

这场辩论没有赢家。谷歌最终的妥协方案，本质是承认一件事：代码质量是个长期博弈，而KPI周期是短期的。AI可以加速重构，但没法替人承担决策责任。

05 一个被忽视的变量

讨论里少有人提的一点：代码"质量"的定义本身在变。

十年前，好代码的标准是可读性、可扩展性、设计模式运用得当。现在，能被AI理解、能被AI安全修改，正在成为新维度。GitHub（代码托管平台）2024年的报告显示，使用AI辅助编程的团队，代码审查时间平均缩短35%——不是因为代码变好了，是因为审查者更信任AI的静态检查。

这带来一个悖论：程序员花更少时间写代码，却花更多时间写"能让AI看懂的代码"。注释要更规范，变量名要更直白，逻辑分支要更扁平。某种程度上，人类正在给AI当翻译。

谷歌实验中最讽刺的细节：被删掉的那3.6万行代码里，有8000行是注释。原开发者以为自己在"务实"地解释逻辑，实际上是在给后来的维护者制造噪音。AI直接把它们当成噪声过滤掉了。

如果代码最终是写给AI看的，"务实"的标准要不要重写？你的团队现在考核代码质量，还看行数吗？