一、教程目标：读完这篇能完成什么

最近一轮行业实践的方向很清晰：不再只是”用模型写几段脚本”，而是把智能体接入引擎与美术工具链，让它参与原型制作、现有工程修改和发行运营。这类方案的通用形态是：一个大模型推理服务作为决策核心，通过工具调用通道驱动引擎编辑器、构建系统、录制与截图能力，形成一个”下达意图—执行操作—观察结果—修正方案”的闭环。

本教程的目标不是介绍某一次产品发布，而是把这套做法抽象成任何团队都能落地的工程流程。完成本教程后，你应当能够：

1. 判断哪些环节适合交给智能体，哪些必须保留人工把关，并写出明确的分工边界；
2. 搭建一套”意图描述—工具调用—运行观察—差异比对”的自动化闭环；
3. 让不具备编程背景的策划在受控环境下产出可试玩的原型工程；
4. 让智能体安全地修改既有工程，并把改动限制在可回滚、可验证的范围内；
5. 建立验证与验收标准，能判断”跑通了”和”跑错了”的区别；
6. 掌握常见问题（上下文溢出、构建失败、视觉回归误判、成本失控）的排查思路。

适合读者：客户端/引擎方向开发者、技术美术、技术负责人、发行与运营人员，以及正在评估 AI 辅助研发可行性的架构师。

二、适用场景与不适用的场景

适合接入的场景（特征是：目标可被明确描述、结果可被程序化判定）

• 玩法验证：把一个玩法描述快速转成可运行、可操作的关卡原型，用于内部评审；
• 工程内的局部改造：参数调优、UI 布局批量调整、资源引用修复、废弃接口替换；
• 重复性问题定位：编译报错、空引用、资源丢失、场景节点错挂等模式化缺陷；
• 素材与运营的初稿生产：投放素材文案与分镜草稿、玩家反馈聚类、多语言本地化初稿、UGC 内容的初步筛查。

不适合直接接入的场景（特征是：结果难以自动判定，或错误代价高）

• 核心战斗手感、关卡节奏等高度依赖主观体验的设计决策；
• 涉及线上账号、支付、数据合规的生产环境变更；
• 复杂性能瓶颈的根因定位（需要人工 profiling 判断瓶颈归属）；
• 美术风格定调与品牌视觉规范的定义。

原则：凡是”正确性可以被自动验证”的环节，优先交给智能体；凡是”正确性依赖人的审美与判断”的环节，智能体只做草稿和候选生成。

三、前置准备

3.1 环境与账号

• 一台可运行目标引擎的机器（原型阶段可用中端开发机；接入主流商业引擎后建议独立的构建节点）；
• 引擎编辑器与命令行构建能力：需要确认你的引擎支持无界面（headless）构建与批处理模式，这是自动化闭环的前提；
• 一款轻量级开源引擎用于快速原型（编译快、工程结构简单、便于脚本化生成场景）；
• 一款主流商业引擎的正式工程（用于验证既有工程修改）；
• 一个三维建模与渲染工具的脚本接口（用于资产批量导出、格式转换、批量命名规范检查）；
• 账号与配额：模型服务的 API 凭证、引擎相关账号的授权、CI 节点权限。建议为智能体使用独立子账号 + 最小权限，不要用个人主账号。

3.2 模型侧准备

• 具备较长上下文窗口的通用大模型服务（原型阶段的场景文件、日志、代码往往体积大）；
• 支持函数/工具调用（function calling）的接口形态，这是让模型”操作工程”而不是”描述操作”的关键；
• 支持流式输出，便于长时间任务中的进度观察；
• 推理服务可自建部署在云上的容器平台或函数类服务中，也可直接使用云上模型服务；上下文快照、素材、构建产物建议落在对象存储上，通过预签名地址传递，避免把大文件塞进对话上下文。

若团队已有云资源，可用通用云能力组合：对象存储存放资产与构建产物、消息队列承接长任务、容器平台跑智能体执行器、日志服务与监控告警观测任务链路、身份认证服务做权限隔离。这套组合与具体厂商无关，按需替换即可。

3.3 工程规范准备（最容易被忽略、但决定成败的一步）

智能体不是”更聪明的程序员”，它是在你提供的上下文里工作的。上下文质量差，输出质量一定差。因此接入前必须先做工程规整：

