前端设计 Skill 的坑，我替你们踩了一遍

Taste-Skill、HyperAgent 网格 Skill、Hallmark 实战经验分享

前几天我让 Claude 用 Taste-Skill 给我做一个 B2B SaaS landing page。

规则都读了，brief 也写了，出来的页面长这样：居中大标题、一张抽象渐变插画、下面三个等宽 feature card，再来一个蓝色 CTA。你闭着眼都能猜出来。

我盯着它看了十秒钟，脑子里只有一个问题：

「我不是已经告诉它别这么做吗？」

这就是写 Skill 最难受的地方。规则写再多，模型还是能绕回训练分布里最熟的那套。Taste-Skill 不是没用，它让结果好了不少。但复杂任务一上，它就像一个很有审美的总监，把所有判断都塞进一次生成里。

brief、结构、字体、颜色、动效、响应式、验收，全压在一个大脑袋里。

页面不对劲的时候，你根本不知道骂哪一层。是 brief 理解偏了？结构选错了？tokens 互相打架？还是移动端根本就没验？

后来我又去啃 HyperAgent 那套思路。它不把写代码当成单人任务，而是拆成 Planner、Navigator、Code Editor、Executor 几个角色。有人定计划，有人找代码，有人改，有人跑验证。

我突然想：

前端设计 Skill，是不是也可以拆成一个「网格」？

不是 UI 网格，是任务网格。一格读 brief，一格读项目上下文，一格选结构，一格定 tokens，一格做组件状态，一格跑响应式，一格做视觉验收。每一格只负责一个稳定决策，错了就重跑那一格。

这篇文章要说的就是这件事：

Skill 真正难的，不是写规则，而是把规则拆成能被 Agent 稳定调用、定位、验证和复盘的工程网格。

Skill 不是提示词仓库，是给 Agent 装上任务操作系统

很多人第一次写 Skill，会把它写成 prompt 收藏夹。

比如这样：

# Frontend Taste

你是顶级设计师。
请做高级、克制、有审美的页面。
不要俗气，不要模板化，不要 AI 感。
要有动效，要响应式，要好看。

这话不能说完全没用。但它解决不了生产问题。

「高级」「克制」「不模板化」都不是可执行对象。模型每次读到这些词，只能在训练分布里猜。猜对了像灵感，猜错了就是一坨很自信的模板。

一个能长期用的 Skill，至少要回答四个工程问题：

Anthropic 官方 Skills 文档里反复说的也是这个：Skill 不是一句提示词，而是一组可以动态加载的说明、脚本和资源。SKILL.md 描述触发条件和执行方式，必要时再加载 templates、scripts、references。

换成人话就是：

别把所有经验都塞进一次聊天。把经验拆成可以被加载、被复用、被验证的文件。

Taste-Skill 先解决第一层问题：把「审美口味」变成约束

模型默认太油。

它会下意识走向几个高频模板：AI 紫蓝渐变、居中 hero、三个等宽 feature card、玻璃拟态乱用、Inter + slate 色系、bento grid 留空格、每个 section 都 fade-up。

Taste-Skill 有价值的地方，是把这些「我觉得不行」变成了可执行约束。

比如它不是说「别做烂 bento」，而是把 bento 拆成几个硬要求：

- bento grid 有几个内容，就只放几个 cell
- 3 个内容可以做 1+2 或 2+1，不能硬凑 6 格
- 不能出现中间空 cell
- 多 cell 网格里至少 2 到 3 个 cell 有视觉差异
- 不要连续堆 6 个白底文字卡

这就比「高级一点」强太多。因为它约束的是结构，不是情绪。

同样，Taste-Skill 对 brief 的处理也很关键。一个页面到底该不该动效重？该不该像 Linear？该不该用 Material？这不是模型自由发挥的问题，而是受众和场景决定的。

它会先做一个 Design Read：

Reading this as: B2B SaaS landing for technical buyers,
with a restrained product-marketing language,
leaning toward Tailwind utilities + Geist + restrained motion.

这句话看着普通，但很有工程意义。它把「我要做什么」冻结成一个中间产物。后面如果页面跑偏，我们至少知道该回滚哪一层：是 brief 判断错了，不是 CSS 写错了。

但 Taste-Skill 也有坑：规则一多，模型会把它当成一锅汤

Taste-Skill 这类长规则也有一个明显问题。

