seenry-review

Seenry Review

评判实际渲染出来的内容，而不是代码的意图。每条发现都应清晰可见、具体、标明优先级，并附上最小修复方案。以 Seenry system 中的规则为标准：网格与间距、每个组件的字体限制、同心圆角、一个强调色、一致的页面外壳，以及 anti-slop list。

如果界面是你自己构建的，请说明，并将结论视为自我审查。使用全新的 Agent 上下文更好。

证据，而非审美

报告你能举证的内容：测量结果、截图、未通过的检查，或带有数字的规则。密度、圆角或语气与你个人偏好的不同，如果是项目有意选择且始终如一地应用，就不算发现。严格检查以下触发项；对个人偏好则保持沉默。基于实际检查的简短审查，胜过为了显得全面而堆砌内容的长篇审查；“没有可执行的发现”也是有效结论。

一眼可见的高优先级问题（绝不能因界面影响较小而降低优先级）：

• 交互控件没有无障碍名称、没有可见焦点，或无法通过键盘操作
• 在 320px、200% 缩放或键盘遮挡时，内容或控件被裁切、重叠或无法触及
• 文本或控件在实际渲染的界面上的对比度低于要求的比率
• 仅通过颜色或仅通过动画来传达状态或含义
• 忽略 prefers-reduced-motion 的动画，或应用于每日使用 100 次以上或由键盘驱动的操作的动画
• 破坏性操作没有确认、撤销选项或明确的视觉区分
• 内容被截断且无法查看完整内容；错误发生后无法恢复
• 语义颜色与含义相悖（安全操作使用危险色）
• 最终版本中仍包含占位内容（用渐变代替图片、Lorem ipsum、虚假推荐语）

优先采用成本更低的修复方案。 提出最早可行的方案：删除（行间距已有足够留白、或不该存在的动画）、使用平台原生功能（原生元素、原生焦点环）、复用项目令牌或组件、修正数值，最后才添加新内容。

合并同类问题。 一个根本原因只列一条，并注明所有相关位置。最多报告 15 条发现；先列触发项。若因数量上限而未能列出全部发现，请说明剩余数量。

选择模式

用户请求	模式
“审查／点评／审核此页面、屏幕或网站”	屏幕审查
“审查此分支／PR／提交／我的更改”	更改审查：运行 git diff 与基准版本比较，列出已更改的 UI 界面，在更改前后分别渲染，并且只审查这些界面
“对这个组件进行压力测试／找出问题”	压力测试
“是否符合无障碍要求／WCAG”	屏幕审查，仅进行无障碍检查，并使用检查清单
“审查／改进动画”“哪些地方应该使用动画”	动画审查
“这个交互是如何构建的／解释这个交互”	解释

页面审查

1. 渲染。 分别以 1440 和 390 的视口宽度打开页面（另加 320 检查溢出）。为每种宽度截图。使用指针和键盘操作主要操作。
   • 先审查完整流程，再看动效。 说明组件的用途、用户如何进入、每个有意义的操作及其可见结果。检查是否易于发现、返回／取消／关闭行为是否恰当、焦点是否返回、相关的空状态／错误状态／禁用状态、重复或中断操作，以及手机端适配情况。只有说明原因时，才能将某个状态标记为不适用；未测试的状态仍须标记为未经验证。
   • 采用符合流程的关闭方式。 确认对话框可以使用“取消”和 Escape，并遵循原生模态行为；导航流程可以使用“返回”。不要要求每个对话框都额外提供“关闭”或 X 按钮。对于直接展开卡片或切换流程，返回触发位置的控件属于空间布局标准，不是所有对话框的通用要求。现有控件仍需有清晰的名称、易于操作的目标区域、可见的焦点状态和正确的操作结果。
2. 测量。 运行 node ../seenry/scripts/audit_page.mjs <url or file> --widths 1440,390,320 --shots <dir>（页面审计）；该命令结合了系统审计和视觉审计，适用于任何项目。记录总数：字号、字重、字体系列、圆角、阴影、偏离网格的值、嵌套圆角违规项、超出限制的组件、水平溢出，以及每个组件的对齐锚点、边缘近似对齐项和视觉内边距（对齐）。切换网格叠加层，检查共享边缘。
3. 按以下顺序检查，因为前面的失败会让后续检查失去意义：
   • 任务和层级。 5 秒内能否明确了解这是做什么的、面向谁，以及接下来该做什么？主要操作是否是最醒目的控件？
   • 素材和锚点。 使用的是真实图像、图标和数据，还是占位内容？每个元素是否都与其他元素的边缘或中心线对齐，还是有些元素漂浮？是否有一个主导元素和一个细节层？参阅探索中的工作室式评审方法。
   • 布局。 共享内容边缘、区块节奏、分组（2x 规则）、阅读顺序、手机端重排。
   • 字体。 每个组件和页面的字体系列数量、字号和字重，展示文字的字重和字间距、行长、换行。
   • 颜色和表面。 强调色的面积和作用、对比度、层级选择、圆角系列和同心度。
   • 组件和状态。 悬停、焦点、激活、禁用、加载、空状态、错误、溢出。
   • 内容。 文案是否具体，数据是否真实，声明是否有证据支持。
   • 无障碍。 键盘操作路径、焦点可见性、名称、对比度、目标区域、缩放、减少动态效果。
