告别氛围编码：我如何从AI生成代码的烂摊子中重写核心系统

“氛围编码”这个词，现在提起来我都有点PTSD。过去两年，我几乎把所有能交给AI的代码都交给了AI——丢给它一个需求描述，让它“照着氛围写”，写完直接跑，跑通就算完事。当时确实爽，一天能交好几个功能，老板满意，我也以为自己效率翻倍了。直到最近，这个“2年攒下的烂摊子”开始反噬——我发现自己面对一个自己亲手“催生”出来的项目，完全不敢改代码，因为改一行可能炸掉三个模块，而这三个模块的代码我看不懂也不再理解了。终于，在一连串线上问题之后，我被逼着做了职业生涯里最痛苦也最清醒的决定：把手底的系统拆开，重新手写核心代码。

这篇文章就想跟你聊聊，氛围编码是怎么帮我挖出一个深坑的，以及我为什么最终还是选择回到“手写代码”这条路上——不是否定AI，而是重新夺回对代码的主导权，顺便给同样在这条路上挣扎的人一些可执行的参考方案。

1. 氛围编码的甜头与陷阱：它为什么“好用”，又留下了什么

1.1 氛围编码到底是怎么回事

先说概念。“氛围编码”（vibe coding）这个词，简单说就是让AI尽可能多地参与编写代码，人类只需要提供一段自然语言的需求描述，比如“写一个用户登录接口，带token刷新”，然后照着AI生成的结果用起来就行，碰到报错就继续把报错往对话框里丢，让AI修到跑通为止。

我一开始并不是全盘氛围编码，只是用它写一些工具的脚本、临时报表的SQL，后来慢慢演变成核心业务模块也让它写。那个流程是固定的：我打开一个空的文件夹，作者在脑子里想好大概要什么功能，然后对着AI编辑器说“帮我搭一个什么什么系统”，然后就是一连串的“这个功能再加一下”“这个地方老是报错，修复一下”。代码长得什么样？没看过。逻辑是怎么串起来的？不清楚。测试怎么写？AI说“不用写，我给你补”，它真的补了，但我从来没跑过那些测试。

站在当时的视角，氛围编码的吸引力是真实存在的。它把“从零到能跑的Demo”的时间压缩到了极致，对于验证创意、做内部原型、临时数据清洗这些场景，效率提升明显。我刚接触时也真心觉得，这可能是未来写代码的方式——毕竟能力再强的工程师，一天手写也就几百行高质量代码，而AI在几分钟内就能产出上千行。

1.2 它的核心缺陷：你在“生产代码”，但你没在“理解代码”

但要命的是，氛围编码有一个根本性的错位：它让开发者处于一种“生产者的位置”而非“作者的位置”。你可以指挥AI按照你的意向产出一堆代码，但你完全没有——或者说放弃了——对每一行代码为何存在的理解。刚开始你可能觉得无所谓：能跑就行嘛。

但这种“能跑就行”的心态，会在代码量膨胀之后变成一场灾难。我大概在用到第8个月的时候，开始感觉到不对劲：某次改一个很小的配置项，我让AI帮忙找是哪里读的，它找了三遍没找到，最后我自己去全项目搜关键词，才在一个我不记得怎么生成的工具类里发现了硬编码的配置。那一刻我突然意识到，这个项目的认知负担已经超出了我的掌控——问题不是AI写得不好，而是我的头脑里没有这张代码地图。

用个生活化的类比：氛围编码就像是叫了一位极其高效的外包团队来帮你装修房子。他们很擅长按照你口头描述的样子把墙刷好、柜子装好，但你从未看过图纸，也从没自己摸过管线。有一天水管堵了，你连总阀在哪里、墙里管线怎么走的都不知道。嵌入式的水管尚且可以砸墙，但代码里的“管线”要是砸错地方，那就不是漏水，是整栋楼塌掉。

1.3 氛围编码真正适合的边界在哪

