用 Hallmark 检查 AI 网页的模板痕迹

首页的每个标题都配一枚小胶囊，末尾再挑两个词换成斜体衬线字，看起来精致，也可能只是模型反复套用的默认样式。作者检查自己的产品首页后发现：六个顶层标题，六套相同套路。

Hallmark 想解决的就是这类问题：把能识别的设计惯性写成规则，再用脚本检查。作者的结论有边界：审美不能靠 lint 判定，但重复的视觉套路、失效的交互和部分代码问题，可以。对用 AI 写页面的程序员，这比一句「做得高级一点」更有操作空间。

设计要求怎样才能变成可执行的检查

Hallmark 是 Together AI 的 Hassan El Mghari（Nutlope）制作的 MIT 许可 skill，支持 Claude Code、Codex、Cursor 和 OpenCode。作者记录，Version 2 的 package.json 版本为 2.0.0，于 10 月 22 日合并；周二登上 GitHub trending 第一，当天新增 2,830 stars，当晚 API 返回累计 39,048 stars。热度说明关注度，不能证明设计质量。

它比一份提示词多了执行流程：先读项目，一次性索取真实素材，从 50 套主题中给出三个候选，单独完成并评审首屏主视觉区域，再检查整页。作者清点了 50 个主题文件和 50 张预览图。

规则分两层。SKILL.md 开头是必须遵守的 16 条 Floor；references/gates.md 列出 90 条带级别和类别的检查项。Floor 不允许带问题交付，Reflex 针对模型惯性，可以在 CSS 注释里说明真实理由后豁免。

检查能力也有边界：M 类能由 CSS 和标记静态判断，R 类需要真实浏览器，J 类留给人工或评审判断。作者数出 45 条 M 类规则，以及 9 条只能依靠判断的规则。

真正执行的是 scripts/sloplint.mjs：4,422 行、零依赖，要求 Node 18 及以上。它把抽象要求变成了可定位的问题。

规则识别的是特征，不是设计意图

Hallmark 禁止的套路包括标题上方的短标签、拉大字距的全大写小字、标题中单独着色的词、元信息之间的中点，以及没有提交任何内容却显示「Thanks」的表单。

其中，标题前导标签、拉大字距的大写标签、每屏 80 词预算、模板化标点，是不能豁免的四项内部风格规定。这里已经混入了审美立场，并非全是通用质量标准。

脚本判断紫蓝渐变，用的是下面这段条件：

const purple = stops.some((h) => hueIn(h, 265, 330));
const blue = stops.some((h) => hueIn(h, 200, 264));
// ...
if (purple && blue) return 'purple-to-blue';

关键是最后一行：只要色标里同时出现两段色相，就会命中。此前各色标会转成 OKLCH，且彩度必须高于 0.04，因此灰色渐变不会仅凭色相被算进去。

大写标签也有具体门槛：大写、小型大写，或超过 0.03em 的字距，再结合 badge、meta、nav、caption 等名称，或者不超过 15px 的字号判断。标题前导标签则结合位置、kicker 等类名、样式信号和固定短语识别。

它还能读取 .jsx、.tsx、.vue、.svelte、.astro 中的 Tailwind 类名，包括 cn() 和 clsx() 调用。但识别到类名，不代表浏览器里一定呈现出对应样式。

作者的首页实验，恰好暴露了静态检查的边界

作者没有运行 Hallmark，也没有验证完整的设计工作流。

他阅读源码后，用约 100 行 Python 复现了五项检查，再分析自己产品首页的 HTML 和 CSS。样式来自一个 217 KB 的包，先是 Bootstrap 5.3.6，再是站点自己的样式。他记录的检查与观察结果如下：

