reviewing-hi-fi

reviewing-hi-fi — SKILL.md

变体： 标准 · 适用时机： 将已完成（或修订后的）高保真设计即代码作为验收门槛进行评判——重新渲染、根据标准对结果进行视觉审查，然后输出 VERDICT: approve|revise，并给出可执行的发现。

概述

此技能是高保真制作/评判组合中的评审部分。由手头已有已完成的高保真设计（代码 + 对应界面）的评审者加载，用于判断一个问题：这个渲染后的高保真设计是否是可靠的构建种子——是否涵盖线框中命名的每个界面、视觉呈现是否达到标准、渲染结果是否具备可访问性，以及是否符合设计系统？ 它应用一份固定的单一来源检查清单——标准与 authoring-hi-fi 制作时所遵循的标准相同——然后输出一个可供机器解析的判定，以及制作方可以一次性处理的发现。这是一个验收门槛——它不会制作、修复或重新渲染以改进设计；它只进行评判并返回发现。

交付物是渲染为像素的代码。评审者的独特之处在于：重新渲染代码本身（使用无头浏览器、agent-browser/Playwright），为每个视口 × 状态截取一张全新屏幕截图，并对这次新渲染进行视觉审查——绝不信任他人提交的截图（可能已过时或经过挑选），也不只靠阅读代码打分。这需要具备视觉能力的运行环境；纯文本评审者的能力会受限（能读代码，但看不到渲染结果）——应说明这一点，并指出交付物本身是否是在无法查看渲染结果的情况下制作的。

有两个边界：高保真设计负责渲染后的视觉效果 + 数值化的像素级 WCAG 评判（线框只为这些内容预留了位置）；设计系统负责各组件的无障碍契约规范——此门槛评判的是组合后的渲染结果是否达到该规范（规范与实现对照；不重复评判）。评判其是否符合设计系统和线框的要求，而不是给它们打分；评判的是一个种子，不是生产代码（不要因缺少测试或真实后端而要求修订）。

何时启用

• 已完成的高保真设计即代码需要在人工视觉门槛 / 构建里程碑前作出接受或修订的决定。
• 你是对制作方刚刚渲染的高保真设计进行独立评审或把关的人。
• 在先前判定为 revise 后重新评判修订版高保真设计，或将修订版高保真设计作为限定范围的差异进行评审（见条件 13）。

请勿在以下情况启用：

• 制作或修复高保真设计 → 使用 authoring-hi-fi。此技能绝不会为了改进而编写代码或重新渲染。
• 评判界面结构（布局区域、组件选择、作为结构的状态）→ 这是上游的线框工作（reviewing-wireframes）。
• 评判令牌系统 / 组件目录 / 各组件的无障碍契约→ 这是设计系统工作（reviewing-design-system）；此门槛检查渲染结果是否符合要求。
• 重新决定存在哪些界面/过渡 → 这是用户流程工作。
• 评判最终的生产代码（测试、真实后端、性能）→ 这是一个种子；这些内容由构建阶段负责。

工作流

步骤 1：重新渲染代码 + 以全新的独立视角通读整个高保真设计

在目标视口下自行渲染高保真设计代码，并为每个状态截取一张全新屏幕截图——不要信任他人提交的截图。如果无法渲染（没有无头浏览器）或无法查看渲染结果（纯文本运行环境），请说明：本次评审的能力受限，你只能评判代码中静态呈现的内容（并标记这一点）。从头到尾阅读代码和界面。如果提供了上游线框和/或设计系统，请快速浏览，以便在步骤 2 中交叉核对覆盖范围和符合性。

步骤 2：运行检查清单——逐项评判渲染结果

针对每项条件，以最新渲染结果（而非仅代码文本）为依据，判定为通过或存在差距。只有存在真实且明确的缺陷时，条件才算未通过——“我会选用不同的色调／布局”不算差距（不纳入集合的主观偏好不予考虑）。记录确切位置（哪个屏幕／哪种状态／哪个视口）。每项条件都应与屏幕的类型相称——对于简洁／静态的屏幕，交互、状态和响应式子检查项可以合理地不适用；不要因为内容简短就凭空制造差距。

