地铁上的碎片时间也能“做游戏”

本文系用户投稿，不代表机核网观点
本文含有AI生成，请注意甄别
碎片时间大家都不陌生。以前坐地铁、排队、等人，很多人会顺手看两页书、刷一集剧，或者在信息流里放空一会儿。那些时间原本轻松、零散，也很容易被悄悄消耗掉。
但现在有了 AI 之后，很多事没那么难开始了。脑子里冒出一个想法，随手说一段语音，或者截张图发过去，都能让它先帮你往前推一小步。所以这些原本只是用来打发时间的空档，也可以拿来做点自己真正喜欢的事。
对我来说，这件事就是做一款自己喜欢的游戏。不是等到有完整的大块时间、完美的开发环境、成熟的团队配置才开始，而是在地铁上的几站路里，把脑子里那些关于玩法、关卡、角色和机制的想法，先一点点变成可以被 AI 理解、被代码验证、被手机预览的东西。
我们光有想法还不够，真要把“地铁上做游戏”这件事跑起来，至少得先解决三个问题：
怎么在手机上跟 AI 说清楚？不是随便聊两句，而是能把需求、截图、反馈高效地传给它。
怎么低成本搭一个能跑起来的环境？
AI 要能改代码、跑项目、处理依赖，背后得有一台稳定工作的机器。
怎么快速看到游戏效果，再马上调整？
游戏开发最怕“改完不知道长什么样”，预览反馈必须足够快。
前期基建-把手机变成 AI 指挥台
第一件事，是先解决“人在手机上，AI 在电脑里”怎么沟通的问题。
我最后选的是飞书。虽然班味很足，但它确实适合做这件事：语音、图片、视频、富文本这些交互都很成熟，手机端体验也稳定。更关键的是，飞书开放接口对大段内容比较友好，代码、截图、Markdown 回复这些东西有很好的支持。
简单说，它不是最酷的选择，但很实用。百万 🐮🐴 衣食所系，说明它在“稳定传消息”这件事上还是靠谱的。接下来要做的，就是把飞书和 AI-Coding 工具接起来，让手机里的每一句话、每一张图，都能变成电脑上的开发指令。

配置飞书
注册一个企业飞书应用
先打开 飞书开放平台，创建一个企业自建应用。这是后面接收消息、发送回复的入口。

添加机器人，并让它能收到消息
真正要用它指挥 AI-Coding，这一步要拆成三块配置：机器人能力、消息权限、事件订阅。
开启机器人能力
让应用以机器人的身份出现在飞书会话里。后面所有“手机发指令、电脑收消息、AI 回结果”的流程，都是从这个机器人入口开始的。

开通消息读取权限
进入「权限管理」，搜索“消息”，把接收单聊、群聊消息需要的权限开通。权限没开齐，后面事件订阅配好了也可能收不到内容。

配置事件订阅
进入「事件与回调」，添加机器人相关事件。这里可以选长连接，长连接会省掉不少公网回调地址的麻烦。先把订阅方式改成“使用长连接接收事件”，再继续添加需要监听的事件。

创建飞书卡片
AI 的回复不能只是一坨纯文本。用卡片承载标题、正文、状态和操作入口，手机上看起来会清楚很多。这一步也可以拆成三块：创建卡片、配置变量、发布并关联应用。
创建空白卡片
先打开 飞书卡片搭建工具，选择“创建空白卡片”。这里建议直接用新版卡片，后面支持变量、Markdown 和更灵活的布局，适合承载 AI-Coding 的回复内容。

配置变量，并拿到卡片 ID
卡片内容可以先做得简单一点：一个标题组件，加一个正文富文本组件。重点是把会变的内容抽成变量，比如 title 和 content。这样代码里发送消息时，只需要传入不同的变量值，就能复用同一张卡片模板。
卡片 ID 在编辑器左上角可以看到，通常就在卡片名称下面，形如 ID: AAq2W9...。这个 ID 后面要写进发送卡片消息的代码里，用来告诉飞书“这次要渲染哪一张卡片模板”。

