better-design

更好的设计

让用户请求的任务清晰且可执行：用户能知道自己身处何处，了解操作后再执行，获得结果，并能从错误中恢复。 分别评估连贯性、表现力和无障碍性。不要承诺完美的 UX。

1. 明确范围并建立视觉依据

• 选择一种模式：创建、聚焦改进、审查或规划。审查应保持只读； 规划时不要实施更改。不要添加用户未请求的功能。
• 根据请求和项目确定平台。只有在缺少上下文时，才以响应式 Web、语义化 HTML 和 WCAG 2.2 AA 为初始目标。
• 在设计或更改响应式界面之前，先确定实际设备和视口矩阵。对于网站，应包含产品支持的移动端、平板、桌面和超宽屏布局；对于手机游戏，应包含小屏和常规尺寸手机以及平板。设计约束和布局行为必须适配这些界面，而不能只是缩小桌面布局。对于浏览器相关工作，矩阵中应包含浏览器缩放，因为 75%、100% 和 150% 可能暴露不同的裁切、密度、重排和交互问题。
• 进行任何 UI 工作之前，查找项目的 DESIGN.md（位于根目录、docs/、design/，或 Agent 指令中指定的路径）并完整阅读。它是界面值的唯一依据：字体、字号比例、颜色角色、间距、圆角、组件尺寸、图标和动效。新增或更改的代码中的每个值都必须按角色或令牌名称取自其中；绝不要凭目测取值、取整或引入近似重复值。规则见 design-md.md。
• 在当前运行环境中或通过已确认的最新截图检查现有界面，然后检查相邻组件、令牌、样式和项目规则。没有 DESIGN.md 并不意味着没有设计系统：此时，代码令牌就是设计系统。 保留与当前工作无关的进行中更改。
• 区分实现缺陷和重新设计请求。首先解决根本原因： 顺序不清晰、操作不可预测、反馈不佳、数据丢失或内容遗失。
• 按以下顺序做出决策：明确的任务和约束 → DESIGN.md 和现有系统 → 平台惯例 → 领域任务 → 此技能的可配置基线。 功能和适用的无障碍要求在每个层级都必须满足。
• 默认视觉方向。 用户未指定视觉风格，且项目没有可沿用的 DESIGN.md、品牌、代码令牌或线上 UI 时，采用统一风格：秉持 Apple 风格的高端极简主义（黑色画布、近白色文字、两种灰色、一种用于链接和焦点的蓝色，只有真实内容使用其他颜色）。规则和可直接使用的 DESIGN.md 预设见 house-style.md。用户提供的任何视觉线索（颜色、氛围、主题、参考、品牌、受众风格）都优先于此默认风格：遵循请求，仅采用默认风格中未被指定且不与请求矛盾的部分。除非用户提出要求，否则绝不要将现有产品改成这种风格。游戏应保留自身的美术方向。
• 保留既有的品牌风格、信息密度、游戏感、编辑风格或表现力构图。不要将它们替换成通用的灰色 CRM。若确实存在冲突，应选择影响最小且无障碍的调整，并说明具体偏离之处。
• 仅针对会实质影响决策的未知信息进行澄清；简要说明合理假设。此技能不会引入新的审批或 HTML 门槛。现有项目对原型、审批和构建的要求仍然适用。

2. 定义任务和与之相称的约定

• 用通俗语言描述主要场景及其可观察到的结果。 按顺序说明进入 → 操作 → 结果 → 错误/重试 → 返回/取消。
• 将主要任务、次要操作和帮助区分开。选择用户熟悉的名称和模式；在各个屏幕中保持导航和操作位置一致。
• 单个修复只需简要记录变更的决策和检查。 对于新流程，应在实施前编写简洁的约定；它是工作工具，并非必须提供给用户的文档。
• 使用 design-contract.md 了解结构、数值默认值和例外情况。 JSON 示例展示了格式；小改动时不要将其整体添加到项目中。
• 将约定限定为平台、目标、现有系统、方向、受影响的组件、组件的操作/状态、响应式行为和验收证据。 计划进行的检查不代表已完成的检查。

