【Skill 创作】一个让大家都能写出小红书千赞笔记的 Skill

从 SOLO 挑战赛的 3300+ 提交作品来看,TRAE 已经帮大家打通了“从念头到产品”的开发闭环。但随之而来的新痛点是:产品或游戏做出来了,没有用户怎么办?该怎么推广?
在众多社媒平台中,我强烈建议将“小红书”作为首选的推广阵地(不是针对其他平台,而是确实分发机制不同)。虽然小红书的审核红线相对严格,但它的自然流推荐机制对“低粉新号”极其友好,这也是我专门针对小红书开发这个内容审核 Skill 的核心初衷。

Skill 地址:xiaohongshu-content-checker

既然是要帮大家写千赞笔记,那我还是先展示一下我之前通过摸爬滚打优化出的笔记成绩:

这些笔记也一定程度上持续为我的小程序带来客观的新增用户,虽然已经很久没有更新了,但是总用户数也来到了 3.6w。(300 日访问页面数 5000,你就说大家爱不爱玩吧)

从我个人近两个月的经历来看,其实各个平台对于外部引流都有着非常严格的限制和处罚力度,很容易导致像我一样被封号处罚,除了外链之外,其实一些限定的词语,我们日常使用可能觉得没有什么,但在平台当前普遍机审的背景下,如果不注意就很容被限流,导致精心准备的内容打了水漂…

所以作为近两月有着多篇上万阅读和千赞笔记的小红书博主(最近确实发得少了,都在水论坛),我结合我自身与小红书审核申诉的历程,同时借鉴了最近比较火的 github 开源项目 andrej-karpathy-skills 的框架,搭建了这个小红书笔记敏感词检测与内容定位分析 Skill

Skill 简介

Skill 定位:小红书笔记文案敏感词检测与内容定位分析工具。
主要功能:检测敏感词、违禁词、极限用语,分析账号定位与内容匹配度,识别影响自然流的因素,提供针对性的优化建议。当用户需要检查小红书笔记合规性、避免限流、优化内容定位、提升自然流量时使用。

使用场景

其实就我个人体验来说,小红书的自然流受到非常多的因素影响,很多朋友在用一些付费的小红书笔记敏感词工具调整之后,流量也没有很明显的提升。

同时如果被官方限流,也仅仅是给你一个笔记风险提示而已,并不会直接指出你具体是封面有问题还是笔记内容有问题,这就导致你原本定时发布的笔记,在频繁修改调整审核之后,及时最后合规,也已经错过了最好的发布时间,同时因为频繁修改,也会被官方降权,导致传播效果大打折扣。

所以基于以上这类问题,以及我个人的实际的笔记经验总结,单纯的敏感词检验并不能根本性的解决笔记被限流的问题,而是应该采用"先定位、后检测、再优化"的标准工作流,给出结合官方内容的专业修改建议。

创作过程

第一步,开启任务

由于我希望借鉴 andrej-karpathy-skills 的结构,所以我在项目一开始就对做了说明。

这个 Skill 之所以极受欢迎,是因为它将 AI 巨头 Andrej Karpathy 对大模型辅助编程缺陷的深刻洞察,提炼成了极简且直击痛点(如 AI 爱瞎猜、过度设计、乱改无辜代码)的四条强约束原则,以最低的成本(一个单文件)极大地提升了 AI 编程的可靠性和可用性。

具体大家可以参考:andrej-karpathy-skills

我在使用 AI 直接对笔记内容调整的时候其实也有以上提到的问题,所以也是用 Skill 来进行约束的必要性。

首先因为我对这个 Skill 的功能已经有了一个很详细的预设,所以我这里在 MTC 模式里直接输出了一个比较详细的 Prompt 让 SOLO 来启动项目

第一步执行完成后可以看到 SOLO 已经创建好了文件结构,同时在我框选的位置大家也可以看到整体的结构也参考了我引用的 github 项目。

第二步,交叉验证方案