• 统一目录结构，明确”可写目录”与”只读目录”；
• 清理生成物（中间缓存、导入缓存）并纳入忽略清单，避免模型读到无关内容；
• 在仓库根目录放置一份机器可读的工程说明（引擎版本、脚本语言版本、命名约定、模块边界、构建命令），作为固定系统提示的一部分；
• 引入版本控制，确保每一次智能体改动都能被单独提交、单独回滚。没有版本控制的智能体接入等于没有安全网。

3.4 验收基线

在让智能体动手之前，先手工跑一遍并把结果固化下来：

• 一次成功构建的耗时与产物体积；
• 一次启动到主菜单的截图；
• 核心玩法的操作录像；
• 现有自动化测试用例的通过率。

这四项目标基线，是后续判断”改动是否引入退化”的唯一依据。

四、整体链路与数据流

策划意图（玩法描述 / 参考素材）
        │
        ▼
[意图结构化] ──► [任务规划] ──► [工具调用层 Engine Bridge]
                                      │
        ┌─────────────────────────────┼──────────────┐
        ▼                             ▼              ▼
   轻量引擎原型生成            商业引擎工程修改     资产工具链处理
        │                             │              │
        └──────────► [运行 + 录制 + 日志 + 截图] ◄────┘
                              │
                              ▼
                    [差异比对 / 规则判定]
                              │
                    ┌─────────┴─────────┐
                 通过                     未通过
                    │                     │
                    ▼                     ▼
                人工评审            修正建议回灌模型（重试上限 N）

关键设计点：判定环节不能依赖模型自评。必须由确定性程序（编译器、测试框架、截图比对脚本、规则检查器）给出结论，模型只负责”根据结论改什么”。

五、实施步骤

步骤一：把玩法意图结构化成机器可消费的输入

做什么：让策划按固定模板提交需求，而不是自由文本。

为什么：自由文本里充满隐含前提（”类似某款游戏的手感”），模型无法验证。结构化后，每一项都能对应到工程中的具体节点。

怎么做：模板至少包含：核心循环（玩家做什么→得到什么→再做什么）、操作输入映射、数值范围、胜负条件、UI 元素清单、参考素材路径、明确排除项。

注意：一定要写”排除项”。缺了排除项，模型会顺手实现你没要的系统，导致原型臃肿、评审失焦。

步骤二：在轻量引擎中生成可试玩原型

做什么：以步骤一的输入为提示，让智能体生成场景文件、脚本、预制体引用，并直接触发引擎构建，产出一个可双击运行的原型。

为什么：原型阶段的目标是验证玩法可行性，不是代码质量。轻量引擎编译快、工程文件是文本格式、便于模型直接生成与 diff，反馈周期可以压到分钟级。有实践称无编程经验的策划可在一到两天内拿到可试玩版本，这个数字成立的前提正是”反馈周期足够短”。

怎么做（伪代码，仅示意流程，非特定接口）：

task = structure_intent(raw_design_doc)      # 输出固定 schema 的 JSON
for round in range(MAX_ROUNDS):              # MAX_ROUNDS 建议 3~6
    patch = agent.propose_changes(task, context=project_snapshot())
    apply_patch(patch, writable_dirs=["/prototype"])
    result = engine.build_and_run(headless=False)
    if result.build_ok and result.starts_ok:
        shot = capture_screenshot(after_seconds=5)
        if visual_check(shot, expect="main_scene_loaded"):
            return success(patch, build_artifact=result.path)
    feedback = summarize_error(result.log_tail)   # 只回灌与失败相关的日志片段
    task = task.merge_fix_hints(feedback)
raise need_human_review(task, last_error)

注意：MAX_ROUNDS 必须设上限。不设上限的重试循环会持续消耗 token 并产生难以归因的改动堆叠。

步骤三：把工具通道接入主流商业引擎工程

做什么：为商业引擎工程建立一层”工具桥”，把编辑器的可编程接口包装成模型可调用的动作集合。

为什么：模型的输出必须落到确定性的、权限受限的动作上，而不是任意代码执行。动作集合越小、越明确，越可控。

建议的最小动作集（按需扩展，不建议一次性开放全部）：