3. 在应用样式之前确定艺术方向

仅有负面规则只会让输出转向下一个最常见的模板；个性来自流程。当任务涉及创建或重新设计具有自身特征的界面（品牌、落地页、作品集、消费级应用、游戏、编辑内容、启动器）时，应先遵循 art-direction.md，再选择设计变量。当适用既定风格（第 1 节）时，调色板、字体、形状和动效变量来自其预设；仍需写明概念，并让概念决定图像、每个版块的主要元素和一处标志性细节（house-style.md 第 10 节）。否则：

• 根据产品领域、受众和内容推导出一句概念描述——从该世界中选取一个物件、地点或技艺，而不是“现代、简洁、极简”等形容词。 再列出三个目标特质和三个具体的反向特质。
• 收集 3–5 个真实参考（优先使用用户提供的参考；绝不使用 AI 生成的图像），并准确注明每个参考借鉴了什么：节奏、密度、数字呈现方式、材质、光线。
• 草拟 2–3 个方向，让它们在主要设计手法上有所不同（以字体为主、以图像为主、以结构为主），再选择一个，并说明其与任务和受众相关的原因。
• 根据概念推导调色板和字体：说明调色板的来源并使用带色调的中性色；列出三种字体候选并说明选择理由。规划一到两处标志性细节；effects-library.md 中的可选资源集包含经过测试的方案。
• 根据同一概念推导动效特征：描述该世界中的事物如何运动（节奏、重量、物理规律、是否有弹性），并确定一处标志性动效细节。调色板、字体和动效必须体现统一的风格；参见 motion.md。
• 在 DESIGN.md 中，已有品牌或设计系统的方向应当继承：从 DESIGN.md 获取，或根据当前界面用一句话说明，并在其框架内设计。高密度工作工具通过精确度和数据字体体现个性；如果没有系统也没有用户提示，则采用既定风格的应用尺度和调色板，并使用中性备选方案的密度。
• 在约定中记录该方向（direction，包括 direction.motion），并规划 distinctiveness 和 motion 检查。将选定的方向和设计变量写入 DESIGN.md，让后续屏幕和会话都基于相同的取值进行构建。

4. 构建一套连贯的决策体系

