一个不会游戏开发的人，用 AI 把一款小游戏做到上线了

上个月，我做的第一款微信小游戏《英语单词收纳盒》正式上线了。

玩法一句话就能说清：把英语单词卡放进正确的分类盒子里。看到 APPLE，放进 FOOD；看到 RAIN，放进 WEATHER。第一版做了 150 个主线关卡，800 多个单词，外加每日复习、进度记录这些基础功能。

游戏本身不大，但这个过程让我验证了一件一直好奇的事：一个没有游戏开发经验的人，在 AI 深度参与的情况下，能不能独立把一款游戏从想法做到真正上线？

答案是能。不过真正做完之后，我发现了一件更重要、也更扎心的事——

AI 确实大幅降低了「把东西做出来」的难度，但它一点都没有让「做一个好产品」变简单。甚至某种程度上，后者变得更难了。

这篇就聊聊整个过程里，我踩过的坑和想明白的几件事。

为什么是「单词 + 分类」

起因很简单：我想找一种轻量的玩法，让背单词别总是「看英文 → 看中文 → 背下来 → 做题」这一套路。尤其对小孩来说，这套流程玩两次就变回学习软件了。

后来想到「分类」这个动作。看到 Apple，不只是知道它叫苹果，还得判断它属于食物；看到 Pencil，得反应出它和学习场景有关。这样一来，单词不再是孤立的「英译中」，而是和具体的语义场景挂上了钩。

「单词卡 + 分类盒子」的玩法就这么定了，名字也顺手取成了《英语单词收纳盒》。

Railway - 现代化的部署平台，告别繁琐运维，让代码分钟级上线

立即开始 →推广

第一版我刻意把野心压得很低：不做养成，不做装备，不做剧情，只验证一件事——用分类来学和复习单词，这条路走不走得通。 150 个关卡串起「第一次认识 → 游戏里判断 → 重复出现 → 后续复习」这条完整链路，就够了。

现在回头看，这个「先把核心假设做成能玩的东西」的决定是对的。很多问题只有真正玩起来才会暴露，坐在那儿想是想不出来的。

这次 AI 不只是「帮我写代码」

如果只是说「这游戏用了 AI 开发」，现在真不算什么了。我这次想试的是另一件事：不把 AI 当代码生成器，而是让它参与产品从想法到上线的整个生命周期。

实际做下来，AI 在这个项目里至少演了五个角色。

产品经理。 最早的问题都不是代码问题：第一版做到什么程度算够？每日复习第几关解锁？新词和复习词怎么搭配？一个关卡放几个分类才不至于变成练习题？这些都得先把产品逻辑聊清楚，才轮到开发。

游戏策划。 150 个关卡纯手工配置，工作量大不说，整体难度很容易失控。我把词库、分类、引入顺序、复习比例都结构化之后，让 AI 按规则检查：这个单词该归哪类、哪几个分类适合同屏出现、前后关卡难度有没有跳变、有没有不适合儿童词汇的内容。原本纯靠人肉整理的活，变成了「规则 + 数据 + AI 审核」。

UI/UX 设计助手。 首页怎么摆主线和复习入口、通关后展示什么数据、怎样让孩子觉得「我真的完成了一件事」而不是干巴巴弹一句「闯关成功」——这些界面都来回改了很多轮。让 AI 出方案、生成原型，再拿回游戏里实际验证。

程序员。 游戏用 Cocos Creator 开发，从游戏逻辑、存档、界面状态，到微信小游戏适配和各种构建脚本，大量实现工作是 AI 写的。我的角色变成了：提需求 → 看结果 → 试玩 → 找问题 → 调整约束 → 再来一版。最大的变化是，我不用先花几个月学引擎再写 Demo 了，可以先从「我想做什么」出发，在真实项目里倒推着理解技术。

测试。 这是最容易被忽略、但我个人觉得价值最大的一环。开发到后期，我花在测试上的时间越来越多：单元测试、数据合法性校验、关卡配置检查、浏览器自动化、发布前验证……很多检查最后都做成了一键脚本。换句话说，AI 不光要「帮我写功能」，还得「帮我证明这个功能没把其他地方弄坏」。这两件事的价值完全不在一个量级。

最难的从来不是写代码

做到这个阶段，一个很微妙的感受浮现出来了。

以前不会开发的时候，总觉得「只要我会写代码，这东西就能做出来」。现在 AI 把「怎么做出来」这件事解决了大半，你会突然看见后面那座更大的山：这东西到底好不好玩？

最典型的就是关卡难度。从规则上看，第一版的一切都很合理：有关卡、有步数限制、单词越来越多、分类越来越杂。但我自己连续玩了十几二十关之后发现——太简单了。有些关卡打完还能剩一大堆步数。

Vultr - 高性能 NVMe 云服务器，32 个全球节点可选，支持一键部署 Docker

查看定价 →推广

