experience-design-validate

体验设计验证

评估渲染后软件的视觉工艺：眼睛所见，以及这些可见设计决策所营造的感受。评判元素之间的关系、层级、克制、一致性和用心程度，而非 CSS、设计令牌或实现技术。

这是一项仅针对视觉工艺的审查。它不用于确认是否符合 WCAG，也不评估键盘或屏幕阅读器支持、行为可用性、实现质量或是否已准备好正式发布。无障碍合规性请交由 experience-accessibility-validate，SLDS 合规性请交由 design-systems-slds-validate。

用途与边界

在以下情形中使用此技能：

• 在设计检查点对视觉工艺进行评审。
• 解释渲染后的设计为何给人深思熟虑、局促、平和、零散或令人愉悦的感受。
• 比较两个或更多针对同一需求的设计在工艺上的表现。
• 找出能让可见体验从优秀提升到卓越的设计手法。

以下情形请勿使用此技能：

• 实现或代码审查。要生成 LWC 或进行安全审查，请视情况使用 experience-lwc-generate 或 experience-lwc-security-validate。
• 无障碍合规性，包括 WCAG、屏幕阅读器、键盘或焦点顺序验证。请使用 experience-accessibility-validate。
• SLDS 设计令牌合规性。请使用 design-systems-slds-validate。
• 关于真实用户行为的断言。如果影响取决于行为而非可见证据，请建议开展可用性研究。

视觉证据约定

必须提供渲染后的像素。优先使用截图，因为它们能保留审查所依据的确切证据。

1. **截图：**直接使用提供的整页截图或局部截图。
2. **在线 URL：**如果具备浏览器能力，打开 URL，仅体验相关路径，截取截图，并将 URL 和视口信息作为证据保留。否则请索要截图。
3. **Figma：**如果具备 Figma 能力，获取或导出指定的渲染画板。除非实际体验了原型行为，否则应将画板视为静态内容。否则请索要画板导出文件或截图。
4. **屏幕录制或交互式原型：**检查可观察到的过渡，并在工具支持时截取代表性画面。
5. **源代码、设计说明或无法访问的链接：**不要推断渲染结果。使用现有能力进行渲染；否则请索要截图。

如果没有可用的渲染像素：

• **交互式运行：**请用户提供截图或其他渲染产物，并暂停审查。
• **非交互式运行：**返回状态 INSUFFICIENT_VISUAL_EVIDENCE，并简短说明缺少的产物。不要评分、给出判定、创建发现项，也不要暗示已满足就绪条件。

证据模式

在分析前声明一种模式：

模式	可支持的评估内容	不可支持的评估内容
STATIC_VISUAL	可见层级、间距、排版、颜色、密度、构图、一致性，以及所捕获时刻的可见呈现	交互行为、状态间过渡、超出已捕获视口的响应式适配、延迟、运行时性能或未展示的状态
MULTI_VIEW_STATIC	跨所提供的屏幕、状态或视口截图的静态视觉证据，包括跨屏一致性	连接各截图的行为、时序、输入响应、运行时性能或未展示的状态
DYNAMIC_VISUAL	静态特征，以及直接体验或录制的行为：交互反馈、过渡、状态变化和感知性能	未体验的路径、未录制的状态、无障碍合规性，或超出观察范围的实测性能

加载、错误或空状态的静态截图，只能支持对该状态可见呈现的评审，不能证明状态覆盖情况、过渡行为或性能。切勿因为未提供未观察到的状态或行为而降低评分；应将该覆盖情况标记为 INSUFFICIENT_EVIDENCE。

五个维度

维度	直观感受
实用性	可见内容是否值得占用这些空间并吸引注意？
易用性	可见的层级结构和操作提示是否让预期路径一目了然？
可靠性	观察到的状态和反馈是否让体验显得可预测？
一致性	可见体验是否给人由同一支团队、秉持同一种品味打造的感觉？
精工细作	可见设计是否精确、周全且令人愉悦？

只有在现有证据充分覆盖某个维度时，才使用 1-10 分。适用维度若缺乏足够依据，请使用 INSUFFICIENT_EVIDENCE。只有当某个维度或主题确实不适用时才使用 N/A，绝不能仅因为缺少证据就使用。

请阅读 references/scoring-rubric.md，了解评分基准、结论规则、严重程度定义和完整报告规范。

工艺视角

请判断呈现出来的体验是否：

• 通透： 空间安排得当，为视觉留出余地。
• 易于上手： 无需解释，视觉上就能清楚看出预期路径。
• 引人探索： 可见状态鼓励探索，而非让人陷入死胡同。
• 经过周密考量： 重复出现的设计决策共同构成一个系统，而非零散堆叠。
• 克制： 层级清晰平和，很少有元素争当主角。
• 令人愉悦： 细节与个性经过精心设计，而非装饰性噪音。
• 自信： 设计有自己的立场，避免不必要的犹豫。

