star
heart
diamond
star
heart
diamond
star
moon
cloud
cloud
cloud
alien
ship
grass flowers grass bush tree
▣ SKILL ACHIEVEMENT UNLOCKED ▣

游戏策划的 AI 技能化

工作流的模块组合
0
SKILLS
0
TOOLS
2
MCP
ai-workflow game-planning npm-package GDD
头像 陈腾骥
PRESS PLAY TO START
SP
LV 0

游戏策划是一项高度系统化的工作,一份完整的 GDD 需要覆盖系统设计、数值平衡、关卡节奏、战斗手感、美术方向、技术可行性等多个维度,且各模块之间存在严格的前后依赖和逻辑一致性要求。

在实际工作中,AI 辅助生成策划案面临三个核心问题

PROBLEM 01
缺乏领域知识结构
AI 容易产出泛泛而谈的内容,达不到专业策划的深度
PROBLEM 02
多模块前后矛盾
系统策划定义了经济系统,但数值策划的产出消耗比与之冲突;战斗策划的 HP 与数值策划的 HP 不一致
PROBLEM 03
策划到开发的断层
产出的文档无法直接指导编码,程序员需要二次"翻译"
▼ SOLUTION

本项目针对这三个问题,构建了一套可灵活组合的 AI 游戏策划技能体系。把游戏策划的专业经验结构化为 11 个独立技能,通过 MCP(Model Context Protocol)协议暴露给 AI 智能体,让 AI 能按照专业策划工作流产出可落地、可直接对接开发的完整游戏设计文档(GDD)。

1.1 技能工具一览表(11 个)

以下是全部 11 个技能工具的完整清单,按"核心 + 类型池 + 组装器"三层架构分组:

# 技能名称 层级 何时使用 核心能力
1
系统策划
game-system-design
核心层 需要设计游戏核心系统(背包、技能、经济、任务、社交、抽卡、成就等)的玩法循环和规则时 从系统关键词出发,通过 6 大知识库(资源循环/成长系统/社交匹配/随机系统/进度系统/商业化系统)产出系统策划案,只定义决策项
2
数值策划
game-numerical-design
核心层 需要推导战斗数值、设计经济系统、平衡成长曲线或计算资源产出消耗比时 涵盖战斗数值推导、经济系统数值推导和成长曲线推导,附带完整公式与实例
3
美术生产
game-art-production
核心层 需要生成游戏美术资源、设计角色立绘、场景概念图、UI界面、特效或动画方案时 涵盖原画三阶段(概念→细化→终稿)、场景、特效、动画、UI 五大方向,含结构化提示词模板和资源输出规格
4
QA 测试
game-qa-testing
核心层 需要测试用例设计、配置校验、可玩性保障或问题定位时 覆盖剧情数值测试、玩法战斗测试、角色单位测试三大方向,P0-P3 优先级分级
5
技术实现全链路
game-tech-implementation
核心层 需要将策划案转化为代码、设计配置表结构、定义状态机、确定网络同步策略、选择引擎架构、生成代码或进行代码审查时 覆盖策划案到代码的完整路径——规范层(配置表Schema、状态机模板、字段映射、网络同步、工程规范)+ 执行层(技术选型、实现链路、代码生成、代码审查)
6
创意框架完善
game-creative-discussion
类型池 有游戏创意想法需要讨论、打磨,或某个模块设计前需要先完善框架,或需要做玩家分析/动机分析/设备适配等策略规划时 基于交互设计五要素(用户/场景/目的/媒介/行为),通过三层递进(策略分析→创意发散→功能规划)产出用户确认的"游戏创意框架"
7
关卡策划
game-level-design
类型池 需要设计关卡、地图布局、难度曲线、节奏控制或关卡流程时 基于节奏控制、空间设计和难度梯度产出可落地的关卡策划案
8
战斗策划
game-combat-design
类型池 需要设计战斗系统、攻击手感、技能连招、Boss 战模式或伤害公式的结构设计时 基于攻击手感参数(前摇/后摇/命中停顿/击退)、Boss 战模式和伤害公式标准形式产出可落地的战斗策划案
9
剧情策划
game-narrative-design
类型池 需要设计游戏剧情、世界观、角色对白、任务文本或故事线结构时 通过剧情大纲→迭代修订→文本润色→逻辑校验的四阶段工作流产出剧情策划案
10
角色与单位设计
game-character-design
类型池 需要设计游戏角色、单位、英雄、怪物或NPC的外观、背景、技能和属性设定时 通过原型调研→设定生成→美术方向→评审优化→变体扩展的五阶段流程
11
GDD 组装器
game-full-workflow
组装器 已有各模块策划案内容,需要整合为完整 GDD,或需要校验多模块策划案之间的一致性与前后逻辑时 将各模块产出整合为统一自洽的完整 GDD,通过六维度校验(数值自洽/角色一致/字段一致/状态机一致/经济闭环/术语统一)确保整体一致性
flow 一、

