旗舰场景 审查核验 行业 · 新闻出版与媒体

FC-01 · 稿件事实核查辅助

痛点 一篇深度稿 15-20 个事实点逐个手工查,漏一个就是撤稿+内部通报 · 而核查员每天只有 4 小时能用来做这件

① 场景引入

一篇深度稿 15-20 个事实点逐个手工查,漏一个就是撤稿+内部通报 · 而核查员每天只有 4 小时能用来做这件事

一、这件事现在是什么样

事实核查专员 · 真实业务触发

每天下午 5 点前要完成当日签发稿件的事实核查。值班主编会问:「这篇稿子的事实都核过了吗?有没有硬伤?」—— 你得敢说「核过了」,因为这句话的背面是「出了问题你担责」。

二、痛点 · 每条都有来源

  1. 每个事实点要打开三四个网页交叉验证,光是搜索和切换标签页就要花大量时间
    依据:报社事实核查岗自述:'一篇深度稿里 15-20 个事实点要逐个查,漏一个就是撤稿+内部通报,去年我们组因为这个被罚了三次'
  2. 有些数据来源是付费数据库或内部报告,核查员没有访问权限
    依据:报社事实核查岗自述:'一篇深度稿里 15-20 个事实点要逐个查,漏一个就是撤稿+内部通报,去年我们组因为这个被罚了三次'
  3. 引用的专家言论可能被断章取义,但原文是 2 小时的讲座录像,没法逐句听
    依据:报社事实核查岗自述:'一篇深度稿里 15-20 个事实点要逐个查,漏一个就是撤稿+内部通报,去年我们组因为这个被罚了三次'
  4. 同一事实在不同来源的表述不一致,判断哪个可信要靠经验,新人容易出错依据· 报社事实核查岗自述:'一篇深度稿里 15-20 个事实点要逐个查,漏一个就是撤稿+内部通报,去年我们组因为这个被罚了三次'5核查完了但没有书面记录,出了问题说不清当时是怎么核的
    依据:《互联网新闻信息服务管理规定》——要求新闻信息服务提供者建立健全信息发布审核制度,不得发布虚假信息,违规可处五十万元以下罚款

三、换个做法之后

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

✕ 现在的做法

  • 每个事实点要打开三四个网页交叉验证,光是搜索和切换标签页就要花大量时间
  • 有些数据来源是付费数据库或内部报告,核查员没有访问权限
  • 引用的专家言论可能被断章取义,但原文是 2 小时的讲座录像,没法逐句听同一事实在不同来源的表述不一致,判断哪个可信要靠经验,新人容易出错

✓ 交给 Agent 之后

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

四、场景闭环

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

  1. 事实点提取 · 先找出所有需要核查的陈述自动识别:数据/统计、人名/职务/机构、时间/地点、引语/归因、因果关系;生成事实点清单
  2. 来源初筛 · 判断哪些可以自动核查、哪些必须人工介入可自动核查:公开数据/知名人物基本信息/公共记录;需人工:付费数据库/内部文件/口述内容
  3. 自动核查 · 能机器做的立刻做搜索引擎交叉比对、权威数据库查询、时间线一致性检验、算术验证
  4. 人工核查指引 · 机器做不了的给人指路每条需人工核查的事实点附带:建议查什么、去哪里查、查什么关键词、预期答案格式
  5. 风险评级 · 这篇稿子的整体风险有多高综合评分:事实准确性风险 × 来源可靠性风险 × 合规风险 × 潜在损害程度
  6. 输出核查报告 · 留证 + 可签字每条事实点附带:原文摘录/核查结果/依据来源/置信度/风险等级/处理建议;含签批栏

要准备什么:待核查稿件(Word/PDF/在线文档)最好是带有批注标记的版本;如果没有,Agent 自动识别事实性陈述引用来源列表(如有)作者提供的参考文献、采访对象联系方式、数据来源 URL 等内部事实核查模板(可选)用于对齐输出格式;如果没有,使用行业标准模板

为什么这个场景值得做

