自定义 Skill 实战：给市场团队做一个永不出错的品牌文案专家

这个项目的起因特别真实——我老婆是她们公司市场部负责人，某天晚上她一边改文案一边叹气：”这个实习生又把 B 端产品的官网 banner 写成了小红书卖货文案的语气，产品经理又发火了。”

我随口问了一句：”你们公司没有品牌 tone & manner 手册吗？”

她一脸苦笑：”有啊，一份 40 页的 PDF。谁会每写一条文案就翻一遍？”

就这一句话点醒我了。这不就是 Claude Skills 完美适配的场景吗？——一套规则、需要严格遵守、人类执行起来很累、但对 AI 来说只是 reading task。那晚我就开始动手，花了大概两周（零碎时间）做了一个「品牌文案专家」Skill。现在她们市场部三个人日常都在用，实习生再也没犯过低级错误。

这篇想完整记录这个事儿——从需求分析到 SKILL.md 落地到上线后的反馈，给正在想给业务团队做 AI 工具的同学一个参考。

一、这个需求到底是个什么问题

先说清楚她们公司的情况。公司主营两条产品线：

• A 产品：给金融机构的合规审计 SaaS，B 端、客单价百万级、买家是银行风控总监。官网、白皮书、案例都要”稳重、专业、权威”
• B 产品：个人理财 App，C 端、年轻白领、社媒投放为主。需要”亲切、有梗、偶尔调皮”

问题出在同一套文案人马同时服务两条线。实习生写 A 产品的时候带着 B 产品的语气——“银行合规好难？让我们一起搞定！”——产品经理看到当场黑脸。反过来写 B 产品的时候又回到”本产品致力于为用户提供专业的理财解决方案”——运营看到又想哭。

传统解决方案？写 tone 手册、做培训、reviewer 卡稿。都试过，人工成本高、效果还不稳定。

二、为什么选 Skill，不选别的

最早我想到的其实是改系统 prompt——在她们 ChatGPT 企业账号的 default prompt 里塞一大段品牌规则。但有几个问题：

• 写一万字 prompt 成本吃不消，每次请求都烧
• 两条产品线混在一个 prompt 里，模型容易串味
• 规则一改全员得手动更新，没版本控制

然后想到 RAG——把品牌手册切片、embedding、按需检索。问题是 tone & manner 是个整体风格，按关键词检索出来都是断章，拼不出完整画面。

Skill 就很对路：

• 按需加载：用户说”写 A 产品文案”才激活 A 的 Skill，不混淆
• 完整上下文：主 SKILL.md 一次性把 tone 完整载入，不会断章
• 版本化：git 管理，改了一次全员同步
• 描述触发：description 里写清楚”什么时候用我”，模型自动选择

关于 Skills 的底层机制为啥适合这种场景，我在 Agent开发 分类 里那篇深度拆解讲得更细，这里就不重复了。

三、SKILL.md 到底怎么写

这是核心问题。我给她们做的那个 A 产品 Skill 完整结构：

1
2
3
4
5
6
7
8

brand-voice-product-a/
├── SKILL.md
├── references/
│   ├── banned-words.md         # 禁用词清单
│   ├── approved-tone-examples.md  # 20 个正例
│   ├── rejected-examples.md    # 20 个反例加点评
│   └── scenario-templates.md   # 5 类场景文案模板
└── .version

SKILL.md 我来完整贴一下（脱敏过，公司名换成了占位符）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

---
name: brand-voice-product-a
description: 为 XX 金融合规 SaaS（产品 A）撰写或审阅营销文案。适用于官网 banner、白皮书摘要、客户案例、社媒、BD 邮件等场景。当用户提到"A 产品""合规审计 SaaS""XX 平台"并需要文案撰写或修改时使用。
---

# 产品 A 品牌文案专家

你正在为 XX 公司的合规审计 SaaS 产品线撰写营销文案。这是一个**严肃的 B 端产品**，目标读者是银行/证券/保险机构的风控、合规、审计部门负责人。

## 品牌基调（Brand Voice）

三个关键词：**专业、稳重、克制**。

- 避免所有"兴奋感"和"营销口吻"
- 不使用感叹号（极特殊场景除外）
- 不使用"革命性""颠覆""绝佳"这类夸张形容
- 不假设读者情绪，直接讲事实和价值

参照行业标杆：埃森哲、普华永道、Palantir 的官网文案。

## 三条铁律

1. **第一段必须给出核心价值**，不要铺垫行业背景
2. **数字比形容词优先**：能用"效率提升 47%"绝不用"大幅提升"
3. **案例用具体机构名**（已脱敏的情况下），不说"某大型银行"

## 必查清单

写完任何一段文案，自查：

- [ ] 有无感叹号？（除了致谢类场景全部改掉）
- [ ] 有无"让我们""一起""轻松"这类 C 端词汇？
- [ ] 有无夸张程度副词（非常、极其、最）？
- [ ] 有无数字支撑？
- [ ] 第一句话是否讲价值？

## 引用文件

详细的禁用词清单见 `references/banned-words.md`。
好文案正例看 `references/approved-tone-examples.md`。
常见翻车反例和点评看 `references/rejected-examples.md`。
不同场景（banner/邮件/案例）模板见 `references/scenario-templates.md`。

## 输出格式

根据任务类型返回：

- **撰写**：直接给最终文案，不给多版本（怕市场同事选困难症）
- **审阅**：先给出修改后的版本，再列 3-5 条"问题所在"

