

现在最容易被一眼识破的 AI 产物,往往不是错字连篇的草稿,而是那些"太顺了"的页面:卡片很多,渐变很稳,按钮很圆,文案也没错。可你看三秒就知道,它像同一个模型从同一个抽屉里掏出来的东西。
这不是单纯的"审美问题"。当 agent 开始真正参与产品设计、前端生成和代码维护时,审美会变成工程约束的一部分。因为一个 agent 不只要能写代码,还要知道什么时候该停下来问:这个页面是否有自己的节奏?这个组件是否只是套了模板?这个设计系统是否会在下一轮生成里继续稳定工作?
这篇文章想聊三个仓库:Hallmark、Stitch Skills 和 Matt Pocock 的 Skills。它们表面上都叫 skills,但侧重点完全不同。Hallmark 把"反 AI 味"写成设计检查清单,Stitch Skills 把设计生成接进工具链,Matt Pocock 则把工程判断拆成小而可组合的工作协议。
把它们放在一起看,会看到一个变化:agent 的下一轮竞争,不是谁更能堆产物,而是谁更能把人的品味、边界和验收标准稳定放进流程。
截至 2026-07-18,三个项目在 GitHub 上的关注度也很能说明问题:
•Hallmark:12,228 stars,定位是 Claude Code、Cursor、Codex 可用的反 AI 味设计 skill。
•Stitch Skills:7,632 stars,围绕 Google Stitch MCP 提供设计、构建和工具插件。
•Matt Pocock Skills:175,827 stars,主张把真实工程经验沉淀成小型、可组合的 agent skills。

Hallmark 的一句话很直接:让 Claude Code、Cursor、Codex 做出来的设计不要像 AI 生成的。
它不是再给 prompt 加一层"高级一点""更有设计感"。Hallmark 做的是更硬的事情:在生成前选择页面宏观结构,套入适合任务的主题和设计规则,生成后再跑 57 道 slop-test gates,并做一次交付前自评。也就是说,它试图把审美判断从"灵感"变成 agent 每次都要执行的流程。
Hallmark 有四个入口:
•默认模式:生成新的 UI,自动选择结构和主题,并在输出前做反模式检查。
•audit:只审查现有代码或页面,给出问题清单,不直接改动。
•redesign:保留文案、信息架构和品牌线索,但抛开原结构,重新做一版有不同指纹的设计。
•study:从截图或 URL 中提取设计 DNA,比如宏观结构、字体组合和颜色锚点;它强调不做像素级复制,也不搬付费模板。
这套思路有点反直觉。多数 UI 生成工具追求"更快给出能看的页面",Hallmark 关心的是"别总长成同一种东西"。它会在 20 个主题之间选择,也会在 brief 不适合现有主题时走 Custom 分支,重新定制色彩、字体和版式。
下面这些页面来自不同 brief。它们的价值不是每一张都多惊艳,而是可以看出它们没有被压成同一种 SaaS 卡片模板。

Bubble:面向酸面包制作的引导式应用。

Distil:内容抽取 API 的产品页。

Cold Snap:唱片厂牌 EP 页面。

Cinder:AI 推理工具页面。

Ferns & Fathom:茶饮菜单页面。

Hollowback Apiary:蜂蜜农场页面。

Off-Register:Risograph 印刷市集页面。

Press Quaternary:字体工作室页面。

Tally:SaaS 产品页。

Wayfare:旅行预订页面。

NAJM:摩洛哥时装品牌页面。

Hyperlane:开发者基础设施页面。

The Cascadia Nightjar:夜行列车票务页面。