整体设计流程图

以下流程图展示了从用户进入到产出完整 GDD 的全流程,包含五种使用路径和事前框架化 + 事后校验的闭环。

1.2 流程说明

▼ 流程步骤

Step 1:用户任意阶段进入,首先调用 list_skills() 获取所有 11 个技能的 name + description(含"何时使用 + 能力 + 边界"三段式)

Step 2:LLM 基于 description 做语义匹配选择最合适的技能(非关键词打分,是 in-context learning)

▼ 五种使用路径

路径一(全流程):创意框架完善 → 各单模块 → 技术实现 → 组装校验

路径二(单模块):直接进入对应技能产出方案

路径三(整合):已有各模块内容,直接进入组装器

路径四(体检):已有完整 GDD,只跑六维度校验

路径五(创意设计):仅走 game-creative-discussion,直接输出用户确认的"游戏创意框架"大纲,不进入下游模块细化——适合早期创意阶段只要框架、不要完整设计的场景

▼ 闭环机制

事前框架化 + 事后校验的闭环game-creative-discussion(事前)减少冲突数量,game-full-workflow(事后)兜底解决遗漏。路径五仅产出框架,不进入事后校验闭环。

1.3 流程图

用户进入: 任意阶段的游戏设计需求 Step 1: list_skills() 返回 11 个技能 name + description (何时使用 + 能力 + 边界) Step 2: LLM 语义匹配选择 基于 description, 非关键词打分, 是 in-context learning 路径一: 全流程 新项目 路径二: 单模块发散 直接进入对应技能 路径三/四: 整合或体检 已有内容→组装器 路径五: 创意设计 仅框架 game-creative-discussion 三层递进 ← 事前框架化 各单模块技能 系统/关卡/战斗/剧情/角色/数值/美术/QA game-tech-implementation 规范+执行 ← 对接开发 直接进入对应技能 如 game-combat-design game-full-workflow GDD组装 + 六维度校验 ← 事后校验 game-creative-discussion 仅走本技能 直接输出游戏框架大纲 用户确认 "游戏创意框架" 结束: 仅框架层 不进入下游 完整 GDD 输出 统一自洽, 可对接开发
入口与终止
决策/步骤
框架完善
模块技能
GDD 组装器
产出节点

1.4 案例展示流程

● ● ● case-study.js
用户: 我想做一个面向 Z 世代的社交游戏。
    [担心赛道选错、玩家画像模糊、缺乏差异化]

AI 调用 game-strategy-analysis:
  1. 玩家分析 → Z 世代玩家画像 (Bartle 分群偏社交型+探索型)
  2. 策略机制 → 内部动机 (好奇心/掌控感) 驱动, 社交关系为切入点
  3. 社交矩阵 → 合作 (组队) + 表达 (自定义) 优先, 竞争为辅
  4. 设计思路三角 → 情感优先于认知, 操作要轻量化

