<!-- title: 官方审美件拆到行：提炼七个写法模式 -->

## 概述

Skills 生态走到第九个月，写 Skill 的人分成了两派：一派把 SKILL.md 当 README 写，堆背景、堆口号；另一派把它当提示词工程写，每一行都在改模型行为。本期（Round 8）把镜头对准第二派的教科书——官方审美件 frontend-design。它是 anthropics/skills 仓库里被模仿最多的纯文本件：没有一行脚本、没有一个子代理，全靠一页 Markdown 管住了“AI 味儿”这个玄学问题。本文先把它拆到段落级，提炼出七个可以直接抄的写法模式，再手把手带你用这七个模式写出自己的第一件 Skill。

---

## 一、为什么是它：一件“三无”件的常青史

先交代选件逻辑。本期主题是设计模式提炼，所以选件标准不是“最新”，而是“最值得抄”。

frontend-design 符合三条：

1. **官方出品，全渠道预装**。它住在 anthropics/skills 仓库里，同时作为官方插件市场的内置件随 Claude Code 分发。你在本栏目近几轮拆过的官方 docx、PDF、PPT 三件之外，它是官方件里最特殊的一类——「纯提示词件」。
2. **被模仿最多**。在 skillsmp.com、mcpservers.org/agent-skills 这类聚合站上，官方件常年占据热门位，而社区仿写件里“审美指导”是重灾区——大量件照抄了它的结构。一个被抄得最多的原件，就是最好的模式样本。
3. **本栏目旧账可查**。5 月扫描时（本栏目存档：349+ 公开仓库、127,000+ 索引件的口径），它在跨领域评测中综合 4.35 分，仅次于 skill-creator。四个月后它没过时，反而因为“AI 味儿”依然是社区第一大痛点，价值更突出了。

它的“三无”：无脚本、无 MCP、无子代理。整个 Skill 就是一个 SKILL.md。这恰恰是它值得拆的原因——**没有任何工程外壳替它兜底，写法本身就是全部战斗力**。你写第一件 Skill 时面对的正是同样的局面：一页 Markdown，凭什么让模型听话。

### 评测对比表

对比对象是官方仓库里同为“范文级”的四件（评分为本栏目编辑评星，1-5 星；综合分按维度权重折算）：

| Skill | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15%（高=易） | 社区活跃度 15% | 综合得分 |
|-------|------|------|------|------|------|------|
| frontend-design | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★☆ | ★★★★☆ | **4.55** |
| skill-creator | ★★★★★ | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★★☆ | **4.48** |
| canvas-design | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ | ★★★★☆ | **3.95** |
| brand-guidelines | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | **3.83** |
| doc-coauthoring | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | **3.70** |

---

## 二、SKILL.md 拆到段：一页纸的骨架

frontend-design 的 SKILL.md 结构可以切成六段。逐段看它每一行在干什么（引文为节选大意）。

### 第 1 段：门牌（frontmatter）

```yaml
---
name: frontend-design
description: 创建有辨识度的、生产级前端界面……当用户要求构建 UI 组件、
页面或前端应用时使用……（大意）
---
```

注意 description 的写法：**前半句说它是干什么的，后半句说什么时候该用它**。这不是简介，是路由规则。Skill 的加载机制是：所有已安装件的 description 常驻上下文，模型根据用户输入判断哪个件该被激活，命中后才把正文整页注入。所以 description 里那半句“Use when…”决定了你的件在几百个候选里会不会被选中。社区空货架件（本栏目往期审计过的那批）最常见死法就是门牌只写“这是一个帮助你的工具”——模型无从判断何时调用。

### 第 2 段：开篇定调

正文第一段直接给目标：要做出“有辨识度、达到生产级”的界面，并且点名要避开千篇一律的 AI 生成感。这一段的作用是**先立验收标准再派活**——模型后面做的每个决定都对着这句话校准。对照反面：多数社区件开篇是一段产品愿景，读完不知道验收时看什么。

### 第 3 段：一次选择（方向承诺）

这是全文最值钱的一段。它要求模型在写任何代码之前，先确定一个明确的美学方向——字体、色彩、布局基调——然后**承诺到底**。原话大意是：选一个大胆的方向，把一种想法推到极致，而不是小心翼翼地各来一点。

这一行解决的是大模型输出的一个经典病灶：没有倾向性。你问它“做个落地页”，它会给你一个四平八稳的中间态。强制“先选边”，等于把一个开放式问题切成封闭式决策，输出立刻从“正确”变成“有态度”。

