17611538698
webmaster@21cto.com

Mitchell Hashimoto 一条推文引发“大乱斗”:AI 写的代码,你到底读还是不读?

人工智能 0 32 17小时前
图片

21CTO导读:当大模型的推理能力越来越强,“Vibe Coding”(凭感觉写代码)正在开发者圈子里迅速蔓延。然而,HashiCorp 创始人 Mitchell Hashimoto 的一句“我会逐行阅读 Claude 写的代码”,一下子引爆了整个技术圈。在 AI 效率与工程质量之间,开发者正面临前所未有的路线抉择。

一条推文引发的行业“大讨论”


Mitchell Hashimoto (中译名:米切尔·桥本)发了一条非常朴素的推文:每次让 Claude Code生成代码后,他都会认真去读一遍。

图片

这句看似理所当然的话,在开发者社区掀起了整整一周多的舆论风暴。

人们争论的核心焦点在于:认真阅读 AI 生成的代码,究竟是程序员应尽的职业操守,还是效率时代的一种时间浪费?

这场争论爆发的时机十分耐人寻味。当时,新一代大模型(如 Anthropic 的 Fable 和 GPT-5.6)相继问世,AI Agent 的能力突飞猛进,推崇“Vibe Coding(无需管细节,凭感觉让 AI 帮你干活)”的派系正沉浸在效率飞跃的狂欢中。Hashimoto 的推文,无疑给这股热潮泼了一盆极其冷酷的冰水。

原教旨派 vs 务实中立派:行业阵营大乱斗


在这场论战中,技术圈迅速分化出了几种截然不同的立场。

强硬原教旨派:不能 Debug,就不配拥有 Ownership


知名技术专家 Cindy Sridharan(@copyconstruct)立下了相当锋利的标尺:

“每当有人跟我说‘这都是 Claude 写的,我自己也不太懂它是怎么运行的’,我就默认这个人完全不具备 Debug 这段代码的能力


如果你无法 Debug,你就无法真正拥有(Own)这段代码;而如果你无法拥有它,任何在意系统稳定性与可靠性的厂商,都绝不敢信任你。”

这一观点立场鲜明,在深受“AI 代码通过 Code Review 却在生产环境频繁爆炸”之苦的工程师群体中引发了强烈共鸣。

务实中立派:不用逐行读,但 Diff 还是要看的


Sourcegraph 联合创始人 Beyang Liu 给出了更为平实的中庸解法:

“你不需要逐行仔细阅读 AI 生成的所有代码。但在把变更 Push 上去之前,你至少应该把 Diff(差异对比)快速过一遍。”

“视情况而定”派:看你到底在盖什么房子


面对非黑即白的争议,更多开发者开始根据具体的业务场景对“读不读代码”进行分级:

应用场景是否需要阅读 AI 代码?核心逻辑
一次性 MVP / 概念验证原型完全不用读速度第一,快速验证 Idea 最重要,坏了直接扔
个人兴趣项目 / 核心爱好的代码Pflicht 逐行精读追求绝对的掌控感与代码品味
生产环境(Production)业务⚖️ 只做架构设计与集成 Review自己定义接口与架构,实现交给 AI,但必须严格审查集成逻辑

这种“分场景讨论”的框架非常实用,因为它打破了二元对立:喊着“我从不看代码”的人往往在做原型开发,而强调“必须逐行审核”的人则立足于高并发的线上生产系统。

更深层的担忧:“Vibe 滑坡”与“AI 垃圾过载”


开源大佬 Christine Lemmer-Webber 提出了一个更值得沉思的观点——“Vibe 恶化(Vibe Bobsled)”

在她看来,从“严谨的 AI 辅助审查”滑向“完全凭感觉的 Vibe Coding”并非一种理性选择,而是一种无法抵挡的引力。极速交付的商业诱惑正在不断侵蚀审查机制。她引用研究指出:即便是顶尖专家,在审查超过 100 行的代码段时也经常漏掉关键 Bug,而如今大模型生成代码的量级早已远超 150 行。

她还提出了 “Vibe Sick(Vibe 恶化病)” 一词,用来形容由 AI 生成的低质代码(AI Slop)泛滥并充斥开源社区、日常工作与个人生活所带来的无力感。

科技博主 Gergely Orosz 也补充道:现在的工程师极度缺乏关于‘AI 垃圾代码因子(AI Slop Factor)’的即时反馈。 大多数人在系统真正崩溃之前,甚至根本意识不到自己引入了多少隐藏的技术债务。

真正改变你习惯的,不是工具,是工程的基本功


一位在真实生产环境中与 Claude、Copilot 以及 JetBrains Junie 深度协同数百小时的资深开发者分享了一个意料之外的发现:

AI 不仅加速了开发,更像一把放大镜,暴露出你过去软弱的工程习惯。

那些能够让 AI 协作真正生效的底层原则:

  • 在向 AI 提需求前,先写出清晰严密的 Specification(规格说明);

  • 保持任务微型化(Small Tasks);

  • 绝不让同一个 AI 既写代码又做自己的 Reviewer;

  • 维持严格的 Diff 变更粒度。


这些本质上全都是最经典的软件工程最佳实践,与 AI 本身无关。

结语:问题的本质


“该不该读 AI 写的代码”这个辩题,本质上是关于责任与 Ownership(所有权)的追问。

答案从来不是一个简单的“代码行数标准”,而是当线上系统在深夜崩溃时,你是否足够理解自己交付出去的东西,并能把它修复好?

至少在当下,对于绝大多数生产环境而言,想要做到这一点,你依然必须亲自阅读代码。尽管大模型越来越擅长让我们产生“可以放手”的错觉,但我们离真正能够当甩手掌柜的那一天,显然还有一段很长的距离。

作者:聆听音乐的鱼

评论

我要赞赏作者

请扫描二维码,使用微信支付哦。

分享到微信