我用 Codex 搭了一个端到端的多平台内容运营工具

我用 Codex 搭了一个端到端的多平台内容运营工具

这两天我在做一个很具体的小工具：让 Codex 不只是帮我写文章，而是把“写作、适配、发布确认、运营记录、数据回收、线索引流”连成一条可操作的链路。

这篇文章本身就是这个链路产出的第一篇验证稿。也就是说，它不是一个事后总结，而是一次 dogfooding：我让 Codex 先升级内容发布 skill，再用升级后的 skill 生成这篇多平台内容包，最后再由我确认发到哪些平台。

为什么要做这个工具

我现在越来越明确地感觉到，产品宣传不是“写一篇文章”这么简单。真正麻烦的是后面的重复工作：

• 同一个产品进展，要改写成长文、短文、海外社交帖、社区帖和私域消息；
• 不同平台的限制不一样，小红书要短、LinkedIn 要清晰、Product Hunt 要像 launch、即刻要像人话；
• 发布之后还要记录 URL、状态、阅读、点赞、评论、收藏、分享；
• 国内读者最好能引到微信，海外读者最好能引到 Telegram；
• 最后还要能复盘：哪篇文章带来了真实对话，哪篇只是热闹。

以前这些动作散落在聊天、文档、浏览器和记忆里。现在我希望 Codex 能把它们收进一个可维护的运营流程里。

这次搭出来的架构

当前的工具不是一个复杂 SaaS，而是一个本地优先的内容运营工作台，核心分成四层。

1. 内容包层

每次发布不再只生成一篇文章，而是生成一个完整内容包：

• cnblogs.md：博客园长文，适合讲清楚背景、架构、验证方法和限制；
• xiaohongshu.md：小红书短文，控制在 1000 个中文字符以内；
• linkedin.md：LinkedIn 帖子，偏海外产品和 operator 叙述；
• producthunt.md：Product Hunt launch/comment 风格文案；
• jike.md：即刻口吻，更像一次真实开发记录；
• telegram.md：海外用户引流或频道消息；
• wechat.md：国内私域触达文案；
• publish-plan.md：发布渠道、模式、确认清单和风险说明。

这篇文章就是通过这一套内容包生成的。

2. 渠道注册层

我没有把平台逻辑写死在某个脚本里，而是加了一个统一的 channel registry。

当前已经注册的渠道包括：

• cnblogs
• xiaohongshu
• linkedin
• producthunt
• jike
• telegram
• wechat

每个渠道都有自己的发布路径、指标路径、长度限制和安全策略。比如 LinkedIn 优先官方 API，Product Hunt 优先官方 GraphQL 读数据但发布走浏览器辅助，即刻没有稳定官方 API 就只做登录态浏览器流程，微信个人号不做批量自动化。

这个设计的好处是：后面如果要加 X、Reddit、Hacker News、Medium，不需要重写整套工具，只需要加一个新的渠道适配。

3. 发布与确认层

这个工具的原则不是“无脑自动发”，而是“自动准备到最后一步，公开发布前必须确认”。

现在的策略是：

• 博客园可以走 MetaWeblog API，但默认 dry-run；
• 小红书走已登录浏览器的创作中心，填内容后停在发布前；
• LinkedIn 有官方 API 时走 API，否则走浏览器；
• Product Hunt 先做 launch checklist 和指标读取，发布创建保守走浏览器；
• 即刻只做浏览器辅助，不碰不稳定私有接口；
• Telegram 可以通过 Bot API 发频道或群，但必须显式确认；
• 微信优先公众号、企业微信或手工确认式发送，不做个人号批量触达。

这个边界对我很重要：工具要提高效率，但不能把账号风险、平台审核和误发内容藏起来。

4. 运营数据层

发布不是终点。这个工具还维护一个本地 SQLite 运营库，用来记录：

• 每个平台的文章标题、slug、标签、状态；
• 远端 URL 或 post id；
• 发布时间；
• 阅读、点赞、评论、收藏、分享、涨粉等快照；
• 数据来源和不确定性；
• 微信或 Telegram 的引流备注。

再配一个本地 dashboard，就可以看到哪些内容已经 ready，哪些已发布，哪些还 blocked，以及每个平台的最新表现。

本篇文章是怎么产出的

这篇文章的生产过程大概是：

1. 我提出需求：验证端到端能力，写一篇介绍 Codex 多平台内容运营工具的文章；
2. Codex 读取发布 skill 的写作、平台、引流和运营约束；
3. Codex 生成多平台内容包；
4. 本地校验各平台文案长度和 frontmatter；
5. 把内容包导入本地运营库，状态标记为 ready；
6. Codex 把待发布平台和发布模式交给我确认；
7. 我确认后，再分别走 API、浏览器辅助或手工确认流程。

换句话说，这不是“我写一篇文章说我有工具”，而是“工具正在产出这篇文章”。

现在已经能做什么

当前这套工具已经能支持：

• 一次生成多平台版本；
• 对不同平台做基础长度和字段校验；
• 记录内容包和发布状态；
• 支持博客园、小红书、LinkedIn、Product Hunt、即刻、Telegram、微信的不同操作路径；
• 对官方 API、浏览器辅助、手工确认三种方式做分层；
• 为国内和海外用户准备不同 CTA；
• 把后续指标采集纳入同一张运营台账。

还没完全解决什么

我不想把它说得过满。现在还有几件事需要继续验证：

• LinkedIn API 需要账号和应用权限，不能假设一定能无阻力发布；
• Product Hunt 官方 API 更适合读数据，真正 launch 创建仍然要谨慎；
• 即刻和小红书这类平台更适合浏览器辅助，不适合维护脆弱的私有接口；
• 微信个人号自动化风险高，应该优先用确认式触达或官方/企业能力；
• 运营数据里有些指标只能从后台页面或人工快照获得，不应该伪装成精确埋点。

我真正想验证的不是“自动发帖”

这次我想验证的核心不是让 Codex 帮我点一个发布按钮，而是一个更实际的闭环：

产品进展 -> 多平台内容 -> 发布确认 -> 状态记录 -> 数据回收 -> 线索流转 -> 下一轮内容优化

如果这个闭环跑通，Codex 就不只是一个写作助手，而会变成一个轻量的内容运营同事。它知道每个平台该怎么说，知道哪些动作需要我确认，也知道后续要记录什么数据。

这篇文章会先作为第一条样本进入这个流程。接下来我会选择要发布的平台，并用实际发布结果验证这套工具到底省不省事、稳不稳、能不能带来真实对话。

如果你也在做类似的产品/服务，可以加微信或 Telegram 聊具体场景。我更关心真实线索、转化和可交付结果，而不是“自动化看起来很酷”。