做有区别的方案，再比较

来源：emil-prototype/SKILL.md 与 PICKER.md。注意这个目录名叫 emil-prototype，但 frontmatter 的 name 是 prototype。调用名称和宿主注册规则要核对，不能仅凭文件夹名称猜。

15.1 它解决什么问题

同一个组件可以有不同布局密度、信息层级、性格和交互。先探索几个可行方向，再选择集成，能够避免只在一个方向反复小修。它不是现有 UI 审查，也不是依赖选型。

15.2 什么才算不同方案

默认 3 个，明确需要时最多 5 个；每个方向先命名并写差异轴，例如 Quiet（低运动）、Editorial（信息主次）、Dense（高密度）。只换颜色、圆角、文案不算三个方向。

各方案都要能独立成立，真实交互、合理产品内容、满足性能和无障碍；不能拿一个故意粗糙的方案陪衬“推荐答案”。

15.3 六个阶段

1. 缩小范围，一次比较一个组件。

2. 侦察技术栈、颜色/字体/间距/曲线 tokens、品牌和周边上下文。

3. 先列方向及差异轴，防止做着做着全部趋同。

4. 在隔离路由或独立 HTML 中做 picker，生产代码不依赖原型。

5. 每个方案跑通、无控制台错误，在真实尺寸和上下文中比较。

6. 选定后只集成赢家，按用户要求清理或保留原型。

原工作流的选择环节由用户完成；若用户已授权具体方向，按已有决策执行，不把每个样式细节再变成审批。

15.4 Picker 是比较工具，不是候选设计

PICKER.md 规定固定深色浮动胶囊，默认底部居中 24px；如果会挡住底部抽屉/Toast，则置顶。样式不随候选品牌变化，避免比较工具成为额外变量。一次只显示一个完整尺寸方案，不用缩略并排图替代实际体验。

这个例外说明作者也会根据影响范围允许 width 动画，不能把性能总纲理解为不许讨论的语法禁令。

15.5 键盘、URL 与重播

数字 1–N 与左右方向切换，R 重播；焦点在 input/textarea/select/contenteditable 或按修饰键时忽略快捷键。只有一个按钮标 active 与 aria-current。URL ?v=2 保存选择，刷新恢复；重播重挂载当前方案，切换重挂载新方案。

重挂载会重置局部状态，适合原型回到起点，但不应无意用于生产表单。URL 参数先校验并限制在 1–N；原参考代码最简写法没有充分处理越界值。快速多次切换要取消过期 rAF，避免晚到的挂载覆盖当前方案。

15.6 测量高亮滑块

读激活按钮 offsetLeft/offsetWidth，再更新滑块 transform/width；resize、字体加载、文案变化可能改变尺寸。样式规范要求保持一致，但工程适配仍要保证窄屏、焦点可见和触屏命中可用。原示例 innerHTML 只应渲染可信内容，不将未处理用户字符串直接拼进去。

15.7 交付方案而不是替用户暗选

比较表写方案、差异轴、适用场景、成本。可说明推荐理由，但不隐藏另外方案的真实优势。需要下一轮时围绕有希望的方向继续发散，而非再输出三种配色。

原文指令 riff 是再探索，keep 是集成，keep 并保留 picker 则保留原型。它们是这个工作流的命令约定，不是所有宿主天然支持的命令。

Skill 的实现方式

主文件约束发散与隔离，PICKER 固定比较机制。把“不可变化的实验工具”和“需要变化的候选方案”分开，有利于公平比较，也减少 AI 在无关工具栏上发挥。

自测与答案

1. 三个方案只有主色不同，算完成吗？不满足有意义的差异轴。

2. 为什么方案切换不做慢过渡？比较是高频动作，过渡会影响判断。

3. 原型运行正常就能直接合入吗？还需按生产约定集成并验证实际上下文。