10K Star 的项目，核心代码全是 Markdown，凭什么让 AI 不再长得像 AI

大家好，我是若风。

前几天我在翻 GitHub Trending，看到一个项目叫 Hallmark，描述写的是「Anti-AI-slop design skill for Claude Code, Cursor, and Codex」，一句话，不让 AI 生成的界面长得像 AI。

我顺手点进去看代码，愣了一下。

整个仓库的主语言标的是 CSS，但你真去翻 package.json，里头除了一个 python3 -m http.server 起静态站的脚本，没有任何运行时依赖。没有 React，没有 Vue，没有 Tailwind 插件，连个构建工具都没有。所谓「核心代码」，全是一堆 .md 文件。

一个 skills/hallmark/SKILL.md 558 行，加上 references/ 目录下一堆 reference 文件，加起来大几万字的自然语言规则。就这么个东西，4 个月拿了 10199 个 Star，510 个 Fork。

你想想看，这事本身就挺反常识的。我们习惯了开源项目靠代码量、靠架构、靠性能取胜，Hallmark 偏偏靠的是「把规则写明白」。

我花了一晚上把它读透了，想跟你聊聊这套东西到底妙在哪，以及它藏着的几个有意思的工程选择。

它到底在解决什么问题

先说清楚 Hallmark 是干嘛的。

它是一个 Skill，装在 Claude Code、Cursor、Codex 这些 AI 编程助手里。装上之后，当你让 AI 给你「做个落地页」「做个产品官网」的时候，AI 生成出来的界面，会刻意避开那些「一看就是 AI 写的」的视觉特征。

什么是「AI 味」？Hallmark 的 references/anti-patterns.md 里列得很具体，我挑几个你可能立刻能对上号的。

紫蓝渐变 hero。一个全屏居中的 hero 区，背景从紫色渐变到蓝色，中间一句白字标语，下面一个大按钮。这是「AI 味」的头号特征，几乎所有 LLM 都会默认吐这个。

Inter 通铺。整个页面只用 Inter 一种字体，标题是 Inter，正文也是 Inter，字号一变就完事。一个字体打天下的页面，就是模板页面。

三列等宽 feature 网格。三列等宽，每列一个图标加两行标题加三行描述，间距 24px。每个 LLM 都会吐这个。

还有渐变标题字、侧边色条卡片、纯黑纯白配色、aurora 流光背景、漂浮的 3D 球体装饰……这些 anti-patterns.md 里一条条列着，每一条都告诉你「为什么这看起来像 AI」，以及「怎么改」。

Hallmark 的判断很尖锐。它在 references/structure.md 开头点破了一层窗户纸，结构性雷同才是 AI 的指纹，不是视觉雷同。

大多数 AI 生成的 UI，视觉上各有不同，但结构上完全一样，hero 加三个 feature 加 CTA 加 footer，标题位置一样，列数一样，组件词表一样。换个颜色换个字体，骨架还是那个骨架。Hallmark 要打的就是这个。

规则就是程序，这是它最反直觉的地方

我读完最大的感受是，Hallmark 把「规则」当成「代码」在写。

普通的设计规范文档，是写给人看的，语气是建议性的，「建议使用」「推荐」「尽量」。Hallmark 的 SKILL.md 不是，它写的是一套可执行的自然语言程序，语气是命令式的，带流程控制，带状态判断，带边界条件。

我给你举几个硬核的例子，你感受一下它的工程化程度。

第一步是 preflight 扫描。 Hallmark 在动你的代码之前，会先读你项目里已有的东西。SKILL.md 的 Step 0 明确列了 6 个信号源，按顺序扫，design.md 优先级最高，其次是字体栈、调色板、动效立场、间距体系、框架。

读到之后还要输出一段带文件行号引用的报告，比如「Font stack: Geist + Geist Mono (next/font, package.json L23)」，让你能去核对。扫完结果写进 .hallmark/preflight.json 缓存，下次跑如果 package.json 的 mtime 没变就直接复用。

这套逻辑放在一个「人读的设计文档」里是很奇怪的，但放在「喂给 LLM 的 skill」里就非常合理，因为 LLM 不会自己做工程判断，你必须在规则里把「先读后写」这件事钉死。