从程序角度看，这套系统完美无缺：没有 Bug，胜负判断正确，数据合法。但从游戏角度看，它没有制造任何压力和决策点。

那一刻我特别有体感：程序正确性和游戏体验，是两套完全不同的评价体系。 AI 能告诉我某段逻辑对不对，能按规则批量生成 150 个关卡，但「玩到第 20 关会不会已经无聊了」这种问题，只能靠真人一遍一遍试出来。

类似的还有用户定位。我一开始写的是「6 岁+」，朋友试玩后提醒了我一句：对低龄孩子来说，界面主要靠文字，意味着他得先认识字才能开始玩。字再小一点，门槛就更明显。这问题简单到可笑，但开发时一直盯着功能，就是会看不见。于是又开始纠结：要不要给单词配图？字体要不要再放大？加了图之后孩子会不会只看图不看英文？——这些已经不是程序员的问题了，没有标准答案，只能一遍遍权衡。

学习游戏，该更像「学习」还是更像「游戏」

这是我现在觉得最值得琢磨的问题。

一个教育小游戏如果只是给练习题套层动画，那它本质上还是练习题。玩家把卡片放进正确的盒子，「啪」一下消失，下一张接着来——功能是完成了，但游戏感约等于零。

成熟的游戏会用无数细小的反馈不断告诉玩家「你刚刚干了件很爽的事」：卡片被吸进盒子的动效、粒子散开、星星飞进进度条、连续正确时音高一点点爬升、Combo、通关时的小高潮……单看每个都是小细节，组合起来，决定了玩家是在「完成一道题」还是在「玩一个游戏」。

所以我现在越来越认同一个思路：与其想办法让学习显得有趣，不如先把游戏本身做有趣，让学习在游戏过程里自然发生。 这两句话看着像，做起来完全是两条路。

从「能跑」到「上线」，中间隔着一条河

另一个以前被低估的环节是上线本身。游戏在电脑上跑起来，顶多算完成了一半。真正发到微信小游戏平台，还有一长串事：Cocos 正式构建、平台适配、包体检查、真机测试、不同屏幕尺寸适配、名称、Logo、封面、分享图、审核素材、提审、处理审核驳回、正式发布……

第一次完整走完一遍，最大的感受是：做出一个 Demo 和做出一个能交给真实用户的产品，中间的距离远比想象中长。 一个人开发时，注意力很容易全扑在功能上，但设计、内容、测试、审核、数据、运营，全都是产品的一部分。

直到有一天它过了审核、真的能在微信里被任何人点开，那种感觉和在自己电脑里试玩完全不同。任何人都可以进来玩，觉得好玩，或者一分钟就退出，甚至直接丢下一句「不好玩」。给自己看的项目可以不断给问题找理由，上线之后，所有问题最终都会收敛成一个：用户愿不愿意继续玩？ 这事没法靠解释解决。

上线不是结束，是一堆新问题的开始

说实话，上线并没有给我「终于做完了」的解脱感，反而冒出了更多问题：玩家进来之后会不会真的开始第一关？玩到第几关开始流失？哪些词最容易分错？每日复习有没有人点？加上图片之后低龄孩子会不会更买账？

KiloClaw - 企业级 OpenClaw 托管服务，赋能 AI Agent 自动化编排与智能模型路由

立即开始 →推广

所以下一阶段我不打算猛加功能，而是先把数据和反馈体系搭起来，让真实数据来决定下一步做什么。关卡难度曲线、消除反馈、配图实验、复习机制，都会跟着数据走。

第一版也教会我一件事：产品不是照着 Roadmap 一路写完的，是在真实用户反馈里一点点长出来的。

写在最后

做完这一版，如果要总结收获，我不会说「AI 写代码真快」——这一点已经越来越不重要了。

我觉得真正重要的是：AI 第一次让一个人能以很低的成本，同时调动过去需要一整个团队才能覆盖的能力——产品、策划、设计、开发、测试、数据分析。这不代表 AI 能替代专业的人，恰恰相反，真做下来你会更清楚地看到专业能力的价值。但过去，个人可能根本走不到需要思考这些问题的阶段，光是把东西开发出来就耗尽了全部力气。现在实现成本降下来了，我们终于可以把更多时间花在「我到底该做什么」上，而不是「这个功能该怎么写」。

至于「什么东西值得做」「什么才算好玩」「用户真正需要什么」——这些问题没有一段 Prompt 能直接给答案。这可能恰恰是做产品最有意思的地方。

《英语单词收纳盒》第一版已经在微信小游戏上线了。如果家里有小学阶段的孩子，可以在微信里搜「英语单词收纳盒」试玩一下。

比起一句「做得不错」，我更想听到的是：哪一关无聊？哪里看不懂？孩子愿不愿意再玩一关？哪些地方让你觉得它更像学习、不像游戏？这些反馈，很可能直接决定它下一版的样子。

后续关卡怎么调、数据怎么看、AI 怎么参与测试，我也会继续记录下来。感兴趣的话，欢迎关注。