希鸥网AI产业观察 | 小红书上线skill工具 要抢AI一杯羹？

希鸥网AI产业观察

登陆PC端小红书，会看到有一个发布“小工具”和“skill”的入口，为了测试小红书平台相关规则，笔者做了一个“查询网信办白名单”相关的skill，向工具提问或者推荐权威官方媒体，工具就会从网信办公布的白名单列表里推荐你想要的。

按照小红书平台要求提交代码之后，大约5分钟就通过了审核。笔者最感兴趣的是，这个费时费力的skill发布后，怎么和自己的小红书定位相结合。于是迫不及待的打开手机版小红书，在头像简介下方就有相关入口。

但点击使用skill时，小红书提示的是：通过对话安装，复制口令给你的AI助手。

没错，你没看错，小红书的skill竟然只是为了给其他agent提供skill安装命令，这不是githup干的活吗？专注生活服务平台的小红书怎么干起了这个活？

一、先承认那个直觉是对的：它确实不像小红书该干的活

开头提到的体验——发布5分钟过审、点“去使用”却弹出“复制口令给你的 AI 助手”——在已有的实测中几乎被原样记录过。有测评者把口令粘贴到 Claude Code 后，得到的指令是“先安装 Red Skill 商店，再安装某个技能”，而真正的安装和运行完全发生在小红书之外。小红书负责把你送到门口，后面的事它基本不在场。

更微妙的一个细节是：详情页显示的“xx 人已使用”，统计的是点击“去使用”的次数，而不是 Skill 真正被安装并跑起来的次数。也就是说，小红书现阶段能度量的是兴趣信号，不是使用效果。

这个体验当然别扭。但“别扭”不等于“错位”。它的别扭恰恰暴露了小红书此刻在生态位上的真实选择：先做分发，再做闭环。

二、数据不支持“小红书在做 GitHub”这个结论，但支持另一个结论

GitHub 的核心价值是代码托管 + 协作基础设施：clone、issue、PR、CI、版本管理。小红书目前做的和这些几乎不沾边。

但它手里有一组 GitHub 没有的数据：截至 2026 年 7 月，小红书上活跃着30 万名 AI Skill 内容创作者和超 16 万名开发者，“Skill”相关话题曝光超过 6 亿；RED Skill 内测一个月，站内涌现超 7300 个原创 Skill。歸藏的 PPT Skill 在 GitHub 上花了 25 天拿到超 1 万 Star，同步上架小红书后，短时间内获得超 4500 人使用。量子位那篇实测的标题直接写的是“你天天刷的小红书，正在长出一个 GitHub”，但正文里真正描述的动作是：Skill “挂在一条条小红书笔记下面，看到就能一键复制”，而不是“clone 下来跑起来”。

GitHub 解决的是“代码放在哪”，小红书解决的是“人从哪里知道、从谁那里信、在什么场景下被触发”。 前者是托管层，后者是发现层。小红书现阶段押注的是后者。

三、“复制口令给其他 Agent”不是 bug，是现阶段的最小可行路径

如果小红书自建站内 Agent 运行时，它需要解决沙箱安全、模型调用成本、多轮对话体验、Skill 兼容性、开发者分成等一系列问题——这些没有一项是短期内能低成本跑通的。但它又不能等。

于是出现了一个精巧的折中：Skill 本身以标准化的 SKILL.md 形式存在，安装动作通过一段口令完成，执行交给用户已有的 Agent（Claude Code、OpenClaw、Codex 等） 。创作者上传的是一份说明书加可选代码，纯提示词也可以是合法 Skill，门槛低到“10 分钟搓一个、5 分钟过审”。用户在小红书内完成“发现—判断—复制口令”，在小红书外完成“安装—运行”。

这个链路的问题在于平台不在场：Skill 有没有装成功、跑起来效果好不好、用户会不会复用、失效了谁来提醒，小红书都感知不到。但它的好处在于极低的启动成本：不需要重建一个 Agent 平台，就能先把“创作者把经验封装成 Skill、用户从笔记下方取走”这个行为习惯养起来。

换一个角度想：微信小程序早期的“跳转 H5”阶段，体验同样割裂，但它先让开发者把服务搬进来、让用户形成“在微信里找服务”的预期，中心化入口和完整闭环是后来才补上的。小红书现在的口令安装，更像是 AI 时代的“早期跳转”——先用最轻的方式把供给和需求连上，闭环留给下一阶段。

