用Skills把小红书获客变成自动化流水线：从提示词到可复用技能包

这段时间我一直在折腾一件事用一套标准化的Skills跑完小红书从选题、写笔记、做图、发帖、回复评论到最后把咨询客户接进私域的全流程。很多人对 Skills 的印象还停留在“给编程工具写技能包”但它完全可以当成一套面向业务场景的自动化作业标准来用。我做小红书获客一段时间后最大的感受是重复劳动实在太多了找选题、改文案、做封面、看私信每个环节都在消耗时间。后来我试着把这些动作全部拆成 Skills让 Claude Code、Codex 这类智能体按固定流程执行才真正把“内容营销”变成一条可复用、可复制、可交接的流水线。这篇东西适合两类人一类是做小红书获客但又被重复内容生产折磨的运营另一类是本身就在用 Claude Code / Cursor / Codex想把自己的提示词沉淀成可维护技能包的开发者。不管你是哪类只要能理解一个核心逻辑——Skills 就是把“一次性提示词”升级成“带操作手册和脚本的工具箱”剩下的就是照方抓药的问题。1. 一套 Skills 到底在解决什么问题1.1 Skills 是给 AI 的“操作手册 工具箱”先说人话版。你给 AI 一句提示词它帮你写一条小红书笔记这叫“临时工”你给它一个固定目录里面写着触发条件、执行步骤、输出格式、参考模板还配几个脚本去抓数据、算指标这叫“正式员工培训手册”。这个“培训手册”就是 Skills。它在文件层面其实不神秘核心是一个SKILL.md外加可选的scripts和templates目录。SKILL.md告诉模型“你接到这个任务后按什么流程做、输出成什么格式、有哪些红线不能碰”scripts里放真正能跑起来的 Python 或 Node 脚本templates里放固定模板减少模型自由发挥的空间。你可以把它类比成浏览器的扩展插件或者 Photoshop 里的动作预设——平时不占地方要用的时候一键调用。放到小红书获客这个场景里Skills 的意义不是“让 AI 写得更好”而是“让每个环节的输出和质量变得稳定”。同样一段提示词不同时间问出来的结果方差很大但一个写好的 Skill只要你把步骤和参数写明白十条笔记里至少八条是能用的。这对内容账号的更新频率和调性一致性来说太重要了。1.2 我把小红书获客拆成了 6 个固定节点我一开始其实没想着做一整套是做着做着发现它必然变成一个体系。现在我在用的这套“跑客户”流程大致包含 6 个节点选题根据行业关键词和平台热点产出 30 天内容日历写正文把选题变成完整的小红书笔记包括标题、正文、标签、评论区引导做封面根据笔记主题生成 3:4 比例的封面图和配图合规审核检查极端词、导流词、违禁词同时生成发布排期评论区维护基于预设话术回复评论把高意向评论筛选出来线索跟进从私信和评论中提取潜在客户打标、归档、生成跟进草稿。你可以看到这六个节点全部是确定性任务输入什么、输出什么非常清楚只是以前靠人肉现在靠 Skill。我实际跑起来之后原来一天只能产出 2 篇内容现在半天能跑出一周的存量还能顺手把私信线索整理好。不是说 AI 取代了人而是把重复度最高、最不产生认知增量的部分交出去了。1.3 为什么不能用普通提示词硬凑很多人问不就是写提示词吗直接让 Claude 按固定格式输出不就行了我一开始也是这么干的后来发现三个问题。第一没有记忆和自检。普通提示词问一次管一次今天让 AI 别用极限词明天它又忘了你得每次都写一遍。Skills 可以在SKILL.md里写“输出前必须自查以下 5 项”让模型自己在生成时完成检查。第二没法挂脚本。选题需要看数据、复盘需要算指标纯提示词做不了任何计算和数据读取。第三没法团队复用。提示词散落在聊天记录里而 Skills 是一个目录可以直接放进 Git 仓库团队里谁都能用新人也少踩坑。所以说从提示词到 Skills不是换了个名字而是把“一次性对话”变成了“可复用的业务资产”。2. 环境搭建Skills 放在哪、如何安装与共享2.1 工具选型Claude Code、Codex、Cursor、OpenCode 怎么选Skills 的生态目前和编程智能体绑定得很深不同工具对它的支持程度不太一样。我自己主力用的是 Claude Code但也在 Cursor 和 Codex 里跑过同一套目录。下面这个表是我实际使用下来的感受工具Skills 支持方式上手难度适合场景Claude Code原生支持.claude/skills目录生态最全低个人/小团队做自动化内容生产Cursor可通过.cursor/rules和社区方案加载中更依赖编辑器内完成内容创作的人Codex CLI支持 AGENTS.md 和自定义命令对 Skills 兼容度在提升中喜欢命令行操作、有开发能力的用户OpenCode开源配置灵活中高愿意折腾、想完全掌控目录结构的用户我的建议是如果你只是想快速把“小红书获客”这套流程跑起来直接选 Claude Code原因很简单——社区里现成的 Skills 最多照搬成本最低。Cursor 的优势在于编辑器体验但配置 Skills 的方式在不同版本里差异较大需要花时间看文档。Codex CLI 和 OpenCode 更适合愿意折腾的人它们的好处是目录自由度更高可以自定义加载逻辑。2.2 一套标准目录结构长什么样目录结构是整个 Skills 体系的骨架。我目前的工作目录大概是这样的skills/ ├── xiaohongshu-select-topic/ │ ├── SKILL.md │ ├── scripts/ │ │ └── hot_keywords.py │ └── templates/ │ └── topic_card.md ├── xiaohongshu-note-writer/ │ ├── SKILL.md │ └── templates/ │ ├── note_template.md │ └── tags_template.txt ├── xiaohongshu-cover-generator/ │ ├── SKILL.md │ └── scripts/ │ └── generate_cover.py ├── xiaohongshu-review/ │ ├── SKILL.md │ └── rules/ │ └── forbidden_words.txt ├── xiaohongshu-comment-reply/ │ ├── SKILL.md │ └── templates/ │ └── reply_levels.md └── xiaohongshu-leads/ ├── SKILL.md └── scripts/ └── extract_leads.py每个子目录就是一个独立 Skill内部至少有一个SKILL.md。这个文件是核心它决定了模型怎么理解任务。如果某个 Skill 需要执行脚本就把脚本放在scripts/把固定模板放在templates/。这种结构的最大好处是每个 Skill 可以独立维护、独立测试。你想改封面生成逻辑只需要动xiaohongshu-cover-generator不用碰其他目录。2.3 从 GitHub 上安装别人写好的 Skills我目前常用的来源主要是几个比较出名的聚合仓库比如 Awesome Claude Skills、Typesafe AI Skills 的 GitHub 仓库还有社区讨论度很高的 superpower skills。这些仓库里既有通用型技能包也有针对特定场景比如图片生成、LaTeX 排版的专用技能包。手动安装的步骤其实很简单把仓库 clone 到本地或者直接下载 zip 包解压找到里面你想要的那个 Skill 子目录整体复制到你的skills目录重启工具或者在对话里问一句“你目前能看到哪些 Skills”确认加载成功。需要注意一个细节并不是所有仓库里的目录都能直接当 Skill 用。有些仓库是纯文档汇总有些才是技能包本体。判断标准是看你复制的目录里有没有SKILL.md如果没有那它大概率只是介绍页。安全方面也要上点心。装第三方 Skills 之前至少扫一眼SKILL.md和scripts里的内容。社区里大多数是正经的自动化工具但你不能保证每一个都没有偷 API Key 或者上传数据的逻辑。我的习惯是凡是涉及网络请求的脚本必须自己过一遍再启用。2.4 多工具共享 Skills 目录的配置思路如果你和我一样Claude Code、Cursor、Codebuddy 要轮着用那就要解决“同一套 Skills 目录怎么共享”的问题。最省事的方案是建立一个独立的skills目录放在一个所有工具都能读到的地方比如用户主目录或者项目根目录然后让每个工具都指向它。Claude Code 是看.claude/skills目录Cursor 更习惯项目级配置Codebuddy 和 Claude Code 的目录协议基本兼容可以直接指向同一个位置。实际操作中我建议以 SKILL.md 为标准其他工具只要实现了“读取目录里的 markdown 并注入上下文”的机制基本都能兼容。如果遇到某个工具不识别多数是因为它对 frontmatter 的字段有额外要求加一个name和description字段通常能解决。3. 核心 Skills 逐个拆解笔记生产与线索识别3.1 选题与内容日历 Skill让内容方向不靠拍脑袋我做选题的 Skill 时给它定的输入是行业关键词、目标用户画像、近期的平台热点以及我自己账号的历史笔记数据。输出是一份 30 天内容日历里面每一行都有发布日期、选题类型、核心痛点、目标标题方向、覆盖的标签。这个 Skill 的实际执行流程是这样的先让模型理解我给的行业关键词然后读一读我历史笔记里互动率较高的内容再结合平台热搜榜产出一批“用户真的在搜”的选题。关键是要告诉它不要模仿爆款文案的字面而是提炼出爆款背后的用户需求。比如一篇“应届生如何写简历”爆了不代表你要再写一篇一模一样的而是说明“简历焦虑”这个需求正在上升换个行业、换个角度切进去同样有机会。实操时我建议把产出量都调大一点比如一次生成 30 个选题再人工砍到 20 个。AI 生成的选题往往偏保守人工介入的价值是去掉“泛泛而谈”的留下“具体、有争议、有情绪”的。3.2 笔记正文生成 Skill 的模板与参数写正文的 Skill 是整个体系里我用得最多的一个。它接收选题、参考素材、语气、目标人群四个输入输出五样东西3 个标题候选、正文、标签、首图建议、评论区置顶引导。一个精简的SKILL.md大概是这种感觉--- name: xiaohongshu-note-writer description: 根据选题和素材生成完整的小红书笔记 version: 1.1.0 --- ## 任务 根据输入选题和素材产出一篇符合小红书调性的笔记。 ## 输入参数 - topic: 选题标题 - material: 素材数据或链接摘要 - tone: 语气风格专业/亲切/犀利 - target: 目标人群描述 ## 执行步骤 1. 分析选题背后的用户痛点 2. 写出 3 个标题候选前 20 字内要有明确结果 3. 正文控制在 800 字以内前 3 行必须能引起好奇 4. 生成 8-12 个标签不能用与内容无关的大流量词 5. 输出评论区置顶引导引导用户留下互动 ## 禁止事项 - 不使用“最后”“总之”等总结词开头 - 不虚构个人经历 - 不出现绝对化宣传语 - 不在正文中直接引导站外交易 ## 自检清单 - [ ] 是否包含 3 个标题候选 - [ ] 正文前 3 行是否足够吸引人 - [ ] 标签是否与内容强相关你会注意到我把“禁止事项”写得很具体因为模型如果不被明确约束非常容易把内容写得像广告或者堆一堆与内容无关的热门标签。只有把红线写进 Skill模型才能在生成时主动避开这也是它和普通提示词最大的区别。3.3 封面图与图片生成 Skill比例和文字层级是关键封面这个环节我踩过不少坑。小红书封面比例最好是 3:4文字信息要足够大颜色要符合品类调性。我一开始让模型随便生图结果不是比例不对就是文字太乱根本没法用。后来我做的封面 Skill 有两套方案方案 A调用可脚本化的图片生成 API输入文案、风格关键词、尺寸参数900x1200直接输出图片文件方案 B先生成一张带排版信息的 HTML/SVG 模板再用无头浏览器截图。方案 A 适合“配图”方案 B 适合“文字封面”。很多“图片生成 skills 安装包”其实默认只提供方案 A但小红书封面很多时候需要的是干净的底图加清晰的主题文字这种场景下方案 B 反而更容易控制。我在 Skill 里会让模型先判断内容属于哪一类如果是以情绪、经验分享为主就选方案 B如果是以多图展示为主就选方案 A。另外千万不要只依赖单一生成通道。API 有波动我可以接受但一次生成失败就卡住整个流程绝对不能接受。我会在 Skill 里配一个“降级方案”也就是某个生成通道失败时自动切换到备选通道保证流水线不断。3.4 合规审核与发布排期 Skill不整改的稿子不发布合规审核是我认为最不能省的一个环节。小红书对营销内容的限制是真实存在的涉及绝对化用语、导流意图轻则限流重则违规。与其靠手工一遍遍检查不如把这个检查标准固化到 Skill 里。我这边做了一个xiaohongshu-review的 Skill输入是一篇完整笔记输出是合规检查结果和修改建议。它检查的点包括有没有“最”“第一”“100%”这类极限词有没有引导用户到站外下单有没有虚构使用体验有没有搬运痕迹。同时它还会给出一条“平台规则修正建议”比如把“加我微信”改成“评论区留言”。审核通过之后顺势就接一个发布排期 Skill。它接收一周内审核过的内容根据用户活跃时段生成具体发布日期和发布时间。比如护肤类账号可能晚上 9 点发布效果最好职场类账号可能中午 12 点半更合适这些经验都可以做成参数写进去让模型排期时自动参考。3.5 评论区运营与线索识别 Skill把流量变成对话内容发布出去真正的获客动作才开始。评论区的回复质量决定了用户愿不愿意私信你。我这里做了一个三级话术库公开评论回复简短、有用、有温度不暴露联系方式私信初步回复确认用户具体问题给一份基础资料或解答框架重点客户跟进当用户连续两次询问时主动约时间进一步沟通。线索识别 Skill 做的事就是把私信和评论里的文字抓出来按意向等级打上 S/A/B 标签。S 代表问题具体、需求明确、有预算A 代表表达过兴趣、但还处于了解阶段B 代表只是来学习的路粉。它还会把每个线索的原始对话、主页简介、意向等级一起落到表格里。这里要非常强调一点AI 可以识别线索可以起草回复但最终发送给客户的每一句话我都建议人工过一遍。不要用脚本去批量私信轰炸这不仅不体面还容易触发平台风控。自动化只负责把重复劳动砍掉人与人之间的信任感还是要靠人建立。4. 从提示词到 Skills自己上手开发技能包的完整思路4.1 什么时候才值得把一段提示词做成 Skill判断标准其实很简单同一个任务你重复了三次以上做的过程还要反复改参数那它就应该被做成 Skill。如果你只是偶尔写一篇笔记直接写提示词就够了没必要为了偶尔一次的事情建目录、写脚本。另外两种值得做 Skill 的情况这个任务需要多人配合做出一个标准文件可以减少沟通成本这个任务有明确的判定标准比如“有没有违规词”“输出格式是否对齐”可以让模型自己完成自检。我举一个例子之前帮朋友做数学建模比赛的时候他们需要统一的论文排版本地文件我就把一个 LaTeX 排版 Skill 放进团队仓库谁需要排版直接调。这其实就是同一套方法的迁移先识别重复场景再把它固化成技能包。小红书获客、数学建模、LaTeX 排版本质上没有区别。4.2 SKILL.md 怎么写才不废话写 SKILL.md 最大的误区是把它当成“功能说明书”写得又长又空。模型读不懂你也不想维护。我的写法是做到三件事告诉它什么时候触发、按什么顺序做、什么不能做。一个比较舒服的模板结构是--- name: skill-name description: 一句话说清楚这个技能解决什么问题 version: 1.0.0 --- ## 任务背景 一句话说明为什么存在这个技能什么时候会用到它。 ## 输入 - 参数1: - 参数2: ## 执行步骤 编号列表每一步都是模型可以直接执行的指令 ## 输出格式 明确产出物的格式最好给一个示例 ## 禁止事项 把踩过的坑写成负面约束写的时候记住一个原则步骤写动作不写态度。不要写“请仔细分析”要写“先提取用户问题中的三个关键词再结合标签库匹配”不要写“注意质量”要写“每条回复不得超过 60 字”。模型是个执行力很强的员工但它需要的是具体指令。4.3 脚本、模板和 API Key 的管理方式一个成熟 Skill 往往不只是文字还会带脚本。比如我封面 Skill 里就放了一个generate_cover.py负责调图片生成接口并保存文件。写这类脚本时有一个底线不要把 API Key 写死在代码里。用环境变量读取配合.env文件管理密钥。templates目录的价值是兜底。我在笔记 Skill 里放了两个模板文件一个空白的正文结构模板一个是标签格式模板。模型看到模板后输出会稳定很多。如果没有模板它很容易生成越来越长的“自由发挥内容”让你后期还得一遍遍改。维护方面我建议给 Skills 用 Git 管起来。每次改执行流程、调参数都留一个提交记录。社区里也有人专门分享“清理 Skills 的方法”核心就三条命名统一、内容去重、不用的及时删。你不想三个月后面对一个两百个目录的 skills 文件夹也没人知道里面哪些还能用。5. 数据复盘与客户跟进获客闭环的最后一公里5.1 数据复盘 Skill让每周复盘从半天缩到 20 分钟数据复盘是我一开始完全没做后来被现实教育了才补上的环节。前两个月我只看“发了多少篇”“涨了多少粉”但这两个指标根本说明不了客户从哪里来。后来我做了复盘 Skill输入是平台导出的数据 CSV输出是一份周报每条笔记的曝光、点击率、互动率、私信转化率以及排名前三的内容特征。这个 Skill 里我会定义好统计口径比如“私信转化率 私信人数 / 笔记阅读量”免得 AI 自己发挥定义指标。它还会对比“数据最好的 3 篇”和“数据最差的 3 篇”找出差异点。结果往往是数据好的笔记不是在文案上多出彩而是选题“恰好踩中了用户当下的焦虑点”数据差的则普遍有个共性——标题看起来很用力但内容给不到对应的干货。5.2 客户跟进 SkillAI 只做草稿决定权留给人线索进表之后下一步是跟进。我做的跟进 Skill 负责三件事根据线索原来的对话生成首次跟进草稿按意向等级分层排序记录每次跟进时间避免漏人。首次跟进的草稿有个固定的公式称呼 来源说明 确认对方问题 提供一个小价值 给出下一步动作。比如对方问过“你这个资料怎么领”草稿就是“嗨看了你在 XX 笔记的留言那份资料我可以直接发你另外你之前提到的 XX 问题我整理了两条方法你看 3 分钟够不够”。这个 Skill 我坚持让它只产出草稿因为信息发出去之前人是必须复核的。AI 让效率变高但客户关系这种东西靠的是每次对话里那一点点“我在认真对待你”的感觉这是模型给不了的。6. 常见问题与避坑实录6.1 为什么我的 Skill 总是加载不出来这是出现频率最高的问题九个里面有八个是路径不对。有些工具读的是项目目录下的.claude/skills有些读的是用户主目录下的~/.claude/skills你放错层级技能包就永远不在上下文里。另外检查一下 SKILL.md 的 frontmatter 格式它必须严格放在文件最开头中间不能有别的文字。字段至少要有name和description很多工具主要靠description来判断是否把技能注入上下文。改完之后不要只凭感觉验证直接在对话里问“你能看到哪些 skills”让模型把当前技能列表列出来最直观。6.2 多工具共用 Skills 时的兼容性坑Codebuddy 和 Claude Code 的目录基本可以共用但也要注意两个坑。第一是文件权限A 工具创建的目录和文件B 工具可能没有写入权限表现是“读得到但改了不生效”第二是 frontmatter 字段差异Codebuddy 对新字段兼容通常没问题但有些工具会比较挑报错时优先看日志里提示的字段。Cursor 的配置方式不一样它更偏向项目级 rules。如果你想在 Cursor 里用同一套技能包社区目前的做法是写一个.cursor/rules/skills.mdc把 skill 的执行步骤以规则形式声明进去。Codex 则可以在 AGENTS.md 里引用对应目录。这里没有银弹以 SKILL.md 为源、用不同工具的“适配层”是最不费心的方案。6.3 内容生产里的高发问题与排查速查最后整理一张速查表都是我实际踩过、也帮别人排查过的坑现象原因处理方式笔记发出去没有流量标题或正文里带了导流词、极限词跑一遍合规 Skill删掉敏感表达后重发生成的封面比例不对没有在输入里声明 3:4 比例把“分辨率必须 900x1200”写进 SKILL.md文案千篇一律模板感严重指令里缺少差异化要求加入“结合素材中的具体数据/案例”这步私信回复像机器人没有进行人工复核直接用了草稿把跟进 Skill 设置为只产草稿发送前要人工确认Skill 偶尔不生效模型上下文过长技能未被注入精简 Skill 描述删掉过长的历史对话脚本报错找不到 API Key脚本里写死密钥或.env没被加载统一用环境变量读取检查.gitignore我自己的经验是所有 Skill 都是会迭代的不是写完就完事。每次生成的笔记被限流、每次客户反馈“你这个说得太官方了”都是反哺给 Skill 的素材。把反面案例写进“禁止事项”或者“自检清单”下一次模型就会主动避开。最后再说一点个人体会。我这套跑完小红书找客户的 Skills核心价值不是“替代人”而是把从选题到线索的每个环节变成可审视、可优化的节点。真正决定效果的永远是你对用户需求的理解以及每次内容背后那点真实经验。把重复交给 Skills把人解放出来去做判断这套流程才算真正闭环。