ss-score

在执行此工作流前，请遵循每个会话仅需执行一次的更新预检。

设计评分

注册表优先的制品边界

如果 .styleseed/project.json 和 .styleseed/artifacts/index.json 存在，请先解析请求的制品 ID，然后只读取 .styleseed/bundles/<artifact-id>.md 和 .styleseed/manifests/<artifact-id>.json。对于注册表项目，绝不要回退到全局旧版 bundle。只有在不存在注册表时，旧版项目才可使用 .styleseed/effective-rules.md。

确定性检查边界

功能完成情况与此评分分开处理。对于声明的用户预期结果，可选的制品契约 validation.functional.scenarios 要求执行测试且测试通过；请参阅功能检查。缺失或跳过的预期结果无法用外观分数抵消。未经授权执行构建/测试任务时，常规评分不会运行测试或附加功能证据。没有功能契约的制品，其功能仍未经验证，即使其他门槛均已通过。

如需执行契约并获取稳定诊断结果，请运行规范检查器：

node <installed-ss-score>/scripts/styleseed-check.mjs scan \
  --project-root . --artifact <artifact-id> --format json
node <installed-ss-score>/scripts/styleseed-check.mjs scan \
  --project-root . --artifact <artifact-id> --format sarif --out .styleseed/evidence/<artifact>/<run>/deterministic.sarif

扫描前，检查器会重新验证制品清单、bundle/输出哈希、声明的源根目录和项目范围。契约/路径/哈希/覆盖率检查失败会作为硬错误处理。在测量夹具精确度并由维护者提升之前，源代码检测器仅发出警告。稳定的检测器 ID 为：SS001 硬编码颜色、SS002 任意像素值、SS003 transition-all、SS004 未处理减少动态效果的动效、SS005 禁用焦点样式，以及 SS006 高置信度判断为无标签的图标控件。确定性 JSON 报告仅包含 detectorRevision、inventoryHash 和排序后的 findings，因此可将其附加到证据门槛，而无需调用方提供通过声明。

在获准写入证据/执行构建的任务中，通过与其他报告相同的类型化门槛路径附加生成的 JSON。常规评分会报告发现项，但不会附加证据：

node <installed-ss-score>/scripts/evidence-gate.mjs attach \
  --project-root . --artifact <artifact-id> --run <run-id> \
  --gate deterministic \
  --report .styleseed/evidence/<artifact-id>/<run-id>/deterministic.json

/ss-review 会告诉你哪里有问题。/ss-score 会告诉你整体质量如何以及应该优先修复什么——用一个数字加上分类明细，让你像追踪测试覆盖率那样追踪 UI 质量。

不适用场景

• 提交前快速检查是否通过 → 使用 /ss-lint
• 进行完整的文字审查并获取建议 → 使用 /ss-review；应用修复属于单独获准的实施步骤
• 逻辑/配置没有视觉制品——评分毫无意义

步骤 0 — 解析生效的规则集

评分前，请应用上述注册表优先的制品边界。注册表项目应读取 .styleseed/bundles/<artifact-id>.md 和 .styleseed/manifests/<artifact-id>.json；使用 ss-resolve --artifact <artifact-id> --check 检查。注册表不完整或无效属于错误，绝不能因此改用旧版 bundle 或源手册。

没有注册表的旧版项目应读取 .styleseed/effective-rules.md 和 .styleseed/manifest.json，并使用 ss-resolve --from-lock STYLESEED.md --check。如果所选 bundle 缺失或已过期，常规评分会报告证据缺失，但不会重新生成。在获准执行构建/修复任务时，应先从对应的项目自有配置中调用 /ss-resolve 或 $ss-resolve。如果既没有注册表也没有锁文件，请先与用户确认预期范围，再对项目合规性做出判断。

按权威性顺序评分：先检查核心不变量，再依次检查精确输出语法、领域/页面、品牌配方、可选的审美配置文件，以及有界锁定值。锁定文件不能豁免不变量。未知值属于解析器错误；不要自行编造例外。

输出必须注明生效的规则集，例如：

Rule set: operations-console × SaaS × dashboard × enterprise-workbench × swiss

评分内容

根据映射到设计语言的八个加权类别，为文件（或目录中的每个文件）评分。总分 = 100。

