reviewing-wireframes

reviewing-wireframes — SKILL.md

**变体：**标准 · **适用时机：**将已完成（或修订过）的线框图文档作为验收关卡进行评审——检查其是否可构建、覆盖充分，且相较上游流程构成合理，然后给出 VERDICT: approve|revise，并附上可执行的发现。

概述

此技能是线框图产出/评审配对流程中的评审部分。评审者手头有一份已完成的线框图文档，此技能会针对一个问题进行判断：下游高保真设计环节和 UI 工程能否据此构建屏幕结构，同时涵盖流程中命名的每个屏幕和状态，并确保每个屏幕的构成合理？它采用固定的可构建性 + 覆盖度 + 构成检查清单——与 authoring-wireframes 所遵循的标准相同，并采用单一来源，避免产出标准和评审标准出现偏差——然后给出一条机器可解析的结论，以及产出者可以在一次修订中处理的发现。这是一个验收关卡——它不会撰写、修复或重绘，而是进行评审并返回发现。

此处的线框图是低到中保真度的结构性描述，以文本形式呈现为结构化布局说明 + ASCII/Markdown 方框草图 + 逐元素注释，而非像素级样稿或二进制设计文件。此方法与媒介无关：当前产物为 Markdown，未来改用设计工具后端只会改变媒介，不会改变以下检查清单。

评审者会收到线框图文档，并在可用时收到两个交叉检查输入：上游用户流程（用于核验屏幕覆盖度）和设计系统（用于核验组件真实存在且保持一致，并确保文档没有重新评判各组件的无障碍访问契约）。如果缺少某项交叉检查输入，请根据文档自身的屏幕清单和组件引用进行评审，并注明缺少该输入，而不要凭空进行比较。

何时启用

• 已完成的线框图文档需要在下游高保真设计环节 / UI 工程开始前作出接受或修订决定。
• 你是独立评审者 / 把关者，负责评审产出者刚完成的线框图文档。
• 对先前结论为 revise 的修订版线框图文档重新评审，或对修订过的文档进行限定范围的差异评审（见条件 13）。

请勿在以下情况启用：

• 撰写或修复线框图文档 → 使用 authoring-wireframes。此技能绝不会撰写或重绘。
• 评审屏幕间的导航图 / 路径 → 这是上游用户流程的职责（reviewing-user-flows）。此技能评审逐屏布局和覆盖度。
• 评审视觉令牌系统 / 组件目录或各组件的无障碍访问契约（对比度、焦点外观、组件自身的目标尺寸 / 键盘操作）→ 这是设计系统的职责。此技能会检查线框图中的组件是否一致地引用设计系统，以及文档是否为屏幕构成层面的无障碍访问留出空间，而不评判设计系统本身是否完善。
• 评审高保真视觉设计 / 最终像素、颜色、字体、动效 → 这是下游的高保真设计环节，超出结构性线框图的范围。
• 检查模板 / 章节是否符合规范 → 这是模板的职责。此技能评审的是是否达到质量标准，而非是否包含每个标题。
• 评审任何其他类型的文档。

工作流

第 1 步：以独立、客观的视角通读整份线框图文档

不受作者的描述影响，从头到尾阅读文档。你的职责是把守下一步（高保真设计 + UI 工程构建）：只有在发现屏幕结构无法按文档所述构建、流程中命名的屏幕 / 状态缺失，或构成未达到客观标准时，才值得提出问题。如果提供了上游用户流程和 / 或设计系统，现在先快速浏览，以便在第 2 步交叉核验覆盖度和组件一致性。

第 2 步：运行检查清单——评判每项条件

对于以下每项条件，判断是通过还是存在差距。只有存在真实且明确指出的缺陷时，条件才算不通过——“我会用不同的方式来布局”不算差距（标准是客观的）。针对每项差距，记录其确切位置（哪个屏幕／哪种状态）（第 4 步会将其转化为一项发现）。每项条件都应根据屏幕的类型适度评估——内容精简／静态的屏幕可以合理省略不需要的条件；不要仅因内容简短就凭空制造差距。

下面的能力边界清单项仅适用于在创作调用中注入了 capability_record，且该记录可作为审查上下文的情况。若不存在，则视为不适用——未定义边界时，不要因文档缺少能力边界标记而扣分。

