prototype

原型

制作可丢弃的原型，让人们在设计投入开发之前进行评估。原型代码可以是临时的；但原型呈现的所有内容都必须符合其预期产品场景，令人信服。

选择模式

• **UI 模式：**问题在于屏幕、组件或简短流程应呈现何种外观，或应如何操作。请遵循以下流程。
• **逻辑模式：**问题在于逻辑、状态、数据形态、API 或 CLI 行为模型能否经受真实案例的检验。请参阅逻辑模式。

如果问题同时涉及两者，请先在逻辑模式中确定模型，再在 UI 模式中设计界面。

UI 流程

1. 明确设计问题。 说明原型需要帮助决定什么、目标用户、产品使用时机、主要任务与操作、目标平台或视口、相关状态、受保护的行为，以及时间、成本或范围限制。如果方向已获认可，或请求只是局部实现细节，请说明为何比较没有价值，然后停止。
2. 以共同事实为依据。 检查当前产品、渲染后的基准版本、代码库、设计系统、组件、术语、真实数据结构及适用的平台规范。优先采用真实的周边框架、信息密度、内容和运行环境。如果存在来自 shape 或其他产品简报的规格说明，就从中获取用户、问题和状态；对于新产品，添加少量相关参考，但不要照搬。区分观察到的事实、用户选择、假设和可自由探索的部分。
3. 冻结一份中立简报。 向每位设计师提供相同的用户、任务、确切内容、功能、代表性数据、每个候选方案的场景选择器所提供的具名场景、视口、不变量、允许的改动、禁止虚构的内容，以及评估条件。固定产品事实，让比较衡量设计，而非对问题的不同解读。
4. 独立探索不同方向。 默认使用 3 个全新的设计师 Agent，最好来自不同的模型系列，且绝不超过 5 个。为每个 Agent 分配隔离的工作区和互不重叠的探索领域。要求每位设计师先提出一个具名的设计主张，然后在不查看其他候选方案的情况下，构建、运行、渲染、检查并收集其方向的证据。每个设计主张都必须在组织结构或交互模型上有所不同，并且至少在其他一个重要维度上有所区别，例如层级、主要操作方式、信息密度、内容展开方式、导航、阅读路径或空间构成。
5. 先评审，再展示。 所有候选方案完成后，指派一名未参与创作的全新评审员。向其提供共同简报、基准版本、完整候选方案和渲染证据。评审员检查每项不变量，禁止虚构内容或行为，并通过两两比较检查候选方案是否存在实质差异。评审员通过候选方案的场景选择器逐一运行所有场景，并像用户一样在各状态间操作，例如更改筛选条件、悬停和拖动进度条，以验证状态、无布局偏移的状态转换和运行时保真度。仅改变颜色、字体、圆角、阴影、插图或文案，不足以构成不同方向；如果两个候选方案的粗略轮廓仍然相近，就必须淘汰其中一个。
6. 仅修复一次。 评审员将每个候选方案标记为 Pass、Rebuild 或 Reject，并给出可核查的理由。失败的候选方案最多允许进行一次范围明确的重建，由其原设计师完成，且不得向其展示其他实现。随后重新评审。不要为了凑足要求的数量而加入凑数方案；如果通过的候选方案少于 2 个，就应返回 Incomplete，说明缺失的证据或功能，而不是呈现虚假的比较。
7. 展示方案供选择。 仅展示通过评审的候选方案，并确保观看条件相同。每个方案都要提供名称、设计主张、重要取舍、渲染证据、一个可打开实时版本的链接或命令，以及已知限制。评审员可以说明合规情况和方案差异，但不得选出审美上的优胜者。请人类选择一个方向、提出具体的混合方案，或否决整组方案。
8. 结束原型阶段。 为所选方向保留清晰无歧义的视觉参考，包括相关状态、查看条件和未解决的问题。如果请求混合方案，就组装并展示合并后的结果，确保其验收依据是可见的设计。保留该参考以供实现对比；保留决策证据后删除未选中的候选方案，或仅将其保留在事先声明的独立探索位置。停止所有已启动的服务和进程，并在实现生产方案之前停止。

UI 忠实度规则

• 一次性描述的是生命周期，而不是视觉质量。不要把粗糙、通用、破损或明显未完成的 UI 作为选项呈现。
• 使用可信且符合领域特点的内容，包括与问题相关的复杂数据范围，以及空白、加载、错误、长内容或响应式状态。
• 除非需求明确允许更改，否则应保留真实应用外壳、组件、设计令牌、术语、行为和平台惯例。
• 为每个候选方案提供一个场景选择器：放在产品 UI 外部，不覆盖产品 UI 的任何部分；按名称列出需求中的场景，可加载其中任一场景，并将当前场景重置到起始状态。将所选场景保存在 URL 中，以便重新加载和分享后仍进入该场景。人类通过一个链接即可驱动所有状态。
• 只加入评估设计所需的交互。对变更操作使用存根，不要为了让候选方案看起来完整而臆造功能、控件、指标、客户或声明。
• 在预期运行环境和目标尺寸下渲染并检查每个候选方案。评估前修正裁切、溢出、层级难以辨认、交互失效、占位内容及其他可见缺陷。
• 在有帮助时共享产品基础元素，但不要强加会预先决定备选方案的通用布局。每个候选方案都应基于自身的设计主张构建，而不是对基础候选方案重新设计样式。

生产边界

选择代表采纳一种方向，而不是采纳其原型代码。根据项目的常规实践，复用候选方案的任何部分都属于新的生产工作，不继承原型的任何质量保证。

完成标准

逻辑模式有其自身的完成标准。UI 模式的完成标准如下：

• 一份基于证据且各方共用的需求说明，明确了设计问题和比较条件。
• 至少尝试了三个在隔离工作区中独立构建的候选方案，并由新的评审者评估其渲染结果。
• 每个展示的候选方案都通过了忠实度检查和两两差异检查；遗漏和构建失败均明确记录。
• 人类获得了可比较的证据，能够实时驱动每个候选方案的所有场景，并保留选择、混合或否决这些方向的决定权。
• 明确说明候选方案的处理方式以及原型到生产的边界，且尚未开始生产实现。