下方的能力边界检查项仅在 capability_record 已注入到编写调用中，并可作为审查上下文时适用。若不存在，则视为不适用；如果没有定义边界，不要因为文档缺少能力边界标记而予以扣分。

1. 与线框图的完整覆盖。 线框图中命名的每个屏幕和流程访问到的每种状态都已渲染。若有未渲染的项目，则为缺口（交叉核对线框图；若其中没有，则检查文档自身的清单并注明缺失的输入）。不可折叠的基线。（在修订时，已有清单即可满足整个制品的覆盖要求——不要重新审查未改动的屏幕；cond-13 负责检查增量引入的覆盖回退。）
2. 保真度 + 范围。 已达到高保真视觉效果（不是线框图灰色样式／浏览器默认样式）；没有超出线框图而虚构结构／导航／屏幕；并且按种子版本评判——不会因缺少测试／真实后端／路由而要求修订，也不会在其声称已具备实际并未达到的生产就绪状态时予以通过。不可折叠的基线。
3. 视觉呈现 + 层次结构。 渲染结果实现了设计系统的视觉语言（颜色／字体／间距／层次／圆角／图标／图像）；主要元素在视觉上突出；层次清晰易辨。若屏幕平淡、缺乏区分或没有样式，则为缺口。*折叠：*仅有一个元素的屏幕不需要太多层次结构。
4. 精修——客观标准 + 明确命名的启发式标准。 客观标准：与网格对齐、比例一致、没有被裁切／重叠／孤立的元素、使用设计令牌、同级元素保持一致。明确命名的启发式标准（每项都能清楚说明）：平衡、留白与克制、间距节奏、焦点清晰度、审美协调性。只有在客观标准不达标，或明确命名的启发式标准不达标时，才算缺口（说明是哪项启发式标准不达标，以及原因）。仅基于主观且不属于上述标准的品味判断（“存在更好看的色调／布局”）不算缺口。*折叠：*极简屏幕自然满足要求。
5. 有令牌支撑／不偏离设计系统。 每个视觉值都能追溯到设计系统令牌（Tailwind 令牌工具类／CSS 变量／shadcn 令牌）；不能使用绕过令牌的原始 #hex／px／bg-blue-500；不能在本地覆盖设计系统令牌／组件；若缺少令牌／组件，应明确指出，而不是内联实现。任何未使用令牌的原始值或偏离设计系统的情况都算缺口。不可折叠的基线。
6. 已渲染 + 经视觉审查（由你完成）。 你重新渲染了代码、截取了新的屏幕截图，且渲染没有损坏，并符合线框图结构和设计系统。若屏幕无法渲染、渲染结果损坏或偏离线框图，则为缺口。仅根据提交的图像进行审查，或只读代码进行审查，都不完整。不可折叠的基线（此机制本身就是门槛）。
7. 内容真实度。 内容真实且有代表性——不得使用 lorem／占位填充内容；应覆盖真实场景和边缘数据（长字符串、溢出）。若使用 lorem 或只有整齐规整的数据，则为缺口。不可折叠的基线。
8. 已渲染的状态 + 质量。 流程访问到的每种状态都已渲染（提供屏幕截图，而不是文字说明）：空状态（说明原因 + 提供操作指引）、加载状态（骨架屏布局应与页面布局对应，而非单独的旋转指示器）、已填充状态、错误状态（使用通俗语言说明原因 + 提供恢复方式）、成功状态、部分状态。适用状态未渲染或只有空壳时，算作缺口。*折叠：*静态屏幕仅有已填充状态。
9. 响应式重排。 在目标视口下已渲染且显示正确；移动端应优先展示重要内容，并在设备形态需要时采用自适应导航；触控目标尺寸合适。若响应式界面只展示了一种宽度，或重排异常，则为缺口。*折叠：*仅适用于一种设备形态的界面（需说明原因）。
10. 渲染结果符合 WCAG 2.2 AA 数值要求。 axe-core 检查通过，没有禁用任何规则（这是必要条件，但并非充分条件——axe 无法检测焦点外观、键盘／焦点顺序、图像上的对比度或减少动态效果的要求；这些应通过渲染结果和手动／辅助技术抽查来评判）+（根据渲染结果评判）：文本对比度 ≥4.5:1／大文本和 UI ≥3:1（SC 1.4.3/1.4.11）；焦点可见（2.4.7）+ 不被遮挡（2.4.11）+ 外观 ≥2px/3:1（2.4.13，内部规则）；目标尺寸 ≥24px（2.5.8）；支持键盘操作 + 焦点顺序合理；遵循减少动态效果的设置。若测量结果不达标或有规则被抑制，则为缺口。应在令牌层修复。*基线：*始终检查对比度 + 地标 + 名称；仅在有交互／动画时检查焦点／目标／动态效果。**规范与实际实现：**判断渲染结果是否达到阈值，而不是设计系统文档是否写明这一点（后者由设计系统门槛评估）。
11. 符合设计系统规范。 渲染结果符合设计系统（组件属于设计系统，或忠实遵守其契约；不存在矛盾）。关于设计系统自身质量的发现不属于本项范围——应明确指出并移交给设计系统门槛处理。不可折叠的基线。
12. 明确指出缺口，不得虚构。 对未定义的屏幕／内容、缺失的设计系统令牌／组件、降级的（未渲染）生产版本，应明确列出假设／待解决问题。若文档用虚构的令牌／组件或伪造的屏幕截图掩盖缺口，则为缺口。如实标注的假设不算缺口。
13. 按增量范围审查（仅适用于修订后的高保真版本）。 审查差异 + 重新渲染的变更屏幕，而不是整个制品：范围受限（未改动屏幕的代码字节保持不变 + 不重新截取其屏幕截图）；无连带问题（变更的令牌已应用于所有使用该令牌的屏幕 + 未通过手动编辑造成偏离令牌的情况；没有使用方仍停留在旧版本；没有线框图中命名的屏幕变为未渲染；组件名称没有偏离；每个变更屏幕都重新截取了屏幕截图——没有过期的渲染结果）；变更屏幕已重新进行视觉审查（在新的渲染结果中仍符合精修 + WCAG + 设计系统规范）；文档自身的版本号更新符合变更类型；破坏性移除附有弃用说明；变更日志与差异一致。上述任一项不满足，均为缺口。对于从零开始的首次构建，标记为不适用。
14. 能力边界（没有 capability_record 时不适用）： 全程使用设计系统令牌；不新增设计系统之外的组件；边界与线框图范围一致（单项能力仅包含内部界面；系统级仅包含外壳）。