审核工作流

请按以下顺序执行：

1. 确定证据模式，并盘点所有提供或捕获的材料。
2. 如果没有渲染后的像素，请遵循视觉证据不足时的处理方式并停止。
3. 先观察，再查阅规则。为每个设计记录最多三条真实的第一印象。
4. 建立覆盖范围与相关性台账。针对每个维度和参考主题，记录 SCORED、N/A 或 INSUFFICIENT_EVIDENCE，证据模式，以及简明理由。
5. 加载 references/craft.md、references/scoring-rubric.md 和 references/visual-system.md。仅加载主题既相关、又能通过当前证据模式观察到的条件性参考资料。
6. 仅为有充分依据的维度评分。选择其适用且可观察的标准均得到充分支持的最高评分基准；只有在证据明确超出该基准、但尚未充分支持下一个基准时，才使用奇数分。
7. 撰写发现。每个维度最多列出五条发现，并对跨维度的根本原因进行去重。
8. 撰写工艺报告，包括台账和证据局限。

渐进式披露

始终加载：

• references/scoring-rubric.md：评分、覆盖度、严重程度、结论和报告架构。
• references/craft.md：经过考量的作品所呈现的质感。
• references/visual-system.md：可见的布局、排版、颜色和表面。

仅在相关且可观察时加载：

参考资料	所需证据
references/components.md	可见的按钮、输入框、模态框、列表、表格或反馈组件
references/navigation.md	可见的导航、标签页、面包屑、搜索或路径指引
references/responsive.md	多个视口的截图，或直接测试过的尺寸调整
references/forms-flows.md	多个可见步骤，或直接测试过的表单行为
references/data.md	可见的图表、仪表板、指标、筛选器、结果或表格
references/records.md	可见的记录、详情页、状态、元数据或协作功能
references/ai.md	可见的 AI、Agent、聊天、引用或模型输出
references/trust.md	可见的身份验证、隐私、同意、权限或破坏性设置
references/usability.md	可见的任务结构；不得推断行为层面的可用性
references/interaction.md	有关交互或动态效果的 DYNAMIC_VISUAL 证据
references/state.md	状态转换的 DYNAMIC_VISUAL 证据；静态状态截图仅支持外观判断
references/performance.md	有关耗时、延迟或布局稳定性的 DYNAMIC_VISUAL 证据

发现描述方式

描述感知层面的体验，并以可见证据支撑判断。

恰当示例：“工具栏显得过于繁杂；太多控件争夺注意力，让人找不到主要操作。”

范围不当：“三类按钮使用了不一致的间距 token。”这属于实现或 SLDS 审查的范畴。

每项发现都必须包含 severity、primary_dimension、可选的 related_dimensions、location、problem、why_it_weakens_craft、what_better_looks_like 和 fix。当同一问题出现在三个或更多位置时，应合并为一项发现，注明数量并列出有代表性的位置。

比较审查

按照相同的证据要求和评估标准，分别审查每个设计。报告必须包含：

• 每个设计的证据模式、覆盖情况记录、第一印象、维度评分、证据，以及达到下一个有证据支持等级所需的差距。
• 并列比较表；保留 N/A 和 INSUFFICIENT_EVIDENCE，不得强行转换为数值比较。
• A_HIGHER_CRAFT、B_HIGHER_CRAFT、TIE 或 MIXED 之一作为结果。当不同维度的领先方不一，或证据覆盖不足以得出整体排名时，使用 MIXED。
• 区分性维度、每个设计更出色的具体设计手法，以及双方都能借鉴但无需照搬的改进之处。

若证据支持平局或结果混合，不要选出胜者。

输出

如果用户明确提供输出路径，请严格写入该路径；该路径优先于命名约定。否则使用 YYYY-MM-DD-<target-slug>-craft-audit-<VERDICT>.md，其中 <VERDICT> 使用大写的 PASS、WARN、FAIL 或 LIMITED。

报告必须明确说明范围：结论和就绪度影响仅针对视觉质感，不涉及无障碍性、功能正确性、实测性能或生产发布审批。

建议和跨领域模式各包含零至五项。仅纳入有证据支持且有用的内容；切勿为了凑数添加无意义条目。只有至少存在一项可执行建议时，才以 references/scoring-rubric.md 中定义的修复提示结尾。

核心原则

1. 像素优先。 没有渲染证据，就无法进行视觉工艺审查。
2. 先看后评。 先记录第一印象，再依据评审标准进行分析。
3. 主张必须有证据支撑。 未观察到的行为属于未知，而非缺陷。
4. 描述感受层面，而非实现层面。 描述视觉体验，而非代码。
5. 边审查边指导。 解释每项发现的重要性，以及更好的体验是什么样的。
6. 严重程度胜过数量。 少数精准的问题胜过冗长的检查清单。