AI 编码工具的横空出世，一度掀起关于“机器是否能替代人类开发者”的争议——有人沉醉于它高效完成任务的惊艳表现，直言其会颠覆开发行业；也有人警惕其潜在的局限性，担心代码质量与系统稳定性。

最近，一位名叫 mo 的开发者在 Hacker News 上分享了自己的亲身经历：过去两年里，他几乎全面采用 AI 进行所谓的“氛围编码”。从最初的惊艳，到不断把更复杂的任务交给模型，再到逐渐意识到问题所在——AI 写出的代码在局部合理，却难以维持整体结构和长期可维护性。最终，他选择放弃高度依赖 AI，回到手写代码。这篇直白、克制的反思，很快在开发者社区引发了强烈共鸣。

大多数人接触 AI 编码的历程都如出一辙：先让它完成一项简单任务，你会为之惊艳。接着交给它一项复杂任务，你会更加叹服。

于是你打开社交平台 X，写了一篇关于“岗位替代”的长篇大论。

如果你能跨过这个阶段——恭喜你，你对 AI 编码的理解已经超过了 99% 的人。

那些用 AI 处理实际工作（而非仅仅是周末项目）的资深工程师，大多也遵循着一条可预见的历程。

在对 AI 完成复杂任务的表现仍感惊叹时，你会忍不住想：能不能给它分配更宏大的任务？甚至是那个没人愿意接手的棘手重构工作？

AI 的能力遭到质疑

但就在这时，AI 的“光环”开始出现裂痕。

一方面，你惊叹于它似乎能精准理解你的需求；但另一方面，它会犯下令人沮丧的错误，做出明显违背你们达成的共识的决策。

你很快就会明白，对 AI 模型生气毫无意义，于是开始将所有不尽如人意的输出归咎于自己：

“是我的问题。我的提示词写得太差，描述不够具体。”

“只要我能把需求说清楚，它就能实现。潜力无限啊。”

你这样想。

于是你打开 Obsidian（笔记工具），开始撰写详尽的需求文档，用极致的细节描述你脑海中的功能。或许你会花半个小时，写出一整页的提示词。

但你会发现，这种“需求驱动式开发”同样行不通。在现实中，设计文档和需求说明都是“活文档”，会随着需求探索和落地实施不断动态演变。

试想一下：在一家真实的公司里，你花 1 小时为复杂架构写好设计文档，交给一位中级工程师（还要求他不能和任何人讨论这份文档），然后自己去度假——结果会怎样？

AI 工具不仅没有能力在数周的开发周期中，随着底层组件的搭建而迭代需求说明，还会在一开始就做出决策，且之后绝不偏离。更糟糕的是，一旦 AI 觉得问题和解决方案超出了自己的掌控，大多会直接“摆烂”（不过现在这种情况已经很少见了，因为 AI 会硬着头皮“闯过迷宫”）。

更致命的是，AI 写的代码在撰写和呈现给你时，看起来既合理又惊艳。甚至在代码合并请求（PR）中也显得无懈可击——毕竟你和 AI 都清楚“一份好的 PR 该是什么样子”。

“杂乱代码”越积越多

直到自己打开完整的代码库，逐行通读最新版本后，才发现那些我们曾以为只是早期模型残留、且会逐渐消失的问题——杂乱代码（slop），依然存在。

那是纯粹、毫无修饰的杂乱。mo 称自己都惊呆了，开始质疑自己，「难道自己之前难道没有逐行审核过每一段代码才合并的吗？这些冗余垃圾是从哪里来的？」

事后回想，一切其实早有征兆。

AI 写的代码片段，单独看都没什么问题，既符合自身逻辑，也契合你的提示词要求。但它完全不考虑整体系统，不重视架构的结构性完整，甚至无视相邻代码的设计模式。