它越写越像「超长代码规范」。字体、颜色、布局、动效、响应式、依赖、组件、图片、hero、bento、CTA、禁用项，全都写在一起。

短任务还好。一旦任务变复杂，模型容易出现三种症状。

第一，局部规则被全局口味吞掉。

明明项目已有设计系统，它还是想重新挑字体、重新配色，因为 skill 里设计口味太强。

第二，规则互相打架时没人仲裁。

比如「结构要有变化」和「产品工具要克制」，到底谁优先？如果没有分层，模型只能现场猜。

第三，验收不可定位。

页面不对劲时，你不知道是 layout 层错了，还是 visual 层错了，还是 responsiveness 层没跑。

我后来给这类 Skill 加了一条内部日志，类似这样：

[skill.trace]
brief_read: B2B SaaS landing / technical buyer / utilitarian
structure_pick: workbench, not centered hero
token_pick: neutral + one accent, no purple gradient
motion_stance: restrained
mobile_check: pending
visual_check: pending

这不是形式主义。它的价值是把一次「感觉不好」的返工，拆成几个可追踪的节点。

你不需要让模型重新生成整页。你可以只说：

保留 token 和组件状态，重跑 structure_pick。
上一版太像通用 SaaS hero，改成 workbench walkthrough。

这就是 Skill 从 prompt 走向工程的第一步。

HyperAgent 的启发：别让一个 Skill 同时当产品、设计、工程、测试

HyperAgent 论文和仓库里的一个核心思路，是把软件工程任务拆给多个角色。

它不是让一个 Agent 从头到尾「凭感觉写代码」，而是把流程拆成：

• Planner：理解任务，拆计划
• Navigator：在代码库里找相关上下文
• Code Editor：执行具体修改
• Executor：运行命令、测试和反馈

这套东西放到前端 Skill 里，很容易得到一个「网格 Skill」的设计。

我说的网格，不是 UI 网格。是任务网格。每一格只负责一个稳定问题。

Design Skill Grid

Brief Cell          读用户需求、受众、动作目标
Context Cell        读项目代码、设计系统、已有约束
Structure Cell      选择页面宏结构，不直接写 CSS
Token Cell          定颜色、字体、间距、动效基线
Component Cell      写组件和状态
Responsive Cell     跑移动端宽度验收
Visual QA Cell      找 AI 味、错位、过度装饰
Asset Cell          管图片、截图、封面、导出文件

看起来像把事情复杂化了。但复杂项目里，恰好相反。

它把复杂度从「模型脑子里的一团糊」搬到了「文件和流程里的多个格子」。

一个网格 Skill 的最小目录可以长这样：

frontend-design-grid/
  SKILL.md
  cells/
    brief.md
    context.md
    structure.md
    tokens.md
    components.md
    responsive.md
    visual-qa.md
  scripts/
    check-mobile.mjs
    contrast-check.mjs
  references/
    anti-patterns.md
    macrostructures.md
    component-states.md

SKILL.md 不再塞满所有细节。它只做三件事：

---
name: frontend-design-grid
description: 用户要求 landing、portfolio、redesign 或视觉重构时触发。用于把前端设计任务拆成 brief、context、structure、tokens、components、responsive、visual QA 多格执行。
---

# Frontend Design Grid

执行顺序：
1. 先运行 Brief Cell，冻结设计判断
2. 再运行 Context Cell，读取项目现有约束
3. Structure 和 Token 必须先于 Component
4. Responsive 和 Visual QA 是交付前强制闸门

不要在未读取项目文件时覆盖已有设计系统。
不要把 invented metrics、假截图、假浏览器 chrome 写进页面。

这个结构最大的好处，是上下文加载变轻。

用户只是让你修一个按钮，就不需要加载整套 landing page 宏结构。用户要求 redesign，就必须先跑 context 和 structure。用户说「移动端崩了」，只加载 responsive cell 就够了。

Hallmark 的狠处：它把审美变成「闸门」，不是建议

Hallmark 给我的另一个启发，是它不太相信模型自觉。

它不会只说「注意不要 AI 味」。它会把一些反 AI 味的经验写成硬闸门。

比如：

