用Skills机制打造睡前故事与公众号文章生成技能包

1. 从两个日常需求说起：为什么我盯上了 Skills 这套机制

最早动这个念头，是因为两件特别琐碎的事。一件是家里小孩每天晚上都要听睡前故事，同一个故事讲三遍就嫌烦，我脑子里的存货早就见底了；另一件是我自己运营的一个小号，每周要憋两三篇公众号文章，选题、搭框架、填内容、改语气，一套流程下来少说两三个小时。这两件事看起来八竿子打不着，但本质上是一回事——都是"给定一个主题，产出一段结构完整、语气合适的文本"。

我一开始的做法很土，就是直接开个对话窗口，把需求敲进去，让它生成。能用，但问题很快暴露出来：每次都要重新描述一遍要求，故事要什么年龄段、多长、有没有教育意义，文章要什么风格、多少字、开头怎么起，全靠我一遍遍复述。更麻烦的是，生成质量飘忽不定，今天写得挺好，明天就给你来一段干巴巴的流水账。这种"每次从零开始"的模式，本质上是在浪费上下文，也在浪费我的耐心。

后来接触到 Skills 这套东西，思路一下就通了。你可以把它理解成给模型预先准备好的一份"岗位说明书加工具箱"：说明书告诉它遇到这类任务该按什么流程走、注意哪些坑，工具箱里放着可以调用的脚本、模板、参考资料。模型接到任务时，不再是两眼一抹黑地硬编，而是先翻说明书，再按流程一步步来。这跟我带新人的逻辑一模一样——你不会指望一个刚入职的同事凭感觉干活，你会给他一份 SOP，再配几个常用工具。

所以这篇东西，我想聊的就是怎么用 Skills 这套机制，把"睡前故事"和"公众号文章"这两个高频、重复、有固定套路的文本生成任务，做成两个可以反复调用、质量稳定的技能包。涉及到的关键词有 Skills、Claude Code、Shell、MCP、Cursor，我会在具体环节里说清楚它们各自扮演什么角色。适合谁来读？如果你手头有类似的重复性文本任务，或者你正在用 Claude Code、Cursor 这类工具但总觉得"每次都要重新调教"，那这篇应该对你有用。哪怕你只是想给自家孩子弄个故事生成器，照着做也能跑起来。

2. Skills 到底是什么：把"提示词"升级成"可复用的能力单元"

2.1 一句话讲清 Skills 和普通提示词的区别

普通提示词是"一次性"的，你打完这段字，它完成任务就结束了，下次还得重打。Skills 是"常驻"的，它是一份放在特定目录下的结构化文件，模型在需要的时候会主动去读它、按它说的做。打个比方，普通提示词像是你临时给同事发的一条微信语音，Skills 像是公司知识库里那份写好的操作手册，谁需要谁去翻。

从技术形态上看，一个 Skill 通常就是一个文件夹，里面至少有一个描述文件（一般叫 SKILL.md 之类），用来说明这个技能是干什么的、什么时候该用它、具体步骤是什么。文件夹里还可以放脚本、模板、示例、参考文档。模型读到这个描述文件后，就知道"哦，遇到生成睡前故事的任务，我该走这套流程"。

这里有个关键点很多人会忽略：Skills 的核心价值不在于"让模型多知道一些知识"，而在于"约束模型的行为路径"。知识模型本来就有，它缺的是"在什么场景下该按什么顺序做什么"这种流程性约束。你把流程固化下来，输出质量自然就稳了。

2.2 Skills、MCP、Claude Code、Cursor 各自的位置

这几个词经常被混在一起说，我按自己的理解理一遍，不一定权威，但足够指导实操。

Skills 是"能力封装层"，解决的是"怎么做这类任务"的问题。MCP 是"工具连接层"，解决的是"模型怎么调用外部工具和数据源"的问题，比如让它能读你本地的文件、能查数据库、能调某个 API。Claude Code 和 Cursor 是"执行环境"，也就是你实际干活的地方，它们负责加载 Skills、连接 MCP、把模型的能力落到具体操作上。

举个具体场景：你要生成一篇公众号文章，需要先读一下你之前存的选题库（这是 MCP 帮你读文件），然后按公众号文章的写作规范来组织内容（这是 Skill 提供的流程），最后把成稿写到指定目录（这又是 MCP 或环境本身提供的文件操作能力）。三者是配合关系，不是替代关系。

Shell 在这里的角色也很实在。很多自动化环节，比如批量重命名生成的故事文件、按日期归档文章、清理临时文件，用 Shell 脚本几行就搞定，比让模型去"思考"怎么操作要可靠得多。模型负责创意和文本，Shell 负责机械性的文件操作，分工明确。