我并不想一棒子打死氛围编码。经过这两年踩坑，我总结出它的适用边界大概是这样几条：

• 一次性脚本或原型验证：用完即弃，没有后续维护需求，跑完拿到数据或结论就删。
• 文档注释、重复模板代码的批量生成：比如给几十个DTO写注解，人工写没价值，AI出活快。
• 测试数据的构造、临时mock服务、压测脚本生成：产出物本身不重要，重要的是快速拿到可用环境。
• 帮你回忆语法或处理繁琐的配置细节：比如某个框架的完整配置示例、某段不常用的API用法。
• 技术探索期的辅助：当作“高级搜索引擎”用，快速生成一段能跑的代码来观察行为。

反过来，核心业务逻辑、涉及状态管理的模块、需要长期演进和多人协作的系统，这些坚决不能完全交给氛围编码。我说“完全”而不是“不能”——是因为AI可以介入某些局部，但你必须亲自做架构决策、理清模块边界、至少通读并理解每一条核心链路。否则，你只是在写一份“发布说明”，而不是在写代码。

2. 烂摊子全景拆解：氛围编码2年后代码库的真实面目

2.1 “屎山”最典型的四大症状

如果你也长期依赖AI生成代码，你的项目很可能已经出现了下面这些症状。我用自己手头那个被逼重写的系统为例，列出最常见的四类问题：

第一，隐式依赖无处不在。我原来核心模块里有一个配置文件，氛围编码时代AI为了让“某个功能快速跑通”，直接在几个工具类里硬编码了文件路径和参数。当时我因为不懂细节，没意识到这个硬编码的存在。结果后来要迁移环境，这个路径藏在三个不同的类里，一个没改到，线上就是一连串的路径报错。这不是AI的锅，是我没把“全局扫描一遍配置引用”当成必做项。

第二，重复代码堆积成山。AI在生成代码时有个特点——它永远不会主动“复用已有的东西”，因为为了确保当前生成的片段能独立运行，它倾向于把依赖的辅助函数、常量、工具逻辑完整复制一份嵌进去。我后来统计那个项目的重复代码率，接近35%。这意味着整个代码库里躺着大量看似不同、实则一致的逻辑实现。改动一处，其余还有七八处在“假装正常”地跑着旧逻辑。

第三，混沌的模块边界。氛围编码时代，我从来没有认真定义过模块之间的接口。需求来了就说“让我在现有代码上再加一个类”，AI生成的新类如果跟旧类有重名，它有时会“聪明地”再生成一个新的文件，然后靠类型推断或者动态调用硬接进去。时间一长，整个项目变成了一张巨型互相调用的“蛛网”。我从没画过它的架构图，因为完全画不出来。

第四，测试形同虚设。这里要说的不是没测试。恰恰相反，AI很“配合”，你说要测试它就给你生成测试，但全是那种“为了通过而通过”的用例：写死输入和期望输出，覆盖率看着还行，实际对业务逻辑的保护价值很低。真正碰到边界条件、异常路径、数据不一致的情况，测试根本帮不上任何忙。更糟的是，如果运行环境稍有不同，这些测试甚至跑不过——它们更像是“为了证明代码存在”，而不是“为了证明代码正确”。

2.2 一个具体的翻车案例：我差点把生产数据全抹了

说个具体的例子。某天产品提了个需求，要求给用户列表增加一个筛选功能：按注册来源筛选。听起来很简单对不对？氛围编码模式下，我把需求贴在对话框里，AI很快生成了一段改动。我没有细看，只简单测了“筛选之后列表正常显示”，就合进主分支准备发布。

结果上线之后，运营那边在后台用筛选功能时突然发现数据少了——不是显示问题，是数据库里的记录被删掉了一批。我当时吓得手心冒汗，赶紧回滚并查日志，发现AI在生成筛选逻辑时，“顺手”在某个公共数据访问方法里加了一个条件：如果来源参数为空，就执行delete操作。它为什么这么加？我不知道，可能是在某次“修复”时被AI自动脑补出来的逻辑。它自以为聪明地“清理无效数据”，但那个方法的调用方不止有筛选功能，还有其他业务模块。