优先级评分:痛感 5 × AI 适配 5 ÷ 落地难度 2 = 15.0

最大差异点:不需要客户先建立事实核查知识库。稿件直接扔进来,Agent 自动识别事实性陈述并逐一核查。每条核查结论附带依据来源和置信度。

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

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

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

五、会产出什么

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

  • 正式件本体:事实核查报告.docx 完整的核查报告 · 含事实点清单/核查结果/依据来源/风险评级/签批栏
  • 可派发清单:需人工核查事项清单.xlsx 机器无法完成的部分 · 附带核查指引和预期答案格式
  • 可派发清单:事实点索引库.xlsx 本次核查的所有事实点及结论 · 用于积累复用

这套东西不承诺什么:不做最终的事实认定(「这条是真的/假的」这种结论由签发编辑或值班主任做出)。不访问付费数据库(如没有权限,会标明「需人工核查付费来源」)。不代替法律合规审查(涉及诽谤、隐私等内容需法务确认)。

② Live Demo(演示逐步)

一篇深度稿 15-20 个事实点逐个手工查,漏一个就是撤稿+内部通报 · 而核查员每天只有 4 小时能用来做这件事

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

案例设定:潮讯快讯事实核查专员钱屿,2026 年 8 月 13 日上午 9:00,记者交来的「祺瑞汽车 E3 事故深度报道」全文含 18 个需核实的事实点,值班主编下午 5 点前要签发,他必须在这之前敢说「核过了」——因为这句话的背面是「出了问题算他没核到」。其中最棘手的是车速:官方通报 98-105km/h、车主自述 120km/h、还有财经速览转引的 122km/h,三个数字他都要给出可信度判断。

事实点总数18 个自动核查12 个人工核查4 个结论2 处存疑 · 待补证

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

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

  • 01_待核查稿件全文_祺瑞汽车E3事故.xlsx 记者交来的全文,逐段标注出需要核实的事实点 —— 平时这个标注工作要核查员自己边读边划,没人事先拆解过记者 8/13 08:30 交稿 · 首次逐点拆解
  • 02_官方通报原文_上海市公安局静安分局.xlsx 警方通报的完整原文摘录 —— 这是唯一的一级信源,但核查员经常图快只看二手报道里的摘要而不查原文上海市公安局静安分局官方微博 8/12 20:15 发布
  • 03_车主原始微博_截图存档.xlsx 车主本人8月12日晚发的原始微博截图转录—— 核查员平时不会去翻当事人的原始社交媒体动态,只看二手引用车主个人微博账号 8/12 21:40 发布
  • 04_历史核查差错记录_近1年.xlsx 过去一年因核查疏漏导致的稿件问题记录 —— 每次出问题后口头总结一下,从未系统整理过值班主编口头提及 · 首次系统整理

注意标橙色那一份 —— 02_官方通报原文_上海市公安局静安分局.xlsx。它上海市公安局静安分局官方微博 8/12 20:15 发布,平时压根不在核对范围里。这个场景的价值,很大一部分就来自把它读进来。

提示词就说这么几句

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

这篇稿子今天要签发,帮我做事实核查。 这是稿件和作者提供的参考资料。 重点查:

  1. 所有数据是不是准确的
  2. 引用的话是不是被断章取义了
  3. 有没有一眼就能看出来的硬伤 拿不准的标出来,我去查付费来源。最终结论由签发编辑做。

短是因为核查规则和来源权重都写在能力包里了。你只需要把稿件和资料扔进来。

触发下午 5 点前必须敢说「核过了」

18个事实点 · 值班主编只关心「有没有硬伤」

钱屿手上的稿件里,18 个事实点大部分是客观陈述(日期、地点、车型),但有 3 条是同一件事的三个版本(官方通报98-105km/h、车主自述120km/h、自媒体转引122km/h),这三条必须放在一起判断,而不能核实一个就当作核查通过。

第 1 步 · 事实点提取 · 先分类哪些能自动核查、哪些必须人工

18个事实点按信源类型分类

