ui-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

UI review

UI 评审

The render is the evidence. A description, DOM text or source code only supports it. Severity, the 13 criteria and the edge cases are in

references/criteria.md

. An installed design system's own rules come first and count as agreed criteria.

渲染结果才是证据。描述、DOM 文本或源代码只能作为佐证。严重程度、13 项标准和边界情况见

references/criteria.md

。已安装的设计系统自身的规则优先，并计为已达成一致的标准。

Steps

步骤

Scope. What the caller names, else the branch's changed screens, else the five top routes.
Lint. Run the project's own lint on the scoped files. Record the command and exit code.
Capture each screen at each width (the app's narrowest and widest, 390 and 1280 by default) in the states that matter, one fresh navigation per width. With
```
build-design-system
```
installed,
```
build-design-system/scripts/capture.mjs
```
does this behind a guard that blocks every write and saves each capture's accessibility tree. It needs
```
--writes <file>
```
listing the app's writes, or
```
--no-backend
```
, and writes only to its
```
--out
```
folder (keep that under
```
.ui-review/
```
). Otherwise use the host's browser tool and save the tree yourself. Run the project's accessibility scanner too when it has one.
Fix the purpose of each screen in one line. Mark it assumed when the caller did not give it.
Probe the traps each screen has, on a local build only: keyboard path, focus after close, loading and error states, a throttled tab, reduced motion, and a touch width. Each probe gets a measured result or a reason it did not run. Measure press feedback with the Event Timing API (a
```
PerformanceObserver
```
on
```
event
```
entries, each
```
duration
```
under 100 ms). Do not click anything that writes to shared data.
Walk the criteria at each width. Cite each finding by number and name, or by the installed rule's ID.
Sort. With more than one reviewer available (a panel), give each the same prompt and no persona, read only. The coordinator then sorts every finding into
```
blocking
```
,
```
should-fix
```
,
```
note
```
or
```
dismissed
```
, naming who raised it and giving one line of reason. A finding raised by two reviewers on their own is the strongest signal. Dismiss nitpicks, hypotheticals nobody traced to a real call site, and "I would have done it differently". Within a bucket, put surfaces that write data first, then order by places hit. Without a panel, do the same alone.
Walk the edge cases and mark each shown or not shown.
Write the verdict last.

范围。 优先采用调用方指定的范围；否则采用该分支中发生变更的屏幕；否则采用五个主要路由。
Lint。 对限定范围内的文件运行项目自身的 lint。记录命令和退出码。
捕获每个宽度下的每个屏幕（即应用的最窄和最宽宽度，默认分别为 390 和 1280），并覆盖相关状态；每个宽度都进行一次全新导航。安装
```
build-design-system
```
后，
```
build-design-system/scripts/capture.mjs
```
会通过一个阻止所有写入操作的 guard 执行，并保存每次捕获的 accessibility tree。它需要提供
```
--writes <file>
```
（列出应用的写入操作），或使用
```
--no-backend
```
；并且只能写入
```
--out
```
文件夹（将其放在
```
.ui-review/
```
下）。否则使用宿主环境的浏览器工具，并自行保存 accessibility tree。如果项目配有 accessibility scanner，也应运行它。
用一行说明每个屏幕的用途。若调用方未提供，则标记为假设。
仅在本地构建版本上探查每个屏幕可能存在的陷阱：键盘操作路径、关闭后的焦点、加载和错误状态、经节流处理的标签页、减少动态效果（reduced motion）和触控宽度。每项探查都要给出测量结果，或说明未运行的原因。使用 Event Timing API 测量按压反馈（使用
```
PerformanceObserver
```
监听
```
event
```
条目，每项的
```
duration
```
均应低于 100 ms）。不要点击任何会写入共享数据的元素。
在每个宽度下逐项检查标准。每项发现都要按编号和名称引用标准，或引用已安装规则的 ID。
排序。 如果有评审组可用，给每位成员相同的提示词，不设置 persona，并且只进行只读评审。协调者随后将每项发现归入
```
blocking
```
、
```
should-fix
```
、
```
note
```
或
```
dismissed
```
，注明由谁提出，并给出一行理由。一项发现若由两位评审者各自独立提出，就是最强的信号。不要纳入吹毛求疵的问题、无法追溯到真实调用位置的假设，以及“我本会采用不同做法”之类的意见。同一分组内，先列出会写入数据的界面，再按命中位置排序。如果没有评审组，则独自执行相同流程。
逐项检查边界情况，并标记每项已展示或未展示。
最后撰写结论。

Rules

规则

A finding has a criterion, a findable location (the element by role and name, with its capture, as in
```
button 'Save changes' (settings-1280.png)
```
), the width, and the evidence. A finding that rests on taste is dropped to Left out.
Wrong: "The spacing feels tight." Right: "Label sits 24 px from its own field and 8 px from the next one (criterion 4, settings-390.png)."
An inferred finding is written as the check that settles it. An inferred
```
blocking
```
finding makes the verdict
```
no, pending <the check>
```
.
A claim that something works or is fixed names a command or capture from this session.
Contrast, target size and keyboard problems are ranked. A change to the accessibility tree that only adds semantics is ranked. One that removes or restructures semantics goes to a person.
A finding or pass on responsiveness to input (criterion 13) from a screenshot is invalid. It needs a measured probe. A focus ring is the reverse. Reach the control with real Tab presses and judge the ring from the capture, because a container that draws it through
```
:has(:focus-visible)
```
leaves the focused element reporting no outline.
Product decisions behind a fix go to For a person to decide. Keeping the user's input is never one.

一项发现必须包含：对应的标准、可查找的位置（以 role 和 name 标识元素，并附上对应捕获结果，例如
```
button 'Save changes' (settings-1280.png)
```
）、宽度和证据。仅凭个人审美得出的发现应归入“未纳入”。
错误：“间距感觉太紧了。”正确：“标签距离自身字段 24 px，却距下一个字段仅 8 px（标准 4，settings-390.png）。”
推断得出的发现应写成一项能够确认问题的检查。若推断出的
```
blocking
```
发现，结论应为
```
否，待完成 <检查项>
```
。
声称某项功能可用或已经修复时，必须指出本次会话运行过的命令或生成的捕获结果。
对比度、目标尺寸和键盘问题都要纳入排序。对 accessibility tree 仅添加语义的改动也要纳入排序；删除或重构语义的改动则交给人决定。
仅凭截图得出的输入响应性发现（标准 13）无效；它需要经过实际测量的探查。焦点环则相反：必须用真实的 Tab 按键到达控件，再根据捕获结果判断焦点环，因为一个通过
```
:has(:focus-visible)
```
绘制焦点环的容器，会使获得焦点的元素仍然报告没有 outline。
修复方案背后的产品决策归入“需要人来决定”。保留用户已输入内容绝不属于此类。

Output

输出

The first line answers the ask in plain words. The ship line follows:

Ready to ship: no. Enter in Email cancels the invite (blocking 1, should-fix 2, 3 questions for a person).

Any

blocking

finding makes the verdict

no

, an inferred one

no, pending <the check>

should-fix

alone

yes, with fixes

, only notes

yes

Then, in order:

Review record. Source, tool, widths, date, criteria file, the purpose marked given or assumed, every assumption and gap.
Findings by bucket, each with who raised it, what was seen, where, criterion, why it matters here, evidence, and the fix as a check that fails on the current build (
```
Fix Enter in Email so that it sends 1 POST
```
).
Edge cases not shown. One line each.
For a person to decide.
Dismissed and left out. Each with who raised it and the reason.

Run on its own, save the report to

.ui-review/<date>-<flow>.md

with captures beside it. When a coordinator asks for captures only, return the capture paths, widths and

Coverage:

line, and no findings. The chat reply gives the answer and ship lines, each command with its exit code, and one prompt the person can paste to take the next step.

第一行用平实的话直接回答问题。接下来是发布结论行：

可以发布：否。在 Email 中按 Enter 会取消邀请（blocking 1，should-fix 2，另有 3 个需要人来决定的问题）。

任何

blocking

发现都会使结论变成

否

；若是推断出的发现，则为

否，待完成 <检查项>

；只有

should-fix

时为

是，需要修复

；只有

note

时为

是

。

然后按以下顺序输出：

评审记录。 来源、工具、宽度、日期、标准文件、用途（标明是给定还是假设）、每项假设和缺口。
发现。 按分组列出，每项包括提出者、观察到的现象、位置、对应标准、为何在此处重要、证据，以及一项会在当前构建版本上失败的检查，用以验证修复方案（
```
修复 Email 中的 Enter，使其发送 1 次 POST
```
）。
未展示的边界情况。 每项一行。
需要人来决定。
已驳回和未纳入。 每项注明提出者和原因。

单独运行，将报告保存到

.ui-review/<date>-<flow>.md

，捕获文件放在报告旁边。当协调者只要求提供捕获结果时，仅返回捕获路径、宽度和

Coverage:

行，不返回发现。聊天回复应包含回答行和发布结论行、每条命令及其退出码，以及一段人员可以直接粘贴来推进下一步的提示词。

Done

完成标准

Every finding has a criterion, a location, evidence and only the widths where it shows. Every probe has a result or a reason. The first line, the ship line and the summary agree. The last line reads

Coverage:

with the routes, widths, themes and probes measured, then what was not.

每项发现都有标准、位置和证据，并且只报告问题实际出现的宽度。每项探查都有结果或未运行的原因。第一行、发布结论行和摘要相互一致。最后一行以

Coverage:

开头，列出已测量的路由、宽度、主题和探查项，然后说明未覆盖的部分。