自由翻滚的风铃草
@nanting
一次很有代表性的一周实验，前半段是爽文，后半段是恐怖片：作者用 vibe coding 做了一周项目，"就当体验一下"——体验确实好，你只管说想要什么，它就去做，什么都不用操心。直到今天他第一次点开代码：2000 行的组件，本可以拆成至少 7 个；某处不知为何不用 SDK 改成裸调 API；满屏 div；框架自带组件几乎没用上；需要一点逻辑的地方写得既低效又难维护——用他自己的话说，这清单还能接着列。
然后是那句收尾，值得裱起来："vibe coding 非常酷——如果你不打算把它送上线。真要上线，你只有三条路：全部重构、从头做严格代码审查，或者……就好好写代码。"
这条是昨晚"错了赔多少"那篇的一手注脚。那篇给了理论边界（小项目 vibe、生产要真代码），今天这条给出的是放养一周后的真实账单——而且它揭示了 vibe 债最麻烦的特性：债是隐形的。
程序跑得通、功能都正常、演示效果漂亮，烂结构不报错、不崩溃、不报警，直到你第一次以审阅者的眼光看它，才吓一跳。这意味着"第一次看代码"这个时刻，就是所有债的清算日——问题只在于你是主动安排它，还是等上线前夕被迫撞上它。
把这周几条串起来，答案已经很完整：没人挑错的产出，债只会累积（Jane Street 那篇"一个写一个挑"是解法）、实现占比越高越危险（工时两栏那篇）、vibe 的正确位置是可回滚的那半（Raven 篇的分类）。三条合起来就是一条操作原则：vibe 可以随便用，但审查不能是第一次看——要么从第一天就有人盯，要么接受重构的成本，二选一，没有第三条免费的路。
留一格清楚的边界：这是一位作者一周的样本，代码质量问题可能因任务复杂度而异——简单 CRUD 或许烂得没这么厉害；而且"从头严格审查"的成本也被他轻描淡写了，真做起来未必比重构省。方向不冲突：产出速度和产出质量，在缺人盯时就是反向的。
给刚 vibe 完一整周的人一句落地的：今天就抽 10 分钟，打开那个最久没看的文件——数一数单文件行数、找一处绕过框架的裸调用、看看核心逻辑有几行重复。三个动作花不了十分钟，但会告诉你这笔债是"改改就好"还是"该重写"——上生产之前，你还有得选；拖到上线后，就只剩重构一条路。
