Game Design Polish

---
name: "game-design-polish"
description: "为游戏系统设计文档和策划案提供专业润色和优化服务，包括结构优化、文本润色、功能细化和策划指导；当用户需要优化游戏策划文档、提升文档专业度、或需要基于同类型产品获取优化建议时使用"
priority: 0.5
imported-from: "minimax"
source-path: "minimax/skills/game-design-polish/SKILL.md"
---
# 游戏策划文档润色

## 任务目标

- 本 Skill 用于：为半成品或待优化的游戏系统设计文档和策划案提供专业的润色和优化服务
- **文档类型范围**：仅处理游戏系统涉及文档和游戏策划案（两者不分家），不处理美术需求文档、运营策划文档、测试用例文档、市场分析文档
- 能力包含：结构优化、文本润色、功能细化、策划指导增强、辅助说明补充、独立文档生成
- 触发条件：用户需要优化游戏策划文档、提升文档专业性、需要基于描述获取优化建议、或需要基于原型图生成完整文档

## 润色原则

### 核心原则（强制遵守）

- **基于文档本身**：所有优化和拓展必须严格基于原文档内容，不得脱离原文范围
- **禁止胡编乱造**：不得凭空想象或添加原文未提及的功能、机制或设定
- **保持原意**：润色过程中保持原文的核心功能和设计意图不变
- **补充式优化**：仅对简略或略过的细节进行细化，不创造新内容
- **场景化拓展**：补充细节时必须基于游戏功能场景进行合理拓展，确保补充内容的合理性和实用性

### 润色深度策略

- 采用**中等策略和积极策略之间**的润色深度
- 对于简略描述的功能点，主动补充基于游戏场景的合理实现细节
- 补充的内容包括：基本功能流程、常见状态定义、典型异常处理、合理边界条件
- 对于非文档本身的内容（凭空拓展或建议），必须明确标注为"（建议）"或"（补充）"

### 专业化表达

- **纯策划角度**：从游戏策划角度描述功能，不涉及程序和美术的具体实现细节
- **逻辑清晰**：功能描述需包含明确的输入、处理、输出逻辑
- **细节充分**：确保每个功能点都有足够的策划细节，指导开发理解需求

### 多文档一致性维护

- **记忆机制**：在会话中记住之前处理过的文档中的特定名词、设定、术语
- **一致性维护**：润色新文档时，确保与之前文档中的特定名词、设定保持一致
- **静默处理**：自动调整表述以保持一致，不提醒用户，不做任何注释说明
- **适用范围**：仅适用于特定名词、设定、术语的一致性，不涉及功能逻辑的一致性检查

### 内容边界（强制遵守）

- **文档定位**：这是策划写给程序和美术看的需求文档
- **不加入的内容**：
  - **设计要点**：这是策划心里考虑的事情，无需在文档中表述
  - **用户体验**：这是策划心里考虑的事情，无需在文档中表述
  - **数据安全**：这是程序考虑的事情，无需在文档中表述
- **文档内容范围**：仅描述"是什么"、"做什么"、"怎么做"（从策划角度）
- **明确职责分工**：
  - 策划：描述功能和需求
  - 程序：考虑数据安全和实现细节
  - 美术：考虑视觉效果和用户体验

### 质量验收优先级

1. **准确性**：功能描述准确无误，无歧义，符合设计意图
2. **完整性**：覆盖所有必要细节，无遗漏，考虑各种场景
3. **专业性**：术语使用准确，符合游戏策划行业规范
4. **可读性**：文档结构清晰，表达易于理解
5. **可执行性**：开发人员能够基于文档理解需求并实现功能

## 工作流程

### 场景一：用户提供待润色文档

#### 步骤1：文档分析与理解

1. 全面阅读文档：完整理解原文档的功能范围、设计意图、业务逻辑
2. 识别完成度：判断文档的完整程度（50%或80%等），识别需要优化的区域
3. 学习写作风格：参考 [references/sample-document.md](references/sample-document.md)，理解用户的写作习惯、术语使用、文档组织方式
4. 列出优化清单：基于原文档，规划需要优化的具体项（结构、文本、细节、辅助说明）
5. 维护一致性：确保文档中的特定名词、设定与之前处理过的文档保持一致

