design-review

设计评审

评析 UI 成品，或回答设计决策问题；每项主张都必须附有引用。

步骤 0 - 加载评分标准

在撰写任何评析之前，请先阅读 references/review-rubric.md，除非它已在上下文中。该文件包含 0-4 分的评分档位、当两个档位都适用于同一界面时如何选定一个档位的规则，以及可供引用的 Nielsen 10 项可用性启发式精简表。即使你熟悉这些启发式，也不要跳过这一步——各档位的确切措辞对于确保不同运行中的评分一致非常重要，而平局判定规则可以避免对同一界面的两次评审给出不同分数。

步骤 1 - 选择模式

有两个事实可以决定模式。是否附带了成品——粘贴的屏幕截图、图片、URL，或代码块中的 HTML 片段？消息是否提出了决策问题——在模式、组件或流程之间做出选择（“我应该用 X 还是 Y”“我该如何处理……”）？“评审一下”“这个怎么样”和“这有什么问题”都不是决策问题：它们询问的是成品本身的质量，这正是评审模式要回答的。

按以下顺序选择第一个匹配项：

1. 比较模式：有两个或更多成品，且问题询问哪个更好（“A 还是 B”“这些里面哪个更好”“重新设计后有改善吗”）。
2. 有依据的建议模式：至少有一个成品，且问题是成品本身无法回答的决策问题（“这是我们的结账页面——地址表单应该用模态框还是抽屉？”）。问题决定模式；成品是依据，而非评审对象。
3. 评审模式：有一个成品，没有决策问题。
4. 建议模式：没有成品，有决策问题。

如果有两个或更多成品但没有决策问题，就应分别评审，而不是进行比较——开始前先询问用户想要哪种方式。如果请求既没有成品也没有决策问题，就询问用户想评审什么，而不要自行猜测。

附带成品并不会悄然将问题转变为评析。用完整评审来回答决策问题，和用两份评析来回答比较问题一样，都是错误的：输出形式完整，但用户提出的问题仍未得到解答。

步骤 2 - 评审模式

2a. 处理成品

• 屏幕截图或图片：直接查看。
• URL：如果具备相应能力，则获取并渲染；否则请用户粘贴屏幕截图。
• HTML 片段：按给出的内容阅读标记和内联样式。

2b. 先评分，范围为 0-4 分

列出问题之前先给出一个分数。严格使用以下档位：

• 0/4 - 不可用：违反基本的无障碍、层级或信任原则。需要重做，而非修补。
• 1/4 - 需要大幅返工：违反五项或更多启发式原则，文案泛泛或仍为占位内容，层级扁平且没有明确焦点。
• 2/4 - 需要改进：结构合理，但设计细节不到位——存在字体、间距或对比度问题。
• 3/4 - 扎实，只需具体调整：层级和设计细节大体妥当，还剩 1-3 项润色工作。
• 4/4 - 可直接发布：没有实质性问题，只有细微的偏好差异。

如果设计满足用户明确提出的项目目标，应酌情给出较高评分；如果设计忽视了这些目标，则应从严评分。

大多数界面都符合多个档位。当两个档位都适用时，应根据修复成本决定采用哪个档位——重做、重构、完善设计细节、进行 1-3 项明确修改，还是无需实质性修复；而第 1 档中的违规数量是结构性问题的证据，绝不能单独作为提高界面评分的门槛。结构合理但有五项轻微违规，评分为 2/4；单项违规若阻碍任务完成或低于无障碍底线，也可能单独对应 1/4 或 0/4。统计评审发现的所有问题，而非仅统计最终报告的问题——2c 中的上限只决定输出内容，不影响界面评分。完整规则见 references/review-rubric.md。

2c. 挑选问题，按影响排序——最多 6 个

不要列出你注意到的每个缺陷——详尽列举只会制造噪声，而噪声正是这项技能的一种失败模式。按影响排序，最多列 6 个，即使还存在更多问题也要停下。

6 是上限，不是配额，也没有最低数量。报告所有达到影响门槛的问题，不要列出其他内容；列表有多长，就取决于筛选结果。为了凑够最低数量而给简短列表充数，与列出所有缺陷一样，都是失败，只不过出发点相反：最后的规则部分会说明，每个问题要么值得列入列表，要么不值得，而这决定了列表长度。