演示数据(表格原文)事实点类型数量核查方式判断客观事实(日期/地点/车型等)9可自动核对通报原文车辆运行参数(刹车/转向等技术数据)4需人工确认专业口径车速三版本(官方/车主/转引)3需交叉核查信源等级赔偿金额与责任认定进展2可自动核对官方公告合计4类 · 18个事实点1811个可自动 / 4个需专业判断 / 3个车速多版本(1个可直接引用、2个存疑)车速三个版本被单独归为一类,不是因为它们最难核实,而是因为它们必须一起判断——只核实其中一个都不能算这条事实点核查完成。

这一步的看点 · 排除性结论车辆运行参数这 4 项可以排除「自动核查」的可能,依据是这些数据涉及专业技术口径(如「刹车助力系统响应时间」这类描述),机器能提取数字但判断「这个数字是否合理」需要懂车辆工程的人——省掉了尝试自动判断这4项的时间,直接标注转人工。

第 2 步 · 自动核查 · 能机器做的立刻做

9个客观事实+2个金额/进展类,逐条核对官方信源(通报原文/车企公告/公开数据)

演示数据(表格原文)事实点稿件表述官方信源原文核查结果事故日期2026年8月12日2026年8月12日一致事故时间14:3214时32分一致事故地点上海静安区某路口上海市静安区延长中路路口一致失控时长67秒约67秒(行驶约67秒后停止)一致涉事车型祺瑞汽车E3祺瑞汽车E3型一致车企历史投诉记录公开平台累计12起公开投诉平台可查12起一致车企历史召回记录近三年无相关召回车企公告:近三年无E3相关召回一致历史同类事故通报无同类失控事故监管部门无同类事故通报一致安全相关处罚记录无安全类行政处罚信用公开信息无相关处罚一致赔偿金额38.6万元(32.8+5.8)公告合计38.6万元一致(32.8+5.8=38.6核算无误)责任认定进展警方仍在调查已介入调查,具体原因将另行通报一致核对11项——11/11 一致表格 11 行对应 9 个客观事实(日期/时间/地点/时长/车型/4 项历史记录)加 2 个金额/进展类,逐字比对全部一致,这一类是本次核查里最省心的部分。

第 3 步 · 车速三版本交叉核查 · 这是本次核查的重点

信源等级不同,措辞也必须不同

演示数据(表格原文)车速版本来源信源等级措辞要求98-105km/h上海市公安局静安分局官方通报一级可直接引用为事实120km/h车主本人微博原文「大概120码左右」二级(当事人自述)必须标注「车主自述」+ 保留估测性措辞(大概)122km/h财经速览8月12日报道转引四级(二次转引,见FC-02)不建议引用,或引用时明确标注「转引自XX,未经证实」合计3个版本—1级1个/2级1个/4级1个—三个车速版本信源等级依次下降——官方通报最可靠,车主自述次之但带估测性措辞,财经速览的转引可信度最低。稿件如果三个数字并列呈现,必须让读者看出这个可信度梯度,不能一视同仁地列出来。

这一步的看点 · 从历史里想起了公司踩过的坑去年 4 月那次差错(04号文件)也是「车速类数字未核对多来源,直接引用当事人说法」——与本次如果不做交叉核查会犯的错误完全同类型。这次的处理方式是把三个版本的信源等级都标出来,而不是像去年那样直接采信车主的一句话——这条不靠钱屿记不记得去年那次教训,而是把「多版本必须标信源等级」做成了固定检查项。

第 4 步 · 人工核查指引 · 机器做不了的给人指路

4项车辆技术参数需要专业背景判断

演示数据(表格原文)事实点机器能做的人工需要判断的刹车系统响应参数提取稿件里的数字判断这个响应时间是否在正常范围内转向系统状态描述提取稿件里的表述判断「转向失灵」这个表述是否有官方依据支撑电池状态数据提取稿件里的数字判断这类数据的引用是否需要额外的专业信源其他运行参数提取稿件里的数字判断是否存在夸大或误读技术数据的风险这四项草稿里全部标注「需专业背景人工判断」,而不是让机器给出「合理」或「不合理」的结论——车辆工程判断不是文本核查能替代的。