发布卡片，并关联飞书应用
最后记得点右上角“发布”。发布弹窗里选择前面创建的飞书应用，把这张卡片授权给对应应用使用。这样应用发送消息时才有权限渲染这张卡片模板。没有发布，或者没有关联应用，代码里即使拿到了卡片 ID，也可能发不出来。
到这里，第一块基础就算搭好了。飞书负责做手机端入口，承接文本、图片和富文本输入；电脑端负责接收消息，交给 AI-Coding 工具处理；处理完的结果再通过飞书卡片回到会话里。核心是先让“手机发起需求 → 电脑执行任务 → 飞书返回结果”这条链路稳定跑起来。只要这个闭环打通，后面再去选择 AI-Coding 工具、部署运行环境、做游戏预览，才会变成一件可以持续迭代的事情。
组合 AI-Coding
挑选 AI-Coding 工具
飞书这条通信链路跑通之后，下一步就是选真正干活的 AI-Coding 工具。说实话，目前市面上主流的 AI-Coding 工具，基础代码能力基本都能胜任日常开发，真正拉开体验差距的，反而是价格、额度和多模态能力。
我主要看两个点：
价格和额度要可预期：个人项目很容易连续折腾好几天，如果额度一天就打空，体验会非常割裂。工具再强，只要你每次用之前都要先算账，就很难进入持续开发状态。
多模态能力要够用：做游戏和界面时，没有多模态能力会非常繁琐。按钮有没有错位、布局是不是挤在一起、手机上看起来顺不顺眼，都需要你一遍遍截图、描述、再让 AI 猜问题在哪里。AI 如果能直接看图，界面调整会省掉很多来回沟通。目前使用 GPT-5.4/5.5 体验还不错。
所以我这次选择的是 Codex。它不一定是所有场景里最便宜的选择，但对开发任务来说比较顺手：可以兼顾公司项目和个人项目，也能更自然地接上本地运行环境。费用上，我用的是大概每月 100 刀的套餐，至少在持续开发时心里更有数。

如果人在国内，订阅这类海外 AI 工具会稍微麻烦一点。我的做法大概是这样：
先准备好网络环境：不然 ChatGPT 和相关服务基本访问不了。
用 Pockyt Shop 购买美区 App Store 礼品卡：支付宝内地址切换到美国，就能完成购买。
准备一个美区 Apple ID：用来下载 App、兑换礼品卡，并完成订阅付款。
顺手再吐槽一下 GitHub Copilot。之前每个月 39 刀，额度基本还能撑住一整个月的高强度开发。但今年 6 月改了新的配额计费方式之后，十分之离谱：一个月的额度，如果全力开发，最多也就够折腾两天。

飞书 + AI-Coding
这一层我没有直接把手机和某一个 AI-Coding 工具绑死，而是中间加了一个自己开发的 aibo。它负责接入飞书 SDK，接收手机端发来的消息，再把任务转给本地电脑上的 AI-Coding 工具。
整体链路大概是这样：手机上通过飞书发送文字、截图或富文本内容；本地电脑运行 aibo 机器人，负责解析消息、下载图片、整理上下文；再通过 ACP 协议 对接 Codex 这类 AI-Coding 工具。这样手机端只需要保持一个简单的聊天入口，真正复杂的代码执行、文件读写和工具调用，都留在本地电脑完成。
这里还有一个很重要的点：飞书的云存储服务可以承载富文本里的图片。这样截图、界面预览、报错信息都能顺着链路传给多模态模型，不需要我手动把图片保存下来再拖给 AI。

本地电脑跑起来
这里还有一个关键点：电脑端不需要搞得特别复杂。飞书提供了 长连接接收事件 的方式，aibo 只要在本地电脑上启动，就可以持续接收飞书推送过来的消息。
直观理解就是：只要这台电脑联网，并且已经配置好 aibo，你人在哪都不重要。人在地铁、咖啡店，甚至只是拿着手机躺着，都可以通过飞书把指令发回来，让本地电脑上的 AI-Coding 工具继续干活。
这也是我选择这条方案的原因：它不需要都把开发环境搬到手机上，也不需要在公网暴露一堆服务。手机只负责发需求，本地电脑负责真正执行，分工非常清楚。

游戏预览
既然目标是在手机上随时看效果，游戏预览最自然的选择就是网页端。现在手机浏览器的性能已经足够好了，小型 2D 游戏、原型验证、交互调试，基本都可以直接在浏览器里跑起来。
我一开始用的是 GitHub Pages：代码提交到 GitHub，再通过流水线自动构建和发布。这个方案能用，但很快就遇到两个问题：
预览地址不够灵活：不能很方便地基于不同分支、不同 commit 生成多个预览地址，想对比几个版本会比较麻烦。
构建额度不太经用：GitHub Actions 每月 2000 次看起来不少，但如果 AI 高频改代码、频繁触发构建，一周左右就可能消耗得差不多。
后来我换成了 Vercel。它对这种网页小游戏预览非常友好：分支、提交、PR 都可以快速生成独立预览地址，手机点开就能看效果，也方便把不同版本放在一起对比。
最关键的是：免费 免费 免费！！！
当然也有一个小缺点：在国内访问 Vercel 预览地址通常需要翻墙，不然你可能连自己刚部署出来的游戏都打不开。