B 产品那个 Skill 结构一样，内容全反——个性化、有梗、允许偶尔玩谐音——就不单独贴了。

四、references 文件的几个关键点

主 SKILL.md 只是总纲，真正的”肌肉”在 references 里。几个我踩过的坑：

banned-words.md 不要只列禁用词

一开始我只列了”禁止用词”清单。后来发现模型会漏掉一些变体——比如禁了”让我们”，它会写成”我们一起来”，绕过检查但语气还是错的。

后来改成禁用词 + 禁用句式 + 语气关键词三类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

## 禁用词

- 让我们、我们一起、不妨、来吧
- 超级、爆款、神器、救星
- 赶紧、立刻、马上（转化类除外）

## 禁用句式

- 反问句（"你还在为 XX 烦恼吗？"）
- 卖惨句式（"再也不用"）
- 召唤句式（"点击了解""立即咨询"——改成陈述"预约演示请访问..."）

## 禁用语气信号

- emoji（B 端全部禁用）
- 过度修辞（类比要克制）
- 网络流行语（出圈、破防、绝绝子……）

approved-examples 至少放 20 条

少于 20 条模型泛化能力不够。每条我都标了为什么这么写：

1
2
3
4
5
6
7
8
9

### 例 1 - 官网主 banner

原文：
"为金融机构构建全流程合规审计基础设施"

为什么好：
- 一句话把产品定义说清楚
- "基础设施"隐含了"深度集成、长期使用"
- 无情绪词、无感叹号

rejected-examples 比 approved 更重要

这个是我后来加的。模型看到”什么是好的”不一定记得住，但看到”什么是错的以及错在哪”效果好得多。

1
2
3
4
5
6
7
8
9
10
11
12
13

### 反例 1

错误文案：
"还在头疼合规审计报告？XX 来帮你搞定！"

错在哪：
- 反问句（营销口吻）
- "头疼"带情绪假设
- "搞定"过于口语
- 感叹号

正确版本：
"XX 支持合规审计全流程自动化，平均缩短人工报告编制时间 60%。"

五、测试怎么做

这步特别容易被忽略，但决定了 Skill 能不能真正上线。

我自己造了一批触发测试集——30 条各种各样的任务描述，一半该触发这个 Skill，一半不该触发：

• 应触发：「帮我写 A 产品官网 banner」「改一下这段合规审计 SaaS 的案例文案」「产品 A 的 BD 邮件开头怎么写」
• 不应触发：「帮我写一封请假邮件」「给 B 产品小红书笔记出个标题」

跑下来第一版触发准确率只有 73%。问题出在 description 写得太泛——“金融文案”这种词把 B 产品的理财 App 也套进来了。改了三版 description 才把准确率拉到 95% 以上。

description 字段是 Skill 能不能被正确选中的关键，值得花时间反复调。我的经验：

• 明确列产品名 / 关键词
• 说清楚场景边界
• 避免过于通用的词（”营销””内容”这种别单独用）

六、上线后的真实反馈

上线三周了，收集到一些真实用户（市场部三个人）的反馈：

正向反馈：

• 实习生那边，产品 PM 审稿打回率从约 40% 掉到 8%
• 我老婆自己写稿速度快了约 30%（因为不用反复核对 tone 手册）
• 最意外的：新入职的人上手时间从 2 周变成 2 天——因为 Skill 本身就是 onboarding 手册

负向反馈：

• 写「混合场景」（比如 A 产品在年轻人媒体投放）的时候，两个 Skill 都不太贴，需要人工裁剪
• 偶尔模型”太听话”，稍微有感情的地方也被它改得死板，需要人工回调一下
• Skill 覆盖不到的完全新场景（比如第一次做播客脚本），还是得人来主导

还没解决的问题：

• 不同 Claude 客户端对 Skills 的支持度不一致。Claude Desktop 原生支持最好，有些第三方 Client 触发不太稳
• Skill 更新后要让所有人同步，目前靠我老婆在群里发 git pull 命令（够土但有用）

七、给想做类似事情的你几个建议

如果你也想给业务团队做一个类似的 Skill，我的踩坑总结：

第一，别一上来写太完美。MVP 先跑起来，用户用起来之后反馈远比闭门造车值钱。我那个第一版只有 SKILL.md 一个文件，references 都是后续加的。

第二，description 是命脉。这一行决定 Skill 能不能被正确激活，花时间反复测。

第三，反例比正例更值钱。模型对”别怎么做”的记忆比”怎么做”更深。

第四，留个人工兜底。Skill 不是万能的，总有它不擅长的场景。告诉用户”遇到 XX 情况直接找人”比硬让模型发挥好。

第五，版本化管理。我用 git 管了这套 Skill 已经改了 18 个 commit，每次改动都能追溯。

想看更多 Claude 在企业落地的案例，可以去 www.cocoloop.cn 翻；想跟进 Skills 相关的最新功能更新，news.cocoloop.cn 上有不少一手信息。

最后说点感触。

以前我们做企业 AI 工具，总觉得要做一个”大脑”——能自动理解一切、自动决策。干了这个项目之后我反而觉得，更好的方式是把企业已有的隐性知识显性化、结构化，让模型当个靠谱的执行者。

你们公司一定有很多「老员工脑子里的规矩」没写下来——Skills 就是把这些东西沉淀下来的最好容器。做一个，就能让新人快速上手；做十个，就是整个团队的共享肌肉。

这事儿不酷炫，但特别管用。