00

前言

两周前的一个晚上，我突然想起了 Coco。

那天我正在准备一门针对非技术人员 AI Coding 课程，梳理用 AI 开发产品和工具的流程。准备着准备着，脑子里冒出一个念头：

有了 AI，很多以前没条件做的事情，现在可以试试了。那能不能把 Coco 复活出来呢？

Coco 是我们几年前创业时做的一个小机器人角色，出现在面向低龄孩子的编程学习产品里。当时团队里的人都挺喜欢它。

后来，因为各种原因，产品下线了，Coco 也就跟着消失了。

说实话，还挺怀念的。

于是，当天晚上我就动手了。从开始到做出来，大概花了一天，来来回回改了好几轮。

最后，我给这个小游戏取了个名字，叫《光之旅程》。

里面的主角还是 Coco。模样和以前有一点不同，权且当作它的另一种形态吧。

01

先看看怎么玩

《光之旅程》的玩法很简单。

你需要把系统提供的指令排成一个序列，再让 Coco 按顺序执行，目标是点亮场景里的所有地砖。

规则很简单，没什么难的，对吧？但如果加上一些限制，就得动动脑子了。

比如，指令数量有限，怎样用循环减少重复操作？路线变复杂之后，怎样把它拆成几个小步骤？还有方向，一旦把自己的方向和机器人的方向搞混，Coco 就不知道走哪儿去了。

目前，游戏一共有 100 多关（最近还会对关卡做一次升级），分布在 10 个章节，分别对应顺序执行、条件判断、循环，以及把复杂任务拆小等能力的锻炼。

做完之后，我觉得这个过程还挺值得记一记。

一方面是怀念 Coco，另一方面，我也想拿一个自己做过的东西，聊聊用 AI 开发到底是怎么回事。

02

聊清楚需求

先说一句：这个小游戏不是靠一句话直接生成出来的。

我依然会先梳理需求，再做原型、拆任务、执行和验证。这些步骤，和以前做产品没有差得特别远。只是这里从聊需求、写代码，到添测试的每一步工作，都可以和 AI 协作去完成。

最开始要解决的，还是：我到底想做什么？

很多人会卡在这里，觉得自己说不清楚需求，所以没法开始。

其实，说不清楚很正常。我有时候也只是脑子里有个模糊的感觉，真要落到文字上，才发现好多地方根本没想过。

这时就可以让 AI 帮忙追问。

我通常会先用语音把想法说一遍，再和 AI 互动，去找出描述里不清楚、互相矛盾，或者还需要我做决定的地方。

先聊清楚，再往下做。

也不用指望第一轮就把所有事情想明白。我的原则是：在当下能想到的范围里，尽量说具体。后面看到了实际效果，再继续调整。

聊出来的结果，我会存成一份本地文档。后续做着做着有点跑偏了，也能回来对照。

实践记录

开发工具我使用的是 Codex，搭配的模型是 GPT 6.1 Sol。

语音输入，用的是 Typeless，不过现在能替代的也挺多，像豆包语音输入法、网易叭哥说，还有 Fish Audio 出的 Dropline，都很不错。关键是，用语音输入比实际打字确实会快很多，在和 AI 会话时，这一点太重要了。

聊需求，对于比较简单的应用或工具，直接和 AI 说就是，不过在描述完需求后，我通常会加上下面一句话：

请不着急给我答案，在回答前，先向我提问，由我来回答，一起把需求理清楚。要求：一次只问一个问题，不超过 8 个问题，每回答一个问题，根据我的回答继续来追问，直到你有 100% 的信心完全理解我的真实需求和目标时，再给出最终的方案。

这个提示词虽然简单，但还挺有效的，至于问多少个问题，你可以自行调整，我的感觉是，对于简单的问题，没必要问太多，容易搞得烦躁。

对于比较复杂的产品，个人推荐使用 Matt Pocock 开源出来的 grill-with-docs 和 grill-me 技能。

我们也根据自己的日常需求，写了一个适合我们自己使用的技能，功能介于上面两者之间吧。

聊完后，不要忘了让 AI 帮你将达成的共识整理成一份需求文档（以 markdown 存到项目目录）。

后来做 AI Coding 培训时，也用过其他工具组合，比如 Workbuddy + Deepseek 4.1 Flash，工具和模型都会有一些差异，但对于光之旅程这个应用来说，都能做出来，这套开发的流程，也不用变。

03

看几个原型

有了需求文档之后，我一般不会马上让 AI 动手去实现。

我会先让它做几份简单的原型，把最核心的流程跑通。

原因很简单，有些东西，看文字的时候觉得没问题，真实看到长什么样，再点记下感觉一下，可能就不是那么回事了。

