技能包成了新的分发单位：这半年生态变了什么

【免费下载链接】hallmarkAnti-AI-slop design skill for Claude Code, Cursor, and Codex.项目地址: https://gitcode.com/GitHub_Trending/hal/hallmark

半年前，把一套设计规范交给 AI 编程助手，动作是"复制一段提示词"；现在，动作是npx skills add nutlope/hallmark -g，然后它在~/.claude/skills/hallmark落下一个 5.8 MB 的目录。同一件事的交付形态变了：从一段可以随时被截断、被摘要、被遗忘的文本，变成了一个有入口文件、有引用树、有脚本、有校验、有版本号的软件制品。

这篇文章不打算复述某个项目有多好用。它要回答三个更硬的问题：技能包作为分发单位，形态具体变成了什么样（可查的源码证据）；供给侧出现了哪几种打法（可查的舆情数据）；以及为什么"能装"之后，"能比"仍然没解决（仓库自带的评测数据）。

Hallmark 是一个合适的样本：它是 Together AI 出品的反 AI 味设计技能，掘金 2026 年 7 月的盘点里给到 1.3 万星；更关键的是，它把"分发"这件事的每一层都摊在了仓库里——安装器、主题索引、评测集、插件清单，一个不缺。

一、三段形态：从片段、规范，到可安装单元

如果按"交付物是什么"来切，这半年至少能看清三段。

第一段是片段。一段 system prompt，一个.cursorrules，一份粘贴进对话的清单。它的版本等于聊天记录，它的校验等于人的肉眼。

第二段是规范文档。单一入口 + 分层引用，标志物是SKILL.md。Hallmark 的入口文件只有 18,239 字节，skills/hallmark/SKILL.md的 frontmatter 已经把"这是一个什么单位"写清楚了：

name: hallmark description: "Design skill for websites and new pages that look designed, not generated..." argument-hint: "<prompt> | redesign <path> | audit <path>" version: 2.0.0 metadata: opencode/slash: "true"

argument-hint这一行值得多看一眼：技能不再只是"给模型看的说明书"，它同时声明了人类怎么调用它——/hallmark redesign <path>。规范文档开始有了 CLI 的形状。

真正让"规范"变成"系统"的是加载纪律。SKILL.md 的第 4 步写的是 "Exactly these"（就这些文件），并列出了layout.md、anatomy.md、imagery.md、craft.md、genre 文件、主题文件、gates.md§1–§4；21 种页面骨架则要求 "load only the file you pick"（只加载你选中的那一个）。配套的目录也确实按这个粒度切开了：skills/hallmark/references/macrostructures/下 21 个文件合计只有 32.6 KB，单个约 1.3 KB。

这是"上下文分页"：把一份巨大的规范拆成可寻址的页，让模型按需读取，而不是一次性灌进去。二手文章里常说的"69 项 slop test"，在仓库里对应的是skills/hallmark/references/gates.md——39 KB，带编号的条目 88 条，分档为 M（静态）44 条、M/R（静态 + 渲染）14 条、R（仅渲染）11 条、J（人工判定）9 条、M/J 6 条、R/J 4 条。一个技能包的门禁数量，已经比很多前端项目的 lint 规则还多。

第三段是可安装单元。这一步的标志不是文档写得多好，而是仓库里出现了"包的自我描述"。package.json里除了常规字段，多了一段：

"files": ["skills"], "skill": { "entry": "skills/hallmark/SKILL.md", "references": "skills/hallmark/references", "harnesses": ["claude-code", "codex", "cursor", "opencode"] }

files白名单只放skills/，意味着eval/、site/、docs/都不进包；skill.entry声明入口；skill.harnesses声明兼容面。再加上.claude-plugin/marketplace.json这份插件市场清单，同一个技能同时有两条分发通道：一条走npx skills add，一条走 Claude Code 的/plugin marketplace add。

形态变化的代价是体积。执行du -sh的结果很直白：

规则很便宜，材料很贵。88 条门禁的全文 39 KB，48 套主题的材料库 5.4 MB。这个比例说明厂商级技能包的护城河不在措辞，而在"待选集合"——48 种纸、字、色、面的组合，以及 755 张可用照片（skills/hallmark/scripts/photos.json，452 KB 元数据，无图片文件）。

二、安装器已经在偷偷做包管理的事

第三段形态最容易被忽略的一点：当交付物是一个目录，安装就不再是cp -r。

skills/hallmark/scripts/install.mjs里有三段代码值得逐行看。

