CE-02 · 多平台内容一致性检查

① 场景引入

一、这件事现在是什么样

内容改编编辑 · 真实业务触发

每周五要做内容质量复盘，检查本周发布的所有平台版本是否存在信息不一致、数据冲突、品牌调性偏差。主编会问：「这周有没有发出去的内容出了问题？」—— 你得在周一之前把所有隐患找出来。

二、痛点 · 每条都有来源

1. 不同编辑负责不同平台，各自改稿时没有对齐过，导致同一件事出现多个版本的说法
   依据：MCN 运营负责人自

述：'同一篇稿子改五个版本，公众号要正式、头条要抓眼球、小红书要种草风、抖音要口语化、B站要玩梗，改完一下午就没了'2数据在多次改编过程中被 rounding 掉了精度，比如「23.7%」变成「约 24%」再到「近 25%」依据 · MCN运营负责人自述：'同一篇稿子改五个版本，公众号要正式、头条要抓眼球、小红书要种草风、抖音要口语化、B站要玩梗，改完一下午就没了'3品牌调性在多次改编中逐渐漂移，公众号正经、小红书随意、抖音夸张——读者觉得不像同一家依据 · 微信公众号运营规范 —— 标题不得超过 64 字符，正文图片建议宽度 900px，严禁诱导分享与虚假信息，违规文章会被删除并扣信用分4事后追查问题时找不到是哪个环节改错的，因为没有留存中间版本依据 · MCN 运营负责人自述：'同一篇稿子改五个版本，公众号要正式、头条要抓眼球、小红书要种草风、抖音要口语化、B站要玩梗，改完一下午就没了'5读者在评论区指出矛盾时，公关团队才知道出了问题，但此时已经传播开了依据 · 《企业舆情管理白皮书》—— 负面舆情的黄金响应窗口期为 2 小时，超过 6 小时未回应的危机事件传播量是及时回应的 12 倍

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 不同编辑负责不同平台，各自改稿时没有对齐过，导致同一件事出现多个版本的说法数据在多次改编过程中被 rounding 掉了精度，比如「23.7%」变成「约 24%」再到「近 25%」品牌调性在多次改编中逐渐漂移，公众号正经、小红书随意、抖音夸张——读者觉得不像同一家事后追查问题时找不到是哪个环节改错的，因为没有留存中间版本

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

6 步 · 每一步的产出都是下一步的输入

1. 内容采集 · 把各平台版本汇集起来从链接/截图中提取文本；无法自动提取的标明「需手工录入」
2. 要素对齐 · 找到各版本共有的核心信息点自动识别：人名/地名/机构名/时间/数据/结论/引用；生成要素矩阵
3. 交叉比对 · 逐个要素检查是否一致完全一致 ✓ / 表述不同但语义相同 ~ / 存在冲突 ✗ / 仅某版本有 ○
4. 偏差分类 ·区分问题的严重程度致命级：事实冲突（如数据矛盾）；严重级：关键信息缺失；一般级：表述差异；提示级：风格漂移
5. 影响评估 · 这个问题会造成什么后果每条偏差附带：读者困惑风险 / 平台处罚风险 / 品牌损害风险 / 法律风险
6. 输出修复建议 · 给出具体的修改方案每条问题附带：建议修改措辞 / 建议统一版本 / 建议发布更正声明要准备什么各平台已发布内容的链接或截图支持微信公众号、今日头条、小红书、抖音、B站等主流平台原始审定稿（如有）作为比对基准；如果没有，以各平台版本互相比对为主品牌调性指南（可选）用于检查调性偏差；如果没有，仅做事实性一致性检查

为什么这个场景值得做

优先级评分：痛感 4 × AI 适配 4 ÷ 落地难度 2 = 8.8

最大差异点：不需要客户先建立版本管理系统。直接把各平台的已发布链接或截图扔进来，Agent 自动提取文本并交叉比对。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：一致性核查报告.docx 完整的核查报告 · 含要素矩阵/偏差清单/影响评估/修复建议
• 可派发清单：偏差明细表.xlsx 逐条偏差记录 · 含位置/内容/风险等级/建议操作
• 可派发清单：修复操作清单.xlsx 按优先级排列的修复任务 · 可直接派发给对应平台编辑

这套东西不承诺什么：不判定哪个版本是「正确的」（原文可能有错）。只标出不一致之处，由编辑确认。不做品牌调性评分（这是主观判断）。不追溯责任到个人（这是管理问题，不是技术问题）。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：一周后，2026 年 8 月 19 日，「祺瑞汽车 E3 事故」话题的评论区出现了读者质疑：「你们公众号写的车速跟知乎写的不一样，到底哪个对？」夏牧之需要复查五个平台版本的一致性，找出问题出在哪个环节。这类质疑平均每个月会出现两三次，但过去从来没有系统性复查过，都是等读者指出来才知道出了问题。