产出策略分析报告 → 进入 game-creative-discussion 做创意发散
    → 进入各策划模块 → 组装 GDD
◆ ◆ ◆
innovation 二、

自动化工作流

2.1 游戏创意框架

大多数 AI 文档生成工具的工作模式是"用户提供需求,AI 产出文档"。这种方式在游戏策划场景下有一个根本问题:创作者往往只有模糊的创意直觉,还不具备将其拆解为系统策划、关卡设计、数值平衡等专业模块的能力。

本体系在创意阶段引入一个游戏创意框架完善工具game-creative-discussion)。它基于交互设计五要素(用户、场景、目的、媒介、行为),通过三层递进结构引导创作者完善一份用户确认的"游戏创意框架":

● ● ● creative-discussion-structure.js
game-creative-discussion
│
├── 第一层: 策略分析 (交互设计五要素的"用户/目的/媒介"前置)
│   ├── 用户 (玩家分析)
│   │   ├── Bartle 分群 (探索/成就/社交/杀手)
│   │   ├── 认知模型 (感官/认知/行为三层)
│   │   └── 心理效应 (心流/损失厌恶/沉没成本/社会认同)
│   ├── 目的 (玩家动机)
│   │   ├── 内部动机 (好奇心/掌控感/成就感)
│   │   ├── 外部动机 (奖励/竞争/社交驱动)
│   │   └── 引导设计方向 (新手/功能/付费)
│   └── 媒介 (游戏设备环境预判)
│       ├── 目标平台 (PC/主机/移动/VR/云)
│       ├── 输入方式 (键鼠/手柄/触屏/体感)
│       └── 使用情境 (碎片化/沉浸/客厅/移动)
│       → 产出: 玩家画像 + 核心动机 + 媒介约束
│
├── 第二层: 创意发散 (原有5维度, 接收第一层输入)
│   ├── 游戏类型与核心机制 (← 媒介: 玩法载体)
│   ├── 目标受众与平台 (← 用户+媒介: 已部分确认)
│   ├── 视觉风格与情绪体验 (← 媒介: 表现形式)
│   ├── 核心循环与玩法深度 (← 行为: 玩家行为循环)
│   └── 风险与可行性
│       → 产出: 初步设计大纲
│
└── 第三层: 功能规划 (交互设计五要素的"行为/场景"细化)
    ├── 行为 (玩家交互行为规划)
    │   ├── 核心玩法流程 (玩家做什么)
    │   ├── 操作方式与反馈设计 (怎么操作)
    │   └── 模块互联方向表 (各模块行为如何衔接)
    ├── 场景 (特定场景下的游戏需求)
    │   ├── 设计思路三角 (认知-情感-操作平衡)
    │   └── 社交行为矩阵 (竞争/合作/冲突/表达)
    └── 交互五要素自检
        ├── 用户: 玩家画像是否清晰?
        ├── 媒介: 设备环境是否确认?
        ├── 目的: 核心动机是否明确?
        ├── 场景: 特定场景下的游戏需求是否明确?
        └── 行为: 核心循环是否闭环?
        → 产出: 创意大纲 + 策略要点 + 互联方向 + 五要素自检报告

用"对战模式作为关卡"举例

● ● ● example-interconnection.txt
互联方向表 (创意发散阶段产出, 各模块据此细化):

【五要素确认】
- 用户: 硬核竞技玩家 (Bartle 杀手型 + 成就型)
- 媒介: PC 端, 键鼠操作, 沉浸式长时间游玩
- 目的: 竞争驱动 + 成就感
- 场景: 竞技对抗场景 (排位/匹配需求)
- 行为: 匹配 → 对战 → 结算 → 解锁 → 再匹配

【模块互联方向】
├── 关卡 ←→ 战斗: 每关是一场对战, 战斗策划定义对战机制
├── 关卡 ←→ 数值: 关卡难度=对手强度, 数值策划平衡
├── 系统 ←→ 关卡: 解锁新对战模式作为关卡奖励
└── 角色 ←→ 战斗: 角色技能直接影响对战平衡