6 是推导出来的，不是随意选的。 它等于第 1 档的下限加 1。该档定义为违反 5 条或更多启发式原则，是任一档列出的最大数量，因此上限为 5 就会刚好卡在这个数量上，而列表若恰好在上限处结束，就无法判断它是完整列出了第 1 档的问题，还是被截断了。6 是能完整列出第 1 档下限，同时仍让列表看起来完整的最小上限。超过 6 后，数量本身就是问题，而不是列表：筛选结果为 1/4 或 0/4，需要重组或重做，因此评分段落会直接说明这一点，而不会悄悄多列第 7 个问题。完整推导见 references/review-rubric.md。

空洞的评审仍然不是答案，因此要遵守两个下限：

• 没有问题达到门槛。 这就是 4/4 的含义。改为指出 2-3 个最值得打磨的地方，并将其表述为打磨建议，而非阻碍。
• 在 0-3 的筛选结果中，达到门槛的问题少于 3 个。 在 3/4 时很常见，该档定义为有 1-3 个打磨事项。列出达到门槛的问题，并用一句话说明列表较短是因为筛选结果状况良好——否则，只有两个问题的评审会显得像是提前结束了。

每个问题严格写三行：

• Before：具体、可观察的事实。不要写“布局感觉很杂乱”——要写“12 个 UI 元素挤在一个宽 320px 且没有分组的卡片中”。
• After：一个人能在一小时内完成并交付的修复。不要写“改进层级”——要写“将次要操作移入溢出菜单，只保留主要操作可见”。
• Why：只给出一条依据——按编号和名称注明 Nielsen 启发式原则、按编号注明 WCAG 2.2 成功标准，或注明一项具名的平台指南（Apple Human Interface Guidelines、Material Design）。在依据后用一个短语说明理由，然后停止。不要长篇说教。

2d. 输出格式——评审模式

## <Artifact name, 2-4 words> - score <X>/4

### 1. <Short issue title>
- **Before:** <observable fact>
- **After:** <fix, doable in under an hour>
- **Why:** <citation> - <one-phrase rationale>

### 2. <Short issue title>
- **Before:** <...>
- **After:** <...>
- **Why:** <citation> - <...>

...

**Fix this first:** <one paragraph naming the single most important fix and why it outranks the others>

按你希望的修复顺序为问题编号，影响最大的排在最前。结尾行始终指出优先级最高的一项修复，绝不要用泛泛的总结收尾。

第 3 步——比较模式

有两个或更多产物，问题是哪个更胜一筹。在这里，逐一完整评审每个产物就是失败模式：这样会给出两份评审，却仍然没有答案。

3a. 为每个产物评分

使用第 2b 步中的分档，每个产物给出一个分数。分数是摘要，不是论据——两个变体都可以得 3/4，但仍然有明确的优胜者。无论产物数量多少，每个收到的产物都必须评分：评分不需要表格列，因此随着产物增加，这一步不会变得更难，而 3d 会依赖这一点。

3b. 在共同维度上进行比较

挑选 3-5 个与这些屏幕的用途相关的维度，例如层级、主要操作是否清晰、浏览成本、无障碍性、信息密度。根据每个维度评判所有产物，并确保措辞客观可观察，采用与评审模式中 Before 相同的标准。只适用于某一个产物的观点属于评审意见，而非比较条目，具体放在哪里取决于它针对哪个产物。关于胜出方案的观点留到结尾的“胜出方案中值得修复的问题”列表中。落败变体的观点不会有自己的列表，这是有意为之：对不会发布的屏幕写一份批评，正是这种模式要避免的“有两份批评却没有答案”的失败，只不过方向相反。如果它与结论有关，就已经是论据的一部分，应在指出胜出方案的段落中说明。如果无关，就用一行给出对该变体的完整评审，然后到此为止。

3c. 指出胜出方案

始终选出一个胜出方案，即使差距很小也不例外。以“视情况而定”收尾的比较没有完成任务。说明什么情况会改变结论——也就是用户、目标或约束中的哪一个事实会让你改选。如果坦诚的答案是最强的屏幕取自多个方案，就说明取了哪些部分，以及分别来自哪个变体。

结尾的修复列表最多 3 项，不设最低项数。由步骤 2c 的影响力门槛决定列入哪些内容，因此，如果胜出方案没有任何问题超过该门槛，就给出空列表并说明这一点。2c 中的两项最低要求针对的是评审模式：在该模式中，批评就是全部交付内容，空列表等于没有答案；而在这里，交付内容是结论，列表开始前已经给出了结论。为了凑数而填充列表，正是 2c 所说的失败；在此模式中，它还会削弱结论——凭空编出胜出方案的第三个问题，会让人怀疑这个选择。

