1. 为什么我决定把整个小红书账号“做成一个 Skill”先说下背景。我是典型的“一个人运营一个小红书账号”的状态白天有本职工作晚上想认真更新内容但一直困在“想选题、憋文案、做图、发布、回评论、看数据”这个循环里。坚持日更两个月后我发现自己不是在创作是在消耗。选题靠刷热点文案靠硬写数据不好也不知道该调哪里每天单是打开小红书的时间就占掉至少两小时。后来我开始接触 Agent Skill 这个东西。Cursor、Claude Code 这些工具里都支持自定义 Skill简单说就是给 AI 助手一份结构化的操作手册告诉它“在什么情况下按什么步骤调用什么资源最终输出什么结果”。一开始我只是用它处理代码库任务有一天忽然冒出一个念头既然 Skill 能把复杂工作流固化下来那我的账号定位、选题方法、文案风格、发布流程、复盘逻辑能不能也全部固化成一个 Skill答案是能而且跑通之后效果远超我预期。这篇文章把所有实现细节拆给你包括我踩过的坑和调试过程中的取舍。你不需要完全复制我的做法但里面的模块划分、流程设计和避坑思路基本可以迁移到你自己的内容账号上。先说清楚一个概念免得后面混淆Skill 不是一段 Prompt。普通 Prompt 是“你帮我写一篇关于 XX 的小红书笔记”说完就完了下次还要重复。Skill 是一整套能力包里面包含触发条件、执行步骤、人格设定、素材库、工具脚本、输出模板甚至可以挂载代码帮你完成排版和发布动作。它解决的是“每次输出都完美继承我的方法和风格”的问题而不是“某一次输出还不错”的问题。还有一个需要区分的东西Skill 和 Agent 的关系。Agent 是干活的人Skill 是这个人掌握的专业技能手册。Agent 负责理解任务、拆解目标、调度工具Skill 负责告诉它“小红书这件事具体该怎么干”。做小红书 Skill 的本质就是把你脑子里的方法论外化成一份机器可执行的标准作业程序。我用的运行环境是 Claude Code它的 Skill 机制比较成熟支持 Markdown 格式的 SKILL.md 作为入口。你如果用的是其他支持自定义指令的 Agent 工具比如 Cursor Rules、Codex 的指令包原理也完全一样后面我给的目录结构可以做对应迁移。2. Skill 核心架构我把账号运营拆成了五个可独立升级的模块真正动手设计这个 Skill 的时候我第一件事不是写代码而是先把“我一个人运营小红书”这件事拆解成最小组成单元。拆完之后发现看起来复杂的运营工作其实只有五件事定方向、找话题、写内容、发出去、看反馈再调整。对应这五件事我把 Skill 分成了五个模块每个模块都是独立目录可以单独改、单独升级互不干扰。这也是做 Skill 和写普通提示词的本质差异之一普通提示词是流水账Skill 是模块化系统。2.1 账号定位模块不靠拍脑袋靠人物档案和内容矩阵定位这件事是最容易被忽视但容错率最低的环节。很多人做账号失败不是内容质量不行而是定位模糊今天发职场感悟明天发美食探店后天又发读书笔记算法没办法给你贴标签用户也没办法形成预期。我在 Skill 里放了一份persona.md也就是账号人设档案。里面写清楚几件事身份设定我是谁例如深夜还在加班的互联网运营人/二胎妈妈/程序员转行产品经理价值主张我持续分享的核心价值是什么内容边界什么内容绝对不碰防止账号定位漂移语言人格用词习惯、称呼方式、情绪基调。但这个档案不是写了一劳永逸的。更重要的是 Skill 里埋了一个内容矩阵表格把内容分成三条线给新用户看的“立人设内容”、给中需求用户看的“提供价值内容”、给老粉看的“建立深度连接内容”每条线的比例参考 5:3:2。每次 Agent 生成内容之前会先校验这条笔记落在矩阵的哪一格如果内容跟矩阵不匹配它会自动退回重新构思。这一步很关键它让定位真正落地成了规则而不是一句“垂直领域”的空话。2.2 选题引擎把“今天写啥”变成可批量生产的流水线做内容账号的人最深的一个痛点就是选题。我见过太多人倒在日更这一步不是写不动是“不知道写什么”。选题模块的核心设计思路是不要等灵感要建一个持续补给的选题池。我让 Skill 每周自动运行一次选题生成任务结合三个输入源我之前笔记里数据表现好的角度同领域头部账号最近的高互动话题用户评论区反复出现的高频问题。这三个输入源汇总之后它会按照“痛点程度、相关性、可写性、生命周期”四个维度打分筛选出 10 个候选选题存入选题库文件。每天日更时Agent 从选题库里取“今日推荐”而不是临时生成。这样避免了每天开写时大脑空白也保证了内容之间有关联性和连续性不是东一榔头西一棒子。2.3 写作模块核心是“风格锁”和“钩子库”写作模块是我迭代次数最多的部分。因为 AI 生成的内容有一个很明显的问题单看没什么毛病放一起全是同一个味道套话多、情绪假、没有记忆点。我做了两个东西来解决这个问题。第一个是风格锁Style Lock它不是一段“请用小红书风格写”这种模糊指令而是一个结构化约束文件里面包括句式节奏要求短句为主单段不超过 4 行表情和 emoji 的使用频率、位置上限控制在小红书用户能接受的范围不能像刷屏一样人称和语气的一致性用词黑名单禁用“众所周知”“总而言之”这类书面腔表达。第二个是钩子库Hooks Library。我把我见过的高打开率开头做了拆解总结出 6 种开头钩子模型比如“反常识结论式”“问题代入式”“过程悬念式”“身份共鸣式”“结果先行式”“踩坑警告式”。每次写作时Agent 需要至少尝试 3 种不同的钩子方向再从中选最优。整个过程不是随机的而是要跟选题定位匹配。2.4 发布动作模块用 Playwright 把“手动发笔记”变成“半自动发布”发布是小红书运营里最机械、最耗时的环节。每篇文章要填标题、写正文、加话题标签、传封面图有时候还要选合集、定时发布。全是重复点击非常适合用自动化工具处理。我的 Skill 里挂了一个 Playwright 脚本用来完成浏览器的自动登录、新建笔记、填充内容和发布动作。你可能会担心平台风控所以这里我必须强调我没有把发布做成完全无人值守的“黑灯运行”。脚本执行到发布前最后一个确认步骤时会停住等我人工检查一遍排版、内容、封面确认没有问题我再手动点发布按钮。这是自动化流程里故意保留的“人工确认节点”后面我会详细讲为什么。2.5 数据复盘模块把流量反馈喂回给 Skill形成迭代闭环复盘模块是让这个 Skill“活”起来的关键。我会定期从创作者后台导出笔记数据曝光、点击、收藏、评论、涨粉生成一个 CSV 文件放进 Skill 的数据目录。Agent 读取之后会做几件事对比近 7 天数据和之前的数据找出涨跌异常把表现最好的 3 篇笔记做特征拆解标题结构、话题选择、正文长度、封面风格更新选题池的权重哪些话题方向应该加大投入输出一份复盘报告和下一周期调整建议我确认后它会把建议落回 persona.md 和内容矩阵文件里。这一环的价值在于账号的进化不再依赖我的主观复盘。以前我最多看一眼数据感觉“这篇不错”但说不清到底哪里不错。现在系统会把“不错的原因”找出来沉淀成下一次可复用的规则。3. 核心实现从定位到日更的每一个环节具体怎么落地讲了模块设计下面讲实现。我会给出实际落地时的目录结构、关键文件内容片段和主要流程逻辑尽量还原到我当时在终端里敲出来的样子。3.1 Skill 目录结构一个账号就是一个目录树我先把 Skill 建成了一个独立目录放在 Claude Code 的 skills 目录下名字就叫xiaohongshu-ops结构如下xiaohongshu-ops/ ├── SKILL.md ├── profile/ │ ├── persona.md │ ├── audience.md │ └── content_matrix.md ├── ideas/ │ ├── generator.md │ └── idea_bank.json ├── editor/ │ ├── style_guide.md │ ├── hooks_library.md │ ├── headline_templates.md │ └── forbidden_words.txt ├── release/ │ ├── checklist.md │ ├── publish_config.json │ └── playwright/ │ └── publish_note.js └── review/ ├── analyze.py ├── metrics_schema.md └── retro_logs/每个目录对应第 2 节说的一个模块。这样做的好处是任何一个子模块有问题我只需要修改对应的那个文件不用动其他部分。比如发现风格锁太死板我就只打开 editor/style_guide.md 调整不会影响选题模块的运行。3.2 SKILL.md 入口文件Agent 每轮执行的“总指挥”SKILL.md 是整个 Skill 的入口Agent 会在相关任务触发时自动加载它。这个文件的写法决定了整个 Skill 的顺畅度。我当时是这么组织它的结构--- name: xiaohongshu-ops description: 小红书账号定位、选题、内容生产、发布复盘的全流程运营技能。 当用户需要更新小红书、生成笔记、复盘数据时使用。 --- # 小红书日更运营 Skill ## 核心原则 1. 先定位后内容。任何笔记生成前必须校验内容矩阵匹配度。 2. 风格锁必须生效禁止出现 forbidden_words.txt 中列出的词。 3. 发布前必须输出 checklist 供用户人工确认不擅自操作。 ## 标准工作流 - 每日更新读取 idea_bank.json → 按权重选取今日选题 → 按 style_guide 撰写初稿 → 生成 3 个标题选项 → 输出排版后的正文和话题建议 → 进入待发布检查。 - 每周复盘读取 review/retro_logs 最新数据 → 生成复盘报告 → 将结论写入 profile 和 ideas 模块。这个文件的核心作用是设定“运行边界”。我特别写清楚了“不擅自操作”和“先定位后内容”这两条因为 Agent 如果不加约束很可能会绕过定位校验直接给你写出一篇新内容。多跑几次你就会发现边界约束比能力要求更重要。3.3 人设档案示例定位不是一句话是一结构的约束下面是一段我从 persona.md 里精简出来的示例你可以直观感受一下“结构化人设档案”长什么样## 账号身份 - 身份标签30岁互联网从业者业余自媒体人 - 在写账号这件事上的优势一线实操经验非理论搬运 ## 价值主张 - 只分享我自己验证过的东西 - 不写“月入十万”“一夜爆红”这类浮夸内容 - 每篇笔记要回答一个问题读完这条读者能带走什么 ## 内容边界红线 - 不讨论任何敏感领域 - 不虚构数据不夸大效果 - 不用“震惊”“必看”等夸大标题词 - 不接无关联的广告 ## 语言人设 - 语气近乎聊天偶尔自嘲不端架子 - 句子短句多用标点断句 - 结尾习惯用一句“实操建议”或“个人经验”收尾3.4 选题池机制从“每天憋选题”到“每周补货”选题池我用了非常轻量的 JSON 文件没有引入数据库。每条记录大概长这样{ id: 1024, title: 一个人运营小红书我劝你不要只发一种内容, source: 评论区高频问题, topic_score: 8.5, fit_level: high, status: ready, created_at: 2025-06-10 }每次 Agent 生成新内容前会优先挑选status为ready且topic_score最高的那一条生成完成后把状态改成used。每周复盘时再根据当周表现给选题池补新货。这样保证每天启动时永远有一个已经成型的选题等着你而不是临时冥思苦想。真实跑下来这个机制最明显的体感是我每天打开电脑知道今天该干什么不用做决策只是执行创作焦虑一下就降下来了。3.5 写作流程中的“三次校验”标题、钩子、风格锁具体到每一篇笔记的生产我的 Skill 内嵌了一条三段式校验规则。Agent 写完初稿后不是直接交付而是依次执行标题校验从 headline_templates.md 中选择匹配的标题模板生成 3 个候选标题并检查是否触及平台标题红线比如“第一”“最”这类极限词。钩子校验检查正文前三行是否命中了 hooks_library.md 中至少一种钩子模型。如果前 3 行没有一个明确钩子直接重写开头。风格锁校验逐条检查 permission 和禁止项用 forbidden_words.txt 做关键词过滤同时评估句式长度和段落密度。这套校验跑完之后输出的稿件基本达到“像一个人写的”标准。但注意一开始这套流程非常容易让内容变得生硬因为 AI 一旦被太多规则约束就会过度谨慎写出来的文字缺一点人味儿。后来我在 style_guide.md 里加了一条非常奇怪的规则“允许偶尔啰嗦但必须诚实。”这个改动释放了 Agent 的表达自由度内容反而自然了。这也是我觉得做自动化内容最有意思的地方约束不是越多越好关键是找到让 AI 既有框架又有人味的那条线。3.6 发布自动化Playwright 脚本怎么嵌入 Skill发布模块我使用的是 Playwright 脚本配合一个固定的账号环境。整体流程如下环境准备用一个单独的浏览器上下文保持登录态。内容读取脚本从编辑模块生成好的待发布文件中读取标题、正文、标签。执行步骤打开创作中心 → 点击“发布笔记” → 上传封面图 → 填充标题正文 → 添加话题标签 → 选择合集分类 → 停在“发布按钮”前。人工确认脚本输出一个明确的提示等我按下“发布”。这里有一个安全和技术上的重要细节小红书这类内容平台的页面 DOM 结构随时可能变脚本的稳定性和失效概率你都难控制。所以我从来不维护复杂的自动上传、自动选择图片这类逻辑只让脚本完成“填写文本类内容”的动作图片上传这类操作尽量保留人工操作。自动化不是追求 100% 全自动而是把最枯燥的部分省掉剩余少量点击留给人这样最省心也最抗风险。3.7 复盘分析脚本把数据文件变成文档复盘模块我用 Python 写了一个 analyze.py逻辑非常简单读取 CSV → 关键指标排序 → 对比上周均值 → 输出结果文件。核心代码逻辑就几十行无非是数据清洗和 groupby 操作。真正有用的是它输出报告时触发的下一步动作如果某篇笔记的收藏率明显高于平均值它会把这篇笔记的“内容角度”回写进 persona 的价值主张如果某类标题点击率很低它会把这类模板标记为“低效”以后不再优先选择。这样就实现了“数据反馈驱动定位调整”的闭环。很多做号的人复盘做得非常粗略看一眼数据就完了。我的 Skill 把我观察数据、提取规律的过程固化成了代码逻辑哪怕我以后账号交给别人维护这套方法论也能稳定输出。4. 运行机制与踩坑实录日更自动化不是一个 Skill 文件就完事有了结构只完成了 50%。真正让它稳定跑下去还取决于运行机制和反复排错。这一节我把最容易出问题的几个点全部说清楚都是实打实踩出来的坑。4.1 触发方式与运行节奏不是让 AI 没事就自动跑Skill 本身不具备“自主行动”的能力它需要有任务请求来触发。我的实际运行节奏是这样的每天早上运行一次日更任务Agent 读取选题池生成今日内容和发布清单每周日晚运行一次复盘任务Agent 读取数据更新选题池和定位档案每月初我手动跑一次“定位校准任务”重新检查人设和内容矩阵确保没有跑偏。这三条触发节奏我都写进了 SKILL.md 的标准工作流里。这样 Agent 日常不会乱动只在指定场景按流程执行。这一点非常重要如果你让 Agent 一直自动运行很快它会给你生成大量同质化内容甚至误触发非目标动作。好的自动化不是时刻在跑而是在合适的时刻精准地跑。4.2 踩坑AI 内容的“保质期”问题内容生成多了以后我发现一个严重问题即使每篇单独看都合格连续 7 天下来整个账号的说教味还是变重了。原因在于选题池的来源太集中在“价值输出型”内容缺少“日常碎碎念型”和“记录过程型”的内容账号显得太“板正”。解决方法是给选题池加“内容情绪维度”。每条选题打三个标签信息量等级、情感温度、生活浓度。每天的输出按比例随机大约 40% 硬知识型、35% 经验记录型、25% 生活互动型。调整之后账号的互动率明显变好评论区开始出现“感觉你好真实”这类反馈。这一条对于做自动化的博主来说最关键内容算法的目标不是完美而是立体。4.3 踩坑风格锁过分收紧导致“AI 味崩溃”这个坑很有意思。我最初为了保证“不像 AI”把风格锁写到很细包括每句话要有短句结尾、禁止用任何连接词、禁止书面语。结果生成的文字离 AI 味远了但离“人话”也远了读起来像初中生写作文没有任何信息密度。后来我发现所谓 AI 味本质上不是句式问题而是信息密度低 逻辑套话。真正的 AI 味表现是“说了很多但什么都没说”。所以我改成了抓大放小只检查两条硬规则——不要空洞铺垫每个观点要有具体细节支撑不要万能金句要有自己的实际经历。其他句式上的东西全部放掉。跑了两周之后内容质量明显回升更接近真人真实表达。4.4 踩坑平台风控与内容安全检查做小红书自动化绕不开平台的风控机制。我在最初测试自动发布脚本时就遇到过一次异常登录检测导致账号被暂时限制。排查之后原因很可能是登录环境与常用设备差异过大。我的处理方案是降低自动化登录频率登录态长期保持不每次跑都重新登录固定运行环境自动化脚本只在本机同一浏览器上下文中运行发布节奏自然每天固定时间发布一小时内只发一次不与平台产生异常交互保留手动确认节点某些环节始终人工兜底。另外在内容安全上所有生成内容都要过白名单审查不带医疗、金融、夸大承诺类敏感词不触犯平台内容规范。这块我用了一个独立的content_safety_check函数把禁止词表和敏感领域写进去生成之后自动校验。4.5 踩坑复盘模块的数据偏差复盘模块看起来简单但有一个隐患数据文件本身可能缺样本。比如你刚开始更新三篇就有一篇数据特别异样它会把一个极端值当成规律写回人设档案导致这周定位方向走偏。我给复盘模块加了一个“样本置信度检查”只有同类内容的数据样本量达到 5 条以上时才允许它总结规律并写回定位档案。如果样本不足只输出观察性描述不执行写入动作。别小看这个规则它避免了系统拿偶然当必然。做自动化的每一步其实都是在跟“少数样本误判”作斗争。5. 效果如何以及自动化内容创作的边界在哪里跑了一个月之后我的账号在日更负担显著下降的情况下数据没有下滑反而在单篇收藏率和粉丝增长速度上有了小幅提升。更重要的是我彻底摆脱了“每天坐下来面对空白选题”的恐惧。现在我每天打开电脑只需要花 20 分钟——检查稿子、微调语气、确认发布剩下的思考和产出环节基本交给了这套系统。但我也必须泼一盆冷水自动化 Skill 不是把内容事业变成印钞机。它解决的是运营执行效率和一致性问题不解决“你到底有没有真知灼见”这个更上游的问题。如果一个人本身没有方法论、没有实践的素材积累那 Skill 生成的只是漂亮的空壳甚至会通过高频更新掩盖内容空心的窘境短期的数据假象之后会伤害账号长期信任。所以我想帮你在考虑做一个“账号自动化 Skill”之前先诚实回答三个问题你有没有足够的原创经验和观点输出值得被固化下来你是否愿意保留“人工确认”这一环而不是把账号完全交给机器你是否能接受初期至少两周的调试期每天像调教新人一样跟 Agent 磨合如果这三个问题的答案都是肯定的那我非常推荐你动手。我自己的体会是把账号方法固化成一个 Skill 的过程中最有价值的未必是自动更新本身而是你会被迫把自己那些模糊的“感觉”变成清晰规则。这个过程会让你的运营思路变得前所未有的清楚。最后分享一个小技巧不要一开始就追求做“全网最复杂”的 Skill。先只做最小闭环——定位 日更生成 手动发布 周末手动复盘跑顺之后再逐步加入自动发布、数据复盘、自动调优。一个能持续跑两个月的小系统远胜过一个功能完整但跑两天就崩了的大系统。