【各模块细化指引】
- game-level-design → 把"对战"作为关卡核心, 细化匹配节奏、地图设计
- game-combat-design → 细化对战机制、技能设计、伤害公式
- game-numerical-design → 平衡对战数值、角色强度
- game-character-design → 角色设计考虑对战平衡

两个关键原则

◆ 框架先行
无论用户想法是否明确,建议全流程都走本技能,产出一份用户确认的框架后再进入各模块细化,减少后期返工成本
◆ 已有内容不重写
用户已提供的想法直接采用,本技能只做确认、补全、框架化

2.2 技能体系:模块组合的灵活性

传统 GDD 流程通常是一条固定流水线:系统→关卡→战斗→剧情→角色→数值,所有游戏走同一条路。问题在于不同游戏类型对策划模块的需求差异极大——解谜游戏不需要战斗策划,竞技游戏不需要剧情策划,抽象益智游戏可能连角色设计都不需要

本体系采用核心层 + 类型模块池的二层架构:

▼ 核心层(几乎所有游戏都需要)
系统策划
数值策划
美术生产
QA 测试
技术实现全链路
▼ 类型模块池(按游戏类型按需选用)
关卡策划(有关卡时)
战斗策划(有战斗时)
剧情策划(有叙事时)
角色与单位设计(有角色时)

确认游戏类型后,系统根据预设的匹配表自动推荐模块组合(如 RPG 全选、解谜只选关卡、模拟经营可选角色),用户可调整。这让同一套方法论不改流程本身,仅通过模块选取的不同,覆盖 11+ 种游戏类型

11 个技能按"核心 + 类型池 + 组装器"分为三层。核心特性是灵活组合——任意阶段可介入,单模块也能用,不强制产出整个游戏。

2.2.1 核心技能(几乎所有游戏都需要)

技能 职责
系统策划
game-system-design
从系统关键词出发,通过 6 大知识库(资源循环、成长系统、社交匹配、随机系统、进度系统、商业化系统)产出系统策划案,只定义决策项
数值策划
game-numerical-design
战斗数值推导、经济系统数值推导、成长曲线设计,附带完整公式与演算实例
美术生产
game-art-production
原画三阶段(概念→细化→终稿)、场景、特效、动画、UI 五大方向的 AI 提示词模板和资源输出规格
QA 测试
game-qa-testing
覆盖剧情数值测试、玩法战斗测试、角色单位测试三大方向,P0-P3 优先级分级
技术实现全链路
game-tech-implementation
规范层(配置表 JSON Schema、状态机模板、字段映射、网络同步策略)+ 执行层(技术选型、引擎对比、代码生成与审查)

2.2.2 类型池技能(按游戏类型按需选用)

技能 职责
创意框架完善
game-creative-discussion
游戏创意框架完善工具,基于交互设计五要素,通过三层递进产出用户确认的框架,全流程建议都走
关卡策划
game-level-design
节奏控制、空间设计、难度梯度,适配有关卡/阶段的游戏
战斗策划
game-combat-design
攻击手感参数(3 种节奏 × 8 项参数)、Boss 战模式、伤害公式
剧情策划
game-narrative-design
剧情大纲→迭代修订→文本润色→逻辑校验的四阶段工作流
角色与单位设计
game-character-design
原型调研→设定生成→美术方向→评审优化→变体扩展的五阶段流程

2.2.3 组装器

技能 职责
GDD 组装器
game-full-workflow
GDD 组装器 + 一致性校验器,整合各模块产出,校验前后逻辑,输出完整 GDD
▼ CORE VALUE

核心价值:不管在游戏设计的哪个阶段,都能通过这个方式来完善并产出完整的内容,也可以只针对某一模块进行方案的发散,不用局限于一定得产出整个游戏,在任何阶段都能有产出。

2.3 协作边界:解耦但有引用

