企业官网建设流程全解析

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。它们的名字和职责如下表：

之所以是这十个，而不是更多，是因为游戏开发最核心的管线刚好被这个组合覆盖：策划把玩法定义清楚，程序把原型跑起来，美术和音频把内容填上，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。它的职责是分析性能瓶颈，给出可落地的优化措施。

我给它定义的优化顺序是：

1. 先看帧耗时分布：CPU、GPU、加载分别占多少；
2. 再查内存峰值：是否有资源的重复加载、泄漏；
3. 最后查 GC 压力：高频调用路径上是否有频繁创建对象；
4. 每一步必须给出代码定位，而不是“建议使用对象池”这种空话。

典型触发指令：“用 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 文件”。如果你在对话里明确点名了技能，但它的行为和普通对话完全一样，那大概率是目录没被扫描到，或者 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 的代码执行和自动迭代能力，一个人撑起一支小型游戏开发团队，真的不是夸张说法。