我把小红书内容生产流程，做成了一个协作平台

最近我把自己本地跑的一套小红书内容工作流，整理成了一个能真正用起来的平台，名字叫 XHS Workbench。

它不是那种只负责“生成一篇文案”的 AI 工具，而是把一条更完整的内容链路串了起来:

• AI 先产出草稿
• 人工再做判断和修改
• 图片素材统一绑定
• 发布前先校验
• 最后再一键发到小红书

说白了，我想解决的不是“写一篇内容难不难”，而是内容团队或者个人创作者在日常生产里，流程太碎、切换太多、回溯太难的问题。

为什么要做这个东西

过去这类内容工作流，经常散落在几个地方:

• 文案在文档里
• 图片在文件夹里
• 状态在表格里
• 发布靠人工打开网页处理

如果只是偶尔发一篇，问题不大。
但只要开始批量做内容，或者开始把 AI 生成接进来，马上就会出现几个很现实的问题:

• 哪篇内容已经改完了，靠记忆
• 配图有没有对应上，要来回找
• 发布失败了，原因留不住
• 同一条内容的版本变更，不好追踪

所以我最后没有继续堆单点脚本，而是直接把它做成了一个“内容协作平台”。

这个平台现在能做什么

目前已经跑起来的能力，主要有这几块。

1. 统一管理内容草稿

每条内容都有自己的标题、正文、标签、图片和状态，不用再把信息拆在不同工具里。

2. 图片素材直接绑定内容

发小红书最烦的一件事，其实不是写文案，而是临发布时还要重新找图、对图、拖图。

现在这部分被前置到了内容层。内容和素材是一条记录，查看和发布时都能直接拿到。

3. 发布前先做一次校验

我不想把“点了发布才发现有问题”当成默认流程，所以在真正发布前会先走一遍校验。

这样能提前发现图片数量、内容格式、发布条件之类的问题，把返工成本压下来。

4. 直接打通发布链路

内容验证通过之后，可以直接进入发布流程，不需要再人工把标题、正文、图片重新搬一遍。

5. 保留状态和错误信息

内容会有 draft、pending、published、failed 这些状态。发成功了能追，发失败了也能看错误原因，后面做失败重试会更顺。

实际界面长什么样

先看工作台首页。内容列表、平台登录状态、小红书登录状态、筛选和新建入口都放在一个界面里。

再看内容详情页。图片、正文、标签和发布时间等信息可以集中查看，后续这里也会继续增强编辑和审核体验。

这套东西是怎么搭起来的

技术上我没有走特别花的路线，核心是先把链路跑通。

• 前端: React + Vite + Tailwind CSS
• 后端: FastAPI
• 存储: SQLite
• 部署: Docker Compose
• 发布能力: 接入 xhs-kit

现在本地已经是容器化运行，前后端和发布链路可以一起启动。对我来说，这样的形态才算从“脚本集合”变成“平台”。

我现在最看重的，不是 AI 写得多像人

很多人讨论 AI 内容工具，焦点都放在“能不能一键写出爆款”。

但真做久了会发现，真正决定效率的，往往不是某一次生成，而是整条链路是不是顺:

• 内容能不能集中管理
• 素材能不能跟内容绑定
• 人工能不能方便接手
• 发布前能不能低成本发现问题
• 发完之后能不能追踪结果

所以我现在更相信一件事:

单点能力当然重要，但真正稳定的产出，靠的是流程产品化。

后面我还会继续补什么

接下来准备继续做几块:

• 更顺手的内容编辑体验
• 批量发布能力
• 更完整的失败重试和日志
• 更细的协作权限
• 更多内容平台接入

如果你也在做 AI 内容生产、个人 IP 工作流，或者小团队内容协作，我觉得这类平台比“再多一个生成器”更值得投入。

因为内容生产到最后，拼的不是一次生成，而是持续、稳定、可复用地把内容发出去。