1. 覆盖所有屏幕。 每个流程中命名的屏幕及隐含的状态转换都要有线框图。若某个屏幕没有线框图，则为缺口（交叉核对用户流程；如果其中没有，则检查文档自身的清单，并注明缺失的输入）。不可折叠的基线。
2. 涵盖各屏幕所有适用状态，且质量达标。 空、加载中、有内容、错误状态；发生状态变化时还要包含成功状态（相关时还要包含部分状态）。不仅要有状态，还要有质量：已知布局时，加载状态应使用反映布局的骨架屏（而非单纯的旋转指示器）；空状态应说明原因并引导用户采取行动；错误状态应以通俗语言说明原因和恢复方法。缺少适用状态，或已有状态只是空壳，都属于缺口。可折叠： 静态屏幕仅有有内容状态。
3. 布局与构图明确无歧义。 区域和内容优先级应清晰到无需猜测即可实现；采用网格；使用统一的应用外壳（不得为每个屏幕重新设计）。如果两位工程师会构建出不同结构，或某个屏幕重新设计／省略了外壳，则为缺口。可折叠： 单元素屏幕无需讨论网格。
4. 布局质量（客观）。 主要操作位于浏览路径上，相关元素分组合理，不存在多余区域／元素，且与同类屏幕保持一致。仅在存在客观问题时才算缺口（主要操作被埋没、无关项目挤在一起、存在冗余区域、同类屏幕布局不一致）。主观偏好（“还有更美观的布局”）不算缺口。可折叠： 简单屏幕自然能够满足要求。
5. 组件已标明、一致且真实存在。 每个显著元素都要注明其 DS 组件（如有）；复用的组件保持一致；不得臆造；按组件结构使用。出现未标明的模糊元素、命名不一致，或将臆造的组件／令牌当作已确定内容，都属于缺口。不可折叠的基线（不得臆造）。
6. 注明交互方式与数据展示。 注明每个交互元素的行为、目标位置和边缘情况；数据密集型屏幕需指定表格／列表／卡片的选择及控件（排序／筛选／分页／密度／展开）和渐进式披露；表单使用结构化输入（不得使用序列化字符串字段）。若控件行为需要猜测，或数据表只写着“此处放置表格”而缺乏结构，都属于缺口。可折叠： 静态屏幕没有数据／表单。
7. 内容与微文案意图。 说明承载重要信息的文本槽位的意图；标签不得直接使用原始数据模型标识符（应使用易懂的标签和描述）；标签应始终显示（占位符不等于标签）；各屏幕术语保持一致；本地化时预留 i18n 文本扩展空间。标签泄漏数据模型标识符、以占位符代替标签或术语不一致，都属于缺口。基线： 不得在标签中泄漏数据模型标识符，且术语须保持一致；这两项不可折叠。单一语言环境下可折叠 i18n（需说明原因）。
8. 考虑响应式布局。 对布局形态会产生影响的屏幕，应说明重排机制（堆叠／折叠／隐藏／重新排序）、移动端内容优先级、自适应导航及触控目标预留空间。明显需要重排的屏幕若未说明重排方式，则为缺口。可折叠： 仅适用于单一形态的界面（需说明原因），或无需实质性重排的屏幕。
9. 屏幕构图的无障碍性。 地标区域、单个 h1 的标题顺序、阅读／焦点顺序、无障碍名称（包括仅图标控件）、键盘操作能力、≥24px 的目标尺寸预留空间、焦点不被遮挡（适用于粘性元素）、非仅依赖颜色传达意图。像素对比度、焦点外观以及各组件的目标尺寸／键盘操作能力不在此处评估——这些属于设计系统的约定；评估它们超出本项范围。 带有交互控件的屏幕若没有构图层面的无障碍标注、仅图标控件没有无障碍名称，或某项必需操作只能用鼠标完成，都属于缺口。基线： 地标区域、单个 h1、无障碍名称和键盘操作能力适用于所有尺寸；其余要求在相关内容存在时适用。
10. 标注、交接与草图同步。 定义标注图例；为每个承载重要信息的元素添加说明（说明工作方式，而不只是画出来）；元素应映射到 DS 组件（以便从设计交接到代码）；草图 ⇄ 标注保持同步（不得有无对应元素的标注，也不得有未标注的元素）。静态但未标注的草图，或草图与标注不一致，都属于缺口。基线： 草图 ⇄ 标注同步，以及可供实现的交接要求不可折叠。
11. 明确暴露缺口，不得臆造。 未定义的屏幕／内容、缺失的 DS 组件，以及延后处理的组件约定级无障碍要求（无 DS／高保真设计）都应明确列为假设／待解决问题，不得悄悄补全或省略。若文档将未定义的屏幕／组件臆造为已确定内容，从而掩盖问题，则为缺口。如实标注的假设不算缺口。
12. 结构性设计，而非高保真设计。 采用低至中等保真度——布局加标注；不涉及最终像素、颜色或字体。若设计深入高保真细节（精确颜色／字体／像素间距），侵犯高保真设计／设计系统的范围，则为缺口。不可折叠的基线。
13. 按差异范围审查（仅适用于修订后的文档）。 审查修订内容时，应审查差异，而非整个文档：范围受限（未改动的屏幕保持不变）；影响完整无遗漏（共享区域的变更已应用到所有复用该区域的屏幕；清单中没有孤立条目；没有新增未覆盖的流程命名屏幕；组件名称未漂移；草图 ⇄ 标注仍保持同步；引用的 DS 组件仍真实存在且未弃用）；文档自身的版本号提升符合变更类型；破坏性移除附带弃用说明；变更日志与差异一致。任何一项不满足都属于缺口。全新项目的首次构建不适用。
14. **能力边界（无 capability_record 时不适用）：**所有 entry_points 均可作为首屏到达上下文；所有 exit_points 均作为跨能力转换标记呈现；不得进行全局导航或外壳重设计（标记为范围外——应归入 system-wireframes）。
15. **系统覆盖（无能力记录时不适用）：**所有 has_ui=true 的能力至少有一个导航项；所有 exit_points 都有通往匹配 entry_point 的转换屏幕；共享模板（加载／错误／空状态）均已提供。