这是本体系在架构设计上的一个关键创新。技能之间遵循"解耦但有协作边界"的原则:每个技能职责单一,不重复产出其他技能的内容;技能间通过跳转指引和引用协作,而非各自包含完整内容。

2.3.1 明确的分工边界

系统策划只定义"经济系统要做哪些决策",数值推导归数值策划
系统策划只定义"技能系统的结构与成长",战斗表现归战斗策划
战斗策划只定义"设计意图"(预期打几轮、持续多久),数值反推归数值策划
配置表 Schema、状态机、网络同步归技术实现,不在各策划模块重复
game-full-workflow 作为组装器,负责整合各模块并校验前后逻辑一致性

2.3.2 引用语规范:消除歧义

为了消除"详见 xxx"这类歧义措辞(既可理解为"去查阅已有内容"导致目标模块无内容时卡死,也可理解为"去产出"语义不清),统一了三种引用语规范:

引用类型 措辞 语义 示例
协作式 "由 xxx 产出" / "由 xxx 基于本模块的 XX 反推产出" 目标模块从零工作,不需要前置内容 数值参数由 game-numerical-design 基于设计意图反推产出
查阅式 "见 xxx" / "参见 xxx" 目标模块需已有内容,本模块直接引用 角色清单见 game-character-design
前置依赖 "需先完成 xxx" 明确标注先后顺序,未完成则本模块无法进行 需先完成 game-character-design 的角色清单

这个规范看似细节,实际解决了 AI 智能体在技能间跳转时的一个关键歧义——它现在能明确知道是去产出、去查阅、还是需要先完成前置,避免"引导去某模块但该模块无内容"的卡死场景。

2.3.3 模块互联方向表

创意框架完善阶段会产出一张"模块互联方向表",作为各模块细化的指导方向。只记录方向,不涉及具体设计。

模块 A ←→ 模块 B 互联关系 细化指引
关卡 ←→ 战斗 每关是一场对战 game-level-design 把对战作为关卡核心;game-combat-design 定义对战机制
关卡 ←→ 数值 关卡难度=对手强度 game-numerical-design 平衡对战数值
角色 ←→ 战斗 角色技能影响对战平衡 game-character-design 考虑平衡性

各模块拿到方向后,在自己的技能内细化具体设计。

2.4 GDD 组装器(六维度一致性校验)

game-full-workflow 的定位是 GDD 组装器 + 一致性校验器——核心场景是用户已经产出了游戏的各个模块内容,输入后由本技能进行内容整合 + 前后逻辑校验 + 冲突检测,最终输出一份统一、自洽的完整 GDD。

2.4.1 四种使用场景

1
全模块组装:已完成所有模块,整合为完整 GDD
2
部分模块组装:只完成了部分模块,整合已有部分并识别缺失模块
3
一致性体检:已有完整 GDD,做一次前后逻辑校验找出不一致点
4
增量组装:已组装过一版,新增/修改某模块后重新校验受影响部分

2.4.2 六维度校验能力

这是组装器区别于"简单拼接"的关键价值。组装时必须对以下维度做交叉校验,发现冲突即输出冲突报告:

校验维度 校验目标 冲突示例
数值自洽性 系统↔数值↔战斗三方数值算平 数值策划 HP=440,但战斗策划设计意图是"打3轮",算出来要打4轮
角色一致性 角色设计↔战斗技能↔美术需求 角色设计案有5个技能,战斗策划只配了4个
配置表字段一致性 命名/类型/取值/枚举/默认值 战斗策划用 skill_mult,数值策划用 skill_multiplier
状态机一致性 枚举冲突/转换互斥/优先级/时机 角色状态机有 Attacking,战斗状态机也有但含义不同
经济系统闭环 产出↔消耗↔成长无断层 系统策划有"挂机产出",数值策划日产估算没算
术语/命名统一 同一概念用词统一 战斗策划叫"体力",系统策划叫"耐力",数值策划叫"ST"

