slop-eval

Slop 评估

像 skill-evaluation 评估技能那样评估设计：每项发现都引用具体证据，每个维度都给出 0–100 分，通过脚本完成计算，最终输出结构化报告——绝不凭感觉评判。

提示特征目录位于 references/tells.md；开始检查前请先阅读。 正向评分标准（标志性公式、协调性检查、从 slop 到高级质感的对照，以及“Adding Soul”指南）位于 references/premium-markers.md；为维度 7–8 评分及撰写修复建议前请先阅读。 设计上下文指南位于 references/contexts.md；请阅读并据此调整评估优先级和容忍度。

来源

• pols.dev 的反 slop 设计法则 —— 提示特征目录、绝对规则和标志性公式均由此提炼而来。
• 方法借鉴自 skill-evaluation （有据可查，否则删除、加权维度、脚本评分、失效模式诊断）。

参数

参数	说明	默认值
target	评估对象：在线 URL、截图、代码路径或 Figma 导出文件	询问用户
brief	品牌简介或用户明确给出的设计要求	无
context	设计类型：landing、saas、editorial、ecommerce 或 auto	auto
output	报告写入路径	./SLOP-REPORT.md
compare	用于跟踪模式（纵向演变）的先前报告路径	无

使用用户所说的语言撰写报告；提示特征 ID 和名称保留英文，以便在目录中搜索。

评估模式

标准模式（默认）

对单个设计进行评估。生成 Slop 报告，包含评分、提示特征、版块清单和按优先级排列的修复建议。

对比模式

并排评估两个不同的设计（例如竞品分析、A/B 版本）。添加 --compare，指定另一个评估对象或现有报告。

跟踪模式

随时间评估同一设计，以衡量改进情况。适用于：

• 开展每周或每个冲刺周期的设计评审
• 衡量重新设计后的进展
• 验证修复是否确实提升了评分

用法：

# First evaluation — establishes baseline
slop-eval --target https://site.com --output ./reports/baseline.md

# Later evaluation — tracks evolution
slop-eval --target https://site.com --output ./reports/week-2.md \
  --compare ./reports/baseline.md

跟踪模式会在报告中添加：

• 带趋势的评分变化表（✅ 有所改进 / ⚠️ 出现退步）
• 已解决的提示特征（修复内容）
• 新增的提示特征
• 回退项（评分或版块表现变差的部分）
• 版块清单变化
• 速度指标（每周解决的提示特征数量、评分提升率）
• 下一轮迭代建议

完整的跟踪输出格式请参阅 references/output-template.md。

证据渠道

根据收到的材料，可验证的内容也有所不同。切勿为无法观察的检查项评分——应标记为 无法验证，并将其排除（如同 skill-evaluation 中的 N/A）。

渠道	可验证	无法验证
代码（CSS/JSX/HTML）	字体、十六进制颜色值、渐变、阴影、圆角、opacity:0 门控、图标导入、布局骨架	视觉居中、渲染后的对比度、接缝、控件是否响应
截图	所有视觉元素：配色、字体、布局、对齐、居中、裁切、对比度、接缝	悬停或滚动动画、失效控件、不可见内容陷阱、响应式行为
在线 URL（浏览并截图）	以上所有内容，以及交互、动画、首屏内容归属	仅限尚未实际测试的内容