步骤 3：确定评审结论

• approve — 所有适用条件均通过。结构可按描述构建，所有流程中命名的屏幕和状态均已覆盖，且组合达到目标标准。即使你能想到布局改进，也应批准；标准是可构建性、覆盖度和目标组合，而非完美。
• revise — 一个或多个条件存在明确、具体的缺口（缺少／空状态、虚构的组件、含糊的布局、主要操作被埋没、暴露数据模型的标签、缺少组合无障碍设计、过度追求高保真、未覆盖流程中命名的屏幕、差异不当）。

不要为了显示投入或索要锦上添花的改进而要求修改；不要因主观布局偏好（条件 4）或像素级对比度问题（由设计系统负责，条件 9）而要求修改。条件要么满足，要么不满足。

步骤 4：给出评审结论和可执行的发现

评审结论须单独占一行——原样输出 VERDICT: approve 或 VERDICT: revise，不得添加外围围栏、引号或其他文字（此处的围栏仅作示例）：

VERDICT: approve

然后列出发现。若结论为 revise，每条发现都必须可执行——指出未通过的条件、确切位置（哪个屏幕／哪种状态），以及如何修复——以便产出方一次性解决。若结论为 approve，发现可选，也可列出非阻塞备注。

好的发现会明确指出缺口和修复方法：

revise — 单屏状态（条件 2）：Dashboard 屏幕只记录了有内容的视图；缺少空状态、加载状态和错误状态。修复方法：添加空状态（无条目提示＋创建 CTA）、加载状态（与有内容布局对应的骨架屏）、错误状态（说明信息的位置＋重试方式，采用内联还是阻塞式呈现）。

不好的发现含糊不清：“Dashboard 可以增加更多状态。”

规则

硬性规则（绝不可违反）：

• 只输出一行判定：VERDICT: approve 或 VERDICT: revise——该字面标记必须独占一行。下游工具会解析它。
• 只评审，不创作。 返回问题；不要重写、重绘或补全内容。由内容创作者修订。
• 统一评判标准。 根据步骤 2 中的条件进行评判——与作者创作时遵循的标准相同。不得另设更严格的标准，也不得凭空增加条件。
• 不得误判为需修订。 满足所有适用条件的文档应予以批准，即使内容较精简、屏幕也相应精简。只有存在真实且明确的问题时才要求修订。主观的布局偏好（条件 4）绝不是问题。
• 不得误判为批准。 缺少状态、擅自添加组件、未覆盖流程中提及的屏幕、泄露数据模型的标签或高保真度超标，均应判为 revise。
• 覆盖范围以流程为准。 流程中提及的屏幕或状态没有线框图，应判为 revise。如果未提供流程，则评审文档自身的清单，并指出缺少交叉核对。
• 擅自添加组件或设计令牌属于阻断性问题。 设计系统未定义的组件或令牌，若被当作已确定内容呈现，而非标注为待定，应判为 revise。
• 无障碍评审不得越界。 评审屏幕构成层面的无障碍性（条件 9）；不要评判像素对比度、焦点外观，或单个组件的目标尺寸和键盘操作——这些属于设计系统的约定。评判这些内容属于越界（偏离要求），而非严谨。
• 依据文档所获的上游材料进行评审。 未提供的上游材料绝不能成为要求修订的理由。已提供但被忽略的上游材料（流程中提及的屏幕未被线框图覆盖；设计系统之外擅自添加组件）则可以作为有效问题。
• 修订 = 差异评审。 修订时，评审差异及其连带影响（条件 13），而不是整个文档；不要重新审查未改动的屏幕。
• 每条修订意见都必须可执行——指出未满足的条件、具体位置和明确的修复方式。

偏好（可调整）：

