我对Vibe Coding的感受（二）

距离上一篇聊 vibe coding 开发摆摊小程序的文章发布已经过去了三周，这段时间我出了十多天摊，根据实际的使用体验又攒下了不少新的功能需求。在端午假期里我成功完成了小程序 1.1.0 版本的开发和上线工作，这篇继续分享coding感受😃

目前整个小程序的代码量已经达到 15000+ 行。这个代码量放在以前用网页版对话编码的模式里是完全不敢想的。之前用网页版编写页面，代码量到500行之后，修改代码就很容易出现改动不全、漏改关联逻辑的情况，平白多出新bug。单就这一点来说 AI IDE 带来了史诗级的提升。

说回摆摊本身，我现在已经形成了一套固定的功能迭代闭环：晚上实地出摊测小程序功能 → 现场记录过程中遇到的问题、痛点和新需求 → 白天在家用 vibe coding 快速落地开发。基本每天都有新改动，每晚出摊就能直接做实测验证。

可能有人会问：摆摊过程中碰到数据问题，难道要现场改代码解决吗？

当然不用。这次版本更新，我最先落地的功能就是访客记录内容的修改与删除。有了这个功能，所有数据变动都可以直接在现场操作调整。我只需要把注意力放在数据结构的设计上——只要底层数据结构不出问题，上层的数据内容随时都能修正。

这次版本更新里，最核心的改动是数据存储方式的升级。最开始我用单 key 存储所有访客记录，后来查微信官方文档才注意到：wx.storage 总存储上限为 10MB，单个 key 最多只能存 1MB。按我每天产生约 17kb 的数据记录体积估算，单 key 的剩余容量最多只能支撑 45 天😥。

但数据存储的改动会牵扯到小程序的每一个页面和功能点，影响范围极大。我最初评估纯人工改动的话至少得 3 天，风险也比较高，所以这个需求记录后的好几天都不敢动手。一直拖到 6 月中旬才决定让 Codex 来做这次改动。动手前我提前给 Git 仓库打了 tag、备份了全量数据，随时准备回滚代码👌。

当时我已经做好了CodeX搞不定的打算，结果却出乎我的意料：Codex 只花了一块多的 token 成本，就完成了整套存储升级和数据迁移逻辑。过程中确实出现了一些小 BUG，人工比对后修复了一些问题，但考虑到它的完成效率和投入性价比，这点小插曲几乎可以忽略不计，随着这个大改动的落地，1.1.0版本也就顺利发布上线✨。

截止1.1.0版本的小程序，我大约消耗了18元的CodeX Token（0.23x倍率的中转站😂），相比于自己写确实省时省力多了。更多的时候，我的主要工作是验证操作流程对数据结构的影响，只要数据结构不出现问题，数据异常都可以通过“访客记录”页面进行修正。

最后，我突然觉得 Vibe Coding 不再是一个玩具了。通过快速迭代成长为一个可靠的工具，再用大量实际使用时间去验证它的稳定性与可用性。这比过去纯手工开发的周期时间，快的多得多❤。