到这里，前期基建基本就闭环了。回头看一开始提到的三个问题，其实都已经有了对应方案：
手机上怎么跟 AI 高效沟通：用飞书作为入口，文本、截图、富文本都能顺着同一个会话发出去。
怎么低成本跑起 AI-Coding 环境：用本地电脑运行 aibo，通过飞书长连接接收消息，再把任务交给 AI-Coding 工具执行。
怎么快速预览游戏效果：把游戏做成网页端，用 Vercel 生成可访问的预览地址，手机点开就能看，也方便对比不同版本。
这三件事解决之后，手机就不只是一个“看消息”的设备了，而是变成了一个可以随时发需求、看结果、继续调整的轻量开发入口。接下来，才是真正开始做游戏。
游戏开发

有点 B 数
正式开始之前，还是得先有点 B 数：AI 很强，但它不是万能游戏制作人。
它擅长的是把明确的想法快速变成代码，帮你搭结构、补逻辑、修 bug、做一些重复性的工程工作。但游戏里真正难的部分，比如玩法是否有趣、手感是否舒服、关卡节奏是否合理、画面和交互是否统一，很多时候还是需要人自己判断。
所以这件事不能变成“我一句话，AI 做完整个游戏”。更现实的方式是：我们负责提出方向、做选择、看效果、给反馈；AI 负责把这些反馈快速落实到代码里。先搞清楚它的长处和短板，后面踩坑的时候才不会太崩溃。
小试牛刀
俄罗斯方块（但是物理引擎）
最开始的想法其实挺上头：在俄罗斯方块的基础上，加一层物理引擎，让它不再是传统意义上的“格子摆放游戏”。
比如方块落下来之后，不是规规矩矩地卡在网格里，而是会受到重力、碰撞、倾斜和堆叠影响。玩家要处理的不只是“怎么消行”，还要考虑方块会不会滑下来、会不会把结构压塌。再加上一些特殊方块，比如爆炸方块、吸附方块、弹性方块，听起来就很有新鲜感。
但真正开始做的时候，第一步就卡住了。
物理引擎这件事，对 AI-Coding 来说并不是不能写，而是很难一次写对。它涉及碰撞体、重力参数、摩擦力、刚体睡眠、边界约束、消行判定等一堆细节。任何一个参数不合适，游戏体验都会变得很怪：方块可能抖动、穿模、卡住、飞出去，或者明明看起来碰到了，却没有触发预期逻辑。
更麻烦的是，俄罗斯方块本身需要“明确、可控、可预期”的摆放体验，而物理引擎天然会带来“不确定性”。这两件事放在一起，就很容易打架：
太像传统俄罗斯方块，物理引擎就只是装饰，玩法没有真正变化。
物理反馈太强，玩家又会觉得失控，明明是自己摆的方块，结果被碰撞和重力搞乱。
一旦出现奇怪的物理 bug，很难通过文字描述让 AI 精准理解问题，只能反复截图、录屏、调整参数。
最后发现，这个方向不是没有意思，而是第一版成本太高了。它需要大量手感调试和物理参数打磨，不适合作为“用碎片时间 + AI 快速推进”的第一个游戏原型。所以先记在想法本里，暂时放下。
空洞骑士 LIKE
物理引擎这条路太重，那就换个看起来更“经典”的方向：2D 平台跳跃游戏。
这个方向一开始也很诱人。它不需要复杂的物理系统，规则也比较直观：角色移动、跳跃、攻击、敌人巡逻、平台机关、关卡推进。听起来非常适合让 AI 先搭一个原型，再慢慢补内容。
但做下来之后发现，它的问题不在“能不能跑起来”，而在“好不好玩、像不像一个游戏”。
主要卡在三件事上：
关卡设计很难交给 AI。平台跳跃最重要的是节奏：哪里该让玩家助跑，哪里该给落脚点，哪里该放敌人，哪里该留喘息空间。这些不是把平台随机摆一摆就行，大模型能生成结构，但很难理解“这一段为什么好玩”。
动作和贴图素材很容易受限。免费素材确实不少，但要拼出一个统一风格、动作完整、敌人和场景都够用的游戏，选择一下子就变窄了。角色跑、跳、攻击、受击、死亡，只要少一组动作，体验就会很生硬。
素材摆放很依赖审美和视觉判断。地图块有没有对齐，边缘是不是突兀，前景和背景会不会混在一起，角色有没有被地形遮住，这些都需要反复看画面。现在的多模态能力已经能帮忙发现一部分问题，但要让它稳定做出“好看又合理”的关卡，还是要谨慎期待。
最后确实做出了一个能玩的 2D 原型，但效果比较粗糙：关卡没有什么节奏，人物动作偏僵硬，贴图素材也有不少错位和风格混杂。它证明了 AI 可以很快把平台游戏的骨架搭出来，但离“有手感、有内容、有美术一致性”的游戏，还差一大段需要人来打磨的距离。