评论区总量340 条质疑一致性89 条发现硬伤2 处结论1 处待更正 · 1 处需说明

输入新闻出版与媒体机构手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_五平台已发布版本_20260813.xlsx 一周前实际发布的五个平台版本原文摘要 —— 平时没人在发布后系统性地把五个版本放在一起比对过夏牧之 8/13 发布 · 首次系统整理
• 02_评论区数据_近1周.xlsx 五个平台评论区里明确提到「数字不一致」「你们说的不一样」这类质疑的原始评论 —— 平时没人统一收集过夏牧之本次手动整理 · 首次系统抓取
• 03_原稿事实核查交接单.xlsx CE-01 改编时使用的同一份钱屿核实交接单 —— 用作本次复查的唯一事实基准钱屿 8/13 09:40 交接 · 复查环节仍以此为准
• 04_历史类似质疑处理记录.xlsx 过去评论区出现类似「数字不一致」质疑的处理记录 —— 散落在客服组和运营组各自的聊天记录里，没有统一存档客服组与运营组分别记录 · 本次首次合并整理

注意标橙色那一份 —— 02_评论区数据_近1周.xlsx。它夏牧之本次手动整理 · 首次系统抓取，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

这是我们本周在各平台发过的内容，帮我检查一遍：

1. 有没有数据或事实对不上的地方
2. 有没有说法互相矛盾的
3. 哪些地方需要统一口径 只标问题，不改内容。最终怎么改由编辑决定。

短是因为比对规则都写在能力包里了。你只需要把各平台的链接或内容贴过来。

触发读者在评论区问「到底哪个对」

这类质疑每月出现两三次 · 但从没系统复查过五个版本

夏牧之收到运营组转来的评论区截图，需要把一周前发布的五个平台版本重新拉出来，逐项比对车速、赔偿金额、责任认定这三项核心信息，找出到底是哪个版本、哪个环节出了问题。

第 1 步 · 内容采集 · 把各平台版本重新汇集起来

发布后的版本可能还有编辑手动做过小修改

这一步的看点 · 排除性结论「发布后被人二次改错」这个可能性可以直接排除，依据是五个平台后台导出的当前版本与最初发布时的存档逐字比对完全一致——问题从一开始就在初版里，不是发布后又被谁动过。这条排除把复查方向从「谁动了发布后的内容」收窄到「改编与核验环节本身」，省掉了去查各平台账号操作日志这一整轮排查。

第 2 步 · 要素对齐 · 找到各版本共有的核心信息点

车速 / 赔偿金额 / 责任认定，三项逐一对齐

第 3 步 · 交叉比对 · 逐个要素检查是否一致

以原稿（钱屿核实过的版本）为基准，标出偏离

这一步的看点 · 从历史里想起了公司踩过的坑CE-01 改编时其实已经检查过「限定语不可删」这条规则（见 CE-01 第 1 步），但检查是针对「重写时是否保留意思」，没有覆盖「后续如果有人二次精简会不会又删掉」这种情况——公众号版本推测是初稿写完后，编辑为了控制字数又做了一轮精简，这一轮精简没有再过一次限定语检查。这条教训会转化成规则：任何「二次精简」都要重新走一遍限定语检查，不能假设第一轮检查过了就一直有效。

第 4 步 · 偏差分类 · 区分问题的严重程度

车速偏差涉及事实性质变化 · 金额偏差是纯数字错误

第 5 步 · 影响评估 · 这两处问题会造成什么后果

评论区已经在质疑，需要评估更正的紧迫性

这一步的看点 · 把技术动作翻译成钱如果两处错误不更正，任其发展，参照本机构去年的先例，一旦被读者或涉事车企正式指出，需要发布更正声明，更正声明本身会带来二次关注，关注度通常是原始错误的1.5到2倍（基于同类事件的传播规律）；而现在主动更正，只需要在评论区置顶说明+修改原文，不需要单独发更正声明，成本低得多。

第 6 步 · 输出修复建议 · 给出具体的修改方案

每条建议都写明改哪个平台的哪句话

这一步的看点 · 该拦的地方拦住了修复清单生成后，系统没有自动执行任何一项修改——结论是「这两处改动现在还不能自动提交，需要夏牧之本人逐条确认措辞后手动修改」。尤其是公众号那条更正，涉及对外承认表述不够严谨，具体怎么措辞会影响读者对机构公信力的感知，这个判断必须由人来定，不能让系统直接把「建议措辞」当成「最终措辞」发布出去。

之后这次复查跑完，攒下了什么

不是纠正了两个错误，是补上了一个检查缺口