第 5 步 · 风险评级 · 这篇稿子的整体风险有多高

18个事实点里,2个存疑决定了整体评级

演示数据(表格原文)风险来源涉及事实点评级依据车速122km/h转引来源存疑第12项四级信源,建议不引用或明确标注未经证实车主自述措辞可能被简化为确定事实第11项改编环节需保留「自述」「大概」等限定语整体风险:中—2处需在改编环节特别关注18 个事实点里 16 个已确认无误,剩下 2 个不是「核查失败」,是「核查后明确标注了使用限制」——这与「核查不出结果」是两种不同的状态。

这一步的看点 · 该拦的地方拦住了车速122km/h这个数字现在还不能在成稿里与官方通报数字并列呈现为同等可信度的信息——结论是「四级信源不能与一级信源用同样的措辞呈现,否则读者会误以为三个数字的可信度是一样的」。替代方案:要么不引用这个数字,要么明确标注「未经证实的转引信息」,把可信度差异展示出来而不是掩盖起来。

第 6 步 · 输出核查报告 · 留证 + 可签字

18项事实点逐条留痕,两处存疑单独标出

演示数据(表格原文)报告区块内容状态事实点核查总表18项逐条核查结果已完成车速三版本专项说明信源等级+措辞建议已完成需人工核查事项清单4项技术参数转专业人员待专业人员确认核查员签批栏钱屿留空待签合计4区块—2已完成 / 2待处理核查报告把能核实的部分填满,4项技术参数与签批栏一律留给专业人员和核查员本人——「核过了」这句话的责任由签字人承担,不能让系统代签。

这一步的看点 · 把技术动作翻译成钱18 个事实点里如果漏查了车速这类争议数字直接签发,参照去年 4 月同类差错(04号文件)的后果——被同行媒体指出「未经核实」,对机构信誉造成的损失无法用金额衡

量,但需要发更正声明、且更正声明本身会带来二次关注;而这次核查提前发现2处存疑并标注清楚,成本只是核查环节多花的这几个小时,换来的是稿件发布后不需要再被动更正。

之后这次核查跑完,攒下了什么

不是核完了18个事实点,是有了可复用的信源分级方法

沉淀项具体内容车速类数字的信源分级方法固定下来以后遇到同一事件多个数字版本,先查信源等级(官方通报>当事人自述>自媒体转引),再决定怎么措辞「多版本数字必须一起判断」成为固定检查项不再是核实一个数字就算完成,而是同一事件的所有版本数字都要放在一起比对信源转给下游的任务更明确「车速三版本」的核查结论直接转给夏牧之(CE-01),带着「哪个可以直接引用、哪个要加限定语」的明确指引这次核查的真正产出不是「18个事实点都核完了」,而是把「多版本数字怎么判断可信度」这件事,从「核查员凭经验」变成了「有信源等级依据的判断」。

这篇稿件现在还不能直接签发18: 个事实点里 16 个已确认无误,但4项车辆技术参数需要专业人员判断,2处车速相关信息需要在改编时严格保留信源等级标注——在这两项完成之前不能签发。方案一 · 先发不涉及技术参数的部分:今天先发「事故时间线+车速版本对比」的轻量版,技术参数确认后再发深度版。代价是今天的稿子信息量有限;方案二· 等技术参数确认后一次成稿:转专业人员今天下午确认4项技术参数,预计傍晚前有结果,今晚发完整版。代价是比方案一晚几个小时,但发出去的版本更完整。建议方案二。车辆技术参数这类专业内容,「发得快」不如「发得对」——涉及车辆安全的技术判断如果出错,比车速数字出错的后果更严重。

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

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

  • ✓ 事实核查多了一个可复用的索引库:每次核查过的 facts 入库,下次遇到同样的事实点直接复用
  • ✓ 两条核查规则被固定下来:具体是「统计数据必须找到原始出处」和「专家引语必须核对原始语境」
  • ✓ 一条历史教训被真正用上:某次因「断章取义的专家言论」导致的撤稿被写入自动预警规则
  • ✓ 岗位角色变了:从「花 4 小时逐条手工核查、漏一条就担责」变成「花 1 小时核对 Agent 初稿、重点复查高风险项」

