Hallmark 不是审美模型，而是一套反默认值的设计审查协议

Hallmark 容易被误读成“让 AI 做出更好看网页”的审美补丁。这个理解太窄，也会用错。它真正提供的是一套设计审查协议：先限制模型最容易回到的默认结构，再用明确的 gate 把常见 AI 味逐项拦下来。换句话说，Hallmark 不负责替团队定义品牌审美，它负责让 AI 交付物在进入人类审美判断之前，先通过一组反默认值检查。

官方 README 对它的定位很直接：这是一个给 Claude Code、Cursor 和 Codex 使用的 design skill，由 Together AI 制作；它会为 brief 选择 macrostructure，套入二十个主题之一，运行五十七项 slop-test gate 加上交付前自评，并拒绝大模型训练分布里最常见的默认输出。这里的关键词不是“漂亮”，而是“拒绝默认”。

它审查的是结构惯性，不是替你判断品味

审美模型通常回答“这个风格好不好看”。Hallmark 回答的是另一个问题：这个页面有没有落入 AI 生成界面最常见的结构惯性。比如 hero、三列 feature、CTA、footer 的固定节奏；比如随手编造的增长数字；比如假浏览器框、假手机框、发光渐变、同一套卡片间距反复出现；比如每个页面只是换了颜色，骨架完全没变。

官方 SKILL.md 把差异说得很清楚：Hallmark 强调 structural variety，而不只是 visual variety。两次不同 brief 的输出，不应该像同一个模板换了配色。这个判断非常关键。很多团队以为 AI 页面“像 AI”，是因为颜色太紫、阴影太重、字体太圆。实际更常见的问题是结构先塌了：标题位置、section 组合、按钮语言、分隔方式、footer 形态都在重复。

所以 Hallmark 的核心不是给模型一个“高级感”提示词，而是把设计工作拆成可追踪的选择：先读项目里的字体、调色、动效和框架信号；再确定 audience、use case、tone；随后选择 macrostructure、theme、nav archetype、footer archetype；最后运行 slop test。审美判断仍然存在，但它被放在协议之后，而不是被一句“make it beautiful”替代。

四个 verb 是四种操作边界

Hallmark 的 README 和 SKILL.md 都把用法压缩成四个 verb。default 用于新建 UI：模型根据 brief 构造页面，选择结构和主题，并在交付前跑 gate。这个模式适合空白落地页、产品页、活动页或需要从零设计的界面。

hallmark audit <target> 是只读审查。它读目标代码，按照反模式列表给出排序后的 punch list，不直接改文件。这个边界很重要：当团队只是想知道当前页面哪里有 AI 味，audit 不应该顺手重构。审查和修改分开，才能让设计债务被讨论，而不是被一次自动编辑掩盖。

hallmark redesign <target> 负责重做视觉结构，但官方 SKILL 明确要求保留 copy、IA、brand 和现有实现边界，除非用户确认完整重建。它不是“把旧站推倒”。正确用法是保留路由、组件归属和信息意图，把 section rhythm、标题摆放、组件语气和交互层换掉。

hallmark study <screenshot | URL> 则是提取设计 DNA：macrostructure、type pairing、colour anchor 等。它不能复制像素，也会拒绝模板市场 URL。URL 模式能读取 HTML 和 CSS 中的字体、颜色等事实，但官方文档也承认一个限制：URL 模式看不到真实视觉节奏，因此需要在诊断里说明 rhythm blind spot，必要时回到截图。

这套 gate 能解决什么

这些 gate 的价值，不在于它们能自动生成好审美，而在于它们把“别像 AI”从模糊吐槽改成可检查条件。这里不宜把数量写成一个永远不变的常数：官方 README 目前仍称有 57 项 slop-test gate，当前 SKILL 和 slop-test 文档却已采用 58-gate 的表述；检查项编号中还出现了后补的 38a，说明清单正在演进。比数字本身更重要的是它覆盖的纪律：交付前六轴自评、禁止编造指标、锁定 token、禁止重画 UI chrome、移动端四个宽度验证、标题禁止斜体。这些不是风格建议，而是门禁。

第一类 gate 处理真实性。Hallmark 明确要求 honest copy：用户没有给指标，就不能写“10× faster”“trusted by 50,000+ teams”。这类数字在 AI 生成落地页里很常见，也最容易损害信任。协议要求要么使用真实数字，要么标记待确认指标，要么换一个不依赖数字的结构。