• 复用 DESIGN.md 和代码令牌中的令牌与组件。对于新系统，先定义颜色、字体、间距、圆角、层级和动效的语义角色，再选择组件变体。
• 保持集合封闭，确保每个屏幕都由相同部件构成：一种或两种字体、包含少量角色的阶梯式字号、固定的间距刻度、少量圆角值，以及固定的组件尺寸（例如按钮 sm/md/lg）。相同角色在每个屏幕上都使用相同值。缺少某个值时，应将其视为系统决策：在 DESIGN.md 和代码令牌中同时添加该角色。
• 从头创建界面时（适用房屋风格时，使用房屋风格预设），或重新设计或涉及多个组件的改动发现尚无 DESIGN.md 时，请根据模板创建 DESIGN.md；根据现有代码令牌推导值，而非凭空编造，并记录矛盾之处，而不是悄悄修正。除非有人提出要求，否则单元素修复不需要创建该文件；用一行文字提出即可。每次改动只要涉及 DESIGN.md 或代码令牌，就要保持二者同步。
• API 表达意图、尺寸、密度和状态。保留原生属性、表单参与行为、链接和可访问名称；不要要求提交按钮或带有 href 的链接必须设置 onClick。
• 不要为每个元素单独调整十六进制颜色、间距、阴影和圆角。如果问题源于共享因素，就修改共享令牌或变体。布局计算、1px 边框、0、fr、%、calc、aspect-ratio 和项目允许的值本身并不违规。
• 根据角色和容器选择文字大小。
• 通过构造几何关系来布局，绝不凭目测摆放。每个屏幕、面板和游戏菜单都遵循 layout-geometry.md，并测量结果（第 8 节）。在根本原因处修复对齐问题（轴心、锚点、缺少布局组、精灵图内边距、字体度量），绝不要通过微调单个元素来掩盖问题：
  • 间隔一致。 同类同级元素应放在布局容器中（flex/grid gap、Unity 布局组、Godot 盒式容器、UMG 盒子），并使用同一个间距令牌，使它们之间的每个间距都相同。间距不同时，应代表新的分组，并在刻度上明确增大。距离层级：控件内部 < 项目之间 < 分组之间 ≤ 内边距。
  • 对齐线一致。 同一行的项目应共享顶端/中心/底端（高度不一时共享中心）；同一列中的项目以及设置列表中的每个标签，都应从同一条垂直基准线开始，控件则沿第二条基准线排列。使用网格或固定标签列，不要为每行单独设置偏移。同组按钮应使用相同尺寸。
  • 小型控件内的内容应按可见字形（大写字母高度、裁切后的图标像素）居中，而非按字体行框或带内边距的精灵图矩形居中；非对称图标应在组件中设定明确的视觉偏移。图标与标签组合应使用同一个间距令牌。
  • 留出呼吸空间。 内容不得溢出或紧贴容器边缘：内边距至少应等于其中包含的间距，并为最长本地化文本、悬停缩放和焦点环预留空间；交互界面在所有受支持的宽高比下都应位于安全区域内。内容放不下时，应调整布局，而不是边距。
• 通过流程选择字体，而非列出禁用字体：根据概念（时代、材质、语气、数据密度）列出三个候选字体系列，再说明选择理由。字体系列必须在实际字号和语言下清晰易读，并具备所需的字重、样式、数字、字形覆盖范围（支持西里尔字母时也应包括在内）和回退行为。没有任何字体系列是禁止使用的，但习惯性选用字体就是缺陷：没有理由地用一种潮流默认字体（Inter、Uni Sans）替换为下一种（Space Grotesk、DM Sans、Instrument Serif），仍然是在套用同一个模板。时髦的字体绝不能让界面更难阅读。
• 通过主次关系和对比建立层级：每个屏幕或区块设置一个主视觉元素；字号刻度应清晰分级（富有表现力的界面中，展示字号为正文的 3–5 倍，密集工具中的级差更小）；在符合概念时有意采用不对称布局；相邻区块应在结构上有所区别，而不是反复使用同一种区块模式。
• 如果黄金比例有助于构图，可用于指导比例、层级、裁切或留白，但它只是视觉工具，并非必须遵循的公式。若与实际任务、内容、响应式限制、可读性或现有系统冲突，应优先考虑后者。
• 如果主屏幕的内容可通过操作、分组或视觉锚点来理解，就不要将其做成一整面不间断的说明文字。将密集的说明拆分为便于浏览的区块，并在适用时配上有意义的控件、图标、插图、预览、图表或其他与任务相关的图像。例如，仪表板或账户区域应展示其主要区块和后续操作，而不应只说明用户可以配置什么。不要添加妨碍理解或造成虚假操作暗示的装饰性视觉元素。
• 使用颜色表达含义并突出重点；不要只用颜色表达状态。错误/成功/必填/已选信息应同时搭配文字、图标、形状、图案或其他非颜色提示，使其在灰度显示和色觉缺陷情况下仍清晰可见。
• 应用不透明度、叠加层、渐变、图像和所有必需主题后，检查实际相邻前景色与背景色之间的对比度；不要将接近阈值的结果四舍五入。普通文本和有意义的文字图像至少应达到 4.5:1；只有大号文本（常规字重至少为 24 CSS px，或粗体至少为 18.5 CSS px）才可采用 3:1。对于较细、小号或特殊字体，应争取更高的对比度。
• 视觉信息若用于识别活动控件、焦点或状态，以及有意义的图形对象与其相邻颜色之间的关系，则至少应达到 3:1 的对比度。仅当边框是识别控件所必需时，才必须添加边框；若边框用于此目的，就必须达到相同的 3:1 阈值。真正处于非活动状态的控件可以使用较低对比度，但必须明确显示为不可用，且绝不能成为完成主要任务的唯一方式。
• 选择一套风格统一的图标集。若项目中已有合适的标准图标，就不要重新绘制。根据任务需要，可使用自定义图形、图表和 SVG。使用熟悉且有明确含义的图标，强化操作或状态，尤其是紧凑且高频使用的控件：例如，为 Play 标签配上向右的启动三角形。图标用于辅助文字；对于不熟悉的操作，不要只用含义模糊的图标作为标签。