#### 步骤2：结构与排版优化

1. 结构审查：检查文档结构是否清晰、层次是否合理
2. 调整目录结构：
   - 确保章节划分合理，同级内容层级一致
   - 功能模块完整，无遗漏或重复
   - 相关内容聚合，避免碎片化
3. 排版优化：
   - 统一标题层级和编号规则
   - 使用列表、表格等提升可读性
   - 合理使用空白和分段，控制段落长度
   - 确保列表层级清晰，避免重复或混乱
   - **列表使用规则**：
     - 单行内容（不超过50字）不使用列表，直接使用段落
     - 多行内容或多要点内容使用列表
     - 避免为追求工整而过度使用列表导致冗余
4. 副标题灵活性：
   - 根据功能复杂度灵活选择副标题
   - 简单功能无需副标题，直接描述
   - 中等复杂度功能使用单个副标题（如"界面元素"、"功能概述"）
   - 复杂功能根据实际需要选择必要的副标题（如"功能描述"、"交互逻辑"、"状态定义"）
   - **禁止生搬硬套固定模板**：不要每个功能都使用"功能描述、触发流程、交互逻辑"
   - 副标题应准确反映内容性质，观感应自然流畅
5. 交叉引用：确保章节间引用关系清晰准确

#### 步骤3：内容润色与细化

1. 文本润色：
   - 优化表达方式，使其更简洁、清晰、易懂
   - 统一术语使用，确保前后一致
   - 调整句式结构，提升专业性和可读性

2. 功能细化：
   - 对简略描述的功能点，基于游戏场景主动补充合理的实现细节
   - 明确功能的输入、处理、输出（从策划角度，不涉及具体数据结构）
   - 补充常见异常情况的处理逻辑
   - 明确状态定义、规则约束、边界条件
   - 对于非文档本身的内容（凭空拓展或建议），标注为"（建议）"或"（补充）"
   - **副标题灵活性**：根据功能复杂度灵活选择副标题，**禁止生搬硬套固定模板**

3. 场景化拓展：
   - 基于游戏功能场景，补充合理的交互细节和用户行为
   - 考虑典型使用场景，补充相关的功能分支
   - 确保补充内容符合游戏类型和目标用户特征

#### 步骤4：策划指导增强

1. 面向整体开发团队：
   - 从游戏策划角度描述功能和需求
   - 详细描述业务逻辑流程和规则
   - 补充状态机和状态转换规则（从策划角度，不涉及具体实现）
   - 明确异常情况和处理方案（从游戏体验角度）

2. 面向美术（策划角度）：
   - 描述界面元素的功能定位和交互行为
   - 描述动画、特效的触发条件和预期表现（不涉及具体参数）
   - 描述不同状态的视觉差异（不涉及具体尺寸、颜色值）
   - 提供参考示例或类似游戏中的表现

3. 面向程序（策划角度）：
   - 描述业务逻辑和功能需求
   - 描述数据流转和状态变化（不涉及具体数据结构）
   - 描述接口的业务语义（不涉及具体API定义）
   - 描述错误处理的业务规则（不涉及具体错误码）

#### 步骤5：辅助说明补充

1. 流程图：
   - 对复杂逻辑流程绘制流程图
   - 明确决策节点、分支条件、结束条件
   - 标注关键业务逻辑流转
   - 参考流程图规范：见 [references/flowchart-guide.md](references/flowchart-guide.md)

2. 表格：
   - 状态定义表：列出所有状态及其特征
   - 参数配置表：列出可配置参数及其范围（从策划角度）
   - 映射关系表：明确数据之间的对应关系
   - 优先级表：定义规则或事件的执行优先级

3. 示例：
   - 为复杂功能提供典型使用场景示例
   - 为抽象概念提供具体实例
   - 为补充的建议内容提供说明

#### 步骤6：质量检查

1. 准确性检查：确保功能描述准确无误，符合设计意图
2. 完整性检查：确保所有功能点都有详细描述，无遗漏
3. 专业性检查：确保术语使用准确，符合行业规范
4. 可读性检查：确保文档结构清晰，表达易于理解
5. 可实现性检查：确保描述的功能可被开发理解和实现
6. 排版检查：确保列表层级清晰，避免重复或混乱
7. 内容边界检查：确保不加入设计要点、用户体验、数据安全等内容

