CtrlK
BlogDocsLog inGet started
Tessl Logo

article-fact-checker

逐段逐句鉴定一篇文章内容的真伪,拆解论证结构,对每个事实/推断节点做六维核查(逻辑正确性、结论可量化性、证据链完整性、证据是否捏造、证据可考证性、来源可信度),最后输出带原文定位的问题清单和置信度打分表。触发条件:用户提到"鉴别真伪"、"这篇文章可信吗"、"内容审查"、"事实核查"、"fact check"、"这段话是真的假的"、"帮我查一下这篇文章的漏洞"、"证据链完不完整"、"这个结论站得住脚吗"、"逐句检查"、"这篇报道靠谱吗",或者给出一篇文章/一段内容并希望知道"能不能信"、"哪里有问题"、"论证严不严密"。即使用户只说"帮我看看这篇文章有没有问题"或"这篇文章说的是真的吗",也应使用本 skill。输出为 Markdown 报告,保存到当前项目 markdown/ 目录。

70

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

文章真伪鉴定

这个 skill 在做什么,为什么这么设计

逐字逐句核查是最耗时也最容易做偏的方式——如果不先搭结构,很容易把力气花在 "这句话写得挺有文采"这种无信息量的修辞句上,反而漏掉真正承载事实主张的关键句。 所以这个 skill 分两步走:

  1. 先拆结构,不先核查:把文章还原成"结论 ← 分论点 ← 证据"的论证树,只标出 承载事实陈述或因果/推断主张的句子作为核查对象,纯描述、过渡、情绪煽动句只 标记类型,不逐条查真伪。这样能把工作量集中在真正需要核查的 20%~30% 的句子上。
  2. 对每个核查节点跑六维检验,而不是笼统给一个"可信/不可信"。六维分别对应 六种不同的造假/失实模式——逻辑断裂、结论空心化、证据链缺环、数据捏造、 孤证无法溯源、来源本身不可靠——混在一起打一个总分,用户没法知道问题到底出 在哪一环,也没法针对性地去核实。

打分用取短板而不是取平均:六维里任何一维出现严重问题(比如证据被证实是 捏造的),这个论证节点的综合置信度就应该被拉到很低,不能被其他维度的高分拉平—— 一篇文章"看起来逻辑严密、来源权威,但关键数据是编的",本质上比"逻辑略松散但 证据都真实"更危险,取平均会掩盖这一点。

第一步:拿到原文

  • 用户直接粘贴文本:直接用。
  • 用户给的是文件路径:纯文本/Markdown 直接读;docx/pdf/pptx 先用对应技能 (docx / pdf-reading / pptx)提取正文再继续,不要对着带格式标记的原始内容分析。
  • 用户给的是 URL:用 web_fetch 抓取正文。

第二步:拆解论证结构

通读全文一遍,产出一张论证树,明确以下三类元素:

  • 主结论:文章最终想让读者相信/接受的核心主张。
  • 分论点:支撑主结论的中间层论点。
  • 句子分类:把文章里每一句/每一段拆成下面几类,并标注原文定位(第几段/ 引用原句片段):
    • 事实陈述句(可核查对象):有具体的人、事、时间、数字、机构。
    • 因果/推断句(可核查对象):从A推出B,包含"导致""因为""说明""证明" 这类连接词。
    • 定性/评价句:不含可验证事实,但构成文章的核心论点(比如"这项技术具有 革命性意义")——这类要单独处理,见第四步。
    • 修辞/过渡/情绪句:无实质信息量,不需要核查真伪,但如果煽动性明显, 在报告里提一句即可,不用展开。

只对前三类(事实陈述句、因果/推断句、定性/评价句)逐一进入第三、四步的核查。

第三步:对事实陈述句和因果/推断句做六维核查

对每一个核查节点,逐维打分(0-100)并写出依据:

