文章目录
- 一、先看成品：背单词，也可以像打怪升级
- Boss 战不是随机抽题，而是阶段测验
- 爬累了，也可以回塔里复习
- 每天一次，用同一套装备重新挑战
- 二、我理解的 Vibe Coding，不是“许愿式编程”
- 三、两周开发，到底做了什么
- 四、让 AI 真正帮上忙的 5 个做法
- 1. 不只告诉 AI“要什么”，还要告诉它“什么不能动”
- 2. 文档要短而有用，不能只追求“看起来很全”
- 3. 测试不是为了数字好看，而是防止同一个 Bug 再犯
- 4. AI 批量生成内容，必须配一条校验流水线
- 5. 大改之前先对齐方案，提交之前一定自己看一遍
- 五、几个真实翻车现场：AI 说修好了，还不算修好
- 1. 下楼以后，单词和选项对不上
- 2. 药水怎么喝都喝不完
- 3. 测试全绿，游戏却可能不好玩
- 4. AI 生成的词义，也不能照单全收
- 六、做完以后，我对 Vibe Coding 的 5 点建议
- 七、欢迎来爬几层
写在前面：大家好，我是晴空๓。之前我在博客和公众号里聊过 Token、大模型是如何“思考”的，这次想分享一次更完整的 AI 实践：我怎样用 Vibe Coding，从空文件夹做出一款可以上线的微信小程序。
这不是一个“输入一句话，AI 自动生成整个项目”的故事。相反，这两周让我更加确定：AI 可以显著加快开发，但产品判断、真机验收和质量底线，仍然需要人来负责。
10 月 14 日，我建了一个空文件夹。
10 月 28 日，这个文件夹里多了一款名为「单词塔背单词」的微信小程序：
- 400 层可供挑战（博主正在精修400+以上楼层，欢迎大家来爬塔背单词）；
- 6,044 个去重单词；
- 104 次Git 提交；
- 4 个页面、5 个云函数；
- 37 个测试文件全部通过。
它把背单词和爬塔游戏放在了一起：答对单词就发起攻击，击败守卫继续上楼；答错会被反击扣血，血量归零就会坠落。
这篇文章既是这个项目的开发复盘，也是一份 Vibe Coding 的真实使用记录。当然，如果你只是对小程序感兴趣，也可以直接微信搜索单词塔背单词来爬几层。
一、先看成品：背单词，也可以像打怪升级
「单词塔背单词」的核心规则并不复杂：
- 每层有一个守卫，给出一个英文单词；
- 玩家从四个中文释义中选择答案；
- 答对就攻击守卫，击败后向上爬；
- 答错或超时会被扣血；
- 每 10 层出现一个 Boss，检验这一阶段的单词。
我很早之前就有做一个背单词的小游戏，之前再某款背单词APP上面见到过滑动选字母拼成单词的小游戏，如果拼对了就打一下对面的小怪，打错了就被对面锤。可惜后来这个小游戏不知道为什么下架了，我后来还去问了客服，客服说让我回退旧版本试试看……。把背单词做成小游戏我觉得很有意思：先让它有游戏该有的反馈、目标和成长感，让学习在游玩过程中自然发生。极大的减少了背单词的“痛苦”。
答对时有挥剑、受击、连击和得分反馈；答错时会扣血，也能马上看到释义和例句；继续向上还有新的词池、装备、勋章和排行榜。
以前打开单词书，目标是“今天背完这一页”；现在打开小程序，目标变成了“我再答对几题，就能过这一层”。
Boss 战不是随机抽题，而是阶段测验
普通层主要负责接触和学习单词，Boss 层则负责复习。
Boss 的题池来自本大层前 9 层出现过的单词，并优先把多义词和例句变成语境题：不再只是问“这个单词是什么意思”，而是给出一句话，问“它在这里是什么意思”。
这样一来，Boss 战就不只是血量更厚、答题更多，而是真正成了一次阶段验收。
爬累了，也可以回塔里复习
已经通关的楼层可以重新进入。系统会保留本次爬塔中的楼层记录，玩家可以回到下一层复习原题，也可以进入“塔内研习”，查看更详细的释义、例句、常用短语和搭配，并播放单词发音。
这个入口只放在已通关楼层。原因其实很简单：当前题还没有答对，就不应该提前进去看答案。
很多类似的细节，都不是第一版就想到的，而是在真机试玩时发现“这里说不通”，再一点点改出来的。
每天一次，用同一套装备重新挑战
游戏里还有一个我比较喜欢的模式：每日一爬。
每天从第 1 层出发，看看今天能爬多高。为了让成绩更公平，这个模式里所有人统一使用初始装备，不吃自己已有的护甲、武器和药水加成，倒下就结算。
老玩家可以重新挑战自己，新玩家也不用先追别人的装备进度。
除此之外，目前还有：
- 楼层榜与连击榜；
- 每日签到；
- 武器、护甲和自由换装；
- 勋章墙与已学单词明细；
- 错题重考与漏词补漏。
二、我理解的 Vibe Coding，不是“许愿式编程”
这次开发之前，我对 Vibe Coding 的期待也很简单：把想法告诉 AI，让 AI 写代码，自己少敲一点键盘。
真正做完以后，我发现更有效的合作方式应该是：
| 角色 | 主要负责什么 |
|---|---|
| 我 | 决定做什么、明确验收标准、选择方案、真机试玩、最终提交 |
| AI | 写代码、补数据、写测试、整理文档、排查问题、提供备选方案 |
| 测试与真机 | 检查“看起来完成了”的功能，是不是真的能用 |
换句话说：
AI 负责提高实现速度，人负责判断方向，测试负责守住底线。
如果只说“帮我做一个背单词的小程序”，AI 确实可以很快生成一堆页面。但“能运行”与“好玩”“词义正确”“老存档还能用”“换台手机不出错”，中间还有很长的距离。
Vibe Coding 并没有省掉这些工作，只是让我能把更多时间放在它们上面。
三、两周开发，到底做了什么
整个项目大致经历了下面几个阶段：
| 阶段 | 主要产出 |
|---|---|
| 第 1～2 天 | 需求文档、核心爬塔循环、基础界面、Boss 战 |
| 第 3～5 天 | 词库管线、装备成长、商城、勋章、倒计时 |
| 第 6～8 天 | 微信云开发、登录与存档合并、真实排行榜、服务端发奖 |
| 第 9～11 天 | 单词发音、每日签到、每日一爬、漏词补漏、真机问题修复 |
| 最后 3 天 | 文档整理、词质复核、经济与难度校验、上线合规收尾 |
技术栈没有刻意追求复杂：
- 客户端：原生微信小程序，无框架、无构建工具；
- 云端：微信云开发，使用云函数、云数据库和云存储；
- 词库：开源英汉词典数据、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 最大的浪费，不一定是写错，而是没有问清楚就直接写出一大屏代码。
所以涉及数据结构、玩法数值或云端逻辑时，我会先让它给出：
- 准备分几步做；
- 会修改哪些文件；
- 可能影响哪些现有功能；
- 哪些地方需要我确认。
完成后，再由 AI 整理提交信息，我自己检查变更并提交。
这个习惯让我始终保留一次“停下来看看”的机会，也让 104 次提交基本都能对应到一个清晰的问题。
五、几个真实翻车现场：AI 说修好了，还不算修好
这部分可能是整篇文章最值得参考的地方。
1. 下楼以后，单词和选项对不上
有一版在真机上出现了很奇怪的问题：回到下一层后，单词卡显示的是 A，正确答案却属于 B。
第一次排查时，数据层看起来已经修好了，但真机问题仍然复发。继续往下查，才发现这里其实有两层原因：
- 楼层记录保存的是页面中正在使用的对象引用，恢复时可能出现数据错位；
- 单词卡使用的某些渲染属性，在部分安卓设备上会让卡片缓存成旧快照。
最后的修法包括：保存和恢复时都使用拷贝、恢复前校验词与答案是否匹配、去掉容易触发缓存的样式，并在换题时强制重建卡片节点。
这件事给我的教训是：数据正确，不代表屏幕显示正确；模拟器正确，也不代表真机正确。
2. 药水怎么喝都喝不完
上线前复核时，我还发现过一个更隐蔽的问题：玩家使用药水后，本地背包确实扣了一瓶，但下一次云端对账又把旧数量发了回来。
从单个页面看，“点击使用”完全正常；把客户端和服务端连起来看，才发现它等于可以无限喝药。
最后的解决方法是：使用药水也必须经过服务端校验和扣减，不能只修改本地状态，同时补上对应测试。
所以验收一个功能时，不能只问“这个按钮有没有效果”，还要问：
本地、云端、重新登录以后，结果是不是仍然一致？
3. 测试全绿，游戏却可能不好玩
上线前我重新跑了一遍经济与难度审计，发现当时的数值虽然能运行，却存在明显问题：
- 玩家爬到 400 层，按原规则大约只能获得 640 钻石；
- 护甲和武器全部买满却需要 2,570 钻石；
- 中后期不是单词太难，而是装备买不起；
- 高护甲成型以后，又可能因为伤害封顶而变得过于轻松。
后来补充了大层通关奖励、调整后期武器价格和守卫反击曲线，并用模拟脚本重新验证。
这让我再次确认：单元测试能保证公式按预期执行，却不能保证公式本身合理。游戏平衡、使用手感和学习节奏，仍然需要单独验收。
4. AI 生成的词义，也不能照单全收
词库复核时发现过一些很典型的问题：例句里的can明明是“能够”，释义却保留成了“装罐”；一些高频词带着很冷僻的词性；还有些词一下列出五六种意思，根本不适合做四选一题目。
最后只能通过自动审计、规则修正和人工抽查一起清理。
AI 很擅长生成“看起来合理”的内容，但学习内容不能只追求看起来合理。在背单词产品里，数据质量本身就是产品质量。
六、做完以后，我对 Vibe Coding 的 5 点建议
如果你也想用类似方式做一个自己的项目，我建议从下面几件小事开始：
- 先写半页需求，再写代码。明确给谁用、第一版做什么，以及明确不做什么。
- 每个功能都写验收标准。“优化一下”很难验收，“连续下楼 10 次，单词和答案都不能错位”才可以。
- 尽早留一条能跑通的测试命令。不等项目变大以后再补，否则补测试本身就会变成大工程。
- 让 AI 批量产内容前，先制定可检查的规则。少用“写好一点”，多写可被程序判断的条件。
- 把最终判断权留给自己。方案要自己选，真机要自己试，提交要自己看。
两周下来，我最大的收获并不是“以后不需要写代码了”，而是更清楚地知道怎样和 AI 分工：
把重复实现交给 AI，把模糊的问题拆清楚，把重要的判断留下来。
Vibe Coding 降低的是从想法到原型的成本，但从原型到一个真正可用的产品，仍然要靠一轮轮反馈、验证和修正。
七、欢迎来爬几层
如果你：
- 想背单词，却总是停在单词书的前几页；
- 想利用等电梯、坐地铁之类的碎片时间；
- 喜欢像素风、爬塔和一点点装备成长；
欢迎微信搜索「单词塔背单词」体验。
不需要额外注册，打开就能开始。当前版本没有充值入口，钻石主要通过爬塔、通关和签到获得。
你可以先定一个小目标：今天先过第 10 层的 Boss。
玩的过程中如果遇到 Bug，或者觉得某个单词、某一层的设计不合理，也欢迎通过小程序内联系作者或者评论区留言告诉我。后续我还会继续整理这次开发中的文档方法、测试实践和词库处理经验，与大家交流。
用知识改变命运，用知识成就未来！一起加油！
