实践复盘：高强度 Vibe Coding 一个月，使用 Claude 开发游戏本地存储的感受

最近一个月，工作上深度体验了一把高强度的 Claude Vibe Coding（因为个人项目一直用 Gemini）。正好公司这个月给了充裕的 API 额度，而手头近期在负责开发一个全新的游戏内本地相册存储功能。于是顺势转变了开发模式：由我来负责设计整体需求和框架，让 Claude Opus 4.6 作为主力编写核心代码。

经过一个月的实践，最大的感受是：当需求明确时，AI 是极佳的辅助工具；但在不断完善需求和修复问题时，人类程序员的经验依然不可或缺。

需求明确时，AI 代码完成度极高

在项目初期搭建框架时，只要提供清晰的需求边界，AI 就能快速输出符合预期的代码。

例如，在处理本地相册文件完整性时，要求实现防数据损坏功能。Claude 立刻领会了意图，并完美借鉴了 SQLite 的 WAL（预写式日志）模式。它准确地实现了临时文件写入、原子替换和故障恢复逻辑。在这个阶段，只要需求明确，AI 就能把细节处理得很好，省去了大量手写样板代码的时间。

修复问题时，AI 暴露了局限性

然而，当项目进入需求迭代或问题修复阶段，Claude 的局限性就体现出来了。

AI 最大的痛点在于缺乏全局视角的把控。遇到逻辑冲突时，它的第一反应往往是打补丁：老是喜欢新增字段，或者开辟新的 if-else 分支，而不是从整体系统的角度去融入新功能。这时候如果完全听从 AI 的安排，代码很快就会变得难以维护。

典型踩坑案例：Texture2D 缓存引用计数

在开发 C# 端的 Texture2D 缓存引用计数功能时，遇到了一个典型的案例。

该功能主要用于管理相册的内存。整体架构设计了两个缓存区：活跃页和非活跃页。如果有引用，就丢进活跃页；如果没引用，就进非活跃页，随时准备被淘汰清理。

结果在处理异步回调与缓存引用的结合时，出了一个 Bug。起因是 Claude 编写了一段错误的时序逻辑：先将页面推入非活跃页，然后再去标记引用。这会导致一个致命问题，如果当前容量刚好超限，第一步推入非活跃页后，页面会直接被清理掉，导致随后的引用标记彻底失效。

为了修复这个 Bug，Claude 给出的方案是：加一个 is_early_marked（提前标记）的字段，试图用增加新字段的方式来绕过生命周期错误。

这个方案直接被否决了。凭借对整体生命周期的理解，重新给它下达了明确的指示：整体检测非活跃页面并执行清理的阶段必须做延迟，保证该阶段发生在异步操作标记引用之后。通过调整整体时序，问题干脆利落地解决了，完全没有增加任何冗余的脏字段。

总结

这次经历证明，AI 极大地提升了编码效率，但也容易掩盖架构上的隐患。

如果是没有经验的程序员，遇到上述的并发 Bug，大概率会直接采纳 Claude 的建议。那么标记字段和 if 分支只会越来越多，最终导致模块彻底失控。在 Vibe Coding 的模式下，具体细节可以不用自己抠，但整体框架的视角和防范烂代码的经验，依然需要人类开发者来坚守。