在第一步阶段创建的 Skill 其实已经初步具备可执行性,但是考虑到 Skill 的可用性,我还是分别用 Gemini 和 ChatGPT 分别用第一步的 Prompt 跑了两个方案,用于第一步设计的参考,可以从截图中看到两个模型也分别从各自的角度出发给出了建议,SOLO 也并不是全盘接收,而是根据现有项目进行比对进行优化。

第三步,流程优化

在第二步优化完成后,我对当前版本的 Skill 进行了测试,发现了一些体验上的问题,这里直接按想要实现的方式进行说明就好,具体内容如下图所示:

第四步,参考文档完善

xiaohongshu-content-checker/
├── SKILL.md                          # Skill 主文件(核心指令)
├── README.md                         # 项目说明
└── references/                       # 参考文档
    ├── SENSITIVE_WORDS.md            # 敏感词完整列表
    ├── REPLACEMENT_SUGGESTIONS.md    # 替换建议库
    ├── PLATFORM_RULES.md             # 小红书平台规则
    ├── ACCOUNT_POSITIONING.md        # 账号定位指南
    └── CONTENT_EXAMPLES.md           # 内容优化案例

SOLO 虽然已经给了我完善的文档结构,同时在参考文档里已经帮我补充了以上五个文档,但是在我审核之后发现还是有一些内容需要补充,所以我直接通过 SOLO 打开对应的 Markdown 文件进行了内容的调整。

以下是我从其他信息源了解到的关于小红书笔记参考文档的补充,同时也是增加对 AI 输出内容的约束:

一、 内容优化案例库(CONTENT_EXAMPLES.md )

新增了三个非常典型且近期官方严打的案例:

  1. 理财/搞钱类(涉及炫富、制造焦虑与违规荐股)
  2. AIGC/虚拟创作类(涉及AI生成内容未标识、虚构打卡地)
  3. 旅游/摄影类(涉及“滤镜照骗”、过度美化)

二、 账号定位指南(ACCOUNT_POSITIONING.md)

补充了以下关键维度的最新趋势:

  1. 新增了当下最容易起号的人设:“养成/听劝型”(极度契合平台“真实”价值观)和“买手型”(极度契合电商变现)。
  2. 强化了“搜索SEO”在账号初期的价值:将搜索流量思维纳入账号定位和新手期起号策略。
  3. 补充了“变现前置”的定位思维:在定位画布中加入了“商业化路径”,避免很多博主遇到“有流量但接不到商单、带不了货”的死局。

三、替换建议库(REPLACEMENT_SUGGESTIONS.md)

重点新增了以下内容:

  1. 价值观敏感词(严打项):补充了“炫富”、“制造焦虑”等容易直接被封号的词汇替换。
  2. 旅游/探店词汇(反照骗):针对近期严打的“此生必去”、“国内马尔代夫”等极端诱导词进行降级替换。
  3. 同质化/低质词汇(防限流):将“绝绝子”、“yyds”等极易被系统判定为“水军通稿”的低质词汇,替换为真实的感官描述。

四、敏感词完整列表(SENSITIVE_WORDS.md)

重点新增了:

  1. 价值观违规高压线(炫富、制造焦虑,当前平台封号重灾区)。
  2. 同质化/水军黑话(易触发“啄木鸟计划”被判定为低质营销号)。
  3. 最新行业监管词汇(如美妆的“抗糖/医美级”、金融的“荐股/代码”、旅游的“照骗”标签)。
  4. 水下商单(暗广)高危词。

效果展示

第一步:调用 Skill

这里会有两个方式可选,方式一也就是我之前说的"先定位、后检测、再优化"的标准工作流,方式二就更简单粗暴,比如你之前的对话流里已经有了关于账号的信息补充,那么后续就直接用方式二快速检测就好。

第二步:选择方式并补充信息

这里已经调整为选择题,可以通过 1-A、2-C 进行快速选择,更方便。

第三步:生成报告,并给出修改建议

执行结果包括:

总体结论

内容定位卡

核心问题摘要

账号定位与人群匹配度

敏感词与高风险表达检测

自然流影响因素判断

修改建议

优化后版本

