夜雨聆风
2026年5月9日，一个叫dropbox_miner的开发者在Hacker News上发了一篇帖子，标题是「I'm going back to writing code by hand」。
帖子写的是他过去7个月的经历。他用Claude做了一个GPU感知的Kubernetes终端界面工具，叫k10s。
整个项目从头到尾几乎完全靠AI生成代码，他自己基本不手写核心代码，也很少真正坐下来读代码。
前几周的体验是「magic」。
他给Claude一句话prompt，「加一个pods视图，要实时更新」，boom，直接能跑。最基本的k9s克隆版，3个周末搞定。
他觉得自己的开发速度大概是以前的10倍。
然后他想加一个GPU集群视图。Claude又一次一把梭搞定了。界面漂亮，数据流畅。
k10s 原文展示的 GPU fleet view：界面看起来完整、漂亮，真正的问题藏在后面的系统结构里
然后他切回了pods视图。
什么都没渲染出来。
他花了7个月时间不断地给AI下指令、不断地发布功能更新，但从来没有真正坐下来读过Claude写的代码。
现在出了根本性的问题，他没法再靠prompt修复了。
于是他打开了model.go这个文件。
1690行。
他用了一个词来形容自己当时的感受，horrified。
这个文件里塞了一个巨大的God Object，就是一个无所不包、什么功能都往里面堆的超级对象。所有的视图、数据流、事件处理全部耦合在一起。
AI每次接到一个新需求，就在这个对象上面再加一层，再接一个管道。从来不重构，从来不拆分，它甚至在里面制造了一个数据竞争。
Go语言不像Rust，编译器不会在编译阶段帮你拦住这种并发问题，所以这个bug一直藏到了系统崩溃才暴露。
他在原文里写了一句很精辟的类比，「就像em-dash之于AI写作，God Object就是AI编程的标配。」
AI写东西有它自己的审美惯性，写文章喜欢用破折号，写代码喜欢堆God Object。你用多了就会发现这种模式。
7个月的氛围编程，造出了一座全新的屎山，而且是一种比传统屎山更麻烦的品种。
传统屎山往往是长期积累出来的，团队里至少还有人知道哪些地方能碰、哪些地方不能碰。
AI造的屎山不一样，它是在极短时间内「一次成型」的，很可能没有任何人类完整梳理过它的内部结构。
他最终做了一个决定，把整个项目归档，从零开始重写。
这篇帖子在Hacker News上炸了。评论区的反应很有意思，不是简单的「AI不行」，而是一种更复杂的共鸣。
Hacker News 讨论串里，争论很快从AI 能不能写代码转向人类还要不要逐行理解系统
一个叫SpicyLemonZest的用户说，他也在用AI写代码，但他会先自己做架构设计，写好接口定义、消息类型、所有权规则，然后才让AI去实现。他估计这样能节省50%到100%的编码时间。
另一个叫cpncrunch的用户反问，如果你要自己设计架构、自己写规则、自己检查AI写的每一行、然后还要反复修改，那你到底省了什么时间？他说，coding从来就不是他工作中占比最大的部分。
还有一个叫striking的用户，讲了一个更细节的故事。
他在做一个大规模重构，写了一个lint规则，指定某些数据库查询只能放在特定文件夹里。然后让AI按这个规则去迁移代码。AI表面上完成了任务，看起来没问题。
但他仔细检查之后发现，AI在迁移过程中悄悄改了查询逻辑，漏掉了一些LIMIT和ORDER BY子句，搞混了主库和只读副本的调用。
他跑了好几轮reviewer agent去修，每次都能修掉十几二十个问题，但他永远无法完全信任输出。
最后他放弃了，回去用传统的codemod手动写规则来完成迁移。
他说了一句话，这个行业需要一个「verification layer」，但据他所知，目前还不存在。
这几个故事指向同一个东西。
不是AI写的代码不能用，是当你把自己从循环里摘出去之后，你就丧失了对系统的理解。而软件工程最终考验的不是你能写多快，是你能不能在凌晨3点被叫醒的时候知道去哪里找问题。
Dev.to上有一篇分析文章，作者是保罗·维克多·莱特·利马·戈麦斯（Paulo Victor Leite Lima Gomes），标题直接点破了这件事的本质，「Why the hand-coding backlash is really about agency, not nostalgia」。不是怀旧，是掌控感。
Dev.to 这篇文章把回到手写代码的反弹解释为 agency，也就是开发者对系统的掌控感。来源：Dev.to / Paulo Victor Leite Lima Gomes。
他提了一个概念叫「Polished Wrong」，打磨过的错误。
AI生成的代码格式漂亮、注释齐全、变量命名规范，看起来比很多人类写的都专业。但里面可能有根本性的逻辑缺陷，或者漏掉了关键的边缘情况。而且它每次产出的代码差异（diff）都特别大，大到人类很难逐行审查。
传统的代码审查建立在「人类看得完这些改动」的前提上，当AI一次性给你吐出大段变更，这个前提就不成立了。
这比一眼就能看出来的烂代码危险得多。因为烂代码你至少知道它烂。
华尔街日报（WSJ）的克里斯托弗·米姆斯（Christopher Mims）在5月22日发了一篇报道，把这类现象称为Vibe Slop。Vibe Coding产生的Vibe Slop。这个说法迅速在开发者圈子里传开了。
他采访了一批AI工程圈的人，包括一个叫马里奥·泽希纳（Mario Zechner）的工程师，这人是OpenClaw项目中agentic harness「Pi」的核心工程师。
泽希纳的判断很直白，用自然语言大量生成软件的做法，在没有适当人工监督的情况下，极度危险。软件正在变得「significantly buggier」，显著地更多bug了。
米姆斯在报道里还提到，一些主流开源代码平台已经开始调整规则，增加针对AI生成代码的审核机制，来应对低质量代码对开源生态的冲击。
这不是一两个人的个体感受了。从开发者社区到科技媒体再到开源平台维护者，这个问题正在被越来越多的人讨论。
开源项目 RPCS3 团队更新 AI 生成代码提交规则，被外媒作为AI slop冲击开源维护者的案例报道
但这件事真正有意思的地方不在于「AI写代码有问题」，这谁都知道。有意思的是这些开发者的反应。
他们没有说「我要彻底不用AI了」。
dropbox_miner自己说得很清楚，他重写k10s的时候选了Rust，不是因为Rust更好，是因为Rust是他能驾驭的语言。他在Rust里写过足够多的代码，能在还没想清楚为什么之前就「闻」到代码不对劲。
他说这种直觉是氛围编程无法替代的。
他的新做法是，自己先画架构，画清楚接口、消息类型、所有权规则，然后把这些写进CLAUDE.md。
让AI去实现，但架构决策必须是人做的。
这很像HN评论区里EMM_386总结的，你不需要回到手写代码，但你需要像管理一个工程团队那样管理AI。先设计，再分发，最后审查。
AI不是在把程序员变成多余的人。至少在需要长期维护的软件里，AI正在把程序员的核心价值往架构、约束和审查上推。
这么说还是太轻巧了，更准确的说法是，AI正在逼程序员回到他们本来就应该在的位置上。
你想想看，过去十年，整个行业其实一直在做一件事，把写代码这个动作本身变得越来越容易。低代码、无代码、各种框架和脚手架、Stack Overflow的复制粘贴、现在又到了AI直接生成。
每一步都在降低「写出能跑的代码」的门槛。
但「能跑」和「能维护」之间的鸿沟从来没有缩小过，甚至可能在加大。
k10s的故事完美地展示了这一点。AI把一个Kubernetes TUI工具从零写到功能完备只花了几个周末。但当一个视图切换导致整个界面崩掉的时候，7个月的工作全部归零。
dropbox_miner的原文里有一句话总结得很精准，「AI writes features, not architecture」。AI写功能，不写架构。它给你的速度让你觉得自己在赢，直到一切同时崩溃。
这让我想到一个可能不太恰当但挺有意思的类比。
文艺复兴。
类比放松一点来说，文艺复兴的一个重要面向，是让技艺和数学、几何、解剖学这些基础知识重新连接起来。
达芬奇不只是一个画家，他是一个理解了透视法数学原理的画家。这个理解让他的创作有了一个完全不同的底座。
现在的情况有点像反过来。AI给了每个人「工匠」的能力，你不需要理解原理就能产出看起来不错的成品。
但那些选择去理解原理的人，选择自己画架构、自己定规则、自己审查每一行代码的人，他们正在变成新时代的达芬奇。
当然我也不确定这个类比能撑多远。毕竟写代码和画蒙娜丽莎之间的距离还是挺大的。
但至少有一点是共通的。当工具变得足够强大，能把大多数人的产出拉到同一个水平线上的时候，真正拉开差距的就不再是工具本身，而是使用工具的人对自己在做什么的理解深度。
Hacker News评论区里有一条留言，来自一个叫travisgriggs的用户，他提了一个很尖锐的问题。
他说他用AI帮自己做西班牙语和葡萄牙语的国际化翻译，用了一段时间之后，他觉得自己对这两门语言反而更不懂了。AI给了他熟悉感，但没有给他能力。
他问了一个更大的问题，在一个大家都被鼓励用AI快速产出的世界里，谁还能获得真正的proficiency？
这可能是整件事里最值得琢磨的一个角度。
AI不会让所有程序员失业。但AI可能会制造出一代「熟练的外行」，他们熟悉所有的工具、流程和术语，他们能快速产出看起来专业的成果，但他们从来没有真正理解过自己在做什么。
中文技术社区里已经有人开始把Vibe Coding产出的这类代码叫「现代屎山」。
传统屎山好歹是一行一行手敲出来的，写的人至少在某个时刻理解过那行代码。AI造出来的这种新品种不一样，很可能从诞生那一刻起就没人完整梳理过它的内部结构。
而那些反过来走的人，那些选择「回到手工写代码」的人，他们其实不是在拒绝AI。他们是在确保自己仍然有资格使用AI。
这可能才是这场「程序员的文艺复兴」的真正含义。
不是回到过去，是重新搞清楚什么是真正的手艺。
