想做个小游戏或者练练强化学习，卡住的地方往往不是「AI 会不会写代码」，而是需求拆不细、训练环境跑不通、跑出来不收敛还不知道先查哪。这篇按做游戏的顺序给一套可执行的路径，也标注哪些环节不该交给 AI。
想做个小游戏或者练练强化学习，卡住的地方往往不是「AI 会不会写代码」，而是需求拆不细、训练环境跑不通、跑出来不收敛还不知道先查哪。这篇按做游戏的顺序给一套可执行的路径，也标注哪些环节不该交给 AI。
下面这套流程分两半：前半段是怎么让 AI 帮你把游戏从想法推到能玩的版本，后半段是怎么把强化学习训练真正跑起来。两半共用的原则只有一个——每次只往前推能自己验收的一小步。哪一步你没法判断对不对，就不要让 AI 批量生成。
先定范围：这个小游戏和这次训练到底要什么
动手前先做一件事：把目标拆成三层，玩法原型、可玩版本、训练或上线。让 AI 参与的，永远是你已经能验收的那一层。玩法原型阶段你自己都不确定好不好玩，AI 生成再多代码也只是把不确定放大。可玩版本起，才值得让它帮你补样板逻辑。
| 环节 | 适合交给 AI 的活 | 建议自己拿主的活 |
|---|---|---|
| 原型期 | 脚手架代码、样板逻辑、占位素材 | 玩法取舍、手感、要不要继续做 |
| 可玩期 | 数值草案、关卡草稿、文案 | 性能瓶颈定位、架构分层 |
| 训练期 | 环境包装代码、日志与绘图脚本 | 奖励函数设计、评测口径、超参决策 |
- 工具按环节挑类型，具体有哪些去 /ai-nav/category/ai-gameAI 游戏工具分类 和 AI 编程工具分类（/ai-nav/category/ai-coding） 翻，别凭记忆点开一个就用。
- 遇到不熟的术语，比如策略梯度、奖励塑形，先到 基础词条（/ai-dict/category/basics） 和 前沿词条（/ai-dict/category/frontier） 对一眼再继续，省得把 AI 的错解当成常识。
- 把「不做什么」也写下来。小团队最容易犯的错，是让 AI 顺手把渲染、网络同步、打包全改了，结果回滚都难。
用 AI 推开发：一条不容易翻车的循环
和 AI 协作最容易失控的地方是改动范围。一次只让它改一个文件或一个函数，并要求它给出改动理由和你该怎么验证。理由写得含糊，通常说明它自己也没想清楚，这时宁可让它重写一遍小改动。
- 固定循环写、跑、看报错、贴回。把完整报错、相关代码片段、你期望的结果一起给它，别只丢一句「跑不起来」，信息越少它越容易瞎猜。
- 每块一提交每完成一小块就自己提交一次版本。AI 改坏的代码靠版本回退，别指望它自己想起来之前写的是什么。
- 按需验证它给的每条改动都问一句「怎么判断这条生效了」。答不上来的，当成没写。
什么情况下不适用：涉及引擎特定版本行为、物理与渲染细节、平台打包问题时，AI 给的答案经常是过时的，必须以你本机实测为准。手感调优、架构取舍这两类，本质上是你比它更懂自己的项目，别交出去。
强化学习落地：环境先跑通，再谈训练
顺序不能反：先让环境能被随机动作跑满若干回合且不报错，再写训练循环，最后才调超参。很多人一上来就搭训练框架，结果报错分不清是环境问题还是算法问题，一卡好几天。
- 随机种子
- 固定下来，让同一份代码两次运行的结果可比。
- 观测与动作空间
- 写清楚每个观测字段从哪来、动作取值范围是多少，别让观测里混进未来信息。
- 奖励函数
- 先写成能把好行为和坏行为区分开的最小版本，再加分项。
- 回合上限
- 给一次完整回合设时长或步数上限，防止环境卡死时训练还在空转。
奖励函数先最小化。一上来堆一堆加权项，出问题根本没法归因——你只知道分数不对，不知道是哪一项在捣乱。什么情况先别上强化学习：规则明确、状态少、能靠搜索或写死逻辑解决的问题，用监督学习或纯规则更省事，硬套强化学习只会把周期拉长。
不收敛时的排查顺序（照这个顺序走）
训练曲线难看，大多数人第一反应是调超参，其实这往往是最不该先动的一步。按下面的顺序走，能省下大量无效试错。
- 第一查环境：同一策略跑两次结果差异是不是过大、回合是不是提前结束、观测里有没有混进不该有的信息。
- 第二查奖励：把每个分项单独打印出来，看是不是某一项一直给常数，或者奖励被某条捷径刷满。
- 第三查超参：学习率、批大小、并行环境数一次只动一个，动完至少跑够能看出趋势的回合数。
- 第四查评测口径：训练曲线好看但实际表现差，多半是评测用了不同种子或不同难度，别急着改模型。
算力、成本与可复现：别在最后一天才发现钱不够
训练前先估算：需要多少并行环境、跑一轮大概多久。租卡和按量推理的价差口径一直在变，去 算力平台（/compute/platforms） 和 价格指数（/compute/price-index） 看当时的数字，别拿印象里的旧价做预算。
| 要存的东西 | 为什么 | 不存的后果 |
|---|---|---|
| 环境版本与依赖清单 | 换机器还能跑起来 | 复现时依赖冲突，重装半天 |
| 随机种子 | 结果可对照 | 曲线对不上，无法判断改动是否有效 |
| 训练脚本与配置 | 一次改动能追溯到源头 | 只留权重，下次复现很难受 |
| 评测脚本 | 训练和评测口径一致 | 曲线好看但实际表现差 |
小团队常见做法是先拿小规模跑通全流程，再决定要不要加卡。规模上去之前，先确认瓶颈在算力还是在自己的奖励设计——多数时候是后者。只保存模型权重、不存环境和种子，是复现失败最常见的原因。
下一步先把自己项目的目标和工具类型记下来，再对照站内分类翻一遍，看看有没有更合适的替代；价格和方案口径以站内当时页面为准。→常见问题
完全不会写代码，能用 AI 做游戏开发和强化学习吗？
能做原型和占位素材，但训练这一段基本绕不开读日志和改代码。务实的路径是先拿 AI 学基础语法与环境配置，把「能看懂报错」当作第一道门槛；如果你只是想做可玩的小游戏，可以先只做开发那部分，强化学习往后放。
强化学习一定要自己租显卡吗？
看规模。环境简单、观测维度不高的小任务，普通机器或按量租卡就能跑；只有并行环境多、单轮耗时长的时候才需要长期租卡或签整机。具体价格和可租规格随时会变，去 /compute/gpu-rental 和 /compute/price-index 核对当时的数字再决定。
训练出来效果差，是模型不行还是我写得不对？
多数情况下先怀疑奖励函数和评测口径，而不是算法本身。按「环境是否稳定 → 奖励各项是否合理 → 超参是否只动了一个 → 评测是否同一套标准」的顺序查一遍，往往比换模型更快找到问题；实在都排除了，再考虑换算法或加算力。