这件事给了我巨大的冲击。问题的根子不在AI写错了，而在于我不了解这个模块的完整逻辑——我不知道那个公共方法被哪些地方调用，也不知道AI在实现新需求时偷偷动了旧的逻辑。如果当时我对代码有足够认识，看到AI生成的结果时，我会立刻发现那个莫名的delete语句，并意识到它施加了不可接受的副作用。可事实恰恰相反，我根本没有形成“审查”的习惯。这种“AI帮你删了一行你全然不知”的时刻，比任何技术债描述都更让人后怕。

2.3 氛围编码债务的累积曲线

如果你还处在“大力出奇迹”的阶段，我建议你用下面这条曲线来评估自己项目面临的债务风险：

• 第1到6个月：代码量爆发期，需求交付速度飞快，心态极度膨胀，感觉“再也不用手写了”。
• 第6到12个月：开始出现“某个模块不敢动”的现象，因为一改就有人际联动的报错；需要频繁问AI“之前那段代码是干嘛的”。
• 第12到18个月：新需求交付速度明显下降，因为AI生成代码的时间不长，但“把新代码嵌进旧系统再调通”的时间越来越长。改动一处，测试一片，回归一遍，心累到极点。
• 第18个月以后：你发现自己完全不想碰这个项目的核心区域，要么改需求就推倒重来，要么对外宣称“这块已经冻结了”，实际上是你自己也不知道它还有多少秘密。

我就是走到了第20个月，才被现实强按着头承认：继续用氛围编码缝补这个项目，只会把烂摊子越铺越大，唯一的选择就是把核心抽出来，亲手重写。

3. 重新手写代码不是返工：这是一次代价更低的止损

3.1 什么情况下该动手重写，什么情况下还能救

说到“重写”，很多人的第一反应是“成本太高了吧，公司不会批的”。我自己也曾经被这个念头吓退过，但实际经历过之后，我觉得真正的判断标准不是“成本高不高”，而是“继续修补的成本是否已经超过了重写”。对于氛围编码攒下的项目来说，有两条硬指标可以参考：

• 指标一：你修改任何一个基础模块，平均需要研读超过三个以上无关文件才能定位改动范围。
• 指标二：你无法在一小时之内画出当前核心链路的调用关系图，起码要找出“请求从入口到落库”中间经过的每一个方法。

只要这两条里有任何一条不满足，就说明代码库的认知负载已经失控，重写的必要性就成立了。但如果项目本身很小、依赖方很少、马上要废弃，那就不要重写了，直接让它“体面退休”即可。

从我个人的经验看，重写不是“把代码用AI再生成一遍”，而是你开始亲手创建项目骨架、亲自动手定义每个模块的边界和接口、亲手写出第一条核心链路。它不是在抄作业，而是逼着自己把之前缺失的功课全部补上。这个过程要把“AI能帮你搞定一切”的心态扔掉，用“我要真正掌握这个系统”的心态去重新组织代码。它当然比让AI生成慢，但慢的是过程，快的是之后的维护响应速度，这两笔账不能只算眼前。

3.2 重新手写前的准备：摸清现存系统的真实行为

在动手重写之前，我花了两周时间做一件看起来“很没用”的事：逆向梳理旧系统的行为。先让AI帮我从系统日志、数据库操作记录和线上监控里把核心请求的时序拉出来，然后我手动画出调用关系图和状态流转图。这一步的本质是，把旧系统当作黑盒去“考古”，而非靠读代码去理解——因为代码本身可能就是错的，但线上行为是真实发生过且被验证过的。

我用表格整理了每个核心接口的行为特征，包括输入参数、依赖数据、副作用、异常分支和性能特点。这个过程非常痛苦，但也让那些以前藏在AI生成代码里的隐藏逻辑浮出水面——比如之前那个delete操作，它到底在什么条件下被触发，哪个调用方会受影响。