游戏地址（需外网打开）
以撒结合 LIKE
为什么这个方向更合适
前面两个方向都踩了一轮坑之后，弹幕射击 + 肉鸽这个方向反而显得很合适。
它没有复杂的物理引擎，不要求角色有特别细腻的动作表现，也不强依赖大规模精美贴图。真正撑起玩法的，主要是机制：怪物怎么移动、弹幕怎么发射、道具怎么改变规则。
这些东西有一个非常大的好处：它们很容易被数值化。
这对 AI-Coding 很关键。因为 AI 最怕的是模糊要求，比如“做得更好玩一点”“手感再丝滑一点”。但如果我们把玩法拆成具体机制和参数，它就会好处理很多。你不是让它凭感觉设计游戏，而是在告诉它一组明确的规则，然后让它把规则实现出来。
怪物设计：把行为拆成参数
怪物设计可以拆得很细：血量、移动速度、追踪距离、攻击间隔、攻击方式、受击反馈、死亡掉落。每一项都可以变成一个明确配置。
比如你可以直接告诉 AI：“做一个移动慢、血量高、靠近玩家后发射三向弹幕的怪物。” 这种描述里有行为、有数值、有触发条件，AI 基本能理解并实现。
更重要的是，怪物可以很容易做变体。一个基础怪物做出来之后，改一点速度、攻击频率、弹幕形状，就能变成新的敌人。这样内容扩展的成本会低很多。
道具设计：改变规则就能产生差异
肉鸽游戏里的道具，本质上就是改变玩家或敌人的某些规则。它不一定需要复杂素材，更多时候是一条清晰的机制。
比如：
射速 +20%。
子弹体积变大。
子弹附带穿透。
低血量时伤害提升。
击杀敌人后生成小范围爆炸。
每隔几秒自动发射一圈弹幕。
这些效果都能写成清楚的条件和参数，非常适合让 AI 一条一条实现。更妙的是，道具之间还可以组合。两个简单效果叠在一起，就可能产生新的玩法反馈，这也是肉鸽游戏很容易做出变化感的原因。
弹幕设计：视觉复杂，但规则清楚
弹幕看起来花，但底层其实很适合数值化。
圆形扩散、扇形发射、延迟追踪、螺旋弹幕、随机散射、分裂子弹，这些都可以用角度、速度、数量、频率、生命周期来描述。它不像“手感好不好”那么玄，至少第一版可以很快做出来，然后通过试玩调整参数。
这里 AI 的优势会比较明显。你可以让它快速生成几种弹幕模式，再通过截图和实际预览去判断哪一种更有压迫感，哪一种太密，哪一种适合前期怪物，哪一种适合 Boss。调整方向会比平台跳跃的关卡手感更明确。
关卡设计：先从一个房间开始
关卡设计也可以先简化。
平台跳跃需要精心安排路线和节奏，但这种房间制游戏可以从最小单位开始：一个房间，放几只不同攻击类型的怪物，再配一点障碍物和奖励。难度曲线可以通过怪物组合、弹幕密度、房间数量慢慢叠上去。
也就是说，我们不需要一开始就设计一张复杂大地图。先做一个房间，把战斗循环跑通；再做多个房间，把怪物组合和奖励机制串起来；最后再考虑路线选择、商店、Boss、隐藏房间这些肉鸽结构。
最终判断
所以目前试开发下来，这个方向是最有希望的。它把很多原本抽象的“好不好玩”，拆成了 AI 更容易处理的规则和参数。
人负责判断节奏和爽感，AI 负责快速实现机制、生成变体、调整数值。这个分工一旦顺起来，碎片时间也能一点一点把游戏往前推。

游戏打磨中...
写在最后
这次尝试下来，我最大的感受是：一个人确实可以借助 AI，去做一些以前觉得“一个人很难开始”的事情。
但也要承认，AI 现在还不是万能的。它更擅长处理那些可以被拆解、被描述、被数值化的目标。比如怪物血量是多少、弹幕速度多快、道具触发条件是什么、房间里放几个敌人。你给它的规则越清楚，它就越容易帮你往前推进。
反过来，如果目标太模糊，只是说“帮我做得更好玩一点”“让画面更高级一点”，AI 就很容易开始猜。猜对了当然开心，猜错了就会变成反复沟通、反复返工。
所以最终还是要回到人自己身上。你得知道自己想要什么效果，也要能判断现在做出来的东西离目标还差多少。AI 更像一支很厉害的画笔，可以帮你画得更快、试得更多、改得更勤，但最后画什么、怎么画、画完满不满意，还是由你这个画家决定。
这次分享不是想证明“AI 可以替你做完整个游戏”，而是想提供一个思路：我们可以把 AI 接到自己的日常生活里，让它帮助我们随时随地推进一些小目标。哪怕每天只前进一步，只要这条链路能跑起来，很多原本停在脑子里的想法，就有机会慢慢变成真实可见的东西。
希望这篇记录能给你一点启发。