我试着采用AI辅助编程已经快1年了。这一年来AI编程工具几乎每隔几个月就会“进化”，变得越来越好用。我也体会到了一点点Vibe Coding（氛围编程）的乐趣。

我还很清楚的记得2024年使用Cursor的时候，生成一个浏览器可用的贪食蛇都很费劲，2025年初国产的Trae还不能生成一个好用的2048游戏。直到现在，与其说是“辅助编程”，“托管”可能更符合我现在的使用状态——几个月前我或许还会给出一些框架，定义一些方法，然后AI补全后再修修改改。现在则是告知AI我需要干什么，让他自己去处理就行了，能让AI做的我绝对不会动一行代码，哪怕只是一个参数！（虽然这有点浪费AI点数）

※Cursor和Trae都是AI编程工具。

接下来我将以这几个月来做的小项目来进一步聊聊AI编程。

项目A：宝可梦睡觉大百科

https://www.kmhgame.com/pokemonsleep/index.html
可以进去看看哦！

这是个为期3天的练手项目，用来记录和展示“宝可梦睡觉”中的图鉴。它包含所有宝可梦睡觉中出现的宝可梦、地图、料理、食材、技能的图鉴，能够查询并看到一些重要的详细信息。

对于这类网站，最重要的部分是数据。如果仅靠个人收集的话，从截图到录入将会是一个海量的时间。幸好，我找到了一个非常全面的资料网站https://pks.raenonx.cc/

感谢raenonx的慷慨！

于是，我的目标从收集汇总数据转变为从raenonx抓取数据，也就是创建爬虫。前后花费了将近一天的时间，我利用谷歌的AI编程工具Antigravity把raenonx上的数据事无巨细都下载下来。

※虽说是练手项目，却是我做的最晚的一个，12月的最后几天做的，目的是想试试Antigravity的实用程度。

数据含多语言在内将近30万行，最大的一个数据文件有15万行。如下图（再次对这款游戏的资料收集者表示敬意！）

我虽然能够看出来这15万行包含了游戏的主要数据，但是他们之间的关系就像这个json所示的，都是通过数字编号关联的，显然不是人类的阅读范畴（也不是不能理解，但时间成本是显而易见的）。

既然让Antigravity抓取了数据，他能不能为我分割数据，并将已知的内容建立关联呢？答案是可以的。他甚至为我在supabase上建立了数据库，使这些数据看上去更加易懂。

数据的活干完了，接下来要做网站了。

之前项目我的做法是，先利用figma make让ai生成可交互的原型，觉得差不多之后发布原型，让AI编程工具自己看网页代码并复制样式再最后实现。但这次我的figma make点数用完了，它也不提供购买额外点数的方法。于是，我决定让Antigravity自己来做。

在大概2个小时的参考图投喂和不断的需求确认和修改后，主页的形象就变成了上文各位看到的样子了。虽然称不上惊艳，但我认为ai的审美还是值得称道的。大家可以登录这个网站实际体验一下观感。

https://www.kmhgame.com/pokemonsleep/index.html

接下来就是为每个子页面提出需求和实现原型了，整体耗时6小时左右。

网页有了，数据有了，然后就是前后端对接了。

在对接过程中，我发现了原始数据中有很多特殊处理的部分。这很正常，因为爱好者网站的技术再好，也顶不住游戏的意外更新，只能通过补丁或特殊处理来解决。其实非特殊处理的部分解决的非常顺畅，不到半天就解决了，大约有一天的时间都在处理这些特殊情况，有些数据要单独抓取，有些数据文不对题，一个一个发现并处理这些细节非常折磨人。

不管如何，还是搞定了。

先说说这个练手项目后的一些心得。

制作爬虫本身是个非常繁琐的事情，这没有太多技巧，需要不厌其烦的点击网页去了解数据流向再去推理数据结构和一些规则。这会花费大量的人力和时间。在AI的帮助下，这个过程是全自动的，虽然也会花费不少时间。Antigravity会在网页上自主点击，模拟浏览行为，不断自我检讨数据流并验证。对于一些非标数据，AI会陷入疑惑，他有时候会思考如何把非标数据加到现有的数据中，有时候会想有没有其他办法。这个时候就要人工干预了，数据量小的就让他模拟点击，用最土的复制黏贴办法，数据量大的就让他先无视过往数据，先试着抓取几个看看能否跑通再全量处理。