5. 用动效让界面保持鲜活

静态界面会显得死气沉沉：控件不响应手指、面板凭空出现、数字毫无痕迹地切换、列表突然跳动。动效和色彩、字体一样，都是系统的一部分，有自己的特性、令牌、层级和规则。目标是不留死寂时刻，也不做无意义的动效，而不是增加更多动画。对于创建、重新设计，以及任何会添加、移除或转换元素或状态的改动，请遵循 motion.md；对于有明确范围的修复，请沿用现有动效令牌。

• 每个动作都要有明确的用途：反馈、因果关系（元素从何处来、到何处去）、方向感（空间模型）、数值变化或生命迹象。没有用途，就不要动。
• 每个交互元素都要立即响应输入，在指针按下或触摸按下时就给出反馈，不要等结果出现：按钮压下后回弹，开关滑动，标签指示器滑动。反馈不得延迟操作本身，也不得延迟界面响应输入。
• 交互基线（必需，不是润色）。 如果没有内置交互，模型往往会跳过；因此，对于你创建或重新设计的任何 UI，都应在构建组件之前采用交互套件：interaction-kit.css + interaction-kit.js（或将其移植到技术栈的 Button/Link/Switch 组件），并映射到 DESIGN.md 中的动效令牌。它为每个控件提供三层按压效果（在 ≤ 90 ms 内将边缘压缩约 4 px，并伴随填充变化；从触摸点扩散的光晕；带约 1% 过冲的弹簧回弹）、悬停和焦点过渡、90 ms 的最短按压时长（确保快速点击也能看见反馈）、键盘按压、开关、复选框、滑动式分段指示器、按钮的等待／完成／错误状态、图标切换、从触发控件展开的菜单，以及高度动画展开的内容区域。单独的 1–2 px 位移，或瞬间恢复的 0.97 缩放，都不算按压反馈；参见 motion.md 第 5 节。
• 每个由用户触发的状态变化都要通过过渡呈现，而不是突然切换：覆盖层从触发控件处展开，插入和移除行时推开相邻行，分区以高度变化展开，骨架屏交叉淡化为内容，变化的数字滚动到新数值。可见的结果还可以移动到它实际起作用的位置（例如，将收集到的奖励飞入余额）。
• 将动效构建为一个系统：按用途划分少量时长、缓动和弹簧令牌；频繁操作用时更短，移动距离更长时用时更长；退出快于进入；整个产品采用统一的物理效果。不要使用 transition: all 或未经调整的默认 ease。
• 编排动效：每个事件只安排一个主要动作，其他动作作为辅助；振幅要小（几像素，缩放 0.95–0.98，而不是从零开始）；交错动画最多只覆盖少数几个项目；共享元素应移动，而不是消失后再出现。
• 保持动效可中断，并能从当前值重新确定目标；延续手势速度；对合成属性（transform、opacity）添加动画；在性能较弱的设备上也要控制帧预算。
• 环境动效应少见、缓慢、处于外围，并源于概念本身；元素隐藏或移出视口时应停止。无限脉冲、漂浮光球，以及每个分区都触发滚动显现，都是噪声。
• 减少动态效果时，应以交叉淡化或即时变化取代空间移动；但不得移除反馈或状态。遵守闪烁及暂停／停止／隐藏限制，绝不能让动画成为传达重要状态的唯一方式。