维度检查什么常见问题信号
① 逻辑正确性形式层:有没有滑坡、稻草人、诉诸权威、幸存者偏差、相关当因果、以偏概全;结构层:论据支撑的到底是这句结论,还是一个"看起来差不多但范围不同"的结论用"样本涨了30%"支撑"行业普遍上涨"这类偷换范围的手法最隐蔽,要重点看
② 证据链完整性先判断论证类型(演绎/归纳/类比/因果),再对照该类型该有的环节找缺口:因果论证缺"排除混淆变量、时间先后顺序、反例检验";归纳论证缺"样本量、样本代表性、选择性引用";类比论证缺"类比双方的关键相似点是否真的成立"明确写出"缺了什么",不要只说"证据链不完整"
③ 证据是否捏造反向搜索原始数据源(用 web_search);核对时间线是否自洽(事件时间/报道时间/引用时间有无矛盾);数字是否经得起量级估算(费米估算法,很多编造数据一算就露馅)找不到原始出处、时间线矛盾、数量级明显不合理
④ 证据可考证性分三级标注:一手可核实(有链接/可查原始出处)、二手转引(只能查到"某人说")、无法溯源(孤证、匿名消息源、"业内人士透露")级别越低,这一维分数越低
⑤ 来源可信度来源历史准确率、作者/来源与该结论是否有利益关联(利益相关方陈述天然降权)、该来源是否有过因类似内容被打脸的记录用 web_search 查该来源过往报道的可信记录
⑥ 综合置信度不是六维平均,而是取短板(木桶原理):任一维严重偏低,综合分跟着拉低证据链断了一环,逻辑再漂亮也不该给高分

需要外部核实的地方(原始数据源、时间线、来源历史记录)主动用 web_search / web_fetch 去查,不要凭训练知识臆断,也不要因为"这个说法很常见"就默认为真。

第四步:定性/评价句的替代检验(不可量化结论怎么判断真伪)

定性结论没法用数字验证,但可以用三条替代路径:

  1. 可证伪性测试:这个结论如果是假的,世界应该长什么样?如果作者举不出 "什么情况下这个结论会被推翻",标记为"不可证伪,存疑"。
  2. 内部一致性测试:这个定性结论和文章里其他可量化的事实是否矛盾?矛盾就是 造假或逻辑断裂的信号。
  3. 同行共识锚定法:用 web_search 把这个定性结论放到该领域公开的专家共识/ 综述文章里比对,标注它是"共识观点""少数派观点"还是"孤例主张"三者之一, 在打分里体现——共识观点即使无法精确量化,可信度权重也应高于孤例主张。

第五步:汇总打分与问题清单

产出一张表,每行对应一个核查节点:

序号原文定位(段落/引用片段)类型①逻辑②证据链③是否捏造④可考证性⑤来源可信度综合置信度(取短板)问题说明

问题说明要具体到"缺了什么/矛盾在哪/查不到出处",不能只写"存疑"。

第六步:输出 Markdown 报告

保存到当前项目的 markdown/ 目录(没有就创建),文件名格式: markdown/真伪鉴定-<文章标题或简短标识>.md

报告结构:

# 文章真伪鉴定报告:<标题>

## 结论摘要
一句话总结:这篇文章整体可信度如何,最大的问题出在哪一环。

## 论证结构
- 主结论:...
- 分论点:
  1. ...
  2. ...

## 核查节点明细表
(第五步的表格,全部核查节点)

## 定性结论核查
(第四步涉及的定性/评价句,逐条给出可证伪性/一致性/共识锚定的判断)

## 未核查内容说明
(修辞/过渡/情绪句的简要说明,不用逐条展开)

## 总体置信度
| 项目 | 结果 |
|---|---|
| 核查节点总数 | N |
| 高置信度(≥80) | N |
| 中等置信度(40-79) | N |
| 低置信度(<40,需重点关注) | N |
| **文章整体可信度判断** | 高 / 中 / 低,附一句话理由 |

存完文件后用 present_files 呈现报告,简短说一句结论(整体可信度+最大问题点), 不用把报告内容在对话里重复一遍。

边界情况

  • 文章很长(超过几千字):可以按小节分批处理论证树和核查表,但最终汇总成 一张完整的核查节点表,不要拆成多个文件。
  • 纯观点性文章(几乎没有事实陈述):核查重点转向第四步的定性检验和第一步 的逻辑检验,提前跟用户说明"这篇文章事实性内容较少,核查会以逻辑严密性和 论点一致性为主"。
  • 用户只想查某一段/某几句,不是全文:可以只对用户指定的部分走完整流程, 但仍要先看一眼上下文,确认这段话在全文论证结构里的位置,避免断章取义式核查。
  • 核查过程中发现证据造假的确凿证据:直接在问题说明里明确指出,不要因为 "不确定意图是不是恶意"而弱化措辞,但也不要过度延伸推测作者动机——只说 "证据与可查证的原始来源不符"这类事实层面的判断,不做诛心之论。
Repository
digoal/blog
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.