其他
用 Layer 输出评分规则做交付前质量门禁与批次评审
在 Layer 工作区/项目中,用规则评分和 brief 逐项核对生成的图像/资产,决定哪些可交付、哪些重跑或修复。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 35/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 38/100 ×0.15
适用场景
用 Layer 输出评分规则做交付前质量特定
解决思路
- 使用 Layer 的三个质量工具:用 `list_output_scoring_rules` 查看工作区(可选项目)生效的 output scoring rules;用 `score_files` 排队评分;用 `get_file_scores` 读取单个文件上的 verdict。
- 生成机制不在本技能内,去看 `layer` 技能;如果本技能提到的同级技能在你的可用技能中缺失,让用户安装:`npx skills add layerai/skills --skill <name>`;无人值守时则依据工具 schema 继续,并标记这个缺口。
- 在凭肉眼判断任何输出前,先调用 `list_output_scoring_rules`;每条规则都是工作室写下来的标准,交付若违反规则,无论看起来多好都算错。
- 规则可以限定到 project 而不只是 workspace;当工作属于某个项目时,调用时传入 project。
- 当存在规则时,调用 `score_files` 排队评分批次,再用 `get_file_scores` 读回 verdict。
- 记住 `score_files` 是异步的:它只在运行入队后返回,不返回结果;之后轮询 `get_file_scores`;大请求要几分钟。
- 不要把空 `scores` 列表当作 0 分;它表示尚未评判。把排队确认当 verdict,或把空列表当失败分,正是该契约容易诱发的缺陷。
- 评分会计费,且没有估价工具:每个 file 和 rule 的组合都是一次 vision-model 调用,会花费 Creative Units;所有 `estimate_*` 工具都不给评分定价。
- 同一文件再次评分是允许的,且会追加一条新 verdict 而不是替换旧 verdict;因此不要因为第一次调用“没有返回”而重新评分,那是真实双重花费。
- 重新评分前先读 `get_file_scores`;不要重新评分那些 `get_file_scores` 已经保存 verdict 的文件。
- 当没有规则时,明确说明没有规则,而不是暗示输出通过了它从未满足的门禁;然后改为对照 brief 评审。
- 评审问题永远不是“这是否好”,而是“这是否做到了被要求的事”;逐项回溯 brief。
- 检查 stated constraints:aspect ratio、pixel size、transparent background、palette、poly budget、clip length;这些是 pass/fail,且常因图像看起来没问题而被静默漏掉。
- 按 intended use 评审:icon 在目标尺寸下判断,texture 以 3x3 tiled 判断,loop 跨接缝判断,background 带角色判断;脱离资产交付上下文判断会让缺陷进入交付。
- 评审 set,而不是 item;对任何属于一组的内容,把候选并排摆在一起;sibling 之间的 drift 单个看不可见,并排看很明显。
- 从批次挑选时,不要选最抢眼的那个;选最接近 brief 的那个,因为最抢眼通常是因为某个不会在整套其余部分重复的原因而抢眼。
- 当没有候选接近 brief 时,要修的是 prompt,而不是再生成一批。
- 连续两次相同的 reroll 都失败,说明 prompt 欠明确;回到 prompt 没有命名的内容(framing、lighting、background treatment),而不是再用同一字符串花钱。
- 报告时诚实说明交付物的哪里有问题:一次运行产出 3 个可用资产和 1 个手部畸变资产,就按“3 个可用、1 个有问题”报告,不要报成 4 个资产。
- 如果 reference set 被降级/退化,点名它(`layer-reference-sets`)。
- 如果漏掉了某个 constraint,点名该 constraint。
- 记住 Creative Units 无论如何都已花掉;悄悄当作通过会让用户之后在已经建立在缺陷资产上的工作上二次发现。
- 示例流程:对“这 8 个 icon 可以交付了吗?”先对 workspace 和 project 调用 `list_output_scoring_rules`;示例中有两条规则:transparent background 和最低 legibility 标准。
- 示例流程:先对 8 个 `file_id` 值调用 `get_file_scores`,以防之前的会话已经评判过;对没有 scores 的那些,调用 `score_files` 排队运行,并告知用户这会花费 Creative Units,因为没有 estimate 工具给评分定价。
- 示例流程:轮询 `get_file_scores` 直到 scores 出现;空列表表示尚未评判,所以继续轮询而不是重新评分。
- 示例流程:两个未通过 transparency 规则;这不是主观判断,所以让它们回去走 `background_removal`(`layer-image-editing`)。
- 示例流程:把剩余六个在目标尺寸下一起查看,而不是全分辨率,并对照之前已批准的两个 icon 检查 stroke weight 和 palette。
- 示例流程:一个比整套更重,产生 drift;以已批准 icon 为 references 重跑那一个。
- 示例流程:交付时说明状态:六个通过,一个已重跑,两个为 transparency 已修复。
- 常见错误规避:不要不检查 scoring rules 是否存在就凭肉眼判断。
- 常见错误规避:不要在从未有规则生效时报告输出通过了门禁。
- 常见错误规避:不要把 `score_files` 读成返回 verdict;它只确认排队的运行。
- 常见错误规避:不要把空 `scores` 列表读成 0 分,而要读成尚未评判。
- 常见错误规避:不要因为第一次调用“没有返回”就重新评分,这会再次花费并追加第二条 verdict。
- 常见错误规避:不要重新评分那些 `get_file_scores` 已经保存 verdict 的文件。
- 常见错误规避:不要在 icon、texture 或 loop 交付的上下文之外判断它们。
- 常见错误规避:不要一次只看一个 set 成员,否则注意不到 drift。
- 常见错误规避:不要选最抢眼的候选,而要选匹配 brief 的候选。
- 常见错误规避:不要在 prompt 欠明确时第三次 reroll,而要修 prompt。
- 常见错误规避:不要围绕已知缺陷静默交付。
适用边界 · 注意事项
- 没有 Layer 工作区/项目或不能调用 `list_output_scoring_rules`、`score_files`、`get_file_scores` 时,不适用;只能做人工 brief 评审。
- 不愿或不能消耗 Creative Units,且没有评分预算时,不要调用 `score_files` 做评分门禁。
- 如果目标只是主观创意口味挑选,而不是对照 brief 或工作室规则判定可交付性,不适用。