可选效果池

当富有表现力的界面需要一个标志性细节，而惯常做法（卡片抬起、按钮变大）看起来像套用模板时，请从 effects-library.md 中选择：动态和烘焙式有序抖动、胶片颗粒、环绕主按钮的光线、拉丝金属文字、蓝图式分区导轨、非抬起缩放式悬停响应、变形为胶囊的页眉、由距离驱动的封面流、条形码刻度滑块、滑动故事卡片堆，以及路由线路上的数据包；点阵语言（带指针聚光效果的点阵网格、由点重构的图像和文字、带路线的点阵地球、脉动点带、点列数据、5×5 LED 状态图标、螺栓固定的面板和角括号、活动卡片上的彗星）；以及滚动联动场景（溢出行的边缘渐隐、定时点状导航、媒体平稳落入画框、分区主题切换）。经过测试的代码位于 assets/effects/，其中包含一个测试页面。

• 效果池为可选项。应根据概念和明确的功能来挑选，绝不默认使用；界面不使用效果池中的任何效果也同样完整。在本项目的设计风格中，只使用第 9 节标记为适用的效果，并采用单色变体，除非产品本身带有颜色。信息密集型工具只使用悬停响应、页眉变形和应用于真实数据的滑块。
• 遵守页面预算（每页一个动态场和一个地球，每个视口一个环形效果和一个光泽效果，总计使用两到四种效果池效果），并在 DESIGN.md 和 direction.motion 中记录所选 ID。点是材质：采用间距比例中的一个间距值、使用淡色调点，并让页面上确实有内容由点构成；光秃秃的点阵壁纸属于粗制滥造。
• 采用选定的代码块及其回退、减少动态效果、离屏暂停和无障碍部分；将 --fx-* 令牌映射到 DESIGN.md 中的角色；绝不导入整个文件。

6. 用决策取代 AI 垃圾风格

垃圾风格模式是模型出于习惯而非产品需求做出的选择：换到任何其他网站上，它都不会显得突兀。完整目录为每种模式提供了检测信号、替代方案和合理例外，见 ai-slop.md；它是这些规则的唯一依据。在渲染新建或重新设计的界面之前，请先阅读该文件，并在之后对截图运行垃圾风格扫描。移除一种模式却不提供替代方案，只会得到一个更乏味的模板。目录按 ID 分类如下：

• 构图与卡片：图标、标题和文本完全相同的卡片网格；图标块堆叠在标题上方且图标尺寸过大；嵌套卡片层；圆角卡片上的彩色侧条和粗重强调边框；英雄指标布局；展示尺寸的英雄标题；工作工具中的营销板块；所有内容都居中；装饰性网格背景。
• 色彩与光效：AI 配色（紫到蓝的渐变、暗色背景上的青色）；渐变文本；玻璃质感和霓虹“偷懒式酷炫”效果；径向光晕、聚光灯和光球；默认使用奶油色／米色。
• 排版：习惯性使用默认字体；扁平的层级；斜体衬线展示标题；标题上方的眉题标签和药丸徽章。
• 动效：所有内容同时争抢注意力；脉冲状态点；每个版块都在滚动时显示（详情见 motion.md）。
• 图像：粗糙的手绘 SVG 场景和吉祥物；图库图片和混杂的图标集；只用闪光效果来标记 AI。
• 文案与行为：介绍页面显而易见用途的开场白；只是换种说法重复开关标签的描述；默认给每一行都添加辅助文本；同一任务区域内重复表达相同含义；泛泛的营销宣传；强行使用“不是 X，而是 Y”的对比句式；每句话都用破折号；虚假内容；无效控件和虚假成功提示。

