jury

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/jury

Score a website the way the Awwwards jury would: from what a visitor sees and what the browser measures, never from the code, the design notes or what the owner meant. Hand back a score card with evidence for every number and a ranked list of fixes.

Not affiliated with Awwwards. The criteria and weights are theirs and public (awwwards.com/about-evaluation); the scores are an estimate. Say so on every card.

Skill root: the directory containing this file (

$SKILL

; substitute the absolute path in commands). The scripts need Node 20+ and Playwright, plus axe-core for the accessibility pass.

references/quality-bar.md

has the system, the rubric and the critic brief.

references/calibration.md

has the measured gap between this critic and real juries. It is for you, for the score card. Never give it to the critic.

像 Awwwards 评审团那样为网站评分：只依据访客看到的内容和浏览器测得的数据，绝不依据代码、设计说明或站主的真实意图。返回一份评分卡，每个分数都有证据，并附上按优先级排序的修复清单。

与 Awwwards 无关。 评判标准与权重归 Awwwards 所有且已公开（awwwards.com/about-evaluation）；评分仅为估算。每张评分卡都必须说明这一点。

Skill 根目录： 包含此文件的目录（

$SKILL

；在命令中替换为绝对路径）。脚本需要 Node 20+ 和 Playwright，无障碍检查还需要 axe-core。

references/quality-bar.md

包含评分体系、评分表和评审简报。

references/calibration.md

记录了该评审者与真实评审团之间经测量的差距。它供你和评分卡使用。绝不能把它交给评审者。

Why blind

为什么要盲评

Anyone who knows what a site is meant to do scores the intent instead of the screen. A juror gets a URL and a few minutes. So the critic gets only screenshots and measurements: no source, no

DESIGN.md

, no README, no pitch from the owner. If the user explains the idea, hold it until the score is in, then compare (step 5).

了解网站意图的人会评判意图，而不是实际呈现。真正的评审只拿到一个 URL 和几分钟时间。因此，评审者只能获得截图和测量结果：没有源代码，没有

DESIGN.md

，没有 README，也没有站主的介绍。如果用户解释了网站创意，先搁置这些信息，等评分完成后再进行对照（步骤 5）。

Workflow

工作流

1. Target

1. 目标

A URL: score what is deployed.
A local project, no URL: build it and serve the production output. Never score a dev server: unminified JS and dev overlays wreck WPO and add console noise.
- Next.js:
```
npm run build
```
  , then
```
npx next start -p 4400
```
  in the background.
- Static output (Astro, Vite, Next
```
output: 'export'
```
  ):
```
node $SKILL/scripts/serve.mjs <dist|out> --port 4400
```
  in the background.
- Anything else: its own production build and start commands.
A dev URL only (localhost with hot reload): build production instead if the project is here. If it isn't, score it and say the WPO numbers are pessimistic.
Several URLs ("mine vs theirs"): run steps 3 to 5 for each, each with its own fresh critic, then put the cards side by side.
Behind a login or password: it can't be scored. Ask for a public URL or a local build.

Evidence goes in

.jury/<host>/

in the current directory (

<host>

such as

example.com

127.0.0.1-4400

). Use absolute paths for it below.

一个 URL： 对已部署的网站评分。
没有 URL 的本地项目： 构建并启动生产构建产物。绝不要对开发服务器评分：未经压缩的 JS 和开发模式浮层会严重干扰 WPO，并增加 console 噪音。
- Next.js：在后台运行
```
npm run build
```
  ，然后运行
```
npx next start -p 4400
```
  。
- 静态输出（Astro、Vite、Next
```
output: 'export'
```
  ）：在后台运行
```
node $SKILL/scripts/serve.mjs <dist|out> --port 4400
```
  。
- 其他项目：使用其自身的生产构建与启动命令。
只有开发 URL（带热重载的 localhost）：如果项目位于当前目录，改为构建生产版本。如果项目不在这里，则照常评分，但必须说明 WPO 数字偏悲观。
多个 URL（“我的与他们的对比”）：分别对每个 URL 执行步骤 3 至 5，每个都使用一个全新的评审者，然后并排展示评分卡。
位于登录或密码之后： 无法评分。请要求用户提供公开 URL 或本地构建。

证据保存在当前目录的

.jury/<host>/

中（

<host>

可能是

example.com

或

127.0.0.1-4400

）。下文使用其绝对路径。

2. Tools

2. 工具

The scripts resolve Playwright and axe-core from their working directory.

If the current project already has Playwright (
```
node -e "require.resolve('playwright')"
```
succeeds), run the scripts from there.
Otherwise don't add dependencies to someone's project for a review. Install once into a cache folder outside it and run the scripts from that folder:
bash
```
mkdir -p ~/.cache/jury && cd ~/.cache/jury && npm init -y > /dev/null && npm i -D playwright axe-core
```
If
```
shoot.mjs
```
reports no Chromium, run
```
npx playwright install chromium
```
once in that folder.

