Hue Skill：让 Claude Code 和 Codex 生成更像“你的品牌”的界面

AI 写界面这件事，最常见的问题不是“做不出来”，而是做出来的东西太像模板。

组件没坏，排版也整齐，甚至配色都不算难看，但你一眼就能看出来：这不是某个产品自己的气质，而是模型默认审美拼出来的“通用型 UI”。如果你已经在用 Claude Code 或 Codex 写页面，这个问题大概率见过很多次。

hue 想解决的，就是这个环节。

它不是一个再造一套组件库的框架，而是一个给 AI 编程助手补上“品牌视觉上下文”的 Skill。你给它一个 URL、品牌名，甚至一张截图，它会去归纳这个品牌的色彩、排版、间距、组件风格和整体气质，然后生成一套新的设计语言 Skill。后续再让 AI 写页面时，产出的界面就不再是“像某个 SaaS 模板”，而是尽量贴近这个品牌本身。

它到底是什么

按照 hue 仓库首页的描述，它是一个开源 Skill，可以“从 URL、名称或截图学习任意品牌，并把它变成一套完整设计系统”。它同时面向 Claude Code 和 Codex，安装一次之后，后续由 AI 生成的组件和页面会尽量保持同一套品牌语言。

官网首页的定位更直接：“No more generic UI with Claude or Codex.” 这句话其实已经把问题说透了。hue 不是为了让 AI 多会一点 CSS，而是为了让 AI 少一点默认味道。

从公开说明来看，hue 生成的不是几条零散的颜色建议，而是一整套可复用的设计语言。仓库 README 明确列出的内容包括：

color tokens
typography
spacing
components
light + dark mode
hero stage recipes
icon kit selection

这意味着它更像一个“设计系统生成器”，而不是一个简单的提示词模板。

Hue 怎么工作

官网把流程压缩成了三步：

Drop a URL or screenshot
hue generates your custom design skill
Every UI your AI builds matches

翻成更容易理解的话，大致就是：

你先给 hue 一个品牌入口，可以是官网 URL，也可以是截图。
它分析品牌已有的视觉语言，整理成一个 AI 可持续使用的设计 Skill。
之后你继续让 Claude Code 或 Codex 生成页面、组件、营销站或应用界面时，这套 Skill 会成为默认设计约束。

如果看它的 SKILL.md，这个过程其实做得比想象中更细。它并不只看首页配色，而是会尝试分析品牌的：

主色、辅助色和强调色
字体与字号层级
间距密度
按钮、卡片、输入框等组件形态
圆角、阴影、表面材质和背景氛围
图标风格
Hero 区域的视觉构图

换句话说，hue 的目标不是“模仿一个页面”，而是提炼一套能够持续出片、并且风格一致的系统。

graph TD
    A[输入品牌线索
URL / 名称 / 截图] --> B[分析视觉语言]
    B --> C[生成 design skill]
    C --> D[约束后续 AI 产出的页面与组件]
    D --> E[得到更一致的品牌化 UI]

它输出的不是“灵感”，而是可检查的文件

这一点是我觉得 hue 比较有意思的地方。

仓库里没有把结果描述成一种抽象感觉，而是直接给了示例产物。README 里提到，examples/ 目录目前有 17 个品牌样例，其中 16 个是一次性生成的虚构品牌，1 个是真实案例，也就是 meadow，对应 mymind-design。

这些样例不是只有一张截图。根据仓库说明，每个样例至少会带上：

design-model.yaml
landing-page.html

另外还有两个额外说明：

ridge 和 stint 还包含 app-screen.html
halcyon 提供了完整的 component-library.html

官网还补了一条很关键的信息：展示区里的那套系统只是生成结果的一部分，8 个自动生成文件中的一个是完整、可浏览的组件库，并且包含 light / dark mode。这就让 hue 的定位更清楚了，它不是只服务于“做一张 Landing Page”，而是试图把品牌语言沉淀成后续能持续复用的资产。

为什么这种 Skill 值得关注

过去我们聊“AI 生成前端”，很容易把注意力放在代码质量、响应式、动效或者组件封装上。但品牌一致性其实是另一个更隐蔽、也更费时间的问题。

很多团队不是不会做页面，而是很难让 AI 在不同会话、不同任务里持续做出像同一个产品团队做出来的东西。今天写官网，明天写登录页，后天做 pricing section，如果每次都靠重新描述一遍“我们想要什么风格”，成本并不低，而且极不稳定。

hue 想做的，就是把这件事从临时提示词提升成一套可安装、可复用、可持续约束输出的 Skill。

仓库 README 里有一句描述我很认同：它生成的设计语言需要“足够有主见”，这样即使是两次不同的会话，最后产出的结果也仍然会保持视觉一致。这个判断其实很重要，因为真正有价值的设计系统，不是元素多，而是约束清晰。

它适合谁

如果你只是偶尔让 AI 帮你搭个页面，hue 不一定是刚需。但下面几类人，会比较明显地感受到它的价值：

已经在用 Claude Code 或 Codex 做前端原型的人
需要不断生成营销页、产品页、组件页面的独立开发者
想把品牌视觉语言“固定下来”的小团队
不想每次都重新写一大段设计提示词的人

尤其是最后一种情况。很多人以为自己缺的是更强的模型，实际上缺的是稳定的设计输入。hue 本质上就是把这种输入结构化。

怎么安装和使用

hue 的安装方式很直接。仓库给出的方式是直接克隆到对应的 Skill 目录里。

Claude Code：

1
git clone https://github.com/dominikmartn/hue ~/.claude/skills/hue

Codex：

1
git clone https://github.com/dominikmartn/hue ~/.agents/skills/hue

如果你使用兼容 CLI 安装器的 Codex 路径，也可以使用：

1
git clone https://github.com/dominikmartn/hue "${CODEX_HOME:-$HOME/.codex}/skills/hue"

安装之后，按照 README 里的示例，你可以直接对助手说：

make a design skill from cursor.com
create a design language inspired by raycast
generate a hue skill from this screenshot

这种使用方式有一个很大的优点：它并没有要求你切换工作流。你还是像平时那样和 Claude Code 或 Codex 对话，只是现在多了一层品牌设计系统的生成和约束能力。

一个更值得看的角度：Hue 在把“设计判断”前移

很多 AI UI 工具现在做的是“先生成，再挑一版顺眼的”。hue 走的是另一条路：先把设计判断做出来，再让生成落地。

这两个思路差别很大。

前者更像无限抽卡，直到抽到顺眼的一版；后者则是在生成之前，先把品牌色、构图方式、组件性格、图标倾向、明暗模式这些“会影响后续所有页面”的规则沉淀下来。这样后面再生成任意页面，至少不会每次都从零开始漂移。

从这个角度看，hue 最有价值的不是那几个示例页面，而是它试图把“审美偏好”变成一种可复用、可传递、可执行的设计规范。

我对 Hue 的看法

如果你现在已经明显感受到 AI 生成页面越来越快，但品牌感越来越稀薄，那么 hue 是一个很值得研究的项目。它不一定能一步到位替代设计师，但它确实提供了一种更合理的中间层：先把品牌视觉语言结构化，再交给 AI 批量生成。

更现实一点说，hue 也提醒了一件事：未来让 AI 做前端，真正拉开差距的可能不是“谁会写 Tailwind”，而是谁先把自己的产品语言整理成模型能长期复用的输入。

截至 2026 年 4 月 23 日，官网首页展示的版本是 1.1。如果你正好在折腾 AI 设计工作流，这个项目值得亲自装一下，看看它生成出来的 Skill 能不能把你的界面从“标准 AI 风格”往前再推一步。