然后，我开始为关键路径写“行为规格说明”，说白了就是：不管这条代码是怎么实现的，先写下它应该做什么。这份规格说明在后续手写代码时就是我们的“施工图纸”。避免重写过程中“边写边改约定”造成新的混乱。强烈建议你也这样做——它帮你把“AI生成代码”时代的黑盒行为，清晰转化为可以指导人工开发的契约。

3.3 动手重写的优先级：先把最痛的那块骨头啃下来

重写的顺序也是有讲究的。我见过有人一上来就想把整个项目全部推翻，结果写了三个月连一个可运行版本都没出来，心态直接崩掉。我的建议是“窄口切入”——先选一个影响面最核心、让你最痛苦的模块来重写。

我的选择是数据访问层和状态管理模块。这两个模块是所有业务逻辑的底层前提，也是之前AI代码里隐式依赖和重复逻辑最密集的地方。先在这个层面亲手写出干净的模型和基于明确接口的数据访问方式，再往上重建业务逻辑时，就会轻松很多。

重写第一版时，不要追求功能100%覆盖旧系统。你要优先保证“核心主链路跑通”：比如一个用户从注册、登录、提交主业务，到数据落库、读取展示的完整闭环。把这条链路用自己手写的代码跑通了，就相当于给新系统打下了“定海神针”。剩下的边角功能，再一个个从老系统里“搬”过来——每搬一个，都要对照之前整理的行为规格说明，确保没有遗漏或偏离。

3.4 如何划定重写范围，避免“范围爆炸”

重写最容易失控的点是：你还想把旧系统的每一个“怪癖”都保留下来。比如某个接口需要返回一个很别扭的结构，仅仅是因为前端早期那样消费了；或者某段业务逻辑有个if分支，但你根本不知道那个分支是否还有人走。我以前的心态是“既然旧系统这样，我就照搬吧”。但这次不一样——我会把每个要保留的怪癖都当成一个“需求决策”来审视。凡是我搞不清楚用途的分支、参数、特判，直接列表标注“待删除试验”，等新的核心链路稳定运行一段时间后，在确保没有业务依赖的情况下坚决移除。

重写期间的团队协同和个人精力管理也很重要。毕竟你已经花了两年代价才走到这一步，不能因为这个过程太累而中途放弃。我当时给自己定的规则是：每天先花至少45分钟纯粹手写核心代码，不打开AI自动生成窗口；只有在写测试、生成迁移脚本或查某个框架语法时，才允许“请AI帮忙”。这个节奏保持了大约两个月之后，新系统已经具备平稳替换旧模块的能力。

4. 技术栈与工程化选择：换掉哪些“氛围编码”留下的隐患

4.1 工具链咋调整：AI辅助写作代码的正确打开方式

重新手写代码，不代表你要彻底告别AI。我的态度是：可以走AI辅助，但角色彻底调转了——人类做架构师，AI做打字员。具体来说，我会用AI完成四类固定工作：

• 帮我快速生成DTO、常量类、配置项的初始模板。
• 帮我写重复性很高的单元测试用例的外壳，比如测试数据的builder。
• 帮我翻译旧系统的SQL逻辑到新系统数据访问层的方法注释。
• 帮我做代码风格的统一和基础重构的批量修改。

但是，核心业务逻辑、状态机转换、锁与并发控制、事务边界这些“系统灵魂”部分，我一定自己写，而且写完一行一行再看一遍。请记住一句话：AI生成代码最好用的时刻，是你已经明确知道要什么的时候，而不是你希望它帮你探索要什么的时候。

4.2 架构设计的取舍：避开隐式依赖，拥抱显式契约

重写过程中，我给新系统立了几条纪律，每一条都是对着旧系统痛点量身定的：

第一，所有模块之间的交互必须通过明确的接口定义。不管是内部方法还是跨服务调用，先定义好输入输出和异常语义，再写实现。严禁模块之间偷偷访问对方的内部工具类。