#### 步骤7：文档输出

1. 生成独立文档文件：
   - 将润色后的文档内容生成独立的文档文件（如 Markdown 或 Word 格式）
   - 文档命名规范：原文件名_润色版.md 或 原文件名_优化版.md
   - 确保文件包含完整的版本记录和修改说明

2. 修改说明：
   - 在文档开头添加"修改说明"章节
   - 列出主要的优化点和补充内容
   - 对于非文档本身的内容（凭空拓展或建议），标注为"（建议）"或"（补充）"

### 场景二：用户未提供文档，仅提供描述

**注意**：默认情况下，此场景仅提供建议和优化方向，不生成完整文档。只有用户明确要求生成完整文档时，才生成完整文档。

#### 步骤1：需求理解

1. 理解用户意图：明确用户想要设计的游戏类型、核心玩法、目标平台
2. 识别关键信息：提取用户描述中的核心功能、特色机制、目标用户
3. 判断触发条件：用户是否明确要求生成完整文档

#### 步骤2：建议生成（默认模式）

1. 分析需求合理性：评估用户描述的功能是否合理、是否可行
2. 提供优化建议：
   - 指出功能设计中的潜在问题或不足
   - 提供优化方向和改进建议
   - 建议参考的同类型产品或成熟方案
3. 提供文档框架建议：
   - 建议文档的章节结构
   - 建议需要重点关注的内容
   - 建议优先完善的功能模块

#### 步骤3：完整文档生成（仅当用户明确要求时）

1. 基于同类型产品：参考同类型游戏的成熟设计方案
2. 结构化输出：
   - 按照标准游戏策划文档结构组织内容
   - 根据系统复杂度灵活调整系统概述的详细程度
   - 简单系统用一段话概括，复杂系统分点列举核心功能
3. 标注不确定性：明确标注假设和待定项
4. 提供文档文件：生成独立的文档文件供下载

### 场景三：用户提供原型图

**说明**：用户仅提供原型图、少量原型图描述和简单内容描述，需要基于原型图、描述、常识、网络信息等多种信息源推断并生成高质量文档。场景三的核心意义是减少用户工作量，用户会根据生成的文档进行细化和调整，因此输出的文档质量应接近场景一（有文档）的完整度，能够有效指导开发。

#### 步骤1：原型图理解

1. **深度分析原型图**：
   - 识别界面结构和布局
   - 识别界面元素（按钮、输入框、列表等）
   - 识别交互关系和跳转逻辑
   - 识别状态变化和视觉反馈
   - 推断隐含功能和交互细节
2. **理解原型图描述**：
   - 结合少量描述确认功能意图
   - 理解各元素的作用和关系
   - 识别关键功能和次要功能

#### 步骤2：信息提取与推断

1. **功能信息提取**：
   - 从原型图中提取可见功能
   - 从少量描述中提取隐含功能
   - 整合信息，构建完整的功能清单
2. **交互逻辑提取**：
   - 提取用户操作路径
   - 提取系统响应逻辑
   - 提取异常处理场景
   - **补充边界条件和异常处理**：主动补充输入限制、边界条件、异常处理场景（标注为"建议"）
3. **数据关系提取**：
   - 识别数据输入来源
   - 识别数据展示内容
   - 识别数据流转关系（从策划角度）
4. **多信息源深度推断**（关键）：
   - 从原型图中提取可见功能和交互逻辑
   - 从少量描述中提取隐含功能和业务意图
   - **基于常识推断标准功能和常见交互**：达到中度推断深度（如搜索框支持实时搜索、搜索历史、清空等）
   - **主动使用网络信息**：参考同类型产品的成熟方案和行业范例
5. **网络信息检索**（质量提升关键）：
   - 主动搜索同类型产品的功能设计
   - 参考行业标准和最佳实践
   - 参考知名游戏的成熟方案
   - 结合网络信息补充完善的功能描述

#### 步骤3：文档生成（高质量）

