每天一个开源项目#39 Hallmark：9.5K Stars，58道门禁拒绝AI设计味
GitHub Trending #2 · 2026-07-16 · ⭐ 9,557 · 🍴 484 · CSS / HTML / JavaScript · MIT
📋 项目概览
| 属性 | 详情 |
|---|---|
| 项目名 | Nutlope/hallmark |
| 一句话 | 面向 Claude Code、Cursor、Codex 的“反 AI 套路”设计 Skill，用结构选择、主题系统和质量门禁约束生成式 UI |
| GitHub Trending | 今日第 2 名，共收录 14 个项目 |
| Stars | 9,557 |
| Forks | 484，约为 Star 数的 5.06% |
| Open Issues | 16（GitHub 仓库口径，可能包含 Pull Request） |
| Watchers | 24 |
| 语言分布 | CSS 58.3% · HTML 35.2% · JavaScript 6.5% |
| License | MIT |
| 版本 | SKILL.md / package.json 均为 v1.1.0；暂无 GitHub Release 与 Tag |
| 创建时间 | 2026-04-27 |
| 默认分支快照 | main @ aeb42fb |
| 项目主页 | usehallmark.com |
数据口径说明：排名、Stars、Forks、语言与日期来自 2026-07-16 的 Trending 快照；贡献者、版本、提交与代码树为同日 GitHub API 和浅克隆补充核验。快照没有保存“今日新增 Stars”，本文不会根据排名反推不存在的数据。
🔥 为什么值得关注？
AI 编程工具已经能快速写出可运行的前端，但“能运行”与“像经过设计”之间仍有明显断层：居中的大标题、三张等宽功能卡、紫蓝渐变、圆角胶囊按钮、四列页脚……模型每次换了颜色，页面骨架却几乎没变。Hallmark 的价值不在于再提供一套 CSS 模板，而在于把设计判断拆成一套可被 Agent 执行、复查和记忆的协议。
它最有意思的创新是把结构多样性置于视觉多样性之前。Hallmark 先从 21 种宏观结构中选择页面形态，再挑选导航、Hero、功能区、CTA、页脚等组件原型，最后才落到 20 套主题或定制主题。换句话说，它试图改变模型的“生成路径”，而不是只在生成结果上换皮。
项目的第二个亮点是质量门禁：交付前先做 6 轴自评，再执行 58 项反套路检查，覆盖字体、布局、动效、交互状态、可访问性、响应式、文案真实性和跨页面重复度。不过必须看清边界：这些门禁目前主要是 Markdown 中的 Agent 指令，并非一个能对 DOM/CSS 自动判定 58 项规则的静态分析器。Hallmark 是一套高密度设计工程知识库与工作流，而不是传统意义上的 UI 框架或自动化测试工具。
🏗️ 核心特性
1. 四种操作模式覆盖设计全生命周期
| 模式 | 输入 | 输出 | 是否修改代码 |
|---|---|---|---|
| 默认 Build | 新页面或组件需求 | 新 UI、Token、结构印章、项目记忆 | 是 |
hallmark audit <target> | 已有页面/代码 | 按严重程度排序的问题清单 | 否 |
hallmark redesign <target> | 已有实现 | 保留文案、信息架构与品牌边界的重构 | 是 |
hallmark study <截图或URL> | 参考设计 | 宏观结构、字体角色、色彩锚点等“设计 DNA” | 默认只诊断 |
study 明确拒绝像素级克隆和付费模板复制。URL 模式读取公开页面的 HTML/CSS，截图模式侧重视觉节奏；诊断后可把提取出的系统导出为便携的 design.md，再交给其他 AI 工具继续使用。
2. 21 种宏观结构，不再默认“Hero + 三卡片”
仓库为每一种页面结构提供独立规范文件，包括 Bento Grid、Long Document、Workbench、Stat-Led、Manifesto、Quote-Led、Catalogue、Index-First、Narrative Workflow、Type Specimen、Map/Diagram 等。Skill 只先读取精简索引，再加载最终选中的一份结构规范，避免一次把完整目录塞进上下文。
这是一种典型的渐进式上下文加载：
读取宏观结构索引
│
├─ 根据受众、任务、语气选出一个结构
│
└─ 只加载 references/macrostructures/<selected>.md
和“让模型自由设计”相比，这种做法牺牲了一部分无约束生成空间，却换来可解释、可复现的结构选择，也显著降低模型掉回训练集高频模板的概率。
3. 20 套主题 + Custom 双深度分支
默认目录提供 20 个命名主题，从 Editorial、Newsprint、Garden、Riso 到 Terminal、Cobalt、Lumen、Hum。主题并非只定义颜色，还被抽象为三个可轮换轴：
- Paper band：dark / mid / light；
- Display style：serif、geometric sans、mono、display-heavy 等；
- Accent hue：warm / cool / neutral / chromatic-other。
连续两次生成至少要在一个轴上不同。若用户明确给出品牌色、多属性气质或独特页面形态，则进入 Custom：
- Tuned：保留 Hallmark 结构，生成一次性的 OKLCH 色板与免费字体配对；
- Bespoke：连页面结构也从零设计，但仍必须通过通用门禁。
这种“自由组合，但不降低质量地板”的设计，比单纯增加主题数量更有扩展性。
4. 58 项 Slop Test + 6 轴交付前自评
交付前自评包含 Philosophy、Hierarchy、Execution、Specificity、Restraint、Variety 六个维度，任一项低于 3/5 都要求重做。随后执行 58 项门禁，代表性规则包括：
- 禁止紫蓝渐变文字、等宽三卡片、卡片嵌套卡片；
- 禁止
transition: all、无差别 hover scale 和布局属性动画； - 禁止编造“10× 更快”“5 万客户”等无来源指标；
- 所有交互元素必须覆盖焦点、激活、禁用等状态；
- 颜色和字体必须来自命名 Token，禁止渲染途中临时硬编码；
- 320 / 375 / 414 / 768 px 宽度必须通过响应式检查；
- 标题禁止斜体，按钮和导航文字不能换成两行；
- 假浏览器栏、假手机外框、假 IDE 窗口被视为强 AI 痕迹；
study提取出的 DNA 不能在构建阶段被悄悄换回目录主题。
这里有一个值得注意的版本细节：README 仍写“57 道门禁”，但 v1.1.0 的 references/slop-test.md 标题、Skill 流程和预览格式均已明确为 58 道。编号采用 1–57，并额外插入 38a“斜体标题”规则，因此总数是 58。本文以实际规则文件为准，也说明 README 存在一处滞后文案。
5. 项目级记忆，主动避免“这次又长一样”
每次构建会把结构、主题、强化方式和 Brief 摘要写入 .hallmark/log.json，新记录放在数组头部，最多保留 20 条：
{
"date": "2026-07-16",
"macrostructure": "Workbench",
"theme": "Cobalt",
"enrichment": "none",
"brief": "开发者工具产品页"
}
下一次生成会读取最近 3–5 条记录：宏观结构不能与最近三次相同，导航与页脚原型也需要轮换。另一个 .hallmark/preflight.json 缓存字体、色板、框架、间距和动效依赖扫描结果，避免反复分析同一工程。
6. 工程安全边界比“全量重写”更克制
Hallmark 明确规定：设计 Skill 不是删除生产代码的许可证。已有项目默认采用原地编辑或增量组件；删除路由树、组件目录和旧站点必须先获得确认。已有全局样式表采用 append-only 策略，不能把 Tailwind 入口指令或原有 Token 一次覆盖掉。这些约束解决的是 AI 设计工具常见的另一类风险——为了“重做视觉”而破坏工程边界。
🔬 技术架构深度解析
1. 它不是组件库，而是 Agent 的分层决策系统
用户 Brief / 已有项目 / 截图或 URL
│
▼
┌────────────────────┐
│ SKILL.md 入口路由器 │
│ Build/Audit/Redesign/Study
└─────────┬──────────┘
│
┌──────────┴───────────┐
│ Pre-flight 工程扫描 │──► .hallmark/preflight.json
│ Scope: 页面 or 组件 │
└──────────┬───────────┘
▼
Audience / Use case / Tone
│
▼
Genre → Macrostructure → Nav/Footer Archetype
│
┌────────┴─────────┐
│ Catalog 20 Themes│
│ Custom Tuned │
│ Custom Bespoke │
│ Studied DNA │
└────────┬─────────┘
▼
按需加载 typography / color / motion / states 等规范
│
▼
生成页面 + tokens.css + CSS Stamp
│
▼
6 轴自评 → 58 门禁 → 失败则修订
│
▼
输出产物并更新 .hallmark/log.json
核心 SKILL.md 本身有 558 行、约 67 KB，承担的是状态机、路由和装载策略；具体知识拆在 references/ 中。它特别强调不要提前加载所有资料，例如 Slop Test 只能在构建完成后加载，宏观结构和组件原型都采用“读索引、选一个、只加载一个”的方式。这说明作者不只关注设计质量，也在控制 Agent 的上下文成本。
2. 代码仓库考古：真正的核心是 Markdown 规则资产
对默认分支 aeb42fb 的浅克隆统计如下：
| 指标 | 数量 |
|---|---|
| 非 Git 文件总数 | 282 |
| Markdown 文件 | 128，约 11,494 行 |
| CSS 文件 | 50，约 27,776 行 |
| HTML 文件 | 39，约 11,641 行 |
| JavaScript 文件 | 13，约 2,463 行 |
| 宏观结构规范 | 21 |
| 组件原型规范 | 50 |
| Genre 规范 | 4 |
| 独立示例目录 | 17 |
site/_tests 下文件 | 71 |
GitHub 显示 CSS 占 58.3%，容易让人误以为这是 CSS 框架。实际上，大量 CSS/HTML 来自官网、示例和测试夹具；产品核心是 SKILL.md + references/*.md 组成的声明式规则系统。它不提供 React/Vue 运行时，也没有把设计限制编译成浏览器插件。
3. 组件原型层负责结构指纹
仓库把常见区域拆成 50 个可选原型，其中包括 9 种 Hero、5 种 Section Head、6 种 Feature、4 种 CTA、4 种 Testimonial、8 种 Footer 和 14 种 Navigation。一次构建通常只加载 5–7 个最终选中的原型文件。
这使页面指纹由多个正交选择组成：
页面指纹 = 宏观结构
+ Genre
+ Theme / Custom DNA
+ Nav 原型
+ Hero 原型
+ Section / Feature 原型
+ Footer 原型
+ 动效与强化方式
相比“20 个模板”，这种组合空间更大，而且每项选择都有适用条件和拒绝条件。项目真正想解决的并不是主题数量不够，而是 LLM 在没有显式决策点时总会回到概率最高的结构。
4. Token、Stamp 与 Log 构成轻量设计治理链
Hallmark 要求页面颜色、字体、间距、字号、动效时长、圆角都落入 tokens.css；CSS 首部写入结构、主题、色相和检查结果 Stamp；.hallmark/log.json 则记录跨生成历史。三者分别承担：
- Token：约束本次实现的一致性，并方便跨项目迁移；
- Stamp：让下一次 Agent 能从代码中识别上次选择；
- Log：提供最近多次生成的结构历史，驱动多样性轮换。
这不是复杂的数据库或设计平台，却形成了“选择—实现—审计—记忆”的闭环，尤其适合以文件系统为工作区的 Coding Agent。
5. 当前测试体系的优势与不足
仓库提供大量自包含 HTML/CSS 样例、site/_tests 夹具和在线主题演示，适合人工浏览、回归比较和提示词评测。但 package.json 只有一个静态站点启动脚本：
{
"scripts": {
"serve": "python3 -m http.server --directory site 4173"
}
}
没有看到自动执行 58 项检查的 linter、浏览器截图差异测试或 CI 测试命令。因此：
| 能力 | 当前成熟度 |
|---|---|
| 设计知识覆盖 | 高：结构、字体、颜色、动效、文案、响应式均有细则 |
| Agent 可执行性 | 高：步骤、分支、输出格式非常明确 |
| 自动判定能力 | 中低：多数门禁仍依赖模型自检和人工验收 |
| 运行时依赖 | 低：Skill 本身无需前端框架 |
| 结果确定性 | 中：同一规则在不同模型上的遵循程度仍可能不同 |
Roadmap 已提出“Live preview as an MCP server”：监听文件、沙箱渲染、截图回灌，再按 Slop Test 复审。如果实现，它会把今天的声明式门禁升级为更接近闭环视觉测试的系统。
📖 README 核心内容摘要
设计哲学
README 的核心主张是：两份不同 Brief 生成的页面应该像两个不同网站，而不是同一模板的颜色替换。为此，Hallmark 把页面构建顺序从“先写组件再修样式”改成“先定结构，再选主题和原型，最后生成代码并审计”。
四个关键词
- Structural variety：宏观结构优先于配色变化；
- Refusal：主动拒绝模型训练分布中的高频 UI 套路；
- Auditability：输出带 Stamp，自评和门禁结果可追溯；
- Portability：通过
tokens.css与可选design.md交给其他工具继续使用。
官方示例覆盖
README 展示了 SaaS、旅行、时尚、开发者基础设施、唱片厂牌、蜂场、茶单、字体工作室等不同 Brief。示例页面均为自包含 HTML + CSS，并在 CSS 注释中记录宏观结构。站点支持按 T 键轮换主题，以便直观看到“同内容、不同结构和主题”的差异。
README 与当前规则文件的差异
README 两处仍写 57 道门禁，但当前 SKILL.md、slop-test.md 和预览契约已经使用 58/58。实际原因是编号序列中新增了 38a，并非少了一条规则。使用时应把仓库内的 Skill 和 references/ 一起更新，不能只复制旧版 README 示例。
🚀 快速上手
方式一：通用 Skills 安装器
npx skills add nutlope/hallmark
重复执行同一命令即可更新。安装完成后，在支持 Skills 的 Coding Agent 中直接给出设计任务，或使用三个显式动词。
最小工作流
hallmark 为我的开源 API 产品设计一个首页。
受众：后端工程师；主要动作：查看文档；语气：technical。
Hallmark 会先扫描现有工程，再给出 Genre、宏观结构、主题、导航/页脚原型与强化方式，随后构建页面、写出 tokens.css、执行 58 项检查并更新项目记忆。
审计已有页面
hallmark audit ./src/pages/index.tsx
该模式只输出按优先级排序的问题清单，不修改代码，适合在合并前做设计质量评审。
保留内容，重做视觉结构
hallmark redesign ./app --mood editorial
默认保留路由、组件所有权、文案意图、品牌和信息架构，只替换请求范围内的视觉/交互层。涉及多文件删除时，协议要求先确认。
从参考页面提取设计 DNA
hallmark study https://example.com/reference
它会提取宏观结构、字体角色、色彩锚点与组件原型，而不是复制像素。若 URL 被鉴权墙挡住、只返回 SPA 空壳或不可读，则应改用截图模式。
手动安装位置
| 工具 | 目标路径 |
|---|---|
| Claude Code | ~/.claude/skills/hallmark/ |
| Cursor | .cursor/rules/hallmark.mdc（复制 SKILL.md 正文，不含 frontmatter） |
| Codex | ~/.codex/skills/hallmark/ 或项目级 .codex/skills/hallmark/ |
手动安装时应同时复制 SKILL.md 与整个 references/，否则宏观结构、主题、动效和门禁等按需加载文件会缺失。
📊 增长速度与社区热度
Star 增长评估
项目从 2026-04-27 创建到 2026-07-16 快照约 80.1 天，累计 9,557 Stars。以全生命周期做一个仅供参照的平均值：
- 平均约 119 Stars/天；
- 折算约 3,578 Stars/30 天；
- Fork / Star 比约 5.06%；
- Open Issues / Star 比约 0.17%。
这组数字说明它在不到三个月内完成了非常快的冷启动，9.5K Stars 对“提示词/Skill 型设计知识库”尤其突出。但该平均值不能代表近期斜率：快照未保存今日新增 Stars，仓库也没有可用的历史 Star 序列，所以不能严谨计算“今日增长率”或判断增长是否仍在加速。能确定的是它当天位列 Trending #2，短期讨论热度很高。
社区活跃度
| 指标 | 数据与解读 |
|---|---|
| Stars | 9,557，创建约 80 天 |
| Forks | 484，Fork 转化率约 5.06% |
| Open Issues | 16，绝对数量不高 |
| Watchers | 24 |
| API 返回贡献者 | 4 位；Luffixos 121 次贡献、Nutlope 10 次，另两位各 1 次 |
| GitHub Releases | 0 |
| Git Tags | 0 |
| 默认分支最近提交 | 2026-06-04，合并现有全局样式表保护修复 |
仓库级 pushed_at | 2026-06-26，晚于默认分支最近提交，说明其他分支仍有更新 |
贡献高度集中在主维护者，且尚未建立 Release/Tag 节奏，这是快速增长项目的典型早期特征。优点是规则体系已经非常庞大且方向统一；风险是版本边界、迁移说明和自动化验证仍不够成熟。对生产团队而言，建议固定 Commit 或自行 Fork，而不是每次无条件拉取 main。
今日 GitHub Trending 完整榜单
下表顺序严格按脚本捕获的 14 个仓库排列；Stars、Forks 和主语言为 2026-07-16 同日 GitHub API 补充核验。今日新增 Stars 未被快照保留，统一标为“未保留”。
| # | 项目 | Stars | Forks | 主语言 | 今日新增 |
|---|---|---|---|---|---|
| 1 | OpenCut-app/OpenCut | 72,892 | 7,415 | TypeScript | 未保留 |
| 2 | Nutlope/hallmark | 9,557 | 484 | CSS | 未保留 |
| 3 | mattpocock/skills | 173,021 | 14,849 | Shell | 未保留 |
| 4 | moeru-ai/airi | 42,666 | 4,258 | TypeScript | 未保留 |
| 5 | Dicklesworthstone/destructive_command_guard | 4,893 | 184 | Rust | 未保留 |
| 6 | HKUDS/Vibe-Trading | 23,978 | 4,069 | Python | 未保留 |
| 7 | openinterpreter/openinterpreter | 65,680 | 5,659 | Rust | 未保留 |
| 8 | HKUDS/DeepTutor | 26,535 | 3,584 | Python | 未保留 |
| 9 | HenryNdubuaku/maths-cs-ai-compendium | 6,101 | 760 | TypeScript | 未保留 |
| 10 | injaneity/pi-computer-use | 1,334 | 83 | TypeScript | 未保留 |
| 11 | Shubhamsaboo/awesome-llm-apps | 122,236 | 18,026 | Python | 未保留 |
| 12 | coreyhaines31/marketingskills | 39,989 | 6,329 | JavaScript | 未保留 |
| 13 | YimMenu/YimMenuV2 | 1,466 | 356 | C++ | 未保留 |
| 14 | hasaneyldrm/exercises-dataset | 14,596 | 1,749 | HTML | 未保留 |
本期没有重复分析榜首 OpenCut：它已在 2026-07-14 的日报中出现。Hallmark 虽不是榜单里代码体量最大的项目，却提供了更独特的工作流边界——把设计审美变成 Agent 可执行、可审计、可积累项目记忆的工程协议，因此更值得单独拆解。
🎯 适用场景
| 场景 | 为什么适合 Hallmark | 注意事项 |
|---|---|---|
| AI 生成营销页/产品页 | 结构和主题先决策，能显著减少模板味 | 仍需真人检查品牌准确性与转化逻辑 |
| Claude Code / Cursor / Codex 团队 | 纯文件型 Skill，容易放入个人或项目配置 | 不同模型对长规则的遵循度可能不同 |
| 已有页面设计审计 | audit 只给问题清单，不会直接破坏代码 | 结论主要来自规则推理，不是浏览器自动测量 |
| 多页面品牌系统 | Token、Stamp、Log 可形成轻量治理链 | 当前多页面一致性仍在 Roadmap 中继续完善 |
| 从参考设计学习 | study 提取结构与视觉 DNA，避免像素复制 | URL 模式无法可靠判断真实视觉节奏，截图更稳 |
| 设计系统原型与交接 | 可输出 tokens.css，并按需锁定 design.md | 要验证导出结果与现有 Tailwind/shadcn Token 是否冲突 |
| 高监管或强可访问性产品 | 有对比度、焦点、禁用态、减弱动效等规则 | 不能替代 axe、Lighthouse、Playwright 等真实工具测试 |
不太适合的情况
- 只需要一套即插即用 React 组件的人：Hallmark 不提供组件运行时；
- 追求完全确定性生成的人：它仍依赖模型正确解释并执行 Markdown 规则；
- 希望自动给出可证明的视觉合规报告的人：当前缺少完整静态 linter 与浏览器测试闭环；
- 已有成熟设计系统且不希望改变结构的人：应明确要求保留现有
design.md、Token 和组件边界，只使用审计能力。
💡 总结
Hallmark 的真正价值不是“让 AI 页面更漂亮”，而是把原本模糊的审美反馈转译成 Agent 能执行的决策树：先理解工程和 Brief，再选择结构与主题，按需加载规则，输出 Token 和可追踪印章，最后用自评与门禁阻止模型回到高概率套路。21 种宏观结构、50 种组件原型、20 套主题、58 项门禁和项目级记忆，共同构成了一个轻量但完整的设计治理层。
它也没有掩盖当前限制：规则丰富不等于自动验证。现阶段最适合把 Hallmark 当作高质量“设计工程系统提示词 + 知识库 + 工作流”，再配合浏览器截图、Playwright、axe 或人工设计评审。若 Roadmap 中的 MCP 实时预览和截图回灌落地，它有机会从“会自我约束的 Skill”进化为真正闭环的 Agent 设计 QA 系统。
数据来源：GitHub Trending（2026-07-16）· Nutlope/hallmark README、GitHub API、默认分支 aeb42fb 代码树。