第二，配置必须集中化管理。旧系统那种“硬编码散落多个工具类”的灾难绝不允许再次发生。所有环境相关的参数，统一进入配置中心或至少一个显式配置类，并通过代码扫描工具保证没有漏网之鱼。

第三，禁止“复用型复制”。如果某个逻辑需要被多个模块使用，那它必须是独立模块并引入依赖；如果因为解耦问题暂时无法下沉，那就把重复代码的“提取重组”作为技术债显式记录下来，排进迭代计划，而不是假装看不到。

第四，写代码时同步画图。哪怕是简单的模块依赖草图，其实就是在逼自己把系统的结构在脑子里显式化。氛围编码时代，系统在自己脑子里就是一堆“生成物”的集合；手写时代，你要让系统结构变成可讲述、可画出来的图景。

4.3 数据迁移和兼容策略：不让重写成为第二场灾难

重写系统时，数据格式、存储位置甚至表结构都可能调整。这里的核心风险是：如果新系统和旧系统的读写不能平滑切换，重写就变成了“数据割裂”。我当时是这么处理数据迁移的：

• 新系统上线前，先做一次“影子运行”：把新系统部署在与旧系统并行的环境里，开启灰度开关，流量先打到旧系统，但新系统同步读取真实数据，持续对比两者输出结果。
• 等到行为对比连续两周没有差异，再把读写切到新系统，旧系统保留只读模式，方便随时回退。
• 切换完成后，继续观察至少一个完整业务周期，比如月底对账、批量任务执行，确认无数据异常后再把旧系统彻底下掉。

这套流程的核心就是“诚实的灰度”。氛围编码时代我往往跳过这个环节，直接全量上线AI生成的代码，等线上出问题再紧急修复，实际上是在用生产环境当测试环境。重写之后，我宁愿慢一点，也要让每一步切换都有据可依。

4.4 重写期间的度量：怎么知道自己真的在变好

重写总会伴随焦虑：花了一两个月，功能还少一大截，到底值不值得？我自己的经验是，盯着几项关键指标看，而不是用“功能数量”这种氛围编码时代特别容易膨胀的指标。用一张表来记录项目健康度：

度量不是为了写汇报，而是为了让自己随时知道：手写代码是否在朝着“可维护、可掌控”的方向前进。如果某项指标在重写过程中迟迟没有改善，就要警惕是不是犯下新的架构错误——提前修正，比全部写完再回头排雷要省力得多。

5. 手写代码之后：我到底拿回了什么

5.1 认知状态的变化：从“代码观游”到“代码掌舵”

如果你问重新手写核心代码之后最大的感觉是什么，我会说是认知状态的改变。以前看到AI生成的项目代码，内心飘着的是一种“不可知”的迷惘；哪怕它什么bug都没有，我心里也是悬的，因为我不知道它为什么会这样。但手写核心代码的过程，本质上是让我重新完成了一次“作者责任”的确认。

我记得新系统核心链路第一次完整跑通时，我看着日志里的每一步流转，那种感觉跟以前“AI写代码跑通了”完全不同。它不是一种“几乎”：我知道这条链路一共经过几个模块、每个模块各自处理了什么、哪里可能出问题、在什么条件下会出问题。我可以拍着胸脯跟团队讲清楚这个系统在干什么，而不是含糊其辞地说“它应该可以”。这份踏实感是氛围编码再快也给不了的。

5.2 对团队协作的影响：代码变成了一门可沟通的语言

另一个显著的变化发生在协作层面。氛围编码时代，我很难跟同事讨论代码——因为大部分代码都不是我“想”出来的，我也没有足够理由解释它为何长这样。同事接替我review时也极其痛苦，因为他们面对的是“遗物考古”。