第一段是载荷声明——它定义了"一个技能包到底包含什么"：

const PAYLOAD = ["SKILL.md", "LICENSE", "references", "scripts", "agents"];

第二段是目标探测——它把"装在哪儿"这个各 harness 各行其是的混乱，收敛成一张表：

const TARGETS = { claude: { dir: path.join(HOME, ".claude", "skills", "hallmark") }, codex: { dir: path.join(HOME, ".agents", "skills", "hallmark"), detect: () => [".codex", ".agents", ".cursor"].some(...), legacy: path.join(HOME, ".codex", "skills", "hallmark") }, opencode: { dir: path.join(HOME, ".config", "opencode", "skills", "hallmark") }, };

注意legacy字段：旧版本装在~/.codex/skills/hallmark，新版本装在~/.agents/skills/hallmark，安装器会主动提示"Codex 可能把 Hallmark 列两次"，并给出清理命令。这是包管理的经典问题——路径迁移与重复安装——只不过发生在技能生态里。

第三段是安装门禁。装之前先跑两个检查，任何一项不干净就拒绝安装：

const clean = gate("refcheck", [..., "refcheck.mjs", "--errors"]) & gate("theme validate", [..., "theme.mjs", "validate", ...themeFiles]); if (!clean && !has("--force")) { /* 什么都不装 */ }

再往外一层是写入策略：先拷到dir + ".tmp-install"，成功后renameSync覆盖；符号链接一律不跟随（"never follow a link out of the skill into the install"）。这两条合起来，就是一个最小可用的原子安装语义。

把这四件事列出来——载荷清单、目标探测、安装前校验、原子写入——你会发现它已经构成了一个包管理器 70% 的骨架。缺的那 30% 是：版本求解、依赖声明、锁文件。

而这 30% 恰好是当下技能生态最大的空洞。仓库里有个细节能佐证：站点上已发布的主题页，CSS 首行的 stamp 记录的是v2.8.0（42 处）与v2.7.0（15 处），而package.json与 SKILL.md 的version仍然是2.0.0。产物自己在记版本，分发元数据没跟上。这不是某个项目的疏忽，而是整个品类还没建立起"技能版本"与"技能产物版本"的对应关系。

三、供给方：个人、方法论、厂商，三种完全不同的成本结构

掘金 7 月那篇盘点的数据足够说明供给侧的密度：7 月 11 日，obra/superpowers、mattpocock/skills、addyosmani/agent-skills三个仓库单日合计涨星接近 50 万；mattpocock/skills16.5 万星、1.5 万 fork；superpowers25.7 万星、23000+ fork；addyosmani/agent-skills7.7 万星。同一篇文章把 hallmark（1.3 万星）和 caveman（9.1 万星）归为"省钱二人组"。

数字背后的三种打法，成本结构完全不同。

个人型：把私人目录掏出来。Matt Pocock 的 21 个技能，定位是"小而可组合"，装法是npx skills add mattpocock/skills。这类供给的边际成本接近零，质量上限取决于作者本人的手感，没有资产、没有评测、也没有兼容性承诺。

方法论型：卖流程，不卖单点。superpowers的 Spec → Plan → Implement → Review → Ship 五段式，配上 23000+ fork，说明它的真实用途是"被团队拿去改成自己的内部标准"。它分发的是组织流程，所以 fork 数比 star 数更能说明问题。

厂商型：带资产、带评测、带发布通道。Hallmark 的 README 第一屏就写着 "Made by Together AI."，仓库里同时有三样个人项目几乎不会有的东西：site/（48 个可点开的主题页 + 21 个成品案例）、eval/（8 个 brief 的评测集）、.claude-plugin/（插件市场清单）。

厂商进入带来的最直接变化，是许可与素材开始被当成工程问题处理。photos.json的头部写得很清楚：全部来自 Wikimedia Commons，许可限于 CC0、公有领域、CC BY、CC BY-SA；并明确排除 Unsplash、Pexels、Pixabay——理由不是画质，而是"whose terms bar AI tools from picking their images"（这些站点的条款禁止 AI 工具挑选其图片）。仓库里的实际分布也确实只有这几类：CC0、Public domain、CC BY 2.0/3.0/4.0、CC BY-SA 1.0–4.0。

这是技能包和提示词片段最不像的地方：提示词没有合规负担，技能包有。一旦技能会替用户选图、选字体、生成页面并附带署名，它就必须处理素材的来源、许可和归属。

四、能装，但不能比：评价体系的三个断点

