Hallmark 规则集实战：在 Claude Code 与 Cursor 中对抗 AI 审美同质化的 UI 设计技能

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 与 CursorHallmark 的安装极简一条命令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_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYsk-你的keyClaude 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 用。我把它接进了 CIPR 阶段自动跑分数低于阈值就拦下来。这一步比事后 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。规则文件进 Gitaudit 进 CI模型端点统一配置。这样一套下来AI 生成的 UI 至少不会是最差的那 10%。需要提醒的是规则集不等于创意。它能防止你做出最平庸的页面但无法保证做出最好的。特别有创意的设计仍然需要人类介入hallmark study能提取 DNA但提取不了「这个品牌的设计为什么在情感层面有效」这类隐性知识。如果你要长期在编码和 Agent 场景里跑这套流程建议把模型调用和规则集分开管理端点用 https://taotoken.net/api Key 在 https://taotoken.net/api-keys 生成接入细节看 https://taotoken.net/doc 。规则集本身是纯文本跟着仓库走就行。