多平台分发内容的底层数据模型怎么设计？

一个简单的文本字符串在单平台发布时没问题，但一旦涉及多平台分发，这个逻辑就崩了。X（原Twitter）需要把长文拆成 Thread，LinkedIn 可能得传 PDF，Instagram 要轮播图，YouTube 还要标题、描述和封面。如果强行在同一个“帖子”对象里打补丁，代码会变得极其恶心。

我在公司推行内容自动化分发时，为了避免后期大规模重构，把模型拆成了「发布意图（Publication）」和「具体呈现（Rendition）」两层。

1. 核心模型拆分

Publication 记录的是原始想法和素材，是所有分发的源头；而 Rendition 则是针对具体账号的适配版本。

type Publication struct {
 ID string
 WorkspaceID string
 Title string
 ContentProfile string
 SourceText string
 SourceURL string
 Status string
 ScheduledAt time.Time
 ActualRunAt time.Time
}

type Rendition struct {
 ID string
 PublicationID string
 SocialAccountID string
 Platform string
 Profile string
 Body string
 Title string
 Description string
 SettingsJSON string
 Status string
 ExternalID string
 ExternalURL string
 ErrorMessage string
}

这里有个细节：我是把 Rendition 绑定到具体账号（Account）而不是平台（Platform）。因为即使是同一个平台的两个账号（比如个人号和公司号），发布的内容和侧重点也完全不同。

2. 验证逻辑的坑

最容易踩的坑就是：验证了 SourceText 合法，就以为所有平台都能发。

实际上，Rendition 可能会覆盖原内容，所以必须对最终生成的 Rendition 进行校验。比如 X 的字数限制，或者 Instagram 对图片格式的硬性要求。我定义了一套 content_profiles（如 short_text、thread、carousel 等），让适配器在调用 API 前先做一次预检，避免请求发出去才报错。

3. 引入 AI Agent 的权限控制

为了让 AI Agent 能帮我们准备草稿，但又不希望给它太高的权限（比如直接操作凭据），我设计了两种 MCP 作用域：

• mcp:read：仅限检查工作区数据。
• mcp:full：允许创建、编辑、上传和发布。

这种在服务端强制执行的权限划分，能有效防止 AI Agent 在自动优化内容时误操作导致全平台发疯。