依赖AI“氛围编码”两年攒下的代码烂摊子，让我重新选择手写代码
“我不能用这种代码欺骗用户。”
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只是讲了个“好听的故事”。就像“氛围写作”小说：展示的几个段落逻辑通顺、语法正确，甚至能捕捉角色独特风格，但通读整章会发现一团糟——与整本书上下文、前后章节衔接格格不入。
通读数月来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的时候，生产力会直接归零——你会发现自己已经忘记该如何实现某些算法或语法，更缺乏对整个代码库的“心智模型”。
那么面向「氛围编码」，你使用的频率如何？以及如何看待它对自身技术能力的影响。
本文来自微信公众号“CSDN”，作者：mo；责编：苏宓，36氪经授权发布。
本文仅代表作者观点，版权归原创者所有，如需转载请在文中注明来源及作者名字。
免责声明：本文系转载编辑文章，仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布，请及时与我们联系进行审核处理或删除，您可以发送材料至邮箱：service@tojoy.com