上限 3 是推导出来的，而非随意选定的。 3/4 档定义为还剩 1-3 项润色工作，而 2c 的第二项最低要求也已将屏幕本身基本正确、只需进行常规润色的情况归为三个问题。这个列表就是针对团队将要发布的那个产物提出的同一份列表：对于层级和工艺大体到位的屏幕，还有哪些地方需要修复。因此，上限是胜出方案仅剩润色工作时所属档位的上限。这也正是为什么列出 3 项和列出 1 项都算完整——列表长度取决于屏幕，而非模板。

需要修复超过 3 项的胜出方案，说明问题出在结论，而不是需要精简列表。 超过三项意味着胜出方案低于 3/4，剩下的问题属于工艺或结构，而非润色，因此不会悄悄删去第四个问题：指出胜出方案的段落会说明评分还留下哪些工作要做，并列出足以改变结论的事实。列表本身仍以 3 项为上限，并按影响力排序。

3d. 输出格式 - 比较模式

## <A> vs <B> - <A> <X>/4, <B> <Y>/4

| Dimension | <A> | <B> | Edge |
|---|---|---|---|
| <dimension> | <observable fact> | <observable fact> | <who is ahead> |
| <dimension> | <observable fact> | <observable fact> | <who is ahead> |
| <dimension> | <observable fact> | <observable fact> | <who is ahead> |

**Winner: <the artifact that wins>.** <One paragraph naming the dimension that decided it, with exactly one citation - same citation rules as review mode.>

**What would change the call:** <the one fact that would flip the decision>

**Worth fixing in the winner:** <0-3 issues, Before/After/Why, only ones that clear the impact bar from Step 2c - or "Nothing in the winner clears the impact bar.">

<One line offering a full review of the losing variant, or of each losing variant by name, only when it carried points that never reached the verdict. Never a printed critique of a screen that lost.>

上面的区块以两个产物为例，因为两者是最常见的情况，而非因为该模式到此为止。 三个或更多产物只需沿一个方向扩展：标题列出每个产物及其分数，并按它们出现的顺序排列（<A> vs <B> vs <C> - <A> <X>/4, <B> <Y>/4, <C> <Z>/4）；表格则为每个产物各设一列，并将 Edge 保留在最后。其他内容一律不变——一个胜出方案、一个决定性维度、一条引用、一个结尾修复列表，且该列表针对胜出方案。整个表格中，每个产物都始终保留自己的列——绝不要将两个变体合并到一个“二者”单元格中，因为表格的意义就在于让人可以沿着单独一列从上往下浏览。 到达顺序就是用户提供它们的顺序，绝不是评分顺序。 表头和列都按这一顺序排列，因此读者会先按这个顺序看到这些设计稿，而后才会看到任何一行给出论据；按分数排序，就等于把结论放在输入本该出现的位置：3a 说明，分数是摘要，不是论据；而按分数排序的表格读起来就像一份判决，表格中的行不过是在为它点缀。两个输入本身都没有顺序。同一张图片里的多个设计稿——同一帧导出的三个变体——按图片的阅读顺序排列，即从左到右，再从上到下。用户命名的设计稿按名称所示的顺序排列，即 A、B、C；如果名称顺序与位置顺序不一致，以名称为准，因为提问时用的就是名称。只要列顺序来自图片而非用户，就用一行说明列的顺序，让读者可以核对，而不必从分数中推断。

前后对比的两张设计稿，无论得分如何，都要把改版前的放在第一列。“改版是否让它变好了”是在问变化的方向；如果把同两张界面反过来排列，回答的就是旧版是否胜过新版，这是另一个问题，答案也相反。顺序确定了在比较什么与什么；它并不决定谁胜出，胜者仍然由各行所承载的界面决定。

表格最多容纳五个设计稿，这个数量是推导出来的，并非随意设定。Dimension 和 Edge 是固定列，因此 N 个设计稿会让表格宽达 N+2 列；每个设计稿都保留独立列的原因已如上所述：读者会沿列向下阅读。表格如果宽到超出显示区域，就会换行；一旦列发生换行，它就不再是一列。因此上限应设在列扫描失效的临界点，而不是一个整齐的数字——七列，也就是五个设计稿。少于这个数量时，不做任何改变。达到六个或更多时，模式分两个阶段运行，而不是舍弃任何设计稿；3a 使这一点成为可能：先为所有收到的设计稿评分，再用表格评审入围者。