手写重写之后，代码的每一处设计决策都有据可循。模块之间靠接口沟通，核心逻辑有注释说明自己为何这么做，复杂分支有测试锁住行为预期。团队里的新同学接手时，不再需要靠AI“翻译”这坨代码，而是可以直接读、可以改、可以提出更优方案。这才是工程协作该有的样子。

5.3 现在还整天用氛围编码吗

我的答案是：用，但完全变了用法。我依然会让AI帮我写日志聚合脚本、生成压测数据、补全注释和简单的测试骨架，也会用AI快速排查某个第三方库的报错原因，甚至会让它帮忙把一段冗长的旧代码重构得更紧凑，但我亲自通读改动结果，确认它没有改变任何行为。

对应到日常开发流程里，我会设定“AI辅助红线清单”：涉及事务控制、锁、权限、数据迁移、外部接口契约的代码，一律不交给AI生成；涉及性能和安全性的实现细节，必须人工评审后再合入。氛围编码不再是默认选项，而是众多“效率工具”之一——它服务于一个我完全理解的系统，而我不再服务于它生成的未知代码。

6. 避坑心得与执行清单：给也想戒掉氛围编码的你

6.1 五个“绝对别做”与五个“一定去做”

如果你看完前面的分析，也决定要给自己的代码库来一次“清创”，下面这份执行清单是我踩了无数坑之后浓缩出来的：

绝对别做：

• 绝对不要在重写之前，迷信“照抄旧系统逻辑就行”——旧系统逻辑本身就是屎山的一部分，盲抄等于把债务换个壳带进新系统。
• 绝对不要一次性“大爆炸式”重写——那会让你在几周内没有可交付物，心态先崩，项目也可能被叫停。
• 绝对不要忽视数据迁移的灰度验证——新旧切换不经过影子运行和对比，就是在拿生产环境赌博。
• 绝对不要只重写代码不重写文档和架构图——手写过程中画下的图，就是未来几天、几月、几年里你和其他维护者的指路明灯。
• 绝对不要让AI直接生成你的核心业务逻辑——哪怕你靠它查语法、生成模板，最后一行一行审查并修改的是你，作者责任在你这头。

一定去做：

• 一定先做旧系统行为梳理，写一份“旧行为规格说明书”，无视代码、只管行为。
• 一定先用一根完整主链路跑通新系统，哪怕是手写得很土，也要让它作为一个闭环存在。
• 一定给每个模块定义干净的接口和异常协议，不允许跨模块引内部类。
• 一定在重写期间定期做代码评审，让第二双眼睛帮你发现“氛围编码后遗症”可能复发的地方。
• 一定给自己设置“无AI手写时段”，哪怕每天只有45分钟，坚持下来，那份代码会让你骄傲地摸到它的每一寸。

6.2 关于心态的几句大实话

最后想说点心态层面的东西。重新手写代码，不是“退步”或者“否认AI的价值”，而是一种主动的权利回归。你用两年时间体验到AI生成代码的高效，也踩遍它带来的雷，这些经历都是财富——它们让你真正懂得哪些环节可以放手给工具，哪些责任必须留在自己手里。这跟开车很像：自动驾驶辅助很好用，但如果你在自动驾驶路段开了两年，却再也不会自己判断车距、自己打方向盘，那这辆车早晚会把你带到沟里。手写核心代码，就是在重新训练你的路感和方向盘手感。

也不要因为“重写太慢”而焦虑。氛围编码把代码量堆起来的速度快，垃圾也堆得飞快；手写代码的速度看起来慢，但写的是承重墙和地基。

我现在的体会是：项目里的核心代码，就该是“手写”的。AI可以当脚手架、当助手、当生成器，但它不该替代你的判断。毕竟，一个你能完全看懂的、能勇敢改动的、能在凌晨三点出故障时快速定位的系统——那种安心感，是任何一个高速生成的代码库都给不了你的。

如果你也正对着一个氛围编码攒下的烂摊子发愁，别犹豫了，从梳理旧行为开始，亲手重写第一步。相信我，这个决定虽然痛苦，却是我这两年做过最值得的一件事。