通过不断投喂参考图，并根据AI给出的样式不断反馈，AI会逐渐把你需要的样式做出来。从开发角度，这是个非常有趣和高效的过程。对传统设计岗位可能不是很友好，我的观点是，“既然我这种非设计人员都能在AI的帮助下做一些好看好用的内容，专业设计人员在AI帮助下一定能够做出更好的东西！”

接下来说说Antigravity现在的一些问题。

容易报错，大概每20次大的代码变更就会产生一次错误，比如少一个”}”，重复定义参数或方法等等。年初的Trae也经常这样，现在已经很少见了。可能几个月后Antigravity也会解决这个问题。

国内的网络环境导致偶尔会出现无法连接的问题，不断重连会带来不必要的麻烦和挫败感。

毫无征兆的删除已有代码导致旧功能失效。Cursor和Trae之前也有这个问题，现在已经很少见了（偶尔也会）。学会使用git，并提高commit频率能有效解决这类情况。编辑器本身也提供历史版本查看和恢复的功能，但并不是很好用。另外，完成一个功能的时候让AI写下当前功能的实现方式、方法、参数作为备忘也能较好的解决这个问题。当你要修改或迭代功能时，把文档喂给ai有助于快速开始并降低错误率。

虽然现在还处于免费阶段，但是使用强度稍高的话就会遇到模型次数受限的情况，受限后只能换模型使用。Gemini和Claude都是代码能力不错的模型，可一个功能做一半告诉你次数用完要换一个还是会有些麻烦并且带来上下文问题（也多亏现在没收费）。

项目B：城市探险（代号）

玩法本身还是比较简单的Choose your Own Adventure，或者按照现在的分类叫做ADV游戏——看故事，做出选择，看故事，打出不同的结局。要说有什么不同的地方，这个玩法中是可以看视频听音乐的。

这本身不复杂，我要隆重介绍的是串联冒险过程的编辑器。

这是个可以在网页运行的连线编辑器。玩法中所有用到的内容都被包装成了“卡片”，比如故事，问题，问卷，排行榜，称号等等。这类编辑器常见于一些低代码工具中，比如游戏引擎的shader编辑、AI画图的comfy ui等等。

在过去，在没有类似经验的前提下，我们要做这样一个编辑器，需要做大量调研与测试。这不仅意味着难以估算的显性和沉没成本，也意味着大量潜在的合同机会丢失。试想，即便我知道能做这个东西，但因为没做过，在实现之前一定会遇到技术路线和选型的反复，特别当做了几天后（甚至更久）发现这么做不行的时候，挫败感还是其次，其花费的时间可是再也回不来了。

在AI的帮助下，原本一个实习生几天的工作量，现在仅需几个小时就能实现多个快速DEMO来进一步发现问题并进行最终选择。这里节约的时间对于争取项目的意义不言而喻。

在这个项目中，有些内容比如称号可以在卡片中直接编辑，有些则需要前往专用的页面进行编辑。游戏内容的编辑需要大量格式化的内容，这导致编辑本身也是个麻烦的事情。我们很难指望让做作者通过json或表格的形式去编辑故事，这很抽象。于是，就有了下图这种组件编辑方式。需要什么组件拖到编辑区域即可，输入的内容也是所见即所得的。系统负责把这些拼装的内容装进json再解析就行了。

“小白能用”，“不需要数据结构的知识”，“所见即所得”，在这样的想法下，就有了这么套东西，剩下就是把其他卡片和编辑方式完善的过程了。

AI让口号不再因为能力或眼界而成为虚妄。

相比宝可梦百科项目，由于这个项目的数据都是从0开始的，对接比较顺畅，大部分都是按部就班的工作，此处不再赘述。

这个项目基本都是用Trae国际版做的，所以来聊聊Trae。

其实我一开始不太喜欢Trae，因为2025年初他到处投放广告的时候尝试着用它在Unity中做一个2048游戏，结果很糟糕。大概每5次就会遇到一次编译错误，好不容易能编译了，运行效果也很差。要知道网络上随便找个教学视频都能在1个小时里面做出一个常见的2048。

初见很糟糕，我继续用了一段时间Cursor，直到Cursor不断更新自己的计费算法，让自己变得不再有优势。而那时，Trae也从用来debug的工具，变成了主角。是的，Trae的进化速度很快，从“糟糕”到可以用来debug花了一个季度的时间，又过了一个季度，它甚至可以用来做些真正的项目了。关键，在同行映衬下，他还很便宜。