• 先做 pre-flight，读取项目已有字体、颜色、框架和 motion 依赖
• 不要发明不存在的指标、客户、logo、案例
• tokens 一旦选定，颜色和字体不能中途即兴
• 禁止手搓假浏览器栏、假终端框、假 IDE chrome
• 移动端必须验 320、375、414、768 四个宽度
• 输出 CSS 顶部要盖章，记录 macrostructure、tone、anchor hue

这套东西的工程味非常重。它不是在教模型「更有品味」，它在限制模型的坏习惯。

我最喜欢的是它的 stamp 机制。

/* Hallmark · macrostructure: Workbench · tone: technical · anchor hue: cobalt */

这行注释看起来像装饰，其实是一个很实用的元数据。下一次再运行 Hallmark，它可以读这个 stamp，知道上一版用了什么结构，然后避免重复。

这就比「请多样化一点」靠谱。

「多样化」是愿望。stamp 是状态。状态能被读取，才能被治理。

真正要沉淀的不是口味，而是这五类资产

我现在看一个 Skill 值不值得长期保留，基本不看它开头写得多燃。我看它有没有五类资产。

这里面最容易被忽略的是 scripts 和 memory。

很多人写 Skill，只写 instructions。但 instructions 只能提高生成概率，不能提供验收闭环。

比如响应式检查，靠模型肉眼说「已适配移动端」没意义。至少应该有一个脚本能跑：

const widths = [320, 375, 414, 768];

for (const width of widths) {
await page.setViewportSize({ width, height: 900 });
await page.goto(url);

const overflow = await page.evaluate(() => {
    returndocument.documentElement.scrollWidth > window.innerWidth;
  });

if (overflow) {
    thrownewError(`horizontal overflow at ${width}px`);
  }
}

这段东西不复杂。但它把「移动端别崩」从一句愿望变成了一个失败条件。失败条件越具体，Agent 越能修。

一个可落地的网格 Skill，应该这样跑

如果让我现在做一个设计类 Skill，我不会一上来写 2000 行审美规范。我会先写最小闭环。

第一格，Brief Cell 只负责冻结判断

输出不是页面。输出是一段可复核的判断。

brief:
  page_kind:"B2B SaaS landing"
audience:"technical buyer"
primary_action:"book demo"
tone:"utilitarian, precise"
avoid:
    -"consumer playful"
    -"AI purple gradient"
    -"three equal feature cards"

这一步如果错了，后面都别写。因为写得越快，错得越完整。

第二格，Context Cell 先读项目，不急着设计

Hallmark 在这里做得很硬。它要求已有项目必须先读 package.json、全局 CSS、tokens、框架信号、motion 依赖。

我建议前端 Skill 也这么做。

Pre-flight findings:
· Framework: Next.js app router
· Styling: Tailwind v4
· Font: Geist via next/font
· Palette: existing CSS variables in globals.css
· Motion: no motion library detected

Preserve: font stack, palette, spacing scale
Introduce: structure discipline, responsive QA, component states

这一步的意义是防止 Skill 变成推土机。再好的设计规则，也不能上来覆盖项目已有系统。

第三格，Structure Cell 只决定页面形状

这格不要写 CSS。它只回答一个问题：这页应该是什么结构？

是 Workbench？Long Document？Bento Grid？Catalogue？还是 Split Studio？

这里可以借 Hallmark 的思路：结构多样性优先于颜色多样性。因为 AI 味最重的地方，往往不是颜色，而是节奏。同样的 hero -> feature -> CTA -> footer，换 100 个配色都还是模板。

第四格，Token Cell 锁住视觉变量

颜色、字体、间距、圆角、动效曲线，一旦确定就别乱飞。

坏例子：

