快速说明：英语不是我的母语，所以我用AI润色了文字。以下的想法、例子和经历都是我的。

昨天我发了一篇关于AI游戏开发的帖子，遇到了很多反对意见，尤其是围绕一个问题：

如果AI在写代码，那我到底在做什么？

问得好。

我的第一款游戏iaBrick是用传统方式开发的。我从零开始学Swift，亲手一行一行地写代码。花了将近一年时间。

我很庆幸自己这么做了。

但那一年的很多时候，我都在和那些我并不真正关心的事情较劲：网络错误、文件处理、UI状态、后端通信、登录逻辑、随机崩溃、框架的古怪问题等等。

后来我开始用AI来做更多实现工作，构建iaReveal。

然后我有了一个有点不安的发现：

对于很多标准的基础设施代码，AI就是比我写得好。

那我为什么还要坚持自己写一个更差的版本呢？

我有时把AI看作编程中的又一个抽象层。

人们从机器码过渡到汇编，然后是C、C++、框架、引擎、可视化工具等等。没有人会说使用Unity就意味着你“没有做游戏”，因为你不是从头编写渲染器的。

AI感觉就是下一步。显然，它不是真正意义上的编程语言，但越来越常见的是，我描述系统必须做什么，而不是手动编写它如何做的每一个步骤。

但我也认为，这就是“一个提示=一个游戏”这个想法容易产生误导的地方。

如果你想基于已有的游戏结构做一个东西——比如平台跳跃、射击、三消、生存、经典解谜等等——那么是的，我完全能想象AI越来越接近“一个提示即可开发”。

这些机制已经存在。

到处都是例子。

AI主要需要复现一个已知的结构，然后改变美术、故事、主题、角色或呈现方式。

但如果机制本身是新的，那这一套很快就失效了。

你不能直接说：

“给我做一个全新的、以前没人做过的解谜游戏。”

AI到底该构建什么？

没有现成的机制可以复制。

没有已建立的状态模型。

没有已知的可解性规则。

没有经过验证的生成器。

没有标准的优化策略。

仍然需要有人把这些东西搞清楚。

而这正是我大部分实际工作转移到的方向。

我现在花在输入语法上的时间少多了，但花在思考以下问题上的时间多得多：

· 这个机制到底是什么？
· 什么让一个操作变得有趣而不是随意？
· 哪些状态绝对不能出现？
· 程序生成的关卡是否总是可解的？
· “技术上可解”实际上可玩吗？
· 一个关卡可能可解，但策略上对普通玩家来说是死局吗？
· 如何在不断裂规则的情况下生成新状态？
· 初始化时我能承受多少搜索量？
· 如何让生成够快，让玩家不会以为应用卡住了？
· 当两个机制在我没预料到的边缘情况下相互作用时会发生什么？

一旦我能清晰回答这些问题，AI往往就能很好地把这些答案变成代码。

但AI无法省去我回答这些问题的过程。

这就是我在意的区别。

“制作一款已知游戏的另一个版本”可能越来越接近一个提示的问题。

“发明一个新的游戏机制，并让它足够健壮用于商业游戏”则是一个完全不同的问题。

老实说，第二个问题才是我享受的部分。

有些人热爱写代码本身。有些人热爱调试。这完全合理。

我的乐趣不一样。

我喜欢把一个只存在于我脑海里的游戏机制，找出为什么第一版不行，修复逻辑，最终看到别人玩它。

我也有比耐心多得多（如果要手动花6-12个月编码每个游戏）的益智游戏想法。

AI让我能够尝试更多想法。

而且是的，我也希望这些游戏最终能赚钱。

我不觉得这有什么不好意思的。

如果玩家不喜欢这个游戏，AI不会神奇地让他们掏钱。

你可以用快十倍的效率做十款烂游戏，结果还是十款烂游戏。

所以我不再认为“谁敲的代码”是最有趣的问题。

对我来说，更有趣的问题是：

谁想出了这个游戏到底应该是什么，以及如何让这个想法实现？

那才是我仍然想拥有的部分。

附注：如果你想知道为什么我还没有正式发布iaBrick的iOS版本，反而先正式发布了iaReveal的iOS版本，这很大部分就是原因。后来AI帮我修复了iaBrick大部分崩溃问题，现在我几乎看不到崩溃了——但调试那段代码库真的让我有点心理阴影。我仍然担心，自己以前那堆意大利面条式的代码里，某处还潜伏着一个致命bug，随时会毁掉玩家的体验。所以我还在纠结：是保留原来那段代码库，还是干脆让AI帮我从头干净地重写整个游戏。讽刺的是，我让AI帮忙构建并放在itch.io上的iaBrick HTML演示版本，到目前为止一直运行没有任何致命bug——实际上，我连小bug都没碰到过。