Unity客户端_AI开发工作流

客户端 AI 开发工作流实践：从辅助编码到全流程托管

一套让 AI 负责实现、留痕和自我纠偏，人负责体验、方向与最终风险把关的客户端研发工作流。

发布项	内容
摘要	这篇文章整理了一套客户端 AI 开发工作流：AI 负责实现、检查、归档和沉淀，人负责需求判断、体验把关和最终风险控制。
适合读者	游戏客户端开发、技术负责人、正在把 AI 接入研发流程的团队。
关键词	AI 编程、客户端开发、Unity、工作流、代码评审、自动化、质量保障。

工作演示

开场：真正变化的不是写代码更快，而是责任边界变了

这几个月，我在客户端开发里最大的变化，不是让 AI 帮我补几段代码，而是把完整开发链路交给 AI 推进：写代码、改代码、跑检查、补文档、留记录，都尽量放进同一套工具流里。

我的角色从“亲手实现”变成“定义什么是对的”：审 spec、定交互方向、看玩家体验、检查风险点、确认最终产出。发现问题时，我也尽量不自己动手改，而是把问题说清楚，让 AI 回到同一条链路里修。这样做的价值不只是省时间，更重要的是每一次修复都会留下痕迹，后续可以继续沉淀成规则。

换成客户端视角，这套工作流关注的不只是逻辑有没有跑通，还包括 UI 状态、资源引用、动画和音效触点、弱网和断线恢复、不同机型表现、包体和热更新风险。AI 可以写实现，但玩家视角和体验判断仍然要由人兜底。

一、日常工作流：一个客户端任务从开坑到归档

我现在会把一个客户端任务看成一份持续更新的 spec 加一条 checklist。spec 写清楚需求、交互、状态流转、资源依赖和验收标准；checklist 记录推进状态。AI 围着这份文档工作，人只在关键节点做决定。

阶段	AI 做什么	人做什么
入池	创建任务文档、拉工作区、整理当前上下文。	确认任务边界和优先级。
理解旧实现	读取旧 UI、玩法逻辑、配置表、资源引用，反向生成模块说明。	补充业务意图和玩家体验要求。
出方案	基于现有客户端框架给出多个接入方案，列出风险和阻塞项。	选择方向，明确交互、表现和验收口径。
审文档	用子 agent 检查 spec 是否完整，字段、资源、状态和文字是否对齐。	批注体验问题、遗漏场景和高风险路径。
编码	实现 UI、状态流转、资源加载、埋点和自测，并同步 checklist。	不插手代码，只看阶段性产出。
审代码	多 agent 从业务正确性、spec 一致性、客户端质量三个视角并行 review。	重点看玩家路径、付费和奖励风险。
验收	跑编译、基础自动化、资源检查、必要的真机或模拟器冒烟。	人工体验关键路径，决定是否能合入。
归档	同步最终 spec、沉淀经验、生成提交说明和工作记录。	审核提交内容，并保留最后一道合入闸门。

这里的关键点是：spec 始终是中心。每个 skill 都读写同一份文档，跨 session 不靠脑子记；审查卡在两个不可逆点前：编码前审方案，合入前审代码。

二、为什么是 100%，不是半自动

很多人用 AI 的方式是“我写一半，AI 写一半”。短期看，这样最快；但在客户端项目里，半自动会带来两个长期问题。

1. 代码和资源风格容易割裂

客户端代码经常和 prefab、动画、配置、图集、字体、音效、埋点一起变化。人改一段、AI 改一段，很容易出现两套命名、两套生命周期处理、两套资源释放习惯。最后不是更好维护，而是更难读。

2. 周边信息会和实现脱节

客户端逻辑不是孤立的。一个按钮为什么这样置灰、一个奖励弹窗为什么要等动画播完、一个活动入口为什么需要读某个配置，这些都应该落在 spec、提交记录和经验规则里。AI 下一次接手时，靠这些信息恢复上下文。