安装是一行命令，比较却没有一行命令。这是当下最真实的体验落差。

需求侧的证据很集中。302.AI 在短时间内连续产出了多篇"实测"：Taste Skill、15K Star 的 Huashu Design Skill、GZH-Design-Skill、Guizang Social Card Skill、Lieflat Charts Skill、Kami Skill、以及 Superpowers + 任务板。这些文章的体裁高度一致——"实测 + 能力拆解 + 适用场景"，本质上是在替代一个不存在的评测榜单。另一侧，CSDN 上同一个 Hallmark 被切成了十几篇"完全指南"：audit一篇、study一篇、21 种 macrostructure 一篇、输出预览块一篇、.hallmark/log.json一篇。阅读量在 187 到 1182 之间，收藏 3 到 23。信息供给非常充分，可比性却接近于零。

断点有三个，而且都能在仓库里找到证据。

断点一：口径不统一。README 写 "checks the page … against the tells"，二手文章写"60+ 项 slop test"，另一批写"69 项 AI 味检测规则"，而gates.md里带编号的条目实际是 88 条。三个数字，三种口径。当"检测项数量"成为宣传语，它就不再是质量指标。

断点二：评测不随包发布。eval/目录做得相当认真：8 个 brief（含一个专门诱发编造指标的 b4、一个纯组件路由的 b5、一个视觉能力探测的 b6）、6 条验收标准、六轴视觉评审（Philosophy / Hierarchy / Execution / Specificity / Restraint / Variety，各 1–5 分）、以及"rotation compliance"——同一 arm 的 b1–b5 的 stamp 不允许重复同一个 macrostructure。但eval/README.md第一段就承认：

Not shipped with the skill: thepackage.jsonfileswhitelist only includesskills/, so nothing ineval/reaches the published package.

评测是仓库私有的，用户装到的包里没有它。

断点三：触发率不被测。同一份文档里还有一句更关键的注记：

skills do not auto-trigger inclaude -p, so we invoke by name; this is a CONFORMANCE harness, not an auto-trigger test.

README 也留了同样的后门："If it does not fire on its own, name it"。也就是说，"装了"和"用上了"之间还有一道没人量化的概率。技能生态目前所有的评测，量的是"按名字调用之后能不能做对"，而不是"该触发的时候有没有触发"。

这三个断点合起来解释了为什么选择困难：安装成本被压到一行命令，比较成本仍然是几篇长文加一次自己试。

五、仓库自己给出的最有价值的一组数字

抛开宣传口径，eval/README.md里 2026-07-23 那一轮的结果，是整个技能生态里少见的、可复现的横向数据。

测试设计是"同一份技能文本，两种打包方式"：--pack floor只把 SKILL.md 的 Floor 与 Flow 段落编进 system prompt；--pack full则包含完整 SKILL.md 加references/craft.md和gates.md的门禁表。然后跑 6 个 brief，用sloplint.mjs数 FAIL。

结果：

原文的结论是："The full pack is load-bearing on open models.… The floor block alone is a safety net, not a substitute; ship the whole skill to open models."

这组数字说明两件事。

第一，技能的价值不在"规则有没有写下来"，而在"引用树有没有被读到"。同样是那 88 条门禁，只把 Floor 塞进上下文，GLM 直接掉到 96 个 FAIL；给全量引用，掉到 11 个，且一轮修复就能清零。分页加载不是省钱技巧，它是能力开关。

其次，"质量"在这个品类里是分布性质，不是单点性质。验收标准第 5 条要求 rotation compliance：同一 arm 在 b1–b5 上的 stamp 不许重复同一个 macrostructure。这对应到实现，就是theme.mjs里的滑动窗口：

const log = readLog(flag('log', '.hallmark/log.json')); const recent = log.slice(0, 3); const recentNames = new Set(recent.map((r) => String(r.theme || '').toLowerCase())); const blocked = recentNames.has(t.name.toLowerCase()) || (lastAxes && lastAxes === triple(t));

写入端则把它截断在 20 条：

const next = [entry, ...readLog(file)].slice(0, 20);

于是"连续生成十个页面不重样"这件事，从一句主观评价，变成了一个可断言的约束：最近 3 次用过的主题被屏蔽，最近 3 次用过的轴线组合被屏蔽，最近 5 次用过的照片被排除（theme.mjs的 photos 分支），历史窗口 20 条。

