layer-quality

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Layer Quality Review

Layer 质量评审

Overview

概述

Generation is not delivery. A batch comes back, and something has to decide which of it is usable, against the brief and against whatever standards the studio has already set. Layer records those standards as output scoring rules, and exposes three tools:

Tool	Purpose
`list_output_scoring_rules`	The rules in force for a workspace, optionally a project
`score_files`	Queue a scoring run. Asynchronous and billed
`get_file_scores`	Read the verdicts recorded on one file

Generation mechanics are in the

layer

skill. If a sibling skill named here is missing from your available skills, ask the user to install it (

npx skills add layerai/skills --skill <name>

); unattended, proceed from tool schemas and flag the gap.

生成并不等于交付。一批文件生成完成后，需要有某种机制根据需求简报以及工作室已经设定的标准，判断其中哪些可以使用。Layer 将这些标准记录为输出评分规则，并提供三个工具：

工具	用途
`list_output_scoring_rules`	当前工作区适用的规则，可选择指定项目
`score_files`	将一次评分任务加入队列。异步执行并计费
`get_file_scores`	读取一个文件上已记录的评审结论

生成机制位于

layer

skill 中。如果可用 skill 列表中缺少这里提到的同级 skill，请要求用户安装（

npx skills add layerai/skills --skill <name>

）；在无人值守的情况下，则根据工具 schema 继续执行，并指出这一缺失。

Check for rules before inventing standards

在自行制定标准前检查规则

Call

list_output_scoring_rules

before judging anything by eye. Each rule is a standard the studio has written down, and a delivery that contradicts one is wrong however good it looks. Rules can be scoped to a project as well as a workspace, so pass the project when the work belongs to one.

When rules exist,

score_files

queues the batch and

get_file_scores

reads the verdicts back.

Three things about that contract are easy to get wrong and expensive to get wrong:

score_files
is asynchronous. It returns as soon as the run is queued, not with results. Poll
```
get_file_scores
```
afterwards; a large request takes a few minutes.
An empty
scores
list means not judged yet, not a zero. Treating the queue acknowledgement as a verdict, or an empty list as a failing score, is the defect this contract invites.
It is billed, and there is no estimate tool for it. Every file and rule pair is a vision-model call that spends Creative Units, and none of the
```
estimate_*
```
tools price it. Scoring the same file again is allowed and appends a fresh verdict rather than replacing the old one, so a re-score because the first call "returned nothing" is a real double spend. Read
```
get_file_scores
```
first.

When no rules exist, say so rather than implying the output passed a gate it never met, then review against the brief.

在凭肉眼评判任何内容之前，先调用

list_output_scoring_rules

。每条规则都是工作室已经明确记录的标准；无论交付物看起来多么出色，只要与某条规则相矛盾，就是错误的。规则既可以限定在工作区范围内，也可以进一步限定到项目，因此当工作属于某个项目时，请传入该项目。

存在规则时，使用

score_files

为批次加入评分队列，再通过

get_file_scores

读取评审结论。

这个调用约定有三个容易理解错误、且一旦理解错误代价高昂的点：

score_files
是异步的。它会在任务进入队列后立即返回，而不是返回结果。随后轮询
```
get_file_scores
```
；大型请求可能需要几分钟。
空的
scores
列表表示尚未评审，而不是零分。把队列确认消息当成评审结论，或把空列表当成不及格分数，正是此调用约定容易引发的缺陷。
它会计费，而且没有对应的预估工具。 每个文件与规则的组合都会触发一次 vision-model 调用并消耗 Creative Units，而所有
```
estimate_*
```
工具都不会为它计价。可以对同一文件重新评分；这会追加一条新结论，而不是替换旧结论。因此，若因首次调用“未返回内容”而重新评分，就会造成真正的重复花费。请先读取
```
get_file_scores
```
。

没有规则时，应明确说明这一点，而不是暗示输出通过了一个实际上并不存在的质量门禁；随后再根据需求简报进行评审。

Review against the brief, not against taste

根据需求简报评审，而不是凭个人审美

The question is never "is this good". It is "does this do what was asked". Work back through the brief item by item:

The stated constraints: aspect ratio, pixel size, transparent background, palette, poly budget, clip length. These are pass or fail, and they are the ones most often silently missed because the image looks fine.
The intended use: an icon judged at its target size, a texture judged tiled at 3x3, a loop judged across its seam, a background judged with a character on it. Judging an asset out of its context is how defects reach delivery.
The set, not the item. For anything that belongs to a group, lay the candidates out together. Drift between siblings is invisible one at a time and obvious side by side.

问题从来不是“这个好不好”，而是“它是否完成了所要求的内容”。逐项回溯需求简报：

明确列出的约束条件：宽高比、像素尺寸、透明背景、调色板、多边形预算、clip 时长。这些条件只有通过或不通过之分；也正因为图像看起来没问题，它们往往最容易在不知不觉中被遗漏。
预期用途：在目标尺寸下评审图标，以 3x3 平铺方式评审纹理，跨越接缝评审循环动画，将背景与角色叠加后评审。脱离最终使用情境来评判资产，正是缺陷流入交付环节的原因。
整组资产，而不是单个资产。对于属于同一组的任何内容，应将候选文件并排呈现。逐个查看时，同组成员之间的漂移并不明显，放在一起对比则一目了然。