如果人绕过工具流手动改了 UI、资源或配置，文档不会自动更新，日志也不会自动留痕。人看到旧文档会怀疑它过期，AI 看到旧文档却会当真。于是下一次它可能基于错误前提继续设计，问题就从“一次修改没同步”变成“后续任务都被带偏”。

所以我更倾向于把实现动作完整交出去。人定“什么是对的”，AI 负责把它实现对；人审体验、风险和方向，AI 负责在同一条链路里修正。

三、用 AI 配置体系保证当下产出质量

要让 AI 写客户端代码不出格，不能靠每次口头提醒。提醒是人在做，人不在就失效。更可靠的方式，是把约束沉淀成文件，让 AI 每次启动自动加载。

组件	作用	客户端场景示例
Rules	约束 AI 的决策倾向，影响它选择什么方案。	先搜现有组件；只做局部修改；字段、配置、文档同步；异步回调考虑界面销毁。
Skills	封装重复流程，把常见操作变成可复用命令。	/client-spec-from-code；/ui-review；/asset-check；/code-review。
Hooks	强制拦截和埋点，AI 无法绕过。	禁止裸提交；拦截危险删除；记录构建、资源检查和测试结果；统计成本和产出。

Rule 和 Skill 本质上仍然是提示词，遵守率不是 100%。AI 有最短路径倾向：能直接改完的事，如果没有强约束，它未必会主动走完整流程。Hook 的价值在这里：它挂在工具调用路径上，只要 AI 调工具就必然经过。

• PreToolUse：动作执行前介入，用来拦截危险操作。
• PostToolUse：动作完成后记录，用来做埋点和审计。
• Stop：session 结束时收尾统计，比如成本、产出和未完成项。
• SessionStart：启动时注入上下文，比如待办、风险提示和项目规则。

对客户端来说，hook 既是减速带，也是可观测性基础设施。没有这些记录，你很难知道 AI 是不是跑了资源检查、有没有跳过构建、是否真的按 spec 更新了所有入口。

四、用自动化服务防止体系长期腐化

把代码交给 AI 以后，最怕的不是某一次写错。单次错误能 review、能修。更怕的是体系悄悄腐化：某个 hook 从来没触发、某个定时任务挂了一周、某条教训昨天刚踩过今天又踩。session 内的约束管不了长期，所以需要持续运转的维护机制。

沉淀闭环：被纠正一次，下次不再犯

我会把“AI 被纠正”的地方当作最有价值的训练信号。每天的 memory-archive 会扫描活跃 session，从对话里提取值得长期记忆的内容，例如某条资源规则没遵守、某个 UI 状态漏处理、某个验收场景反复遗漏。

自动提取之后不会直接写进正式规则，而是进入人工 review。第二天我用 /memory-review 逐条判断：哪些升级成 rule，哪些应该做成 hook，哪些只是一次性问题不需要固化。自动负责不漏，人负责不滥。

任务	调度	客户端侧作用
memory-archive	每日	从对话和修复记录里提取可沉淀经验，生成待审核规则。
health-check	每日	检查 hook、定时任务、构建脚本和自动化服务是否静默失效。
nightly-client-review	每日	自动审当天客户端改动，重点看 UI 状态、资源引用、生命周期和高风险逻辑。
asset-reference-scan	每日或合入前	检查资源引用、丢失图片、冗余资源、热更新清单和包体变化。
device-smoke	按需或夜间	跑关键机型、分辨率、弱网和断线恢复的冒烟验证。
archive	每个任务结束	自动记录产出、提交、风险和经验，减少周报和复盘成本。

这套闭环能转起来，靠一个习惯：每个 skill、rule、hook 都尽量留下可观测日志。没有日志，自动化就是黑盒；有了日志，后续才能做审计、复盘和自我进化。

五、几个最有用的工具实践

pool：让一个客户端任务有始有终

pool 工作流把任务从开坑、出 spec、审方案、写代码、审代码、验收、归档串起来。它的价值不是某个单点命令，而是让任务状态不散落在聊天、脑子和临时文件里。