**哪些设计稿进入表格，本身就是输出的一部分，绝不是模板上的权宜之计。**按分数筛选。逐一列出所有已评分但未纳入表格的设计稿，并注明其分数，以及使它落后的一个可观察事实——每项一行，不做前后对比，因为对没人准备发布的界面进行成文批评，正是 3b 要排除的情况。这样读者就能核对入围名单，而不是盲目信任它；这也不与 3a 矛盾：3a 否定的是由一个数字决定胜者，而不是说一个 1/4 的设计稿不能与三个 3/4 的设计稿同台竞争。如果筛选线落在同分组中间，表格就扩展到足以容纳所有同分项，因为不得不多出第六列，比使用此模式并不支持的破同分规则来筛选代价更小——五是决定纳入哪些设计稿的依据，不是迫使输出撒谎以符合的上限。有两种做法仍然不允许：把设计稿既排除在表格之外，又不列入名单，这相当于不展示它，从而擅自决定了部分问题；以及给出一张包含五个设计稿的表格，再单独评审其余设计稿，这正是本模式通过明确列出设计稿而要避免的“给了两份评审，却没有答案”的问题。 Edge 单元格应填写该行中领先的产物名称，而非整体胜出者。 通常只填一个名称。在三方对比表中，若填写两个名称，表示这两者旗鼓相当，且都领先于第三者；这是关于该行的发现，而不是拒绝作出判断。没有任何一方领先时，标记为 Tie。只有当旗鼓相当本身就是论据的一部分时，才应单独列出这一行——例如，三个变体都未达到同一对比门槛，这是一个适用于三者的事实，具体作用应由结论段落说明。如果某一行打平且没有决定任何事情，说明根据 3b 选错了维度：换成能区分它们的维度，而不是打印一行读者看不出任何信息的内容。绝不要为了让列整齐而打破平局。为了填满单元格而凭空捏造差异，就是 2c 所说的填充问题；它出现在构成结论的行中，而这恰恰是之后无法再把它排除在外的地方。

Step 4 - 建议模式

没有产物，只有一个决策问题。完全跳过 Before/After/Why 结构。

• 用一个句子给出一条直接建议。
• 接着列出支撑建议的论断，每条论断配一条引文，引用规则与评审模式相同。五条是上限，不是配额，就像 Step 2c 中的六条一样：只列出确有依据的论断，然后就此打住。第六条论断应像第七个问题一样删去；为了凑数而添加论断，就是 2c 所说的填充问题，而它出现在代价最高的模式中——建议本身就是全部交付内容，凭空捏造支撑理由会让人质疑答案。
• 至少要有一条论断，这是该技能的核心要求：建议本身就是一条论断，而这项技能不会在没有引文支撑答案的情况下作答。如果没有任何论断站得住脚，就说明无法根据现有信息回答这个问题。此时，应该输出下方的澄清问题，而不是给出毫无依据的建议。
• 如果问题过于开放，以至于任何合理的回答都需要更多背景信息（没有列出选项，也没有关于用户或约束的信息），就提出一个有针对性的澄清问题，而不是猜测。列出 2-3 种可能的理解，让用户直接选择。

5 是推导得出的，而非人为选定的，它源自 Step 5 对 band 1 的最低要求。这里的一条论断是一个带引文的陈述，与 band 1 统计「五条或更多启发式规则违规」时采用的计数单位相同，因此评分标准要求任何单次输出最多支撑五条此类论断。Step 5 体现了这一点：这些论断依据对所附产物的可观察事实，遵循与评审模式中 Before 相同的标准；并且明确指出，附上产物会提高证据门槛，但不会改变这一范围的上下限。因此，上限是两个模式共用的一个数字，由能够观察到内容的模式所设定；这也解释了为什么建议模式不会因为没有产物可供查看而设定更低的上限。剩下的问题是，为什么这个上限落在 band 1 的最低要求上，而 Step 2c 的上限却比最低要求高一条；答案在于评分。2c 的列表会与它所支撑的分数并列展示，因此，五条列表在达到上限时，无法说明它是完整的 band 1 列表，还是更长列表被截断后的结果。两种建议模式都不输出分数，其中没有任何内容是需要这些条目来佐证的计数，因此，额外增加一条所要解决的歧义并不存在——所以上限就落在最低要求本身。两个上限相差一条，是因为两种模式是否包含分数有所不同，并非偶然。各 band 见 references/review-rubric.md。