第 3 步：判定结果

• approve — 渲染结果满足所有适用条件。高保真设计是可靠的构建起点：覆盖完整、视觉呈现达到标准、可访问且符合设计系统。即使你能想到视觉上的改进，也应批准；标准是这些条件，而非完美。即使屏幕内容很少，且相应条件也按比例减少，仍应批准。
• revise — 一个或多个条件存在明确且具体的缺口（未渲染的屏幕、保真度仍停留在线框图的灰阶水平、使用了非令牌原始值、渲染结果未通过对比度检查、占位文本、缺少已渲染状态、未通过指定启发式检查、存在不当差异）。

不要为了体现投入或要求锦上添花的改进而要求修改；不要因范围外的主观审美（条件 4）或设计系统本身的质量（条件 11），也不要因仅属于构建起点的缺口（例如缺少测试，条件 2）而要求修改。条件要么满足，要么不满足。

第 4 步：输出结果和可执行的发现

将结果写成单独一行——原样输出 VERDICT: approve 或 VERDICT: revise，单独成行，不要添加外围代码围栏、引号或其他文字（这里的代码围栏仅作示例）：

VERDICT: approve

然后列出发现。若为 revise，每条发现都必须可执行：指出未满足的条件、具体位置（哪个屏幕／状态／视口），以及如何修复（若涉及对比度／令牌问题，应在令牌层面修复），确保制作方一次修改即可解决。若为 approve，可选择列出不影响通过的备注。

好的发现会指出缺口并说明修复方法：

revise — WCAG 数值检查（条件 10）：在已渲染的 Projects-empty 屏幕上，“New project”按钮使用白色背景上的 --muted，对比度为 2.9:1（低于 4.5:1，SC 1.4.3）。修复：将按钮绑定到 --primary 令牌（不要只对单个按钮使用非令牌颜色）；重新渲染并确认对比度 ≥4.5:1。

不好的发现过于含糊：“某处的对比度可能需要提高。”

规则

硬性规则（绝不违反）：

