AI 把“写出第一稿”的成本压得越来越低，但多平台运营并没有因此变成一键任务。相反，当一天能生成十篇稿时，真正麻烦的部分会迅速浮上来：哪一版引用了旧数据？哪张图是头条横版？掘金分类是不是还停在默认“后端”？CSDN 的摘要和标签有没有漏？
9 月 4 日，Adobe 复盘了 Firefly 在时代广场的一次大型项目。官方披露，这个项目包含 392 个独特图像与视频资产、超过 300 万渲染帧和 20TB 数据，还要适配 38 块屏幕、30 种比例。Firefly 负责加速生成和编辑，Frame.io 则被用来共享素材、传递反馈和管理审批。
这个案例规模很大，却说明了一个适用于小团队的问题：生成便宜以后，版本管理就会变贵。
不要把“万能正文”当成唯一源文件
不少内容自动化系统把一篇 Markdown 当作 Source of Truth，再复制到 CSDN、掘金和头条，最多改一下标题。这种设计看起来简单，实际把三类东西混在了一起：
- 不应该变化的事实与来源；
- 可以变化的叙事、措辞和例子；
- 每个平台独有的标题、摘要、标签、分类、封面和声明。
一旦正文成为唯一源文件，平台改写就很容易污染事实层。为了让头条开头更快，模型可能顺手删掉限定语；为了让掘金更“技术”，又可能补出原始资料没有的实现细节。几轮修改之后，三个版本表面讲同一件事，实际已经出现语义漂移。
更合适的做法，是先建立一份内容中间表示（Content IR）。它不是可直接发布的文章，而是一份可核验的母题包：
type ContentIR = {
thesis: string;
audienceProblem: string;
facts: Array<{
claim: string;
source: string;
checkedAt: string;
}>;
inferences: string[];
opinions: string[];
forbiddenClaims: string[];
assets: Array<{
id: string;
role: "cover" | "explainer";
path: string;
}>;
};
母题层只回答“什么不能写错”，不追求好读。真正的文章结构交给平台 Adapter。
Adapter 不是同义词替换器
三个平台的差异，远不止标题长短。
CSDN 读者通常愿意跟着问题、机制、数据结构和实现步骤往下看。稿件需要把术语说清楚，给出流程或代码骨架，并让搜索关键词自然出现在标题、小标题和摘要中。
掘金更在意工程取舍：为什么要多一层 IR？Adapter 如何防止事实漂移？校验器放在生成前还是生成后？同样的材料，开头可以直接从失败模式或架构冲突切入。
头条则更适合从日常场景开始，用短段落回答“这件事跟我有什么关系”。代码不是完全不能出现，但如果读者必须先理解一组类型定义才能继续，开场就已经失效了。
所以，平台适配器的输入是同一份 IR，输出却应该拥有独立结构：
interface PlatformAdapter {
outline(ir: ContentIR): PlatformOutline;
render(ir: ContentIR, outline: PlatformOutline): Draft;
buildMetadata(draft: Draft): PlatformMetadata;
}
这里最关键的约束是：Adapter 可以重新排序事实、替换例子、改变语气，却不能创造新的事实。新增断言要退回研究层核验，而不是直接混进某个平台的正文。
发布字段也应该进入编译产物
很多系统写完正文就宣布完成，剩下的封面、摘要、标签、分类和作品声明全部留给人。结果是生成端节省了十分钟，发布端又多出一串复制粘贴和排错工作。
可以把平台产物做成一个 Manifest：
platform: juejin
title: 别再一稿三发：把多平台内容系统做成一台编译器
category: 人工智能
tags: [人工智能]
summary: "…"
cover: images/cover.png
body_images:
– images/pipeline.png
source_digest: sha256:…
source_digest 用来说明这篇平台稿来自哪一版母题。如果事实清单变化，三个目标版本都能被标记为需要重新构建，而不是靠人回忆“我刚才改过哪一篇”。
Validator 要检查页面约束，不只检查 Markdown
编译器不会在语法错误时假装构建成功，内容流水线也不应该只看“正文字符串非空”。至少要有两类校验。
第一类是静态校验：标题长度、摘要范围、必需图片、标签、分类、引用链接、敏感词和禁止断言。这些在进入平台前就能完成。
第二类是页面回读：图片是否真的上传、标签是不是平台接受的候选、掘金分类有没有被默认成后端、头条封面是否单图、CSDN 的原创和可见范围是否正确。输入参数没报错，只能说明请求发出去了，不能证明页面已经处于可发布状态。
整个流程可以用下面几个状态表达：
RESEARCHED -> ADAPTED -> VALIDATED -> PREFILLED -> COMMITTED -> VERIFIED
其中 PREFILLED 和 VERIFIED 不能合并。点过发布按钮后，还要从成功页、公开链接或作品管理记录确认结果；网络超时也不能靠连续点击解决。
为什么更适合交给多个岗位 Agent
这套结构并不要求一定使用多 Agent，但它天然适合分工：研究岗位维护事实层，平台编辑负责各自 Adapter，视觉岗位交付封面和解释图，发布岗位处理字段、页面校验和结果记录。每个岗位面对的上下文更窄，验收标准也更清楚。
这也是我们做 Tipkay 时采用岗位化 AI 的原因之一。官网目前明确写的是：同一份业务目标由不同岗位按各自平台和专业方法完成，而不是机械复制一篇内容；业务资料、历史内容和素材进入共同上下文，平台登录态留在本机，发布等关键动作单独确认。
对今天这篇文章，我们也按同样的方式处理：Adobe 的数字和来源只保存一次，但 CSDN、掘金和头条拥有不同标题、开头、结构、摘要和结尾。Tipkay 只是这套方法的一种实现；不用它，也可以先从一个 content-ir.yaml 和三个 Adapter 模板开始。
AI 时代真正稀缺的，不再是把字生成出来，而是让同一个观点在不同场景里仍然准确、自然，并且可以被验证地交付出去。
参考资料：
- Adobe 项目复盘：https://blog.adobe.com/en/publish/2026/09/04/times-square-takeover-how-adobe-brought-firefly-world-biggest-stages
- Tipkay 官网：https://www.tipkay.com/