真正精妙的是 diversification 机制。 这是 Hallmark 区别于普通模板系统的核心。

它要求，同一个项目里连续两次生成的页面，不能用同一个 macrostructure（页面骨架）。怎么保证？它在每次生成的 CSS 文件第一行打一个 stamp，长这样。

/* Hallmark · macrostructure: <name> · tone: <tone> · anchor hue: <hue> */

下次再跑的时候，先去代码库里找这个 stamp，找到了就必须换一个骨架。更狠的是，光换骨架还不够，它还要求连续两个 theme 必须在三个轴上至少有一个不同，paper 的明度带、display 字体风格、accent 的色相。如果上一个输出是 Specimen（浅底 + 高对比衬线 + 暖色），下一个就不能是 Newsprint（浅底 + 罗马衬线 + 暖色），因为两个轴重合了，得换一个更远的。

这些记录全部写进项目根目录的 .hallmark/log.json，一个 JSON 数组，最新的在最前，保留最近 20 条。Step 2.5 会先读这个文件，用最近 3 到 5 条来约束这次的选择。

你品一下这个设计。它本质上是在用外部状态来对抗 LLM 的无状态性。LLM 每次生成都是独立的，它没有记忆，不知道你上次生成了什么，所以会默认往最安全、最训练数据里高频的那个方向靠。Hallmark 用一个 log 文件强行给它塞了记忆，逼它在每次生成前先看一眼历史，再做差异化决策。

这个思路我之前在拆 ai-website-cloner 那篇里提炼过，叫「Foreman Pattern 包工头调度」，把任务拆解和执行分开。Hallmark 这里是另一个变体，我愿意叫它**「记忆外置」模式**，把 LLM 缺失的跨会话状态，用文件系统补回来。这个模式是可以迁移到任何需要一致性和差异化的 Agent 场景的，不只是前端设计。

上面这六层，从用户输入 Brief 到最终输出页面，全部用自然语言写成，没有任何运行时代码。看图会更直观。

接入层识别动词，预检层扫现有项目，决策层做流派和骨架选择，规则加载层按需读 reference 文件，构建层打 stamp 并导出 token，校验层跑 58 道 gate。整条流水线的状态都落在 .hallmark/ 目录的 JSON 文件里，这就是 LLM 的「外部记忆」。

58 道 slop gate，是它最贵的资产

如果说 diversification 是「防雷同」，那 slop test 就是「防偷懒」。

SKILL.md 的 Step 7 要求，每次生成完之后，必须跑一遍 slop test，58 个 gate，每一个 gate 都是一个 yes/no 的检查，答案必须全部是 no。README 里说的是「fifty-seven slop-test gates」，但你真去翻 SKILL.md 的 Step 7 原文，写的是「the 58-gate slop test」，references/slop-test.md 也是按 58 个编号走的。这点 README 和实际代码对不上，版本对齐没做好，不过不影响理解。

这些 gate 覆盖面极广。我挑几个有代表性的给你看。

gate 34 管移动端溢出，overflow-x 必须是 clip 不能是 hidden。gate 38a 禁止斜体标题，标题永远用 roman 正体，强调用字重或下划线，因为斜体强调词是「AI 味」最可靠的信号之一。gate 47 禁止手绘假浏览器边框，不准自己画 URL 胶囊加红黄绿三个圆点，因为用户的运行环境已经有真的 chrome 了。gate 48 强制 token 锁定，所有颜色和字体必须引用命名变量，不准在渲染中临时写死 OKLCH 值。gate 50 要求带图的 grid 轨道用 minmax(0, 1fr) 而不是裸 1fr，否则长图会撑爆网格。

还有一条特别有意思，叫「诚实文案」。discipline 第 2 条明确写着，如果用户没给数据，就不准编一个。+47% 转化率、50,000+ 团队信任、10 倍更快，这些一旦是编的，就是 slop。这条直击 AI 生成的另一个重灾区，LLM 太喜欢编数据撑场面了。