2.3 为什么这两个任务特别适合做成 Skill

睡前故事和公众号文章，看起来一个是哄娃一个是搞自媒体，但它们的共同点非常明显：高频、有固定结构、对语气有要求、需要一定的变化度避免重复。这四点正好是 Skill 能发挥价值的地方。

高频意味着值得投入一次性的封装成本。有固定结构意味着流程可以固化。对语气有要求意味着需要明确的风格指引。需要变化度意味着 Skill 里要设计"随机化"或"参数化"的机制，不能每次都产出一模一样的东西。

我实测下来，把这两个任务做成 Skill 之后，单次生成的时间没怎么变，但"调教成本"几乎降到零。以前每次要花五分钟描述需求，现在一句话触发，直接出结果。这个收益在长期高频使用下非常可观。

3. 动手前的准备：环境、目录与最小可用骨架

3.1 环境准备与工具确认

不管你用 Claude Code 还是 Cursor，第一步都是确认你的工作目录结构。我的习惯是在项目根目录下建一个skills文件夹，里面每个子文件夹就是一个技能。比如skills/bedtime-story/和skills/wechat-article/。这种扁平结构的好处是直观，模型扫描的时候也容易定位。

如果你用的是 Claude Code，它一般会约定一个特定的技能目录，你需要确认一下当前版本的约定路径。我踩过的坑是：早期版本对目录名大小写敏感，Skills和skills会被当成两个不同的东西，导致技能加载不出来。所以统一用小写，别给自己找麻烦。

Cursor 这边，它本身是个编辑器，Skills 的加载更多依赖你配置的规则文件或者 MCP 提供的能力。我的做法是在项目里放一个说明文件，把技能目录的位置和用途写清楚，让 Cursor 的 AI 在需要时能读到。具体配置方式各版本有差异，以你当前版本的文档为准，我这里说的是通用思路。

Shell 环境基本不用额外准备，Linux 和 macOS 自带，Windows 用户建议用 WSL，不然很多脚本会水土不服。这一点很关键，我见过太多人在 Windows 原生环境下跑 Shell 脚本，各种路径分隔符和权限问题，折腾半天。

3.2 一个 Skill 的最小骨架长什么样

别一上来就追求完美，先搞一个能跑起来的最小版本。一个 Skill 文件夹里，我建议至少放三样东西：

• SKILL.md：核心描述文件，说明技能用途、触发条件、执行步骤
• templates/：模板目录，放故事结构模板、文章框架模板
• scripts/：脚本目录，放 Shell 脚本处理文件操作

SKILL.md的写法有讲究。开头要有一段简短的"这个技能是干什么的"，然后是"什么时候该用"，接着是"具体步骤"。步骤要写得像给新人的操作手册，一步一步，别跳步。我见过有人把 SKILL.md 写成一段散文，模型读起来抓不住重点，效果大打折扣。

提示：SKILL.md 里的步骤描述，动词要明确。写"生成故事"不如写"先确定年龄段，再选择故事模板，然后填充角色和情节，最后检查字数"。越具体，模型执行越稳。

3.3 目录结构的一个参考样例

我实际用的结构大概是这样：

skills/ bedtime-story/ SKILL.md templates/ age-3-5.md age-6-8.md scripts/ archive.sh wechat-article/ SKILL.md templates/ opinion.md tutorial.md scripts/ slugify.sh

这个结构不复杂，但足够支撑起两个完整的技能。archive.sh负责把生成的故事按日期归档，slugify.sh负责把文章标题转成适合做文件名的格式。这些脚本都很短，但能省掉大量手动操作。

4. 睡前故事 Skill：从"随便编一个"到"稳定产出合格故事"

4.1 故事 Skill 的核心设计思路

睡前故事这个任务，表面需求是"讲个故事"，但真实需求要复杂得多。孩子年龄不同，能理解的情节复杂度不同；家长希望故事有正向引导，但不能说教味太重；故事长度要适中，太短孩子不过瘾，太长又影响入睡；最重要的是，不能每天重复，得有新鲜感。

所以我在设计这个 Skill 的时候，把"参数化"作为核心。也就是说，Skill 不是固定产出某一个故事，而是根据输入参数（年龄段、主题偏好、期望长度、是否需要特定教育点）动态组合出一个故事。参数从哪来？可以是你每次触发时给的，也可以是 Skill 里预设的默认值。

这里有个设计取舍值得说：我一开始想做成"完全随机"，每次从一堆元素里随机拼。实测发现效果不好，随机拼出来的故事经常逻辑断裂，角色动机莫名其妙。后来改成"半随机"——故事骨架固定几种，角色和场景从预设池里选，情节走向按骨架走。这样既有变化，又保证了逻辑完整。