项目3：砰砰斗恶龙

是的，我最近在做的这个弹球游戏，里面的代码全是用AI写的。

近100个脚本，从宏观的管理器，到细节的行为设置，都是用AI写的。

事实上，我一开始也对此表示怀疑，AI编程能否驾驭实际游戏开发：需求多变，性能要求高，多媒体配合，这怎么看都不是相对“安静”的网站和应用能比的。

结论很清楚，能做，而且这是一种很爽快的体验。

我把游戏开发定义为增量开发，他不是宝可梦百科那种一眼就能望到头的工程，稍有经验就能大差不差估算出工作量和时间。从一个需求开始，到实现原型，不断迭代，听视觉配合与加入，一个看似很小的功能都可能耗费大量的时间。

在这个项目中，为了模拟和调整弹球碰撞的“弹性”感觉，就试验了多个技术方案，更别说参数调整了。传统开发模式下这些迭代调整很容易变成人员间的无效扯皮，毕竟这是“感觉”。但是在AI帮助下，这类调整就变得很有意思——这个效果不好，换一个，参数不够那就加——能否达到那个“感觉”不再取决于技术水平或者眼界，而是我对“感觉”的描述能否更好地让AI明白，因为AI拥有大部分我知道甚至不知道的东西，是一个近乎完美的技术顾问（偶尔也会乱来）。

至于很多人担心的的代码屎山问题，我的观点是有些人对代码的“纯洁性”过分追求了。在增量开发的过程中维持代码易懂易维护远比屎山与否更重要，而目前来讲（当然这个游戏并没有那么复杂）也还没有出现这种情况。当然，我也不确定在200甚至更多个脚本之后会不会。

性能上目前也基本没问题，在大量弹球和粒子出现的场合也没有明显lag或帧数下降。如果选择60帧模式，即便在8年前的笔记本电脑上也能几乎全程帧数稳定。

关于如何迭代已有功能，我的方法是这样的:不急于做非常完善的功能，一方面AI的上下文有限，另一方面内容越复杂越容易搞砸，即便用Trae的Solo模式或者Antigravity的plan模式都是这样。所以，总是先创建原型，从基础的属性到一个方块能有简单的反馈，到最后再添加复杂的动态效果。每个有效的步骤后都在git上commit防止意外修改，并让AI写接口和功能文档，需要迭代的时候直接喂给他这个文档就行。通过这种方式就能尽可能的避免上下文不够，或者长期不维护后人员忘记代码怎么运作的问题了（事实上，AI做注释的习惯好于绝大部分程序员，但是注释由于内容分散并不容易阅读，这里提到的文档能够帮助人和机器快速找到对应的东西，更像目录索引的作用）。

这个游戏从2025年国庆之后开始制作，断断续续有3个月了，还没做完，现在还是玩法原型阶段（接近完成），感兴趣的可以关注我们，说不定某天就测试了。

我们来总结一下：

• AI编程能有效提高代码效率。
• 我们需要有限的基础知识就能较好的驾驭AI编程。我们要不断告诉AI要调用什么参数和方法，防止他重复造轮子。特别是在一些复杂流程中，不指挥或指挥不足很有可能带来奇怪的结果。
• 我们提出的需求更精确，AI就能更好地帮助我们。事实上，有时候人类看不懂的需求AI也能看懂，问题在于能不能更精确一些。AI的回复中甚至能看到大量的专业俚语和黑话！
• 用Git，习惯经常保存（commit），防止意外发生。
• 功能的每一次迭代结束后都让AI写功能文档，方便后续更新。
• 上下文限制决定了AI还不能处理超长脚本。目前我有一个几千行的服务器脚本在文档的标注的情况下AI还能正常处理，不清楚更长的脚本是否能顶住。而且，每次处理这个脚本都会带来大量的Token损耗（这时候用Cursor就会带来大量花费）。

至于其他，随着砰砰斗恶龙的进展以后再分享吧。

妙游社决定新开一个微信群“游戏与AI”，欢迎对AI结合游戏开发感兴趣的朋友，以及愿意分享AI使用经验或最新消息的朋友加入。请添加管理员微信miaoyoushe001。