从手动到自动化：我的内容运营系统搭建复盘

一个独立内容创作者的 AI 工具链构建实录

背景

一个人做内容运营最难的是什么？不是写不出好内容，而是写完之后的事情比写本身还多。

2025 年底，我开始搭建个人品牌网站"内容运营实验室"。最初的设想很简单：一个博客系统、能发文章就行。但真正跑起来才发现，内容运营从来不只是"写"这件事——从内容分析、分类归档、配图生成，到多渠道发布、数据追踪，每一步都藏着大量重复劳动。

这篇文章复盘了我在过去几个月里，从"手动管理一切"到"搭建 AI 驱动的内容运营工具链"的完整过程。不谈理论，只说踩过的坑和最终的解决方案。

阶段一：纯手动时期（痛楚期）

网站初期用 PocketBase 作为后端，前端基于 Vite 构建。每发布一篇文章，流程是这样的：

• 在 Markdown 编辑器里写完文章
• 手动登录 PocketBase 后台，创建新记录
• 填写标题、摘要、分类、标签——每一个字段都要手敲
• 去另一个网站用 AI 生成配图，下载，再上传到图床
• 把图片 URL 粘贴回文章字段
• 手动计算阅读时长（然后经常算错）
• 发布后发现有错别字？重复以上大部分步骤

一篇 2000 字的文章，光是"发布"这个环节就要耗费 20-30 分钟。更别说在多平台同步发布时，同样的流程要走好几遍。

痛点总结：

• 工具割裂：写作一个工具、配图一个工具、发布一个工具、数据管理又一个工具
• 缺乏标准化：没有统一的内容分类规范，标签随意，导致后期检索困难
• 重复劳动：每次发布都是体力活，毫无技术含量

阶段二：搭建工具链（解决期）

意识到问题后，我开始系统性地搭建内容运营工具链，目标是把"发布"这件事从 30 分钟压缩到 5 分钟以内。

核心架构

写作端 (Obsidian/编辑器)
    ↓
内容分析层 (analyze_content - DeepSeek)
    ↓
智能发布层 (publish_smart - 自动适配栏目)
    ↓
配图生成层 (generate_image - 火山引擎 Doubao)
    ↑
图床 (腾讯云 COS)
    ↑
后端数据层 (PocketBase)

关键设计决策

1. 用 AI 做内容分析，而不是人工分类

我之前有个坏习惯：写完后纠结"这篇文章该归到哪个栏目"。后来让 DeepSeek 模型来做这件事。输入文章内容，自动输出推荐的栏目、标签、摘要。准确率从最初的 60% 到现在的 85% 以上，关键是省掉了"犹豫时间"。

2. 自动化配图工作流

独立创作者最头疼的事之一就是配图。我用火山引擎 Doubao 模型接入了 AI 生图能力，配合规范化的命名规则（{slug}-{序号}.{扩展名}），生图到上传完全自动化。目前在用的是一个 20 行的脚本，从生图请求到 COS 上传、到文章关联，一气呵成。

3. 智能发布适配不同的内容类型

不同类型的文章（原创、转载、AI 实践、项目复盘），发布时的格式要求各不相同。转载需要加"个人点评"区块和原文链接，原创需要重点配图。我设计了一个 publish_smart 接口，传入内容后自动识别类型、适配格式、补全缺失字段。这个接口现在是我发布文章的"单一入口"，所有发布逻辑都收敛在这里。

阶段三：持续迭代（优化期）

工具链搭好只是第一步。在真实使用中，我发现了很多"看起来很美，跑起来就崩"的问题：

踩坑记录

坑 1：MCP 工具的双向问题

早期我依赖一套封装好的 MCP 工具（create_article、delete_article 等）来操作 PocketBase。但这些工具的"读取"链路走的是 CloudBase 服务层，而"写入"需要走 PocketBase 管理 API。两条链路的认证方式不同，导致写入端频繁报错。

解决方案： 读取保留通过封装工具（方便），写入全部改为直接调用 PocketBase Admin API（可靠）。这也是后来我发现很多 AI 编码工具的通用问题——读可以抽象，写必须直连。

坑 2：图片质量不稳定

AI 生图看起来很方便，但实际跑起来发现：prompt 写得好不好，直接决定图片能不能用。早期的 prompt 太简略（"文章配图，科技感"），生成的图片空洞且缺乏细节。

解决方案： 建立了一个 prompt 模板库，覆盖封面、插图、数据图等常见场景。每次生成时自动从模板库加载，再根据文章内容做关键词替换。出图可用率从 30% 提升到 70% 以上。

坑 3：缓存导致的数据不一致

全站搜索功能（搜索文章、项目、资源）用了 localStorage 做缓存，过期时间设为 10 分钟。但测试中发现：刚发布一篇文章，搜索里查不到——因为缓存还没刷新。

解决方案： 发布成功后主动清除 localStorage 缓存标识位，同时开放搜索面板时重新拉取数据。最终效果：用户永远看到最新数据，但非发布场景下 10 分钟内的重复搜索不走网络。

数据对比

| 维度 | 手动时期 | 自动化后 |

|------|---------|---------|

| 单篇文章发布耗时 | 25-30 分钟 | 3-5 分钟 |

| 配图生成到上传 | 10-15 分钟 | 30 秒 |

| 多平台适配 | 每平台单独操作 | 一次完成 |

| 内容分类决策 | 人工犹豫 2-3 分钟 | AI 即时推荐 |

| 错别字修复成本 | 需手动回溯修改 | 一键修复重发 |

经验总结

如果让我给想做类似事情的独立创作者三个建议，我会说：

1. 先跑通手动流程，再思考自动化

不要在一开始就追求完美的自动化方案。先用最笨的办法跑通一个完整的内容发布流程，把每个环节的痛点和耗时记录下来。这些数据会告诉你"哪一步最值得自动化"。我一开始想做全自动发布，后来发现配图环节才是最大的效率瓶颈。

2. 工具链的"写入端"要稳

读数据可以有很多层抽象（缓存、CDN、API 网关），但写入端越直接越好。我的教训是：任何路径上有超过一个中间层的写入操作，都会成为故障点。最终我选择了 PocketBase 的 Admin API 作为唯一写入通道，稳定运行至今。

3. 为"失败"预留处理路径

AI 工具再好用，也一定会有失败的时候——模型返回格式不对、图片生成内容不合预期、网络超时。在设计工具链时，不要假设每个环节都会成功。我在每个步骤都加了 fallback 路径：AI 分类失败则走预设规则，生图失败则使用备选素材库，API 超时则进入重试队列。

下一步

工具链目前覆盖了"写→分析→配图→发布"这个核心链路。接下来的方向是：

• 数据反哺内容：接入网站分析数据，用阅读数据指导选题方向
• 定时发布 pipeline：草稿撰写完成后，自动规划发布时间，分批推送
• 多平台分发：从公众号扩展到知乎、掘金等平台，每次发布自动化多平台同步

本文是"内容运营实验室"项目复盘系列的第一篇。如果你也在做独立内容运营，欢迎一起交流踩坑经验。