Unity 给 Claude Code 上了 29 个技能、给 Codex 上了 31 个：为什么「领域技能包」胜过通用 Agent

Unity 干了一件值得所有做 Agent 平台的人注意的事：它没有等社区把经验攒成论坛帖子，而是由自家工程师直接发布了官方一手插件。按公开报道，面向 Claude Code 的插件在 9 月 10 日上线，带 29 个内置技能；面向 OpenAI Codex 的插件在 9 月 16 日跟进，带 31 个技能，两者都面向 Unity 6 及以上版本，并由 Unity 自家工程团队维护。用报道里那句很传神的话说：别再让 AI 编码 Agent 从「没人再用的引擎版本」的论坛帖子里学游戏开发了。据报道，这些技能覆盖 UI Toolkit、uGUI、2D 与 Tilemap、URP 与 Shader Graph、音频、导航、物理、IAP、LevelPlay、多人、Web 与本地化等方向。

一、发布了什么：官方技能包的形状

据 Inven Global、BigGo 与 MIXED Reality News 等报道，这次发布的核心特征是「官方一手」：插件由 Unity 工程师直接开发与维护，而非第三方社区方案。工程上的差异落在执行顺序上——Agent 会在动手前先检查项目结构与状态，应用最新的 API，并在结果通过内部验证步骤之后才交付给开发者。Codex 插件一次带来 31 个与游戏开发相关的技能，覆盖 UI Toolkit、uGUI、2D、Tilemap、URP、Shader Graph、音频、导航、物理、IAP、LevelPlay、多人、Web 与本地化等；Claude Code 插件则先一步上线，带 29 个技能。值得一提的是，据 MIXED Reality News 报道，这些技能覆盖面集中在引擎本身，并不包含 XR 相关内容。

# A skill pack is a repository, not a prompt. Lay it out like one.
skills/
  unity-ui-toolkit/
    SKILL.md              # when to use it, what it guarantees
    scripts/validate_ui.py  # deterministic actions the agent calls
    references/uxml.md      # deep docs, loaded only when needed
  unity-urp-render/
    SKILL.md
    scripts/inspect_pipeline.py

别再让 Agent 从旧论坛帖子里学 API

二、为什么「技能」胜过「塞上下文」

通用编码 Agent 的知识来自训练数据，而训练数据里的引擎文档往往是过时的——论坛帖子里讨论的可能是几个大版本之前的 API。把这些旧知识注入上下文，Agent 会自信地写出早已弃用的写法。技能包解决的是这个「知识新鲜度」问题：把「当前正确的做法」写成 Agent 在任务中按需加载的资源，由维护者负责更新。它同时也解决了「动作可靠性」问题：技能不只是文档，还包含一组确定性的脚本，Agent 调用脚本而不是凭空生成命令。文档负责「知道什么」，脚本负责「做得对」，两者合起来才是技能。

---
name: unity-ui-toolkit
description: Build and refactor UI Toolkit and uGUI interfaces for Unity 6+
when_to_use: The task mentions UI Toolkit, UXML, USS, or uGUI canvases.
verify: scripts/validate_ui.py must exit 0 before you report success.
---
# UI Toolkit

1. Read references/uxml.md before editing any .uxml file.
2. Prefer live in-engine APIs; never invent component names.
3. After edits, run scripts/validate_ui.py and paste its output.

Deep reference material lives in references/ and is loaded on demand,
so the skill stays small until the task actually needs the detail.

三、一个好技能的解剖：三层结构

第一层是「何时使用」：SKILL.md 里用简短的话说明触发条件，比如「任务提到 UI Toolkit、UXML、USS 或 uGUI 时」。第二层是「怎么做」：一组确定性的动作，通常以脚本形式提供，输入输出都是结构化的，Agent 调用它而不是即兴发挥。第三层是「深水区」：把详细参考资料放在 references/ 目录里，只在任务真正需要时才加载，这样技能在平时保持轻量。这个三层结构还有一个隐含要求——技能必须以一次可验证的检查收尾。没有验证，「看起来对」会一路蒙混过关。

// Give the agent a typed contract, not a paragraph. Types can be checked;
// prose cannot. This is what makes a skill reusable across models.
import { z } from "zod";

export const InspectPipelineInput = z.object({
  projectPath: z.string(),
  pipeline: z.enum(["urp", "hdrp", "builtin"]),
});

export async function inspectPipeline(input: z.infer<typeof InspectPipelineInput>) {
  const args = InspectPipelineInput.parse(input);
  return runEditor("RenderPipelineInspector", args); // structured, verifiable
}

技能包是仓库，不是一段提示词

四、自己写一套技能包：契约、验证与版本

自己写技能包时，有三件事最值得投入。第一是契约：给技能的动作定义带类型的输入输出（例如用 zod 定义 schema），让 Agent 能够依赖类型而不是靠猜；比起一整段散文式说明，可校验的契约在不同模型之间迁移时更稳定。第二是验证：每个技能都要以一次可重复的检查收尾，比如跑一个验证脚本、或跑一遍引擎测试，把「完成」从主观判断变成客观结果。第三是版本：像管理依赖一样钉住技能版本，并在 CI 里跑技能自己的测试套件——一个没有钉版本的技能，就是某天别人偷偷改了仓库之后的一次静默行为变更。

# Every skill must end in a verifiable check. 'It looks right' is not one.
set -euo pipefail

python skills/unity-ui-toolkit/scripts/validate_ui.py ./Project   # must exit 0
unity-editor -batchmode -projectPath ./Project -runTests          # engine tests
echo "skill verified: unity-ui-toolkit"

# Verification is what separates a skill pack from a well-written prompt.

五、落地代码：从目录结构到版本固定

第一段给出技能包的目录结构：SKILL.md、scripts/ 与 references/ 各司其职。第二段是一个 SKILL.md 的示例，用 frontmatter 声明名称、触发条件与验证要求，正文只写必要的步骤，深水材料按需加载。第三段用带类型的 schema 定义技能动作的输入，让契约可被校验、可跨模型复用。第四段演示「可验证收尾」：跑验证脚本、跑引擎测试，只有退出码为 0 才算完成。第五段是版本固定的声明——把技能像依赖一样钉住，并规定在升级前必须评审、在 CI 中跑测试。

// Pin skills like dependencies. An unpinned skill is a silent behavior
// change the day someone edits the repository behind your back.
{
  "skills": {
    "unity-ui-toolkit": "1.2.0",
    "unity-urp-render": "1.0.3"
  },
  "policy": "review before bump; run the skill test suite in CI"
}

每个技能都要以一次可验证的检查收尾

六、清单：把领域知识做成可维护的资产

五个检查项。第一，你的 Agent 依赖的领域知识，是写在可维护的技能包里，还是散落在提示词和过时文档中？第二，技能是否说清了「何时使用」？第三，动作是否有带类型的契约，而不是散文化的描述？第四，每个技能是否以一次可验证的检查收尾？第五，技能版本是否被钉住，并纳入 CI 测试？Unity 这件事最值得学的地方，其实不是那 29 和 31 这两个数字，而是它背后的姿态：与其让 Agent 从互联网的旧帖子里猜你的 API，不如由最懂它的人写下来、维护起来、并且能验证。