做错事!是一款基于选择的奇幻喜剧游戏——在浏览器中免费，在安卓设备上收费。AI写了大部分文字，生成了所有艺术作品，并生成了音乐。 我设计了结构，编写了引擎，并进行了编辑。值得分享的部分不是我提示了LLM。它是生成内容在这个规模上会分崩离析的特定、可预测的方式，而我的大部分实际工作都是建立一个捕捉它的框架。

1. 语音规范做得比任何提示都要多

最高杠杆的东西不是在游戏中——它是~300行的编写规范，模型写了它。不是“写在一个幽默的奇幻语音中”，而是实际的机制：

  • 三种喜剧模式——冷静的观察、绝望的自我意识、荒谬的升级——每种都有具体的例子。
  • 一条具体性规则与一个模糊→具体的表格。 “很多钱”→“四十银币”。 “一把武器”→“可疑的假设刀”。具体细节落地；通用细节被读过了。
  • 每个角色都有独特的语音签名和样本语句。巨人说话时全大写，Earnest 声明。导师巫师说话时像是在委员会会议中，提到Seers的财产损失基金。如果一句话可以来自任何角色，它就会被重写。
  • 一份明确的“语音破裂”清单：没有四壁打破，没有现代俚语，没有黑暗，无法表达情绪（“你感到害怕”→“你的腿决定离开你的身体的其他部分”）。
  • 每种节点类型都有长度指南——转换50-100个词，标准场景150-400个词，结尾300-600个词。

在那之前，每个生成场景都很幽默，但在会话之间漂浮。之后，输出就足够一致，以便编辑而不是重写。如果你在一个语音中生成大量内容，首先编写风格指南是最高回报的投资——并且它会累积，因为你可以把它交给模型几个月后，得到相同的语音。

2. 结构是我的，文字是模型的

分支是生成内容分崩离析的最快地方。线性文字保持一致。只要有两个选择重叠，模型就忘记它们曾经不同，写下一个通用的场景，适用于两者。所以我拥有图表——节点、状态标志、哪个选择设置什么——并根据一个规范生成每个节点：

玩家到达这里拒绝了，还是付款了，文字都必须反映哪个。

模型在紧缩的约束下写出好的文字。它不能在头脑中保持160个节点的图表，并要求它这样做是如何获得混乱的。规范也编码了设计规则：

两个选择落在同一个节点上是可以接受的 如果它们通过不同的意义——一个谦逊的，一个傲慢的，不同的标志，下游的风味不同。同一个节点，同样的标志，同样的文字是假的代理，玩家会感觉到欺骗，即使他们无法指名它。

3. 验证是使生成内容可发布的关键

这是我会推广给任何做大量内容的人的部分。生成内容会 静音失败，所以我制作了失败的噪音：

  • 一个图表统计脚本走遍整个故事：从开始节点可达性，是否每个结尾都实际关闭，设置但未检查的标志，检查但未设置的标志，定义的项目与实际使用的项目。它暴露了一个堆积的静默死胡同，我永远不会通过阅读找到。
  • 每个条件文字函数都运行所有组合——6个种族 × 4个职业 × 3个性别，针对每个节点。生成的条件文字喜欢假设一个标志存在。测试套件找到的是崩溃，而不是玩家找到的。
  • 错误的节点引用，非蛇式ID，addItem指向不存在的项目——所有这些都是硬性测试失败，而不是我应该在审阅中注意到的东西。生成的内容是好的。 未验证 的生成内容在大规模上是坏的。

4. 艺术：一个锁定的风格字符串，以及一个让你说不的fallback

在~160个场景插画之间保持一致性的方法是对风格描述器进行固定资产处理——一个长字符串（中性，线质量，调色板，照明）被每次生成时都粘贴到每个生成中，仅变换主体。然后过度生成并剪辑掉任何不合邻居的东西。

实际上让我愿意剪辑的东西是可预测的fallback。缺少的图像会将节点ID哈希到一个温暖的渐变上，并将场景描述写在上面，所以被拒绝的图像会退化为一个看起来有意图的东西而不是一个空洞。

这是很便宜的成本，也会提高你的标准——你会拒绝更多，因为拒绝是免费的。

5. 音乐：16首歌曲，没有手动映射160个节点

16首歌曲——标题，村庄，巫师，出发，森林，男爵的道路，河流，战斗，城市，最后的夜晚，墓穴，高潮，结尾，字幕。有趣的问题不是生成它们，而是在不维护一个160行查找表的手动映射的情况下将它们路由。

节点ID以区域前缀命名（dw_森林，br_男爵的道路，rv_河流，ash_城市，ending_结尾）。因此音乐通过 前缀匹配在命名约定中解决。然后一个小的 明确的覆盖映射处理例外——战斗在森林中需要战斗的歌曲，而不是森林的歌曲；一些结尾需要墓穴的歌曲，而不是通用的ending_规则。

明确的覆盖映射首先，然后是前缀匹配。并且在开发构建中，未映射的节点会记录一个警告，所以一个新场景会在默默播放错误的情绪之前宣布自己。命名约定作为路由表双重使用值得学习，如果你在大规模上生成场景。

6. 引擎：手写，故意

React/Vite，自定义，没用游戏引擎；Capacitor包装它以便安卓。

我故意保持手写，因为内容是有界的，很便宜的审阅——一场景读起来对或不对。引擎错误是相反的；它们会在几个星期后在别人的设备上出现。

具体来说：在发布构建中打开代码压缩的机会会静默地打破应用内付费，因为付费客户倚赖反射。

这是不可能在 diff 中捕捉到的。

你通过知道这是一个风险并在商店签名的构建上测试购买恢复路径来捕捉它。

我会做得不同

早点将验证绑定到一起。

我在有大量内容后添加了图表统计脚本，它立即暴露了几个星期来存在的问题。

便宜的成本在一开始，昂贵的成本是在后期修复。