发布前检查清单

Skill 地址:xiaohongshu-content-checker
欢迎大家体验 !

总结与思考

最后可以说是给到了一份非常详尽的小红书笔记分析报告,内容覆盖笔记和账号定位、人群匹配度、敏感词表达以及修改建议等等。这一定程度上能让你更直观地了解小红书的笔记审核机制,也让你在后续写笔记时,有意识地去规避可能的限流和违规风险。

虽然但是我还是要说一下,并不是说所有检查都通过了,你的笔记就一定能爆。本 Skill 只是在底层规则的基础上,尽量帮你规避那些“必死”的显性问题。但一篇笔记要大爆,内容本身的情绪共鸣、发布时的「天时地利人和」缺一不可,AI 只能帮你拉高下限,上限还得靠你自己对受众的洞察。

但其实,这次借助成熟的 Skill 框架去写这个辅助工具,也让我有了新的体会。像我之前的帖子,基本都是把我和 SOLO 的对话记录简单总结成一个单 Skill.md 文档,这种做法应对一些发散性的创意任务还行;但如果遇到像“内容审核”这种需要高度严谨性的 Skill,单纯依赖大模型自由发挥,一定会发生“同一篇笔记在多次执行后,得出完全不同结论”的尴尬事情。

所以,这类 Skill 设计的核心在于“规则的结构化”与“约束的前置”。 必须像我们做这个工具一样,把小红书的平台红线、敏感词库、定位指南等变成清晰的、外挂的客观标准,并给 AI 制定一套强制的“体检工作流”(先核对敏感词 → 再看人设 → 最后给出修改建议)。用强规则去对抗 AI 的发散,赋予 AI 极强的“边界感”,才能最大限度地减少幻觉,让它真正变成一个稳定、可靠且每次输出标准一致的“金牌审核员”。

希望这个 Skill 和背后的框架思路,不仅能帮大家少踩小红书流量的坑,也能在大家自己构建 AI 工作流时提供一些灵感。写笔记和调教 AI 一样,都是不断迭代的过程,祝大家的笔记都能顺利过审,写出大爆款!

更新日志(2026-05-14 v1.1.0)

  • Skill.md 真的是越写越长,因为本来想着是一个单 Skill 文件,后面越写越多,所以这个版本把 Skill 文件从 716 行缩减到 150 行左右,符合了 K 叔最开始的建议,Skill 只作为中心路由,其他的内容还是拆到不同的知识库里。
  • 文件架构优化,其实就是调整了下位置,更顺眼一点
  • 新增可计算风险评分,这个是用 ChatGPT 检查之后让添加的,但也是给方案让 SOLO 调整
  • 新版本 Skill 已更新 GitHub

更新日志(2026-05-21 v1.2.1)

  • 新增反馈收集与自进化机制;
  • 输出模板支持 emoji 色标(:red_circle::orange_circle::yellow_circle::green_circle:)和修改前后对比表格;
  • 新增交互确认节点

更新日志(2026-05-24 v1.3.1)

  • 删除:记录至 references/feedback/ 目录并按月归档,这在绝大多数无状态的 AI Agent 平台(包括 TRAE 商店的常规 Skill)上是无法直接执行的。LLM 本身没有持续写本地文件的权限和状态记忆。
  • 优化:说明文档中,删掉具体加载哪些文件的表格,只需保留“工作流图”(用户输入 → 意图识别 → 执行检测 → 输出报告)。保持产品体验的极简和“黑盒魔法”感。
  • 优化: 采用“渐进式抽取”或“零样本推断”。用户只需丢进来一段文本,Agent 优先通过文本风格自动推测人设和领域。如果不确定,Agent 再通过对话主动发起轻量级单选追问,而不是让用户一开始就填表。
  • 强化:System Prompt 的“防御性设计”
  • 优化:输出结果的“视觉化”与“卡片化”设计
  • 优化:增强“Vibe Coding”风格的 API/CLI 友好度
  • 优化:版本号之前自动写的,太夸张了,整体都调了一下

