通用编码代理已经能阅读仓库、修改文件并修复测试，但游戏同时存在磁盘上的项目和运行中的体验。代码正确，不代表镜头、输入、动画、存档或帧率正确。
真正有用的区别不是品牌，而是代理能否进入引擎与运行时，观察玩家实际遇到的状态，并用证据闭环。
快速阅读
核心要点
- 游戏代理的完成标准是可玩的结果，而不只是通过代码测试。
- 场景、素材、输入、时间行为和性能都属于必要上下文。
- 可靠流程逐级完成静态检查、引擎导入、运行测试、游玩与人工审核。
- 交付物应包含可复现命令、运行证据、已知限制和回滚方式。
重新定义游戏开发中的完成
通用编码代理主要操作代码、配置、测试与日志；游戏开发代理还要理解场景层级、素材引用、输入映射和运行时状态。
它不一定需要不同的基础模型，但需要引擎接口、可运行构建、观测工具和明确验收标准。
游戏需要六层上下文
任务意图、仓库、世界与场景、素材、运行时和验证证据共同构成上下文。任何一层缺失，都可能产生能编译却不能玩的改动。
按阶段查询必要信息，比一次塞入整个项目更安全，也更容易审查。
建立闭环验证
先定义可测场景，再检查实现、做最小改动、构建、启动、执行输入、观察结果并根据证据修订。
单元测试只能证明局部逻辑；截图、输入模拟、关卡测试、性能数据和目标设备检查覆盖不同风险。
何时使用通用代理或游戏代理
文档、构建脚本、局部重构和纯逻辑测试适合通用编码代理。跨场景、素材、生命周期、手感或性能的任务需要游戏感知能力。
从低风险任务开始，并把写入、发布、凭证和付费操作保留给人工批准。
用证据评估代理
评估任务成功率、首次可用率、返工时间、运行回归、性能预算和人工审核时间，而不是生成代码量。
一个可信交付应包含聚焦的 diff、复现步骤、运行截图或记录、预算测量、限制与简单回滚路径。
常见问题
游戏开发代理与编码代理有什么不同？
前者把场景、素材、引擎和运行时证据纳入完成标准。
通过单元测试是否足够？
不够。输入、时间行为、画面、存档和性能仍需运行验证。
应该先自动化什么？
从可回滚、验收条件明确且无需敏感权限的任务开始。
如何比较不同代理？
让它们完成相同任务，并比较可玩结果、证据质量、返工与成本。
资料来源与延伸阅读
- SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
官方研究或引擎文档，用于界定编码任务、场景系统、测试和性能验证。
- Godot Engine: SceneTree documentation
官方研究或引擎文档，用于界定编码任务、场景系统、测试和性能验证。
- Unreal Engine: Automation Test Framework
官方研究或引擎文档，用于界定编码任务、场景系统、测试和性能验证。
- Unity Manual: Profiling your application
官方研究或引擎文档，用于界定编码任务、场景系统、测试和性能验证。
下一步