Choosing from a batch

从批次中选择

batch_size

returns variations, and the temptation is to pick the most striking one. Pick the one closest to the brief instead, because the striking one is usually striking for a reason that will not repeat across the rest of the set.

When no candidate is close, the fix is the prompt, not another batch. Two identical rerolls in a row mean the prompt is underspecified: go back to what the prompt failed to name (framing, lighting, background treatment) rather than spending again on the same string.

batch_size

会返回多个变体，而人们很容易倾向于选择最醒目的那个。应选择最符合需求简报的那个，因为最醒目的版本通常之所以醒目，往往源于某个无法稳定复现于该组其余版本的因素。

如果没有任何候选版本足够接近，解决方案是修改 prompt，而不是再生成一批。连续两次使用完全相同的 prompt 重新生成，说明 prompt 描述不足：应回头检查其中未能明确说明的部分（构图、光照、背景处理），而不是再次花费成本重复使用同一字符串。

Report honestly

如实报告

Say what is wrong with what you deliver. A run that produced three usable assets and one with a mangled hand is reported as exactly that, not as four assets. Where a reference set was degraded, name it (

layer-reference-sets

). Where a constraint was missed, name the constraint.

Creative Units were spent either way, so a quiet pass costs the user a second discovery later, on work already built on the flawed asset.

明确说明交付内容存在的问题。如果一次运行生成了三个可用资产和一个手部畸形的资产，就应如实报告为三个可用、一个有问题，而不能笼统称为四个资产。若参考集质量下降，应明确指出（

layer-reference-sets

）；若遗漏了某项约束，应明确指出该约束。

无论是否指出问题，Creative Units 都已经消耗。因此，隐瞒缺陷只会让用户在之后发现问题时再次付出成本，而此时后续工作已经建立在有缺陷的资产之上。

Worked example

示例

"Are these eight icons ready to ship?"

```
list_output_scoring_rules
```
for the workspace and the project. Two rules exist: transparent background, and a minimum legibility standard.
```
get_file_scores
```
on the eight
```
file_id
```
values first, in case an earlier session already judged them. For the ones with no scores,
```
score_files
```
to queue a run, telling the user it spends Creative Units since no estimate tool prices scoring.
Poll
```
get_file_scores
```
until scores appear. An empty list means not yet judged, so keep polling rather than re-scoring.
Two fail the transparency rule. Those are not judgement calls, so they go back through
```
background_removal
```
(
```
layer-image-editing
```
).
View the remaining six together at their target size, not at full resolution, and check stroke weight and palette against the two icons approved earlier.
One has drifted heavier than the set. Reroll that one against the approved icons as references.
Deliver with the state named: six passing, one rerolled, two fixed for transparency.

“这八个图标可以交付了吗？”

为工作区和项目调用
```
list_output_scoring_rules
```
。存在两条规则：透明背景和最低可读性标准。
首先对这八个
```
file_id
```
调用
```
get_file_scores
```
，以防之前的会话已经评审过它们。对于没有评分的文件，调用
```
score_files
```
将评分任务加入队列，并告知用户：由于没有预估工具能够为评分定价，此操作会消耗 Creative Units。
轮询
```
get_file_scores
```
直到出现评分。空列表表示尚未评审，因此应继续轮询，而不是重新评分。
有两个未通过透明背景规则。这些不是需要主观判断的情况，因此应通过
```
background_removal
```
（
```
layer-image-editing
```
）重新处理。
将其余六个放在目标尺寸下一起查看，而不是以全尺寸查看；并根据此前批准的两个图标检查笔画粗细和调色板是否一致。
其中一个的笔画比整组明显更重。将此前批准的图标作为参考，重新生成该图标。
交付时明确说明状态：六个通过、一个重新生成、两个已修复透明背景问题。

Common mistakes

常见错误

Judging by eye without checking whether scoring rules exist.
Reporting output as passing a gate when no rules were ever in force.
Reading
```
score_files
```
as if it returned verdicts, when it only acknowledges the queued run.
Reading an empty
```
scores
```
list as a zero rather than as not yet judged.
Re-scoring because the first call "returned nothing", which spends again and appends a second verdict.
Re-scoring files whose verdicts
```
get_file_scores
```
already holds.
Judging an icon, texture, or loop outside the context it ships in.
Reviewing set members one at a time, so drift goes unnoticed.
Picking the most striking candidate rather than the one matching the brief.
Rerolling an underspecified prompt a third time instead of fixing it.
Delivering silently around a known defect.

未检查是否存在评分规则，就凭肉眼进行评判。
在从未生效过任何规则的情况下，仍将输出报告为已通过质量门禁。
把
```
score_files
```
当作会返回评审结论来读取，但它实际上只确认评分任务已进入队列。
把空的
```
scores
```
列表理解为零分，而不是尚未评审。
因为首次调用“未返回内容”就重新评分，从而再次花费并追加第二条评审结论。
对
```
get_file_scores
```
中已有评审结论的文件重新评分。
脱离最终使用情境来评审图标、纹理或循环动画。
逐个评审组内成员，导致偏差未被察觉。
选择最醒目的候选，而不是最符合需求简报的候选。
对描述不充分的 prompt 进行第三次重新生成，而不是先修正它。
已知存在缺陷，却在不说明的情况下交付。