如果 DESIGN.md 将某种模式记录为有意采用的品牌选择，那它就不属于垃圾风格。这些限制针对的是不加思考地使用这些元素，并非禁止使用色彩、字体、卡片或表现力。

评估语义：嵌套的 DOM 容器并不必然是装饰性卡片。 先尝试调整层级、对齐和间距。确认去掉装饰后不会破坏有用的分组。不要以“极简”为由隐藏操作，或移除必要的提示、标签、快捷键、错误信息，或对陌生概念的说明。

将界面文案也纳入此次审查。对每段介绍、副标题、提示和工具提示，都应用目录“文案”部分中的信息测试：如果删掉它，用户会失去什么具体信息？如果它只是在复述标题、标签或可见状态，就应删除，即使换了种说法也一样。不要仅仅因为组件提供了一个插槽，就添加描述。保留经过核实的后果、限制、要求、恢复方法和必要的无障碍使用说明；绝不要编造事实来替代填充内容。这一要求同样适用于普通工作界面和表现力强的页面。如果文档的实际用途是介绍功能，则可以在其中说明功能。

7. 同时实现行为与外观

• 阅读 behavior-and-content.md 中适用的章节。 为每项操作提供可观察的结果，并为每项风险提供恢复途径。
• 让组件中的辅助描述可选；未使用时，移除其包装元素和间距。工作页面应以任务、数据或控件开篇；只有在标题之外还提供用户所需信息时，才添加引导说明。以目录中的文案规则为准。
• 补齐受影响组件的必需状态。悬停状态适用于指针操作；选中／已勾选／已展开状态分别对应其语义；等待／错误／重试状态适用于异步操作。不要为静态区块凭空添加加载／错误状态。
• 命令使用按钮，导航使用链接，字段使用持久标签。图标操作需要名称。支持键盘／辅助设备、清晰可见的焦点，以及符合预期的返回／取消行为。
• 出错时保留已输入的数据，并显示原因和下一步操作。不要把加载失败伪装成空列表。避免重复提交和过时响应。
• 为每个异步区域设置明确的加载状态，并根据预计时长和已知内容形态选择状态（参见 behavior-and-content.md 的加载章节）。初次加载内容时，使用布局与实际内容一致的骨架屏；将操作进度显示在控件内；长时间操作使用确定性进度指示。仅在真正的启动阶段使用加载闪屏：例如应用必须完成网络发现、登录或会话恢复、强制同步或资源加载等耗时步骤后，才能显示有意义的内容。闪屏应展示实际阶段；失败时提供重试或离线选项；不得添加人为延迟；若缓存数据可用于显示界面，则跳过闪屏。
• 主动支持拖放，不要等到有人提出才处理。所有允许用户导入内容的位置（文件或图片上传、头像、封面、附件、导入、资源或模组槽位），首个版本就应配备放置区，并在旁提供可用的“选择文件”按钮。放置区在静止状态下应清晰易懂（图标、“将文件拖放到此处或选择文件”、支持的类型和限制），并提供不同且不依赖颜色区分的状态：文件拖到窗口上、拖到放置区上、文件将被拒绝、正在上传并显示每个文件的进度、完成并显示预览及移除／替换选项、失败并说明原因且可重试。拖放到放置区外时，不能打开文件，也不能清空表单。用户可排序的集合（图库、播放列表、优先级、看板）应支持拖放排序或移动，并始终提供按钮／菜单和键盘替代操作。详情见 behavior-and-content.md 的拖放章节。
• 与每种状态一并实现动效，不要留到后期润色：组件新增的每种状态（按下、打开、选中、等待、插入、移除、错误、成功）都应使用动效目录中的动效和令牌，并提供减少动态效果时的替代方案。
• 对于重要且不可逆的操作，使用适用的撤销、确认或审核机制。不要让每次保存都弹出确认对话框。
• 只完整实现所请求的流程。在原型中标明模拟数据；如后端不可用，应如实说明这是限制，而不是模拟操作已完成。

