用Gemini和Claude Code在26天内制作5.2万行游戏并上架Steam的实战经验

本文分享的内容（给未来用AI制作游戏和应用的人）
让AI编写“数百行脚本”很简单，但要让它一行代码都不写就做出“5万行、超过100个关卡的游戏”，如果按常规方法操作，上下文会溢出并导致100%失败。
本文将公开在26天内、总计消耗47亿token完成Steam平台游戏的过程中所构建的“能让AI自主运行和自我验证的Harness设计”，以及“实际踩过的7个坑及其规避策略”。

1. 实证结果：在26天内与AI们共同制作的东西

首先，展示一下本次介绍的这种方法论能够实现多大规模的项目，这里提供仓库的实际数据（截至v1.0版本）。

項目	規模（実数）
C# 代码（Unity + 终端引擎）	约 52,200 行（137 个文件）※人类手写代码为 0 行
Python 代码（剧本生成与检查）	约 10,900 行（18 个文件）
自动测试（冒烟测试）	1,646 项（包含全 104 话及隐藏关卡的通关验证）
已实现命令与场景	Linux 命令 80 种 / 场景主线 104 话＋入职前培训＋隐藏关卡
Claude Code 总 Token 数	输入约47.3亿（现金98.6%）/ 输出约1,140万
开发期间·提交次数	26天（实际运行22天）/ 198次提交
变更日志·手动测试步骤（MD）	变更日志167项 / 手动测试步骤121节

主题是，将我21年的SE经验浓缩其中，用Linux命令管道镇压黑心企业事故的模拟游戏『战斗的信息系统部』。

※当此规模的开发项目，与常规项目一样，标准化和基准书等「机制（环境设计）」不可或缺。

2. 角色分工与技术选型：以“AI不迷茫、自己不动手”为最高优先级

