1. 找客户这件事,为什么值得用一整套 Skills 来跑
1.1 先说一个我实际经历过的时间黑洞
两个月前帮一个做女性个护的品牌搭小红书获客流程,对方给的诉求特别朴素:每天有人在小红书上问“这个在哪买”“有没有链接”,但我们根本盯不过来,而且就算看到了,也不知道该先回复谁、谁才是真的买家。
我一开始也是按老思路来,写 prompt、开多个 Claude 窗口、手动复制笔记文案和评论区,再一张一张整理表格。听起来不复杂,但是真跑起来非常痛苦:一篇爆文下面可能有两三百条评论,里面真正有购买意向的“求链接”“求推荐”可能只有七八条,剩下全是“蹲一个”“礼貌问价”“姐妹求私”,你逐条刷完眼睛都花了,还得判断这个人的主页是不是代购、是不是同行、是不是已经买过竞品了。
后来我停下来想了想,这件事本质上是:输入关键词 → 生成搜索词 → 抓取公开笔记 → 提取评论区信号 → 做账号画像 → 打分排序 → 生成跟进话术 → 沉淀成表格。这其实是一条非常标准的流水线,而流水线上的每一步都是可重复、有规则、能写成指令的。于是我把这整条流水线拆成了一整套 Skills,让 Claude Code 作为总调度,跑完之后整个人轻松了不止一个量级。这篇文章就把这套东西完整拆给你看。
1.2 先对齐一个概念:我说的 Skills 到底是什么
最近半年 AI 圈子里最常见的热词就是 Skills,但很多人把它理解成“一个更长的 prompt”,这个理解不够。Anthropic 官方最早提出 Agent Skills 的时候,定位是“给 Agent 的专项能力包”:一个 Skill 是一个目录,里面有SKILL.md说明文件、可能有配套的脚本、模板、示例,它比 prompt 多了一层“可执行工具箱”的意思。
举个例子。你写一段 prompt 让模型“帮我想出 30 个小红书搜索词”,模型也能做,但每次都要重新解释背景、格式、目标,跑出来的东西还不稳定。如果做成 Skill,它就是一个固定目录,SKILL.md里写清楚这个技能解决什么问题、输入输出长什么样、有哪些规范;模型被唤醒之后,直接按这套流程走,还能调用目录里的 Python 脚本去批量处理数据。Skills 的价值不是让模型“更聪明”,而是让模型的输出更稳定、更容易被下一个环节接着用。
所以“一套 Skills”和“一个好 prompt”最大的区别是:前者是一套模块化的生产流水线,后者是一次性的对话约定。多个 Skills 组合起来,才能覆盖“跑完小红书找客户”这种跨步骤的复杂任务。
1.3 为什么我敢让 AI 去小红书“找客户”
先说明一点:小红书的搜索、笔记内容、评论区,都是公开可见的信息,我们做的是在公开信息层面做结构化整理,不涉及任何绕过登录或反爬机制的操作。实际操作中,我会让 Agent 把搜索词、笔记 ID、评论片段整理出来,真正把页面内容抓下来这一步由我人工配合浏览或者用浏览器里已登录的页面把文本复制给模型。这不是什么高深技巧,但胜在稳妥。
选小红书作为获客渠道,是因为它的用户行为信号非常明显。很多人认为小红书是种草平台,但其实它同时是一个“被忽略的 B 端线索池”。你在评论区经常能看到“姐妹这个在哪买”“求链接”“多少钱呀”,这种评论的购买意向比表单留资还强。还有一类是博主主页简介里写着“货源对接”“找代理”,这摆明了就是做供应链或分销的潜在客户。传统搜索引擎搜出来的可能是官网、行业报告,但小红书搜出来的是一群带着真实消费意图的人。
这套思路适合谁?适合做电商、私域、本地服务、To C 高客单产品的运营和销售,也适合代运营公司给客户做线索盘点。接下来的内容,我会把整套 Skills 怎么设计、怎么写、怎么装进 Claude Code / Codex / Cursor,以及真实跑了一遍之后的坑,全部展开讲。
2. 一套小红书获客 Skills 的目录拆解:六个子技能组成一个闭环
2.1 管道式结构:一个技能的输出,是下一个技能的输入
我在设计这套 Skills 的时候,没有做一个“万能的小红书获客技能”,而是拆成了六个各司其职的小技能。原因是 Agent 每次能被唤醒的上下文是有限的,如果让一个 Skill 干所有事情,指令会非常臃肿,模型很容易在执行中途跑偏;拆成管道式之后,每一步的输出都固化成一个结构,下一步直接读上一步的结果继续干,这样每一步都能单独验证、单独调优。
管道是这样的:关键词扩展 → 笔记采集 → 评论区线索提取 → 账号画像评分 → 私信话术生成 → 线索日报汇总。这六步从“找什么人”一路走到“跟他说什么”,落地的时候是完整闭环的。
你可能会问,为什么需要“关键词扩展”这一步?很多人找客户就是直接搜产品词,比如“脱毛仪”,但小红书用户的表达习惯里,“脱毛仪”和“家用脱毛仪哪个牌子好”“激光脱毛仪测评”背后的用户行为完全不同。前者可能是随便逛逛,后者几乎就是在研究购买。关键词扩展器干的事,就是把这些搜索意图铺开,让后续抓取到的内容更接近“正在考虑购买的人”,而不是“只是看看的人”。
2.2 六个子技能各自的职责、输入和输出
我把这套 Skills 的职责边界拉了一张表,后面每个 Skill 怎么开发都围绕这张表展开:
| 子技能 | 核心任务 | 主要输入 | 核心输出 |
|---|---|---|---|
| keyword-expander | 扩展搜索词,覆盖不同购买阶段 | 1-5 个种子词 | 按意图分类的关键词清单(种草类/对比类/痛点类/购买类) |
| note-collector | 从搜索结果中筛选值得分析的笔记 | 关键词清单、笔记标题链接 | 笔记清单(标题/正文/点赞量/评论量/发布时间) |
| comment-lead-extractor | 从评论区提取有购买意向的账号 | 笔记正文和评论文本 | 线索 JSON(用户名/昵称/意向信号/原文片段) |
| persona-scorer | 给每条线索做账号画像和评分 | 线索列表、个人主页简介 | 1-5 分评分和理由 |
| outreach-writer | 生成私信/评论回复话术 | 评分高的线索列表 | 个性化话术文案 |
| lead-report-builder | 汇总当天线索,输出可执行的跟进表 | 以上全部输出 | Markdown 表格/日报 |
这六个技能不是上下级关系,而是前后道工序。keyword-expander 生成的词列表,note-collector 拿去筛笔记;comment-lead-extractor 提取出来的线索,persona-scorer 拿去评分;评分高的线索才轮到 outreach-writer 写话术;lead-report-builder 最后把全部结果汇总成一张能直接给销售团队用的表。
2.3 但必须划一条红线:哪些信号该抓,哪些不该碰
这里要特别说一下合规边界。从公开页面上分析用户行为、识别购买意向,没有问题;但如果有意去批量采集用户隐私信息、绕过访问限制、频繁请求接口,那就不行了。我的做法是全程保持“半自动”:Agent 负责搜词、分析、写话术、排版,页面内容由人工配合读取后贴给 Agent。频率上也控制得很保守,同一个关键词一天最多跑两轮,中午一轮、晚上一轮,够用了。
还有一条红线是私信话术。小红书对导流行为的管控很严,私信里直接甩微信号很容易被限甚至封号。所以 outreach-writer 这个 Skill 我写死了规则:不会生成包含微信号、手机号、二维码的话术,只生成有信息量、能引发对方回复的开场,后续联系方式交换放到对话自然发生之后。这一点在实操中也非常重要,后面我会专门展开。
3. 把这些 Skill 做出来:SKILL.md 怎么写才不会被模型用偏
3.1 目录长什么样
一个标准的 Skills 目录,长这样:
skills/ xiaohongshu-keyword-expander/ SKILL.md scripts/ expand.py examples/ good_keywords.md bad_keywords.md own-lead-scorer/ SKILL.md scripts/ score.py templates/ lead_table.md核心文件是SKILL.md,它是一个带 YAML frontmatter 的 Markdown 文件,模型会先读 frontmatter 里的name和description来判断“什么时候该用这个技能”。很多人在这一步就踩坑了,description写得太宽泛,比如“处理小红书内容”,结果模型什么任务都想调用它;正确写法是写清楚“在什么条件下使用、输入是什么、输出是什么、明确不需要做什么”。
scripts/里放的是可以执行的 Python 或 shell 脚本,这些脚本最好设计成从 stdin 读数据、往 stdout 输出结果,这样 Agent 可以直接调用,不需要处理额外文件权限问题。examples/放正反例子,这一步看着不起眼,但对模型理解你的预期帮助极大。
3.2 关键词扩展器的 SKILL.md 核心片段
下面这个例子是 keyword-expander 的简化版 SKILL.md,我保留了核心逻辑。
--- name: xiaohongshu-keyword-expander description: 适用于从小红书寻找潜在客户、制定搜索关键词的场景。输入1-5个种子行业词,输出按搜索意图分类的关键词清单。不要在做标题文案优化时使用。 --- # 小红书关键词扩展 你是一名熟悉小红书搜索行为的获客策略师。根据输入的种子词,按以下词根库生成关键词: - 种草词根:测评、好物、分享、安利、记录 - 对比词根:哪个牌子好、对比、还是、怎么选 - 痛点词根:踩雷、智商税、到底有没有用、求避雷 - 购买词根:在哪买、找代购、求链接、有货源吗、多少钱 每个关键词必须满足下面两个条件之一: 1. 用户有正在搜索比较的行为; 2. 用户有明确购买/找货源的表达。 输出要求:JSON 数组,字段为 {"keyword": "xxx", "intent": "buying|comparing|painpoint|seeding", "reason": "为什么这个词能筛出潜在客户"}。 最后单独给一行“建议首轮搜索的15个词”,尽量覆盖四种意图。这段指令的要点在于:它把“什么词值得搜”的决策标准写成了模型能逐条检验的清单。后续模型跑出来的词,不会全是“脱毛仪好用吗”这种太泛的,也不会全是“哪里有卖”这种太窄的,四类意图都有覆盖。你完全可以照着这个结构扩展你自己的行业词根。
3.3 评论区线索提取器:输出契约比指令更重要
小红书找客户,真正值钱的是评论区,不是笔记正文。一篇笔记可能是品牌方的软文,但评论区里“姐妹求私”“怎么买”“礼貌问价”这些真实信号是装不出来的。所以 comment-lead-extractor 这个 Skill 的关键是定义好“什么样的评论算有购买意向”。
我在 SKILL.md 里写死了信号词库,同时强调模型要做语义判断而非简单字符串匹配:
--- name: comment-lead-extractor description: 从小红书笔记正文和评论中提取有购买意向的潜在客户线索。输入笔记标题+正文+评论列表,输出线索JSON。不要用于抓取他人隐私信息。 --- # 评论线索提取器 识别以下明确购买意向信号: - 直接询问:求链接、在哪买、怎么买、多少钱、有链接吗 - 间接咨询:礼貌问价、蹲一个、求推荐、有姐妹知道吗、还能买到吗 - 渠道意图:有货源吗、找代理、能不能代发、想入代理 忽略以下内容: - 纯吹捧评论:太美了、好喜欢、拍得真好 - 闲聊评论:博主好漂亮、羡慕了 - 非商业信息:同款穿搭、项链是哪家的(除非明显指向商品) 输出 JSON:{"leads": [{"username": "xxx", "intent_signal": "求链接", "snippet": "原文片段", "note_title": "xx"}]}模型对“礼貌问价”这种隐晦表达是能识别的,但如果我不给“忽略什么”这条约束,它会把 50% 的评论都当成线索。这里的原则是:给正例,也给反例;给标准,也给边界。
3.4 打分脚本和话术模板:把判断规则写成模型知道怎么用的代码
persona-scorer 这个 Skill 我配了一个score.py脚本,逻辑非常简单:输入一段主页简介和几条行为特征,输出一个 1-5 分。判断维度包括:账号是否高频发布同品类内容、简介里有没有招商/代购/供应链关键词、评论区的意向表达是否明确、账号最近是否活跃。排序后的结果,由模型生成推荐跟进理由。
这里有个经验:脚本别写复杂,复杂脚本容易出错,Agent 调试成本很高。用 Python 写个几十行的规则打分就行,核心判断还是交给模型。真正决定分数质量的不是代码,而是你传递给模型的特征维度。我自己的做法是,把评分规则用中文表格写在 SKILL.md 里,脚本只做加减分计算,这样以后想调权重大改 Markdown 就行,不用改代码。
4. 装进 Claude Code / Codex / Cursor,并跑通一整条流程
4.1 不同工具装 Skills 的方式
这套 Skills 装到不同工具里其实路径都差不多,本质就是放到工具约定的 skills 目录下。我整理了一张常见的目录对照表:
| 工具 | 推荐放置位置 | 备注 |
|---|---|---|
| Claude Code | ~/.claude/skills/或项目.claude/skills/ | 也支持直接claude install-skill安装本地目录 |
| Codex | ~/.codex/skills/或项目.codex/skills/ | 配置里声明启用 skills 后即可 |
| Cursor | 项目.cursor/skills/ | Cursor 会根据目录自动识别 |
| OpenCode | ~/.opencode/skills/ | 社区方案里比较常见 |
如果你从 GitHub 上的 awesome-claude-skills 之类仓库下载别人做好的 Skills,手动装也很简单:下载目录,放进对应的 skills 目录,确保目录名和 SKILL.md 里的name一致,然后重启会话就行。Community 里流传的“codebuddy 和 Claude Code 公用 skills 目录”我也试过,很多场景是可以共用的,因为它们底层都读同一套 SKILL.md 规范,只是命名空间隔离要注意一下,别两个工具的 skill 同名互相覆盖。
4.2 给 Agent 下第一道完整任务
装好之后,最难的一步来了:怎么给 Agent 下任务,让它把整条流水线跑起来。我实际在 Claude Code 里下达的总任务是这一句话,你可以直接抄走改参数:
我现在负责一个女性个护品牌的小红书获客,想找两种人: 1. 有明确购买意向的 C 端用户(评论区出现求链接/怎么买/多少钱); 2. 能做分销/团购的博主或代购(主页简介出现代购/招代理/供应链/一件代发)。 请按这套流程执行: 第一步,用 xiaohongshu-keyword-expander 扩展种子词“脱毛仪”“家用脱毛仪”“美容仪”; 第二步,把扩展出来的词逐个在小红书网页版搜索,收集点赞量大于100的笔记标题和链接; 第三步,我手动把每篇笔记的正文和评论区文本发给你,你用 comment-lead-extractor 提取线索; 第四步,对每条线索用 persona-scorer 评分,优先留下评分>=4的; 第五步,给前20个高分线索用 outreach-writer 写开场私信,要求口语化、不出现微信号二维码; 第六步,用 lead-report-builder 输出一张 Markdown 表格,字段包括:用户名、主页链接、意向信号、评分、建议跟进话术。注意这句话里的几个细节:我没让 Agent 自己去火星上找数据,而是明确告诉它“关键页面内容由人工贴给你”,避免它因为无法真正访问小红书而开始瞎编笔记数据;同时我把每一步需要的组件名都写了出来,模型在能力允许的情况下会主动调度对应的 Skills 或脚本。Claude Code 这类 Agent 工具看到步骤描述后,会优先调用与自己技能库匹配的子技能,这正是“一套 Skills”的威力所在。
4.3 一次真实执行:从两个种子词到 20 个可跟进线索
我用上面的流程实际跑过一轮,过程给你复盘一下。
种子词是“脱毛仪”和“家用脱毛仪”,keyword-expander 一轮输出了 38 个词,覆盖了“脱毛仪测评”“脱毛仪是智商税吗”“脱毛仪在哪买”“脱毛仪代购”“脱毛仪货源”等,四类意图都有。
用这些词在网页版搜索后,筛出 62 篇点赞过 100 的笔记。我花了大约四十分钟把其中 30 篇内容相关的笔记正文和评论区贴给 Agent,comment-lead-extractor 一共提取出 18 条带明确购买意向的线索。印象比较深的一条线索是一个昵称带“XX美妆小铺”的用户,在一条脱毛仪测评笔记下面连着评论了三次“求链接”“有代理价吗”,persona-scorer 直接给了 5 分,理由是主页简介里有“代购 10 年”和“可代发”,这就是典型的渠道型客户。
最后 lead-report-builder 输出了一张表,我把关键字段简化放在下面:
| 用户名 | 意向信号 | 评分 | 建议动作 |
|---|---|---|---|
| XX美妆小铺 | 有代理价吗 | 5 | 私信告知可以沟通代理政策,先介绍产品线和售价体系 |
| 小眠不熬夜 | 求链接 求推荐 | 4 | 私信提供购买入口,附带对比说明 |
| 阿欣的日常 | 礼貌问价 | 3 | 先回复价格区间,再试探是否接受后续联系 |
整轮跑下来,包括我手工贴页面文本的时间,大概一个半小时。放在过去,光人工看那 62 篇笔记和几百条评论就得三四个小时,而且大概率漏掉一批优质线索。Agent 不累,不会看漏,这是实打实的效率提升。
4.4 为什么它能在中间结果上“自动接力”
很多人第一次用这套流程会问一个问题:Agent 怎么知道跑完第一步接着跑第二步?
答案藏在 SKILL.md 的输出设计里。我在每个技能里都约定了“输出的最后一段必须是一个下一步可读的结构”,比如 keyword-expander 输出的 JSON 文件名会被后续流程直接读到,comment-lead-extractor 输出的 leads 列表就是 persona-scorer 的输入。Agent 在执行的时候,会不断把上一步的结果回填到自己的上下文里,再去调度下一步的 Skill。这种“中间产物契约”是让整套流水线自动衔接的关键。
所以如果你也想复刻,我建议把每个 SKILL.md 里的“输出格式”当成头等大事来设计,宁可在一开始多花十分钟定义 JSON 字段,也不要让模型每次自由发挥。
5. 真实跑了一周之后,我踩过的坑和调整方向
5.1 别把“跑完”理解成无视平台规则
小红书反垃圾和反导流的力度比很多人想象中强。我第一周跑下来最大的感受是:这套 Skills 只能帮你做分析和整理,真正和用户建立联系的节奏还是得自己把握。
我是这样限制频率的:同一个账号,每天私信触达不超过 15 人,且每条私信都根据对方评论的上下文做了个性化定制;绝不群发同一条模板,绝不出现明显导流词汇。原因很简单,小红书的举报机制是用户一举报、平台就重点盯,你一旦被限流,前面辛苦筛出来的线索可能一条都触达不到,得不偿失。
5.2 Skills 自身的四个常见翻车点
跑了一周,Skills 本身我踩了四个坑,值得单独说:
第一,description写得太宽,Agent 乱调度。我自己一开始把 comment-lead-extractor 写成了“分析小红书笔记和评论”,结果模型在 keyword-expander 阶段就试图调用它。后来改成“从评论区提取购买意向线索”,误用率立刻降下来。
第二,输出格式没有固定成 JSON,导致后续步骤接不上。中途有一次 keyword-expander 输出的是自然语言列表,note-collector 没法直接读,整个管道断链,排错花了二十分钟。后来我在所有输出型 SKILL.md 里都写死“严格按照 JSON 数组输出”。
第三,脚本依赖复杂。我一开始给 scorer 写了一个需要联网更新词库的 Python 脚本,结果 Agent 沙箱里根本跑不了。改成纯本地规则打分后,再没出过问题。
第四,example 太少。模型在处理“忽略什么”时容易偏。系统把那些诸如“蹲一个”“礼貌问价”这类隐晦表达,既有正例也有反例写进 examples 之后,提取准确率明显提升,漏报率反而降低了。
5.3 线索只是起点,后面还差一套承接系统
这套 Skills 解决的是“找客户”,但它不负责“成交”。我实际跑完之后发现,真正有价值的是把线索沉淀下来,交给专人承接。
我给客户搭的流程是:Skills 跑出来的每日线索表,同步到飞书多维表格,由销售标注跟进状态;Agent 同时生成一条建议备注,比如“该线索是 C 端用户,倾向于比较价格”“该用户是渠道型,可以谈一件代发”。销售看到备注以后再做二次触达,这样 Agent 就不只是帮你省掉盯评论的时间,它还帮你把不同用户的需求给预分类了。
如果要把这套东西继续扩张,下一篇我想写的是怎么把小红书外的渠道(抖音评论区、知乎回答、论坛帖)也抽象成同一套 Skills。它们的底层逻辑是一样的,都是“从公开内容里识别购买信号,再结构化输出”。不过那是后话了,先把小红书的这套跑顺,已经足够让获客效率上一个台阶。
说回 Skills 本身,我现在越来越觉得,它真正厉害的并不是某个单独的提示词技巧,而是把“人的判断标准”复制成了模型能稳定执行的流程。找客户这种活儿,看起来是最不能被 AI 替代的,但拆到最后,它不过就是一套重复、有章法、需要极大耐心的工作。恰好,这套工作长在 Agent 的能力圈里。