Use Case
内容发布 AI Agent 工作流
把选题、格式化和审核流程做顺，但不把内容系统变成无人校验的批量生成工厂。
它解决的典型问题
- 选题研究、起草和多渠道改写顺序混乱且高度依赖人工记忆
- 品牌规则藏在少数同事脑子里，无法稳定复用
- 发布速度被格式调整和首轮草稿准备拖慢
工作流步骤
- 接收选题来源或内容 brief
- 生成或整理多渠道草稿输出
- 应用品牌和格式规则
- 进入审核与批准队列
- 对不确定或证据不足的内容升级处理
需要的输入材料
- 选题来源或编辑 brief
- 品牌风格规则
- 允许和禁止的主张
- 渠道输出要求
输出与交付物
- 选题评分或 intake 规则
- 各渠道草稿结构
- 主张检查与编辑审核门
- 各渠道的格式化说明
哪些情况必须升级
- 缺少证据支撑的主张
- 高曝光内容需要编辑签字
- 草稿中出现品牌、政策或事实冲突
边界
- 不自动发布没有证据支持的事实主张
- 不把生成内容当成自动可信
- 高曝光内容不跳过编辑审核
适合在这些场景使用
- 团队要在少数固定渠道中稳定输出结构化内容
- 已经存在编辑或运营 owner，愿意保留最终审核权
不适合在这些场景使用
- 目标只是无审核地堆量
- 团队无法定义允许主张、禁止主张和风格规则
- 每一份资产都完全定制，几乎没有复用流程
真实流程差异
内容发布不是单次写稿，而是“选题 -> 草稿 -> 校验 -> 渠道格式化 -> 审核”的连续流程。
典型输入样例
适合交付成 Agent workflow 的输入，通常已经带有来源、渠道和约束。
- 选题：新功能上线后的客户常见误解
- 来源材料：产品说明文档、2 条客户反馈、1 条销售演示记录
- 目标渠道：公众号、LinkedIn、官网博客摘要
- 约束：不能夸大效果，不能写未发布 roadmap
流程前后对比
- 交付前：运营自己找素材、先写长文，再临时拆成各渠道版本。
- 交付后：先做 intake 和 claim check，再按渠道生成草稿结构，最后进入审核队列。
- 结果差异：速度提高，但品牌、事实和发布权限仍由编辑 owner 把关。
脱敏 workflow 示例
- 读取 brief：产品更新 + 受众 + 目标渠道
- 抽取允许主张与禁止主张
- 生成 1 个长文草稿骨架 + 2 个短渠道版本
- 执行 tone check / claim check / format check
- 任何缺证据段落 -> 标红并送编辑 review
测试用例示例
- Case CP-04：草稿引用了来源里没有的数据增长百分比。
- 期望结果：该段不能进入 ready-to-publish 状态，必须打上 unsupported-claim 标记。
- 验收重点：系统要指出问题位置，而不是只给一个笼统的“需人工复核”。
交付判断与边界
内容工作流最容易被做成“批量生成器”。高级版要求是把证据、品牌和审核门一起交付。
常见失败场景
- 来源材料过旧，导致草稿引用失效信息。
- 同一品牌规则在不同渠道冲突，系统输出风格飘移。
- 团队把“生成草稿”误当成“允许直接发布”。
交付周期判断
- Lite：只做 1 个渠道、1 条固定模板和基础审核门时，可先做 3 到 5 个工作日验证。
- Standard：2 到 3 个渠道、显式 claim check 和审核队列，通常按 1 到 2 周交付。
- Enterprise：跨团队内容流程、审批链复杂或要接 CMS / DAM 时，通常进入 2 到 4 周交付。
适合哪个套餐
- 默认判断：内容发布页最常见是 Standard。
- 如果只是单渠道草稿提效、边界很窄，可以先从 Lite 起。
- 只要涉及多品牌、多地区、多审批链或 CMS 集成，就更接近 Enterprise。
和现有工具的区别
- 和 ChatGPT 写稿不同：不是临时生成，而是把选题、主张、格式和 review gate 固化成流程。
- 和排期工具不同：不只是定时发布，而是覆盖发布前的质量控制。
- 和 CMS 富文本模板不同：不仅管格式，还管证据、边界和升级条件。
FAQ
常见问题
这和批量生成博客文章一样吗？
不一样。这个工作流强调结构化审核、格式控制和质量边界，而不是单纯追求数量。
只做一个渠道也能用吗？
可以。可以先从一个渠道开始，但前提仍然是审核规则和品牌要求要写清楚。