类别	权重	参考内容
色彩规范	16	DESIGN-LANGUAGE §1、§18、§72 + VISUAL-CRAFT §C4
层级与字体排印	16	§2、§3、§4、§16 + 字号表 + VISUAL-CRAFT §C2
布局与节奏	12	§13、§14、§15、§61 + VISUAL-CRAFT §C1
卡片与层次	10	§7、§8、§12、§1 + VISUAL-CRAFT §C3
状态与无障碍	18	§11、§70、§71、§72 + VISUAL-CRAFT §C3
动效与交互	6	§24、§59 + engine/motion
一致性	12	VISUAL-CRAFT §C0（每个轴选一种）
辨识度	10	Golden Rules 14–16 + VISUAL-CRAFT §CC-9b（不通用／默认／模板化）

各类别评分方法

每个类别从满分开始，根据阅读代码时发现的违规项扣分。务必具体，并以证据为依据——注明行号。

色彩规范（16）——以下情况扣分：在明确规定使用纯黑作为结构元素的配置文件或语法约定之外，意外使用 #000／text-black（每处 −4，最多 −8）；存在相互竞争的装饰性强调色（−5）；将 emoji 用作 UI 图标（−5）；将正常／OK／“보통”状态显示为状态色，而不是中性灰色（−4）；大多数／每一行都使用状态色（没有严重程度层级）（−4）；使用装饰性色调（金色星星、彩虹分类圆点），而不是强调色／灰色（−3）；存在语义令牌时仍使用硬编码的十六进制颜色（每处 −2，最多 −6）；仅通过颜色传达状态（−4）；使用未解锁的默认靛蓝色（#5E6AD2／#4F46E5）作为强调色，而非选择符合领域特征的颜色（−4）。

辨识度（10）——设计一致的界面仍可能看起来像“AI 生成”。以下情况扣分：图标徽章陈词滥调——每个功能／步骤都重复使用相同的浅色圆角方块，内含通用 Lucide 线性图标（−4，§CC-9b）；逐字照搬 StyleSeed 演示布局（主视觉 + 聊天／3 步流程／功能网格／定价），没有产品专属标识（−4）；没有视觉焦点——所有卡片权重相同、居中且间距均匀，形成整齐划一的网格（−3）；主视觉展示的是图库／占位图，而非这个产品本身（−3）；将逃生出口变成新制服（§CC-9c）——每个区块都使用幽灵般的 01／02／03 序号，或重复使用完全相同的大写眉题 + 大数字卡片，毫无变化（−2）；有特色但过时（§CC-9d）——整页以米色／纸张色为底，产品界面使用衬线正文，或大量深色区块让页面看起来像“宣传册”而非“2026 年的产品”（−3）。最多扣 10 分。

层级与字体排印（16）——以下情况扣分：数值／单位层级与所选语法相矛盾（−4；若有明确规定，紧凑／表格化和类散文式关系均可接受）；字体角色偏离编译后的约定，或 CSS 渲染的字号错误（−5）；所有文本字重相同，没有清晰的主次（−5）；正文字号拥挤或行高不当（−3）；桌面／Web B2B 界面的正文字号 < 16px（宽屏使用紧凑移动端字号）（−4——但密集数据界面元素不在此限：图表刻度、等宽字体 SHA／时间戳、12–13px 的表格元数据都恰当；仪表盘应用界面的 h1 使用 22–24px 也恰当，不属于营销页面 40–56px 标题字号违规）。

布局与节奏（12）——以下情况扣分：分组方式与所选语法或配方相矛盾（−6）：operations-console 需要明确的功能分组，而 editorial-reading 不应被强行塞入卡片；enterprise-workbench 需要对齐的面板／行，而 public-service 需要平铺的步骤流程；间距随意，不符合比例尺度（−3）；无目的地重复相同区块类型（−4）；缺乏可辨识的邻近关系节奏（−3）。 卡片与层级（10） — 如果表面语言混杂或不适合当前任务，则扣分。只有当所选语法／配置文件能一致地运用发丝线、扁平分组、色调渐变或克制的阴影时，这些做法才有效。边框／阴影语言混杂（−4）、阴影明显过重或方向不一致（−4），或在语法要求的情况下缺少组／表面区分（−5），均应扣分。

状态与无障碍（18） — 以下情况应扣分：数据表面缺少空状态／加载状态／错误状态（每项 −5，最多扣 −10；没有数据表面的静态模型图或营销落地页为 N/A：跳过这些扣分，不要因此判定该类别不合格）；正文对比度低于 4.5:1／大号文本低于 3:1（−6）；触控表面上的触控目标 < 44px（以指针为主的桌面控件为 36–40px 时可接受）（−4）；没有可见焦点状态／outline:none（−5）；纯图标控件没有 aria-label（−3）。