8. 验证实际界面

• 对于 Web 项目，请阅读 web-quality.md；对于原生应用／桌面应用／游戏，请阅读 platform-adapters.md 中的相关部分。 使用当前项目的工具、运行时和平台无障碍 API。 按照环境规定的方法获取特定库的文档。
• 首先运行适用的类型／构建／lint 检查和令牌检查；然后进行安全的交互／键盘、错误、恢复、响应式和视觉检查。
• 检查是否符合 DESIGN.md：变更代码中的每个样式字面值都必须是 DESIGN.md 令牌或合理的布局值；渲染结果中的字体系列、字号、控件高度、圆角和文字颜色必须符合 DESIGN.md，并且同一角色在各屏幕上的渲染值保持一致。操作步骤见 design-md.md；将其记录为 tokens 检查。
• 检查所需状态和尺寸下的当前渲染结果：层级、易读性、焦点、溢出、重叠和缺失的操作。不要仅凭 JSX 推断是否正确。
• 测量布局几何尺寸，而不要凭目测判断：使用该技术栈（web, Unity, Godot）的布局转储工具导出渲染布局，并针对矩阵中的每种分辨率运行 check_layout.py；修复每个 uneven-gap、misaligned-*、off-center、overflow、tight-edge 和 overlap 问题的根本原因，并重新运行，直到检查通过。然后以 1:1 比例或放大裁剪图检查每一行按钮、列表起始边缘和小控件；全屏缩略图无法显示 2px 的误差。将其记录为 layout 检查。操作步骤和注释见 layout-geometry.md 第 6 节。
• 检查各个受影响任务区域中的可见文案和无障碍名称／描述。针对标题、标签、状态和相邻文本运行目录的信息测试；测试内容应包括语义相近的改述，而不只是完全重复的内容。删除后，确认必要的说明和后果仍然保留、无障碍关联仍能解析，并且布局中没有空的描述间隙。报告具有代表性的删除内容及有充分理由保留的帮助信息。
• 验证定义的平台矩阵中的每个视口和浏览器缩放目标，包括最小和最宽的受支持界面。确认布局、触控目标、控件、图像、文本换行、安全区域、滚动和状态反馈都能适配，不会发生裁切、重叠、意外的水平滚动或主要操作缺失。
• 测试较长的真实数据、200% 文字缩放、适用的主题和减少动态效果。对于文本变更，可使用伪扩展；支持或要求 RTL 时应进行测试。不要把局部修复扩大为 i18n 或设计系统迁移。
• 使用具有预期结果的安全测试数据逐步验证操作。不要自动触发实时系统中的每个控件：测试可能会删除记录或发送消息。
• 在真实界面上检查加载状态：通过节流或延迟测试数据，观察骨架屏、替换过程是否造成布局偏移、超时／错误路径，以及启动画面各阶段和失败情形。
• 将真实文件拖到每个上传区域进行测试：窗口级和区域级高亮、鼠标悬停在子元素上时不会闪烁、拒绝错误类型和超大文件时给出原因、一次拖放多个文件、在区域旁边放开文件时既不打开文件也不清空表单，以及按钮、键盘和粘贴方式仍然可用。在触屏设备上，该区域应表现为文件选择器，不得使用“拖动”字样。
• 对每个新建或变更的页面运行动态效果探测： node scripts/motion_probe.mjs <url-or-file>（无依赖的无头 Chrome）。它会悬停、按下（在区域外释放，因此不会触发任何操作）并通过键盘聚焦每个可交互元素；若缺少按下反馈、缺少焦点或状态卡住，则会判定失败；若按下反馈较弱、恢复过快、缺少悬停效果或使用 transition: all，则会发出警告。修复问题，直到错误数为 0；然后使用 --reduced-motion 重新运行，并将结果记录在 motion 检查中。
• 应在动态过程中检查动态效果，而不是只看静态画面：以慢速录制或逐步播放关键过渡；走完主要流程，找出无响应时刻（输入后约 100 ms 内没有可见响应，以及状态被切断的情况）；快速连续点击并在过渡中途取消，以发现排队和卡住状态；列出所有空闲时仍在移动的内容并说明理由；在低性能配置下验证减少动态效果设置和帧时序。详情见 motion.md 的验证部分。
• 对于新建或重新设计的表现性界面，在功能正常后，针对当前截图单独进行一轮评审：进行替换测试（原样替换后是否适用于竞争对手？）、眯眼测试（模糊的灰度截图是否仍显示层级和一个主导元素？）、与概念和参考资料进行对比，并按照 ai-slop.md 中的模式 ID 进行套路化设计扫描。重新设计任何看起来像“随处可见的模板”的部分。
• 离线辅助脚本 validate_design.py 会验证自身的契约格式和有限的令牌子集；说明见 validation.md。 其 PASS 结果仅确认所列的结构／颜色检查通过。 该辅助脚本不包含浏览器、屏幕阅读器或完整的 WCAG 审核。