The Mend Assembly:维修咖啡馆风格页面。
Hallmark 给我的启发是:审美 skill 不一定要"会画图"。它更像一个不太客气的设计 reviewer,专门拦那些模型最容易滑进去的默认选项:假浏览器框、泛蓝紫渐变、三等分卡片、毫无必要的居中英雄区,还有所有行业都长得像同一家 B2B SaaS 的懒惰设计。
Hallmark 更像审美刹车,Stitch Skills 则像一整套设计生产水线。它围绕 Google Stitch 和 Stitch MCP,把 agent skills 分成 Design、Build、Utilities 三组插件,目标是让 Codex、Antigravity、Gemini CLI、Claude Code、Cursor 这类 coding agents 可以直接操作 Stitch 设计资产。
Design 组偏设计创建和迁移:
•code-to-design:把前端代码转换成 Stitch Design,流程包括 HTML 提取、设计系统处理和上传。
•generate-design:从文本或图片生成新屏幕,编辑已有屏幕,或者生成多个设计变体。
•manage-design-system:上传 DESIGN.md,并把主题应用到屏幕。
•extract-design-md:从前端源码中提取 DESIGN.md。
•extract-static-html:从运行中的 Web 应用抽取自包含静态 HTML,并内联 CSS 和图片。
•upload-to-stitch:把本地图片、mockup 或 HTML 上传到 Stitch 项目。
Build 组负责把设计往代码侧带:
•react-components:把 Stitch 屏幕转换成 React 组件系统,并做设计 token 一致性验证。
•react-native:把 Stitch HTML 设计转换成 React Native 组件。
•remotion:从 Stitch 项目生成 walkthrough video。
•shadcn-ui:给 shadcn/ui 集成和应用构建提供指导。
•react-vite-dashboard:把 Stitch 屏幕转换成 React + Vite 仪表盘,结合 TanStack Query、DESIGN.md tokens 和 Web3 读取模式。
Utilities 组更像辅助工具:
•design-md:分析 Stitch 项目并生成 DESIGN.md。
•enhance-prompt:把模糊 UI 想法改写成更适合 Stitch 的 prompt。
•stitch-loop:从单个 prompt 生成多页网站,并加入自动验证。
•taste-design:生成约束更强的 DESIGN.md,用于压住泛化、普通、廉价的 UI 输出。
Stitch Skills 的重点不在单个技能多聪明。它真正处理的是资产状态:设计可以被 agent 读取、上传、同步、转换和再生成。过去设计稿和代码经常隔着一层手工翻译;这里的方向是让 agent 在设计工具、设计系统、前端代码之间来回跑,而且每一步都有脚本和 skill 兜住。
这也解释了为什么 Stitch MCP 是前提。没有 MCP,agent 很容易只是在本地"想象"设计;有了 MCP,它能拿到真实项目、上传真实资产、同步真实屏幕。审美在这里不再只是输出风格,而是工作流里的状态管理问题。


Matt Pocock 这套 skills 没有把自己包装成设计工具。它的主题是"Skills For Real Engineers":给真实工程工作使用,不是 vibe coding。
这套技能的观点很清楚:GSD、BMAD、Spec-Kit 这类流程试图托管整个软件开发过程,但托管得越多,人类越容易失去控制。Matt 的选择相反:把技能做小,容易改,能组合,适配任何模型。
它解决的几个问题都很工程化:
•agent 没理解需求:用 /grill-me 或 /grill-with-docs 让 agent 在动手前追问细节,逼近真实目标。
•agent 太啰嗦:通过共享语言和 CONTEXT.md 降低项目术语解释成本,让 agent 少绕圈。
•代码跑不起来:用 /tdd、/diagnosing-bugs 这类技能建立反馈回路,而不是让模型凭感觉改。
•代码库变成泥球:用 /to-spec、/improve-codebase-architecture、codebase-design 等技能,把模块边界、接口深度和架构债务纳入日常工作。
这部分和"反 AI 味设计"的关系,其实比看起来更近。UI 的 AI 味,是模型在视觉层面掉进统计默认值。代码的 AI 味,是模型在工程层面掉进"看似合理但没有反馈"的默认值。前者长得像模板,后者跑起来像负债。
Matt Pocock Skills 的价值在于提醒我们:skills 不只是 prompt 包。一个好的 skill 应该保存判断、约束行为、制造反馈,并且允许人类随时接管。它不需要替你拥有整个流程,但必须在关键节点把模型拉回现实。

