1. 从两个真实需求说起为什么我要用 Skills 做内容自动化去年冬天有一阵子我每天晚上都要给家里的小朋友编睡前故事。一开始还挺有新鲜感什么小狐狸找星星、小恐龙学游泳随口就能来一段。但连续讲了两个礼拜之后我发现自己开始重复套路了——主角永远是迷路的小动物结局永远是找到家。小朋友不傻第三天就听出来了爸爸这个故事昨天讲过了。与此同时我手上还运营着一个技术公众号每周要更新两三篇长文。选题、查资料、搭结构、写初稿、改措辞一套流程下来一篇三千字的文章至少要耗掉我三四个小时。最要命的是这两件事本质上都是内容生成——一个面向儿童一个面向技术读者但底层逻辑惊人地相似给定一个主题和风格约束产出一段结构完整、语言通顺的文本。后来我开始接触 Claude Code 的 Skills 机制突然意识到这东西天生就是干这个的。Skills 说白了就是一套可复用的指令模板加工具调用流程你把怎么写睡前故事或者怎么写公众号文章这件事拆解成明确的步骤、约束和输出格式封装成一个 Skill之后每次只需要给一个主题词它就能按照你预设的流程自动跑完。这篇文章我会把整个探索过程完整拆开讲——从 Skills 到底是什么、怎么设计一个故事生成 Skill、怎么设计一个公众号文章 Skill到实际跑起来之后踩的那些坑。如果你也在用 Claude Code、Cursor 或者类似工具做内容自动化这篇应该能帮你省不少时间。2. Skills 到底是什么和普通 Prompt 的本质区别2.1 一个容易被忽略的概念分层很多人第一次听到 Skills 这个词第一反应是不就是存了一段 Prompt 吗。我一开始也这么想直到实际用了一段时间才发现Skills 和普通 Prompt 的区别有点像菜谱和厨师即兴发挥的区别。普通 Prompt 是你每次都要重新描述一遍需求帮我写一个关于小兔子勇敢的故事要适合五岁小孩大概五百字语言要简单结尾要温馨……每次都得说一遍而且稍微换个主题你还得重新组织语言。Skills 则是把这一整套需求固化下来形成一个有名字、有描述、有触发条件的能力单元。你只需要说用睡前故事 Skill 写一个关于小兔子勇敢的故事剩下的风格约束、字数要求、结构模板、输出格式Skill 内部已经定义好了。更关键的是Skills 可以调用工具。比如生成故事之后自动保存成文件、自动按照日期命名、自动推送到某个目录。这就不是单纯的文本生成了而是一条完整的流水线。2.2 Skills 的目录结构和核心文件Claude Code 的 Skills 通常放在项目的.claude/skills/目录下每个 Skill 一个文件夹里面至少包含一个SKILL.md文件。这个文件用 YAML frontmatter 定义元信息下面是正文指令。--- name: bedtime-story description: 根据主题自动生成适合 3-8 岁儿童的睡前故事包含标题、正文和一句晚安语 --- # 睡前故事生成器 ## 触发条件 当用户要求生成睡前故事、儿童故事或提到讲故事时使用此 Skill。 ## 生成规则 1. 故事长度控制在 400-600 字 2. 主角必须是动物或拟人化的小物件 3. 情节包含遇到困难 → 尝试解决 → 获得帮助 → 温馨结局四段式 4. 语言简单句子不超过 20 字 5. 结尾必须有一句晚安语这个结构看起来简单但每一行都有讲究。description字段尤其重要它决定了 Claude 在什么场景下会自动加载这个 Skill。写得太窄该触发的时候不触发写得太宽不该触发的时候乱触发。2.3 为什么 Skills 比一次性 Prompt 更适合内容生产我总结下来有三个原因。第一是一致性。你给小朋友讲故事今天讲小狐狸明天讲小兔子但风格得统一不能今天文绉绉明天大白话。Skill 把风格约束固化下来每次输出都稳定。第二是可迭代。你发现故事结尾总是太仓促只需要改 SKILL.md 里的一行规则之后所有生成都会生效。而如果你用的是散落的 Prompt改起来就是到处找、到处改。第三是可组合。你可以做一个故事生成 Skill再做一个配图描述 Skill再做一个文件保存 Skill让它们串起来。这种组合能力是普通 Prompt 做不到的。提示Skills 的加载是有上下文成本的。每个 Skill 的 description 都会占用一定的 token如果你装了二三十个 Skill光是描述就吃掉不少上下文。建议按项目分组不要一股脑全塞进去。3. 睡前故事 Skill 的设计把哄睡拆成可执行规则3.1 先想清楚好故事的标准是什么动手写 SKILL.md 之前我先花了一个晚上复盘到底什么样的睡前故事算是合格的我列了一个清单情节不能太刺激否则小孩越听越兴奋不能有恐怖元素哪怕是大灰狼这种经典反派在睡前场景里也得处理得温和长度要适中太短小孩不过瘾太长大人念得口干结尾要有明确的收束感让小孩知道故事结束了该睡了。这些标准如果只放在我脑子里每次生成都得重新交代。写进 Skill 之后就变成了硬约束。3.2 SKILL.md 的完整写法下面是我实际在用的版本做了脱敏处理但核心逻辑都在。--- name: bedtime-story description: 生成适合 3-8 岁儿童的睡前故事。当用户提到睡前故事、儿童故事、哄睡、讲故事时触发。 --- # 睡前故事生成器 ## 角色设定 你是一位有十年经验的儿童故事创作者擅长用简单的语言讲温暖的故事。 ## 输入 用户会提供一个主题词例如勇敢分享友谊小兔子。 ## 输出结构 严格按照以下格式输出 标题xxx 正文xxx400-600字 晚安语xxx一句话不超过 20 字 ## 内容规则 1. 主角必须是动物或拟人化物品不能是真实人物 2. 情节遵循四段式平静开场 → 遇到小困难 → 在朋友帮助下解决 → 温馨收尾 3. 禁止出现死亡、暴力、恐怖、争吵升级、惩罚性结局 4. 句子长度不超过 20 字段落不超过 4 行 5. 至少出现一次对话让故事有画面感 6. 结尾的晚安语要呼应故事主题 ## 风格约束 - 语气温柔像妈妈在床边轻声讲 - 多用拟声词和叠词例如咕噜咕噜慢慢地 - 避免说教道理要藏在情节里3.3 四段式结构为什么有效我试过好几种结构最后发现四段式最稳。原因是它符合儿童注意力的节奏。第一段平静开场大概 80 字作用是建立场景让小孩进入状态。第二段遇到小困难大概 120 字制造一点点张力但不能太强。第三段获得帮助大概 200 字是故事的主体也是情绪释放的地方。第四段温馨收尾大概 100 字把情绪收回来自然过渡到睡觉。这个比例不是拍脑袋定的。我试过把困难段拉长到 200 字结果小孩听完反而更精神了因为张力持续太久。也试过把收尾压到 50 字感觉故事没讲完就结束了。3.4 实测中发现的几个细节问题跑了几十次之后我发现了几个 SKILL.md 里没写但很关键的点。第一个是主角名字的重复率。Claude 默认很喜欢用小兔子小熊小狐狸这几个连续几天都是这几个小孩会腻。后来我在 Skill 里加了一条每次生成时随机选择主角优先使用不常见的动物如小刺猬、小浣熊、小树懒。第二个是晚安语的套路化。不加约束的话十次有八次是晚安做个好梦。后来我改成晚安语必须包含故事中的一个具体元素比如故事里讲了星星晚安语就是晚安愿你梦里有星星。第三个是对话的生硬感。早期版本里对话经常是小兔子说我们一起去玩吧。这种教科书式的。后来我加了一条对话要口语化允许出现语气词和省略。注意Skill 的规则不是越多越好。我一开始写了二十多条结果 Claude 经常顾此失彼满足了这条忘了那条。后来精简到十条左右反而稳定了。规则之间如果有冲突优先级要明确写出来。4. 公众号文章 Skill从选题到成稿的流水线4.1 公众号文章和睡前故事的本质差异同样是内容生成公众号文章的复杂度高一个量级。睡前故事是单一场景、单一受众、单一风格公众号文章要考虑选题角度、目标读者、信息密度、结构层次、开头吸引力、结尾引导。我一开始想偷懒把睡前故事的 Skill 改改就用结果生成出来的文章像童话——从前有一个程序员他遇到了一个 bug……这种开头放在技术号里读者三秒就划走了。所以公众号文章 Skill 必须重新设计核心是把写文章这件事拆成几个可独立控制的模块。4.2 模块化设计选题、结构、语言、收尾我的做法是把 Skill 分成四个模块每个模块有独立的规则但整体串起来。选题模块负责把用户给的一个模糊主题转化成具体的切入角度。比如用户说写一篇关于 Skills 的文章选题模块会输出三个候选角度Skills 入门教程、Skills 实战案例、Skills 踩坑记录然后根据目标读者选一个。结构模块负责搭骨架。技术文章我固定用问题引入 → 概念解释 → 实操步骤 → 踩坑经验 → 收尾这个结构但每个部分的比例会根据选题调整。语言模块负责风格。技术号不能太口语但也不能太学术。我的设定是像一个有五年经验的工程师在茶水间跟你聊天专业但不端着。收尾模块负责最后一段。技术文章的收尾最忌讳综上所述我要求收尾必须是一个具体的经验分享或者一个可执行的建议。4.3 SKILL.md 的实际配置--- name: tech-article description: 生成技术类公众号文章。当用户要求写公众号文章、技术长文、教程文章时触发。 --- # 技术公众号文章生成器 ## 角色设定 你是一位有五年一线经验的技术博主擅长把复杂概念讲得通俗易懂。 ## 输入 用户提供一个主题词或一句话描述。 ## 工作流程 1. 先输出三个候选切入角度标注目标读者和难度 2. 用户选定后输出文章大纲H2 级别 3. 用户确认后逐段生成正文 4. 最后统一检查语言风格和事实准确性 ## 结构规则 - 开头用一个具体场景或反直觉结论引入禁止随着...的发展 - 主体至少 4 个 H2 章节每章 800 字以上 - 每个 H2 下至少 2 个 H3 小节 - 结尾用一个个人经验或实用建议收尾禁止总结性套话 ## 语言规则 - 句子长度 15-40 字避免超长句 - 专业术语首次出现时用一句话解释 - 每 300 字至少出现一个具体例子 - 禁止使用通过...可以本文介绍了综上所述 ## 格式规则 - 使用 Markdown - 代码块标注语言 - 对比内容用表格 - 关键步骤用有序列表4.4 为什么要有分步确认机制这个 Skill 和我见过的很多文章生成工具最大的区别是它不会一口气把整篇文章吐出来而是分三步先给角度再给大纲最后给正文。原因很简单一篇文章如果方向错了写三千字也是白写。让用户在角度阶段就介入成本最低。大纲阶段再确认一次避免结构跑偏。到了正文阶段基本就是填充细节了。我实测下来这个分步机制能把返工率降低至少一半。以前一口气生成经常是写完了发现角度不对只能重来。现在最多在大纲阶段调整一下正文基本一次过。4.5 语言风格的可调参数不同公众号的调性差别很大。有的偏严肃有的偏活泼。我在 Skill 里留了几个可调参数用的时候在指令里带上就行。参数可选值效果语气严谨 / 轻松 / 犀利影响用词和句式读者小白 / 进阶 / 专家影响解释深度篇幅短 / 中 / 长影响章节数量案例多 / 少影响举例频率比如用轻松语气、面向小白、中等篇幅、多案例生成出来的文章和用严谨语气、面向专家、长篇幅、少案例生成出来的完全是两个风格。这个参数化设计让一个 Skill 能覆盖多种场景。5. 把两个 Skill 串起来文件保存与批量生成5.1 为什么需要文件保存环节生成完内容之后如果只是显示在终端里你还得手动复制粘贴到文件里。生成十篇就要复制十次很烦。所以我在两个 Skill 后面都加了一个文件保存的步骤。Claude Code 可以直接调用 Shell 命令所以保存文件这件事用一行命令就能搞定。关键是要设计好文件命名规则否则生成多了之后根本找不到。我的命名规则是{类型}-{主题}-{日期}.md比如story-勇敢-20250115.md、article-skills入门-20250115.md。这样按类型和日期排序都很方便。5.2 用 Shell 做批量重命名和归档生成的文件多了之后我习惯按月份归档。这里用到一个很实用的 Shell 循环#!/bin/bash # 把当前目录下所有 story- 开头的文件移动到对应月份目录 for file in story-*.md; do # 从文件名提取日期格式如 20250115 date_part$(echo $file | grep -oE [0-9]{8}) month_dir${date_part:0:6} # 目录不存在就创建 mkdir -p archive/$month_dir # 移动文件 mv $file archive/$month_dir/ done echo 归档完成这段脚本里有个容易踩的坑grep -oE [0-9]{8}提取日期的时候如果文件名里还有其他数字可能会提取错。所以命名规则里要保证日期是唯一的一组八位数字。5.3 批量生成的节奏控制我试过一次性让 Claude 生成十篇故事结果发现两个问题。一是上下文会越来越长后面的生成质量会下降二是如果中间有一篇跑偏了后面可能跟着跑偏。后来我改成一次生成三到五篇生成完检查一遍没问题再继续。虽然慢一点但质量稳定得多。另外批量生成的时候建议把主题词提前列好放在一个文本文件里让 Claude 逐行读取。这样比每次手动输入要高效。# topics.txt 里每行一个主题词 while read topic; do echo 正在生成$topic # 这里调用 Claude Code 生成 done topics.txt5.4 一个完整的自动化流程示例把上面这些串起来我现在的日常流程是这样的早上花十分钟列好当天要生成的主题词写进topics.txt运行批量生成脚本Claude 逐个读取主题调用对应的 Skill生成的内容自动保存到output/目录按类型和日期命名晚上统一检查一遍手动微调不满意的部分每周日运行归档脚本把文件按月份整理这套流程跑下来睡前故事基本不用我操心了公众号文章的初稿也能省掉一大半时间。当然最终发布前我还是会自己过一遍毕竟机器生成的东西事实准确性和个人风格还是需要人工把关。6. 踩过的坑那些 SKILL.md 里不会告诉你的问题6.1 Skill 触发不稳定description 写法的玄学最开始我的睡前故事 Skill 经常不触发。我明明说了讲个故事Claude 却当成普通对话处理了。排查了半天发现是 description 写得太窄只写了生成睡前故事没覆盖讲故事哄睡这些同义表达。后来我把 description 改成当用户提到睡前故事、儿童故事、哄睡、讲故事、编个故事时触发触发率立刻上来了。但反过来也有问题。有一次我把公众号 Skill 的 description 写得太宽结果我随口说帮我写个东西它也触发了生成了一篇三千字的文章完全不是我想要的。所以 description 的写法要遵循一个原则覆盖同义表达但不覆盖泛化表达。讲故事是睡前故事的同义表达要覆盖写东西太泛不覆盖。6.2 规则冲突当两条约束打架时我在睡前故事 Skill 里同时写了句子不超过 20 字和至少出现一次对话。结果有一次生成的故事里对话被拆成了好几段短句读起来很别扭。这就是规则冲突。对话天然需要长一点的句子来表达完整意思但字数限制又要求短句。后来我在规则里加了一条优先级说明对话部分可以适当放宽字数限制但单句不超过 30 字。类似的冲突还有情节要有张力和不能太刺激。这两个约束在睡前场景下天然矛盾。我的处理是把张力限定在小困难级别明确写出困难必须是可以通过朋友帮助解决的不能是危险或紧急情况。6.3 上下文污染多 Skill 同时加载的副作用有一阵子我装了很多 Skill结果发现生成质量下降了。排查之后发现是上下文污染——多个 Skill 的规则互相干扰。比如我同时装了睡前故事和技术文章两个 Skill有一次生成故事的时候Claude 莫名其妙地在结尾加了一段总结本故事讲述了……这明显是技术文章 Skill 的规则串过来了。解决办法有两个。一是按项目隔离写故事的项目目录下只放故事 Skill写文章的项目目录下只放文章 Skill。二是如果必须放在一起在 Skill 里明确写本 Skill 的规则仅适用于本 Skill 的输出不影响其他任务。6.4 生成内容的AI 味怎么让它说人话这是最头疼的问题。早期生成的故事和文章一眼就能看出是 AI 写的。故事里全是小兔子感到非常开心文章里全是通过本文的介绍相信读者已经对……有了深入的了解。我花了很长时间才找到几个有效的去 AI 味方法。第一个是禁用词清单。在 Skill 里明确列出禁止使用的表达比如通过……可以随着……的发展综上所述值得注意的是不难发现。这些词一出现AI 味就藏不住了。第二个是强制具体化。要求每 300 字至少出现一个具体的数字、名字或场景。AI 喜欢说很多人你就要求它说我认识的三个朋友AI 喜欢说效果很好你就要求它说响应时间从 800ms 降到了 120ms。第三个是口语化改写。生成完之后让 Claude 自己再过一遍把书面语改成口语。比如因此改成所以此外改成另外然而改成但是。6.5 事实准确性的边界技术文章最怕的是事实错误。Claude 生成的内容里经常会有一些看起来很像真的、但实际上是编造的细节。比如某个 API 的参数名、某个工具的版本号、某个命令的选项。我的处理方式是在 Skill 里加一条硬规则涉及具体 API、命令、参数、版本号时如果不确定必须标注待核实不能编造。另外生成完之后我会用搜索工具交叉验证关键事实。这一步不能省尤其是要发布的内容。提示不要指望 Skill 能保证事实准确性。Skill 能保证的是结构和风格的一致性事实核查还是得靠人。把 Skill 当成一个高效的初稿生成器而不是一个可以完全信任的内容源。7. 一些让 Skill 更好用的进阶技巧7.1 用示例驱动生成质量SKILL.md 里除了规则还可以放示例。我发现放了示例之后生成质量明显提升。因为规则是抽象的示例是具体的Claude 更容易理解你想要什么。比如睡前故事 Skill 里我放了一段我自己写的范文。公众号 Skill 里我放了一段我觉得写得好的开头。Claude 会模仿这些示例的风格。但示例不能放太多否则会限制创造力。我的经验是每个 Skill 放一到两个示例就够了而且要标注这是风格参考不是模板不要照抄内容。7.2 版本管理Skill 也要迭代Skill 不是写完就完了要持续迭代。我现在的做法是给每个 Skill 建一个简单的版本记录每次改动都记一笔写清楚改了什么、为什么改。## 版本记录 - v1.0 初始版本基础规则 - v1.1 增加主角随机化规则解决重复问题 - v1.2 调整四段式比例困难段从 200 字降到 120 字 - v1.3 增加禁用词清单去 AI 味 - v1.4 增加示例段落这样过一段时间回头看能清楚知道哪些改动是有效的哪些是无效的。7.3 和其他工具配合Skills 不是孤立的。我现在的流程里Skills 负责生成内容其他工具负责后续处理。比如生成完文章之后我会用格式检查工具过一遍 Markdown 语法用字数统计工具确认篇幅用敏感词检查工具扫一遍。这些都可以用 Shell 脚本串起来形成一条完整的流水线。如果你用 Cursor 或者类似的编辑器还可以把 Skill 生成的草稿直接导入编辑器用编辑器的 AI 功能做二次润色。工具之间配合好了效率能再上一个台阶。7.4 什么场景不适合用 Skill说了这么多 Skill 的好处也得说说它不适合的场景。高度创意性的内容不适合。比如你要写一篇有强烈个人风格的观点文Skill 生成的东西往往太标准了缺少那种独特的棱角。需要实时信息的内容不适合。Skill 本身不联网生成的内容基于训练数据时效性有限。需要最新数据的场景得配合搜索工具。需要深度专业判断的内容不适合。比如技术方案选型、架构设计这类需要结合具体业务场景做权衡的内容Skill 只能给通用建议深度不够。我的原则是Skill 适合处理有明确规则、可复用、对一致性要求高的内容不适合处理需要独特判断、依赖实时信息、强调个人风格的内容。8. 我现在的实际使用状态跑了大半年之后我现在的状态是这样的睡前故事基本全自动了每天晚上给一个主题词生成一篇我念之前扫一眼没问题就直接讲。偶尔遇到特别好的我会存下来现在已经攒了一百多篇小朋友有时候还会点播再讲一遍小刺猬那个。公众号文章这边Skill 负责生成初稿和大纲我负责选题把关和最终润色。以前一篇三千字的文章要三四个小时现在初稿半小时能出来我花一个小时改总共一个半小时左右。效率提升是实实在在的。但我也得说句实话Skill 生成的内容直接发布的合格率大概在六成左右。剩下四成需要不同程度的修改有的是事实错误有的是风格不对有的是结构需要调整。所以它是个好帮手但不是甩手掌柜。最后分享一个我最近发现的小技巧如果你觉得生成的内容总是差那么一口气不妨在 Skill 里加一条生成完成后自己检查一遍列出三个可以改进的地方然后根据这些改进点重新生成一版。这个自我批评再重写的机制能让质量再上一个台阶。我试了几次第二版确实比第一版好不少。