做《星尘守护》这款小游戏时我第一次特别清楚地感受到AI 最大的价值不是帮我把代码写得更多而是帮我更快走到一个残酷的问题面前:这段代码虽然能跑但它真的让游戏变好玩了吗最后的结果是AI 帮我写出了将近 5000 行代码我自己又删掉了大概 2000 行。删掉的不是拼写错误也不是那种一眼就该扔掉的垃圾代码。很多代码逻辑完整、结构也不算乱放在工程角度甚至可以说“写得还行”。但问题在于它们没让《星尘守护》更紧凑没让体验更顺没让玩家更想再来一局。而小游戏最怕的恰恰就是“看起来做了很多玩起来却没有更爽”。这篇文章不想再聊空泛的“AI 提效”或者“小游戏很有前景”。我想更具体地讲讲《星尘守护》这个项目里到底删掉了什么最后又保留了什么以及一款基于 Cocos Creator 开发的小游戏真正该把力气花在哪。先说结果《星尘守护》最后保留的是一条很短的核心循环如果把《星尘守护》压缩成一句话它的核心循环其实非常短移动 - 自动射击 - 击败敌人 - 掉落星尘 - 升级三选一 - 继续活下去这就是它最值钱的部分。玩家进入游戏后不需要读长教程也不需要理解复杂系统。角色会自动锁定最近敌人并发射能量弹玩家只要专注走位、规避包围、规划拾取路线然后在升级时做一次清晰选择。这套循环越短越适合小游戏。因为小游戏不是靠“功能百科全书”留住人的而是靠连续不断的小反馈把人往前推。《星尘守护》现在保留下来的三种升级也很克制疾速星火把发射间隔往下压最低可以从0.42秒压到0.14秒分裂光弹把投射物数量一路加到最多5发星尘磁场把拾取半径从90提升到最高260你会发现这三种升级都不是“看起来很多”而是“拿到以后立刻有感觉”。这就是小游戏该有的设计。不是做一个很大的系统树而是让玩家每 20 秒、30 秒就感受到一次明确的变化。删掉的 2000 行代码本质上是在删“自我感动”我后来复盘AI 特别擅长一件事把一个想法迅速补全。你说要一个功能它会给你一套完整结构。你说要一个面板它会把状态、逻辑、流程都铺出来。你说要一个系统它很容易顺手把周边也补齐。这很高效但也很危险。因为小游戏开发里很多“完整”其实是多余。《星尘守护》这个项目里被我删掉的那部分内容大多有几个共同点第一看起来很全面实际上会拖慢决策。小游戏玩家不是来做复杂学习的。进入战斗的前 10 秒如果还在理解规则、分辨按钮、消化信息很多人就已经走了。所以凡是会让前期理解成本上升的内容哪怕逻辑没问题我最后都倾向于砍掉。第二工程上成立体验上却没有增益。有些功能加上去代码是“完成了”但打起来并没有更爽甚至还会分散注意力。这种内容最容易骗过开发者因为它在代码层面很像成果但在体验层面不一定成立。第三它没有进入核心循环。如果一个功能既不影响移动、也不影响输出、也不影响成长、也不影响“再来一局”的冲动那它在这个阶段就很可能不是必须的。后来我越来越认同一句话小游戏前期最重要的能力不是会加东西而是会删东西。为什么《星尘守护》最后要保留这么“少”的东西因为它的目标不是做成一个大而全的游戏而是先把“停不下来”的结构打透。现在《星尘守护》的数据和节奏其实很具体不是那种泛泛而谈的“有成长、有战斗”。比如玩家基础属性一开始就是一套明确的生存模型生命值5移动速度280发射间隔0.42子弹速度760初始拾取半径90再比如敌人的节奏不是随便刷的而是按阶段逐步抬压0 秒开始只刷星晶幼体25 秒后加入幽光星蛾55 秒后加入凝视之眼90 秒后开始混入陨星蠕虫、晶核重卫、星环哨兵140 秒后触发星渊守望者Boss 波次连刷怪间隔也是持续往下压的从1.15秒一路收紧到最低0.28秒。这意味着什么意味着《星尘守护》真正推动玩家上头的不是某个炫技系统而是战场压力一直在变。前 30 秒你在熟悉节奏。30 到 75 秒你开始被逼着处理更多方向的威胁。75 秒以后重型敌人和更复杂的组合会把你从“我活着”推到“我必须优化路线”。140 秒以后Boss 波次出现整局的目标感一下就明确了。这套节奏一旦成立玩家自然会有“再来一把”的冲动因为他每次失败都会觉得自己不是输在无聊而是输在差一点。这才是我现在理解的“爆款小游戏底层结构”很多人喜欢问小游戏为什么容易让人停不下来。以前我会回答一些比较抽象的话比如反馈快、门槛低、成长强。现在我更愿意说具体一点。真正让人停不下来的通常不是“内容多”而是下面这四件事同时成立上手足够快玩家 3 秒就知道自己要做什么。反馈足够密移动、命中、掉落、升级这些反馈不能断。成长足够近不是 10 分钟以后才变强而是几十秒内就能感受到变化。失败足够可惜不是“算了不玩了”而是“我刚才差一点就过了”。《星尘守护》最后保留下来的内容基本都是围绕这四点服务的。所以你会看到它的升级项很少但每个都很有效。关卡数量不算夸张但每个关卡时长和主题都不一样。敌人种类只有 7 个但功能分工很清晰。整体 UI 和流程也都在尽量减少废信息。这不是做不出来更复杂的而是我开始知道什么复杂值得什么复杂不值得。为什么这类项目特别适合用 Cocos Creator 来做这一轮做下来我对 Cocos Creator 的感受也比以前更具体了。不是简单一句“适合小游戏”而是它确实适合这种需要高频试错、高频删改的项目。《星尘守护》现在已经不只是一个能跑的原型它有 3 个明确的关卡星门遗迹300 秒森林秘境480 秒极光冰域720 秒最后一个关卡还挂了星渊守望者作为 Boss。同时项目在工程层面也做了不少很实际的东西敌人、子弹、经验球都做了对象池子弹池从50预热到80最大扩到150经验球和敌人池也都做了增长与回收策略加了日志系统、性能监控、设置管理器、暂停机制做了微信小游戏相关的竖屏和生命周期适配这些东西听起来不像宣传稿里的亮点但它们才是真正支撑项目能不能往下迭代的部分。小游戏开发很多时候不是死在“做不出来”而是死在“做着做着越来越乱”。而 Cocos Creator TypeScript 这套组合对这种中小体量、需要快速调整玩法节奏的项目确实很顺手。它最大的好处不是帮你一开始就做出满分答案而是让你可以比较稳定地反复改反复试反复砍直到把正确的结构留下来。一个比“AI 提效”更重要的结论如果这次做《星尘守护》只给我留下一个结论那就是AI 可以把开发速度提高很多但它不会自动帮你长出判断力。判断力来自哪里来自你是不是愿意承认某些写出来的代码其实不该留某些看起来丰富的功能其实没有价值某些“我已经做了很多”的满足感跟玩家体验没什么关系这也是为什么我现在反而越来越不想写那种特别虚的内容了。比起说“AI 改变游戏开发”我更想记录这些更真实的过程哪些代码明明能跑最后却必须删哪些 Bug 最耗时间哪些功能是开发者自己以为重要其实玩家根本不在乎哪些数值一改整个手感就完全不一样这些东西不高级甚至有点土但它们很真。而真实恰恰比空洞观点更有价值。最后现在回头看《星尘守护》最重要的进展不是“AI 帮我写了很多”而是“我终于更清楚什么不该留”。删掉 2000 行代码不是后退。删掉 2000 行代码是在把这款游戏从“看起来很多”拉回“真正好玩”。它现在还不是一个完美的答案但至少它已经越来越像我真正想做的那个东西一个规则足够简单、反馈足够密、成长足够近、失败足够可惜的小游戏。一个玩家点进去之后会忍不住想再来一局的小游戏。一个基于 Cocos Creator一点点从冗余里收敛出来的《星尘守护》。