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













游戏策划是一项高度系统化的工作,一份完整的 GDD 需要覆盖系统设计、数值平衡、关卡节奏、战斗手感、美术方向、技术可行性等多个维度,且各模块之间存在严格的前后依赖和逻辑一致性要求。
在实际工作中,AI 辅助生成策划案面临三个核心问题:
本项目针对这三个问题,构建了一套可灵活组合的 AI 游戏策划技能体系。把游戏策划的专业经验结构化为 11 个独立技能,通过 MCP(Model Context Protocol)协议暴露给 AI 智能体,让 AI 能按照专业策划工作流产出可落地、可直接对接开发的完整游戏设计文档(GDD)。
以下是全部 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,通过六维度校验(数值自洽/角色一致/字段一致/状态机一致/经济闭环/术语统一)确保整体一致性 |
以下流程图展示了从用户进入到产出完整 GDD 的全流程,包含五种使用路径和事前框架化 + 事后校验的闭环。
Step 1:用户任意阶段进入,首先调用 list_skills() 获取所有 11 个技能的 name + description(含"何时使用 + 能力 + 边界"三段式)
Step 2:LLM 基于 description 做语义匹配选择最合适的技能(非关键词打分,是 in-context learning)
路径一(全流程):创意框架完善 → 各单模块 → 技术实现 → 组装校验
路径二(单模块):直接进入对应技能产出方案
路径三(整合):已有各模块内容,直接进入组装器
路径四(体检):已有完整 GDD,只跑六维度校验
路径五(创意设计):仅走 game-creative-discussion,直接输出用户确认的"游戏创意框架"大纲,不进入下游模块细化——适合早期创意阶段只要框架、不要完整设计的场景
事前框架化 + 事后校验的闭环:game-creative-discussion(事前)减少冲突数量,game-full-workflow(事后)兜底解决遗漏。路径五仅产出框架,不进入事后校验闭环。
用户: 我想做一个面向 Z 世代的社交游戏。
[担心赛道选错、玩家画像模糊、缺乏差异化]
AI 调用 game-strategy-analysis:
1. 玩家分析 → Z 世代玩家画像 (Bartle 分群偏社交型+探索型)
2. 策略机制 → 内部动机 (好奇心/掌控感) 驱动, 社交关系为切入点
3. 社交矩阵 → 合作 (组队) + 表达 (自定义) 优先, 竞争为辅
4. 设计思路三角 → 情感优先于认知, 操作要轻量化
产出策略分析报告 → 进入 game-creative-discussion 做创意发散
→ 进入各策划模块 → 组装 GDD
大多数 AI 文档生成工具的工作模式是"用户提供需求,AI 产出文档"。这种方式在游戏策划场景下有一个根本问题:创作者往往只有模糊的创意直觉,还不具备将其拆解为系统策划、关卡设计、数值平衡等专业模块的能力。
本体系在创意阶段引入一个游戏创意框架完善工具(game-creative-discussion)。它基于交互设计五要素(用户、场景、目的、媒介、行为),通过三层递进结构引导创作者完善一份用户确认的"游戏创意框架":
game-creative-discussion │ ├── 第一层: 策略分析 (交互设计五要素的"用户/目的/媒介"前置) │ ├── 用户 (玩家分析) │ │ ├── Bartle 分群 (探索/成就/社交/杀手) │ │ ├── 认知模型 (感官/认知/行为三层) │ │ └── 心理效应 (心流/损失厌恶/沉没成本/社会认同) │ ├── 目的 (玩家动机) │ │ ├── 内部动机 (好奇心/掌控感/成就感) │ │ ├── 外部动机 (奖励/竞争/社交驱动) │ │ └── 引导设计方向 (新手/功能/付费) │ └── 媒介 (游戏设备环境预判) │ ├── 目标平台 (PC/主机/移动/VR/云) │ ├── 输入方式 (键鼠/手柄/触屏/体感) │ └── 使用情境 (碎片化/沉浸/客厅/移动) │ → 产出: 玩家画像 + 核心动机 + 媒介约束 │ ├── 第二层: 创意发散 (原有5维度, 接收第一层输入) │ ├── 游戏类型与核心机制 (← 媒介: 玩法载体) │ ├── 目标受众与平台 (← 用户+媒介: 已部分确认) │ ├── 视觉风格与情绪体验 (← 媒介: 表现形式) │ ├── 核心循环与玩法深度 (← 行为: 玩家行为循环) │ └── 风险与可行性 │ → 产出: 初步设计大纲 │ └── 第三层: 功能规划 (交互设计五要素的"行为/场景"细化) ├── 行为 (玩家交互行为规划) │ ├── 核心玩法流程 (玩家做什么) │ ├── 操作方式与反馈设计 (怎么操作) │ └── 模块互联方向表 (各模块行为如何衔接) ├── 场景 (特定场景下的游戏需求) │ ├── 设计思路三角 (认知-情感-操作平衡) │ └── 社交行为矩阵 (竞争/合作/冲突/表达) └── 交互五要素自检 ├── 用户: 玩家画像是否清晰? ├── 媒介: 设备环境是否确认? ├── 目的: 核心动机是否明确? ├── 场景: 特定场景下的游戏需求是否明确? └── 行为: 核心循环是否闭环? → 产出: 创意大纲 + 策略要点 + 互联方向 + 五要素自检报告
互联方向表 (创意发散阶段产出, 各模块据此细化): 【五要素确认】 - 用户: 硬核竞技玩家 (Bartle 杀手型 + 成就型) - 媒介: PC 端, 键鼠操作, 沉浸式长时间游玩 - 目的: 竞争驱动 + 成就感 - 场景: 竞技对抗场景 (排位/匹配需求) - 行为: 匹配 → 对战 → 结算 → 解锁 → 再匹配 【模块互联方向】 ├── 关卡 ←→ 战斗: 每关是一场对战, 战斗策划定义对战机制 ├── 关卡 ←→ 数值: 关卡难度=对手强度, 数值策划平衡 ├── 系统 ←→ 关卡: 解锁新对战模式作为关卡奖励 └── 角色 ←→ 战斗: 角色技能直接影响对战平衡 【各模块细化指引】 - game-level-design → 把"对战"作为关卡核心, 细化匹配节奏、地图设计 - game-combat-design → 细化对战机制、技能设计、伤害公式 - game-numerical-design → 平衡对战数值、角色强度 - game-character-design → 角色设计考虑对战平衡
传统 GDD 流程通常是一条固定流水线:系统→关卡→战斗→剧情→角色→数值,所有游戏走同一条路。问题在于不同游戏类型对策划模块的需求差异极大——解谜游戏不需要战斗策划,竞技游戏不需要剧情策划,抽象益智游戏可能连角色设计都不需要。
本体系采用核心层 + 类型模块池的二层架构:
确认游戏类型后,系统根据预设的匹配表自动推荐模块组合(如 RPG 全选、解谜只选关卡、模拟经营可选角色),用户可调整。这让同一套方法论不改流程本身,仅通过模块选取的不同,覆盖 11+ 种游戏类型。
11 个技能按"核心 + 类型池 + 组装器"分为三层。核心特性是灵活组合——任意阶段可介入,单模块也能用,不强制产出整个游戏。
| 技能 | 职责 |
|---|---|
系统策划 game-system-design |
从系统关键词出发,通过 6 大知识库(资源循环、成长系统、社交匹配、随机系统、进度系统、商业化系统)产出系统策划案,只定义决策项 |
数值策划 game-numerical-design |
战斗数值推导、经济系统数值推导、成长曲线设计,附带完整公式与演算实例 |
美术生产 game-art-production |
原画三阶段(概念→细化→终稿)、场景、特效、动画、UI 五大方向的 AI 提示词模板和资源输出规格 |
QA 测试 game-qa-testing |
覆盖剧情数值测试、玩法战斗测试、角色单位测试三大方向,P0-P3 优先级分级 |
技术实现全链路 game-tech-implementation |
规范层(配置表 JSON Schema、状态机模板、字段映射、网络同步策略)+ 执行层(技术选型、引擎对比、代码生成与审查) |
| 技能 | 职责 |
|---|---|
创意框架完善 game-creative-discussion |
游戏创意框架完善工具,基于交互设计五要素,通过三层递进产出用户确认的框架,全流程建议都走 |
关卡策划 game-level-design |
节奏控制、空间设计、难度梯度,适配有关卡/阶段的游戏 |
战斗策划 game-combat-design |
攻击手感参数(3 种节奏 × 8 项参数)、Boss 战模式、伤害公式 |
剧情策划 game-narrative-design |
剧情大纲→迭代修订→文本润色→逻辑校验的四阶段工作流 |
角色与单位设计 game-character-design |
原型调研→设定生成→美术方向→评审优化→变体扩展的五阶段流程 |
| 技能 | 职责 |
|---|---|
GDD 组装器 game-full-workflow |
GDD 组装器 + 一致性校验器,整合各模块产出,校验前后逻辑,输出完整 GDD |
核心价值:不管在游戏设计的哪个阶段,都能通过这个方式来完善并产出完整的内容,也可以只针对某一模块进行方案的发散,不用局限于一定得产出整个游戏,在任何阶段都能有产出。
这是本体系在架构设计上的一个关键创新。技能之间遵循"解耦但有协作边界"的原则:每个技能职责单一,不重复产出其他技能的内容;技能间通过跳转指引和引用协作,而非各自包含完整内容。
game-full-workflow 作为组装器,负责整合各模块并校验前后逻辑一致性为了消除"详见 xxx"这类歧义措辞(既可理解为"去查阅已有内容"导致目标模块无内容时卡死,也可理解为"去产出"语义不清),统一了三种引用语规范:
| 引用类型 | 措辞 | 语义 | 示例 |
|---|---|---|---|
| 协作式 | "由 xxx 产出" / "由 xxx 基于本模块的 XX 反推产出" | 目标模块从零工作,不需要前置内容 | 数值参数由 game-numerical-design 基于设计意图反推产出 |
| 查阅式 | "见 xxx" / "参见 xxx" | 目标模块需已有内容,本模块直接引用 | 角色清单见 game-character-design |
| 前置依赖 | "需先完成 xxx" | 明确标注先后顺序,未完成则本模块无法进行 | 需先完成 game-character-design 的角色清单 |
这个规范看似细节,实际解决了 AI 智能体在技能间跳转时的一个关键歧义——它现在能明确知道是去产出、去查阅、还是需要先完成前置,避免"引导去某模块但该模块无内容"的卡死场景。
创意框架完善阶段会产出一张"模块互联方向表",作为各模块细化的指导方向。只记录方向,不涉及具体设计。
| 模块 A | ←→ | 模块 B | 互联关系 | 细化指引 |
|---|---|---|---|---|
| 关卡 | ←→ | 战斗 | 每关是一场对战 | game-level-design 把对战作为关卡核心;game-combat-design 定义对战机制 |
| 关卡 | ←→ | 数值 | 关卡难度=对手强度 | game-numerical-design 平衡对战数值 |
| 角色 | ←→ | 战斗 | 角色技能影响对战平衡 | game-character-design 考虑平衡性 |
各模块拿到方向后,在自己的技能内细化具体设计。
game-full-workflow 的定位是 GDD 组装器 + 一致性校验器——核心场景是用户已经产出了游戏的各个模块内容,输入后由本技能进行内容整合 + 前后逻辑校验 + 冲突检测,最终输出一份统一、自洽的完整 GDD。
这是组装器区别于"简单拼接"的关键价值。组装时必须对以下维度做交叉校验,发现冲突即输出冲突报告:
| 校验维度 | 校验目标 | 冲突示例 |
|---|---|---|
| 数值自洽性 | 系统↔数值↔战斗三方数值算平 | 数值策划 HP=440,但战斗策划设计意图是"打3轮",算出来要打4轮 |
| 角色一致性 | 角色设计↔战斗技能↔美术需求 | 角色设计案有5个技能,战斗策划只配了4个 |
| 配置表字段一致性 | 命名/类型/取值/枚举/默认值 | 战斗策划用 skill_mult,数值策划用 skill_multiplier |
| 状态机一致性 | 枚举冲突/转换互斥/优先级/时机 | 角色状态机有 Attacking,战斗状态机也有但含义不同 |
| 经济系统闭环 | 产出↔消耗↔成长无断层 | 系统策划有"挂机产出",数值策划日产估算没算 |
| 术语/命名统一 | 同一概念用词统一 | 战斗策划叫"体力",系统策划叫"耐力",数值策划叫"ST" |
发现冲突时输出结构化报告,按严重等级分级:
每个冲突附带 2 个以上解决方案及代价,用户选择处理方式后重新校验受影响部分。
┌──────────────────────┐ ┌──────────────────────┐ │ 事前:框架完善 │ │ 事后:一致性校验 │ │ (game-creative- │ │ (game-full-workflow) │ │ discussion) │ │ │ │ │ │ │ │ ├── 策略分析(5要素) │ │ ├── 数值自洽性 │ │ ├── 创意发散(5维度) │ ──→ │ ├── 角色一致性 │ │ ├── 功能规划(互联方向) │ │ ├── 字段一致性 │ │ ├── 五要素自检 │ │ ├── 状态机一致性 │ │ └── 用户确认框架 │ │ ├── 经济闭环 │ │ │ │ └── 术语统一 │ │ 减少事后返工 │ │ 最后一道防线 │ └──────────────────────┘ └──────────────────────┘
事前框架化减少冲突数量,事后校验兜底解决遗漏,形成完整保障。
基于 TypeScript + Node.js,使用 @modelcontextprotocol/sdk 的 McpServer 类和 StdioServerTransport,参数校验用 zod。不依赖 js-yaml,使用正则解析 YAML frontmatter(字段结构简单,无需完整 YAML 解析器)。
| 工具 | 作用 |
|---|---|
| list_skills | 首选入口:列出所有技能的 name + description(含"何时使用 + 能力 + 边界"),LLM 据此选择 |
| get_skill | 获取指定技能的完整 SKILL.md 内容,命中 LRU 缓存时免重复读取磁盘 |
| get_reference | 获取技能的参考资料文件(如有) |
推荐使用流程是:
list_skills 查看所有技能的 descriptionget_skill 获取完整工作流这种做法让 LLM 用自身的语义理解能力选 tool,而非依赖 server 端的关键词打分——对中文同义词和俚语场景(如"肉鸽"匹配 Roguelike)更准确。
每个技能的 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 条),重复调用同一技能直接返回内存数据。
每个技能目录只需包含一个 SKILL.md,frontmatter 必须包含两个字段:
--- name: "game-combat-design" description: "何时使用:需要设计战斗系统、攻击手感、技能连招、Boss战模式或伤害公式的结构设计时。能力:基于攻击手感参数(前摇/后摇/命中停顿/击退)、Boss战模式和伤害公式标准形式产出可落地的战斗策划案。边界:只定义设计意图,具体数值反推归 game-numerical-design。" ---
description 字段是 LLM 选择技能的核心依据,采用"何时使用 + 能力说明 + 边界"三段式。
| 指标 | 数值 |
|---|---|
| 技能数量 | 11 个独立技能 |
| 覆盖游戏类型 | 11 种(RPG / ARPG / 动作 / 策略 / 收集 / 解谜 / 模拟 / 竞速 / FPS-TPS / MOBA / Roguelike) |
| npm 包名 | @chantezy/mcp-game-design |
| 开源地址 | https://github.com/chantezy/game-skills |
npm i @chantezy/mcp-game-design
在任何支持 MCP 的客户端(Claude Desktop、Cursor、Trae 等)中配置:
{
"mcpServers": {
"game-design": {
"command": "npx",
"args": ["--yes", "@chantezy/mcp-game-design@latest"]
}
}
}
这套体系的本质,是把游戏策划的专业经验结构化为 AI 可消费的技能。让 AI 成为策划的合格助手——能做深度设计决策、能保持多模块一致性、能直接对接开发实现。
核心设计是模块组合的灵活性——不管在游戏设计的哪个阶段,都能通过这个方式来完善并产出完整的内容,也可以只针对某一模块进行方案的发散,不用局限于一定得产出整个游戏。这使得它既是一套游戏策划方法论,也是一套可即插即用、按需组合的 AI 工具。
通过描述直接完善整个方案内容,生成独立的模块文档。
生成独立的模块文档:
游戏策划只解决游戏要怎么做的策略问题,没有解决游戏直接制作的环节,所以我做了 cocos-mcp,通过 AI 对画布的控制进行内容的生成。
输入已有的策略文档,可以直接控制内容生成。
npm i @chantezy/cocos-bridge
接入 MCP 后,可以直接对编辑器进行控制。cocos-bridge 提供 16 个意图级工具(项目脚手架 & 资源、代码生成、场景 & UI)+ 1 个通用回退工具(兜底),共 17 个工具:
| # | 工具名称 | 作用 |
|---|---|---|
| 1 | generate_project_scaffold | 根据游戏类型+架构+功能标志生成完整项目目录结构、tsconfig 和基础框架代码 |
| 2 | generate_config_files | 根据 GDD Schema 定义生成 JSON 配置文件、TypeScript 接口和 ConfigLoader |
| 3 | generate_component_scripts | 根据组件属性列表生成 @ccclass 组件 .ts 文件和 @property 装饰器 |
| 4 | generate_state_machine | 根据状态枚举和转移规则生成 State enum + StateMachine class |
| 5 | build_scene_from_config | 根据关卡配置 JSON 构建场景节点层级(地形/灯光/相机/出生点) |
| 6 | build_ui_layout | 根据 UI 布局定义构建 Canvas 下的 UI 节点树和组件绑定 |
| 7 | build_combat_setup | 根据战斗场景配置构建角色节点、碰撞体、相机跟随和 UI 面板 |
| 8 | populate_level_enemies | 根据敌人刷新点列表生成敌人 Prefab 实例和刷新逻辑脚本 |
| 9 | import_and_organize_assets | 根据源目录和命名规则自动分类导入资源(sprites/audio/prefabs 等) |
| 10 | validate_asset_references | 检查项目目录中的断裂引用和孤立资产,输出报告 |
| 11 | apply_naming_convention | 根据目录和命名规范批量重命名资源并生成校验报告 |
| 12 | check_config_consistency | 校验配置目录中的字段类型、范围和引用一致性 |
| 13 | audit_project_health | 项目全面体检:结构/资产/场景/脚本/配置 |
| 14 | inspect_scene_graph | 查看场景文件的节点层级、组件和属性树 |
| 15 | get_project_context | 获取项目路径、引擎版本、场景列表和脚本统计信息 |
| 16 | capture_scene_snapshot | 捕获当前场景的节点树、组件和变换信息快照 |
| 17 | execute_script | 在场景或编辑器上下文中执行任意 JavaScript 代码(通用回退工具) |