game-design-review

游戏设计评审

通过追踪规则和呈现方式可能如何影响玩家的决策与体验，来评审设计。应将评审视为辅助决策的工具，而非通用清单或试玩的替代品。

责任边界

• 当已有设计对象或决策需要审查时，使用此技能。
• 此技能自成一体。不要假设存在任何其他技能、工作流、代码库布局、文档集或游戏引擎。
• 当用户需要的是一份新的正式设计文档，而非评审时，应提供经澄清的方向、约束、待解决问题和验证标准，以便据此编写文档。
• 不要将设计建议直接转化为代码结构、引擎 API 或实现任务。

评审模式

每种评审都遵循相同的基本框架：

1. 明确评审对象。 整款游戏、一个循环、一项机制、一个关卡、一段界面流程、一段叙事、一项社交功能或一个制作决策。
2. 说明待定决策。 一项选择或可测试的问题；如果没有，则指出影响最大的未解决假设。
3. 建立证据基线。 说明受众、规则、约束、原型表现和试玩观察，区分反复出现的模式与个别事例；为每项重要陈述标记 confirmed、assumed 或 unknown。
4. 完成评审。 列出按优先级排序的发现、最小且有效的干预措施，以及验证实验。

各模式的区别在于两端之间如何开展审查。选择最适用的窄范围模式；如无法确定，则采用全面评审。

全面评审（默认）

适用于方向已确定、已有可供审查的正式材料（文档、原型、遥测数据或试玩记录），且目标是全面检查弱点、风险和矛盾的情况。

1. 先排除，再覆盖。 仅排除评审对象明确无关的参考项，至少保留 6 项；记录每项排除及其理由，并在最终报告中说明未评审的领域。
2. 分组并委派。 将其余参考项分成若干组，每组包含 2 到 4 个相关领域；按照下文“将评审委派给子 Agent”的说明，每组交由一个只读子 Agent 处理。若无法使用子 Agent，则由你自行依次处理各组。
3. 追踪影响。 每组的审阅者都要将每项设计选择与玩家获取的信息、决策、行动、反馈和后果关联起来，并区分症状与原因。
4. 合并并协调。 将根本原因相同的重复项合并，统一严重程度，并检查跨领域矛盾；将每项矛盾单独作为一条发现；不要输出一份不加区分的清单。

聚焦评审

适用于所有待评内容都包含在对话中、设计或问题较简短，或仅以用户消息中的笔记或关键词形式存在，且没有正式文档可供阅读的情况。

1. 自行从路由表中阅读 2 或 3 项相关参考内容。
2. 按全面评审中的方式追踪影响，并且只返回可能改变决策的发现。

探索性评审

适用于尚未确定方向、设计尚不成熟而不适合查找问题，且目标是提出备选方向以及能够加以区分的测试的情况。

1. 明确玩家承诺和核心不确定因素。
2. 概述 2 或 3 个连贯的方向。
3. 设计一项能够区分这些方向的小型测试，并在扩展为完整设计文档之前停止。

比较评审

适用于需要在 2 个或更多已明确选项之间做出选择的情况，不论材料多少。

1. 对每个选项采用相同的证据和标准；不要对某个选项进行更严格的评审。
2. 如果比较涉及多个领域，可以为每个选项委派一个子 Agent，并让他们使用相同的参考资料集。
3. 按照全面评审中的方式合并各选项的发现。

将评审工作委派给子 Agent

子 Agent 不会共享此对话，因此请向每个子 Agent 简要说明其所需的一切：

• 评审对象，以及设计材料的位置；
• 当前需要做出的决策和证据基线，避免重新讨论已经确定的事实；
• 分配给它的参考路径，并要求它在分析前完整阅读；
• 下文的发现质量标准，确保发现具有足够的实质内容，可以纳入成果；
• 工作边界：每批次返回设计发现和建议的最小干预方案，而不是实现任务。