脚本会从其工作目录解析 Playwright 和 axe-core。

如果当前项目已经安装 Playwright（
```
node -e "require.resolve('playwright')"
```
执行成功），则从该项目运行脚本。
否则，不要为了评审而向用户的项目添加依赖。将依赖一次性安装到项目外的缓存目录，并从该目录运行脚本：
bash
```
mkdir -p ~/.cache/jury && cd ~/.cache/jury && npm init -y > /dev/null && npm i -D playwright axe-core
```
如果
```
shoot.mjs
```
报告没有 Chromium，请在该目录中一次性运行
```
npx playwright install chromium
```
。

3. Evidence

3. 证据

bash

node $SKILL/scripts/shoot.mjs <url> --crawl --nav --out <abs>/.jury/<host>/shots
node $SKILL/scripts/audit.mjs <url> > <abs>/.jury/<host>/audit.txt

```
shoot.mjs --crawl
```
takes one page of every type (home, each top-level page, one item per collection) plus the 404. For each: desktop at 1440, a phone at 390 throttled to a mid-range device (4x CPU, slow 4G), reduced motion, keyboard focus, rest/hover pairs for pointer targets, idle motion, and page-transition frames. Allow a minute or two per page.
```
audit.mjs
```
exits with code 1 when it finds a FAIL. That is a finding, not a broken run.
For a quick look at one page, drop
```
--crawl
```
and pass
```
--max 10
```
to the audit. Say on the card that it covers one page.
Check the evidence is real before scoring. Open
```
shots/home/d-01-hero.png
```
and
```
shots/summary.json
```
. A bot challenge, a login wall, an error page, or a blank frame with errors in
```
report.json
```
means there is nothing to score: stop and tell the user. A cookie banner is not a reason to stop. Visitors see it too, so it counts.
Crawling is light: at most 40 HTML pages for the audit and 8 page types for screenshots. Don't raise those limits on a site the user doesn't own.

bash

node $SKILL/scripts/shoot.mjs <url> --crawl --nav --out <abs>/.jury/<host>/shots
node $SKILL/scripts/audit.mjs <url> > <abs>/.jury/<host>/audit.txt

```
shoot.mjs --crawl
```
会截取每种页面类型的一个页面（首页、每个顶层页面、每个集合中的一个条目）以及 404 页面。对于每个页面，截取桌面端宽度 1440、手机端宽度 390 并模拟中端设备限速（4x CPU、慢速 4G）、减弱动态效果、键盘焦点、指针目标的静止/悬停状态配对、空闲状态动效和页面转场帧。每页预留一到两分钟。
```
audit.mjs
```
找到 FAIL 时会以代码 1 退出。这是一项检查发现，而不是运行失败。
如果只想快速查看一个页面，请移除
```
--crawl
```
，并向 audit 传入
```
--max 10
```
。在评分卡上说明此次检查仅覆盖一个页面。
评分前先确认证据真实有效。 打开
```
shots/home/d-01-hero.png
```
和
```
shots/summary.json
```
。如果遇到机器人验证、登录墙、错误页面，或者
```
report.json
```
中有错误的空白帧，则没有可评分的内容：立即停止并告知用户。Cookie 横幅不是停止的理由。访客也会看到它，因此它应计入评分。
爬取范围较轻：audit 最多检查 40 个 HTML 页面，截图最多覆盖 8 种页面类型。对于用户并不拥有的网站，不要提高这些限制。

4. Score

4. 评分

With subagents: give a fresh one the critic brief from
```
references/quality-bar.md
```
("Critic brief"), with its three paths filled in (the rubric,
```
.jury/<host>/shots/
```
,
```
.jury/<host>/audit.txt
```
). Give it nothing else, and never
```
calibration.md
```
. It reads every screenshot, so your own context stays small.
Without subagents: score it yourself under the same brief, from the evidence alone, and mark the card as a self-score.
If you built or edited this site in this conversation, a self-score isn't blind. Use a subagent, or say on the card that the score is not independent.

使用 subagent： 给一个全新的 subagent 提供
```
references/quality-bar.md
```
中的评审简报（“Critic brief”），并填写其中三条路径（评分表、
```
.jury/<host>/shots/
```
、
```
.jury/<host>/audit.txt
```
）。不要提供其他任何内容，也绝不能提供
```
calibration.md
```
。它会读取每一张截图，从而让你自己的上下文保持精简。
不使用 subagent： 根据相同简报，仅依据证据自行评分，并在评分卡上标记为自行评分。
如果你在本次对话中构建或编辑过该网站： 自行评分就不属于盲评。请使用 subagent，或在评分卡上说明该评分并非独立完成。

5. Score card

5. 评分卡

Write

.jury/<host>/scorecard.md

and give the same card in chat:

markdown

undefined

编写

.jury/<host>/scorecard.md

，并在聊天中提供相同的评分卡：

markdown

undefined

<site>: jury score

<site>：评审团评分