.hero { background: #0f172a; }
.cta { background: #7c3aed; }
.card:hover { box-shadow: 0 20px 50px rgba(59,130,246,.25); }

每个地方都在即兴。

好一点的写法是：

:root {
--color-paper: #f8fafc;
--color-ink: #0f172a;
--color-accent: #0f766e;
--radius-card: 8px;
--motion-fast: 160ms;
}

.cta {
background: var(--color-accent);
color: white;
}

这不是为了优雅。是为了后面能统一改、统一查、统一验收。

第五格，QA Cell 必须能失败

一个没有失败条件的 Skill，最后都会变成「生成完了就算成功」。

前端设计至少要有这些失败条件：

• 320/375/414/768 任一宽度出现横向滚动，失败
• CTA 文本换行导致按钮破相，失败
• 图片格子用裸 1fr 导致溢出，失败
• invented metrics 出现在页面里，失败
• 重复使用上一版 macrostructure，失败
• 手搓假浏览器、假终端、假 IDE chrome，失败

Skill 要能说「不行」。否则它只是一个更会夸自己的 prompt。

我踩出来的几个边界

第一，Skill 不能替代产品判断。

再好的 Taste-Skill，也不能自动知道这个页面到底卖给 CTO、采购、开发者还是普通用户。brief 不清楚时，别硬生成。

第二，网格不能拆得太碎。

如果每个按钮、每个标题、每个图标都拆成一个 cell，Agent 会被流程拖死。我的经验是：一格必须对应一个稳定决策边界。

比如 brief、context、structure、tokens、responsive，这些值得拆。「按钮阴影怎么写」不值得单独拆。

第三，Hallmark 这种强约束 Skill 很适合 redesign，但别让它压过已有设计系统。

它的 pre-flight 很关键。如果项目已经有完整 design.md，那后续页面要服从系统一致性，而不是每页都追求新鲜。

第四，越是审美类 Skill，越要把「主观判断」后移。

先用可验证条件筛掉明显错误：

• 文本有没有溢出
• 移动端有没有横向滚动
• 色彩有没有乱飞
• 指标有没有编造
• 结构有没有重复

这些过了，再讨论「好不好看」。

工程上怎么落地

如果你也想把自己的 Skill 从 prompt 升级成工程资产，我建议按这个顺序来。

1. 先做一个最小 SKILL.md

不要一开始写百科。只写触发条件、执行顺序和禁止事项。

---
name: frontend-design-grid
description: 用户要求 landing、portfolio、redesign、视觉升级时触发。用于把设计任务拆成可验证的工程网格。
---

# Frontend Design Grid

必须顺序：
Brief -> Context -> Structure -> Tokens -> Component -> Responsive -> Visual QA

如果是已有项目，先读代码和设计系统，不要覆盖。
如果无法验证移动端，明确说明没有跑验证。

2. 把高频规则移到 references/

比如：

references/
  anti-patterns.md
  macrostructures.md
  responsive.md
  component-states.md

SKILL.md 不要背所有规则。它只在需要时告诉 Agent 读哪个文件。这就是渐进式加载。

3. 把可验证动作移到 scripts/

比如：

scripts/
  check-mobile.mjs
  check-contrast.mjs
  screenshot.mjs

不要让模型凭嘴说验收完成。能跑脚本就跑脚本。不能跑，就在最终输出里说清楚。

4. 给输出加 stamp

stamp 不一定只用于 CSS。文章、设计稿、配置、组件都可以有。

Design Grid Stamp:
brief=B2B SaaS
structure=Workbench
tokens=neutral-teal
motion=restrained
verified=320/375/414/768

下一轮 Agent 看到这个，就知道不要从零开始猜。

5. 每次返工只重跑一格

这是网格 Skill 最大的价值。不要动不动「重新生成一个更高级版本」。

你要像改代码一样改 Skill 输出：

保留 Brief、Context、Tokens。
只重跑 Structure Cell。
原因：上一版结构仍然像通用 SaaS，改成 Workbench walkthrough。

这个动作一旦固定下来，AI 设计就从抽奖变成了工程迭代。

最后

为什么同样是设计 Skill，有的越用越稳，有的用几次就开始发散？

不是因为某个 Skill 写了更多形容词。恰好相反。

真正稳定的 Skill，都在减少模型自由发挥的关键路径。

Taste-Skill 先把审美口味变成结构约束。HyperAgent 式网格把复杂任务拆成多个可定位角色。Hallmark 再用闸门、stamp、pre-flight 和移动端验收，把「反 AI 味」变成失败条件。

所以我现在不太问一个 Skill 「写得漂不漂亮」。我会问它四个问题——说实话，能答上来一个的都不多：

它能不能被稳定触发？

它能不能少加载一点上下文？

它能不能定位哪一格错了？

它能不能验证自己没翻车？

如果这四个问题答不上来，它就还不是工程资产。

它只是一个更长的 prompt。

参考资料

• Anthropic Claude Code Skills 文档：https://docs.anthropic.com/en/docs/claude-code/skills
• Anthropic Skills 示例仓库：https://github.com/anthropics/skills
• HyperAgent 论文与仓库：https://github.com/FSoft-AI4Code/HyperAgent