Vibe Coding 实战：两周、104 次提交，我做了一款背单词的爬塔小程序

写在前面：大家好，我是晴空๓。之前我在博客和公众号里聊过 Token、大模型是如何“思考”的，这次想分享一次更完整的 AI 实践：我怎样用 Vibe Coding，从空文件夹做出一款可以上线的微信小程序。

这不是一个“输入一句话，AI 自动生成整个项目”的故事。相反，这两周让我更加确定：AI 可以显著加快开发，但产品判断、真机验收和质量底线，仍然需要人来负责。

10 月 14 日，我建了一个空文件夹。

10 月 28 日，这个文件夹里多了一款名为「单词塔背单词」的微信小程序：

• 400 层可供挑战（博主正在精修400+以上楼层，欢迎大家来爬塔背单词）；
• 6,044 个去重单词；
• 104 次Git 提交；
• 4 个页面、5 个云函数；
• 37 个测试文件全部通过。

它把背单词和爬塔游戏放在了一起：答对单词就发起攻击，击败守卫继续上楼；答错会被反击扣血，血量归零就会坠落。

这篇文章既是这个项目的开发复盘，也是一份 Vibe Coding 的真实使用记录。当然，如果你只是对小程序感兴趣，也可以直接微信搜索单词塔背单词来爬几层。

一、先看成品：背单词，也可以像打怪升级

「单词塔背单词」的核心规则并不复杂：

1. 每层有一个守卫，给出一个英文单词；
2. 玩家从四个中文释义中选择答案；
3. 答对就攻击守卫，击败后向上爬；
4. 答错或超时会被扣血；
5. 每 10 层出现一个 Boss，检验这一阶段的单词。

我很早之前就有做一个背单词的小游戏，之前再某款背单词APP上面见到过滑动选字母拼成单词的小游戏，如果拼对了就打一下对面的小怪，打错了就被对面锤。可惜后来这个小游戏不知道为什么下架了，我后来还去问了客服，客服说让我回退旧版本试试看……。把背单词做成小游戏我觉得很有意思：先让它有游戏该有的反馈、目标和成长感，让学习在游玩过程中自然发生。极大的减少了背单词的“痛苦”。

答对时有挥剑、受击、连击和得分反馈；答错时会扣血，也能马上看到释义和例句；继续向上还有新的词池、装备、勋章和排行榜。

以前打开单词书，目标是“今天背完这一页”；现在打开小程序，目标变成了“我再答对几题，就能过这一层”。

Boss 战不是随机抽题，而是阶段测验

普通层主要负责接触和学习单词，Boss 层则负责复习。

Boss 的题池来自本大层前 9 层出现过的单词，并优先把多义词和例句变成语境题：不再只是问“这个单词是什么意思”，而是给出一句话，问“它在这里是什么意思”。

这样一来，Boss 战就不只是血量更厚、答题更多，而是真正成了一次阶段验收。

爬累了，也可以回塔里复习

已经通关的楼层可以重新进入。系统会保留本次爬塔中的楼层记录，玩家可以回到下一层复习原题，也可以进入“塔内研习”，查看更详细的释义、例句、常用短语和搭配，并播放单词发音。

这个入口只放在已通关楼层。原因其实很简单：当前题还没有答对，就不应该提前进去看答案。

很多类似的细节，都不是第一版就想到的，而是在真机试玩时发现“这里说不通”，再一点点改出来的。

每天一次，用同一套装备重新挑战

游戏里还有一个我比较喜欢的模式：每日一爬。

每天从第 1 层出发，看看今天能爬多高。为了让成绩更公平，这个模式里所有人统一使用初始装备，不吃自己已有的护甲、武器和药水加成，倒下就结算。

老玩家可以重新挑战自己，新玩家也不用先追别人的装备进度。

除此之外，目前还有：

• 楼层榜与连击榜；
• 每日签到；
• 武器、护甲和自由换装；
• 勋章墙与已学单词明细；
• 错题重考与漏词补漏。
  

二、我理解的 Vibe Coding，不是“许愿式编程”

这次开发之前，我对 Vibe Coding 的期待也很简单：把想法告诉 AI，让 AI 写代码，自己少敲一点键盘。

真正做完以后，我发现更有效的合作方式应该是：

换句话说：

AI 负责提高实现速度，人负责判断方向，测试负责守住底线。

如果只说“帮我做一个背单词的小程序”，AI 确实可以很快生成一堆页面。但“能运行”与“好玩”“词义正确”“老存档还能用”“换台手机不出错”，中间还有很长的距离。

Vibe Coding 并没有省掉这些工作，只是让我能把更多时间放在它们上面。