追问现场可能被问到的

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

  • 能保证核查完就没有事实错误吗? 不能保证 100%,但能把显性的、可自动核查的错误降到最低。最终签字权在你手里,我只是帮你把能查的都查了。
  • 付费数据库里的数据怎么办? 我会标明「此数据来源于 XX 数据库,需人工核查」并告诉你大概查什么、去哪查。如果你有数据库的导出权限,也可以把导出结果给我,我在本地帮你对。
  • 核查报告能给法务看吗? 可以,报告格式是按照行业审计标准设计的,含完整的依据来源和签批栏。但法律风险的最终判定还是要法务来做。

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

一篇深度稿 15-20 个事实点逐个手工查,漏一个就是撤稿+内部通报 · 而核查员每天只有 4 小时能用来做这件事

1. Skill 能力包

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

稿件事实核查辅助 · Skill

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

版本 v1.0

fact-checking-assistant.zip

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

包内结构

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

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

2. 原始素材

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

📁FC-01 · 演示素材

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

共 4 份

  • 01_待核查稿件全文_祺瑞汽车E3事故.xlsx 记者交来的全文,逐段标注出需要核实的事实点 —— 平时这个标注工作要核查员自己边读边划,没人事先拆解过
  • 02_官方通报原文_上海市公安局静安分局.xlsx 警方通报的完整原文摘录 —— 这是唯一的一级信源,但核查员经常图快只看二手报道里的摘要而不查原文
  • 03_车主原始微博_截图存档.xlsx 车主本人8月12日晚发的原始微博截图转录 —— 核查员平时不会去翻当事人的原始社交媒体动态,只看二手引用
  • 04_历史核查差错记录_近1年.xlsx 过去一年因核查疏漏导致的稿件问题记录 —— 每次出问题后口头总结一下,从未系统整理过

怎么用

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

3. 提示词卡片

这篇稿子今天要签发,帮我做事实核查。 这是稿件和作者提供的参考资料。 重点查:

  1. 所有数据是不是准确的
  2. 引用的话是不是被断章取义了
  3. 有没有一眼就能看出来的硬伤 拿不准的标出来,我去查付费来源。最终结论由签发编辑做。

为什么这么短就够了:短是因为核查规则和来源权重都写在能力包里了。你只需要把稿件和资料扔进来。

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

XLSFC-01_事实核查报告.docx完整的核查报告 · 含事实点清单/核查结果/依据来源/风险评级/签批栏下载

  • ↓XLSFC-01_需人工核查事项清单.xlsx 机器无法完成的部分 · 附带核查指引和预期答案格式
  • FC-01_事实点索引库.xlsx 本次核查的所有事实点及结论 · 用于积累复用

Skill 里固化了什么:从历史核查记录里想起了上次踩过的坑该拦的错误拦住了排除性结论把核查结果翻译成责任语言

输入清单:待核查稿件(Word/PDF/在线文档)最好是带有批注标记的版本;如果没有,Agent 自动识别事实性陈述引用来源列表(如有)作者提供的参考文献、采访对象联系方式、数据来源 URL 等内部事实核查模板(可选)用于对齐输出格式;如果没有,使用行业标准模板

人工边界:不做最终的事实认定(「这条是真的/假的」这种结论由签发编辑或值班主任做出)。不访问付费数据库(如没有权限,会标明「需人工核查付费来源」)。不代替法律合规审查(涉及诽谤、隐私等内容需法务确认)。

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

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

事实核查专员 · 产出即下一步输入

FC-02 · 引用来源与数据交叉验证 — 稿件里引用了 8 个来源,其中 3 个是二手转引、2 个已经失效、1 个根本不存在· 但这些在签发前没人系统性查过 查看 →

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

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

想把这个场景在你们企业跑通?

顾问会先看你们的数据和流程够不够,再决定从哪一步开始。