• 仅输出一行判定：VERDICT: approve 或 VERDICT: revise——该字面标记必须独占一行。下游工具会解析它。
• 重新渲染；绝不信任提交的截图。 自行渲染代码，并对新结果进行视觉审查（条件 6）。仅阅读代码或只看提交的图片都属于审查不完整；降级运行（未渲染／仅文本）必须标明。
• 评判，不创作。 返回问题；不要重写或重新渲染以改进。由产出者修订。
• 以单一标准为准。 按第 2 步的条件评判——作者产出时遵循的同一标准。不得另设更严格的标准，也不得臆造额外条件。
• 不得错误地要求修订。 符合所有适用条件的种子内容，即使较为简略，也应予以批准。范围外的主观偏好不构成缺陷；种子阶段才会有的缺项（没有测试／后端）不构成缺陷。
• 不得错误地批准。 屏幕未渲染、原始值不符合设计令牌、渲染结果对比度不达标、含有占位文本，或臆造令牌／组件，都应判为 revise。
• 以渲染结果衡量数值型无障碍标准；绝不接受禁用规则。 根据渲染像素评判对比度／焦点／目标尺寸；若为通过审查而抑制 axe 规则，本身就是一项问题。
• 区分规范与实现，不越界。 评判渲染结果是否达到 WCAG 阈值并符合设计系统；不要评判设计系统自身的契约／质量（那属于 reviewing-design-system），也不要评判屏幕结构（那属于 reviewing-wireframes）。
• 这是种子阶段，不是生产阶段。 不要因缺少测试／真实后端／路由而要求修订——这些属于构建阶段。
• 依据给定的上游输入进行评判。 未产出的上游内容绝不构成要求修订的理由；已产出但被忽略的上游内容（线框图中的屏幕未渲染；绕过设计系统令牌）则是合理的问题。
• 修订 = 差异审查。 修订时，审查差异和连带影响，并重新进行视觉审查，检查变更部分（条件 13）；不要重新审查未改动的屏幕。
• 每条要求修订的问题都必须可执行——指出未满足的条件、位置和具体修复方法。

偏好（可覆盖）：

• 按严重程度排列问题——先列阻断性缺陷（屏幕未渲染、对比度不达标、偏离令牌、占位文本），再列轻微问题（单一启发式细节）。
• 每条问题都注明条件编号／名称。
• 批准说明应精简，并明确标明为非阻断项。
• 缺少交叉检查输入（线框图或设计系统）或渲染降级时，应明确说明一次，不要默默假定其存在。

易踩问题

• 轻信提交的截图。 提供的图像可能已过时或经过筛选——自行重新渲染代码（条件 6）；这才是把关的关键。
• 只通过阅读代码来审核。 代码看起来没问题，渲染结果却可能出错——必须渲染并检查（条件 6）。
• 评判设计系统。 因为设计系统的令牌值或组件契约看起来不妥就要求修改，这超出了本关的职责范围——判断渲染结果是否符合要求（条件 11）；设计系统质量问题应交由设计系统关卡处理。
• 重复评判 WCAG。 设计系统规定了各组件的阈值；本关评判的是渲染结果是否达到这些阈值（规范与实际实现的对照），而不是重新评判设计系统规定的数值。
• 因生产环境缺口而要求修改种子项目。 没有测试、使用模拟数据、单文件或 CDN 都是种子项目允许的情况，并非缺口（条件 2）。
• 凭个人喜好要求修改。 “有更好看的色调／布局”属于范围之外的主观喜好——条件 4 评判客观子集和指定的启发式标准（指出具体哪项不符合）。硬凑出喜好上的问题属于误判修改。
• 放过 lorem 占位文本。 占位填充内容会掩盖溢出、语气和无障碍问题——应当 revise。
• 放过不符合令牌的值。 绕过令牌映射的原始 #hex／px 值属于偏离（条件 5）——应在令牌层修复。
• 修改后重新审核整个产物。 审核差异和连带影响，并重新审视修改部分（条件 13）；反复争论未改动的屏幕只会制造噪音。
• 判定令牌格式漂移。 “Approved”、“LGTM”、“needs work”，或埋在段落中间的判定都无法解析。必须单独一行原样输出 VERDICT: approve|revise。

反模式

