Vibe Coding 之后如何重构

Vibe Coding 很适合做原型。你有一个想法，边想边说，Agent 边写，几个小时后东西就跑起来了。Mario 做的小机器人就是这样的例子：他一边焊接硬件，一边对着语音输入描述需求，让 Pi 帮他生成 Web UI、WebSocket 通信、语音输入、文字转语音、摄像头拍照和电机控制逻辑。

结果是，项目真的能跑。孩子们能和机器人互动，机器人能转头、拍照、回答问题。作为周末玩具，这是成功的。但从代码结构看，它也非常典型：一个巨大的 index.ts，前端 UI、WebSocket、摄像头、音频、USB 控制、电机逻辑混在一起；服务端也曾经是一个大文件，只是后来被拆过。

这就是 Vibe Coding 的常见结果：功能先跑起来，结构后面再说。对于一次性工具和低风险玩具，这完全可以接受。但如果项目要继续演化，就必须重构。否则下一次需求不是“加一个小功能”，而是在一团混乱里继续堆复杂度。

重构的第一步不是改代码，而是恢复理解。Mario 会先让 Agent 阅读客户端和服务端代码，解释它们分别做什么、如何通信、有哪些 RPC 请求、哪些逻辑属于工具实现、哪些属于 UI 状态。这个阶段的目标不是让 Agent 立刻拆文件，而是先建立系统地图。

第二步是找边界。比如机器人项目里，很自然的边界包括：RPC 通信层、摄像头工具、电机工具、语音播放、日志、UI 状态、设置页、机器人表情页。重构不是随便拆文件，而是把“变化原因相同”的逻辑放在一起，把不同职责隔离开。

第三步是小步抽取。不要一次性把整个前端重写掉，而是先抽一个明确模块，比如把工具实现移到 client/tools，再处理 RPC server/client 抽象，再拆 UI 状态。每一步都看 diff，确认行为没有变，只是结构更清楚。

第四步是接受现实：不是所有原型都值得补齐完整测试。对于这种玩具项目，最有效的验证可能就是跑起来、连上手机、看机器人会不会动。但如果这个项目变成生产系统，就必须逐步引入自动化检查、边界测试和集成测试。

Vibe Coding 之后的重构，本质上是在还债。Agent 帮你快速证明“这个东西可以做”，但工程师要把“可以跑”变成“可以维护”。这个过程不能完全交给 Agent，因为重构最重要的不是移动代码，而是重新定义边界。

所以更健康的做法是：允许 Vibe Coding 作为探索阶段，但不要把探索阶段的代码直接当成长期架构。先用它验证想法，再用工程方法把它拆干净。

相关：从 Vibe Coding 到 Spec Coding：如何用 TDD 解决 AI 带来的“架构崩坏”、如何让 Agent 不把代码库写烂、大代码库里如何管理上下文