code-review：多 agent 加多模型互审

客户端 review 我通常会分成几个视角并行跑：一个看业务正确性，例如奖励、入口、状态推进；一个看 spec 一致性，例如字段、配置、文案、埋点；一个看客户端质量，例如生命周期、异步取消、资源释放、性能和异常分支。不同 agent 独立上下文，不共享假设，能降低单一路径推理带来的盲区。

md-review：文档评审集中处理

评审 spec 时，我会在文档里一次性批注所有问题，再交给 AI 统一分析和修改。相比来回切窗口问一句改一句，批注式评审更适合客户端需求，因为交互、表现、文案和验收项往往要一起看。

debug-panel：让非技术同事也能驱动修复

客户端 bug 很多来自测试、策划或运营体验。以前链路是截图、发消息、开发复现、开发修复、再让测试验收。现在可以让非技术同事在 debug-panel 里截图提 bug，AI 自动定位相关模块，修复后输出验收步骤。开发从大量转述和复现里解放出来，只需要看最终产出和高风险变更。

client-env：用自然语言处理联调状态

联调时经常要切换账号状态、模拟活动阶段、清本地缓存、触发新手流程、切弱网、重置红点和引导。把这些动作封装成工具后，可以用自然语言让 AI 准备测试现场，减少“为了复现一个状态先手动点五分钟”的损耗。

六、遇到的问题：效率提升不是免费的

工作流维护成本会上升。为了让体系越跑越顺，需要处理自动化推送的记忆待办，检查日报里有没有可复用的社区实践，也要持续观察哪些流程本身需要优化。这些都是业务开发之外新增的工作量。

角色也会从深度专注转向广度调度。以前是一段时间盯一块代码，现在可能同时看几个窗口：一个在生成方案，一个在修 UI，一个在跑构建，一个在等 review。吞吐上去了，但注意力被切碎，这是必须提前接受的代价。

还有信任滑坡。AI 越可靠，人越容易审得松。尤其在客户端，很多问题不是编译能发现的：按钮手感、动画节奏、弱网体验、机型适配、热更新边界、付费链路和奖励展示，都需要人站在玩家视角重新走一遍。体系越完整，越容易诱导你放手；但最后那 1% 的风险不会因为你信任它就消失。

七、下一步改进方向

• 完善 debug-panel：支持批量 bug、优先级排布、修复后自动回归和可视化进度，让测试和策划从“提了等结果”变成“提了能跟进，改完能直接验”。
• 接入 PR 和 issue 流程：自动 review 发现问题后开 issue，AI 领取修复并提交 PR，人只在最终合入前把关。
• 加强客户端自动验收：把截图 diff、关键路径录屏、包体变化、资源引用、帧率和内存波动纳入自动报告。
• 接入飞书任务流：让需求来源、状态变化、临时补充和最终归档全程有痕，不再靠人记。

结语：让 AI 跑完整链路，但最后的判断仍然在人

这套工作流最重要的变化，是把“AI 帮我写代码”升级成“AI 在规则、工具和日志里完整推进任务”。对客户端开发来说，真正值得托管给 AI 的不是某一段实现，而是从理解需求、形成方案、实现、自查、留痕到沉淀经验的整条链路。

但这不等于人可以退出。客户端面对的是玩家体验，很多判断无法只靠代码静态分析完成。人应该从执行细节里退出来，把注意力放在更高价值的位置：体验是否顺、风险是否兜住、方向是否正确、最终是否值得发布。

最后补一句：每个团队的项目结构、工具链和风险点都不同，这篇文章提供的是一套实践思路，不建议原样照搬。更好的做法，是先选一个低风险客户端模块试跑，把能留痕的地方先留痕，把反复纠正的地方沉淀成规则，再逐步扩大范围。

注：本文由原始分享文档整理改写而成，已将叙述重点调整为客户端研发视角。发布前建议结合团队实际工具链和内部规范再做一次人工审阅。