• 敷衍通过。 扫一眼代码／屏幕就批准——设置关卡就是为了在构建以这些内容为种子之前，发现未渲染的屏幕、对比度问题和设计系统偏离。
• 吹毛求疵地要求修改。 将视觉喜好、设计系统令牌值或种子项目专属缺项包装成缺陷并据此阻止通过。只有真正阻碍覆盖度、保真度、无障碍性或符合性的问题才应要求修改。
• 轻信图片进行审核。 直接评判提交的截图，而不是重新渲染——这违背了整个关卡的目的。
• 悄悄重新渲染并修复。 “直接改代码更省事”——在审核过程中创作会混淆制作与评判的分工。
• 凭空添加条件。 “还应该通过 AAA／添加动效／换一种布局”——这会让标准偏离单一来源的条件。
• 评判错误的产物。 评判结构（线框图）或令牌目录（设计系统），而不是渲染后的高保真稿——不要越界。
• 模棱两可的判定。 “基本通过，但是……”或给出两行判定。只能有一个决定、一个令牌。

输出

针对一个高保真设计给出一份审核结果：

• 一行判定——单独一行原样写出 VERDICT: approve 或 VERDICT: revise。
• 问题项——判定为 revise 时，每个阻塞问题分别列出一项可执行的问题说明（未通过的条件 + 所在位置 + 具体修复方法）；判定为 approve 时，可选列出非阻塞说明。

抽象使用方是负责编排制作→审核循环的任何主体：approve 表示接受该高保真稿，进入人工视觉关卡／构建里程碑；revise 则将问题项退回制作者，进行范围明确的修改。

问题示例（确实需要修改）。 交接内容：一个高保真“Settings”屏幕，仅提供代码和一张截图。审核者在 360／768／1280 宽度下重新渲染：在 360 宽度下，表单字段溢出视口（未重新排版），分区标题使用了原始 #1a1a1a（不符合令牌），axe 标出了切换开关的标签问题。判定：revise——条件 9（Settings 在 360 宽度下重新排版异常：字段溢出；修复：将字段组纵向堆叠，并在 768 以下使用单列布局），条件 5（标题使用原始 #1a1a1a；修复：绑定到 --foreground），条件 10（切换开关缺少可访问名称，axe 提示 label；修复：添加 aria-label）。提供的截图（桌面端、已填入内容）看起来没问题——只有在所有视口下重新渲染，关卡才发现了这些问题。

相关内容

• authoring-hi-fi — 负责产出的部分；遵循本技能评判的同一标准。配对使用可确保标准只有一个来源，避免产出和评审各行其是。
• reviewing-wireframes — 负责屏幕结构的同级把关；线框图在这里是 交叉核对输入（用于检查覆盖情况），而不是本技能评审的对象。
• reviewing-design-system — 负责令牌系统和各组件无障碍访问 契约 的同级把关；设计系统在这里是 交叉核对输入（用于检查符合性），而本把关会依据它评审 实际呈现（规格与实际呈现的对比）。
• agent-browser（加上 playwright-best-practices）— 渲染代码并截取屏幕截图，供评审者进行视觉审查；本技能会驱动它。
• 一个 高保真模板 / 内容模板 工具 — 负责章节的 结构；本技能评判的是 是否达到标准，而非结构是否符合要求。

渐进式披露

• references/buildability-bar.md — 展开说明 14 项条件，包含每项条件的通过/差距信号和已完成的评审发现（包括规格与实际呈现的 WCAG 边界、按指定启发式判断精修程度、种子与生产的界线，以及差异评审）。当某项边界条件需要更准确的判断时加载。
• references/sources.md — 说明方法和单一来源标准（与同级的 authoring-hi-fi 共用）的研究出处。

正文篇幅限制

• description ≤ 1,024 个字符（agentskills.io 上限）；在列表中，description 与 when_to_use 合计超过 1,536 个字符的部分会被截断。
• 正文约 500 行 / 5,000 个词元（软性目标——优先保证质量；如果持续超过 700 行 / 7,000 个词元，则标记出来）——每轮都会保留在上下文中。
• 每个参考文件：超过 10k 个词元时警告，超过 25k 个词元时报错。参考文件总计：超过 25k 个词元时警告，超过 50k 个词元时报错。