更狠的是，这些 gate 不是一刀切，它分 genre（流派）。Hallmark 有四个 genre，editorial 是默认，modern-minimal 对应 Stripe/Linear 那一派，atmospheric 对应 Suno/Runway 那种暗色 AI 工具风，playful 是柔和消费向。不同 genre 下，部分 gate 会松绑或收紧。比如 atmospheric 流派下，radial-bloom 这个 gate 会松一点，因为暗色 AI 工具本来就需要一点光晕氛围。这种分 genre 的规则管理，比一刀切的 lint 规则聪明得多。

这里还有一个反直觉的工程细节。SKILL.md 特别强调，slop-test.md 这个文件只能在 Step 7 加载，不能提前加载。原话是「Pre-loading slop-test.md costs ~7K tokens for nothing」。为什么？因为 slop test 是生成完之后的检查，不是生成之前的参考。如果你在生成前就把这 58 条喂给 LLM，LLM 会花 7K token 去读它，但生成时根本用不上，反而挤占了真正有用的规则文件的注意力。

这个「什么时候加载什么文件」的精细控制，是 Hallmark 整套 Skill 里最容易被忽略、但成本意识最强的设计。它把每个 reference 文件都标了加载时机，always-load 的只有 genre 文件，index-then-pick 的是 macrostructure 和组件清单，load-conditionally 的是动效、响应式、富化这些，load-at-the-end 的才是 slop test 和 output contract。一个 Skill 文件做 token 预算管理做到这个粒度，挺少见的。

一套设计 DSL，21 套骨架 50 个组件

光有规则不够，Hallmark 还内置了一套相当完整的设计词汇表，我愿意叫它「设计 DSL」。

它定义了 21 个命名的 macrostructure，就是 21 套完整的页面骨架，每个骨架是一个打包好的整体选择，标题放哪、正文怎么排、分割线用什么语言、按钮什么调性、图片怎么处理，全在一个名字里定了。你不用每次从零拼六个轴，选一个名字就行。比如 Bento Grid、Long Document、Manifesto、Marquee Hero、Stat-Led、Workbench、Quote-Led、Specimen……每个都有自己的适用场景。

组件层面更细。references/component-cookbook.md 是个瘦身索引，列了 50 个组件 archetype，9 个 hero、5 个 section head、6 个 feature、4 个 CTA、4 个 testimonial、8 个 footer、14 个 nav。每个 archetype 有自己的编号和文件，比如 H1 是 Marquee hero，N5 是 Floating pill 导航，Ft5 是 Statement 页脚。

这里有个细节能看出 Hallmark 的「反默认」哲学。它明确要求默认避开 N1a 和 Ft3。N1a 就是那个「logo 硬左 + 几个文字链接居中 + CTA 按钮硬右 + sticky + 白底 + 1px 底边」的导航，FT3 就是那个「四列链接 + 社交图标行 + 版权小字」的页脚。这两个是 AI 最容易吐的导航和页脚指纹，Hallmark 把它们标记为「最被识别的 AI 指纹」，要求除非页面真的只有 2 个目的地，否则别用 N1a，除非是真的文档根或枢纽页，否则别用 Ft3。

配色这块也有完整体系。references/color.md 强制用 OKLCH，不用 HSL 和 RGB，理由是 OKLCH 感知均匀，亮度可控，而 HSL 和 RGB 在亮度上会骗人。一个完整的 Hallmark 调色板有四层，paper 底色、ink 主文字、neutrals 中间 5 到 9 阶灰、accent 一个强调色。accent 有条铁律，占用视口面积不能超过 3%，它是高亮笔，不是色块。

还有一条，禁止纯黑纯白。不准用 #000000，不准用 #ffffff，必须往 anchor hue 方向带一点点色度。因为纯黑纯白读起来扁平、合成感重。这种「禁止极端值」的规则，放在人读的文档里是审美建议，放在 Hallmark 里是硬约束，违反了 slop test 就挂。

扒开看，它也有自己的边界

说了这么多好话，得诚实聊聊它的局限，不然就成了软文。

bus factor 很低。 我查了 contributors，只有 4 个贡献者。一个 10K Star 的项目，核心维护者这么少，说明它高度依赖 Together AI 这家公司的投入。README 第一行就写着「Made by Together AI」，这是一个公司主导的项目，不是社区长出来的。它的持续维护能力，跟公司的战略强绑定。