AI 只是给大家讲了一个“好听的故事”。就像“氛围写作”（vibewriting）一部小说：AI 给你展示的几个段落确实逻辑通顺、语法正确，甚至能捕捉到不同角色的独特风格。但不知为何，当你通读整章内容时，会发现它一团糟——与整本书的上下文、前后章节的衔接都格格不入。

在通读了数月来 AI 依据详尽需求写出的累积代码后，mo 坦言道：“这破玩意儿绝不能上线。我不能拿这种东西收费，更不能用它来承诺保护用户数据。”

“我不能用这种代码欺骗用户。”

最终，mo 称，自己的大多数工作都开始回归手写代码了。令人意外的是，「把所有因素都考虑进去（而不仅仅是每小时生成的代码量），我比用 AI 时更快、更精准、更有创造力、效率也更高」。

越来越多开发者开始克制使用“氛围编码”

对于 mo 的举措，不少工程师，甚至一线教学者都表达了明确的认同。

在 Hacker News 上，一位名为 recursivedoubts 的网友给出了颇具代表性的分析。他指出，AI 真正危险的地方，并不在于它能做难事，而在于——它把“简单的事情”做得太好了。

这会让新手程序员极易跳过本该反复打磨的基础训练，心里想着“反正让 AI 生成就行”。结果不仅基本功没有真正建立起来，也逐渐失去了继续理解中等难度、复杂问题，乃至更高层次抽象思考的机会——而这些能力，原本需要通过大量练习，最终内化为直觉。

而这，正是教学一线最直观、也最令人焦虑的变化。

recursivedoubts 直言，作为一名计算机科学教师，这是他目前最担心的问题之一。因此，他会非常明确地告诉学生：代码必须自己写，不能把“写代码”这件事交给机器。学生阶段所需要练习的代码本身并不复杂，但也正因为如此，才更应该亲手完成——这是理解能力形成的关键过程。

另一位网友 leros 则从工程实践的角度，给出了更为直白的判断。他指出，自己看到不少初级开发者在热捧所谓的“Vibe Coding”，而大多数资深工程师更多只是把 AI 当作辅助工具使用——他本人也属于后者。

leros 表示，自己曾招聘并培养过大量刚毕业的初级工程师。通常情况下，在积累了一年左右的经验后，这些人的生产力往往能提升到最初的 20 倍。他认为，vibe coding 的确可以在短时间内把新手推到 5 倍生产力，这听起来非常诱人，但问题在于，他们往往会被卡在这个水平上，因为并没有真正学到东西。结果就是，一年之后，他们依然只是一个“5 倍工程师”，而不是本该成长为的“20 倍工程师”。

他也坦言，自己身边一些从业 1 到 3 年的软件工程师，对基础问题的理解之浅，常常让他感到意外。

类似的反思，也出现在更多工程师的实际使用经验中。Verdi 表示：“我同意这个观点，而且在过去几个月里也得出了相似的结论。”

他承认，把一部分任务交给大模型，节省下来的时间确实不可忽视，自己也会继续使用 AI。但他的态度已经从最初的“100% 投入 vibe coding”，转向了更加克制、审慎的使用方式——目前大概只占不到 40%。原因主要集中在几个方面：

模型生成的代码，几乎不可避免地会引入技术债。

随着时间推移，这些看似细微的问题会不断累积，最终形成一个连 LLM 自己都难以理解、难以继续演化的代码库。

与此同时，开发者本人的理解能力也会被削弱，逐渐失去对代码的内在连接，变成一旦离开 AI 就几乎无法排错，这种状态还会形成自我强化的循环。

最终，甚至在坐火车或飞机、无法使用 AI 的时候，生产力会直接归零——你会发现自己已经忘记该如何实现某些算法或语法，更缺乏对整个代码库的“心智模型”。

那么面向「氛围编码」，你使用的频率如何？以及如何看待它对自身技术能力的影响。

来源：https://atmoio.substack.com/p/after-two-years-of-vibecoding-im