第二类 gate 处理 token 和一致性。Hallmark 要求主题确定后，颜色和字体声明必须通过命名 token 使用。它反对在渲染过程中临时写 hex、rgb 或散落的 font-family。这个机制解决的是“看起来有设计系统，实际到处是即兴值”的问题。对于需要长期维护的站点，这比一次性好看的截图更重要。

第三类 gate 处理伪装。官方 SKILL 特别禁止重画浏览器栏、手机壳、代码窗口标题栏、IDE chrome。原因很现实：这些元素常被用来制造“产品感”，但多数时候只是廉价装饰。真实截图可以放进 <figure>，不存在真实截图就不要伪造环境。

第四类 gate 处理移动端和可访问性。Hallmark 要求 320、375、414、768 px 都要验证，强调无横向滚动、根元素使用 overflow-x: clip 而不是 hidden、按钮和导航文字不能在移动端断成两行、图片网格使用 minmax(0, 1fr)、长标题必须能换行。这些规则不浪漫，但能挡住大量“桌面截图好看，手机一打开就破”的 AI 页面。

第五类 gate 处理结构重复。Hallmark 要读取项目记忆里的 macrostructure、theme、nav 和 footer 选择，避免连续输出同一形态。它还要求默认避开最容易暴露模板味的 N1a 极简导航和 Ft3 四列 footer。这里的机制不是“随机换主题”，而是按纸面明暗、display style、accent hue 等轴线做差异。

具体机制：从 pre-flight 到 slop test

一个完整 Hallmark 流程先做 pre-flight scan。它会读 design.md、package、tailwind 配置、全局 CSS、tokens、motion 依赖和框架信号，判断该保留什么。已有项目里的字体、调色和 spacing scale 不应该被模型随意覆盖。这个步骤解决的是 AI 设计常见的“进项目第一件事就是发明一套新系统”。

接着是 design-context gate：audience、use case、tone。官方 SKILL 甚至要求即使 brief 看起来完整，也先问这三件事；如果用户说 go ahead，再明确说明推断结果。这个设计看似啰嗦，其实是在防止模型把“clean and modern”当成万能语气，把业务目标、受众知识水平和主要行为全部猜掉。

然后才是结构选择。Hallmark 会先选 macrostructure，再选 theme、nav archetype 和 footer archetype。它的主题不是单一风格库，而是二十个 catalog theme 加一个 custom 分支。custom 只在 brief 明确有品牌色、多属性氛围或要求独特视觉时触发；普通 brief 默认走 catalog，不把选择负担甩给用户。

最后是 slop test 和 pre-emit self-critique。自评维度包括 Philosophy、Hierarchy、Execution、Specificity、Restraint、Variety；低于阈值要返工。gate 则像发布前检查表：有没有假数字、假 chrome、斜体标题、移动端断裂、token 即兴、结构重复。它不是设计总监，但能把一批明显不该进评审的输出挡在门外。

安装与使用示例

官方 README 给出的安装方式是：

npx skills add nutlope/hallmark

更新时可以重新运行同一条命令。也可以把 SKILL.md 和 references 目录复制到不同助手的技能目录：Claude Code 使用 ~/.claude/skills/hallmark/，Codex 可放在 ~/.codex/skills/hallmark/ 或项目级 .codex/skills/hallmark/，Cursor 则把 SKILL 正文放进 .cursor/rules/hallmark.mdc。

这类安装不是把一份无害的配色表放进项目，而是把能指导编码助手读取目标代码、提出修改并执行工作流的指令集加入开发环境。供应链边界因此很清楚：只从 Hallmark 官方仓库或可核验的安装入口获取内容，安装前查看将写入的 skill 与 references，更新时复核差异，不要把来源不明的镜像、打包副本或同名规则直接交给拥有仓库写权限的助手。Hallmark 约束的是设计输出，并不会替宿主助手提供权限隔离。

实际调用可以很直接：

hallmark audit ./apps/web
hallmark redesign ./app/page.tsx --mood austere
hallmark study https://example.com
hallmark study ./screenshot.png

默认 verb 不需要显式写出来。你可以让助手“用 Hallmark 设计一个开发者工具 landing page”，它应该进入 default design flow；如果你只想拿到问题清单，就用 audit；如果已有页面要换结构，就用 redesign；如果你想分析一个参考页面的 DNA，再决定是否采用，就用 study。

采用边界：哪些团队适合，哪些不适合