4.2 故事模板的写法与参数设计

以 3 到 5 岁这个年龄段为例，我用的模板大概包含这几个要素：一个可爱的主角（动物或小孩）、一个简单的小问题（比如找不到玩具、不敢一个人睡）、一次小小的冒险、一个温暖的解决、一句晚安。这个结构听起来很套路，但对这个年龄段的孩子来说，套路就是安全感。

模板里我会留出"变量位"，用占位符标出来，比如{{主角}}、{{小问题}}、{{帮助者}}。生成的时候，Skill 会从预设的角色池里挑一个填进去。角色池我准备了二十多个，涵盖常见的小动物和日常物品，足够撑一两个月不重样。

长度控制也很关键。3 到 5 岁的故事，我控制在 400 到 600 字，读出来大概三到五分钟，正好是孩子入睡前的注意力窗口。6 到 8 岁的可以到 800 到 1000 字，情节可以稍微复杂一点，加入一点小悬念。

注意：别在睡前故事里放太刺激的情节。我试过一次加入"大灰狼追赶"的桥段，结果孩子越听越精神，完全适得其反。睡前故事的基调应该是平缓、温暖、有安全感。

4.3 用 Shell 脚本做归档和去重

故事生成多了，管理就成了问题。我的做法是每生成一个故事，就用 Shell 脚本按日期归档到对应目录，文件名带上年龄段和主题标签。这样以后想找"上周讲过的关于分享的故事"，直接按标签搜就行。

归档脚本的核心逻辑很简单：读日期、建目录、移动文件、更新一个索引文件。索引文件是个纯文本，每行记录一个故事的元信息，方便后续检索。去重这块，我用的是简单的标题加主题组合判断，如果发现高度相似的就提示一下，避免重复讲。

#!/bin/bash # archive.sh - 把生成的故事按日期归档 DATE=$(date +%Y-%m-%d) STORY_DIR="stories/$DATE" mkdir -p "$STORY_DIR" mv "$1" "$STORY_DIR/" echo "$DATE | $1" >> stories/index.txt

这个脚本短得不能再短，但它解决了一个真实痛点：故事文件散落各处，找起来费劲。自动化归档之后，整个故事库是井井有条的。

4.4 让故事"有教育意义但不說教"的技巧

这是我在实操中琢磨最久的一点。直接告诉模型"要教孩子分享"，它很容易写成一篇说教文，孩子一听就烦。我的做法是在 Skill 里明确要求：教育点要通过角色的行为和结果自然体现，不能由旁白直接说出来。

比如要体现"分享"，就让主角一开始不愿意分享，然后遇到一个小困境，因为别人的分享而解决了，最后主角自己主动分享。整个过程不出现"我们要学会分享"这种句子，但孩子听完自然能感受到。这个技巧我写进了 SKILL.md 的"注意事项"里，效果立竿见影。

5. 公众号文章 Skill：把写作流程拆成可复用的流水线

5.1 文章 Skill 的流程拆解

公众号文章比睡前故事复杂，因为它涉及的环节更多。我把它拆成了五步：定选题、搭框架、填内容、调语气、做收尾。每一步在 Skill 里都有明确的输入和输出要求。

定选题这一步，我会让 Skill 先读一个本地的选题库文件（这里就用到了 MCP 的文件读取能力），从里面挑一个还没写过的。搭框架就是根据文章类型（观点文、教程文、盘点文）选对应的模板。填内容是最耗时的，但因为有框架约束，模型不会跑偏。调语气是让文章读起来像人写的，不是机器拼的。收尾就是加个自然的结尾，别用那种"综上所述"的套路。

这个流程拆解的好处是，每一步都可以单独优化。比如我发现"调语气"这步效果不好，就专门改这一步的指引，不用动其他部分。这种模块化的思路，是 Skill 相比一次性提示词的最大优势。

5.2 三种常用文章框架的模板设计

我常用的三种框架，各有各的适用场景。观点文适合表达立场，结构是"现象引入、观点亮明、论据支撑、反驳预设、收束"。教程文适合讲操作，结构是"问题场景、方案概述、分步实操、避坑提示、效果验证"。盘点文适合整理信息，结构是"主题引入、分项列举、每项点评、横向对比、个人推荐"。

每种框架我都写成了一个模板文件，里面用占位符标出各部分该填什么。模型拿到模板后，按部就班填就行。这里的关键是模板要足够细，细到每一段该写什么、大概多少字、用什么语气，都写清楚。模板越细，输出越稳。