三、两周开发，到底做了什么

整个项目大致经历了下面几个阶段：

技术栈没有刻意追求复杂：

• 客户端：原生微信小程序，无框架、无构建工具；
• 云端：微信云开发，使用云函数、云数据库和云存储；
• 词库：开源英汉词典数据、Node 处理脚本、AI 分片补全；
• 发音：腾讯云 TTS，同一个词合成后缓存复用；
• 测试：Node 直接加载页面逻辑，模拟微信 API，一条命令跑回归。

选择原生小程序，是因为项目没有跨端需求，少一层框架就少一层心智负担；选择云开发，则是因为个人项目不需要自己维护服务器，可以把更多精力放在玩法和数据上。

104 次提交听起来很多，但它们并不是 104 个大功能。更多时候，一次提交只解决一个问题：修一个倒计时边界、补一组例句、调整一个弹窗、增加几条测试。

这也是我在这个项目里一直坚持的习惯：小步实现，小步验证，小步提交。

四、让 AI 真正帮上忙的 5 个做法

1. 不只告诉 AI“要什么”，还要告诉它“什么不能动”

项目里有两类文档：

• 需求文档.md：记录产品要做什么、规则是什么、哪些事情暂时不做；
• AGENTS.md：记录当前项目状态、文件入口、验证命令和不能破坏的约束。

比如，需求文档可以写“答错扣血”；交接文档则必须进一步明确：

扣血统一读取当前守卫伤害，不允许在代码里写死一个数字；新增用户字段必须进入默认数据结构，否则旧存档无法兼容。

前一类文档帮助 AI 理解目标，后一类文档防止 AI 在实现目标时顺手改坏别的地方。

我还逐渐养成了一个习惯：把已经否决的方案和踩过的坑也写下来。因为新会话里的 AI 不知道上次为什么否决，很可能又会热情地把旧方案做一遍。

2. 文档要短而有用，不能只追求“看起来很全”

项目中期，交接文档一度膨胀到约 100 KB。结果某次会话只读进了其中一部分，后面的约束根本没有生效。

这件事让我意识到：文档写进去，不等于 AI 真的读到了。

后来我把长文档拆成“索引＋专题文件”：

• 出题和战斗看一份；
• 装备和日常玩法看一份；
• 渲染和布局看一份；
• 云同步、排行榜和发音看一份；
• 测试、字段和历史记录各自独立。

每次开工让AI先从AGENTS.md文档读索引，再按任务读取一两份专题，不再把整本“项目百科”塞进上下文。

Vibe Coding 里很重要的一项能力，其实不是写提示词，而是管理上下文。

3. 测试不是为了数字好看，而是防止同一个 Bug 再犯

项目目前没有复杂 CI，但保留了一条很简单的命令：

nodetests/run-all.js

现在共有 37 个测试文件，其中 31 个核心测试文件约有 1,000 条断言，另外 6 个是早期回归校验脚本。

真正有价值的是这条规则：

每个真机 Bug 修完，都要留下至少一条防回归断言。

因为 AI 很可能在下一次修改时忘掉这个坑，人也一样。只有测试会在代码再次被改坏时直接停下来。

4. AI 批量生成内容，必须配一条校验流水线

这款小程序不只是代码，还有大量词条、例句、翻译、多义词语境题和搭配。

如果只对 AI 说一句“帮我把这些单词补全”，得到的内容看起来可能很像样，但真正使用时会出现各种问题：例句里的词性和释义不一致、选项重复、句子不含目标单词、常用词被解释成生僻义。

所以我把内容生产拆成了一条流水线：

拆分批次 → AI 按 STYLE.md 生成 → 脚本检查格式与完整性 → 不合格项返修 → 人工抽查 → 回填词库

规范里的要求尽量写成可以机器检查的规则，例如：

• 例句必须包含目标单词；
• 例句长度必须在限定范围内；
• 多义词必须恰好有四个不同选项；
• 释义不能残留英文或无关领域标签；
• 凑不出合格内容时宁可留空，也不要硬编。

AI 适合批量生产，但批量生产之后，更要批量验收。

5. 大改之前先对齐方案，提交之前一定自己看一遍

AI 最大的浪费，不一定是写错，而是没有问清楚就直接写出一大屏代码。

所以涉及数据结构、玩法数值或云端逻辑时，我会先让它给出：

1. 准备分几步做；
2. 会修改哪些文件；
3. 可能影响哪些现有功能；
4. 哪些地方需要我确认。

完成后，再由 AI 整理提交信息，我自己检查变更并提交。

