UI 设计探索
为指定任务生成可用的设计方向。在生成备选方案前，检查现有屏幕、组件、设计令牌、密度、内容和交互惯例。除非要求重新设计，否则保留产品身份。
使用参考证据
当外部参考信息指导任务时，如果可用，请使用 design-reference-research，或者直接检查相关提供的/默认来源。吸收其来源覆盖率，捕获 ID、观察结果和不确定性。不要重新完成已完成的研究，也不要将未经检查的情绪板视为证据。参考信息的可用性并不意味着对于已基于产品的小型任务，研究是强制性的。
将有用的原则转化为使用现有产品身份的原始备选方案。解释每个关键选择如何遵循用户任务和证据。通过平台、任务和约束来解决冲突的模式；不要混合不兼容的导航系统或复制其他产品的品牌。将未知的交互状态作为待验证的问题向前推进，而不是默默地发明观察到的行为。
构建备选方案
仅澄清那些实质上会改变结果的选择。确定用户任务、内容层次结构、适用状态、可访问性约束和目标界面。使备选方案在关键结构或交互上有所不同，而不仅仅是颜色。使用与请求成比例的小数量；不要总是生成三个或要求并行智能体。
除非已经请求实现，否则将探索性工件与生产代码分开。使用真实数据、长标签、空/错误状态和响应式布局，在它们会改变选择的地方进行展示。展示每个备选方案改进和代价。仅一张截图不足以指定焦点、导航或持久性。
使用可用的设计能力
使用仓库原生的组件和可用的预览/设计工具。可用的交付物可以是本地 HTML、现有设计画布或带注释的视觉效果；它不需要依赖托管供应商。在没有证据的情况下，不要声称设计已被渲染或测试。
对于明确配置的 Superdesign 集成，请阅读 hosted-design.md。工作流程仍必须在该服务不可用时正常工作。不要下载最新的 CLI、创建账户或上传源代码作为设计工作的隐含先决条件。
交接方向
针对任务和约束比较备选方案。如果用户请求选择，则展示该决策的实际备选方案。如果他们授权您选择，则推荐并继续，给出理由，而不是引入另一个批准关卡。
提供选定的工件、重用的令牌/组件、布局规则、响应式更改、交互/焦点行为、有意义的状态、资产和未解决的决策。将验收标准和有意偏差与可用的参考证据 ID 关联起来；未选中的备选方案不是实现要求。区分选定的设计与可工作的实现。将授权的实现路由到 frontend-ui-engineering，将评审路由到 plan-design-review（当可用时），无需要求安装这两个功能。
阅读 provenance.md 以了解上游工作流程的来源和注意事项。