mc-prototype git:20261010.79a4f96A

Immutable. This exact content never changes and is served at /api/v1/blob/131fbf2f538c32df.

---
name: mc-prototype
description: 一次性设计原型。当创意/取舍题需要「先看一眼再拍板」——GUI 布局、HUD 信息层级、tooltip 文案排版、配色占位这类屏幕上可呈现的设计选择——用户说「给我看看有几种方案 / 画个样子我选」时激活：做 2–3 个差异明显的单文件 HTML 变体（假数据逐处标注、整份标明一次性件），用户在浏览器里选定，结论回写规格或共识清单。游戏内渲染手感与技术可行性验证不适用本技能；原型不承诺与游戏内像素一致，实现是拍板后另走开发模板的事。
---

# mc-prototype — 先看一眼，再拍板

一句话目标：创意与取舍题最难空想——把「你想要哪种」变成浏览器里点两下就能选的 2–3 个一次性原型，选完即弃。

## 第 1 步 · 定可判定的问题

- 把设计题写成可判真伪的一句：「这个物品栏布局的信息层级对不对」可以；「GUI 做成什么样」不行——后者先收窄再开工。
- 写明拍板后结论去向：mc-spec 的条目 / mc-grill 共识清单——原型答完就完，不留实现债。
- 判适用面：屏幕上能呈现的排版、层级、文案、配色 → 做；游戏内渲染、动画手感、性能、真交互 → 不做，那是游玩自测与 GameTest 的活。

## 第 2 步 · 做变体

- 2–3 个**差异明显**的单文件 HTML 变体（同一入口可切换），别做三个只差间距的伪选项——差异要落在方案层（信息放哪、什么优先），不是像素层。
- 每个变体头部两行：这个方案赌什么（取舍一句话）/ 与游戏内的差异（字体、缩放、渲染——明说哪些地方对不上，别让用户拿原型当真机预览）。
- 假数据逐处标注（「数量 999 为占位」）；素材用色块 / 文字占位，从游戏里抠图当素材要先用户同意。

## 第 3 步 · 交付与回收

- 文件落用户工程指定目录（默认 temp/prototype/<主题>/，先问），浏览器打开给用户选——**选哪个由用户拍板**，agent 只给每案的取舍说明。
- 结论回写：选定方案 + 理由 → mc-spec 条目或共识清单；整份标「一次性件，不提交」，用完即弃。
- 实现是拍板后的事：走对应开发模板（GUI → mc-new-gui 一类），别把原型代码当架构起手。

## 边界

- 原型只答设计题；「技术上做不做得到」不做担保，可行性留给查证与真机。
- 本仓动画演示技能那套（录屏成片向）与本技能无关——那面向成片，这面向用户当场选择。