创意验证（Idea Validation）

核心定义：在大规模投入资源之前，用最小成本，把主观创意转化为可检验的假设，通过实验、原型、观测行为，区分「自嗨构想」和「真正可行的方案」，用来规避知识的诅咒、过度开发带来的沉没成本。 创意验证不是证明创意一定完美，而是尽早证伪错误假设。

对游戏开发：不是把完整游戏做出来再测试，而是优先验证核心循环、核心情绪、核心约束是否成立。

一、完整四阶段流程

阶段1：概念收敛——把模糊想法变成可验证假设

大多数创意死亡源于概念本身模糊。

1. 剥离装饰：美术、剧情、次要系统全部暂时搁置，提取唯一核心命题。
2. 写出一句话概念（对齐SUCCESs的Simple原则）：玩家做什么 → 获得什么体验。

❌坏例子：做一款暗黑风格ARPG，内容丰富，打击爽快。 ✅可验证：玩家通过击杀怪物获取随机词缀装备，持续构筑角色，获得刷装的成就感。

3. 把观点转为If‑Then可证伪假设

假设：如果玩家可以自由拾取随机词缀装备，那么玩家愿意重复游玩核心循环至少8分钟以上。 同时明确：什么算成功，什么算失败。

输出物：1‑3页极简概念文档，只保留核心循环、关键假设、成功/失败判定标准。

阶段2：纸面与思维验证（零代码，成本最低）

不写一行代码，先做逻辑自检。

1. 逻辑自洽检查 魔法圈视角：这套规则能否形成封闭自洽的游戏边界？（苏茨：游戏需要人为设置的非必要障碍，不能把障碍全部删掉）
2. 后向创新推演：如果对这套系统做减法，最小可运行版本是什么？哪些是绝对不能删除的核心，哪些是附属装饰。
3. 知识的诅咒排查：外人是否能一句话听懂你的创意（SUCCESs‑Simple）。找完全不了解项目的人复述你的核心概念，如果讲不清楚，概念本身就有问题。
4. 舍恩定理视角：团队内部，是否有人真正相信这套核心假设；如果团队本身半信半疑，后续实现必然变形。

输出：桌面原型、卡牌原型、Excel数值推演文档。

阶段3：低保真原型验证（核心环节）

原则：一个原型只回答一个关键问题，不要做缩小版完整游戏。

• 不要加剧情、UI美化、大量怪物、完整装备库。
• 只实现能够验证核心假设的最小机制。

游戏行业常用原型手段：

1. 纸面原型：卡牌、表格，人工模拟回合战斗，观测决策是否有趣。
2. 可玩极简原型，只保留核心循环：打怪‑掉落‑更换装备。
3. 数值沙盘：用Excel模拟资源流入流出，提前暴露经济崩坏风险。

测试执行要点：

1. 优先找陌生测试者，避开熟悉项目的团队成员；
2. 测试时不讲解玩法，不主动帮助玩家，纯观察行为；
3. 重点观测行为，而不是听主观评价；玩家嘴上说好，但迅速退出，就是失败信号。

常用观测指标（玩法原型）

• 单次会话时长：无外力干预下能否持续游玩
• 重试意愿：死亡/结束后是否主动再来一局
• 决策多样性：玩家是否出现不同策略，还是只有唯一最优解
• 困惑点：在哪一步发生卡顿、误解规则（魔法圈边界被打破）

阶段4：扩展验证（假设通过之后）

当核心假设被原型确认成立，才开始叠加次要系统、美术、剧情。

1. 横向扩展：把次要机制接入已验证的核心循环，观察会不会破坏原有体验。
2. 小范围封闭测试，观测系统涌现行为（伽达默尔：系统会产生设计者预料之外行为）。
3. 市场信号验证：社群反馈、愿望单、众筹意向等，注意：意向不等于付费行为，仅作为辅助信号。

二、创意验证的三类常见陷阱

1. 原型做的太完整 把原型做成缩小版完整游戏，混杂大量无关功能，分不清是核心玩法有趣，还是美术、剧情带来的短期新鲜感。原型目标是回答一个危险问题，而不是做半成品游戏。

2. 混淆口头反馈和真实行为 问卷、访谈里玩家会说喜欢，但实际操作中并不愿意投入时间。行为＞口头表态。

3. 过度依赖数据扼杀突破性创意

激进创新，不能完全依靠普通玩家测试；成熟范式迭代，更适合数据驱动。完全盲从测试，会消灭真正突破性想法。

平衡原则：

• 成熟品类迭代：以原型测试、用户行为数据为主；
• 高度创新玩法：保留核心设计者审美判断，验证聚焦于「核心循环是否成立」，而不是全部体验。

三、和前面理论串联对照表

理论	在创意验证中的作用
SUCCESs 黏性六原则	Simple：概念收敛；Concrete：原型拒绝抽象描述；Stories：用小故事描述目标体验，辅助写假设
舍恩定理	验证前确认：团队是否真正相信核心假设，否则原型实现会持续走形
魔法圈 Magic Circle	验证观察：玩家是否能够进入游戏规则边界；规则是否自洽，会不会频繁打破沉浸边界
苏茨（蚱蜢）	验证时检查：游戏是否保留「人为非必要障碍」；不要把挑战全部删掉，否则游戏直接消解
伽达默尔	原型阶段就要留意涌现行为；系统运行会产生设计者意料之外结果，不能只看预设目标
后向创新	原型就是后向创新实践：完整构想向下删减，保留内核，剥离附属功能做最小验证版本
维特根斯坦	系统符号意义来自规则；原型测试重点看规则实际运行效果，而不是文档文字

四、游戏策划自检清单（可直接写进博客/文档）

• 是否剥离美术、剧情等装饰，提炼出唯一核心假设？
• 假设是否可以证伪？是否定义清楚成功、失败标准？
• 原型是否只验证一个核心问题，没有做成缩小版完整游戏？
• 是否安排陌生测试人员，不做讲解、不干预，观察真实行为？
• 原型删减之后，游戏必要的人为障碍（挑战）是否还存在？
• 团队内部是否真正认同这套核心构想？
• 是否留意系统涌现行为，而不是只验证设计者预想结果？