布局行不行，按钮放这里顺不顺手？页面切换是不是太绕？这个操作，孩子能看懂吗？

很多判断，要看到、用到之后才能做出来。

而且你经常会在这个时候发现：

“哦，原来我想要的不是刚才说的那个，我想要的是这样 ……”

这太正常了。原型就是帮我早点发现这些问题的。

它不需要很复杂，一个能打开、能点击的简单页面，就足够讨论很多事情了。

实际执行时，我一般会让 AI 多给几份原型出来，我来选择。

除了整体布局，一些局部设计，也可以让 AI 给几个出来，当你看到后，就靠你的品味去做选择了。

比如，最初我在设计 Coco 形象时，并没有使用 3D 去实现，当时想的是通过角色多侧面的图切换来实现，还支持多角色的切换使用。

这里还有一个我反复用的小经验：如果有参考图，就把参考图给 AI，一张图往往比描述半天的文字更有效。

04

分解任务并实现

原型确定之后，我才会开始拆任务。

特别简单的东西，直接做也行。但对于复杂一点需求，我还是建议把任务拆得小一点。

一块做错了，就改这一块，检查起来也方便。否则让 AI 一口气做一大堆，等最后发现不对，自己都很难说清楚是从哪里开始走偏的。

我一般会让 AI 把任务拆到预计三五分钟就能完成的程度。这个时间只是个参考，合适就行，既能方便后续验证，也不至于在实现一个任务时，模型的上下文就爆掉了。

除此之外，重点是每项任务都要有明确的完成条件，做完之后能判断对不对。

剩下的代码实现，全交给了 AI。

它写完之后会先自己验证，我再去看结果。有问题，AI 继续改。

除了检查核心逻辑，还可以直接让 AI 打开页面，去操作、截图，检查布局有没有错位，检查电脑和手机上的显示是否正常。

从目前 AI 的能力来看，大部分功能逻辑，通过上面两步，基本上都能搞定。

05

根据真实反馈再优化迭代

当然，功能过了，也不等于游戏就好玩了。

有些问题，你得亲自用一遍，才会意识到少了什么。

有一次，我在试玩一个教孩子用循环简化指令的章节，玩着玩着发现不太对。

这一章居然把「跳跃」全漏掉了。

AI 太关注循环本身了，设计出来的关卡都围着循环转，之前用过的跳跃动作就没再出现。

我希望孩子学了新指令之后，还能结合前面的内容继续练习。这一条，当时没有说清楚。

于是，我又把要求补了进去，让它重新调整关卡。

这件事给我提了个醒。有些验收标准，你很难一开始就想到，最后的判断、选择还是要人过一遍再确定。

06

关于文案

应用出来后，我也让朋友玩了玩，大家觉得里面的文案，包括 Logo，感觉还不错。

实际上，除了玩法，我在一开始就挺在意这个应用里的文字表达。

毕竟它设计之初就是给孩子玩的，玩的过程中顺便能锻炼到一些逻辑和编程思维。我希望孩子在看到 Coco 的时候，除了亲切，愿意试一试外，也能接受到一些比较积极的信息。

光，我觉得是一个不错的点，于是和 AI 讨论了一下，很快就确定了游戏表达的主题：让每一步都有光。

Coco 要做的事情，就是走过一块块地砖，把它们点亮。围绕这个动作，闯关的过程，就变成：一起去找下一束光。

这些想法，也直接影响了各章节的名称和介绍。

最终的文字大多是 AI 给出的，但并不是第一轮就写成了现在这样，我和它讨论修改很多次。

目前的结果，还是挺满意的。

07

结语

一句话出来一个应用，网上出现的这类宣传用语，太有迷惑和误导性，小心些，要开发出一个比较可靠和满意的产品，并不容易，大多情况都不可能是一两句话就能完成的。

在 AI 出现之前，好多想法都停在了「以后有空再做」。

每次想动手，就得考虑要花多少时间、投入多少精力，估算了一下后，事情可能就搁下了。

像《光之旅程》这样的一个应用，不算复杂，即便如此，放在以前，想要用一两天，把它做到现在这个程度，至少对我来说是不可能的。

有了 AI 之后，要实现一个想法，比以前容易太多了，可新的问题又出现了，毕竟人的时间和精力并没有跟着变多，不要掉进另一个坑，这个能做，那个也能做，最后把自己弄得更忙了。

你得自己想清楚：到底要做什么，要有所判断和取舍。

文章快写完了，还是会有些感叹，没想到，几年之后的一个晚上，我又有机会让 Coco 动了起来。

让每一步，都有光！

这是 Coco 送给大家的祝福。

[全文完]

末尾插个小广告，我正在开设一门 AI Coding 的付费课程，光之旅程是其中一个例子，感兴趣参加的朋友，下方微信联系我。