这三个项目都在回答同一个问题:当 agent 可以批量生成内容时,人类的判断应该被放在哪里?
Hallmark 的答案是:放进设计规则和反模式测试里。它先管住"长得像 AI"这件事,避免输出被默认模板吞掉。
Stitch Skills 的答案是:放进工具链和真实资产流转里。设计不是一次性图片,而是可生成、可上传、可转换、可同步的工作对象。
Matt Pocock Skills 的答案是:放进工程工作协议里。不要让 agent 接管一切,要把提问、术语、测试、调试、架构审查拆成可重复的小技能。
如果按架构模式区分,大概可以这样看:
•Hallmark 是"审美守门人"模式:输入 brief 或已有页面,输出带反模式检查的 UI 或审计意见。
•Stitch Skills 是"设计工具链"模式:输入代码、图片、prompt 或 Stitch 项目,输出设计稿、组件、DESIGN.md 或视频。
•Matt Pocock Skills 是"工程协议库"模式:输入任务、问题或代码库状态,输出提问、规格、测试回路、调试路径和架构建议。
它们的共同点是都不满足于"给模型一段提示词"。它们都在做经验拆解:把某种人的判断变成 agent 可以执行、可以复用、可以被检查的步骤。不同点在于经验的类型:Hallmark 是视觉判断,Stitch 是设计生产,Matt 是工程纪律。

如果把这三种思路揉成一个实际流程,大概会变成这样:
1先读取项目上下文,搞清楚用户、品牌、页面目标和技术约束。
2再选择审美路径:是新建页面、审计页面、重设计,还是从参考图中提取风格 DNA。
3生成设计产物,可能是 HTML、组件、DESIGN.md,也可能是 Stitch 项目里的屏幕。
4执行禁忌清单,检查假指标、泛蓝紫、模板卡片、移动端、字体和信息密度。
5做视觉验收,不只看文件是否存在,还要真实打开图片或页面,看文字、比例、裁切和小屏可读性。
6把反馈落回代码、文档、测试或下一轮生成,让 agent 不是每次从零猜。
第 5 步很容易被忽略。很多内容链路失败,并不是模型不会画架构图,而是没人真的打开看一眼:字糊没糊,节点重没重叠,图片有没有被裁掉,SVG 转 PNG 后有没有变形。审美进入 agent 工具链后,验收也得进入工具链。
以前我们可以忍受一点 AI 味,因为 AI 只是辅助起草。现在不一样了。agent 正在直接生成网页、改组件、写文档、迁移设计系统、提交 PR。它参与的链路越靠近交付,"差不多能看"的账就越贵。
反 AI 味设计的本质,不是讨厌 AI,而是讨厌默认值。默认值最省 token,也最容易规模化;但产品、品牌和工程质量,恰好经常死在默认值里。
我更看好这种方向:让 agent 继续快,但把人的判断变成它必须经过的门。Hallmark 把视觉反模式写成门,Stitch Skills 把设计资产流转写成门,Matt Pocock Skills 把工程反馈写成门。门多了,速度会慢一点,但产物会更像有人负责。
这可能就是下一阶段 agent 工具链的变化:不是让模型显得更聪明,而是让它更少胡来。
本文由山行整理自:Hallmark[1]、Stitch Skills[2]、Matt Pocock Skills[3],如果对您有帮助,请帮忙点赞、关注、收藏,谢谢~
参考链接
[1] Hallmark: https://github.com/Nutlope/hallmark
[2] Stitch Skills: https://github.com/google-labs-code/stitch-skills
[3] Matt Pocock Skills: https://github.com/mattpocock/skills