谷歌工程师自曝：AI写了80%代码后，我开始怀疑自己了

一位在谷歌干了8年的工程师最近算了笔账：他去年写的代码里，80%不是亲手敲的。这个数字让他既兴奋又有点慌——就像突然发现自动驾驶能开高速了，但你还是忍不住想摸方向盘。

这哥们叫Evan，在Medium发了篇长文。他说以前写功能要泡咖啡、查文档、debug到半夜，现在变成"描述需求→AI生成→我改改→上线"。整个流程快得不像话，但乐趣和焦虑一起翻倍了。

从"码农"到"产品经理"的 overnight 转型

Evan打了个比方：以前他是厨师，从切菜到摆盘全自己来；现在他是点菜的人，AI是后厨，他只需要尝一口说"咸了"或"再辣点"。

这种转变来得猝不及防。2023年他还在用Copilot（代码补全工具）当辅助，2024年Claude和Cursor（AI编程工具）已经能端到端生成完整模块。他试过让AI写一个用户登录系统，从数据库设计到前端界面，15分钟出活。他自己做的话，至少半天。

但问题也跟着来了：当"写代码"不再是核心技能，他这8年积累算什么？

他观察到一个现象：团队里年轻工程师适应得更快。他们本来就没形成"必须亲手写"的肌肉记忆，直接拿AI当默认工具。而老程序员反而纠结——有人觉得这是作弊，有人偷偷用但不敢承认。

那20%的手写代码，反而更值钱了

Evan发现，AI搞不定的恰恰是那20%。

比如一个边缘 case：用户在网络抖动时连续点击支付按钮，怎么保证只扣一次钱？AI能生成常规方案，但涉及分布式锁、幂等设计的微妙平衡，还得人来拍板。再比如代码安全审查，AI会漏掉一些"看起来正常但能被注入攻击"的写法。

他总结了一个规律：AI擅长"已知问题的高效解决"，人擅长"未知问题的边界判断"。

这让他想起摄影的演变。胶片时代，摄影师要懂暗房、化学、测光；数码时代，这些技术门槛崩塌了，但"拍什么、怎么构图、传递什么情绪"变得更核心。代码可能正在走同样的路——执行层贬值，决策层升值。

一个尴尬的新问题：我还算"开发者"吗？

Evan在文章里坦承，他有时候会有冒充者综合征（Impostor Syndrome，自我能力否定倾向）。

上周他参加技术分享会，有人问他"那个新功能怎么实现的"。他说"我让Claude写的"，对方愣了一下，气氛微妙地冷了两秒。他赶紧补了句"但我设计了架构和review了关键部分"，听起来像在辩解。

这种身份焦虑在行业里挺普遍。GitHub 2024年的调研显示，92%的开发者用过AI编程工具，但只有34%愿意在简历里强调这一点。大家用，但不太想说。

Evan的应对方式是重新定义工作：不再以"写了多少行代码"衡量产出，而是看"解决了什么业务问题"。他最近一个项目，用AI三天搭完原型，剩下两周全花在用户访谈和迭代上。放在以前，这两周还在debug。

工具链正在重组，但有人被甩下车

不是所有开发者都享受这种转变。

Evan提到一个同事，15年经验，打字速度极快，靠肌肉记忆就能盲写复杂SQL。AI工具对他反而是负担——他描述需求的时间，自己早就写完了。更麻烦的是，AI生成的代码风格和他不一致，改起来比重写还累。

这种代际差异正在撕裂技术团队的协作方式。年轻工程师习惯"先让AI跑一版"，老工程师坚持"我先想清楚再动手"。两种路径都没错，但混在一起容易互相嫌弃。

公司层面也在重新算账。Evan听说有的团队在评估"AI渗透率"作为效率指标，这让他隐隐不安——如果80%是基准线，那写90% AI代码的人是不是更"高效"？人的价值会不会被压缩成" prompt 工程师"（提示词工程师）？

他特意澄清：prompt 工程不是真正的工程。好的系统需要理解业务上下文、权衡技术债、预判扩展瓶颈，这些AI还做不到。但问题是，老板们知道吗？

写在最后

Evan的文章结尾挺有意思。他说自己现在写代码，会故意留一部分手写——不是为了效率，是为了"保持手感"。就像钢琴家每天练音阶，不是为了演出，是为了不忘记怎么弹琴。

他最后抛了个问题给读者：如果十年后，AI能写99%的代码，那1%的手写部分，你还愿意保留吗？是为了实用，还是为了证明自己曾经会这门手艺？