ROADMAP 里很多功能还是半成品。 比如 Nanobanana（一个图像生成集成），现在的状态是「recommend-only」，Hallmark 只是建议你去生成图片再拿回来，图片密集的 brief（电商、旅游、美食、lookbook）目前会被路由到纯排版方案，明显服务不到位。ROADMAP 自己也承认这是「Now」阶段要补的缺口。还有 hallmark variant（一次产出三个结构差异化的版本）、multi-page coherence（多页面品牌一致性）这些功能，都还在「Next」阶段没落地。

有个细节我专门验证了一下。 README 副标题写的是「four verbs」，列表里给出的是默认行为加上 audit、redesign、study 三个显式动词。但你真去读 SKILL.md 的 Step 2.0 选品逻辑，以及 component-scope 的分支，实际执行路径比「四个动词」复杂得多。比如 study 还分 image mode 和 URL mode，URL mode 还要过 refuse list、attestation、junk-or-blocked 检测。README 的「four verbs」是一个对外简化的说法，实际的协议分支要细密得多。这种「对外宣传简单、内部规则复杂」的落差，用好了是易用性，用不好会让贡献者摸不清边界。

它的适用场景其实很窄。 Hallmark 的核心价值是「让 AI 生成的页面摆脱 AI 味」，它针对的是从零开始的落地页、产品页、品牌页这些 greenfield 场景。如果你的需求是复杂的多页面应用、数据密集的 dashboard、需要复杂交互的 web app，它的 21 套 macrostructure 基本不覆盖。它自己也承认，charts、data-viz 这些是「Later」阶段才补的。所以别指望拿它当万能前端方案，它更像是一个「设计师同行评审」的角色，专门盯你 greenfield 页面的「品味」。

它依赖 LLM 的服从性。 这是最根本的限制。Hallmark 的全部规则都是自然语言，它的执行力完全取决于底层 LLM 有多听话。Claude Code 可能很听话，换成别的模型，规则的执行率会打折。58 个 gate 里，有多少是模型真的会逐条自查的，有多少是写在那摆设的，没人能保证。这是一个「规则即程序」范式的固有风险，没有编译器帮你强制执行。

一点想法

Hallmark 让我重新想了一件事。

我们一直默认「skill」或者「prompt」是轻量的、辅助性的东西，真正的产品力在代码里。Hallmark 颠覆了这个默认。它几乎不写代码，把全部产品力压在「规则的质量」上，而且真的跑通了，拿到了 10K Star 的市场验证。

这说明在 LLM 原生时代，规则设计本身就是一种编程，而且可能是一种被严重低估的编程。当执行环境是一个足够服从的 LLM 时，一份严谨、无歧义、带流程控制和状态管理的自然语言规则，能达到的效果不亚于一套传统代码系统。Hallmark 的 preflight 扫描、diversification log、slop test gate、token 预算管理，每一项都是实打实的工程逻辑，只不过载体从代码变成了 Markdown。

但它也暴露了这种范式的一个核心矛盾。自然语言规则没有编译器，执行率取决于模型的服从度，这天然不如代码可靠。Hallmark 选择用「打 stamp」「写 log.json」「要求口述选择理由」这些外部化手段来强制执行，本质是在用文件系统和协议规范，给自然语言规则补上代码才有的确定性。

这种「记忆外置 + 规则强制口述」的组合，我觉得是所有想做 Agent Skill 的人都该学一手的。不管你做的是设计、写作、代码 review 还是数据分析，只要你的 Agent 需要跨会话的一致性和差异化，这套模式都能直接搬。

Hallmark 自己是 MIT 协议，一行 npx skills add nutlope/hallmark 就能装。如果你平时用 Claude Code 或 Cursor 做前端，装一个试试，哪怕只为了看它那个 preflight 报告和 diversification 口述，都值回票价。

至于它能不能持续，说实话我也在看。4 个贡献者、公司主导、ROADmap 一半没落地，这些是真实的风险。但作为一个「规则即程序」范式的活样本，它已经足够有意思了。