AI 驱动的游戏开发生产力重构
AI驱动的游戏开发生产力重构 从单点生成到Harness工程闭环 AI驱动的游戏开发生产力重构以WorkBuddy、CodeBuddy、UnrealEngine项目实践为例重点不讲AI能生成什么AI如何进入可验证、可回滚、可沉淀的工程闭环 今天从几个真实问题开始 AI单点能力很强，为什么长任务还是经常失败？为什么通用Agent不能直接解决游戏开发？单点AIGC能力如何被工程化连接起来？为什么最终必须走到Harness Engineering？个人/小团队的生产力边界是否正在被重新打开？ 01AI单点能力很强，为什么长任务还是经常失败？ AI很强，但真实项目不只是单点任务 AI会生图、生模型、写代码、写方案单点效果已经足够惊艳游戏项目是长周期、多角色、多系统协作单点生成解决“有没有”工程闭环解决“能不能持续交付” 为什么Agent执行长任务容易出问题？ 长任务不是一次问答，而是连续状态管理上下文会变长、压缩、丢失、被覆盖任务目标、历史决策、失败原因很容易断层没有持久化的数据，在后续阶段极易丢失长任务需要“外接大脑” 长任务需要持久化 目标要持久化：写成任务文档规则要持久化：写成项目约束状态要持久化：写入进度和记忆结果要持久化：留下日志、截图、差异没有持久化，Agent只能临场发挥 Markdown AI时代的“工程合同”与“记忆库” 本质是什么？ 极简符号排版的纯文本。 为何是核心基建？人类看直观，大模型也易懂。版本控制精细追踪，告别二进制黑盒。 为何被Agent当作记忆中枢？聚焦内容，减少结构字符。文件即记忆，易于解析。 02为什么通用Agent不能直接解决游戏开发？ 为什么通用Agent不能直接解决游戏开发？ 通用Agent适合文本、网页、脚本、常规代码游戏开发不是纯文本工程UE里混合C++、蓝图、材质、动画、UMG、资产引用很多问题只有进入编辑器和运行时才暴露游戏开发需要专属工程现场 UE需要定制Harness范式 通用Agent负责执行能力Harness负责工程约束MCP负责接入游戏领域需求日志负责反馈证据版本控制负责安全回滚 03单点AIGC能力如何被工程化连接起来？P1浅水区 浅水区：AIGC最容易创造价值的地方 浅水区是低风险、低成本、快速验证适合做原型、概念、视觉方向、早期UI它能大幅降低试错成本但它还没有进入重型工程闭环所以要先用，但不能停在这里 WorkBuddy：先把想法跑起来 进入UE前，先低成本验证核心循环Web原型让想法变成可交互对象策划、美术、程序都能围绕原型讨论重点不是做成品，而是验证方向原型结果要继续收敛成工程任务 WorkBuddy使用Web快速原型验证 白盒到视觉方向 白盒截图可以快速生成概念参考概念图的价值是“定锚”美术风格、材质方向、UI氛围可以提前统一这一步适合快速发散和收敛但还不是可维护资产 WEB原型使用Stitch生成的UI 图像生成到3D资产 图生图、图生3D已经能快速给素材角色、道具、场景资产都能形成第一版 图像生成到3D资产 复杂结构仍然会粘连、穿插、糊成一团分件生成、后期组装更稳定生成素材还需进入工程管线 浅水区结论：单点生成解决“有没有” 有没有概念图有没有原型有没有角色和场景素材有没有UI方向但项目真正关心的是：能不能复用、维护、迭代 04为什么从Prompt Engineering到Context Engineering，最后必须走到Harness Engineering？ 三者关系：Prompt/ Context / Harness Prompt：把话说清楚Context：把背景给完整Harness：把AI放进可控流程轻量任务Prompt就能满足需求重型游戏开发需要Harness范式 Harness Engineering完善的是工作环境 规则：什么能做，什么不能做(rule skills)工具：通过确定接口执行(MCP)验证：用日志、编译、运行结果判断回滚：每次修改都能退回记忆：把经验沉淀成下一轮上下文 05单点AIGC能力如何被工程化连接起来？P2深水区 进入深水区：AIGC怎么变成工程能力？ 浅水区看效果深水区看结构真正难的是接入UE、DCC、资产规范和版本控制每一步都要有任务边界、执行接口和验证证据这里才是Harness的价值区 版本控制：AI修改工程文件时的安全绳 只要AI能改文件，就必须默认它可能改坏每轮任务都要有diff每个阶段都要能回滚SVN / Git不是程序员专属工具它是AI参与项目的底层安全机制 CodeBuddy：从需求到受控执行 不让Agent直接自由发挥先Plan：拆任务，看影响范围再Rules：读取项目规范和禁止事项再Execute：修改代码、脚本、配置、文档最后Review：看diff、日志、运行结果 UEEditorMCP：把Unreal Editor接进AI工程现场 UE不能只靠文本理解MCP把编辑器能力包装成稳定接口AI通过搜索、看schema、执行动作来操作UE日志、缩略图、资产diff让结果可观察它的价值不是“能操作”，而是“能稳定接入现场” 蓝图节点自动布局&注释 日志、截图、diff：AI验证闭环的证据链 没有日志，AI只能猜有日志，AI才能定位真实错误截图能补充运行时状态diff能说明到底改了什么日志、截图、diff合起来，才是可验证结果 AI全自动Debug 启动引擎>运行游戏>获取LOG >修复或输出结论 资产管线：规则明确的重复工作最适合AI 命名、路径、通道、材质参数都是规则人工维护容易漏，AI适合按规则补齐SP / PS / Figma / UE都可以成为Harness节点关键是先定义数据结构和验收标准管线价值高于一次性素材生成 GitHub的用法变了：参考设计后改造 过去：找到项目，clone，安装，照教程用现在：让AI读架构、读接口、读测试、读限制提取可迁移的设计模式按当前项目规则裁剪和重写开源项目变成AI时代的工程范式库 06为什么OpenClaw、Hermes Agent都开始重视记忆？ 为什么Agent系统越来越重视记忆？ 长任务需要跨会话状态项目协作需要沉淀历史决策失败经验需要被下一次复用记忆不是聊天记录，而是持续协作能力没有记忆，Agent每次都像新人入职 MemoryMCP项目：把项目经验变成可复用资产 定位：跨会话项目记忆保存事实、决策、观察、任务节点、错误摘要、交接信息Markdown是真源，SQLite是索引普通Agent只用memory_read / memory_write高级维护交给CLI：重建、诊断、备份、压缩、治理 团队记忆不是个人偏好记忆 个人记忆：偏好、习惯、沟通方式Agent记忆：当前任务、执行过程、失败修复项目记忆：规则、决策、资产规范、坑点、交接信息团队真正需要的是项目记忆它必须可版本化、可审查、可继承 开发自循环：AI如何越做越稳 开始任务：读取项目记忆和规则执行任务：CodeBuddy按Plan修改验证结果：UE /日志/ diff提供证据失败处理：回滚并记录原因成功收尾：把新规则、新坑点写回记忆 07这是否意味着个人/小团队的生产力边界被重新打开？ 这是不是“用爱发电”的时代到了？ 个人达到过去团队才能达到的生产力短期热情也能支撑相对大项目个人能调用更完整的工程能力AI降低了原型、资产、工具开发的门槛流程和验证能力变得更为重要 个人/小团队的落地路线 第一步：WorkBuddy快速实现低成本原型第二步：版本控制第三步：搭建Harness范式开发环境第四步：AIGC快速占位第五步：打通开发自循环启动开发飞轮 MemoryMCP HarnessEngineering：把AI能力变成可信交付系统 从Agent到工程现场用Harness组织规则、工具、资产与权限 从结果到证据链用日志、截图、diff、回滚判断可信