患上“VibeCoding 洁癖”？当新模型发布，你是否总想重构旧代码

最近的 AI 模型迭代速度简直比翻书还快。前脚可能还在用 GPT-4.1 或者 Claude 3 Opus 把项目跑通，后脚号称“更聪明、更懂你”的新模型（比如各种代号 5 的版本）就发布了。

这时候，很多开发者可能都会陷入一种奇怪的心理状态：看着自己一个月前用旧模型“VibeCoding”出来的项目，越看越不顺眼。

面对旧代码时的心理挣扎

代码逻辑虽然是对的，功能也能用，但心里总觉得这堆代码是“屎山”，不够优雅，不够现代。这种被称为“VibeCoding 洁癖”的强迫症，让你抓心挠肝想重构：要是用新模型重写一遍，会不会更简洁？性能会不会更好？甚至会不会减少潜在的 Bug？

为什么你会觉得旧代码“脏”？

这其实不完全是因为代码真的烂，更多是技术落差带来的心理不安全感。

1. 能力的可见性：早期模型的代码生成往往偏向“能用就行”，可能会有冗余的注释、过时的库调用，或者不够聪明的命名。当你习惯了新模型那种“直击痛点”的风格，回头再看旧代码，就像在用 5G 的年代看 2G 网页，满是沧桑感。
2. 认知的升级：你在使用 AI 编程的过程中，其实也在不断学习。你对架构、对最佳实践的理解也在加深。现在的你回头看过去的代码，本质上也是现在的你在审视过去的自己，这种审视往往会带有批判性。
3. 完美主义的陷阱：开发者多多少少都有点完美主义倾向。如果是自己一行行敲出来的代码，可能还舍不得大改；但既然是 AI 几秒钟生成的，删掉重写的心理成本极低，这就助长了重构的冲动。

重构的投入产出比分析

重构还是忍住？这是一个 ROI 问题

心里的“草”虽然长得茂盛，但动手之前，建议先冷静计算一下 ROI（投入产出比）。

什么时候该重构？

• 核心业务逻辑：如果这坨旧代码是核心业务模块，且维护成本极高（比如每次改需求都要通读半天），用新模型结合你现在的认知进行重构是值得的。
• 已知性能瓶颈：旧模型可能在算法选择上不够优化，如果这里拖慢了整体系统，换新模型给出一套更高效的实现是必要的。
• 长期维护的项目：如果是你要养好几年的项目，现在花时间把地基打牢，后续能省无数麻烦。

什么时候该忍住？

• 边缘功能或一次性脚本：如果这个功能一个月都调用不了几次，或者只是为了验证某个想法，只要能跑就行，千万别因为“不优雅”就去重构。那是浪费生命。
• 工期紧迫时：不要在老板盯着上线进度的时候，因为“这变量名起得不够性感”而去重构。
• “如果不坏就别修”场景：旧代码虽然丑，但经过了生产环境的考验，稳定性是实打实的。新模型生成的新代码虽然优雅，但可能藏着边缘情况下的未知 Bug。

如何治愈这种“洁癖”？

1. 拥抱版本控制：既然想重构，那就用新模型生个新分支，跑跑测试。如果新代码真的惊艳且通过测试，再合并；如果发现新坑比旧坑多，果断 revert。把冲动变成实验，而不是负担。
2. 增量式优化：不要一上来就想推倒重来。下次修改 Bug 或者加新功能时，顺带让新模型重写那个具体的函数或模块。这样既满足了重构的欲望，又不会因为大动干戈而引入风险。
3. 关注结果而非过程：VibeCoding 的本质是“感受编程”，最终的目标是交付价值。只要代码安全、可维护、满足需求，它是用 Opus 写的还是用 Fable 写的，其实没那么重要。

总结一下：有“洁癖”说明你的技术在进步，对代码质量有追求是好事。但别让这种焦虑绑架了你的生产效率。在这个模型代际极速更迭的时代，“能用、够用、好用” 才是检验代码的唯一标准，至于这代码是不是长得像艺术品，还是留给业余时间去雕琢吧。