来源公布的内容
Kyle Kukshtel 是一名有近 15 年经验的游戏程序员。2026 年 9 月 12 日，他在卡尔加里的 Indie Rodeo 大会上做了一场 45 分钟的演讲《Your Game Is A Harness》，随后把演讲内容整理成博客长文（不是演讲转录稿）——他还特意声明，这篇是 100% 人类写作。他讨论的是用大模型做真正的游戏开发：每天八小时、一周五天、持续几个月的那种，而不是 Twitter 上看起来很酷的一句话生成 demo。他的起点可以追溯到 agentic 时代之前：那时他把代码盲目地复制粘贴进 ChatGPT 网页版，硬是拼出了一个 moodboarding 网站 mood.site，前后花了 2 到 3 周的夜晚、总计约 20 小时——做成了，也让他彻底相信了大模型写代码的能力。
他的核心判断被他自己做成一张幻灯片：“LLMs are Bad At Games”。但他认为这不是智商问题，而是结构问题。Three.js 那套“一句话做游戏”之所以走得通，是因为一切皆代码：模型能读懂代码、能改、能看结果。而传统游戏里有大量非代码的“东西”——资产、场景，以及几十个难以用代码表达的系统——这些部分对模型基本不透明。他还指出，高质量的游戏开源代码在训练数据里比 web 项目少几个量级。为了讲清楚解法，他先科普了提示词结构（system / assistant / user 三部分）、同一个会话里每次发消息都会把之前的上下文全部重发一遍，以及由此产生的“上下文污染”：早期的坏内容会反复污染后面的工作——而新兴的 context engineering（上下文工程）就是研究怎么把最有用的信息放进上下文、污染压到最低。
解法从 harness（脚手架/线束）这个概念开始：harness 是智能体针对某类预期输入采取的一组动作模式。Claude Code 本身就是一个 harness，而 harness 可以为具体的工作增强、裁剪、抽象。现在很多团队都在给各个领域造 harness：接浏览器、遥测、性能分析、ticket、文档生成。但没有一个能真正“对你的游戏说话”：游戏是个黑盒，模型能看到的只有写出来的代码，这远远不够。所以要做的事，就是把游戏里的“东西”变成模型能直接操作的东西——把黑盒撬开，让游戏对 AI agent 可读。他还顺带说了一句实在话：下面这些技巧很多本身就是好的游戏工程，只是被 AI 放大了收益。
跟着做：把你的游戏改造成 harness 的六步
- 先定随机数：从项目第一天起，所有不确定性调用都走唯一的种子随机源——第 30 次 Random.Float 调用永远返回同一个值。确定性状态复现的地基要现在打，别等到上线前一个月。
- 存档优先：从一开始就把“精确存档/读档”做成基础设施。问自己一个问题：把当前状态完整存下来、再原样读回来，有多容易？新手团队总把它当“功能”留到最后补，这是大忌。
- 截图对比闭环：给引擎接上截图能力（多数引擎自带），并能开关 UI 层、玩法层来降噪。但别把原图直接扔给多模态模型——图像噪声本身也是一种上下文污染。正确姿势是用免费命令行工具 odiff 做前后对比，拿“85% 相似”这类量化值当每个 agent 回合的稳定评估基准。
- Thing 式对象：别搞上百个继承类，用一种胖结构 Thing（一块网格、一个碰撞体、若干数值、存活标志、类型枚举）表达一切。树和狗在代码眼里都是“有网格和碰撞体的东西”加不同组件。对象模型只剩一个真相源，AI 永远知道去哪改；序列化只剩一条路，存档读档天然简单。
- 命令模式加数据外置：所有状态变化都走可序列化的 Command 对象，经统一处理器生效。命令可以录制回放——bug 复现变成“回放命令序列”；也可以在文本编辑器里手写（你或 AI 都行），发给运行中的游戏免编译执行——这就是一张类型化的“遥控器”。数值类数据全部外置到游戏之外、启动时反序列化，调个移速不用再重新编译。
- 仿真核独立加文本性能分析：把游戏逻辑剥成独立的仿真库（DLL），引擎只通过命令和它通信——像 web 里客户端和服务器的关系。引擎变“傻”，只执行仿真返回的状态。这样测逻辑不用起引擎，纯 C# 工程加标准测试工具就能跑，AI 也喜欢。性能分析别用给人看的火焰图工具，用免费的 samply 把采样结果打成纯文本，agent 自己读输出、查文档、闭环迭代。
资料：[1]
正文详解：每个技术为什么对 AI 特别有效
先说截图为什么必须配 diff：作者实测过 naive 的版本——即使是多模态模型，也很难从两张截图里看出到底改了什么，更别说判断离目标近了没有。他的例子很直观：让骷髅“变成海盗”，模型会被迫处理整张带标注的图片，画面里其他所有东西都成了上下文污染。odiff 同时输出 diff 图和一个数字，而数字正是模型擅长读的稳定信号——“我离目标还有多远”变成了一个可以跨回合优化的量化基准。再配合裁剪，只让模型盯着该变的地方看。
Thing 驱动开发是作者口中“AI 真的很喜欢”的部分。如果有 100 个类、100 种对象，AI 动手前得先理解它们全部的关系，上下文直接爆炸，还要纠结是继承、改类型还是新建类——又乱又贵。单一对象类型消灭了这种歧义：改哪里永远只有一个答案。存档也从噩梦变成 trivial：一种类型、一种进出路，不用处理多态反序列化、竞态和对象树挂接。游戏退化成“一长串 Thing 的列表”：存就是全量存，读就是反向读。他还提到这不是新发明——Dreams 团队用过类似思路，Wookash 播客里有和创始人的访谈。
命令与数据外置的核心是收紧循环。命令模式给了 AI 一张类型化的“遥控器”：不用反射、不用写胶水代码，就能操控游戏；命令甚至不必来自游戏本身。他的实证是 Cantata 项目：约 7 个非程序员用自研数据编辑器 Depot 直接改 build 里的数据，不用等他重新打包——AI agent 也可以被教会用你的数据工具，同样免重编迭代。仿真核独立走得更远：逻辑进了独立库，就能在纯 C# 工程里用标准工具狂跑测试，根本不用启动引擎；而且游戏本来就在消费“状态差分”，差分从哪来（网络、LLM）根本无所谓——网络同步都变简单了。Brian Cronin 在 Roguelike Celebration 上讲过 Monster Train 的“黑盒游戏架构”，Solium Infernum 团队也是类似做法。
拼起来全景是这样的：确定性输入打底 → 用免编译的方式改状态 → 在真空中验证自己的改动 → 顺手看一眼性能影响——智能体一回合几秒钟跑完全部。因为循环够快，它可以对“每次改动”都跑一遍，而不是只在“重要时刻”跑。附言里作者留了个诚实的注脚：他正在交付的一个很小的项目压根没用这些——规模决定一切，这套是给大项目准备的重型装备。
如何解读
这篇文章真正的价值是视角反转：别再问“模型够不够聪明来做游戏”，要问“你的游戏让不让模型看懂”。一句话 demo 和真实开发之间隔着的不是模型智商，而是工程接口。Harness 不是某个具体工具，而是一套“让一切可寻址”的纪律：确定性、可截图、可存档、可命令化、可文本化。这些做到位，Claude Code 这类 agent 就从“写代码的”变成“能直接操控你游戏的协作者”。
对订阅者来说，最务实的建议是先上 ROI 最高的三件套，再碰架构：固定随机种子（成本最低的一行改动）、截图加 odiff 评估闭环（立刻让 agent 的迭代可度量）、数值数据外置（策划和 AI 都能免编译调参）。这三件不碰大手术，任何进行中的项目都能插进去。尝到甜头之后，再考虑 Thing 化和仿真核独立这种深水区。另外记住作者的尺度提醒：小项目别折腾，harness 是重型装备。
资料：[1]
阅读要点
- 核心论点：LLM 搞不定游戏不是智商问题，是上下文问题——游戏里大量非代码资产对模型不透明；harness 就是把黑盒撬开、让游戏可被 agent 直接操作的一套工程方法。
- 确定性先行：开工第一天定唯一随机种子源，存档/读档当基础设施而不是后期功能；衡量标准是“完整复现当前状态有多容易”。
- 截图别直接喂：用 odiff 做前后对比，拿“85% 相似”这类量化值当评估基准——图像噪声本身也是上下文污染，裁剪只让模型看该变的地方。
- Thing 驱动：一种胖对象表达一切，单一真相源让 AI 永远知道改哪，序列化一条路走通，存档读档天然简单。
- 命令加数据外置：状态变化走可序列化的命令对象，可录制回放、免编译执行；数值数据放游戏外面，AI 用你的数据工具自己迭代。
- 仿真核独立：逻辑剥成独立库、引擎只消费状态差分，测试不用起引擎；性能用 samply 输出纯文本给 agent 自己读。智能体一回合几秒跑完全循环，对每次改动都跑。
资料：[1]
