review-design

review-design — 评估面向用户的制品

判断受众能否理解、参与并按预期使用该制品，包括其以目的为导向的视觉表现。仅进行评审：你负责发现问题并说明，作者负责决策和修改。你绝不修复制品；根据报告应用修复属于调用此工作流的另一项请求。作为关卡调用时，记录判断所依据的实际情况；此技能不会改变本次运行的验证方式。独立评审自己制作的作品时，尽可能使用全新的上下文；否则须披露这是自我评审，并采用相同的证据标准。

输入

$ARGUMENTS 提供待评审的对象——文件路径、目录、URL，或正在运行的应用及其访问方式。它可能会明确指定类型（genre=dashboard、genre=deck），以覆盖自动检测结果。清单关卡的 Evidence 会在本次运行所选评估器下启用此技能；关卡可能会指定类型和任何固定参考资料——即作者在定义时确定、评估时据以评判的模拟稿、示例或标准。

如果没有参数，评审工作树中最近修改的面向用户的制品，并说明你选择了哪一个。如果无法明确判断，不要猜测，而应询问要评审什么；若作为关卡评估器运行且无法向用户提问，则返回 BLOCKED，并说明存在的歧义。

渲染证据或 BLOCKED

仅检查源代码所得的结论，并不构成完整的设计评估。应在制品预期运行的浏览器、原生宿主、播放器或设备中检查交付结果，并体验相关行为。响应式网页视口只是起点，并不意味着要把每个文件都变成网站。对于音频、命令或对话，应使用播放或交互证据；对于非视觉属性，无须提供截图。检查支持的主题、输入方式、访问权限及相关状态。如果无法凭现有能力检查某项必要属性，则应针对该评估范围返回 BLOCKED，并说明需要什么条件才能验证；不得用代理预览来判定通过。源代码检查可用于定位原因，以及确认语义结构等属性。

标准

使用 ../design/SKILL.md 获取以受众为中心的艺术指导。将其视为低于需求说明和既定设计系统的指导，而非风格合规关卡。此处列出的所有标准都是带有倾向性的默认要求：如果用户在会话或上下文文件中提出的规则，或项目自身有文档记录的设计系统，与某项规则不同，则以该规则为准；遵循该规则的制品不应被列为问题，报告中须说明所采用的规则。唯一的限制是 Procedure 下的关键失败规则；此类问题须说明导致问题的规则。如果缺少配套技能，则依据提供的需求说明和参考资料进行评判，不得凭空编造默认要求。

此评估器负责执行以下条件性标准。根据制品的媒介和涉及的领域，加载相应内容：

评审对象	阅读内容
Web 访问与交互	references/floors.md — 要求、例外和行为检查
结构化或定量信息及信息图形	references/figures.md — 忠实编码与等效访问
有状态或共享的作品、多页面旅程、演示文稿、非 Web 或不熟悉的媒介	references/experience.md — 连贯性、后果及实际媒介证据

流程

1. 在任何发现之前，用一行说明你据以评判的体裁和使用场景——如果发现是针对错误用途评分，那就是作者应忽略的噪声。显式的 genre= 参数优先；否则根据产物的用途判断；如果确实难以区分，就说明这一点并提出询问——如果没有用户可询问，就按更接近的使用场景进行评判，并在报告中说明这一判断。
2. **在评判产物之前，根据所提供的简报、证据和要求，梳理预期结果和工作流程。**说明受众、他们相关的路径或循环，以及需要同时获取的信息。如果无法得知意图，就区分哪些方面可以评估，哪些方面的目的契合度尚未核实。产物可以揭示其表面上的运行方式，但这并不能证明它实现了预期结果。不要臆造目标再据此定罪。
3. **执行适用的检查。**使用项目已有的工具；对于 HTML，运行 node scripts/design-check.mjs <artifact.html>（从本技能所在目录执行）。退出码为零表示检查已完成，不代表结果无问题。评分前，依据实际产物和适用的例外，核实测量候选项和 NOTE 项；标记为 SKIPPED 的属性仍未验证。选择器存在与否或启发式计数，都不能证明存在违规或已通过要求。
4. **按上文所述进行渲染和操作。**亲自运行第 2 步中的工作流程两次，并留意每次需要付出多少成本。根据预期结果选择观察重点；已加载标准中的交付探查示例可作为起点。
5. **提出改进时，在内容、状态、输出尺寸和实用保真度相匹配的条件下，与现有版本比较。**指出实际任务和视觉表现上的得失，同时保留已有的成功特征和行为。如果无法获取原版本，应说明这一限制，而不是声称有所提升。
6. 按以下顺序，依据已加载的标准评判渲染结果：任务契合度——布局是否能让该工作流程顺利运行，流程所需的信息是否同时可见，重复操作是否无需搜索即可触达，顺序是否与阅读顺序一致，以及所选呈现形式是否符合 references/figures.md 中的编码指导、适用于所呈现的信息或体验；对使用场景的适配度；功能底线（状态、错误路径、恢复能力）；构图与层级——将每个关键渲染模糊处理或缩小，检查视线首先落在哪里、随后如何移动，是否符合用户当下的需要，是否有次要元素争夺注意力；并将其他视觉探查作为判断辅助；工艺一致性（分组、对齐、色彩角色、排版）；文案；视觉冲击力与创意方向——构图、排版、色彩、图像、材质、交互和动效是否以服务其目的与主题的方式令产物更具吸引力。对所有体裁都应用这些标准，同时遵循用户要求和现有设计系统；仅仅做到机械正确，并不意味着设计已经完成。既要评判整体体验，也要评判各个部分：关系何时变得清晰，重点何处相互争夺，说明文字是在增添含义，还是只是在重复。不要只检查最出色的画面，还要检查实际使用过程、结尾和返回路径；在适用时，将动效与静态或减少动效的替代方案进行比较。区分设计判断与对受众理解、记忆或偏好的测量结果。