• 按严重程度排列问题——先列阻断性问题（缺少屏幕或状态、擅自添加组件、布局含糊、主要操作被埋没），再列次要问题（例如一条简略的微文案说明）。
• 每条问题都注明条件编号或名称。
• 批准说明应尽量精简，并明确标注为非阻断项。
• 缺少交叉核对输入（用户流程或设计系统）时，应明确说明一次，不要默默假定。

易错点

• 为了完整性而非可构建性批准。 每个部分都可能齐全，但文档仍然无法构建（区域含糊、未标注的可供性、流程中提及的屏幕从未绘制）。判断结构是否可构建 + 流程中提及的每个屏幕是否都有覆盖，而不是看模板是否填满。
• 遗漏仅覆盖理想路径的问题。 屏幕只有填充后的视图，却悄然省略空状态／加载状态／错误状态／成功状态，这是最常见的缺陷。
• 遗漏流程覆盖问题。 流程提到某个屏幕，却没有为它绘制线框图——沿着流程 → 屏幕逐一追踪；清单表是发现此问题的地方（条件 1）。
• 放过自创组件。 设计系统未定义、却被自信地命名出来的组件属于偏离——请指出（条件 5）。
• 评判像素对比度。 因未注明对比度而要求修改，超出了职责范围——这是设计系统的约定；应评判预留的非颜色意图 + 构图，而不是像素值（条件 9）。
• 因布局偏好而要求修改。 “我会用卡片”属于主观意见——条件 4 只涉及客观标准（扫描路径／分组／避免无谓元素／一致性）。凭空制造偏好差异属于误判修改。
• 误判比例较简单的屏幕。 静态信息屏幕确实可能没有加载／错误状态，也无需讨论网格或重排。应根据屏幕类型调整判断标准。
• 偏离职责，进行高保真评审。 评判具体颜色、字体或像素间距，超出了结构范围（条件 12）。
• 修订时重新评审整份文档。 评审差异 + 连带影响（条件 13）；反复争论未改动的屏幕只会制造噪音。
• 判定标记漂移。 “Approved”“LGTM”“needs work”或埋在段落中间的判定都无法解析。请在单独一行输出字面内容 VERDICT: approve|revise。

反模式

• 敷衍批准。 草草浏览便批准——设置关卡是为了发现无法构建或不完整的线框图；放过缺少错误状态的屏幕，会给后续构建带来问题。
• 吹毛求疵地要求修改。 因布局偏好、草图美观度、像素对比度，或把锦上添花的问题伪装成缺陷而阻塞。只有真正阻碍可构建性／覆盖度／构图的问题才需要修改。
• 悄悄重画。 “直接修一下草图更简单”——在评审过程中代为创作，会破坏产出与评判的分工。
• 擅自增加条件。 “还应该确定最终颜色／完整组件规范／对比度”——这会把标准带入高保真领域，也侵入设计系统的职责范围。
• 评判错误的产物。 评判导航图（用户流程）或设计令牌目录／组件无障碍约定（设计系统），而不是逐屏线框图——请坚守职责范围。
• 含糊其辞的判定。 “大体批准，不过……”或给出两行判定。只能有一个决定、一个标记。

输出

针对一份线框图文档给出一份评审结果：

• 一行判定——在单独一行原样输出 VERDICT: approve 或 VERDICT: revise。
• 问题——若判定为 revise，针对每个阻塞问题分别给出一条可执行的问题描述（未通过的条件 + 位置 + 具体修复方法）；若判定为 approve，可选提供非阻塞备注。

抽象的使用方是负责协调产出→评审循环的部分：approve 表示接受线框图文档并进入下一阶段（后续高保真设计 + UI 工程）；revise 则将问题反馈给产出方，进行范围明确的修订。

相关内容

• authoring-wireframes — 负责产出；遵循本技能评审的同一套可构建性 + 覆盖度 + 构图标准。配对使用可统一标准，避免产出与评审各行其是。
• reviewing-user-flows — 面向上游导航图的同级门槛；此处将用户流程作为交叉核对输入（屏幕覆盖度），而非本技能的评分对象。
• reviewing-design-system — 面向视觉 Token 系统 + 组件目录 + 各组件的 a11y 契约（对比度、焦点外观）的同级门槛；此处将设计系统作为交叉核对输入（组件一致性），而非本技能的评分对象。
• 下游的 hi-fi 评审 — 评判最终视觉效果/像素；本技能止于结构。
• wireframes 模板 / content-template 工具 — 负责各章节的结构；本技能评判的是相对于标准的质量，而非结构符合性。

渐进式披露

• references/buildability-bar.md — 展开的检查清单条件，包含各条件的通过/差距信号 + 具体评审发现（含 a11y 边界 + 布局质量目标子集 + 差异评审）。当边界条件需要更明确的判断时加载。
• references/sources.md — 方法与统一标准的研究来源（与同级技能 authoring-wireframes 共用）。

正文预算

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