传统包评测算"能不能跑通"，技能评测算"连续跑 N 次会不会收敛到同一个答案"。这是评价维度的一次真实迁移，也是为什么二手文章里最常被拆解的不是 gates，而是.hallmark/log.json。

六、下一步的中间层：更像 npm + CI，而不是 App Store

把上面所有证据摊开，能对"中间层长什么样"做几个有据可依的判断。它们不是预测，是可以被验证或证伪的判据。

判据一：先出现的是版本与校验，不是商店。依据是install.mjs已经实现了载荷、探测、校验、原子写入四件事，缺的只有版本求解和锁。版本这一环甚至已经有内部压力——站点产物的 stamp 写着v2.8.0，包元数据还停在2.0.0。任何一个技能只要被两个以上项目依赖，这个问题就会立刻变成阻塞。

判据二：锁文件会先于市场出现。现在最接近锁的是.hallmark/log.json，但它是"技能行为的项目记忆"（防重复），不是"依赖的版本快照"。两者结构相似、目的不同。真正需要的是"这个项目用哪个版本的技能、读哪套主题、跑哪版 linter"——因为sloplint的判定会随版本变化，今天 0 FAIL 的页面换一版 linter 可能变红。

判据三：信任模型会成为分水岭。技能一旦越出"纯文本"边界，就开始持有权限。Hallmark 的install-hook.mjs往~/.claude/settings.json的PostToolUse里塞一条Write|Edit|MultiEdit钩子，命令是node lint-hook.mjs，超时 10 秒；lint-hook.mjs自身只处理.html/.css与.jsx/.tsx/.vue/.svelte/.astro，且只对带/* Hallmark标记或位于含.hallmark目录的项目生效，"advises and never blocks"。这套设计相当克制，但它清楚地展示了未来市场的核心问题不是"好不好用"，而是**"它在我机器上能做什么"**。

references/flow.md的 harness 对照表把这件事摊得更明白：Claude Code 有子代理、有编辑时钩子、有浏览器预览；Codex CLI 默认断网，imagegen.mjs需要显式请求与批准；OpenCode 的 bash 权限分 allow / ask / deny，且明确要求"永远不要替用户改权限配置"。同一份技能，在三种运行时下的权限面完全不同。任何中间层如果只分发文件，不分发权限声明，就无法解决这个问题。

判据四：评测会从"仓库私有"变成"注册表 CI"。eval/证明了一件事：可复现的技能评测是做得出来的——8 个 brief、6 条验收线、六轴评审、rotation 断言、修复轮次。它现在不进包，也不测触发率。下一步合理的形态不是"技能商店给个五星"，而是"提交时跑固定 brief 集，产出 FAIL 数、轮换合规、成本三项"。ROADMAP 的 "Now" 里还列着两条未完成项，恰好就是这套 CI 的前置条件：三个 harness 上的 conformance（Claude Code、codex exec、OpenCode 非交互模式跑同一 brief，都要 0 FAIL），以及"Measure a build"——同一 brief 下一次页面构建的时间与 token 成本。

至于"技能市场"，短期内更可能长成npm + CI + 一点点商店的混合体，而不是 App Store。理由很朴素：技能包的价值密度集中在"材料库 + 门禁 + 引用树"这三样可被程序检查的东西上，而商店的核心是人工策展与评分。前者已经能被refcheck、theme validate、sloplint自动验证，后者还没有任何可信的量化口径——毕竟连"有多少条检测规则"这件事，三个来源就能给出三个数字。

结语：分发单位变了，评价单位还没变

这半年真正变化的，不是模型变强了，而是经验被封装成了可分发的目录。SKILL.md是入口，references/是分页，scripts/是可执行的部分，tokens.css与主题库是材料，log.json是记忆，sloplint是自检。这六件东西凑齐，它就已经是一个软件包，而不是一段提示词。

但生态只完成了前半程。安装被压到一行npx skills add，比较却还停留在"看几篇实测 + 自己试一次"。仓库里那份不随包发布的eval/，和那句"skills do not auto-trigger"，是这条鸿沟最诚实的注脚。

下一个中间层要解决的，不是"哪里能下载到更多技能"，而是三个更无聊的问题：这个技能是哪个版本、它在我这台机器上有哪些权限、换一台 harness 它还能不能跑到 0 FAIL。谁把这三件事做成一行命令，谁就拿到了这个品类真正的分发权。

【免费下载链接】hallmarkAnti-AI-slop design skill for Claude Code, Cursor, and Codex.项目地址: https://gitcode.com/GitHub_Trending/hal/hallmark