我试过用很粗的模板，只写"开头、主体、结尾"三段，结果模型自由发挥，写出来的东西结构松散。后来把模板细化到七八个部分，质量立刻上来了。这个经验值得记一下：模板的颗粒度，直接决定输出的可控度。

5.3 语气调整：让文章读起来像"人话"

这是我觉得最有价值的一步。模型默认写出来的东西，有一种"正确的废话"的味道，句子都对，但读起来没劲。我在 Skill 里专门加了一段语气指引，核心就几条：多用短句，少用长句；多用具体例子，少用抽象概括；允许口语化表达，比如"我试过""实测下来"；避免"通过……可以……"这种被动句式。

这几条听起来简单，但效果非常明显。我做过对比，同样的内容，加了语气指引之后，读起来顺畅多了，像是真人在分享经验，而不是在念说明书。

提示：语气指引最好配上正反例。写一句"要口语化"不如写"要写成'我试过这个方法'，而不是'该方法经实践验证有效'"。模型对例子的理解比对抽象描述的理解准确得多。

5.4 用脚本处理标题和文件名

公众号文章写完之后，经常需要把标题转成适合做文件名的格式，去掉标点、空格换成连字符、限制长度。这个用 Shell 脚本处理最合适，几行就搞定。

#!/bin/bash # slugify.sh - 把标题转成文件名 TITLE="$1" SLUG=$(echo "$TITLE" | tr ' ' '-' | tr -d '[:punct:]' | cut -c1-50) echo "$SLUG"

这种小脚本看着不起眼，但积累起来能省很多事。我的原则是：凡是机械性的、有固定规则的文本处理，都交给脚本，别让模型去"想"。模型想一次要几秒，脚本跑一次是毫秒级，而且脚本不会出错。

6. 常见问题与排查技巧实录

6.1 技能加载不出来怎么办

这是最常见的问题。排查顺序我一般是这样的：先确认目录名和文件名是否符合约定，大小写、拼写都要对；再确认 SKILL.md 的格式是否正确，有些环境对文件头的格式有要求；然后确认技能目录是否在环境扫描的范围内，有些工具需要显式配置路径。

我踩过最坑的一次，是 SKILL.md 里用了中文标点，导致解析失败。后来统一改成英文标点，问题就没了。这种细节文档里不一定写，但实际会卡住你半天。

6.2 生成内容质量不稳定的排查思路

质量飘忽，通常有三个原因：一是 Skill 里的步骤描述太模糊，模型自由发挥空间太大；二是模板不够细，约束力不足；三是输入参数不完整，模型只能猜。

我的排查方法是：先固定输入参数，看输出是否稳定。如果固定输入还是飘，那就是 Skill 本身的问题，需要细化步骤和模板。如果固定输入稳定了，那就是参数的问题，需要在触发时把参数给全。

6.3 常见问题速查表

6.4 几个我踩过的坑

第一个坑是贪多。一开始我想做一个"万能写作 Skill"，什么类型的文章都包。结果是什么都做不好。后来拆成两个独立 Skill，各自专注，效果反而好。这印证了一个道理：Skill 要窄而深，不要宽而浅。

第二个坑是忽略版本差异。不同工具、不同版本对 Skill 的支持程度不一样，我照着旧文档配了半天没生效，换了新文档一看，路径约定变了。所以动手前先确认你当前版本的约定，别照搬网上的老教程。

第三个坑是忘了做备份。有一次改 SKILL.md 改崩了，把能用的版本覆盖了，只能重写。现在我改之前都会复制一份，命名带日期，出问题随时回滚。这个习惯看着笨，但救过我好几次。

7. 我个人的一些实操体会

这套东西用下来，最大的感受是：Skill 的价值不在"让模型更聪明"，而在"让模型更守规矩"。模型本身的能力已经够强了，缺的是流程约束和场景适配。你把这两样补上，输出质量自然就上来了。

另一个体会是，别指望一次做到完美。我的两个 Skill 都是迭代了七八个版本才稳定下来的。第一版能用但粗糙，后面每次遇到问题就改一点，慢慢就顺了。这个过程本身也是学习，你会越来越清楚模型在什么情况下会出什么错，怎么防。

最后分享一个小技巧：给 Skill 加一个"自检"步骤。也就是在生成完成后，让模型自己检查一遍，看是否符合要求，不符合就重来。这一步能拦掉不少低级问题，比如字数不够、结构缺失、语气跑偏。加这一步之后，我的返工率明显下降。

这套思路其实可以扩展到很多其他场景，比如自动生成周报、自动整理会议纪要、自动回复常见咨询。核心逻辑是一样的：找到高频重复的任务，拆解流程，固化成 Skill，配上脚本处理机械环节。你手头如果有类似的活儿，不妨试试这个路子。