更新日志(2026-06-11 v1.3.2)

  • 新增:首次使用欢迎语,新用户触发时自动展示 Skill 能力、5 种可用模式和示例指令
  • 新增:语义风险识别模块,双引擎检测:关键词匹配 + 语义分析,识别 6 类非字面风险
  • 优化:修正过度确定性措辞,“必查"→"降低风险”、“3秒"→"快速”、"统统"→"尽量"等
  • 优化:批量检测输入分隔协议,支持 ---、编号标记、JSON/YAML 三种分隔方式
  • 删除:移除 reference 版本历史,统一放 CHANGELOG.md,减少上下文占用

更新日志(2026-06-12 v1.3.3)

  • 新增:五项风险评分项(AIGC/价值观/商单/照骗)
  • 新增:能力边界说明
  • 优化:重写 README,加入个人经历,实战成绩和设计哲学
  • 优化:调整 Github 仓库结构,README 文件移到仓库根目录

5 个赞

@TRAE-小阳 给我写哭了越写越长

5 个赞

好好好,要是没有一千赞,就回来取消赞 :zany_face:

5 个赞

「天时地利人和 」缺一不可
复议 :folded_hands:t6:

4 个赞

好好好,要是没有一千赞,就回来取消赞 :face_with_monocle:

4 个赞

先帮哥顶一下人气,没有一千赞我回来~

5 个赞

我送你三百六十五个祝福:check_mark:

4 个赞

为啥不是直接输出合规的小红书文案 :smiling_face_with_tear:

我还想用你这个生成一个分享顺便做测评呢

4 个赞

不行奥,以我被封的经历来看完全不建议,最近小红书对 AI 内容的审核非常严,而且误判的概率非常高,直接给你关 7 天小黑屋,我自己看到稍微有点 ai 味的笔记都是一举报一个准,内容可以少写点,但最好还是自己写

5 个赞


哈哈,我就测评你的skill啦,优化好,今晚发

4 个赞

简单评测了下,主要关注的是实现技巧这块

一句话结论

xiaohongshu-content-checker 的领域知识密度很高,内容实用性也强,已经具备“可直接拿来用”的实战手册价值;但如果按我的标准来看,它目前更像“超长运营指南 + 参考资料库”,还没有收敛成“结构化、可路由、可验证、可发布”的 Skill。

复杂度判断

结论:复杂 Skill

判断依据:

  • 存在多个阶段性产物:主文档、README、5 份大型 reference 文档
  • 存在多个稳定用户意图:账号定位判断、敏感词检测、自然流诊断、标题与封面优化、最终发布建议
  • 存在明显的多阶段流程:收集账号信息 → 判断意图 → 检测 → 诊断 → 优化 → 输出
  • 目标 Skill 已明显出现“正文膨胀 + reference 增长”的重构信号

因此,若要继续长期维护,建议补 workflow 映射,而不是继续在单一主文档中堆内容。

主要优点

1. 问题定义清楚,适用场景明确

主文档的 description 和开头说明已经比较准确地定义了使用场景:不是单纯查敏感词,而是“定位分析 + 合规检查 + 自然流优化”一体化工具。这一点比普通“违禁词表”型 Skill 更强。

参考:

2. 工作目标是完整的业务闭环

这个 Skill 不是只做“检测”,而是试图覆盖:

  • 账号人设确认
  • 笔记意图澄清
  • 违规风险识别
  • 流量风险识别
  • 优化建议生成
  • 最终发布检查

从业务完整性上看,它已经非常接近一个完整顾问式 workflow。

3. reference 方向基本正确

references/ 已经按知识类型拆成了:

  • 平台规则
  • 敏感词
  • 替换建议
  • 账号定位
  • 内容案例

这说明作者已经有“主文档不应该承载所有细节”的意识,只是还没有拆干净。

参考:

4. 输出结构设计得很强

标准化9步结构 这一段是当前 Skill 最有价值的部分之一,因为它把复杂分析结果变成了稳定输出格式。这很适合保留为常驻主规则。

参考:

主要问题