为何选择“Unity (C#)”？

如果是基于CUI的游戏，Electron或Godot也是选项之一，但通过与Gemini进行头脑风暴后，我们以「AI能否最准确地编写代码」为标准，最终采用了Unity。

Claude的学习量与自足能力：鉴于Unity特有的生命周期、uGUI控制以及C#类设计的训练数据丰富，我们判断让Claude自主推进打字特效和日志滚动控制较为容易。
Steamworks.NET的实绩：由于网上关于全部9种成就解锁及通过Steam Cloud进行存档同步的案例众多，仅凭Claude就能顺利实现而无需迷茫（虽然在商店审核阶段因AI使用披露栏英文内容过短及胶囊图文字规定被退回两次，但连同构建审核在内最终顺利通过）。
演出的简洁性：后半段的“警告红灯闪烁”、“黑色KVM控制台”、屏幕晃动以及服务器机房的风扇环境音等，都没有使用复杂的功能，仅通过uGUI的颜色和主题切换与AudioSource即可实现。

四方团队体制：原案由Gemini负责，实现与维护由Claude负责

プランナー兼監査役：Google Gemini(3.1 Pro)
- 平衡“黑色幽默”与“现场正确教训”的剧本原案、命令谜题的关卡设计
- 完成剧本（MD）的审核、为图像生成AI制作英文提示词
リードエンジニア：Claude Code（Opus 5 → Fable 5.1 → Opus 5.5）
- Unity（C#）及Linux命令模拟器（终端引擎）的实现
- 将原案转化为剧本数据（Python生成脚本 → 阶段JSON）并润色台词
- 整合性机械检查、自动测试、与实体机（WSL）的对照，以及根据规格变更更新MD
アートディレクター：NanoBananaPro2
- 从游戏内资产创建Steam商店横幅（使用Gemini生成的英文提示词）
プロデューサー兼テストプレイヤー：私
- 提供21年的现场经验，进行“这很有趣/这令人不适”的判断，以及「观看画面」

实际开发中的感受是，Claude可以按照指示修改细微的对白，但
在构思想法和润色方面非常不擅长。

因此，润色工作主要由Gemini 3.1 Pro负责。
相反，Gemini在陪练时有“附和”的倾向，因此需要适当区分使用。

3. 【设计的核心】防止AI驱动开发崩溃的两种架构

在让AI共同完成5万行代码的游戏开发中，以下两项设计最为关键。

① 将游戏的核心部分从Unity中分离（无头化）

铁律：AI无法操作GUI（Unity编辑器）
如果采用“必须启动Unity才能进行功能验证”的设计，人类就不得不每次手动进行测试游玩，导致开发速度急剧下降。核心在于尽可能扩大无需编辑器即可验证的范围。

因此，我们将命令解析、虚拟文件系统、通关判定等“终端引擎”部分剥离出来，使其完全不接触UnityEngine，作为纯C#（Pure C#）独立实现。
此外，窗口和按钮等UI也不手动放置到场景文件中，而是改为在启动时通过代码动态构建的方式，从而减少了被要求“重新制作场景”的次数。

这样一来，Claude在修改代码后，无需启动Unity，只需使用普通的C#编译器进行构建，即可通过命令行高速运行1,646项自动检查。

② 将Markdown（MD）设为“唯一信息源（Single Source of Truth）”

在与生成式AI进行大规模开发时，最可怕的是因上下文遗漏而导致的时间线和设定不一致。Claude Code在会话变长后会对上下文进行摘要，但由于“对话会消失，但MD会保留”，所以我们将所有信息都汇总到了MD中。

通过事前定义构筑防波堤：将世界观、时间线、登场人物、各集的通关条件等全部定义在MD中，并要求在实现前务必阅读。
变更履历的连续编号管理（共167件）：规格变更时，将“变更内容与经过”带连续编号地累积到MD文件的上部。这样下一个会话中的AI就能继承“为什么会变成这样”的信息。
将手写部分与从数据生成的部分分开：各集的列表（日期时间、委托者、解放指令、通关条件）每次都从关卡数据用脚本生成并写回 MD，从根本上消除了台本与资料之间的偏差。
手动测试步骤也积累到MD中（共121节）：每次修正时，都逐节追加“输入什么、达到什么结果算合格”。人工试玩就是按照这些步骤进行的。
明确“约定事项”：像“提交要等我要求之后”“不要使用字体中没有的字符”这样的规则也写进MD，让其在跨会话时也能被遵守。

【场景MD文件摘录（规格变更记录）】

【场景MD文件摘录（各阶段设计）】

实际共享资料（MD文件）的摘录

【角色与人格定义示例】

铃木董事：4个系统全部 admin1234，在共享文件夹中以明文形式放置一览表。凌晨3点打开预算文件。11月16日与供应商密谈（不告知情报系统部门，将日志保存期缩短至30天，使用维护用账户进行操作）。"别显示在画面上""销毁证据，这是业务命令"。

【世界观与公司企业文化定义示例】

绝对的上位关系与对传统模式的沿袭：职位具有绝对权威，甚至在数字系统中也要体现对上级的尊敬。例如“盖章角度规定第41条（向左倾斜5至15度按下＝鞠躬章）”就是将现实中存在的陋习系统化的产物。

【满足条件的类型定义示例（数量由数据自动统计）】

型	意味	使用数
`run_command`	输入指定命令	118
`submit_answer`	在聊天窗口或控制台中发送答案	23
`kill_all_malicious`	停止所有恶意进程	3

4. “万无一失”是谎言：实际踩中的7个地雷及解决方案

即使将MD作为中心，崩溃仍会发生。关键在于建立一套让机器和人类都能发现崩溃的机制。以下是团队实际踩中的地雷及其修复方法的记录。

地雷①：检查脚本“读取0件即判定合格”

用于发现剧本矛盾的检查脚本以相对路径持有剧本的位置。

STAGES = os.path.join("Assets", "StreamingAssets", "Stages")   # 実行した場所に依存する

从其他目录运行时，连1集都读不了，却仍然显示“剧本封面与内容一致”，程序照常运行。由于改变执行位置后结果发生了变化，Claude自己找到了原因。

解决：将路径改为相对于脚本所在位置进行解析，并如果一件也读不到就判定为失败。修改后立刻发现了5处隐藏的偏差。
教训：编写检查逻辑后，要一起验证“故意破坏时是否会崩溃”。通过测试并不能证明任何事。

地雷②：被默默丢弃的配置键

第52话是“向账本上没有的服务器发送 ping 以确认存活”的一集，但在测试游玩中发现了这样一个bug：ping 实际上是 100% loss ，但请求者却回复说“已确认可达性”。

原因是剧本中写的是 hosts 这个键，而读取端只读取了 reachableHosts 。由于未知的键会被默默忽略，因此没有报错。

解决：在生成脚本侧引入机制，将设置键与读取侧的列表进行比对，若发现未知的键则停止（在全部104集中，仅此1集出现了该问题）。
教训：名称相似导致的混淆，无论是人类还是AI都会发生。“宽容式读取”会隐藏bug，因此应设置为不默默通过而是报错的机制。

地雷③：微小追加的不断累积，踩中了TextMeshPro的上限（16,383个）

在第33集中打开游戏内浏览器的手册时，上一页的文字出现崩坏并残留 IndexOutOfRangeException 。

原因是TextMeshPro的上限限制（单个文本最多可拥有16,383个矩形）。由于持续请求“每次都是微小的追加”，如命令说明或图解等，结果在第24集超过了上限，最终话达到了4万至6万个。

解决：Claude从堆栈跟踪读取到TextMeshPro的源码，实测了所有集数的页面大小后，提出了将正文按每5,000个为单位分块绘制的方案并进行了实现（分割位置的判定已通过模糊测试验证）。
教训：正因为对方会欣然答应请求，所以请求方和被请求方都没有对数量设定上限。请在关键节点进行实际测量。

地雷④：从最初的提交开始就损坏的成绩保存（通过AI之间的交叉审查发现）

“读取”函数带有“恢复成绩”的副作用，导致每次自动保存时成绩都会回退到文件中的内容。由于游戏不会崩溃且不会报错，因此无人察觉。

解决：通过在提交前运行Claude进行的AI之间多视角审查发现了问题。为每个视角设立审查角色，让其他AI验证“能否反驳”发现的指摘，最终修正了幸存下来的5项问题。
教训：与人类团队一样，务必经过不同于撰写者本人的视角（不同视角、反证角色）。

地雷⑤：对于“和真机一样吗？”这个问题，不应依靠知识，而应通过真机（WSL）来回答

出于教育目的，我坚持让它在“与实物相同的行为”上保持一致。当询问在通过 top 到 q 时画面是否会消失时，Claude 诚实地补充道：“这是基于知识的判断，未在实物上进行过确认。”于是，我在 PC 内的 WSL（Ubuntu）中记录了包含模拟终端的输出，并计数控制字符以进行验证。

命令	进入替代画面（`ESC[?1049h`）	从替代画面返回（`ESC[?1049l`）	退出时
`top`（procps-ng 3.3.16）	0 回	0 回	画面不消失。最后一帧保留下来
`less`	1 回	1 回	返回原始画面

用同样的方法，我们还发现 sed 的错误文本位置偏移了一位（实机为 char 11，游戏为 char 12）。

教训：准备一台可供 AI 进行验证的实机（WSL 即可），并要求其分别报告“已确认的事实”与“基于知识的推测”。

地雷⑥：主动汇报提案的前提是错误的

Claude 提议将终端历史的上限设为“15,000 字吧。普通输出要少得多”，我同意了；但在实现前，Claude 重新测量了全部 104 话的输出量，并报告说：“本篇的 28 条日志会超过 15,000 字。刚才的说明是错误的。”

教训：带有数字的提案应在实现前请对方实测。欢迎指出错误、能轻松开口的关系，最终反而能提升质量。

陷阱⑦：画面看起来不像AI生成的

“页码出现在纸张正中间”“文字重叠”“场景中保存的值优先于代码默认值”这类问题，对于看不见画面的 AI 来说无法自行观测。由我截图后交给它是最快的办法。

教训：人类负责“观察”与“判断”，AI负责“日志、原因与修正”。试玩（进行了2周）不能省略。

5. 支撑质量的机制：每次修复都会运行的6项自动验证

每次修正时，都会自动通过以下所有检查，无需启动Unity。

剧本生成（Python → 舞台JSON）以及剧本之间的比对
冒烟测试（共1,646项检查）：在不使用Unity的情况下编译终端引擎，并实际运行所有剧情的正确步骤以验证能否通关
针对Unity的编译确认
字体检查：若使用的字体中混入了全角的“！”或“？”等字符，会导致乱码（豆腐块），因此会扫描所有文件
存档数据删除遗漏检查
更新变更日志与测试流程的MD文件

6. 实际花费：模型、套餐、Token、时长

基于 Claude Code 的会话记录（JSONL），从编码开始到 v1.0 构建完成的所有会话，去重后统计的实际数值（不包含 Gemini 和图像生成 AI 的部分）。

開発期間（26日間 / 実稼働22日）

項目	日付
编码开始（首次提交）	2026-09-05
增至全部 100 话	2026-09-07
全部 104 话及隐藏关卡的重制（剧本第 6 版）	2026-09-14
第2周测试游玩的修正	2026-09-18
连接至Steam（成就、构建与分发机制）	2026-09-25
v1.0版本构建（冻结）	2026-09-30

使用的模型与Token明细

模型	使用期间	主要共同完成事项	回复数量	输出令牌
Claude Opus 5	9/5〜9/14	终端引擎与界面基础，共100集的框架，KVM控制台	約 4,100 回	約 462 万
Claude Fable 5.1	9/8〜9/25	研修与设定，全部104话的重制，与实机的全面检查，第二轮的修正	約 2,800 回	約 497 万
Claude Opus 5.5	9/25〜9/30	支持Steam（成就、云存档、分发），发布前的审计	約 3,200 回	約 175 万

（※此外，9/10至9/12期间Claude Opus 4.8有13次响应）

項目	Token数量
输出（AI编写的代码、剧本、说明、报告）	約 1,140 万
输入（包含每次重新发送的对话上下文）	約 47 億 3,000 万
其中来自缓存的重新读取	約 46 億 7,000 万（98.6%）
其中新读取的内容	約 6,500 万
响应总数	約 1 万回

最初从 Claude Pro 开始开发（使用 Opus5.0），但最终因令牌量不足和质量不佳，改为 Claude Max 5x（使用 Fable5.1）。即便如此令牌仍不够用，最终升级到了 Claude Max 20x 计划（使用 Opus5.5）。

特别是在 Opus5.0 中退化现象较多，虽然升级到了 Fable5.1，但在质量与性能的权衡下，令牌的消耗量极其惊人。Opus5.5 发布后，令牌的消耗量趋于稳定，真是帮了大忙。

基本上，通过以Opus5.5为基础并将Effort设为超高，同时开启Ultracode，Token和品质都一下子稳定了下来。

正因为采用的是API的固定套餐而非按量计费，所以才能毫不迟疑地运行一万次，每次进行烟雾测试输出的读取以及加载超长的MD文档。

结语：致各位工程师

所谓“由AI制作”，实际上是“让AI制作、让AI检查，而我则游玩并做出判断”。
人类作为制作人，负责准备MD的中枢环节和验证环境，并非甩手不管，而是盯着屏幕、游玩并做出决定（例如，在试玩中只要感到任何不适的BGM或煽情演出就将其剔除，而在真结局中选择只保留粉丝声音的安静演出）。这就是人类一方的职责所在。

游戏正篇中，我融入了这样的“现场的真实感”与“Linux哲学的快感”。

ps aux | grep enc-worker | awk '{print $2}' | xargs sudo kill -9 仅用这一行代码，就一次性终止了12个失控进程
从2万行的syslog中，仅提取出grep里可疑的8行
最后的办法是让保安人员跑过去，物理上拔掉LAN电缆

《战斗的信息系统部》是写给所有直面不合理社会与系统的工程师的情书。

请尽情体验凝聚了21年现场实况的“Linux哲学的宣泄”。
（如果您是IT行业新手，不妨将其作为CUI环境的练习场。）

🎮 Steam商店页面在此: 《战斗的信息系统部》

价格为480日元（发售7天内享受15%折扣，即408日元，约一杯咖啡的价格）。仅限Windows（64位）使用。
※游戏内的命令均在虚拟环境中运行，不会触碰您个人PC上的任何文件，请放心输入（顺便一提，rm -rf /在游戏中也能正常停止）。

即使暂时还没有时间玩的朋友，也请加入愿望单，这将是对我们的鼓励！

如果您对提示词的构思或AI之间的协作流程有任何疑问，欢迎在评论区提问！