1. **文档结构规划**：
   - 根据提取的功能信息规划文档结构
   - 确定主要功能模块
   - 确定文档类型（系统设计文档、功能说明文档等）
   - 确保结构完整，接近场景一的完整度
2. **内容填充**：
   - 按照标准文档结构组织内容
   - 基于多种信息源（原型图、描述、常识、网络信息）推断并生成详细功能描述
   - **中度推断深度**：对每个功能进行中等深度的推断，补充必要细节
   - 用户描述和原型图不一致时，以用户描述为准
   - 都不明确时，自己推断并在文档中标注不一致，让用户确认
   - **主动补充边界条件和异常处理**：补充输入限制、边界条件、异常处理（标注为"建议"）
   - 确保内容符合策划角度，不加入设计要点、用户体验、数据安全
   - 根据系统复杂度灵活调整，保持专业度
3. **系统概述编写**：
   - 根据系统复杂度灵活调整
   - 简要介绍系统功能和包含的主要模块
   - 如果用户未提供，从原型图和描述中推断
4. **辅助说明补充**（质量提升关键）：
   - **尽可能生成流程图**：对复杂功能生成流程图，帮助理解交互逻辑
   - **尽可能生成表格**：生成状态定义表、参数配置表等结构化信息
   - 信息不足时，基于原型图、系统功能、用户描述综合推断并生成
   - 为复杂功能添加示例
5. **一致性维护**：
   - 保持与之前文档中特定名词、概念、定义的一致性
   - 如果不一致，进行调整
   - 如果不确定是否为同一个东西，询问用户

#### 步骤4：质量检查（严格）

**目标**：输出文档的完整度应接近场景一（有文档），能够有效指导开发

1. **准确性检查**：确保功能描述准确反映原型图、描述和网络信息
2. **完整性检查**：确保覆盖原型图中的所有主要功能，补充必要的边界条件和异常处理
3. **专业性检查**：确保术语使用准确，符合行业规范
4. **可读性检查**：确保文档结构清晰，表达易于理解
5. **系统性检查**：确保功能之间的关系清晰，文档具有系统性
6. **内容边界检查**：确保不加入设计要点、用户体验、数据安全等内容
7. **辅助说明检查**：确保复杂功能配有流程图和表格

#### 步骤5：文档输出

1. **生成独立文档文件**：
   - 将生成的文档内容生成独立的文档文件（如 Markdown 或 Word 格式）
   - 文档命名规范：从原型图的主要功能及描述关键词综合推断系统名称，格式为 [系统名称]_系统设计.md
   - 说明章节：根据模板和具体情况灵活决定命名（如"文档说明"、"说明"等），保持专业度即可

2. **标注说明**（可选）：
   - 在文档开头或相应位置添加说明
   - 说明文档基于原型图、描述、常识、网络信息等推断生成
   - 标注所有建议性的补充内容
   - 标注用户描述和原型图不一致的地方，供用户确认

## 资源索引

- 写作风格参考：见 [references/sample-document.md](references/sample-document.md)（用户的实际文档案例，用于理解写作习惯）
- 写作规范标准：见 [references/prescription-standard.md](references/prescription-standard.md)（策划文档的标准格式和规范）
- 文档模板集：见 [references/documentation-templates.md](references/documentation-templates.md)（不同类型游戏文档的模板）
- 流程图指南：见 [references/flowchart-guide.md](references/flowchart-guide.md)（流程图的绘制规范和示例）

## 输出规范

### 文档结构要求

- **文档结构要求**：包含版本号、修改内容、修改人、修改日期
- **修改说明**：列出本次润色的主要优化点和补充内容，对于非文档本身的内容标注为"（建议）"或"（补充）"
- **生成说明**：对于基于原型图生成的文档，说明文档基于原型图和描述生成
- **目录结构**：清晰的章节划分和编号
- **功能模块**：每个功能模块包含完整的描述、逻辑、交互、规则

### 内容质量标准（按优先级排序）

1. **准确性**：功能描述准确无误，无歧义，符合设计意图
2. **完整性**：覆盖所有必要细节，无遗漏，考虑各种场景
3. **专业性**：术语使用准确，符合游戏策划行业规范
4. **可读性**：语言清晰，逻辑顺畅，易于理解
5. **可执行性**：开发人员能够基于文档理解需求并实现功能

