产品团队确认了一次更新，内容团队接下来要写官网 Blog、社媒动态和客户邮件。同一件事，官网读者想知道怎么用，社媒读者需要迅速理解变化，现有客户则关心自己是否能用、下一步做什么。一份发布说明，很难直接满足这三种阅读需求。
把材料交给 AI Agent 改写，可以从同一份来源准备不同渠道的稿件。难点在于：表达要变，产品事实不能跟着变。为了更短、更有吸引力而删掉可用条件，或把具体功能改成更大的承诺，会让三份稿件向读者介绍出三个不同的产品。多渠道写作需要同时解决两件事：按读者重排信息，并让每一条承诺都能回到原始依据。
字数变少，承诺却可能变大
产品资料写“部分用户可以手动导出 CSV”。Blog 解释导出步骤，社媒稿变成“报表全自动”，邮件又邀请所有客户立即使用。三稿语气一致，事实却不一致。
这是虚构教学例子，不是 Buda 的功能发布。它说明多平台改写不能只靠“缩短一点”：开场、详略和结构可以变，可用对象、能力范围和限制必须跟着承诺走。
先准备所有任务共用的事实页
写稿前整理已确认变化、可用对象、必要条件、限制、来源 URL 与日期，以及不能使用的宣传词。给事实短编号，例如 F1、F2；未确定项留空，并写清谁能确认。品牌语气指南单独放，避免“写得自信”覆盖产品事实。
虚构导出例子里，F1 是手动导出 CSV，F2 是仅向部分试用用户开放，F3 是没有定时导出。“报表自动化”和“所有人都能用”都超出这些事实。事实文件是编辑输入，不是自动锁定事实或检测错误的产品功能。
三种渠道，三张任务卡
Blog 负责讲清机制和操作。 读者需要知道解决哪个问题、怎么使用、限制在哪里。先讲任务，再解释步骤，不从功能清单开场。
LinkedIn 或 X 负责一个独立成立的用户变化。 短句也要带上关键条件。可以写“试用用户现在能把报表导出成 CSV，不必重新录进表格”，不能暗示定时处理或全量开放。
邮件负责现有客户的下一步。 明确谁该行动、做什么、去哪里看操作。虚构例子可以写“如果你的团队已在试用范围内，打开报表并选择 CSV 导出”。收件人和资格另行审核，生成邮件不等于允许发送。
这三稿是三种论证，不是一段摘要删成三个长度。
独立 Session，共用明确的文件路径
营销场景支持从产品与品牌背景准备多渠道内容。Agent 角色设计建议相关写作任务放在同一 Agent 的多个 Session，不必按渠道拆出一批 Agent。
在 Drive保存 updates/export-v1/facts.md 和 brand/voice.md，Blog、社媒、邮件分别输出到各自目录。每个 Session 都明确引用这两份文件。Session隔离的是对话上下文，不是为每稿创建独立 Drive。
读取指定路径的已确认事实页和品牌指南。只为本渠道及受众写稿；能力、可用对象、条件和限制必须保留在相关承诺旁。未确认项显式留出。交付正文和事实编号→对应句子的映射，不发布、不发送。
审的是具体承诺，不只审语气
要求交付事实编号与三稿对应句子的映射，每项标保留、缺失或变化。虚构例子里，Blog 可能保留 F1–F3，社媒漏了 F2，邮件把 F2 改成所有用户。这样能直接定位两处修改。
“报表全自动”把手动导出改成更大承诺，应退回改为具体导出动作。面向所有人的邮件 CTA，应收窄到有资格的试用用户。指出哪句话与哪条事实不符，比泛泛要求“再准确一点”有用。
编辑也要判断正确事实是否服务读者：社媒句子可能准确但看不出价值，邮件可能信息齐全却把行动藏在末尾。事实一致并不替代编辑取舍。
产品变化，先改来源，再改受影响稿
若试用范围扩大，先更新事实页 F2，保留旧版，再让 Agent 列出所有依赖 F2 的句子。定向改写各稿对应段落，比较旧文和新文。改了来源文件，不意味着所有已保存稿件自动重读和同步。
记录来源版本、受影响稿件、改动段落和审核结果。确认之后才进入各渠道真正的发布流程；这套准备方法不自动发帖或发邮件。内容发布流水线介绍更大的生产链，事实映射让其中的稿件不偏离源材料。
小团队最常见的三个选择
每渠道都要一个 Agent 吗？ 角色、工具和文件相同时，用多个 Session；确实需要不同职责或隔离边界时再拆 Agent。
短稿怎么保留限制？ 把决定性条件紧贴收益，例如“试用用户可以……”。条件太长就收窄承诺，别把限制藏到链接后。
产品更新后哪些稿重写？ 按事实编号列出受影响句子，再逐稿检查新承诺和 CTA，不必把无关部分全部重写。
需要复用方法时，可以在 Buda AI 的 Marketplace 搜索并安装相关 Skill，先读清流程；没有适配项再创建自定义方法。从一份已确认更新和三个可审阅稿开始，编辑决定表达，Agent 执行写作与逐句比对。