动作	说明	风险等级
read_file	读取指定白名单目录内文件	低
search_symbol	全工程符号/引用检索	低
patch_file	对单个文件做限定范围的替换	中
run_build	触发编译并返回日志	中
run_playmode	以批处理模式运行指定场景	中
capture_frame	指定时间点截图	低
run_tests	执行已有自动化测试	低
export_asset	调用资产工具链导出/转格式	中
delete_* / publish_*	删除、发布类动作	默认关闭

注意：所有写操作必须走同一条路径——先在临时工作区生成 patch，通过校验后再落盘并自动提交到独立分支。禁止让智能体直接改动主干分支或生产环境工程。

步骤四：建立”运行—观察—修改”的闭环

做什么：把步骤二的循环从原型阶段复制到商业引擎工程上，但增加更严格的守卫。

为什么：商业工程的构建时间可能是原型的上百倍，且改动耦合面大。必须用”分层验证”控制成本：先语法/编译层，再场景加载层，最后行为层。

分层策略：

1. 编译层：只做编译，失败则立即返回错误行，不进入下一步；
2. 加载层：批处理模式加载目标场景，检查是否有缺失引用、空节点、脚本异常；
3. 行为层：运行预设输入序列（可用输入录制回放），采集日志与帧序列；
4. 视觉层：与基线截图做差异比对，超过阈值则标记为”待人工确认”，而非直接判失败（光照、动画时序会造成误判）。

注意：日志回灌要做裁剪。整份日志通常包含大量无关警告，直接塞给模型会迅速耗尽上下文。只回灌 error 与首个异常堆栈，是最有效的做法。

步骤五：区分两类改动场景

场景一：现有工程的局部修改

• 先让智能体做”只读分析”，输出改动计划（涉及哪些文件、每处改什么、影响面），人工确认后再执行；
• 一次只处理一个逻辑变更，禁止在一个分支里混入多个不相关改动；
• 改动完成后必须跑既有自动化测试，通过率不得低于基线。

场景二：新增独立模块/玩法

• 允许更高自由度，但必须约定模块边界：新代码只落在指定目录，不得修改既有模块的公共接口；
• 先生成接口定义与骨架，人工评审接口后再生成实现；
• 模块级测试由智能体同时生成，并纳入持续集成。

步骤六：发行运营环节的智能体参与

这一环节的模式与开发环节不同：不需要闭环执行，只需要批量生成候选 + 人工筛选。

• 投放素材：由智能体根据已确定的卖点与合规要求生成多版本文案与分镜草稿，产出统一命名与尺寸规范，再交设计审核；
• 玩家反馈整理：把评论、工单、社群反馈按”崩溃/卡顿/数值/引导/UI/内容期待”归类，输出高频问题清单与原始链接溯源；
• 本地化初稿：导出字符串资源，逐语言生成初稿，保留上下文与变量占位符，必须由母语者审校后入库，不可直接上线；
• UGC 初筛：按明示规则（违规内容类型、质量下限、重复性）做第一层过滤，把命中项与边界样本交人工复核。这里的关键是规则必须事先公示并留痕，避免形成不可解释的自动化决策。

六、关键配置说明

以下是通用配置项与其含义，取值需按自身工程实测调整（YAML 仅示意结构）：

agent:
  model_context_budget: 120000      # 上下文预算。留 20% 余量给输出，避免中途截断
  max_tool_rounds: 5                # 单次任务的工具调用轮次上限
  retry_on_build_error: 2           # 编译失败后的重试次数上限
  stream_output: true               # 长任务必须开启，便于观察卡点
guardrail:
  writable_paths:                   # 白名单。清单外一律拒绝写入
    - "Assets/Prototype"
    - "Tools/Scripts"
  readonly_paths:
    - "Assets/Art"
    - "ProjectSettings"
  deny_actions: ["delete", "publish", "git_push_main"]
  require_human_approval_for: ["patch_file"]   # 写操作需人工确认
  auto_commit_branch_prefix: "agent/"          # 强制落在独立分支
verification:
  build_timeout_seconds: 1800
  screenshot_diff_threshold: 0.05    # 阈值过小会大量误报，需按工程实际标定
  regression_min_pass_rate: 1.0      # 既有测试不得出现退化
cost_control:
  daily_token_limit: 2000000
  log_sampling_rate: 0.1             # 采样落日志，降低存储与噪声

配置风险点：