子 Agent 报告的形式不限，只要包含上述实质内容即可。绝不要未经审查就照搬子 Agent 给出的严重性或优先级；整合工作由你负责，而不是由它们负责。

参考资料路由

评审关注点	阅读	重点
受众、预期体验、动机、理解	references/experience-and-audience.md	对玩家的承诺、动机链、乐趣清单、学习假设、体验缺口
核心概念、主题、情感、幻想、美学特征、好奇心与新颖性	references/concept-theme-and-emotion.md	概念清晰度、想象空间、主题连贯性、情感成因、表现统一性、令人难忘的特色
行动、目标、规则、信息、能动性、复杂度与策略	references/actions-rules-and-agency.md	目标层级、决策质量、表现评判、规则易懂度、结构与状态、主导行为、系统性特征
挑战、技能要求、风险、惩罚、奖励、进度、经济系统与重玩深度	references/challenge-progression-and-economy.md	难度曲线、技能需求、公平性、预期回报、奖励意义、时间结构、资源来源与消耗、可行路径
谜题、推理、提示、瓶颈与可见进度	references/puzzles-and-problem-solving.md	问题呈现、推理链、解法结构、恢复机制与提示递进
关卡空间、遭遇、导航与节奏	references/space-level-and-pacing.md	路线选择、易读性、节奏、恢复、空间压力
注意力曲线、难忘时刻、间接引导与沉浸感	references/attention-guidance-and-presence.md	随时间变化的兴趣、自主引导、自由度、干扰、代入感与复述体验
操作、UI、反馈与实用的无障碍性	references/interface-feedback-and-accessibility.md	意图到行动的循环、信息时机、反馈丰富度、错误恢复、输入与感知障碍
叙事、世界、角色与玩家创作的故事	references/narrative-world-and-characters.md	可玩形式的故事传达、故事结构、世界因果关系、角色定位、能动性、地位与角色功能
竞争、合作、友谊、社区与有害行为	references/social-community-and-safety.md	玩家间的激励、信任、关系延续、表达、管理与观众理解度
范围、原型、试玩、技术、市场、发行、商业模式与责任	references/production-validation-and-responsibility.md	制作适配度、证据质量、风险消除、市场可行性、可持续性与玩家福祉

发现质量

有用的发现包含：

• 观察： 当前设计或证据表明了什么；
• 机制： 它可能如何影响玩家的理解、选择、行为或感受；
• 证据状态： 已确认事实、有依据的推断、假设或未知；
• 影响： 如果问题确实存在，会造成什么失败；
• 建议： 值得尝试的最小改动；
• 验证： 什么结果会支持或否定该建议。

避免仅凭个人喜好提出发现。缺少证据时，应提出假设和测试，而不是把预测说成事实。

报告结构

使用能解决需求的最简报告。对于正式评审，请使用：

# Design Review: [object]

## Decision at stake
[The choice or uncertainty this review should resolve.]

## Evidence baseline
- Confirmed: ...
- Assumed: ...
- Unknown: ...

## Priority findings
### [Severity] [Finding]
- Observation:
- Mechanism:
- Evidence status:
- Recommendation:
- Validation:

## Tradeoffs
[What improves, what may get worse, and who is affected.]

## Next experiment
[Smallest build, simulation, or playtest; participants; observable signals; decision rule.]

只有在严重程度有助于确定优先级时，才使用 critical、major 或 minor：

• critical：损害核心承诺，或导致无法进行有意义的验证；
• major：严重影响常见的玩家流程，或导致后续返工成本高昂；
• minor：局部体验不佳或润色问题，但不会使当前方向失效。

指导原则

• 不要捏造玩家反应、遥测数据、市场事实或游玩测试证据。
• 不要隐瞒相互冲突的目标。说明其中的权衡，并指出由谁做出最终决定。
• 不要仅为弥补设计弱点而扩展功能集；删除内容、澄清规则或进行较小的规则调整可能更合适。
• 不要规定技术架构。应说明已确认的设计约束和验证标准，以便后续技术流程采用，同时不要求使用特定工具或工作流。