1. 用 Codex 做游戏我为什么先折腾 Agent Skill最近我把 Codex 当主力开发工具做了一款横版小游戏真正让开发流程跑起来的不是什么玄学提示词而是整整十个 Agent Skill。如果你也想用 AI 做游戏开发又觉得“一问一答式”的编程助手总是在写好代码和写坏代码之间反复横跳那这套组合足够帮你搭起一支虚拟团队。先说结论Codex 这类 Coding Agent 的底层能力已经够强它缺的不是“聪明程度”而是“专业分工”。游戏开发是一个天然需要多角色协作的领域策划、程序、美术、音频、UI、测试、性能、构建、版本管理每个环节都有完全不同的上下文和输出规范。如果你把所有要求都塞进一段对话里模型很容易迷失上一秒还在写战斗逻辑下一秒就开始帮你改 UI 字号最后什么都没做好。Agent Skill 解决的就是这个问题。它把某个岗位的职责、流程、输出规范、参考示例打包成一个可复用的技能包。开新项目时我只要告诉 Codex“按这套技能组来工作”它就能在不同阶段切到对应岗位的心智模型写玩法时像策划写逻辑时像主程跑测试时像 QA。这篇文章会把我在游戏项目里沉淀下来的十个 Skill 全部拆开从职责设计、文件结构到实际触发指令尽量做到你拿过去就能用。这件事适合谁独立游戏开发者、想做小游戏但不会系统拆解的编程新手、以及想用 AI 改造现有工作流的游戏团队。你不一定需要多深的编程底子但你得愿意花半小时把技能包建好——这半小时的投入换来的是一整个开发周期里不再重复解释需求的轻松。2. Agent Skill 到底是什么和普通提示词、Agent 有什么区别在把十个 Skill 亮出来之前我先把 Agent Skill 的机制说清楚。很多人会把 Agent Skill 理解成“一段更长的提示词”这个理解不准确实际用起来会吃大亏。2.1 Skill 的三件套结构一个 Skill 本质上是一个目录里面通常有三样东西SKILL.md技能的说明书包含技能名称、职责描述、使用场景、工作流程、输出规范、注意事项参考文件比如代码模板、设计文档样例、数值表格式、资源路径约定示例产物一个或几个“标准答案”让模型知道输出长什么样。Codex 在运行时会扫描这些技能包当你下达的任务和某个技能的描述匹配时它会把对应目录里的内容加载进上下文。也就是说Skill 不是每时每刻都占据对话窗口而是“按需调用”。对比一下普通提示词你每次开新对话都要把需求重写一遍还很容易漏掉关键约束。Skill 则是一份持久化的岗位说明书项目里的任何一次调用都能复用同一套规范不会出现“上次说的规则这次忘了”的情况。2.2 Skill 和 Agent 的分工再聊一个很多人问的问题Skill 和 Agent 到底啥关系我的理解是Agent 是“干活的人”Skill 是“这个人掌握的技能”。同一个 Codex Agent可以同时装载策划、开发、测试等多个 Skill反过来同一个 Skill 也可以被不同 Agent 使用。这就像你招了一个全能程序员他脑子里装着多种工作方法拿需求文档时用策划思维写代码时用工程思维提测时用测试思维。Agent Skill 就是把“切换思维模式”这个动作显性化、模块化而不是靠你在对话里一遍遍提醒。用游戏开发来打比方Agent 是那个坐在工位上的开发者Skill 是他工位上贴着的一张张流程卡。不贴流程卡他可能凭感觉干活贴了流程卡他每一步都知道该遵循什么规范。2.3 为什么游戏开发特别需要这套机制游戏开发相比普通 Web 开发有一个很明显的差异上下文碎片化严重。策划文档、场景数据、美术资源、音效文件、构建脚本这些内容散落在不同目录格式完全不一样。你不可能把整个项目都塞进模型上下文但你又希望模型在每个环节都表现得像经验丰富的从业者。Skill 在这里扮演的是“导航器”。它不会把所有文件都读进来只告诉模型这个岗位要关注哪些目录、遵循什么规范、产出什么格式。比如美术 Skill 会指向assets/sprites目录并告诉模型“调色板只能使用 16 色”测试 Skill 会指向tests/目录并规定“每个缺陷报告必须包含复现步骤、预期结果、实际结果”。这样 Codex 每次切换到对应岗位时拿到的都是最相关的信息。一句话总结普通提示词是“一次性叮嘱”Agent Skill 是“可复用的专业流程”Agent 是“执行者本体”Skill 是“执行者身上的能力包”。3. 十个 Skill 的团队骨架一个人也能跑完整条游戏管线有了概念基础我直接上我实际在游戏中维护的十个 Skill。它们的名字和职责如下表Skill 名称对应岗位核心职责典型触发场景game-designer策划输出玩法文档、设计最小可玩循环、数值平衡项目启动、玩法调整core-programmer主程搭建游戏主循环、状态机、核心战斗逻辑开始写代码、重构核心系统level-builder关卡策划生成关卡数据、配置敌人/物品/出生点新增关卡、调整难度曲线pixel-artist美术生成像素画、精灵图、图集坐标、调色板缺美术资源、批量占位图生成sound-designer音频用代码合成音效、BGM 片段、音量规范缺音效、需要程序化音频ui-craftspersonUI 开发设计界面布局、交互状态、无障碍基础写菜单、HUD、对话框qa-tester测试生成测试用例、冒烟测试、缺陷报告玩法可跑后、提测前performance-tuner性能优化分析帧率/内存/GC、定位性能瓶颈画面卡顿、加载缓慢release-engineer构建/发布版本号管理、打包脚本、发版检查清单出包、上架 itch.io/Steamproducer项目管理拆解任务、维护路线图、跟进进度每次迭代开始、每日规划之所以是这十个而不是更多是因为游戏开发最核心的管线刚好被这个组合覆盖策划把玩法定义清楚程序把原型跑起来美术和音频把内容填上UI 把操作界面理顺测试保证质量性能优化保证体验发布工程把东西送出去项目管理保证整个过程有序推进。这套骨架里没有“网络联机”。原因是大多数独立游戏和小游戏项目一开始根本不需要联机先把单机体验做扎实更重要。需要联机时再单独拆一个 network-programmer Skill 进去就行——Skill 体系的好处就是可插拔。在实际运行时我不会一次把十个 Skill 全激活而是按阶段点名。比如原型期只用到 game-designer、core-programmer、pixel-artist、sound-designer进入打磨期才加 ui-craftsperson、performance-tuner准备上线前再叫 release-engineer 和 qa-tester。协作指令大概长这样使用 game-designer skill 审阅当前 GDD输出最小可玩循环清单 然后切换到 core-programmer skill按清单实现战斗原型 最后请 pixel-artist skill 为原型生成一套 16 像素占位精灵图。Codex 会按顺序处理每个 Skill 的 SKILL.md 会告诉它该读哪些文件、产出放哪里。这就像你分别跟策划、程序、美术说了三句话而不是让一个人同时干三份活。4. 五个创作类 Skill从玩法文档到能跑的原型这五个 Skill 解决的是“把游戏从想法变成可玩版本”的问题也是整个体系中更新最频繁的部分。4.1 game-designer先做减法再做加法游戏开发最常见的翻车点是玩法定义太散。我见过不少 AI 辅助项目对话里全是“加一个跳跃”“加一个冲刺”“加一个二段跳”最后做出来的东西像一个功能堆砌的 demo没有任何取舍。game-designer 这个 Skill 的作用就是强制 Codex 先输出一页纸的玩法定义而不是直接跳到代码。它的 SKILL.md 长这样--- name: game-designer description: 游戏玩法设计、GDD 撰写、数值平衡 when_to_use: 项目启动、玩法大幅调整、需要输出设计文档时 --- # 职责 - 输出一页纸 GDD包含核心玩法、胜利条件、失败条件、玩家操作 - 定义最小可玩循环玩家做什么、系统怎么反馈、下一步挑战是什么 - 数值设计必须给出具体表格禁止写“适当调整”这类含糊描述 # 输出规范 - 文档写入 docs/game-design.md - 所有数值用 Markdown 表格呈现 - 每个玩法点都要标注“保留/待验证/砍掉”实际用的时候我会对 Codex 说“启动新项目用 game-designer skill 输出一份一页纸 GDD玩法核心是‘躲避敌人并收集宝石’目标平台是 PC操作方式键盘。” 它生成的内容会比裸提示词规整得多关键是有“待验证”这一栏这能时刻提醒自己哪些设计还没经过实际手感检验。一个很重要的心得策划 Skill 一定要逼它区分“核心循环”和“外围系统”。很多 AI 生成的 GDD 动不动就写装备系统、技能树、剧情分支但一个原型期根本不需要这些东西。game-designer 的作用就是把需求砍到最小等核心循环好玩了再逐步加。4.2 core-programmer用状态机组织游戏逻辑core-programmer 是整个团队里最重要的 Skill没有之一。它决定了 Codex 写出来的代码是“能跑但一改就崩”还是“结构清晰、可以长期维护”。我给它定义的职权范围是主循环、状态机、输入处理、核心玩法逻辑。它必须遵守几条硬规则--- name: core-programmer description: 游戏主循环、角色状态机、核心玩法逻辑实现 when_to_use: 实现玩法逻辑、重构核心系统、排查核心 bug 时 --- # 编码规范 - 游戏状态用 enum 定义禁止散落字符串 - 输入处理独立成模块逻辑层不直接读取按键 - 核心代码必须添加关键注释为什么这样写而不是写什么 - 每次改动后更新 docs/architecture.md 中的系统关系说明 # 输出要求 - 先说明改动方案再贴代码 - 如果改动超过 200 行必须拆成多次提交实际运行中我会这样下达任务“用 core-programmer skill 实现角色三态状态机Idle、Run、Jump跳跃时保持水平方向惯性落地后自动回到 Run 或 Idle。” 状态机的好处是后续加新动作非常方便比如加一个 Attack 状态只需要在 enum 里加一项再补充状态切换条件。如果一开始就让 AI 用散落的布尔变量管理角色行为后面几乎一定会出现“在空中跳跃却没抬头”“攻击时还能移动”之类的问题。这里还涉及一个我在项目里被坑过的点同一段逻辑被 Codex 在不同会话里以不同风格反复重写。解决办法是在 core-programmer 目录下放一份samples/state-machine.cs示例文件让模型在生成代码前先看一眼标准写法。有了“锚点”输出质量会稳定很多。4.3 level-builder关卡数据与代码解耦level-builder 负责把关卡设计变成数据而不是把关卡逻辑硬编码在代码里。小游戏项目里最常见的坏味道就是把每个敌人的坐标写死在主循环代码中改一次关卡就要动一大堆代码。这个 Skill 的核心约定是所有关卡内容用 JSON 描述程序运行时读取数据生成实体。{ level: 1, player_start: { x: 2, y: 1 }, tiles: [ { type: ground, x: 0, y: 4, width: 10 }, { type: platform, x: 3, y: 2, width: 2 } ], enemies: [ { type: walker, x: 6, y: 3, speed: 1.0 } ] }当我需要新增关卡时指令很简单“用 level-builder skill 生成第 3 关的 JSON 数据难度比第 2 关提升 20%加入一个追踪型敌人。” Codex 会先读已有的关卡数据文件理解当前难度结构再生成符合规范的新数据。这套机制的隐性收益是因为数据和逻辑分离后续接可视化关卡编辑器会非常方便QA 定位问题也更快。很多独立项目死在“改关卡改代码”这个循环里level-builder Skill 算是性价比极高的一道保险丝。4.4 pixel-artist用代码生成程序化美术资源我知道很多人听到“AI 做美术”会想到 Midjourney 或者 Stable Diffusion但 Codex 场景下更顺畅的做法是让它写程序化生成脚本。尤其是像素风、几何风、低多边形风格用 Pillow、pyxel 这类 Python 库完全可以产出可用的素材。pixel-artist Skill 的职责是生成精灵图、调整调色板、输出图集坐标。我给它的规范包括--- name: pixel-artist description: 生成像素画、精灵表、调色板、图集配置 when_to_use: 需要新增美术资源、批量生成占位图、调整像素风格时 --- # 工作流程 1. 读取 assets/sprites 目录中已有资源的风格 2. 确认画布尺寸和调色板颜色数量 3. 用 Python 脚本生成 PNG严禁直接手写二进制图片 4. 输出图集 JSON标注每个精灵的坐标和尺寸 # 风格约束 - 默认调色板16 色避免高饱和荧光色 - 影子统一用比主色暗 25% 的颜色 - 动画帧优先做 4 帧循环idle、walk、hit一次典型调用“用 pixel-artist skill 生成一张 4 帧的玩家行走精灵表每帧 16x16 像素角色是戴帽子的橘猫。” 它会先写一个 Python 脚本画出猫的轮廓、帽子、眼睛然后拼接成精灵表再输出 JSON 坐标。我的经验是这个 Skill 的作用不是替代美术而是让开发早期不断需要“先用起来”的资源时不用停下来等人画图。占位图统一风格之后换成正式美术资源的成本也低。4.5 sound-designer不想找素材时就合成音效音效是独立开发者最容易忽略的部分但一个小游戏如果完全没有音效手感会塌一半。sound-designer Skill 的思路是用 Python 合成音效而不是去找素材库。这个 Skill 的核心能力是生成 wav 文件包含射击音效短促的噪声衰减拾取音效两声不同频率的方波叠加跳跃音效频率从低到高的正弦扫频背景音乐简单的琶音循环。SKILL.md 里会规定--- name: sound-designer description: 程序化合成音效与简易背景音乐 when_to_use: 缺少音效素材、需要快速生成占位音频时 --- # 输出规范 - 使用 Python wave 和 math 库生成 WAV采样率 22050 或 44100 - 所有音效文件名类型_参数.wav例如 jump_up_100_300.wav - 音量峰值不超过 -3 dB避免削波 - 生成完成后在 assets/sounds 目录下补齐 audio_manifest.json让 Codex 合成音效比在素材网站上找资源更快而且音频参数频率、时长、包络都可以程序化调整。比如我觉得跳跃音效太闷只说“把 jump 音效起始频率从 200Hz 提到 300Hz”就行了代码改一个参数重新运行不用重新找素材。5. 五个质量与发布类 Skill从可玩到能上线创作类 Skill 解决“能不能玩”质量与发布类 Skill 解决“能不能上线”。很多独立项目做出来自己觉得不错一给别人玩就到处出问题就是因为后面这一半管线完全缺失。5.1 ui-craftsperson让界面不只是“能点”ui-craftsperson 管的是菜单、HUD、对话框、设置页。它不会直接生成视觉稿但会保证代码层面的界面合理。我给它的关键规范是所有界面元素都要区分四种状态normal、hover、pressed、disabled键盘和手柄必须可以完成所有操作不能只支持鼠标文本层级保持三级标题、正文、提示字号差异明显HUD 元素禁止遮挡游戏主区域的核心信息。实际操作中我会说“用 ui-craftsperson skill 实现主菜单包含开始、设置、退出三个按钮要求支持键盘上下选择。” Codex 会生成界面代码并把键位绑定逻辑放在单独模块里而不是散落在按钮回调中。一个容易踩的坑AI 生成的 UI 代码经常只有鼠标事件忽略了键盘导航。把这个要求写进 SKILL.md 之后每次生成主菜单都会自动带键盘支持不用次次提醒。5.2 qa-tester让 AI 自己检查自己qa-tester 的核心思路是让 Codex 生成测试用例和测试脚本然后运行测试再把失败信息扔回给 Codex 修复。这形成一个“生成-验证-修复”的小循环。这个 Skill 的输出包括功能测试用例每个操作步骤、预期结果冒烟测试脚本一键启动游戏自动走完主流程缺陷报告复现步骤、实际表现、期望表现、影响范围。SKILL.md 里我特别写了一条缺陷报告禁止只说“游戏崩溃了”必须附带定位信息比如崩溃日志路径、触发前最后一个操作、涉及的系统模块。实际用法是“用 qa-tester skill 为主菜单和第一关生成冒烟测试用例并自动执行一次。” 当测试失败时我会把失败日志传给 core-programmer skill 修复然后再次让 qa-tester 重跑。这套机制下来很多问题在提交给真实玩家之前就被消灭了。5.3 performance-tuner别等卡了才优化performance-tuner 是那种“平时不起眼出事时救命”的 Skill。它的职责是分析性能瓶颈给出可落地的优化措施。我给它定义的优化顺序是先看帧耗时分布CPU、GPU、加载分别占多少再查内存峰值是否有资源的重复加载、泄漏最后查 GC 压力高频调用路径上是否有频繁创建对象每一步必须给出代码定位而不是“建议使用对象池”这种空话。典型触发指令“用 performance-tuner skill 分析当前场景的卡顿点优先检查 Update 函数里的字符串拼接和临时数组分配。” Codex 会定位到具体代码块给出优化前的分配次数和优化后的对比方案。这块经常有人问为什么不让 Codex 直接优化我的经验是不先定位就直接优化往往优化错地方反而把可读性搞坏了。performance-tuner 的 SKILL.md 里写明了“先证据、后方案”可以避免这个坑。5.4 release-engineer把“能跑”变成“能发”release-engineer 是上线前的守门员。它负责版本号管理、构建脚本、发布检查清单。很多独立开发者自己打包时都吃过亏版本号忘了改、资源没打进去、发布发现少了动态链接库。这些锅release-engineer 可以帮你接住。这个 Skill 的规范包括--- name: release-engineer description: 构建、打包、版本号管理、发布前检查 when_to_use: 需要出包、更新版本号、准备发布到 itch.io/Steam 时 --- # 工作流程 1. 读取 CHANGELOG.md确认本次版本包含哪些变更 2. 检查版本号是否严格遵循 主版本.次版本.修订号 格式 3. 执行构建命令确认无报错 4. 输出发布检查清单资源完整性、路径大小写、首启崩溃、存档兼容 5. 打包完成后记录构建产物 hash实际调用“用 release-engineer skill 执行一次 0.4.0 版本的 WebGL 构建并输出发布检查清单。” 它会自动更新 CHANGELOG生成新的版本号跑构建命令然后给出检查清单。5.5 producer协调整个团队的进度最后一个 Skill 更像“项目经理”它把散落的任务串起来。producer 的职责是维护 ROADMAP、拆解迭代任务、在每次任务开始前提供上下文。我给它的工作方式是定期对话读取 docs/roadmap.md 和 docs/status.md总结当前进度 结合 game-designer 输出的 GDD给出下一个迭代的任务清单 任务拆解粒度以“一次 Codex 会话能完成”为准。producer 的输出会让 Codex 在开始一天工作前先把背景、目标、边界理清楚而不是打开对话就说“帮我做个游戏”。有了这个 Skill十个技能之间就不是一锅粥而是有一个清晰的调度中枢。6. 在 Codex 里落地 Skills 的配置与排错经验有了理论和十个 Skill 的设计最后一步是把它们真正变成 Codex 可以识别的技能包。这部分我讲配置流程也把我实际踩过的坑列出来省得到时候你对着报错发愁。6.1 标准配置流程第一步在项目根目录下建一个skills文件夹或者按你所用 Codex 版本的约定放在全局技能目录。我习惯项目级和全局级分开通用技能放全局游戏相关技能放项目内方便多项目复用与差异化。第二步为每个 Skill 创建独立子目录目录名与技能名一致。比如skills/ ├── game-designer/ ├── core-programmer/ ├── level-builder/ ├── pixel-artist/ ├── sound-designer/ ├── ui-craftsperson/ ├── qa-tester/ ├── performance-tuner/ ├── release-engineer/ └── producer/第三步每个目录里写一个SKILL.md带 YAML front matter再放必要的参考文件和示例。front matter 里的name和description是触发匹配的关键description写得越具体Codex 越能准确判断何时该用这个技能。第四步在项目的 AGENTS.md 或 README 中写明“本项目的技能列表”让 Codex 在启动时就知道可调用的技能集合。推荐在项目说明里这样写本目录 skills/ 包含十个游戏开发技能 - game-designer玩法设计、GDD、数值平衡 - core-programmer核心玩法逻辑、状态机 - level-builder关卡 JSON 数据生成 - pixel-artist程序化像素美术 - sound-designer程序化音效 - ui-craftsperson界面布局与交互 - qa-tester测试用例与缺陷报告 - performance-tuner性能瓶颈定位与优化 - release-engineer构建发布与版本管理 - producer路线图与任务拆解第五步用一个真实任务测试某个 Skill 是否被正确触发。比如简单说一句“用 pixel-artist skill 生成一个 16x16 的白色方块 PNG”看它是否读取了对应目录里的规范。如果它没按 SKILL.md 工作说明描述或目录结构有问题需要调整。6.2 高频报错与排查链路我在用 Codex 调试这套体系时遇到过几个比较典型的报错和异常整理成表格方便对照现象可能原因处理方式Skill 完全不生效输出和裸 Codex 没区别技能名写错、description 太泛、技能目录没被扫描检查目录结构确认 AGENTS.md 已列出技能名任务指令里直接点名报错auth token is unavailable登录态失效或凭证未配置重新登录 Codex确认环境变量中凭证配置正确后重启终端报错model is not supported当前 CLI 版本不支持指定模型将模型参数切回官方可用模型或升级 Codex 版本上下文越来越长回答质量下降单个 Skill 加载了过多参考文件精简 SKILL.md参考文件拆小只在需要时让模型读特定目录Codex 生成了代码但无法运行缺少依赖或运行时版本不一致让 Codex 先读取项目依赖文件再按版本生成代码不要盲写排错时我自己的经验是先确认“它到底有没有读到 Skill 文件”。如果你在对话里明确点名了技能但它的行为和普通对话完全一样那大概率是目录没被扫描到或者 SKILL.md 的 front matter 格式有问题。遇到报错不要急着删掉重装先检查登录态、模型参数、目录结构这三层能解决九成问题。6.3 游戏逻辑里的事件锁问题最后聊一个和 Codex 不直接相关但游戏开发里一定会遇到的典型坑事件锁。这个坑我在让 Codex 写“点击按钮触发一次连续动作”时遇到过。假设玩家点击攻击按钮角色需要播放动画、位移、产生伤害判定这一整套动作必须保证只执行一次不能因为快速连点被重复触发。如果锁的逻辑处理不当会出现“点击一次怪物掉两次血”或者“动画播到一半被重置”。典型错误写法public void OnAttackButtonClicked() { StartCoroutine(AttackSequence()); }快速点击时AttackSequence会被多次启动动画、伤害、音效全部叠加。正确做法是加一个处理中的保护锁private bool _isAttacking; public void OnAttackButtonClicked() { if (_isAttacking) return; _isAttacking true; StartCoroutine(AttackSequence()); } private IEnumerator AttackSequence() { // 播放攻击动画 // 等待动画结束 // 生成伤害判定 _isAttacking false; }这种事件锁问题的麻烦之处在于它不是每次必现而是取决于玩家点击的时机所以很容易被 Codex 的测试用例漏掉。我的对策是在 qa-tester 的 SKILL.md 里加一条强制要求“涉及用户输入触发连续动作时必须检查是否存在防止重复触发的保护锁并加入连点测试用例。” 这样 Codex 在写测试脚本时会自动把“快速连点 10 次”这种边界场景覆盖进去。6.4 关于 Skill 粒度与维护的一点经验十套 Skill 全部建好之后并不是一劳永逸。Skill 是活的会随着项目的演进不断修正。我的维护习惯是每次发现 Codex 在某个岗位上的表现不符合预期第一反应不是换模型而是回头看对应 Skill 的说明是不是不够明确。比如 core-programmer 最初没有规定“改动超过 200 行必须拆提交”结果它一次生成了一大坨代码出了问题很难定位。我把这条规则补进去之后后续输出明显更稳。Skill 的粒度也需要控制不要小到一个函数也建一个 Skill它的合理单位是“岗位职责”或者“工作流程”不是“单个功能”。还有一个小技巧每个 Skill 的目录里放一份“反面教材”文件不是必须但非常有效。比如 pixel-artist 里放一张“配色混乱的反例图”Codex 看到之后会更理解为什么约束调色板很重要。大模型学习示例的能力很强一个正例加一个反例比写十条文字规则都有用。我个人现在开新游戏项目最先写的不是代码也不是 GDD而是 producer Skill 里的项目基础文档。它会把项目背景、技术栈、目录结构、技能清单全部初始化好再让 Codex 按路线图推进。这个过程有点像给团队开了个启动会看起来多花了十分钟但后面每一步都更顺。你把这十个 Skill 铺好再配合 Codex 的代码执行和自动迭代能力一个人撑起一支小型游戏开发团队真的不是夸张说法。