输出格式 - 建议模式

**Recommendation:** <one-sentence direct answer>

- <Claim 1>. Why: <citation> - <one-phrase rationale>.
- <Claim 2>. Why: <citation> - <one-phrase rationale>.
- <Claim 3>. Why: <citation> - <one-phrase rationale>.

If you want specifics, share a screenshot or a URL and I'll do a full review.

第 5 步 - 有依据的建议模式

附带设计稿的决策问题。答案仍保持建议的形式；设计稿提高了证据门槛，但不会改变问题本身。

• 先用一句话回答问题。如有批评意见，放在后面。
• 声明数量沿用第 4 步：最多五条，有多少条有依据就给多少条，绝不凑数。附带设计稿会提高证据门槛，但不会改变数量范围的上下限——这句话至关重要，因为第 4 步推导出五条的依据正是这种模式：它限定的单位，是基于观察到的事实并附有引用的声明，而这正是此模式提出的声明。
• 设计稿能够证实的每条声明，都必须依据其中可观察到的事实，标准与评审模式中的 Before 相同：例如“地址表单有九个字段，页面上已经有一个固定的订单摘要”，而不是“表单看起来很长”。设计稿无法证实的声明——如流量、设备组合、用户接下来会做什么——仍可作为一般性建议提出，但要说明它们属于此类，不要把它们说成观察结果。
• 指出支撑建议的那一项可观察事实。如果设计稿使你的答案与没有设计稿时的答案不同，请直截了当地说明：这正是附带设计稿的全部价值。
• 如果设计稿没有展示问题所涉及的元素，请用一句话说明，然后基于一般性建议作答。绝不要根据周边布局推断缺失的元素。
• 最后列出最多 3 条评审模式下的问题，且仅限与决策相关的问题。这里的“3”就是 3c 中的“3”，其推导也同样适用：在两种模式下，批评意见都从属于其他交付内容；当屏幕整体已无问题、只需润色时，两种模式的问题列表都会到此为止。其他内容留待完整评审——请在结尾处提出可进行完整评审，而不要把未受要求的批评夹带在答案中。

输出格式 - 有依据的建议模式

**Recommendation:** <one-sentence direct answer to the question that was asked>

- <Claim 1, resting on an observable fact from the artifact>. Why: <citation> - <one-phrase rationale>.
- <Claim 2>. Why: <citation> - <one-phrase rationale>.
- <Claim 3>. Why: <citation> - <one-phrase rationale>.

**What in the artifact decided it:** <the single observable fact that carried the recommendation>

**Also worth fixing:** <0-3 issues in Before/After/Why, only ones that bear on this decision - or "Nothing that bears on this decision. Ask for a full review if you want the rest.">

边界情况

