快速说明：英语不是我的母语，所以我用了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都没遇到过。