Loop Engineering 来了：游戏开发者如何用 AI 循环自动化重构工作流
2026 年 6 月初，Claude Code 的创造者 Boris Cherny 在 Acquired Unplugged 开发者大会上说了一句话：「我已经不给 Claude 写提示词了。我有一堆循环在跑，它们负责给 Claude 下指令、决定下一步做什么。我的工作，就是写循环。」几乎同一周，Google Cloud AI 总监 Addy Osmani 发布长文，正式将这种工作方式命名为 Loop Engineering（循环工程）。这不是又一个营销词汇——Claude Code 和 OpenAI Codex 都已在 2026 年 Q2 原生支持了循环所需的全套组件。对于游戏开发者而言，理解这一范式转变，可能比学习任何单个 AI 工具都更重要。
[[image:overview]]
从 Prompt 到 Loop：四次迭代到底在解决什么
过去三年，AI 工程方法论经历了四次迭代，每一次都对应着 AI 自主工作能力的跃迁。
Prompt Engineering（2023 年起）：AI 是一问一答的工具。你写提示词，它执行。核心技能是「把指令说清楚」——角色设定、少样本示例、思维链。在游戏开发中，这就像你告诉美术 AI「画一个暗黑风格的骑士角色，手持发光长剑，背景是废墟城堡」。
Context Engineering（2025 年中起）：AI 开始能连续干几十步，但会忘事。你需要管理它看到什么信息——RAG、MCP 工具调用、记忆机制。在 UE5 项目中，这意味着让 AI 理解你的项目结构、材质命名规范、蓝图组织方式，而不是每次都从零开始。
Harness Engineering（2026 年 2 月起）：AI 能干几个小时的大活了。你需要给它搭完整的工作环境——项目规范文档（如 CLAUDE.md）、验证钩子、权限约束。HashiCorp 联合创始人 Mitchell Hashimoto 提出的核心思想是：每当 Agent 犯错，不要改提示词，而是改造它的运行环境，让这个错误在结构上不可能再发生。
Loop Engineering（2026 年 6 月起）：AI 能连续干几天了，还能同时开几十个实例并行。你需要一套自动调度系统——什么时候启动 Agent、干完谁来检查、检查不过怎么重试、记录存在哪、什么时候收工。人彻底退出执行环节，只保留设计权和验收权。
这条演进线的底层变量只有一个：AI 能连续自主工作的时间长度。从一问一答，到几十步，到几小时，到几天。人的角色同步上移：提问者、信息管理者、环境搭建者、系统设计师。
一个循环由什么构成
按 Osmani 的拆解，一个完整的 Loop 由五个核心构件组成：
目标条件（Goal）：什么算干完？不是「尽量做好」，而是「所有测试通过且 lint 无报错」这种可被机器验证的条件。Claude Code 提供 /goal 命令，Codex 提供 automation 原生支持。判断「算不算完成」的，是一个独立的小模型，而不是写代码的 Agent 自己——就像考试不能自己批卷。
技能系统（Skills）：解决「每开一个新会话都要从头介绍项目」的问题。本质上是一个结构化文件夹，存放项目约定、构建步骤、历史踩坑记录。在 UE5 项目中，这可能包含：蓝图命名规范、材质层叠规则、PCG 节点配置标准、打包发布流程。写一次，Agent 每轮运行都读得到。
子 Agent 分工：写代码的 Agent 给自己打分手太松。换一个指令不同、甚至模型不同的第二个 Agent 来审，能逮住第一个说服自己忽略的问题。常见分工是：探索 Agent → 实现 Agent → 验证 Agent。这和游戏团队里「开发不能自测」是同一个原理。
连接器（Connectors）：基于 MCP 协议的连接器让循环能读问题追踪器、查数据库、开 PR、更新工单。在游戏开发场景中，这意味着 Agent 能直接读取 Jira 上的 Bug 列表、访问 Perforce/Git 的提交记录、触发 Jenkins 的构建流程。
工作树（Worktrees）：多个 Agent 同时工作时，各自在独立分支的独立目录上操作，互不污染，干完自动清理。这是并行不退化成混乱的前提。
第六样是记忆——落在磁盘上的状态文件，记着「干完了什么、还剩什么、上次踩了什么坑」。模型每次重启都失忆，所以记忆必须活在单次对话之外。
游戏开发中的 Loop 应用场景
理解了循环的构成，关键问题是：哪些游戏开发工作适合做成循环？判断标准有四个——任务足够重复（至少每周发生一次）、结果能自动验证、Token 预算充足、工具链已接通。
场景一：CI 构建失败自动分诊。大型 UE5 项目的 CI 流水线经常因为各种原因挂掉——材质编译错误、蓝图引用丢失、着色器编译超时。传统方式是开发者手动查看日志、定位问题、修复、重新提交。用 Loop 可以做到：每天定时检查 CI 状态，发现失败后自动拉取日志，分析错误类型，尝试常见修复模式（清理中间产物、更新依赖、回退冲突提交），修复后自动触发重新构建。搞不定的才升级给人处理。
场景二：资产规范批量检查。游戏项目中，美术资产命名不规范、LOD 配置错误、材质通道缺失是常见问题。一个外循环可以每天扫描新增资产，对照项目规范文档检查命名、尺寸、格式、LOD 配置，不符合的自动生成报告并创建 Jira 工单。验证标准清晰：命名匹配正则、尺寸在阈值内、LOD 层级完整。
场景三：Bug 修复流水线。从 Jira 拉取标记为「已确认」的 Bug，按优先级排序，为每个 Bug 开一个隔离工作区，派实现 Agent 分析代码、起草修复、跑测试，验证 Agent 独立审核，通过后自动提交 PR。你每天早上看到的不再是 Bug 列表，而是待审核的 PR 列表。
场景四：跨平台适配回归测试。UE5 项目需要同时维护 PC、主机、移动端的适配。每次引擎升级或平台 SDK 更新后，需要跑一轮跨平台回归。循环可以自动在各平台构建目标上执行测试套件，收集崩溃日志和性能数据，生成对比报告。
内循环与外循环：先跑通再自动化
Loop Engineering 有一个关键区分：内循环（Agent 在一次对话中如何工作）和外循环（谁来启动 Agent、什么时候启动）。
内循环是基础。你给 AI 一个明确的完成条件，比如「把场景中所有使用旧版材质的 StaticMesh 替换为新版 Substrate 材质，替换后场景无报错且帧率不低于 55fps」，然后让它自己跑到达标为止。这对应 Claude Code 的 /goal 命令。
外循环是进阶。在内循环跑通的前提下，加定时触发（每天早上检查新增资产）、事件触发（PR 合并后自动跑测试）、或目标触发（迁移 200 个蓝图节点到新系统）。Claude Code 的 /loop 命令和 Codex 的 automation 原生支持提供了这些能力。
一条铁律：内循环没跑通之前，别碰外循环。如果 AI 连一次性任务都做不好，让它自动反复做，就是在自动化生产垃圾。正确的顺序是：先把 Harness 搭扎实（项目规范文档写清楚、验证钩子配好、权限设对），再用内循环验证可靠性，最后加外循环实现自动化。
游戏团队的落地建议
第一步：写好你的项目规范文档。这是所有后续工作的基础。无论是 CLAUDE.md、AGENTS.md 还是其他格式，核心是让 AI 在每次启动时都能快速理解项目的技术栈、命名规范、已知限制和决策历史。UE5 项目需要覆盖：蓝图组织结构、材质层叠标准、PCG 配置规范、打包发布流程。
第二步：建立可自动验证的交付标准。不是「代码质量好」这种模糊标准，而是「Unreal Automation Tool 全部通过、无编译警告、目标平台帧率达标」这种机器可检查的条件。好的完成条件有三个特征：可验证、具体、有边界。
第三步：从最小循环开始。不要一上来就搞「每天自动修复所有 Bug」这种大循环。从一个明确的、可验证的小任务开始——比如「自动检查新增蓝图是否遵循命名规范」——验证内循环能稳定交付后，再逐步扩大范围。
第四步：接入工具链。通过 MCP 连接器让 Agent 能访问 Jira、Git、CI 系统。游戏项目的工具链通常比普通软件项目更复杂（引擎编辑器、DCC 工具、版本控制、构建系统），打通这些环节是循环可靠运行的前提。
需要警惕的陷阱
Loop Engineering 不是万能药。几个需要认真对待的问题：
代码库成熟度门槛：Boris Cherny 单月 259 个 PR 的成绩，建立在他对 Claude Code 了如指掌、代码库按「适合 AI 干活」的标准收拾过的基础上。大多数游戏团队面对的是多年积累的遗留代码，文档缺失、测试不足。真正的门槛往往不是「会不会搭循环」，而是「代码库有没有达到能跑循环的状态」。
Goodhart 定律：完成条件一旦写成「测试通过、检查干净」，循环优化的目标就悄悄从「把事做对」变成了「让指标变绿」——放松断言、给 Mock 注水、用 try/catch 吞掉异常，都是它找得到的捷径。对游戏开发来说，这意味着循环可能生成「技术上通过测试但体验上完全不对」的内容。
理解债：循环产出越快，你没亲手做过、也没仔细看过的东西就越多。当产出速度超过审阅速度，瓶颈就从「做」挪到了「看」。在游戏开发中，一个没被认真审阅的材质修改可能破坏整个场景的视觉一致性。
LLM 的同质化盲区：写代码的 Agent 和检查代码的 Agent 都是 LLM，相近的训练数据意味着相近的盲区。第二个 Agent 能逮住低级错误，但一旦第一个 Agent 的整体方向就错了，两个模型很可能一起点头放行。这不构成真正的独立验证。
写在最后
Loop Engineering 的杠杆点，从来不在工具上，而在你对游戏开发工作流的理解深度上。两个人搭出一模一样的循环，结果可能完全相反：一个拿它在自己吃透的流程上跑得更快，一个拿它绕开「吃透」这件事本身。循环只奖励已经想明白的人。
从 Prompt 到 Loop，AI 工程方法论的四次迭代本质上是一部「人逐渐退场」的历史——但退场不等于淘汰。人的核心价值从「会操作 AI」变成了「会设计 AI 系统」。而系统设计、流程拆解、规则定义、异常边界，这些恰好是资深游戏开发者的原生能力。Loop Engineering 对游戏开发者不是威胁，是一次能力变现的窗口。现在正是理解这一范式、在自家项目中小范围验证的最佳时机。