情况	应采取的做法
截图模糊或分辨率过低，无法看清文字或间距	直接说明这一点，并请对方提供更高分辨率的图片或 URL。不要猜测模糊元素上写了什么。
URL 无法访问（有身份验证墙、404、需要登录）	说明无法打开该 URL，并请对方改为提供截图或 HTML 导出文件。
作品已经很出色（得分会是 4/4）	没有任何问题达到影响门槛，因此指出 2-3 项最值得打磨的地方，并将其表述为锦上添花，而非阻碍。绝不要返回空白的评审意见。
只有一两个问题达到影响门槛（得分为 3/4，且只有一项打磨建议）	列出这些问题后就停止，并用一句话说明列表较短是因为界面整体状况良好。绝不要为了凑数而添加内容——没有最低数量要求，杜撰第三个问题正是失败案例 2c 要防止的。
未说明项目目标	仅依据 references/review-rubric.md 中的一般启发式和指南进行评审。不要臆造目标或目标受众。
咨询问题过于含糊（“哪个更好？”但没有说明选项）	提出一个澄清问题，并列出 2-3 个可能的选项，而不是猜测用户指的是哪一个。
支持咨询建议的主张中，只有一两个有实际依据	列出这些主张后就停止。五条是上限，没有高于一条的下限，因此简短回答也完整。为凑数而杜撰主张，会破坏建议赖以成立的引用门槛。
咨询问题中，没有任何主张经得起核实	不要给出建议。达不到引用门槛的回答等同于没有回答，因此改为提出第 4 步中的澄清问题，并列出 2-3 种会得出不同答案的解读。
一张截图中有多个不同界面，且未要求比较	询问要评审哪一个，或表示可以按需分别评审。如果是同一界面的两个变体，并附有“哪个更好？”之类的问题，则属于比较模式——不要让用户替你挑选一个。
比较中的胜出方案没有任何超过影响门槛的问题（两个方案都很出色，胜出方案为 4/4）	指出胜出方案，并说明结尾的修复清单为空。第 2c 条中的 4/4 下限适用于评审模式；在该模式下，空白评审意见根本不算交付内容。比较模式已经给出了结论，因此为了凑数而添加 2-3 项打磨建议只会削弱结论。
比较中的一个作品无法读清或无法访问	不要进行比较。指出哪个作品出了问题，并请对方重新提供——一半证据都靠猜的比较，还不如不比较。
比较中的作品是不同界面，而非同一界面的变体（例如我们的定价页面与竞争对手的定价页面）	仍按比较模式处理，但比较维度必须围绕两个界面共同承担的任务，而不是只适用于其中一个界面的功能。用一句话说明这一点，然后再给出表格。
一次比较中提供了 3-5 个作品	照常使用比较模式。表头列出每个作品及其得分，表格每个作品占一列，并将 Edge 放在最后，且仍需明确指出一个胜出方案。绝不要拆成两个方案的比较，再把剩下的一个单独评审——没有放进表格的变体，恰恰是用户正在考虑取舍的对象。
一次比较中提供了 6 个或更多作品	按照 3a 为所有作品评分，然后对入围作品制作表格，并列出每个未入围作品的得分及其落后的一个事实。表格最多容纳五列，因为更宽的表格会换行，而列换行会破坏每个作品各占一列的初衷。既不放入表格、也不在列表中提及某个作品，和为了套用模板而删掉一个变体一样，都是错误的。
一张图片中包含多个作品（例如从一个画面导出的三个变体）	使用比较模式，图片中的阅读顺序即提交顺序：从左到右，再从上到下。用一句话说明各列的排列顺序，因为用户没有指定。绝不要按得分排列各列——否则表头会在本应对应输入内容的位置提前公布结论。
提供了一组改版前后对比图（“重新设计后有改进吗？”）	使用比较模式，将改版前的作品放在第一列，无论其得分如何。如果将顺序反过来，回答的就会变成旧界面是否胜过新界面，和用户的问题正好相反。
两个作品在某个维度上持平，而第三个落后	Edge 单元格中应同时写出两个持平的作品，表示它们彼此平手，且都胜过第三个。只有当某一行中没有任何作品领先时，才使用 Tie。如果这一行打成平手且无法得出结论，就说明该维度不适合用来区分它们。绝不要为了填满单元格而臆造差距——结论必须有表格中的各行作为依据。
用户附上了作品，并提出决策问题（“这是界面——用模态框还是抽屉？”）	使用基于证据的咨询模式（第 5 步）。先回答问题，并以作品作为依据。用户没有要求完整评审；无论评审写得多完整，都不能代替对问题本身的回答。
决策问题涉及的对象在所附作品中不可见（询问空状态，却提供了填充后的界面）	用一句话说明作品中没有展示该对象，然后依据一般指南作答，并照常注明依据。不要从周围布局推断缺失元素。
附上作品并问“这个怎么样？”或“这有什么问题？”	使用评审模式。这类问题询问的是作品本身的质量，而不是在不同选项间做选择，因此不属于决策问题。

适用于所有模式的规则

• 每个问题或主张只引用一条来源。不要在同一行堆叠两条引用，也不要在未注明具体启发式编号、WCAG 成功标准或平台指南的情况下引用。
• 每条 After（评审模式）、每项判定（比较模式）或每项主张（建议模式和基于依据的建议模式），都必须具体到开发者或设计师无需追问即可着手处理。
• 绝不编造来源、研究或统计数据。如果不确定某项主张是否有依据，就删掉它。
• 保持直接、客观的语气。不要使用“这可能会是个问题”之类含糊措辞——要么这是值得列出的问题，要么就不是。