1. 为什么 AI 写的 UI 总像同一个模板倒出来的
如果你最近用 Claude Code 或 Cursor 生成过落地页、SaaS 首页、后台面板，大概率见过这套组合：紫到青的渐变背景、玻璃拟态卡片、六列等宽 feature grid、每个按钮都写着「Get Started」。单看一个页面还行，连着生成三个项目就会发现，它们连骨架都一样——英雄区、三列特性、定价卡、CTA，换个主题色还是同一张脸。
这不是模型偷懒，而是它的训练分布决定的。互联网上出现频率最高的 UI 代码，本身就是审美上最平庸的那一批，模型会无条件滑向这个分布中心。更麻烦的是当前 AI 辅助设计基本是单次射击：生成即完成，没有反馈闭环，这次犯的错下次照样犯。
Hallmark 想解决的就是这件事。它不是设计工具，而是一份注入到 Claude Code、Cursor、Codex 工作流里的「品味规则集」，目标是在模型吐出代码之前就把设计纪律烧进去。它对外暴露四个动词：build选宏观结构并套规则集、audit给现有代码打分、redesign换骨架重建、study提取目标设计的 DNA。适合独立开发者、小团队前端，以及任何被 AI 同质化 UI 烦到的人。
我试过把它接进两个正在跑的项目，下面把配置骨架、验证动作和踩过的坑完整拆一遍，你可以直接抄。
2. 前置准备：把 Hallmark 规则集接进 Claude Code 与 Cursor
Hallmark 的安装极简，一条命令：
npx skills add nutlope/hallmark如果你不想走 npx，也可以手动把SKILL.md和references/目录复制到对应位置。三个编辑器的落点不一样，别放错：
| 编辑器 | 规则集落点 | 生效方式 |
|---|---|---|
| Claude Code | ~/.claude/skills/hallmark/ | 全局生效，所有项目可用 |
| Cursor | .cursor/rules/hallmark.mdc | 项目级，随仓库走 |
| Codex | ~/.codex/skills/hallmark/ | 全局生效 |
这里有个容易忽略的点：Cursor 的.mdc是项目级规则，意味着你可以把它提交进 Git，团队成员拉下来就自动带上同一套设计约束。Claude Code 的 skills 目录是用户级的，换项目不用重装，但也意味着它不会跟着仓库走。我的做法是两边都放一份，Cursor 那份进版本控制，Claude Code 那份当个人默认。
规则集本身不依赖任何外部服务，它是一份纯文本的 Skill 文件。但如果你想让模型在生成时更稳定地遵守规则，建议把模型调用统一走一个可控的入口，避免不同项目里模型版本漂移导致规则执行不一致。我这边是把 Claude Code 和 Cursor 的模型请求都指向同一个 API 端点，配置在下一节。
3. 可复制的规则集配置骨架
3.1 项目级规则文件骨架
在项目根目录建.cursor/rules/hallmark.mdc，内容骨架如下。注意alwaysApply决定它是否每次对话都注入，UI 相关任务建议开：
--- description: Hallmark anti-slop UI design rules globs: ["**/*.tsx", "**/*.jsx", "**/*.vue", "**/*.html"] alwaysApply: true --- # Hallmark Design Discipline ## Macrostructure First Before writing any layout code, pick ONE macrostructure prototype: editorial | narrative | catalog | dashboard | gallery | split Do NOT default to hero + 3-col features + pricing + CTA. State the chosen macrostructure in a comment at the top of the file. ## Slop Test Gates (must pass before emit) - No purple-to-cyan gradient backgrounds - No glassmorphism cards unless brand explicitly requires - No 6-column equal-width feature grid - Every interactive element needs 8 states: default, hover, focus, active, disabled, loading, error, success - Typography: max 2 font families, define scale tokens - Spacing: use a 4/8px scale, no arbitrary values这份骨架的核心不是那几条禁令，而是Macrostructure First这一段。大多数人以为 AI 页面「看起来一样」是颜色或字体问题，其实真正让两个页面像同一模板的是骨架相同。Hallmark 在接到 brief 之前会先选定一个宏观结构原型，两个不同 brief 产出的页面连布局逻辑都不同，而不只是换了主题色。
3.2 预飞行扫描配置
Hallmark 在读取 brief 前会先做一次预飞行扫描，记录当前代码库里已有的字体栈、颜色 token、间距规模，写进.hallmark/preflight.json。这样它决策主题时是基于你项目现状，而不是凭空发明一套。手动触发一次：
npx hallmark preflight --root . --out .hallmark/preflight.json生成的 JSON 大概长这样，你可以按需改：
{ "fonts": ["Inter", "JetBrains Mono"], "colorTokens": ["--bg", "--fg", "--accent", "--muted"], "spacingScale": [4, 8, 12, 16, 24, 32, 48, 64], "existingMacrostructures": ["dashboard"] }existingMacrostructures这个字段很关键。如果你项目里已经全是 dashboard 骨架，Hallmark 下次 build 时会主动避开它，选一个不同的原型，这就是宏观结构多样性的落地方式。
3.3 模型调用端点配置
为了让规则集在不同项目里执行一致，把模型请求统一到一个端点。以环境变量方式配置，别硬编码进规则文件：
export ANTHROPIC_BASE_URL="https://taotoken.net/api" export ANTHROPIC_API_KEY="sk-你的key"Claude Code 和 Cursor 都认这套环境变量。Key 在控制台生成，地址是 https://taotoken.net/api-keys ，接入文档在 https://taotoken.net/doc 。配好之后，规则集注入和模型调用就解耦了，换项目只改规则文件，不动端点。
4. 验证请求：跑一次 build 和 audit 看结果
4.1 用 build 生成一个页面
在 Claude Code 里直接说：
hallmark build 一个开源项目的落地页，面向开发者，强调代码可读性模型会先声明它选的宏观结构，比如editorial，然后在文件顶部留一行注释：
// macrostructure: editorial // hallmark: preflight loaded from .hallmark/preflight.json接着才是布局代码。你会明显感觉到它没有直接冲进「英雄区 + 三列特性」那套默认骨架，而是先铺了一段叙事性的内容流。这就是差异化的来源。
4.2 用 audit 给现有代码打分
对已经写好的页面跑审计：
npx hallmark audit ./src/pages/landing.tsx输出是一份问题清单，不改代码。典型输出：
[hallmark audit] landing.tsx Score: 62/100 Issues: - [hierarchy] 3 competing H1-level headings - [specificity] CTA copy "Get Started" is generic - [restraint] 4 accent colors used, recommend max 2 - [diversity] macrostructure matches 2 other pages in repo这份清单可以直接当 code review 用。我把它接进了 CI，PR 阶段自动跑，分数低于阈值就拦下来。这一步比事后 lint 有用得多，因为它评的是设计品质，不是语法。
4.3 用 study 提取竞品 DNA
想学一个你认可的设计，跑：
npx hallmark study https://example.com --out design.md生成的design.md包含宏观结构、字型搭配、色彩锚点，可以直接放进项目根目录，下次 build 时让 Hallmark 读这份 DNA。这是最快看到实质差异的路径：先 study 两三个竞品，再 build 自己的页面。
5. 本篇常见错排查
5.1 规则文件没生效
最常见的原因是alwaysApply没开，或者globs没匹配到你的文件类型。检查.cursor/rules/hallmark.mdc的 frontmatter，确认globs里包含你实际在写的扩展名。Claude Code 那边检查~/.claude/skills/hallmark/SKILL.md是否存在，路径大小写敏感。
5.2 模型跳过检查门
Hallmark 官方也承认，闭源模型在某些上下文窗口里可能「漂移」，偷偷跳过部分检查门。57 道关卡不保证每次都被执行。对策是把hallmark audit纳入 CI，而不是只在本地跑。本地跑是自觉，CI 跑是强制。
5.3 与既有设计系统冲突
如果你的项目已经有严格的 token 系统，首次运行 Hallmark 可能和既有 token 打架。这时候先跑 preflight，让它读到你的 token，再手动把规则文件里的 spacing scale 和 color 部分改成引用你的 token，而不是让它自己发明一套。
5.4 生成结果仍然同质
如果连着几个页面还是像同一模板，检查.hallmark/preflight.json里的existingMacrostructures是不是没更新。它没记录到已有骨架，Hallmark 就会重复选同一个原型。手动补上，或者重跑 preflight。
5.5 规则集与模型版本不匹配
规则集的效果和底层模型强相关。在 Claude Sonnet 上测试充分，换到其他模型可能有解释偏差。如果你发现规则执行不稳定，先确认模型端点是否一致，再考虑调整规则文件的措辞，把模糊的约束改成可判定的条件。
6. 把设计纪律变成可版本化的资产
Hallmark 最值得关注的不是那 21 个主题，而是它代表的一种做法：把设计判断力编码成可版本化、可复用的规则集。这意味着团队的设计品味开始能被 Git 管理、被 CI 守卫，而不是只活在 Figma 文件和口头传授里。
具体行动路径很清楚：先用hallmark study分析两三个你认可的竞品，拿到design.md放进项目根目录，然后在下一次新页面任务里让 Hallmark 读这份 DNA 来 build。规则文件进 Git，audit 进 CI，模型端点统一配置。这样一套下来，AI 生成的 UI 至少不会是最差的那 10%。
需要提醒的是，规则集不等于创意。它能防止你做出最平庸的页面，但无法保证做出最好的。特别有创意的设计仍然需要人类介入，hallmark study能提取 DNA，但提取不了「这个品牌的设计为什么在情感层面有效」这类隐性知识。
如果你要长期在编码和 Agent 场景里跑这套流程，建议把模型调用和规则集分开管理，端点用 https://taotoken.net/api ，Key 在 https://taotoken.net/api-keys 生成，接入细节看 https://taotoken.net/doc 。规则集本身是纯文本，跟着仓库走就行。
