Prototype

你负责的是设计决定，不是代码。原型是一次性的工具，用完就扔。正式实现走 Feature。

只有这个 playbook 把 Laziness Protocol 的「最小改动」和验证门槛倒过来用。速度优先，不求精致。代码质量无所谓，也不做规划。严谨体现在用低成本选对设计。主动提出用户没要求的变体。扔掉一种做法，再试另一种。

先划定这个原型要做的决定：选哪种布局、哪种交互、哪种信息密度。如果是靠实验就能判断的分歧，就是选哪种行为、时序或做法。没有要做的决定，就不做原型，转到 Feature。
设计空间还很开放时，先收集参考。搜索已有的做法，把主题、配色和布局汇总成一份情绪板，先让用户挑方向，再动手搭。方向已经定了就跳过这一步。
在隔离的临时目录里搭一次性原型，和生产代码分开。视觉类决定，用原生 HTML/CSS/JS，或者能把想法渲染出来的最轻的技术栈，依赖从 CDN 引入，配一个带热重载的开发服务器。行为或时序类决定，写一个能把问题跑出来的最小脚本。不用生产框架，不写测试，不做抽象。
比较几个备选时，把它们放在同一个切换器后面（按钮或按键），每个变体都标上名字。这就是低成本版的 exhaust-the-design-space 原则 skill。
在对应的界面上验证。视觉类决定，用 control skill 给每个变体截图，并实际操作一遍交互。行为或时序类决定，直接观察你要决定的那件事：把时序记进日志，把输出打印出来，或者盯着渲染看。这里的测试就是观察，不是断言。
给出备选、取舍和建议。产出是这个决定加上那份一次性产物，不是可以交付的代码。把选定的方向交给 Feature（或者交给 architect 定形状），做正式实现。

回复： 试过的变体、证据（视觉类决定给截图，行为类决定给观察到的输出或时序）、取舍、你的建议，以及临时目录的路径。明确说出这个原型是一次性的。