### 第 4 段：四个抓手

方向定了之后，它给出四个可操作的执行面：字体、色彩、布局、动效。每一面都给到“具体名词”级别——选有个性的展示字体、用 CSS 变量管理色板、动效要有目的而不滥用手。这里的功力在于**把抽象形容词全部翻译成可执行名词**：“高级感”没法执行，但“建立 3 级字号层级、主色只允许一个”可以执行。

### 第 5 段：负面清单（全文传播最广的一段）

它列了一份“什么会让设计一眼假”的禁令，大意包括：不要用 Inter、Roboto、Arial、system-ui 当主字体；不要紫蓝渐变配白底；不要发光标题；不要等宽三栏卡片阵列；不要拿 emoji 当图标。

这份清单为什么有效？因为它是**针对模型默认值的精确打击**。模型未经约束时的输出高度趋同——这份禁令几乎逐条对应模型的“肌肉记忆”。写 Skill 的一条铁律藏在背后：**你最该写进文件的，是你已经在对话里纠正过模型三遍的东西**。负面清单不是设计出来的，是从血泪里抄出来的。

### 第 6 段：执行细则与收尾

最后是落地约束：色彩进 CSS 变量、动效克制、整体质量底线。收尾把责任压回模型自身——按前面的标准自查一遍再交付。

整页读完，你会发现它的行文密度极高：几乎没有一句“了解背景介绍”，每一句要么在改变模型的默认选择，要么在给出可执行的判断标准。

```mermaid
flowchart TD
    A[用户输入一句话] --> B{description 是否命中}
    B -->|命中| C[SKILL.md 正文注入上下文]
    B -->|未命中| D[继续当普通对话处理]
    C --> E[开篇定调 立验收标准]
    E --> F[先选边 承诺美学方向]
    F --> G[四个抓手 落到名词级]
    G --> H[负面清单拦截默认值]
    H --> I[按标准自查后交付]
```

---

## 三、提炼：七个可抄的写法模式

把上面的拆解压成七个模式。前两个管门牌，中间三个管正文，后两个管生命周期。

```mermaid
mindmap
  root((七个写法模式))
    门牌层
      写触发不写简介
      给边界留一句
    正文层
      禁令先行
      先选边再动手
      形容词换成名词
    生命周期层
      一件只干一事
      纠正过三遍的才入库
```

**模式一：写触发，不写简介。** description 是给模型看的路由器，不是给人看的产品介绍。句式固定：「做什么……当用户要求 X / 提到 Y 时使用」。写完自测：把 description 单独拿出来，你能不能判断十句用户话术里哪几句该命中。

**模式二：给边界留一句。** 官方件会在门牌或开头标明不适用场景（大意：简单脚本或纯后端任务不需要它）。边界句能显著降低误触发——被不相关任务激活的 Skill 会污染整个会话。

**模式三：禁令先行。** 与其描述理想态，不如先列模型默认值黑名单。方法是把你最近十次对话里重复出现的纠正搬进文件，写成“不要 X”清单。负面清单比正面描述更能改变行为，因为模型对“避免什么”的遵循度显著更高。

**模式四：先选边再动手。** 在正文里强制一个前置决策点：先承诺方向，再开始产出。适用于一切“输出容易和稀泥”的任务——文案定调、架构选型、命名风格，都吃这一套。

**模式五：形容词换成名词。** 每写完一段自检：这句话模型能直接执行吗？“写得专业一点”不行；“标题不超过两行、每段不超过四句”行。官方件通篇找不到一个无法执行的形容词。

**模式六：一件只干一事。** frontend-design 只管审美，不管性能优化、不管可访问性审计。范围越窄，description 越容易写准，触发越稳。想扩功能，正确做法是新开一件，而不是往正文里塞章节——这是官方 docx、pdf、pptx 三件各自独立的原因。

**模式七：纠正过三遍的才入库。** Skill 是品味的固化，不是想法的收藏。判断一条内容值不值得写进 SKILL.md 的标准：它是否曾在对话里被你反复纠正过。第一次纠正写在对话里，第三次纠正写进文件。

---

## 四、动手：30 分钟写你的第一件

用七个模式写一个真实需求——「中文技术文风审校」。以下模板可直接复制（应用到七个模式的位置已标注）。

```bash
# 第一步：建目录（个人级，全项目可用）
mkdir -p ~/.claude/skills/zh-tech-style
```

