demo和源码
不支持移动端，可能需要1分钟的加载
plugin我之前弄的时候很容易碰上路径问题，导致读取不到项目根目录下setting，如果要用的话得从Marketplace中获取后手工拷贝 agent & skills & script 到项目目录
技术栈：
| 类型 | 工具 |
|---|---|
| LLM | GLM |
| Harness | Claude Code |
| 美术 | GPT Image 2.0 |
| 配音 | Qwen3-TTS |
| 配乐 | SeedMusic 1.0 Preview |
| 环境音效 | AudioFly |
| 游戏引擎 | Godot |
| 图数据库 | Neo4j |
写在前面的话
请原谅我的标题党，这篇文章真正的标题应该是：
《3句话 + 21个 Skill + 无数人工微调，AI 给我生成了一个 Galgame》
实际上，这个游戏确实几乎所有资产都是 AIGC ，但距离"3句话生成一个 Galgame"还差得很远。
换句话说，AI 确实参与了绝大部分生产过程，但它距离一个可以完全自主完成游戏开发的智能体，还有相当长的距离。
LLM 真的已经无所不能了吗？
随着大语言模型的出现，网上一直充斥着各种相当乐观的声音。
各种公众号、自媒体和利益相关者不断神话 LLM 的能力，似乎只要再等一段时间，AGI 就会出现，软件、游戏、小说、音乐乃至所有知识工作都会被 AI 接管。
但如果暂时把宣传放到一边，只看实际生产，我认为现实要凄凉得多。
LLM 目前真正表现出工业生产能力的领域，依然集中在编程相关领域。
而在其他领域，普遍还是：
出个简单的 demo 可以，大规模工业化还不够。
这也是我这次尝试用 AI 做一个完整游戏后最大的感受。
问题并不是 AI 不会生成。
恰恰相反，现在的模型已经非常擅长生成各种东西，真正的问题是：
生成之后，怎么知道它对不对？
为什么编程特别适合 LLM？
如果分析一下为什么 LLM 能够在编程领域率先进入相对实用的阶段，我认为主要有三个原因。
1. 编程语言相对无歧义
编程语言从设计之初就是为了让机器执行。
text
if (condition) {
doSomething();
}它的语义空间受到语言规范、类型系统和运行环境的严格限制。
自然语言则完全不同，同一句话可能有很多合理解释。
"一个温柔的女孩"到底有多温柔？
"昏暗的房间"到底有多暗？
"悲伤地说话"到底应该是什么声音？
这些问题很难得到一个唯一答案。
2. 有大量高质量训练数据
开源项目、GitHub、Stack Overflow、技术文档以及大量程序代码，为模型提供了规模非常庞大的程序训练数据。
更重要的是，这些数据之间存在大量重复和相似结构。
一个问题通常可以找到很多已经存在的解决方案。
3. 交付物可以被快速测试
我认为第三点才是最重要的。
代码写出来之后，可以立刻得到反馈：
text
代码 -> 编译器 -> 语法错误 / 类型错误
代码 -> Unit Test -> Integration Test -> 运行结果也就是说，AI 生成的东西可以快速进入一个反馈闭环。
这个闭环实际上构成了 AI 进行工业级编程开发的重要基础：
text
生成 -> 测试 -> 发现问题 -> 修改 -> 再次测试AI 不需要一次就写对，只要错误能够被快速、明确地反馈出来，它就可以不断迭代。
游戏开发的问题恰恰相反
如果把同样的思路放到游戏开发中，就会发现事情突然变得麻烦起来。
游戏开发的交付物远不止代码，还有：
- 剧情、台词
- 角色设计、角色立绘
- 场景
- 配音、音乐、音效
而这些东西大多数都没有像语法检查或者单元测试一样明确的"正确答案"。例如：
这张角色立绘到底好不好？
这个角色的声音是否符合人物设定？
这一段剧情是不是足够精彩？
于是整个生产流程很容易变成：
text
AI 生成 -> 人工审阅 -> 觉得不对 -> 告诉 AI -> 重新生成问题在于，"不对"本身就是一个非常模糊的反馈。
这也是为什么我认为，AI 在游戏开发中真正的瓶颈已经不是生成能力，而是验证能力。
不同生产环节，难度完全不同
这次实际做下来，我对几个环节难度的体感大概是：
text
剧情 >>> 台词 >> 配音 > 美术 > 配乐 ≈ 程序下面分别说。
剧情：目前基本没有特别好的解决方案
剧情是整个流程里最让我头疼的部分。
理论上，可以把人物、地点、事件和信息全部放进知识图谱，然后使用图算法寻找图中的缺口，再让 LLM 根据这些缺口继续生成剧情。
例如：
角色 A 只有两个事件关联
而其他核心角色已经拥有几十个事件，那么 B 就可能是一个值得继续扩展的节点。
从工程角度来说，这套方案是可行的。
但问题是：
能找到剧情缺口，不代表能写出好剧情。
目前 LLM 可以比较稳定地生成"合理"的剧情，但距离真正有趣、有张力、有记忆点的剧情还有明显差距。
所以这次 Demo 的剧情部分，我最终还是选择了手写。
图算法负责发现问题的思路我会继续做，但至少目前，它更适合作为创作辅助工具，而不是一个真正的自动编剧。
台词：最大的问题是不说人话
台词的问题和剧情不太一样。
它不是完全不会写，而是经常会写出一种非常明显的AI 味。
语言逻辑没有问题，语法也没有问题，但就是不像人在说话。
例如人物明明只是表达一个很简单的情绪，AI 往往会不自觉地把句子写得过于完整、过于工整。
这或多或少也和我使用的模型有关。这次主要使用的是 GLM，DeepSeek 在这方面会稍微好一些，理论上 GPT 是写作最好的选择。
但我不认为换模型能够从根本上解决这个问题。
我之前也专门潜伏观察过一些网文写作社区，一个比较有意思的共识是：
如果只看写作能力，现在主流 LLM 和当年的 GPT-3.5，在"说人话"这件事情上的差距，几乎没有区别，甚至更差
模型可以润色，可以改错别字，可以调整表达，可以根据要求扩写，但让它长期维持人物、世界观、叙事节奏，并持续产出真正有吸引力的内容，依然很困难。
至少目前，我更愿意把它看成一个非常强的编辑和辅助创作者，而不是作者本人。
配音：情绪和音色的一致性很难同时满足
配音看起来比剧情简单得多。
现在的 TTS 已经能够生成质量相当不错的人声。
但真正开始施工之后，会发现这里存在两个要求：
- 角色需要有稳定的音色。
- 不同台词又需要有不同的情绪。
单独解决任何一个都不难。
固定一个声音，然后一直念同样的东西，音色可以非常稳定。
或者让模型自由发挥情绪，也可以得到很有表现力的声音。
但把两件事情放在一起：
text
固定角色音色 + 不同情绪 + 不同语气 + 不同场景事情就开始变得麻烦。
同一个角色开心的时候、愤怒的时候、害怕的时候、低声说话的时候，都需要还是"这个人"。
美术：单张图片已经不是问题，统一画风才是
如果只评价单张图片，质量已经足够高。
现在的问题已经不是：
AI 能不能画出一张好看的图？
而是：
AI 能不能连续画出 20 张不同角色、画风相同的设计图
例如我明确要求：
半写实角色设计风格。
对于成年人角色，模型通常可以做到。但当我要求它生成一个小女孩的三视图时，模型又很容易被自己的训练数据带偏，最后变成非常典型的日系二次元画风。
这说明一个问题：
单张图片的生成能力和稳定的视觉风格控制，是两个完全不同的问题。
配乐：问题不大
配乐是这次比较轻松的一个环节，虽然这份轻松是建立在demo场景不多的前提下的。
程序：目前反而是最简单的一环
这可能也是整个项目里最符合大家对"AI Coding"想象的部分，也恰恰是大语言模型的甜点区。