这个习惯让我始终保留一次“停下来看看”的机会，也让 104 次提交基本都能对应到一个清晰的问题。

五、几个真实翻车现场：AI 说修好了，还不算修好

这部分可能是整篇文章最值得参考的地方。

1. 下楼以后，单词和选项对不上

有一版在真机上出现了很奇怪的问题：回到下一层后，单词卡显示的是 A，正确答案却属于 B。

第一次排查时，数据层看起来已经修好了，但真机问题仍然复发。继续往下查，才发现这里其实有两层原因：

• 楼层记录保存的是页面中正在使用的对象引用，恢复时可能出现数据错位；
• 单词卡使用的某些渲染属性，在部分安卓设备上会让卡片缓存成旧快照。

最后的修法包括：保存和恢复时都使用拷贝、恢复前校验词与答案是否匹配、去掉容易触发缓存的样式，并在换题时强制重建卡片节点。

这件事给我的教训是：数据正确，不代表屏幕显示正确；模拟器正确，也不代表真机正确。

2. 药水怎么喝都喝不完

上线前复核时，我还发现过一个更隐蔽的问题：玩家使用药水后，本地背包确实扣了一瓶，但下一次云端对账又把旧数量发了回来。

从单个页面看，“点击使用”完全正常；把客户端和服务端连起来看，才发现它等于可以无限喝药。

最后的解决方法是：使用药水也必须经过服务端校验和扣减，不能只修改本地状态，同时补上对应测试。

所以验收一个功能时，不能只问“这个按钮有没有效果”，还要问：

本地、云端、重新登录以后，结果是不是仍然一致？

3. 测试全绿，游戏却可能不好玩

上线前我重新跑了一遍经济与难度审计，发现当时的数值虽然能运行，却存在明显问题：

• 玩家爬到 400 层，按原规则大约只能获得 640 钻石；
• 护甲和武器全部买满却需要 2,570 钻石；
• 中后期不是单词太难，而是装备买不起；
• 高护甲成型以后，又可能因为伤害封顶而变得过于轻松。

后来补充了大层通关奖励、调整后期武器价格和守卫反击曲线，并用模拟脚本重新验证。

这让我再次确认：单元测试能保证公式按预期执行，却不能保证公式本身合理。游戏平衡、使用手感和学习节奏，仍然需要单独验收。

4. AI 生成的词义，也不能照单全收

词库复核时发现过一些很典型的问题：例句里的can明明是“能够”，释义却保留成了“装罐”；一些高频词带着很冷僻的词性；还有些词一下列出五六种意思，根本不适合做四选一题目。

最后只能通过自动审计、规则修正和人工抽查一起清理。

AI 很擅长生成“看起来合理”的内容，但学习内容不能只追求看起来合理。在背单词产品里，数据质量本身就是产品质量。

六、做完以后，我对 Vibe Coding 的 5 点建议

如果你也想用类似方式做一个自己的项目，我建议从下面几件小事开始：

1. 先写半页需求，再写代码。明确给谁用、第一版做什么，以及明确不做什么。
2. 每个功能都写验收标准。“优化一下”很难验收，“连续下楼 10 次，单词和答案都不能错位”才可以。
3. 尽早留一条能跑通的测试命令。不等项目变大以后再补，否则补测试本身就会变成大工程。
4. 让 AI 批量产内容前，先制定可检查的规则。少用“写好一点”，多写可被程序判断的条件。
5. 把最终判断权留给自己。方案要自己选，真机要自己试，提交要自己看。

两周下来，我最大的收获并不是“以后不需要写代码了”，而是更清楚地知道怎样和 AI 分工：

把重复实现交给 AI，把模糊的问题拆清楚，把重要的判断留下来。

Vibe Coding 降低的是从想法到原型的成本，但从原型到一个真正可用的产品，仍然要靠一轮轮反馈、验证和修正。

七、欢迎来爬几层

如果你：

• 想背单词，却总是停在单词书的前几页；
• 想利用等电梯、坐地铁之类的碎片时间；
• 喜欢像素风、爬塔和一点点装备成长；

欢迎微信搜索「单词塔背单词」体验。

不需要额外注册，打开就能开始。当前版本没有充值入口，钻石主要通过爬塔、通关和签到获得。

你可以先定一个小目标：今天先过第 10 层的 Boss。

玩的过程中如果遇到 Bug，或者觉得某个单词、某一层的设计不合理，也欢迎通过小程序内联系作者或者评论区留言告诉我。后续我还会继续整理这次开发中的文档方法、测试实践和词库处理经验，与大家交流。

用知识改变命运，用知识成就未来！一起加油！