P0. 当前 Skill 只有 metadata.version,没有顶层 version;同时缺少:

  • 头部 > **版本**: vX.Y.Z
  • 文末 ## 版本历史

这意味着它在版本管理上偏弱。

证据:

P0. 主 SKILL.md 严重超出“路由层”职责

主文档当前达到 653 行,且同时承担了:

  • 产品说明
  • 完整 SOP
  • 敏感词分类清单
  • 流量风险知识库
  • 用户输入模板
  • 输出模板
  • 示例

这已经不是“主 Skill 路由层”,而是一份完整操作手册。按 kz-skill-creator 的标准,主文档应更多承载:

  • 何时触发
  • 走哪个 workflow
  • 何时读取哪份 reference
  • 最终如何校验输出

而现在大量细节本可下沉却仍保留在正文中。

证据:

P0. 文档没有使用语义化标记体系

这使得它虽然“人能读懂”,但“机器稳定执行”能力较弱。尤其对这种复杂 Skill 来说,缺少结构化标记会放大执行漂移。

P1. 主文档与 references 存在明显重复维护

当前主文档中已经写了大量平台规则、敏感词类别、替代表达、定位逻辑,而 references/ 中又各自维护了更详细版本:

  • 主文档写“变体敏感词识别”,SENSITIVE_WORDS.md 里又写完整清单
  • 主文档写“账号定位与人设确认”,ACCOUNT_POSITIONING.md 里又写完整定位方法
  • 主文档写“修改原则”,REPLACEMENT_SUGGESTIONS.md 里又给了系统替换库
  • 主文档写输出案例,CONTENT_EXAMPLES.md 里又维护案例库

这类重复会导致两个问题:

  1. 更新一处时容易忘记同步另一处
  2. 主文档越来越重,reference 却没有真正承担“按需加载”职责

证据:

P1. references 已经很大,但主文档没有清晰规定“何时读哪份”

这是典型的“reference 失衡”问题。

现在虽然有 5 份 reference,但主文档并没有正式建立稳定入口规则,例如:

  • 什么时候必须读 PLATFORM_RULES.md
  • 什么时候才需要读 CONTENT_EXAMPLES.md
  • 什么时候只做快速检测,不需要加载 ACCOUNT_POSITIONING.md
  • 什么时候替换建议应来自 REPLACEMENT_SUGGESTIONS.md

这会让执行者倾向于“全读”,反而破坏渐进式披露。

P1. README 与主文档重复度过高

README.md 当前本质上是 SKILL.md 的压缩复写版,重复了:

  • 核心特点
  • 工作流程
  • 示例
  • 输出样式

这会增加维护成本。更理想的分工是:

  • README.md:给人看的快速介绍、安装/使用入口
  • SKILL.md:给模型执行的路由和规则

而现在两者边界仍然偏模糊。

证据:

P1. references 本身也未纳入版本规范

这些 reference 文档体量都很大,而且明显会持续更新,但当前没有统一的:

  • frontmatter version
  • 头部版本块
  • 文末版本历史

从“知识库”角度看问题不大,但从“Skill 可维护性”角度看,后续很难知道哪份 reference 在何时被修改过、是否与主 Skill 同步。

P2. 针对 TRAE 社区的定制内容嵌入过深,削弱了 Skill 的通用边界

主文档和示例中多次出现面向 TRAE 社区用户的排序和举例,例如:

  • 内容领域排序偏向 数码工具 / 编程教程 / AI应用
  • 示例文案直接以 TRAE 为核心案例

如果这是该项目的明确目标用户群,这样做可以理解;但当前 description 写法仍像“通用小红书内容检查器”。这会造成边界不一致:

  • 实际上更像“TRAE / 技术向创作者的小红书内容检查器”
  • 文案上却表现为通用小红书检查器

建议二选一:

  1. 明确收窄边界,写成面向技术 / 工具 / AI创作者的专用 Skill
  2. 保持通用边界,但把 TRAE 相关内容下沉为行业示例,而不是主流程默认项

工作流重构建议

