快速原型

快速把机制交到玩家手中，以了解它是否值得构建。原型的输出是一个决定（保留 / 砍掉 / 重构），而不是产品。优先考虑学习速度，并在一开始就决定代码是一次性的还是承重的。

何时使用

• 在验证单个机制或“如果……会怎样”、构建垂直切片 / MVP、对关卡或交互进行灰盒，或在投入真实时间前降低想法风险时使用。
• 在用户说“先做出可玩的东西”“这好玩吗？”或“先粗略实现”时使用。

***不* 使用的情况：** 有截止时间和提交物的限时比赛（使用 game-jam）；发布或更新真实发行版本（使用 steam-publish / itch-publish）；构建已验证功能的生产版本（直接使用引擎/类型技能）。

核心工作流

1. 写出唯一问题。 陈述原型必须回答的唯一问题，例如：*“边下落边抓钩的控制是否令人满足？”* 如果你有两个问题，就构建两个原型。测试一切的原型等于没有测试。
2. 在编写代码前决定一次性还是保留。 一次性（*spike*，即一次性原型）：硬编码，无架构，之后删除。保留：仍然粗糙，但目录/命名可以扩展。大多数原型应该是一次性的；假装不是这样，就是原型腐烂进入发行代码库的原因。
3. 设置硬性时间盒（机制为 30-90 分钟；切片为一次专注时段）并放置可见计时器。约束才是重点——它迫使你测试*核心*想法，而不是装饰。
4. 对所有非必要内容进行灰盒。 美术使用原语（方盒、圆形、胶囊），使用内置字体，只保留一个调试音效或没有。问题不依赖的任何内容都零时间投入。
5. 为问题添加检测。 添加屏幕调试文本 / 小工具，显示你正在判断的内容（速度、距离、时机窗口）。你是在测量，而不是装饰。
6. 立即并诚实地试玩。 自己先玩，然后不解释控制方式就交给另一个人。观察他们在哪里遇到困难。
7. 根据砍掉标准做出决定（见下文）。保留 → 安排正式构建并*重写*，不要提升一次性原型。砍掉 → 记录经验并继续前进。重构 → 缩小问题并再次做一次性原型。

模式

1. 原型简报（编码前填写）

QUESTION:     The one thing this must prove (binary if possible).
CORE VERB:    The single action the player repeats.
THROWAWAY?:   yes -> hard-code freely, delete after.  no -> minimal structure to grow.
TIMEBOX:      e.g. 60 min. Stop when it rings, even if unfinished.
KEEP IF:      observable signal that means "fun / worth building" (see kill criteria).
KILL IF:      observable signal that means "stop".

2. 灰盒核心循环，其余全部伪造（引擎无关伪代码）

# Only the CORE VERB is real. Visuals are primitives; systems are stubs.
on update(dt):
    read_input()
    apply_core_mechanic(dt)        # the ONLY thing you're testing — make this feel right
    draw_primitive(player)         # a box. not a sprite. not animated.
    draw_debug_hud(speed, timing)  # show the numbers you're judging
    # enemies, menus, save, audio, art -> stubbed or absent until the verb proves out

3. 砍掉标准——让保留/砍掉的决定可观察，而不是情绪化

KEEP when, with placeholder art:
  - a fresh player does the core verb on purpose within ~30s, unprompted, and
  - you (or they) repeat the loop "one more time" without being asked.
KILL when:
  - the verb only feels good after you explain it, or
  - making it fun needs systems far beyond the prototype's scope, or
  - you're adding art/levels to avoid admitting the verb is flat.
REFACTOR when one variable is clearly off (too slow, window too tight) -> retune, retest.

4. 隔离：让一次性原型不进入发行代码库

prototypes/<idea-name>/      # separate folder or project, never imported by main game
  - hard-coded values, single file ok, magic numbers welcome
  - committed on a throwaway branch (or not at all)
Rule: a "keep" decision authorizes a REWRITE in the real project, not a copy-paste of the
spike. Prototype code carries prototype assumptions; shipping it ships the assumptions.

常见陷阱

• 过早打磨。 美术、菜单和音频会让平淡机制看起来已经完成，并延迟裁决。在动词得到验证前保持灰盒。
• 没有砍掉标准。 如果没有书面的“砍掉如果”，每个原型都“有潜力”，什么都不会被砍掉。在你依恋代码*之前*决定信号。
• 构建系统而不是机制。 库存、存档/读档和设置不是问题。把它们存根化。
• 一次性原型变成了产品。 一次性代码被提升到生产环境，就是带着有趣起源故事的技术债。保留时重写。
• 在真实代码库中原型。 它把实验与发行系统纠缠在一起，使一次性原型删除成本很高。使用独立目录/项目。
• 只测试自己。 你知道控制方式和意图。一名未经指导的外部玩家在两分钟内揭示的信息，比一小时自玩更多。

参考

• 若要在硬性外部截止期限下工作并提交，阅读 game-jam 技能。
• 若要在其中灰盒特定引擎核心循环，阅读该引擎技能（godot-gdscript、phaser-core、love2d-core、unity-csharp-scripting，…）。

相关技能

• game-jam — 将同样的范围纪律应用于有提交物的限时比赛。
• 引擎核心与类型技能 — “保留”决定在那里被正确重建。