9. 根据任务和证据验收

• 阻断级问题：主要场景无法使用、数据丢失、重要操作无法访问、缺少必需的名称或焦点、存在键盘陷阱，或重要内容被隐藏。
• 错误：实现行为或适用的项目规则偏离约定；修改后的代码使用了 DESIGN.md 以外的值，却未添加对应角色，或 DESIGN.md 与代码中的令牌不同步；粗糙模式扫描发现了严重级别为错误且缺乏合理依据的模式；异步区域没有加载状态，或将失败显示为空；没有真正的引导需求却使用了启动页；任何元素溢出或贴靠容器或安全区域，同类相邻间距不一致，行、列或设置基准线偏差超过容差，或文本／图标在控件中未居中且没有声明视觉偏移；文件或图片上传没有拖放区，拖放区没有清晰可见的拖动悬停状态，或只能通过拖动来添加或重新排序；或者当任务涉及身份识别时，结果未通过替换测试或与记录的方向相矛盾；创建或重新设计的界面缺乏交互反馈（控件按下时无反馈、覆盖层和列表更改生硬切换），或运动探测报告错误，或未在创建／修改的页面上运行；采用了池化效果却没有提供回退、减少动态效果或暂停路径，或超出页面预算且没有记录原因；动态效果阻碍输入、重复输入时排队、卡顿，或减少动态效果时连反馈也完全消失；或者任何内容闪烁或循环播放，却没有暂停路径。新编写的页面旁白、对标签的改述，或没有提供新信息的重复辅助文本，即使在密集型工具中也属于错误；删除必要说明，或编造产品声明来替代填充内容，同样属于错误。仅在任务范围内应用这些检查。 警告：品味启发式、过多的卡片／胶囊／阴影、可疑的信息密度或主观语气；动态效果偏离令牌或使用未命名的函数、装饰性的滚动显示、空闲时的动效噪声；对于密集型工作工具，外观通用属于警告，而非错误。 更改之前先确认上下文。不要把计数器当作对美观程度的评估。
• 在任务范围内修复已确认的重大缺陷，并重新检查受影响的部分。 场景通过验收后，如任务涉及身份识别，还应确保独特性和动态效果检查通过，然后停止润色；如果仍有阻断级问题，不要因随意设定的迭代次数而停止。批评检查一无所获时，应再检查一遍。
• 报告更改内容、实际检查过的操作／状态、结果所在位置，以及无法执行的检查。将未测试的工作标记为未经验证，而非 PASS。
• 不要声称扫描器能证明完全符合 WCAG，不要声称无障碍树等同于屏幕阅读器测试，不要声称本地 Lighthouse 能测出实际用户群体的 p75，也不要根据单个屏幕声称 UX 提升了某个百分比。
• 若要评估生成器本身，请使用 evaluations.md。 规范性要求的依据和边界见 sources.md。