Estimate, not affiliated with Awwwards. <Independent critic | Self-score>, from <n> pages on <date>.

The idea, as the critic read it: one sentence Critic overall: 6.2 (0.4 Design + 0.3 Usability + 0.2 Creativity + 0.1 Content, on the critic's strict scale) Jury estimate: about 7.3 (critic + 1.1, measured on two recent Sites of the Day) Band, from the estimate: below Honorable Mention (under 6.5) | Honorable Mention range (6.5 to 7.1) | Site of the Day range (7.2 and up)

Criterion	Score	Evidence
Design (40%)		file or report field, and what it shows
Usability (30%)
Creativity (20%)
Content (10%)

Developer	Score	Evidence
Semantics/SEO
Animations/Transitions
Accessibility
WPO
Responsive
Markup/Meta-data

估算结果，与 Awwwards 无关。<独立评审者 | 自行评分>，基于 <date> 的 <n> 个页面。

评审者理解到的创意： 一句话 评审者总分：6.2（0.4 设计 + 0.3 可用性 + 0.2 创意 + 0.1 内容，采用评审者的严格量表） 评审团估算：约 7.3（评审者得分 + 1.1；该偏移量基于最近两个 Site of the Day 案例测得） 依据估算划分的等级： 低于 Honorable Mention（低于 6.5） | Honorable Mention 区间（6.5 至 7.1） | Site of the Day 区间（7.2 及以上）

评判维度	分数	证据
设计（40%）		文件或报告字段，以及它所显示的内容
可用性（30%）
创意（20%）
内容（10%）

开发者维度	分数	证据
语义/SEO
动画/转场
可访问性
WPO
响应式
标记/Meta-data

Fixes, most score first

修复项，按分数提升优先级排序

[Usability] m-03: what is wrong, and what to change
...

[可用性] m-03：存在的问题，以及具体修改方式
...

Measured

实测结果

Mobile LCP and CLS, loader time, FPS, serious axe violations, overflow,

noHoverChange

colorOnly

, idle motion, audit FAIL and WARN counts (from

summary.json

and the audit).

Not scored: anything stills can't show (how motion feels, sound).


Take the offset for the jury estimate from `references/calibration.md` (the 1.1 above is the
offset when this was written) and follow its rules: the critic's own numbers stay as scored, and
the developer areas get no jury estimate.

Then, in chat only:
- If the user told you what the site is meant to say, one line: does the critic's reading
  match? If not, the site isn't saying it, and that is the first Creativity fix.
- The two fixes that would move the overall most.
- An offer: fix the list in this project if it's here, or run `/awwwards` in it for a redesign.

移动端 LCP 和 CLS、加载时间、FPS、严重 axe 违规、溢出、

noHoverChange

、

colorOnly

、空闲状态动效，以及 audit 中的 FAIL 和 WARN 数量（来自

summary.json

和 audit）。

未评分：静态图无法呈现的内容（动效体验、声音）。


评审团估算的偏移量取自 `references/calibration.md`（上文的 1.1 是撰写时的偏移量），并遵循其中的规则：评审者给出的原始分数保持不变，开发者维度不提供评审团估算。

然后，仅在聊天中补充：
- 如果用户说明了网站想表达的内容，用一行回答：评审者的理解是否一致？如果不一致，说明网站没有把意图表达出来，这就是第一项 Creativity 修复。
- 最能提升总分的两个修复项。
- 提供后续帮助：如果项目就在当前目录中，可以修复该清单；也可以运行 `/awwwards` 对其进行重新设计。

Re-scoring after fixes

修复后重新评分

Run steps 3 to 5 again with a new critic, never the earlier one, and never show it the earlier card: it would anchor on the old numbers. Before writing the new card, rename the old one to

scorecard-<n>.md

, then show the change per category.

再次执行步骤 3 至 5，并使用一个全新的评审者，绝不能复用之前的评审者，也绝不能向其展示之前的评分卡，否则新评分会锚定在旧分数上。编写新评分卡前，将旧评分卡重命名为

scorecard-<n>.md

，然后按类别展示变化。

Rules

规则

No evidence, no points. Every score cites a screenshot file or a report field. Start each category at 6 and make the evidence earn every point above it.
Don't argue a score up. Dispute one only by pointing at a screenshot the critic misread.
Judge the site on screen. Don't propose a new concept; fix what's there.
Specific, not cruel: "m-03: the title wraps to five lines at 390 px; drop it to 14vw", never "the typography needs work". Someone made this.

没有证据，就没有分数。每个分数都必须引用截图文件或报告字段。每个类别从 6 分起步，只有证据才能支撑高于 6 分的评分。
不要为了抬高分数而争论。只有在指出评审者误读了某张截图时，才能对分数提出异议。
根据屏幕上的实际呈现判断网站。不要提出全新的概念；应修复当前已有的问题。
具体但不刻薄：“m-03：在 390 px 下标题换成五行；将其改为 14vw”，不要说“排版有问题”。这是有人辛辛苦苦做出来的。