如果按复杂 Skill 标准重构,我建议至少拆成 4 个主 workflow:

工作流 类型 做什么 不做什么 上游 下游 失败回流 可否单独触发
账号定位与发布意图确认 主 workflow 收集账号信息、人设、目标受众、发布目的,生成内容定位卡 不直接做敏感词细查 用户提交笔记需求 风险检测、优化输出 信息不足时回到补充提问 是
快速敏感词与违规风险检测 主 workflow 对标题、正文、标签、封面做快速敏感词和导流风险排查 不做深度定位判断 用户只给文案 完整改稿或建议补充定位信息 发现信息不足时回到定位确认 是
自然流与匹配度诊断 主 workflow 诊断人设匹配、营销浓度、UGC感、收藏价值、评论区风险 不维护完整敏感词词库 已有定位卡或已有文案 优化建议与发布建议 定位不清时回到第一工作流 是
优化改写与最终发布建议 主 workflow 产出标题、正文、封面、标签、Checklist 和最终建议 不自行扩展平台规则知识库 已完成风险与匹配度诊断 最终交付 若改写后仍高风险,回到前两步重新判断 是

优化建议

第一优先级

  1. 给 SKILL.md 补齐顶层 version、头部版本块、文末版本历史。
  2. 把主文档改造成真正的路由层,保留:
    • 触发边界
    • workflow 路由
    • 最终输出规范
    • 强制校验规则
  3. 把详细规则、词表、案例、替换库进一步下沉到 references/。

第二优先级

  1. 用 ## @工作流: / ### @步骤N: / HTML 注释元数据重写主文档结构。
  2. 为每份 reference 在主文档中补上“何时读取”的明确入口。
  3. 重新划分 README 与 SKILL 的职责,减少重复维护。

第三优先级

  1. 若继续长期维护,给 references 也补版本信息与更新历史。
  2. 视目标决定是否把 TRAE 定制内容收窄为专用场景,或下沉为案例。
  3. 可以增加 design.md,保存 workflow 映射表和边界决策。

建议的重构方向

较稳妥的重构方案可以是:

  • SKILL.md
    • 只保留触发边界、workflow、输出格式、关键校验
  • references/platform/
    • 平台规则与算法机制
  • references/detection/
    • 敏感词、替换建议
  • references/positioning/
    • 账号定位与人设判断
  • references/examples/
    • 内容优化案例
  • README.md
    • 给人看的简介和快速用法

也就是说,不一定非要减少总内容量,而是要减少“主文档常驻内容量”。

总评

从“内容专业度”看,这个 Skill 很强;从“按规范的 Skill 工程化程度”看,它目前是中等偏下。

它最强的地方是:

  • 业务理解完整
  • 参考资料丰富
  • 输出模板成熟
  • 兼顾违规风险与流量风险,不是单点检测

它最需要补的地方是:

  • 版本与校验闭环
  • 主文档瘦身
  • workflow 显式建模
  • reference 路由化
  • 减少重复维护

如果目标只是“给人直接阅读使用”,它已经很有价值;如果目标是“让另一个 AI 稳定调用、长期演进、持续发布”,那现在正是该做结构化重构的时候。

4 个赞

太牛了哥,我在车上,等我有空了好好看看,确实有点不严谨其实,因为是越写越多的,最后仓促收尾了

4 个赞

原来是谁输谁洗碗的作者,小红书发帖子确实需要技巧,有时候发帖子确实没什么浏览量 :distorted_face: ,已投票试试效果 :wink:

5 个赞

我靠居然还是事实说话,牛逼

1 个赞

开始赚钱了吗

1 个赞

如果一个月三百也算钱的话…

4 个赞

反正去中心化,我推荐还是多试试小红书,其他几个平台推荐机制不友好反正

4 个赞

@大模型善后工程师-K叔 K 叔我更新了一版,有时间的话麻烦再测一下哈,我自己看确实条理了不少,直接更在 github 上了

5 个赞

好的,我到时候直接回复在评测贴里

3 个赞

已经是很强了,牛

1 个赞