四、和三个参照系比，小红书的卡位是独特的

vs. GitHub：GitHub 有托管能力和开发者信任，但没有大众消费场景。一个非技术用户不会为了一个“PPT 排版 Skill”去 GitHub 读 README。小红书有场景、有信任中介（笔记作者）、有“刷到即想要”的触发机制，缺的是执行环境。两者在 AI 能力的分发链上处于不同层，不是替代关系。

vs. OpenAI GPT Store：GPT Store 有站内闭环——用户在 ChatGPT 里直接使用 GPT，不需要复制口令。但它的发现机制始终是弱项：300 万个 GPT 被创建，只有约 15.9 万个保持活跃，存活率 5.3%，创作者中位月收入 47 美元，排名前 1% 的创作者拿走 78% 的收入。有闭环不等于有分发，有分发才可能有生态。 小红书正好反过来：闭环尚未建成，但分发土壤是现成的。

vs. 微信小程序：微信有 800 万个小程序量级和最强的超级入口，但它走的是“开发—部署—中心化货架”的路径，门槛天然筛掉了大量“只是想把个人经验封装一下”的轻量创作者。小红书的路子是低门槛创作 + 内容化分发：一篇笔记同时是内容、是货架、是安装入口。它不追求“做一个完整的应用”，而是“把一段有用的 AI 能力挂出来”。

三者的差异可以压缩成一句话：GitHub 有供给无消费，GPT Store 有闭环无发现，微信有入口有门槛，小红书有发现、有供给冲动，闭环待补。

五、真正的缺口不在“复制口令”，在“平台不在场”带来的三个后果

第一，数据黑洞。 点击“去使用”不等于安装，安装不等于跑通，跑通不等于复用。创作者不知道自己的 Skill 在真实 Agent 里表现如何，平台也无法用“使用效果”来优化分发权重。一个没有反馈回路的 Skill 生态，长期会退化成“笔记挂件”，而不是“能力资产”。

第二，付费链路缺席。 目前RED Skill是纯粹的内容消费场景，付费售卖能力尚未打通。GPT Store 的前车之鉴已经说明，靠 engagement 分成的创作者收入结构极其陡峭，中位月收入只有 47 美元。小红书如果停留在“免费 Skill + 流量曝光”阶段，头部创作者可以用 Skill 给账号导流，但腰尾部创作者缺少持续投入的經濟理由。

第三，资产沉淀在别人手里。 创作者上传的是一份 SKILL.md，但真正的运行发生在用户的 Claude Code 或 OpenClaw 里。如果未来小红书不能把“安装”变成“站内使用”，那么它培育出来的 Skill 供给，最终可能喂养的是其他 Agent 平台。有内部知情人士透露小红书后续会推进站内直接使用，让“创造—种草—使用”在一个平台内完成——这个“后续”的推进速度，决定了小红书是从“AI 能力的种草层”升级为“AI 能力的消费层”，还是长期停在发现层。

希鸥网认为，小红书不是在做 GitHub，它在抢 AI 时代“发现层”的定义权

回到开头那个问题：专注生活服务的小红书，怎么干起了 GitHub 的活？

更准确的问法可能是：当 AI 能力开始以 Skill 的形态泛滥时，谁来决定用户“看到哪个、相信哪个、取走哪个”？

GitHub 定义了开发者的发现方式（Star、Trending、README），GPT Store 试图定义 Agent 的发现方式但没完全做成，微信小程序正在把发现权收回到中心化货架。小红书选择的是它最擅长的那一种：把 Skill 重新放进“笔记”里，让创作者的真人身份和过往内容充当信任背书，让“刷到”代替“搜索”，让“一键复制”代替“配置环境”。

它现在只做到了“送到门口”。但 AI 能力的分发链上，“门口”本身就是一个极具价值的位置——因为用户的时间和注意力在那里，创作者的表达习惯在那里，而“安装”这个动作，迟早会被产品化掉。

小红书现阶段做的不是 GitHub，而是 AI 时代的 Skill 种草层。种草之后能不能自己收割，是下一个章节的事。但先把“种”这个动作占住，已经让它在 Agent 分发战争中拿到了一个别人没有的起点。