2.4.3 冲突检测与解决

发现冲突时输出结构化报告,按严重等级分级:

P0 阻断
会导致程序无法编码或数值无法算平,必须解决才能完成组装
P1 重要
会导致玩家体验明显异常,强烈建议解决
P2 建议
不影响功能但影响一致性,可延迟处理

每个冲突附带 2 个以上解决方案及代价,用户选择处理方式后重新校验受影响部分。

2.4.4 事前框架化 + 事后校验的闭环

● ● ● validation-loop.js
┌──────────────────────┐         ┌──────────────────────┐
│  事前:框架完善          │         │  事后:一致性校验        │
│  (game-creative-       │         │  (game-full-workflow) │
│   discussion)          │         │                      │
│                        │         │                      │
│  ├── 策略分析(5要素)   │         │  ├── 数值自洽性        │
│  ├── 创意发散(5维度)   │  ──→    │  ├── 角色一致性        │
│  ├── 功能规划(互联方向) │         │  ├── 字段一致性        │
│  ├── 五要素自检         │         │  ├── 状态机一致性      │
│  └── 用户确认框架        │         │  ├── 经济闭环          │
│                        │         │  └── 术语统一          │
│  减少事后返工            │         │  最后一道防线           │
└──────────────────────┘         └──────────────────────┘

事前框架化减少冲突数量,事后校验兜底解决遗漏,形成完整保障。

◆ ◆ ◆
mcp 三、

MCP Server 实现

基于 TypeScript + Node.js,使用 @modelcontextprotocol/sdk 的 McpServer 类和 StdioServerTransport,参数校验用 zod。不依赖 js-yaml,使用正则解析 YAML frontmatter(字段结构简单,无需完整 YAML 解析器)。

3.1 MCP 工具

工具 作用
list_skills 首选入口:列出所有技能的 name + description(含"何时使用 + 能力 + 边界"),LLM 据此选择
get_skill 获取指定技能的完整 SKILL.md 内容,命中 LRU 缓存时免重复读取磁盘
get_reference 获取技能的参考资料文件(如有)

推荐使用流程是:

1
先调 list_skills 查看所有技能的 description
2
LLM 根据"何时使用"部分做语义匹配选择最合适的技能
3
再调 get_skill 获取完整工作流

这种做法让 LLM 用自身的语义理解能力选 tool,而非依赖 server 端的关键词打分——对中文同义词和俚语场景(如"肉鸽"匹配 Roguelike)更准确。

3.2 技能选择机制:description 三段式

每个技能的 description 采用"何时使用 + 能力说明 + 边界"三段式写法。

不使用独立的路由工具——LLM 在初始化时通过 tools/list 拿到所有 tool 的 description,基于语义匹配选择,本质是 in-context learning,不是关键词匹配。这与 MCP 官方参考 server(Filesystem / Git / Memory / Fetch / Sequential Thinking / Time / Everything)的做法一致:扁平暴露所有 tool,每个 description 写清楚 "When to use"。

元数据索引在首次访问时构建一次并缓存(只读取每个 SKILL.md 的前 1KB 解析 frontmatter),后续调用不再重复扫描磁盘。完整技能内容使用 LRU 缓存(最大 32 条),重复调用同一技能直接返回内存数据。

3.3 技能自包含格式

每个技能目录只需包含一个 SKILL.md,frontmatter 必须包含两个字段:

● ● ● SKILL.md
---
name: "game-combat-design"
description: "何时使用:需要设计战斗系统、攻击手感、技能连招、Boss战模式或伤害公式的结构设计时。能力:基于攻击手感参数(前摇/后摇/命中停顿/击退)、Boss战模式和伤害公式标准形式产出可落地的战斗策划案。边界:只定义设计意图,具体数值反推归 game-numerical-design。"
---

description 字段是 LLM 选择技能的核心依据,采用"何时使用 + 能力说明 + 边界"三段式。

3.4 项目数据