• writable_paths 过宽是最常见的隐患，务必从最小集合开始逐步放开；
• screenshot_diff_threshold 设得过严会让闭环反复”看起来失败”，掩盖真实问题；
• 日 token 限额是防止跑飞循环的最后一道闸门，不要省略。

七、结果验证：怎么判断”真的成了”

验证分四个层次，缺一层就可能把假象当成成果：

1. 可构建：在干净环境（清空缓存后）能完整构建成功。缓存命中下的构建成功不算数。
2. 可运行：能启动、能进入目标场景、无致命异常。以截图与启动日志双重确认。
3. 可回归：既有自动化测试通过率不低于基线；新增功能的自测用例全部通过。
4. 可评审：把”玩法意图—实际表现”对照表交给策划确认，包括操作是否响应、数值是否符合模板、UI 元素是否齐全。

另外建议记录三个过程指标，用于评估这套流程是否值得长期投入：单次原型从意图到可试玩的耗时、一次改动从提交到验证通过的耗时、人工返工率（被人工推翻的产出占比）。人工返工率如果长期高于一半，问题通常不在模型，而在工程规整度与意图描述质量。

八、常见问题与排查

现象	常见原因	排查思路
模型生成场景文件但引擎无法加载	引擎/脚本版本与模型认知的版本不一致	在系统提示中显式声明版本与目录约定；把”读取现有同类文件作为范例”加入上下文
反复在同一错误上循环	只回灌了错误摘要，缺少定位信息	回灌首个异常的完整堆栈与出错文件片段，而非末尾 N 行
改动”能跑但行为不对”	缺少行为层验证，只做了编译验证	补齐输入回放与断言；把可判定规则写进验收脚本
上下文很快被占满	一次性塞入整个工程或整份日志	改为按需检索；用符号索引替代全文；大文件走对象存储传引用
视觉比对大量误报	阈值不合理、存在随机性（粒子、时间相关动画）	固定随机种子与时间步；对不稳定区域做遮罩；提高阈值并保留人工确认环节
构建节点资源被打满	并发任务数无限制	限制并发、为长任务单独排队（可用消息队列解耦调度）
成本远超预期	无轮次上限、无日限额	收紧 max_tool_rounds 与日 token 限额；先用小样本压测
改动难以归因	多次改动混在一个提交里	一次一个逻辑变更 + 独立分支 + 规范提交信息

九、优化建议

性能：把验证做成分层流水线，编译失败不进入运行阶段；构建节点使用增量编译与缓存；并行跑互不依赖的场景验证。

安全：智能体执行器与业务网络隔离；凭据通过密钥管理服务注入，不写入工程文件与提示词；写操作全部经白名单与人工确认；禁止开放任意命令执行与任意路径写入；所有工具调用留审计日志（谁、何时、改了什么、是否通过验证）。

稳定性：所有长任务设置超时与轮次上限；失败任务自动落”待处理队列”而非静默重试；闭环逻辑本身要有单元测试。

可维护性：把工程说明、动作集定义、验收脚本、提示词模板全部纳入版本控制，与代码同等对待。提示词和动作集是会演进的，不纳管就无法复现历史结果。

成本控制：分级用模型——意图分析与代码生成用能力较强的模型，日志摘要、命名规范检查、格式转换等模式化任务用轻量模型；对高频重复任务做结果缓存。

流程规范：明确”智能体产出”与”人工定稿”的边界与署名规则，尤其在本地化与 UGC 初筛环节，需要可追溯的审核记录。

十、总结

把智能体接入游戏开发，本质不是”让模型替你写游戏”，而是把游戏研发中可判定的环节自动化，把判断权保留在人手里。教程的核心可归纳为四步：先规整工程与验收基线，再打通”意图→工具调用→运行观察→差异判定”的闭环，然后按场景区分改动策略（现有工程保守、新增模块放权），最后把智能体擅长的批量生成用在素材、反馈整理、本地化初稿与 UGC 初筛上。

值得继续关注的方向有三个：一是引擎侧自动化能力的标准化，越标准的工具接口越容易接入；二是视觉与行为验证的自动化程度，这是当前闭环中最依赖人工的一环；三是团队知识如何沉淀成智能体可复用的上下文资产，包括工程约定、历史缺陷模式与验收规则库。

建议的起步方式：选一个已经用手工方式做过一次的小型原型，完整走一遍本教程流程，用”耗时对比 + 返工率”量化收益，再决定是否扩展到正式工程。