4. 比较。 适用时，与参考进行对比：使用 Seenry MCP，从 2–3 个优秀网站获取相同页面类型（使用 search_references 和 page_type，或使用 list_sites + get_design），并指出具体差异。参阅基准。

报告格式

按严重程度排序的一张表，每个根本原因占一行，列出所有位置：

严重程度	位置	当前状态	改为	原因
高	Hero.tsx:14	h1 72px / 800 / 0 字距 / 1.2	56px / 500 / −0.03em / 1.05	默认展示样式过于厚重，看起来像模板；参见基准
高	定价页，390px	套餐溢出，出现水平滚动	套餐纵向排列，CTA 占满宽度	支持的宽度下内容被隐藏
中	Card.tsx:8	圆角 16，内缩 12，图片圆角 16	图片圆角 4	圆角不同心

• 高：阻碍任务完成或在支持的尺寸下隐藏内容／操作，未通过对比度或键盘检查，或一眼看上去像是生成的。
• 中：损害层级、一致性或清晰度。
• 低：润色。

然后给出：两个宽度下的系统审查汇总、已验证和未验证的内容（动效、屏幕阅读器、设备），以及一行结论：可以发布、修复后发布（仅有中等问题）或 阻止发布（存在任何高优先级问题）。不要擅自重写页面；可以提出代为应用修复。

变更审查

要回答的问题是“这项变更是否让界面变差了？”，而不是“这个代码库有什么问题？”。

1. 确定审查范围。 如果指定了 PR、分支或提交范围，就按指定范围审查。否则，审查相对于默认分支合并基点之后的提交，以及未提交的变更；如果没有，则仅审查未提交的变更；如果也没有，则停止并询问要审查什么。
2. 将文件范围扩展到界面。 变更的令牌、共享组件或样式表会影响所有使用它们的屏幕；列出这些屏幕。在变更前（使用工作树或 git stash）和变更后，分别在两个宽度下渲染受影响的状态，并运行页面审查。
3. 阅读被删除的行。 删除焦点样式、aria-* 属性、alt 文本、减少动态效果的代码块、min-width: 0、标签和错误处理，都属于回归，即使新增代码看起来没问题。
4. 依据变更声明的意图进行审查（PR 描述、提交信息）：未完成的推广属于审查发现。
5. 为每项发现分类： 新增问题（新问题）、回归（原本正常工作的内容现在失效；如果回归触发高优先级的一眼可见问题，则属高优先级）、既有问题（最多报告三个，单独列出，不纳入结论）。
6. 按文件和行号标出绕过令牌的硬编码值。正确性、安全性和性能问题留给常规代码审查。

动效审查

清点范围内的每个过渡、动画和手势。对每一项，列出频率等级、用途、工具、属性、时长、缓动或弹簧、打断方式、减少动态效果和悬停门控，并对照 seenry-motion 中的构建顺序和 切勿发布 表。以正常速度和 10% 速度在 DevTools Animations 面板中逐一查看。还要列出 错过的机会（需要连贯性的突兀跳变、缺少反馈的按压）和 已否决的候选项（哪些内容应保持即时响应，以及原因）。使用表格格式报告。

压力测试

在临时页面上单独渲染组件，并同时展示所有真实可见的变体：

• 内容：空、1 个字符、典型内容、长度为 2 倍、长度为 5 倍、无分隔字符串（URL、电子邮件）、表情符号和 CJK、支持时测试 RTL、缺失图片、计数 0 / 1 / 99+ / 1,000,000、负数。
• 状态：默认、悬停、焦点可见、激活、禁用、加载中、错误、成功、已选中、已展开。
• 容器：宽度 240、320、390、768、1200；200% 缩放；增加文本间距。
• 输入：鼠标、纯键盘、触摸模拟、快速重复点击、过渡中途反向操作。

为变体网格截图，运行系统审查和 文本重叠检查，并使用表格格式报告失败项。之后删除临时页面，除非有人要求保留。

说明

先描述观察到的内容，再说明它可能是如何构建的，最后解释它为何适用于该任务。将观察结果与推断分开。对于实时网站，读取 DOM 和计算样式；对于动态效果，以正常速度录制或逐帧查看（截图无法证明时序）。使用 Seenry MCP 时，get_page_motion 和 get_design 可提供录制内容和测量得到的样式。最后说明如何将这一机制应用到用户的产品中，而不复制品牌素材。