检查代码时，先用 grep 搜索，再仔细查看：fonts.googleapis|next/font、 lucide-react、linear-gradient、box-shadow、border-radius: *9999、 backdrop-filter、opacity: *0、initial={{ *opacity: *0、 overflow: *hidden、clip-path、position: *fixed。每处命中只是线索， 不是结论——记录之前，请对照目录条目确认。

证据采集标准操作流程

根据 target 的类型选择路径；最后始终列出证据清单 （采集了什么、哪些内容无法验证）——这会作为报告的页眉内容。

在线 URL——信息最丰富的渠道；只要可以访问，就优先使用。 使用本次会话可用的任意浏览器自动化工具（浏览器 MCP，例如 Playwright 或 Chrome DevTools；若无 MCP，则使用 npx playwright screenshot） 并将每份材料都保存到临时工作区，以便发现项可以引用 文件 + 区域：

1. 在桌面端（1440×900）和移动端（390×844）加载页面；等待网络空闲。
2. 加载后立即对两个视口进行整页截图，必须在任何滚动之前——此处如果某些区块的 opacity:0 正等待滚动触发展示，它们会显示为空白（M1 证据）。
3. 从上到下滚动一遍，然后再进行一次整页截图；对比两次截图，检查由滚动触发的内容、接缝（C11、X13）以及首屏归属（L16）。
4. 交互检查：悬停主 CTA、一张卡片、一个导航链接（M2–M4）；点击每个标签页、折叠面板、开关和按钮（M8）；按 Tab 键遍历页面，确认焦点环可见（X14）。
5. 将以下内容放大 2 倍截图：靠近裁切边缘的内容（X2）、带圆圈或平铺排列的数字和图标（X1）、并排的定价列（X3）、按钮标签（X5）。
6. 获取代码渠道 grep 所需的渲染后源码：从网络面板或 <link>/@font-face 中提取字体名称，从样式表中提取计算后的十六进制颜色值。

没有可用的浏览器自动化工具 → 获取 HTML/CSS（curl）并对其运行代码渠道检查，要求用户提供桌面端和移动端的整页截图；在收到截图前，将所有纯视觉检查和交互检查标记为无法验证。切勿根据原始 HTML 对视觉检查评分。

截图——逐张查看图片。如果提供的只有局部裁切图，在开始全面检查前要求提供桌面端和移动端的整页截图（仅有首屏截图无法支撑 L11、L15 或整体协调度轴的评估）。所有交互检查（M1、M8、X14、悬停反馈）均无法验证。

代码路径——运行 grep 检查，阅读所有匹配到的文件，以及布局／页面组件和全局样式。如果项目可以在本地运行，启动开发服务器，并按照在线 URL 标准操作——只有代码与实时渲染相结合，才能验证所有内容。

Figma 导出——视觉表现检查按截图处理；此外，文件中的字体、十六进制颜色值和间距均为精确值。动态效果和交互轴无法验证（除非提供了原型，否则轴 5 评分为 NA）。

维度与权重

#	维度	权重	评分依据
1	色彩与光线	2x	特征 C1–C15
2	排版与文案	2x	特征 T1–T10、W1–W3
3	组件与装饰	1x	特征 K1–K27
4	布局与构图	2x	特征 L1–L21
5	动态效果与交互	1x	特征 M1–M8
6	执行与工艺	2x	特征 X1–X14
7	标志性与独特性	3x	7 要素公式（正向评分标准）
8	整体协调度	2x	4 项检查（正向评分标准）

第 7 维的权重最高，这是刻意安排的：这套准则最根本的规则是，回避特征清单本身也是粗制滥造——一个没有任何特征、也没有标志性的页面，就是把克制当借口的未完成作品。

评分

轴 1–6（按特征计数）。 按严重程度统计该轴上已确认的特征，然后：score = max(0, 100 − 30·critical − 15·major − 5·minor)。运行 scripts/score.py axis CRIT MAJOR MINOR — 不要手动计算。一个特征，只计一次：即使某种模式在多个部分重复出现，也仍只算一个特征（在证据中注明重复情况；若目录中有说明，重复可能使严重程度从 minor 升级为 major）。

轴 7（标志性特征）。 根据 premium-markers.md 中的评分标准，为 7 个公式要素分别评分：0（缺失）、50（尝试过但较弱）或 100（突出）；该轴得分为这些分数的平均值。

轴 8（协调性）。 对 4 项协调性检查采用相同的 0/50/100 评分；得分取平均值。

叠加规则。 单页上有 3 个或更多 major 版式特征时，轴 4 最高记 40 — 由已知框架拼装而成的页面，无论每个区块有多整洁，都是粗制滥造。

门槛（作为 --cap 传给总体评分）：

• 标志性特征门槛： 轴 7 < 40 时，总体评分最高为 59（最高等级为 C）。间距再整洁，也无法挽救缺乏标志性特征的页面。
• 绝对规则门槛： 任意已确认的 critical 特征都会将总体评分封顶为 69（执行不合格，无法获得 A 级）。

总体评分与粗制滥造指数。

overall    = sum(axis_score × weight) / sum(weight)   # capped by gates
Slop Index = 100 − overall

运行 scripts/score.py overall 1:80:2 2:65:2 ... [--cap 59] [--cap 69]。 无法验证的轴记为 NA，不计入两项总和。--fail-below N 会在 CI 门槛检查中以非零状态退出，例如，根据 PR 的预览部署结果设置门槛：

# .github/workflows/slop-gate.yml (step excerpt)
- name: Slop gate
  run: |
    # run slop-eval against $PREVIEW_URL, export each axis score, then:
    python3 skills/slop-eval/scripts/score.py overall \
      1:$A1:2 2:$A2:2 3:$A3:1 4:$A4:2 5:$A5:1 6:$A6:2 7:$A7:3 8:$A8:2 \
      --fail-below 40

等级标准

等级	总体评分	粗制滥造指数	评语
A	80–100	0–20	臻品 — 精心设计、风格鲜明、执行到位
B	60–79	21–40	深思熟虑 — 大体经过刻意设计，但仍有一些默认做法
C	40–59	41–60	普通 — 整洁，但套用模板或缺乏风格
D	20–39	61–80	粗制滥造 — 由预设拼装而成
F	0–19	81–100	纯属粗制滥造

绝对规则检查

六项执行规则，每项标记为通过/失败/无法验证，并在单独的表格中报告。任何一项失败都是 critical 特征（计入对应轴，并触发绝对规则门槛）：

1. 默认显示内容 — 不得将内容设为仅在入场动画后显示 （opacity:0 + reveal）（M1）
2. 避免裁切 — 不得有文字/控件被裁剪、凹口、溢出或固定高度截断（X2、X11）
3. 对齐一致 — 可比较的列共享基线；按钮位置固定（X3）
4. 真正居中 — 所有需要居中的元素都应在数学上和视觉上居中（X1）
5. 对比度清晰 — 所有文字与背景之间都有足够的实际色差（X5）
6. 控件可用 — 所有看起来可交互的控件都有响应（M8）

工作流

1. 收集证据 — 按照上述证据采集 SOP 检查 target。证据清单说明已采集的内容以及无法验证的内容后，即为完成。
2. 阅读 references/tells.md — 扫描时对照的目录。
3. 扫描轴 1–6 — 按组逐一检查目录。有据才记： 只有具备具体证据（十六进制值、字体名称、file:line 或截图区域）才能记录某项特征；没有证据，就不记录。根据对应的优质做法说明逐一核查候选项 — 精心设计的模式不是问题特征。所有目录分组均已扫描，且每项记录的特征都有引用后，即为完成。
4. 执行绝对规则检查 — 六项规则均标记为通过/失败/无法验证，并提供证据。
5. 为轴 7–8 评分 — 阅读 references/premium-markers.md，为 7 个标志性特征要素和 4 项协调性检查评分，并分别给出一句说明。全部 11 项都有分数和说明后，即为完成。
6. 计算 — 对每个按特征计数的轴运行 score.py axis，然后使用权重和任何已触发的 --cap 运行 score.py overall。切勿手动计算。
7. 撰写报告 — 阅读 references/output-template.md，并严格按该结构输出到 output，最后列出 3–5 项优先修复项，按对评分的影响从大到小排列（缺少标志性特征通常比任何单个特征更值得优先处理）。

易错点

• 设计简报优先于规则。 如果用户或品牌明确指定了某项选择（颜色、布局、效果），它就不算问题——规则本身规定，用户的要求具有 100% 的优先权。若设计明显遵循了简报，请索取简报；在报告中添加带有适当理由标签的排除项（见下文“排除系统”）。
• 上下文会改变问题的性质。 在真实数据上使用单色是正确的；内容充实、看起来真实的产品窗口是鲜明特色，而非虚假窗口问题；带纹理的紧密微网格显得高级，整页方格纸则显得粗糙。记录前务必核对高级设计组合项。
• 不要因为没犯错就给予奖励。 没有问题但特色薄弱，是那些试图避免粗糙感的设计最常见的失败。特色门槛正是为此而设——务必严格执行。
• 严格把控严重程度。 严重级别仅用于损坏的情况（六条绝对规则）。蓝紫渐变很醒目，但并未损坏：应评为主要级别。
• 单轴归类。 有些问题可能属于两个轴（截断的光晕同时涉及颜色和执行）。目录将每个问题严格归入一个轴——只在该轴计数。
• 作品集问题。 L19（重复使用自己的固定风格）需要同一作者的过往作品作为依据；没有依据时，应标记为无法验证，而不是猜测。

排除系统

每个排除的问题都必须附有理由标签。没有标签的问题照常计入——没有例外。这样可以留下审计记录，并避免随意排除。

理由标签

标签	使用时机	示例
// BRIEF:	客户／利益相关方明确指定了此项选择	// BRIEF: client requested blue-purple gradient as brand identity
// DESIGN DECISION:	有记录在案且理由具体的设计决策	// DESIGN DECISION: countdown is real — sale ends 2026-08-01
// CONTEXT:	设计上下文使此模式可以接受	// CONTEXT: mono typeface is appropriate for code snippets in SaaS docs
// PREMIUM PAIR:	这是精心制作的版本，而非粗糙版本	// PREMIUM PAIR: glass effect has proper refraction, edge dispersion, tuned shadows

有效与无效的排除

有效排除：

| C1 | Blue→purple gradient | `// BRIEF: brand guidelines v2.3 specify #6366f1→#8b5cf6` |
| K14 | Countdown timer | `// DESIGN DECISION: real sale ends 2026-12-31, verified in CMS` |
| T4 | Mono as house voice | `// CONTEXT: SaaS product with code-heavy documentation` |
| K25 | Glass effect | `// PREMIUM PAIR: proper backdrop blur, chromatic dispersion, directional light` |

无效排除（问题仍计入）：

| C1 | Blue→purple gradient | "we liked it" | ❌ Not a justification
| K9 | Default CTA pair | "it's our style" | ❌ Too vague
| L1 | Default hero stack | "approved by team" | ❌ Who? When? Why?
| K6 | Kitchen-sink card | "industry standard" | ❌ Slop IS the industry standard

排除数量限制

• >5 项排除 → 逐项复查。大量排除表明设计未遵循简报，或评估者过于宽松。
• >10 项排除 → 一定有问题。要么简报几乎允许一切（那评估的意义何在？），要么有人在利用排除来抬高分数。
• 排除特色元素 → 几乎从不合理。如果排除了 S1–S7，按定义该设计就没有特色。

在报告中记录排除项

在“排除的问题”表格中，按以下格式填写：

## Excluded tells

| ID | Tell | Exclusion reason |
|----|------|------------------|
| C1 | Blue→purple gradient | `// BRIEF: brand guidelines v2.3 specify #6366f1→#8b5cf6` |
| K14 | Countdown timer | `// DESIGN DECISION: real sale ends 2026-12-31, verified in CMS` |

**Exclusion summary:** 2 tells excluded (1 BRIEF, 1 DESIGN DECISION)

质疑排除项

复核他人的粗糙度报告时，先检查排除项：

1. 是否有标签？ 没有标签 = 问题计入。
2. 标签是否恰当？ // BRIEF: 需要引用实际的简报。
3. 理由是否具体？ 理由含糊 = 问题计入。
4. 排除数量是否合理？ >5 项需要仔细审查。

使用 Jev 进行评估（可选）

如果运行环境可以访问 TypeSafe Jev，主观评分步骤（轴 7–8）和质量清单核验可使用 Jev 进行校准评估。

Jev 的使用范围：

• 轴 7（特色）——7 个评分问题（S1–S7），采用 0/50/100 评分标准
• 轴 8（协调性）——4 个评分问题（H1–H4），采用 0/50/100 评分标准
• 质量清单——27 个 Noul 问题，用于二元核验

Jev 不会用于：

• 轴 1–6——问题检测是事实性的（引用或删除）；算术由 score.py 处理
• 门槛与上限——由 score.py 执行的确定性规则

发现协议

1. MCP Tool `jev_eval` configured in harness → use it
2. Model `typesafe/jev-latest` via OpenRouter → request it
3. Auxiliary slot (Hermes/Devin/Codex) with Jev → delegate
4. Fallback → inline scoring via current LLM using premium-markers.md rubric

集成文件

文件	描述
scripts/jev_questions.json	38 个分类问题（11 个 Score + 27 个 Noul）
references/jev-integration.md	完整协议、请求/响应格式

完整文档：请参阅 references/jev-integration.md，了解发现 详情、特定于测试框架的说明以及请求/响应结构。

---

质量检查清单

交付前的最终关卡。逐项检查——任何一项未通过， 都意味着报告尚未准备就绪。这是自我评估评分标准；请将其视为 硬性关卡，而非建议。

扫描前检查

• 证据清单完整 — 已记录捕获的内容（代码、 截图、线上 URL）以及无法验证的内容
• 已记录需求简报 — 如果提供了简报，已在报告标题中概述；如果 未提供，已注明“无需求简报”
• 已识别设计背景 — 这是什么类型的设计？（落地 页、SaaS 仪表板、编辑设计、电商）。请阅读 references/contexts.md 以调整优先级和容差
• 已阅读所有参考文件 — 开始扫描前已加载 tells.md、premium-markers.md 和 contexts.md

扫描期间检查

• 严格执行引用或删除 — 每条记录的问题模式都有 ID + 严重程度 + 具体依据（十六进制值、字体名称、file:line 或截图区域）
• 已检查高端设计模式对照 — 记录任何问题模式前，已确认它不是 该模式经过精心设计的高端版本
• 已应用可移植性测试 — 对边界案例，询问：“这个 元素能否原样移到其他网站？”如果可以 → 视为问题模式。 如果不可以（它是该品牌特有的）→ 不视为问题模式
• 已应用辩护测试 — 对边界案例，询问：“如果被问到， 设计师能否用具体理由为这个选择辩护？”如果不能 → 视为问题模式。粗糙设计无法辩护；有意为之的选择则可以。
• 已标注所属区块 — 每条问题模式都分配到具体区块 （主视觉区、功能、定价、页脚等），以便填写区块账本
• 严格控制严重程度 — 仅将绝对规则违规列为严重；不得夸大严重程度

排除项检查

• 已记录排除项 — 每条排除的问题模式都有 // BRIEF: 或 // DESIGN DECISION: 说明作为依据
• 排除理由确实有效 — “我们喜欢它”或“它看起来不错”都不是 有效的排除理由。只有明确的需求简报指示，或有具体理由支持的已记录 设计决策，才符合条件。
• 排除数量合理 — 如果排除了超过 5 条问题模式，请逐条复查。 大量排除意味着未遵循需求简报，而非这些问题模式不适用。

扫描后检查

• 已标记所有无法验证的检查项 — 不得默认为通过或跳过
• 已报告全部 6 条绝对规则 — 根据证据标记为通过/未通过/无法验证
• 已为全部 11 项特征/一致性指标评分 — 评分为 0/50/100，并为每项提供一行 说明
• 区块账本完整 — 每个主要区块都有结论 （CLEAN/SUSPICIOUS/INFLATED/CRITICAL），并附问题模式数量和处理措施
• 正确应用关卡：
  • 特征关卡：如果 Axis 7 < 40，总分上限为 59
  • 绝对规则关卡：如果任何一项严重违规，总分上限为 69
  • 叠加上限：如果主要布局问题模式 ≥3 个，Axis 4 上限为 40
• 仅使用脚本计算 — 所有评分均通过 score.py 完成，绝不手动计算

报告检查

• 严格遵循模板 — 结构与 output-template.md 一致
• 按加权影响排列修复项 — 特征问题（权重 3 倍） 通常优先于单个问题模式
• 语言正确 — 报告使用用户的语言，问题模式 ID 使用英文

最终自查

在提交前，问问自己：

• “还有哪些明显的粗糙之处是我没指出的？”——如果某处看起来明显粗糙，却没有出现在你的发现中，要么找到能说明问题的依据，要么将其记为目录中的一个缺漏。
• “我是否矫枉过正了？”——对于明显粗糙的设计，报告过于简略可能意味着漏掉了问题；对于优质设计，报告过于冗长则可能意味着误报。
• “如果这份报告是别人写的，我会相信它吗？”——像审阅同事的工作一样通读报告。每项说法都站得住脚吗？