transition: all          16 rules (15 site layer, 1 inline)
animated height/width     2 (Bootstrap's own .collapsing)
purple-to-blue gradient   7 rules, 2 in use (hero, pills)
tracked capitals          0
middle-dot strings        0
eyebrows                  6 above 6 headings
accented word             6 of 6 headings
focus styles              present (passes)
overflow-x: clip          missing on html and body

最值得看的是命中来源：两处宽高动画属于 Bootstrap 的 .collapsing，不能直接算成页面作者随手写出的坏代码。

六个标题则确实重复了同一套设计。每个 h1、h2 都用 <span class="text-accent"> 包住末尾一两个词，设为斜体衬线字；每个标题上方也都有标签。其中「How it works」「Get started」恰好出现在检查器的短语列表里。

渐变检测就有争议了。首屏的八色彩虹渐变包含 #a166ab 和 #5073b8，作者换算出的色相分别为 322 和 263，因此被归为紫蓝渐变。但人在页面上看到的是彩虹。样式表里还有典型的 #5b47fb 到 #00d4ff，却没有用于当前页面。

另一个个人站点提供了相反例子：<p class="text-uppercase tracking-widest"> 看起来包含拉大字距的指令，但它是 Bootstrap 站点，两份样式表都没定义 Tailwind 的 tracking-widest，浏览器实际只显示普通大写字母。

静态检查能找到可疑证据，不能独自还原页面效果。

我的判断

我认同把可验证的要求交给工具。要求模型「显得高级」，无法给出稳定的通过条件；要求它修复某条规则命中的具体行，至少能形成检查闭环。

原文引用的对照数据也支持一个较窄的结论。9 月，用户 ktlesr 在 issue #74 中报告：针对四份落地页需求，有无 skill 两组页面里，纯黑或纯白的出现次数分别是 40/40 和 14/28；但 transition: all 没有下降，分别为 14/40 和 16/28。参与者认为，后者藏在模型没读到的参考文件里。两组数量不同，评分又是模式检查，不能据此宣称整体设计质量提升。

Version 2 把 transition: all 提到 Floor 第 2 条，并在第 16 条要求有 Node 时运行 sloplint、修复全部 FAIL。这有助于减少规则被跳过的问题，前提是检查真的执行，而且参数正确。

源码还有反例：作者阅读的提交 6033bab 没有校验 --tier。传入 --tier Floor，大写 F 会让过滤器匹配不到规则，程序却显示干净并以退出码 0 结束。报告此问题的 PR #93 已关闭且未合并。

通过 lint，只能证明通过了这套规则，不能证明页面有辨识度。

与单纯提示词相比，它更容易复查；与浏览器审查相比，它缺少渲染证据。首屏和实际尺寸仍需 render tier，依赖 Chrome 与 puppeteer-core。而杂志式栏目有意使用疏排小型大写时，也会违反它的内部风格规定。

Hallmark 还用主题抽取、避开历史构建的记录、独立 reviewer subagent 尝试减少设计趋同，但作者没有测试这部分，效果仍待验证。

能拿来做什么

• 可以先审计现有页面。安装命令是 npx skills add nutlope/hallmark -g，随后用 /hallmark audit ./index.html 生成报告；从克隆仓库也可执行 node skills/hallmark/scripts/sloplint.mjs index.html。作者未运行这两种方式，不能把原文当成安装验证记录。
• 给 AI 编程工具提要求时，把「更精致」补充为具体约束和交付检查。针对 React、Vue 等页面，可先关注重复标题装饰、transition: all 和虚假提交反馈，再结合浏览器确认实际表现。
• 将检查接入 Node 脚本或 CI 前，先确认参数错误会报错，并区分未使用 CSS、框架内置样式和当前页面真正生效的规则，避免把命中数当成整改数量。
• 使用它的素材和主题流程时，可以参考其来源约束。原文记录照片库含 755 张 Wikimedia Commons 开放许可图片，并在页面署名；README 称跳过 Unsplash、Pexels 和 Pixabay，是因为其条款限制 AI 工具选图。具体授权仍应逐项确认。