然后创建 `~/.claude/skills/zh-tech-style/SKILL.md`：

```markdown
---
name: zh-tech-style
description: 按团队文风规范审校中文技术文章，改口语化、翻译腔和营销腔。
当用户要求审校、润色、检查中文文章或文档时使用。英文内容或代码注释不适用。
---

## 目标
产出像资深工程师写的中文：句子短、术语准、零营销腔。
验收标准：朗读一遍不换气不过来，删掉任何一句不影响信息量就该删。

## 禁止（常见 AI 腔默认值）
- 禁用「赋能」「抓手」「闭环」「深度解析」类词
- 禁用「首先/其次/最后」三段式开头
- 禁止连续三句使用相同句长
- 禁止「综上所述」式总结段，结论并入正文

## 动手前先选边
先判断文章类型：教程（允许口语）、 announcement（克制热情）、
深挖（冷静密实）。在回复开头用一行声明你选的类型和理由，再开始改。

## 执行标准
- 单句不超过 40 字，超了就拆
- 被动句主动化：「被执行」→「执行」
- 术语首次出现给英文原词，之后全用中文

## 交付前自查
对照禁止清单逐条过一遍，在文末列出你改动的三类主要问题及数量。
```

对照七个模式：门牌写了触发和边界（模式一、二）；禁止清单来自最高频的 AI 腔（模式三）；「先选边」强制声明文章类型（模式四）；执行标准全是名词级（模式五）；只管审校、不顺手改排版（模式六）；这份清单本身就应该是你被「赋能」刺到三次之后攒出来的（模式七）。

### 测试触发

写完必测，正例反例各来几句：

```text
应命中：帮我审校这篇发布稿，语气太营销了
应命中：检查一下这篇教程的中文表达
不应命中：帮我写一个 Python 脚本（边界句生效）
不应命中：把这段英文文档翻译成中文（description 里排除了）
```

不改文的请求命中了，说明 description 太宽，回去加边界；该命中的没命中，说明触发词漏了关键说法，回去补。

### 安装与使用命令速查

```bash
# 发现市场里的件（搜官方审美件）
npx skills find frontend-design

# 手动安装任意件：把件的文件夹整个拷进技能目录
mkdir -p ~/.claude/skills
# 项目级则放在项目的 .claude/skills/ 下

# Claude Code 内查看已装载的件
# 会话中输入 /查看技能列表，或用 /plugins 浏览官方插件市场安装 frontend-design
```

---

## 五、反模式清单（写完对照删一遍）

| 反模式 | 症状 | 处方 |
|--------|------|------|
| 空话门牌 | description 写成「一个强大的助手」 | 换成模式一句式：做什么+何时用 |
| 百科正文 | 塞满背景知识和概念科普 | 只留能改变模型行为的话 |
| 全家桶件 | 一个件管审校又管排版又管发布 | 拆成三件，各写门牌 |
| 口号无标准 | 「输出要专业、要优雅」 | 全部降级为名词级规则 |
| 从没触发过 | 装了一个月从未被激活 | description 缺触发场景词，重写 |

---

## 六、推荐排行榜

- **最佳入门范文**：frontend-design——一页纸、零依赖、七个模式全占，第一件 Skill 之前先通读它
- **最佳结构课代表**：skill-creator——官方造件机，示范了多文件结构与渐进披露（本栏目往期已拆）
- **最佳多文件示范**：brand-guidelines——看它怎么把大规范拆成正文摘要加外置细节
- **最佳克制样本**：doc-coauthoring——正文短到近乎吝啬，全部篇幅留给流程约束
- **最被低估**：canvas-design——和 frontend-design 同门不同科，管平面视觉，适合对照阅读看官方怎么切分两个相邻领域

---

## 参考来源

1. [anthropics/skills 官方仓库](https://github.com/anthropics/skills) — frontend-design、skill-creator、brand-guidelines 等官方件源文件所在仓库
2. [Anthropic 工程博客：Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) — Skills 机制与渐进披露设计的官方阐述
3. [Claude Code 官方文档：Skills](https://code.claude.com/docs/en/skills) — name/description 字段规范、个人级与项目级安装路径
4. [Simon Willison: Claude Skills](https://simonwillison.net/2025/Oct/16/claude-skills/) — Skills 发布初期的独立技术评述
5. [skills.sh](https://skills.sh) 与 [mcpservers.org/agent-skills](https://mcpservers.org/agent-skills) — Skills 聚合目录，观察官方件与社区仿写件分布

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