任务契合度应优先，因为只有这一维度的修复会重构产物：其下的每项发现，都是针对一种可能不复存在的布局进行评分。陌生的布局如果能让工作流程顺畅运行，就不构成问题。 评判时应依据作品的用途和选定方向，而不是你自己会选择的布局或风格；偏离数值或风格上的默认值，本身并不构成问题。指出适用的要求或观察到的任务后果；标准的等级和例外情况应予保留。既定规则和个人偏好都不能抵消关键功能或无障碍方面的缺陷。

指出视觉表现力方面的问题时，必须说明渲染结果留下了哪些未解决的问题——例如，千篇一律的构图未能赋予主体视觉表现力，或相互冲突的效果掩盖了作品的核心理念——并描述符合简报要求的具体改进方案。常见模式、克制的风格以及必需的设计系统组件都不算缺陷。

评级

• CRITICAL — 作品无法完成其所属类型的用途：表单出错时会丢失输入，演示文稿的论点无法复述，内容无法访问或阅读，或者根本无法完成重复循环。
• HIGH — 违反受众在正常使用中会遇到的底线要求：缺少空状态或错误状态，正文文本对比度不足，窄视口布局损坏，或布局破坏了循环所需的同时可见性，导致每次操作都必须滚动离开当前操作对象，或必须在脑中记住相关值；也包括误导性或不合适的呈现方式实质性地掩盖了任务所需的信息。
• MEDIUM — 明确的产品或质量缺陷；谨慎的评审者会坚持在发布前修复，并且有渲染证据支持：未解决的创意方向，或让受众执行任务明显更困难的分组方式。误导性控件、错误行为和违背明确承诺的问题，等级为 High 或 Critical。
• LOW — 任何风格、命名、结构或其他方面的润色问题或细枝末节。明确要求仍具有约束力；若正确性或安全性缺陷，或违背了具有约束力的承诺，却被评为 Low，则应根据证据重新评级，然后再应用调用方的规则。

调用方提供验收声明，以及任何明确要求的严重程度或类别规则。对于基于声明的门槛评估，应说明渲染结果如何妨碍受众的使用、选定方向或适用要求；仅给出评级或提出另一种审美方案，不足以推翻该声明。若提供了明确阈值，应予保留。未要求门槛评估时，只报告分类，不作结论；如果要求作出结论，但无法还原相关声明或规则，则应提出询问或报告 BLOCKED。缺少必要的渲染或交互证据时，仍应报告 BLOCKED。

报告

每项问题都应报告以下内容：

• 严重程度和规则领域
• 问题所在位置——元素、屏幕和状态，以及能证明问题的截图或机器检查行
• 标准要求，以及此处为何不符合要求
• 具体修复方案——若一行就能说明，则给出需要更改的值或规则；否则描述改动的大致形式

按严重程度排序，然后按位置排序。作品没有问题也是有效结论：明确说明结果良好，指出评估时采用的作品类型、使用情境和参考依据，然后结束。切勿为了显得全面而凑数报告边缘问题。如果同一模式有多个实例，只报告一次该模式，并列举两三个示例及实例数量。如果某项规则的适用确实存在判断空间，应在问题描述中说明，而不要将其评为缺陷。

范围，以及本技能不负责的事项

本技能根据请求或清单门槛评估已完成或进行中的作品；不提供设计指导。它不评审文案风格：对于文档，它评判的是布局、层级、排版和阅读结构，而不是写作质量。