动效与交互（6） — 以下情况应扣分：用随机／临时淡入淡出代替命名的种子／关键词（−3）；动效延迟内容显示或阻止操作（−4）；自定义动效未处理 prefers-reduced-motion（−3）。滚动联动／视差／3D／动画渐变取决于表面类型（§43）：在应用／仪表板／数据／表单表面上属于禁止项（−5）；在营销／落地页／品牌页面上则允许（电影级别）——对于这类页面，不要因滚动联动显现、固定区块、3D 主视觉或动画背景而扣分；只针对滚动劫持（劫持滚动／困住用户）（−5）、滚动前隐藏内容或延迟显示标题／CTA 的动效（−4），或缺少 prefers-reduced-motion 回退方案（−3）扣分。先判断页面类型，再评分。

一致性（12） — “每个轴只选一种”的规则（VISUAL-CRAFT §C0）。所选系统中的每项偏离均应扣分：圆角半径角色与方案矛盾（−5；不要惩罚方案认可的表面／控件差异）；使用两个或更多相互竞争的强调色（−4）；阴影语言／光线方向混杂（−3）；图标系列、填充模式或描边粗细混杂（−3）；嵌套轮廓违反方案的几何规则（−2；同心圆角矩形通常使用 max(0, outer − padding)）；控件高度出现无明确原因的偏差（−2）。这个类别最能预测“看起来像 AI 生成的”——应重视整个系统的一致性证据，而非单个组件是否精致。

每个类别最低计为 0。汇总得出总分。

输出格式

## Design Score: 70 / 100   (src/app/Dashboard.tsx)
Rule set: operations-console × product-ui × SaaS × dashboard × enterprise-workbench × swiss

████████████████░░░░░░  C-

Color discipline      11/16   ▓▓▓░  competing orange+blue emphasis hues (l.28-34)
Hierarchy & typography 13/16  ▓▓▓▓  number/unit 1:1 on hero (l.18)
Layout & rhythm         9/12  ▓▓▓░  two identical KPI rows (l.22-31)
Cards & elevation       8/10  ▓▓░░  mixed border + floating-shadow language (l.22)
States & a11y          11/18  ▓▓░░  no empty/loading state; focus ring missing (l.55)
Motion & interaction    4/6   ▓▓▓░  default fade, not a named seed
Coherence               6/12  ▓▓░░  control shape drifts from enterprise-workbench (l.48); competing accents
Distinctiveness          8/10  ▓▓▓░  all-even KPI grid weakens the operational focal panel

### Fix first (highest score gain)
1. Add empty + loading states to the orders list       → +7 states (§71)
2. Restore locked control geometry and primary-action hierarchy → +9 coherence+color
3. Restore recipe-bound hairlines; remove unrelated floating shadows → +4 cards

Re-score after: ~92 / 100.

使用字母等级：90+ 为 A · 80-89 为 B · 70-79 为 C · 60-69 为 D · <60 为 F。

Gate 模式（在向用户展示 UI 前，将此模式用作质量门槛）

Gate 模式适用于已授权的构建或修复任务。普通评分仅作只读评估，不得修改实现或配置。低分不代表可以开始编辑。

1. 为刚生成的 UI 评分。
2. 如果 < 80，将问题反馈给已授权的实现步骤，修复后重新评分。/ss-review 可以说明问题，但它是只读的；它不是编辑步骤。
3. 达到 ≥ 80 时停止，或最多进行三轮修复与重新评分。不得通过切换技能来重新开始预算。遇到权限边界或依赖不可用时，应提前停止。
4. 即使未通过 Gate，也要报告实际分数、修复内容和未解决的问题。将未完成的工作标记为失败或受阻，不要标记为已接受或可发布。

通过分数是底线，不是上限——达到 ≥ 80 就停止；不要追求 100。必须报告 Gate 未通过的情况，这不代表批准发布。总分达标不能免除核心问题，也不能代表已获得人工验收。

规则

• 读取文件——依据真实证据（行号）评分，绝不猜测。
• 优先处理损坏的必需流程以及无障碍性／核心功能故障，然后按影响和工作量对其余改进排序。不要为了提高分数而牺牲约定。
• 对于目录，每个文件打印一行评分，然后给出得分最低文件的完整分析。
• 在纯评分模式下不要自动编辑。/ss-score 用于测量，/ss-review 用于提出建议；在 Gate 模式下，由获授权的实施步骤负责编辑。
• 作为一道 关卡，≥ 80 才能判定通过，而非用于报告未通过的结果。所需检查通过后，不要为了从 95 提高到 100 而延迟完成。