Hallmark 适合三类场景。第一，团队已经让 AI 生成 UI，但发现输出总像同一种 SaaS 模板。第二，团队需要一个轻量审查清单，把“AI 味”从主观争论转成可复核问题。第三，团队有多个页面或多个实验版本，希望模型主动拉开结构差异，而不是重复同一个 hero 和 footer。

它不适合替代品牌系统。官方 ROADMAP 已经把 brand-first flow 放在 Next，说明当前版本并不把“从一句产品描述生成完整品牌并锁进 design.md”当成已经完成的主路径。现在的 Hallmark 可以尊重已有 design.md，也能在特定 brief 下走 custom palette，但这不等于它已经是品牌策略工具。

它也不适合图像主导项目的完整视觉生产。ROADMAP 的 Now 项写到 Nanobanana hook：今天对 image-heavy brief 仍偏 recommend-only，电商、旅行、食物、lookbook 等需要摄影或强图像资产的页面会被 typography-only 路由得不够充分。也就是说，Hallmark 能约束如何不要乱用图，但不能凭空补齐一套可信照片资产。

还有一个边界是 multi-page coherence。ROADMAP 明确提到：结构多样性对避免模板感是对的，但对同一产品里的多页面品牌一致性可能不足。一个站点内部应该锁住字体、颜色和分隔语言，变化的是页面 voice 轴，而不是每页都像不同品牌。这是 Hallmark 已经意识到、但仍在路线图上的问题。

可验证的评估方案

评估 Hallmark 不应该只问“好不好看”。更可靠的方式是做三组对照。第一组看结构差异：用同一批 brief 分别让普通助手和 Hallmark 产出页面，记录 macrostructure、nav、footer、section 顺序、CTA 语言和首屏构图。若 Hallmark 有效，不同 brief 之间不应只是换色。

第二组看 slop gate 通过率。把输出按官方 gate 转成检查表：是否编造指标、是否出现假 chrome、标题是否斜体、token 是否锁定、移动端四个宽度是否无横向滚动、按钮文字是否断行。每项保留截图、代码位置或浏览器测量结果，不接受“看起来还行”。

第三组看维护成本。让工程师在一周后修改同一页面：换主色、增加一个 section、删除一个 CTA、复用 token 到新组件。记录需要改几处、是否存在散落颜色、是否因结构重复导致页面难以区分。Hallmark 真正的价值应该体现在这些后续修改里，而不只是第一次截图。

如果团队有条件，可以加入盲评，但盲评也要问具体问题：你能否看出这两个页面属于不同 brief？哪些元素像模板？哪里有假内容？移动端是否能完成主要行为？这样得到的是可行动反馈，而不是“更高级”“更干净”之类无法复现的形容词。

失败模式：Hallmark 也会被用坏

第一种失败，是把 gate 当成审美充分条件。通过 57 项检查，只能说明它避开了一批已知低级错误，不能说明页面已经有强品牌、强叙事或强转化。gate 是地板，不是天花板。

第二种失败，是过度追求差异。结构变化如果脱离信息架构，就会变成“为了不像模板而不像产品”。官方 redesign 边界要求保留 copy、IA、brand 和实现边界，正是为了避免设计协议变成代码库破坏器。

第三种失败，是把 study 当成临摹工具。Hallmark 的 study 提取 DNA，不复制像素，也拒绝模板市场。团队如果期待它复刻某个站点的视觉皮肤，会直接撞上协议边界。正确做法是带走结构、类型角色和色彩锚点，再换成自己的内容和品牌语气。

第四种失败，是忽略官方路线图里的未完成项。图像生成接入、brand-first flow、theme-aware motion tokens、variant、structural cookbook、charts reference、multi-page coherence、从代码库读取设计 DNA，这些都还在 Now、Next 或 Later。把这些当成当前能力写进流程，就是在编造。

更准确的采用方式

把 Hallmark 放在 AI UI 生产链路里，最合适的位置是“交付前协议层”。先让模型根据业务目标生成或改造界面，再用 Hallmark 的结构选择、token 纪律、反模式 gate 和移动端规则做约束。通过之后，仍然需要人类设计师或产品负责人判断：品牌是否成立，信息是否该这样排序，语气是否符合用户，哪些内容需要真实证据。

这也是它最有价值的地方。它不承诺替你拥有品味，却能稳定地反对一批模型默认值；它不把设计简化成主题库，却要求每次输出留下结构选择和门禁记录；它不解决所有视觉问题，却让团队知道哪些问题已经被机器挡住，哪些必须由人负责。