### 格式要求

- 使用统一的标题层级（# ## ### ####）
- **列表使用规则**：
  - 单行内容（不超过50字）不使用列表，直接使用段落
  - 多行内容或多要点内容使用列表
  - 避免为追求工整而过度使用列表导致冗余
- 使用表格展示状态、参数、映射关系
- 使用流程图展示复杂逻辑
- 代码、参数、界面元素使用行内代码标记

### 文件输出格式

- **默认格式**：Markdown（.md）
- **可选格式**：根据用户需求可提供其他格式（如 .docx）
- **命名规范**：原文件名_润色版.md 或 原文件名_优化版.md，或 [系统名称]_系统设计.md

## 注意事项

- **文档定位**：这是策划写给程序和美术看的需求文档，要站在策划角度
- **文档类型限制**：仅处理游戏系统设计文档和策划案，不处理其他类型文档
- **基于文档本身**：仅基于原文档内容进行优化，不得添加原文未提及的内容
- **场景化拓展**：补充细节时必须基于游戏功能场景，确保合理性
- **标注非文档内容**：对于非文档本身的内容（凭空拓展或建议），必须标注为"（建议）"或"（补充）"
- **保持用户风格**：优化过程中保持用户的写作风格和术语习惯
- **静默维护一致性**：自动维护特定名词、设定的一致性，不做任何提醒或注释
- **排版规范**：确保列表层级清晰，避免重复列表或层级混乱
- **内容边界**：不加入设计要点、用户体验、数据安全等内容
  - **设计要点**：这是策划心里考虑的事情，无需在文档中表述
  - **用户体验**：这是策划心里考虑的事情，无需在文档中表述
  - **数据安全**：这是程序考虑的事情，无需在文档中表述
- **输出方式**：生成独立的文档文件供下载，不在对话中展示完整内容

## 使用示例

### 示例1：润色半成品系统设计文档

**功能说明**：优化一份完成度为60%的游戏后台管理系统设计文档

**执行方式**：智能体主导，按照工作流程逐步润色

**关键要点**：
- 保持原有功能范围不变
- 基于游戏场景补充状态定义、异常处理、边界条件
- 对于非文档本身的内容（凭空拓展或建议），标注为"（建议）"或"（补充）"
- 添加流程图说明复杂业务逻辑
- 从策划角度提供开发指导，不涉及具体技术细节
- 生成独立的文档文件供下载
- 自动维护特定名词、设定的一致性，静默处理

### 示例2：基于描述获取优化建议

**功能说明**：根据用户对"背包系统"的口头描述，提供优化建议和方向

**执行方式**：智能体主导，分析需求并提供建议

**关键要点**：
- 分析功能设计的合理性和可行性
- 提供优化方向和改进建议
- 建议参考的同类型产品
- 提供文档框架建议
- 不生成完整文档（除非用户明确要求）

### 示例3：基于原型图生成完整文档

**功能说明**：根据用户提供的原型图、原型图描述和简单内容描述，生成完整的策划文档

**执行方式**：智能体主导，分析原型图并生成文档

**关键要点**：
- 分析原型图的界面结构、元素布局、交互关系
- 从原型图和少量描述中提取功能信息
- 基于多种信息源（原型图、描述、常识、网络信息）推断并生成详细功能描述
- 用户描述和原型图不一致时，以用户描述为准
- 都不明确时，自己推断并在文档中标注不一致，让用户确认
- 确保内容符合策划角度，不加入设计要点、用户体验、数据安全
- 保持与之前文档中特定名词、概念、定义的一致性
- 生成雏形文档，减少用户工作量
- 这是一个迭代过程，无需过于苛刻，保持专业度即可
- 生成独立的文档文件供下载

### 示例4：多文档一致性维护

**功能说明**：润色"背包系统"文档，之前已经润色过"战斗系统"文档

**执行方式**：智能体主导，静默维护一致性

**关键要点**：
- 自动检查并调整特定名词、设定的一致性
- 不提醒用户，不做任何注释说明
- 以当前"背包系统"文档的润色效果为第一优先级
- 确保列表层级清晰，避免重复或混乱