指标 数值
技能数量 11 个独立技能
覆盖游戏类型 11 种(RPG / ARPG / 动作 / 策略 / 收集 / 解谜 / 模拟 / 竞速 / FPS-TPS / MOBA / Roguelike)
npm 包名 @chantezy/mcp-game-design
开源地址 https://github.com/chantezy/game-skills

3.5 使用方式

● ● ● install.sh
npm i @chantezy/mcp-game-design

在任何支持 MCP 的客户端(Claude Desktop、Cursor、Trae 等)中配置:

● ● ● mcp-config.json
{
  "mcpServers": {
    "game-design": {
      "command": "npx",
      "args": ["--yes", "@chantezy/mcp-game-design@latest"]
    }
  }
}
◆ ◆ ◆
conclusion 四、

结语

这套体系的本质,是把游戏策划的专业经验结构化为 AI 可消费的技能。让 AI 成为策划的合格助手——能做深度设计决策、能保持多模块一致性、能直接对接开发实现。

核心设计是模块组合的灵活性——不管在游戏设计的哪个阶段,都能通过这个方式来完善并产出完整的内容,也可以只针对某一模块进行方案的发散,不用局限于一定得产出整个游戏。这使得它既是一套游戏策划方法论,也是一套可即插即用、按需组合的 AI 工具

◆ ◆ ◆
cases 五、

实战案例

5.1 游戏策划案生成

通过描述直接完善整个方案内容,生成独立的模块文档。

策划案生成示例

生成独立的模块文档:

模块文档输出

5.2 联动 cocos 编辑器制作游戏

游戏策划只解决游戏要怎么做的策略问题,没有解决游戏直接制作的环节,所以我做了 cocos-mcp,通过 AI 对画布的控制进行内容的生成。

输入已有的策略文档,可以直接控制内容生成。

https://www.npmjs.com/package/@chantezy/cocos-bridge

● ● ● install-cocos.sh
npm i @chantezy/cocos-bridge

接入 MCP 后,可以直接对编辑器进行控制。cocos-bridge 提供 16 个意图级工具(项目脚手架 & 资源、代码生成、场景 & UI)+ 1 个通用回退工具(兜底),共 17 个工具:

# 工具名称 作用
1generate_project_scaffold根据游戏类型+架构+功能标志生成完整项目目录结构、tsconfig 和基础框架代码
2generate_config_files根据 GDD Schema 定义生成 JSON 配置文件、TypeScript 接口和 ConfigLoader
3generate_component_scripts根据组件属性列表生成 @ccclass 组件 .ts 文件和 @property 装饰器
4generate_state_machine根据状态枚举和转移规则生成 State enum + StateMachine class
5build_scene_from_config根据关卡配置 JSON 构建场景节点层级(地形/灯光/相机/出生点)
6build_ui_layout根据 UI 布局定义构建 Canvas 下的 UI 节点树和组件绑定
7build_combat_setup根据战斗场景配置构建角色节点、碰撞体、相机跟随和 UI 面板
8populate_level_enemies根据敌人刷新点列表生成敌人 Prefab 实例和刷新逻辑脚本
9import_and_organize_assets根据源目录和命名规则自动分类导入资源(sprites/audio/prefabs 等)
10validate_asset_references检查项目目录中的断裂引用和孤立资产,输出报告
11apply_naming_convention根据目录和命名规范批量重命名资源并生成校验报告
12check_config_consistency校验配置目录中的字段类型、范围和引用一致性
13audit_project_health项目全面体检:结构/资产/场景/脚本/配置
14inspect_scene_graph查看场景文件的节点层级、组件和属性树
15get_project_context获取项目路径、引擎版本、场景列表和脚本统计信息
16capture_scene_snapshot捕获当前场景的节点树、组件和变换信息快照
17execute_script在场景或编辑器上下文中执行任意 JavaScript 代码(通用回退工具)
cocos编辑器控制 cocos编辑器生成