沉淀项具体内容「二次精简需重新检查」规则补充进流程CE-01 的限定语检查只覆盖首次改编，这次事件后补充为「任何后续精简都要重新过一次检查」评论区质疑的系统性收集方式确立以前靠运营组随手转发截图，这次开始按周整理，下次出现类似质疑能更快定位问题版本车速/金额/责任认定三项核心信息的复查清单可复用以后任何多平台稿件发布一周后，都可以用这份清单快速复查这次复查的真正价值不是「改对了两个数字」，而是发现了「首次检查有效，但二次修改后失效」这个流程漏洞，并把它补上了。

更正声明的对外措辞还不能直接发布两处问题（公众号车速限定语丢失、小红书赔偿金额多写10万）的具体修改内容已经明确，但对外的更正措辞需要运营主管把关——尤其是公众号那处，涉及「我们此前的表述不够严谨」这类自我批评性语言，需要考虑对机构公信力的影响。方案一 · 低调更正：直接修改原文，不加额外说明。代价是如果后续被读者发现「偷偷改了」，可能引发「掩盖错误」的二次质疑；方案二 · 公开说明更正：修改原文 + 评论区置顶说明。代价是主动承认了错误，但避免了「偷偷改」的风险。建议方案二。两处都是可以合理解释的错误（精简时的疏漏、数字笔误），公开说明的可信度成本远低于被发现「悄悄改」的信任损失。

之后这一次跑完，公司多了什么

不讲省了多久：讲少了几个隐患、沉淀了什么

• ✓ 一致性基线多了一条：每次核查的结果入库，下周对比就能看出改进趋势
• ✓ 两条检查规则被固定下来：具体是「数据必须精确到原始来源的位数」和「关键事实必须在所有版本中出现」
• ✓ 一条历史教训被真正用上：某次因「数据精度漂移」导致的读者质疑被写入自动检查规则
• ✓ 岗位角色变了：从「周五加班逐篇人工比对」变成「周四晚上跑一次Agent、周五只花 30 分钟确认问题点」

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 能自动帮我们改好吗？ 不能，修改内容由各平台编辑自行决定。但我可以给出具体的修改建议措辞，编辑复制粘贴即可。
• 能对接 CMS 自动检查吗？ 目前不支持自动对接，但你可以把 CMS 导出的内容定期扔进来做批量检查。
• 发现了问题怎么办？ 报告中会按风险等级排列：致命级的建议立即处理并考虑发布更正声明，一般级的可以在下一轮内容中自然修正。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

多平台内容一致性检查 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

content-consistency-check.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是新闻出版与媒体机构手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁CE-02 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

• 01_五平台已发布版本_20260813.xlsx 一周前实际发布的五个平台版本原文摘要 —— 平时没人在发布后系统性地把五个版本放在一起比对过
• 02_评论区数据_近1周.xlsx 五个平台评论区里明确提到「数字不一致」「你们说的不一样」这类质疑的原始评论 —— 平时没人统一收集过
• 03_原稿事实核查交接单.xlsx CE-01 改编时使用的同一份钱屿核实交接单 —— 用作本次复查的唯一事实基准
• 04_历史类似质疑处理记录.xlsx 过去评论区出现类似「数字不一致」质疑的处理记录 —— 散落在客服组和运营组各自的聊天记录里，没有统一存档

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

这是我们本周在各平台发过的内容，帮我检查一遍：

1. 有没有数据或事实对不上的地方
2. 有没有说法互相矛盾的
3. 哪些地方需要统一口径 只标问题，不改内容。最终怎么改由编辑决定。

为什么这么短就够了：短是因为比对规则都写在能力包里了。你只需要把各平台的链接或内容贴过来。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

• CE-02_一致性核查报告.docx 完整的核查报告 · 含要素矩阵/偏差清单/影响评估/修复建议
• CE-02_偏差明细表.xlsx 逐条偏差记录 · 含位置/内容/风险等级/建议操作
• CE-02_修复操作清单.xlsx 按优先级排列的修复任务 · 可直接派发给对应平台编辑

Skill 里固化了什么：从历史核查记录里想起了上次踩过的坑该拦的问题拦住了排除性结论把不一致翻译成业务后果

输入清单：各平台已发布内容的链接或截图支持微信公众号、今日头条、小红书、抖音、B站等主流平台原始审定稿（如有）作为比对基准；如果没有，以各平台版本互相比对为主品牌调性指南（可选）用于检查调性偏差；如果没有，仅做事实性一致性检查

人工边界：不判定哪个版本是「正确的」（原文可能有错）。只标出不一致之处，由编辑确认。不做品牌调性评分（这是主观判断）。不追溯责任到个人（这是管理问题，不是技术问题）。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

内容改编编辑 · 产出即下一步输入

CE-01 · 长稿改写为多平台适配版本 — 同一篇深度稿改五个平台版本要花一下午 · 而且每个版本都是人工从头改，连核心数据点都能改不一致 查看 →

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。