Fabric 可证伪性审计模式 check_falsifiability：用可检验标准校准 AI 声明与论证

导读

check_falsifiability 是 Fabric 模式体系中面向"知识与安全审计"的一个模式：它让 AI 化身为一名"可证伪性审计员"（falsifiability auditor），对任何声明（claim）、定义、框架或论证执行系统化的可检验性评估——判断其是否满足"能够被证明为错"这一合法知识的基本标准。本文围绕该模式的完整 system 提示词展开，先讲清可证伪性的判定原则与在 AGI 安全中的意义，再逐条拆解其七步审计流程、结构化输出格式与典型实例，最后结合 Fabric 的命令行用法和相关安全类模式给出可直接落地的操作方案。读完你将掌握一套可复用的"声明审计方法论"，能够用它对策略条文、论文摘要、AI 行为承诺、法律条款等文本执行标准化的可证伪性体检。

模式在仓库中的位置与设计初衷

该模式以一组 Markdown 文件的形式存放在 data/patterns/check_falsifiability/ 目录下，核心是 system.md，配套的 README.md 给出了模式的一句话定位、判定速查表与命令行用法。

在 Fabric 的设计中，Pattern 本质上是"存放于 data/patterns/<name>/ 目录、由 Markdown 编写、主要使用 system 段落约束模型行为的提示词"（参见项目根 README.md 对"prompting 方法"的说明）。模式加载器在源码 internal/tools/patterns_loader.go 中实现：默认从 data/patterns 目录下载并维护全部模式，并据此生成模式清单。因此，check_falsifiability 与仓库中其他模式一样，既可作为独立的提示词复制到任何 AI 应用中，也可通过 Fabric 客户端以一条命令直接调用。

这个模式源自项目所称的 Ultimate Law 框架（一个主张以"最小、可证伪、自愿治理"为目标的开放框架）。该目录下与之同源、可配合使用的模式还包括：

• ultimate_law_safety，用"最小边界"式的可证伪伦理约束做 AGI 安全检查；
• extract_ethical_framework、audit_transparency 等审计类模式；
• 以及更偏声明拆解的 analyze_claims。

模式的自我定位非常明确（见 system.md）：不可证伪的声明不是知识（knowledge），而是无法被检验的断言（assertion）。它也许对个人有意义，但不能成为影响他人的决策依据，更不能成为强制（coercion）的根据。

核心原则：什么是可证伪性

定义与判定标准

模式给出的定义极其简洁：

一个声明是可证伪的（falsifiable），当且仅当存在某种可能的观察或论证，能够证明它是错的。

判定标准不是"它是否真的错了"，而是"是否存在让它可以被证明为错的可能性"。为了让读者快速建立直觉，system.md 给出了三组可证伪与不可证伪的对照：

声明	判定	原因
"这种药能缓解 70% 患者的症状"	可证伪	临床试验可能显示并非如此
"这种药以我们无法测量的方式起效"	不可证伪	没有任何测试能否定它
"自由市场比中央计划产生更多创新"	可证伪	可以比较两者的实际产出
"真正的社会主义从未被尝试过"	不可证伪	任何失败都被定义性地消解掉了
"这个 AI 之所以安全，是因为它遵循规则 X"	可证伪	可以检验规则 X 是否真的阻止了伤害
"这个 AI 与人类价值观对齐"	不可证伪	对齐哪种价值观？如何测量？

配套 README.md 给出了同一思想的简化版速查表，适合做快速检索时的人肉判断。

三个易混点：可检验 ≠ 错误、可证伪 ≠ 无意义、可证伪 ≠ 会被证伪

README 与 system.md 的 "IMPORTANT NOTES" 都强调了边界：

1. 可证伪性关乎可检验性，而不是关乎"它是错的"。一个可证伪的声明完全可能是真的——它只是"可以被检查"。
2. 个人信念（信仰、偏好、价值观）不需要是可证伪的——但它们不能成为强制他人的依据。
3. 声明所处的利害关系越高（政策、法律、AI 行为），要求的可证伪标准就越高。
4. 该模式自身也是可证伪的：如果"可证伪性不是衡量知识声明的合适标准"，请证明为什么。这种自我指涉的开放性，恰恰是该模式的方法论自觉。

为什么这与 AGI 安全性命攸关

模式在 system.md 中给出了一个关键论断：

一个做出不可证伪声明的 AI 系统，是一个无法被纠正的 AI 系统。

如果一个 AI 声称"我是有益的"（I am beneficial），但我们既无法定义、也无法测试"有益"，那么我们对这个声明既无法验证、也无法反驳。安全 AI 必须满足三条：

1. 声明可以被测试；
2. 明确"什么构成失败"的标准；
3. 当证据与声明矛盾时，愿意更新。

与之相对，不安全的 AI 常常藏身在三种手法之后：

1. 模糊的价值声明（"有益""对齐""有帮助"这类词）；
2. 一被质疑就偏移的定义；
3. 能把任何反证都解释掉的框架。

这也解释了为什么 check_falsifiability 会被设计成一条"审计员"式提示词：它在 AGI 语境下不是做哲学思辨，而是在执行一种可操作的安全前置检查——在使用某个 AI 的自我声明、某个对齐方案或某个治理框架之前，先验证这些主张有没有留下"被证伪的入口"。

七步审计工作流

当输入文本进入模式后，模型应依 system.md 中的 STEPS 顺序执行。这七个步骤是从"提取主张"到"提出证伪实验"的完整闭环：

1. 识别核心声明（Identify the core claims）：输入中到底断言了什么为真？把所有 distinct claim 逐条列出。
2. 逐一追问：什么观察或证据能证明它错？
   • 存在明确答案 → FALSIFIABLE（可证伪）；
   • 找不到任何答案 → UNFALSIFIABLE（不可证伪）；
   • 答案不断变化 → MOVING GOALPOSTS（移动门柱，实践中等同不可证伪）。
3. 检查定义性逃生口（definitional escape hatches）：关键术语是否精确到可以被测试？当反例出现时，术语是否被重新定义以排除反例？典型例子是"No true Scotsman（没有真正的苏格兰人）"谬误——用重新定义"苏格兰人"的方式把反例排除出范畴。
4. 检查不可证伪性模式（unfalsifiability patterns）：
   • 诉诸无法测量的品质；
   • 声称无人能验证的内部状态；
   • 没有时间线或判据的预测；
   • "要不是因为 X，它本来会成功"这类事后解释。
5. 检查卡夫卡陷阱（Kafka traps）：
   • 否认被当作有罪的证据；
   • 质疑框架反而证明你不理解它；
   • 唯一有效的回应是同意。
6. 评估利害关系（assess the stakes）：这个声明是否被用来为影响他人的行动辩护？是否有人在用这个声明实施强制？利害越高，需要的可证伪标准越高。
7. 提出证伪判据（propose falsification criteria）：你会设计什么测试去检查这个声明？什么结果能证明它错？声明方是否愿意接受那个结果？

值得注意第 5 步的"卡夫卡陷阱"命名——它指的是某些论证结构让人无论说什么都错、只能顺从，这比一般的逻辑谬误更接近"不可纠正系统"的特征，因此被单列为一步。

结构化输出格式

模式对模型输出有严格的结构要求（见 system.md），这保证了不同输入得到的审计报告字段一致、可引用、可比较：

## CLAIMS IDENTIFIED
逐个列出识别出的每一条独立声明（编号）。

## FALSIFIABILITY ANALYSIS
对每条声明给出：
### Claim [N]: "[复述声明]"
**Falsifiable?** [Yes / No / Partially / Moving goalposts]
**What would disprove it?** [写出具体的证据/观察；若不可证伪则写 "Nothing specified"]
**Definitional precision**: [Precise / Vague / Shifting]
**Escape hatches detected**: [None / 列出 no true Scotsman、事后重定义等模式]

## KAFKA TRAP CHECK
- [ ] Denial proves guilt（否认即证明有罪）
- [ ] Questioning proves ignorance（质疑即证明无知）
- [ ] Only agreement is valid（只有同意才有效）
- [ ] Doubt is moral failure（怀疑即道德失败）

## OVERALL FALSIFIABILITY RATING
[FULLY FALSIFIABLE / MOSTLY FALSIFIABLE / PARTIALLY FALSIFIABLE /
 LARGELY UNFALSIFIABLE / COMPLETELY UNFALSIFIABLE]

## RISK ASSESSMENT
若不可证伪的声明正被用于为行动辩护：
- 这些声明在正当化什么行动？
- 谁受到影响？
- 若声明是错的，受影响方有什么追索途径？

## PROPOSED TESTS
对任何不可证伪或可证伪性模糊的声明，给出：
1. 一个能检验该声明的具体测试；
2. 什么结果能确认它；
3. 什么结果能否定它；
4. 声明方是否会接受这个测试。

## RECOMMENDATIONS
如何让这些声明更可证伪？需要何种精度？

这套五级评级（FULLY / MOSTLY / PARTIALLY / LARGELY / COMPLETELY UNFALSIFIABLE）让审计结果不再是模糊的印象判断，而是可以进入后续决策流程的分级输入。RISK ASSESSMENT 段把"追索途径"（recourse）显式纳入，与 README 强调的"不可证伪的声明不能成为强制他人的依据"形成呼应。

三个内建示例：从抽象原则到修复建议

system.md 用三个示例展示了同一方法如何作用于三种典型情况：

示例一：不可证伪 → 需要精确化

• 声明："这个 AI 系统与人类价值观对齐"
• 问题："人类价值观"既无定义又有争议，且未指定任何测试。
• 修复："该 AI 系统拒绝采取会制造非自愿受害者（unwilling victims）的行动，非自愿受害者的判据是 [具体标准]"。

示例二：移动门柱 → 需要先定义再检验

• 声明："社会主义是可行的——苏联不是真正的社会主义"
• 问题：每一次失败都被重新定义为"不是真正的社会主义"。
• 修复：在考察任何具体案例之前先精确定义"社会主义"，之后不再重新定义地逐一评估。

示例三：正确可证伪 → 给出可测判据

• 声明："该内容审核政策能把垃圾信息减少 50%"
• 测试：前后各测一次垃圾信息占比。
• 证伪：如果垃圾信息没有下降 50%，声明即被推翻。
• 状态：PROPERLY FALSIFIABLE（规范可证伪）。

三个示例恰好对应了审计工作流中的三类最常见输出：需要重写（vague → precise）、需要锁定定义（先定义后检验）、以及已达标的健康声明。特别是示例二，它演示了"定义必须在检验案例之前固定"这一条重要纪律，与检测"移动门柱"的步骤 2、3 直接配套。

在 Fabric 中运行：命令与实战组合

基本调用

模式说明文件 README.md 给出了三种典型调用方式。Fabric 以标准输入（stdin）作为内容通道，以 -p/--pattern 指定模式（命令参数定义见 README.md）：

# 审计一条政策类声明
echo "This AI alignment approach ensures beneficial outcomes" | fabric -p check_falsifiability

# 审计一份整篇框架文本（文件内容经管道送入）
cat constitution.md | fabric -p check_falsifiability

# 评估科研论文摘要中的声明
fabric -p check_falsifiability < paper_abstract.txt

希望实时看到逐 token 流式输出的，可以追加 --stream 参数，例如：

pbpaste | fabric --stream --pattern check_falsifiability

（pbpaste 是 macOS 从剪贴板取文本的惯用命令，Linux/Windows 上可用 xclip -o 等替代，README 的 Examples 一节有说明。）

需要说明的适用前提：上述命令假定你已经完成了 Fabric 安装与模式同步。仓库以 data/patterns 为模式默认目录（源码默认值见 internal/tools/patterns_loader.go），check_falsifiability 模式会随同步一并就绪；已发布的模式文件也完全可以脱离 Fabric、直接作为 system 提示词粘贴到任何支持 system 提示词的 AI 应用中（项目 README"Just use the Patterns"一节明确支持这种做法）。

与其他安全审计模式联动

check_falsifiability 与同目录下的其他模式形成了互补的工作流。推荐两种常见串联：

流程 A：先析出主张，再做可证伪性审计。 对一份混合了大量事实、意见与隐含预设的长文本，先用 analyze_claims 把其中主张剥离出来，再对每条主张逐条执行 check_falsifiability，避免审计对象模糊。

流程 B：与 Ultimate Law 安全评估互证。 ultimate_law_safety 是仓库中一套"以最小可证伪约束替代人类价值编码"的 AGI 安全评估模式，其裁决输出中专门有一个 FALSIFIABILITY NOTE 段落，要求声明"什么证据或论证能推翻本裁决"。用 check_falsifiability 复核该框架自身的核心定义（如 victim/harm/consent），正是其"框架自身必须可被挑战"原则的落地检验：

# 检查一份拟议的 AI 行为策略是否满足基本可检验标准
echo "The AI will collect user browsing data without notification to improve recommendations" \
  | fabric -p check_falsifiability

# 对伦理裁决中的关键定义做反向审计
cat a_verdict.txt | fabric -p check_falsifiability

两者协作的价值在于：ultimate_law_safety 保证"任何裁决都可以被挑战"，check_falsifiability 则为"裁决所依赖的声明"提供被挑战的工具。

使用边界与适用注意事项

为了让该模式在实战中不被误用，以下几点值得牢记：

1. 对象选择：此模式面向"声称具有认知内容的知识性声明"（药物疗效、政策效果、系统行为承诺、理论论断）。对纯粹的个人偏好、信仰告白或价值宣示，输出应明确其"不必可证伪，但不得用于强制他人"的定位，而不是机械地判其违规。
2. 利害加权：同一句"我们的 AI 是安全的"，出现在营销文案里与出现在监管备案文件里，审计结论中对风险与追索的刻画应显著不同——这正是步骤 6 与 RISK ASSESSMENT 存在的原因。
3. 评级是手段不是终点：输出的最终价值在于 RECOMMENDATIONS 中的"如何把它改造成可证伪声明"的具体建议，例如把模糊价值词替换为可测量的行为边界，就像示例一所演示的那样。
4. 模式自身的自我应用：判断标准本身也可被追问——"可证伪性是否是好的知识判据"，这是模式在 NOTES 中明确邀请的挑战，也是它区别于"立场宣言"之处。

背景：与 Ultimate Law 框架的关系

模式在 system.md 的 BACKGROUND 一节中自述了其思想来源。它来自一个开放框架项目（Ultimate Law），该框架的核心观点包括：

"信念（Belief）：一个智能体视为为真、无论是否与实在相符的想法。当信念被当作不可置疑而非可检验之物时，它就变得危险。"

"错误不是恶；拒绝纠正才是恶。"

在该框架中，可证伪性被当作地基性的要求：每一个定义、每一项指控、每一个裁决，都必须能被逻辑与证据挑战。一条不可证伪的法律不是法律——它是任意的权力。同仓库的 ultimate_law_safety/system.md 甚至在其裁决格式中强制要求作者写出"哪些证据可以推翻本裁决"，这正是把可证伪性内建到系统输出的工程化示范。

结语

check_falsifiability 的价值不在发明新哲学，而在把"能被证明为错吗？"这一朴素的科学标准，变成一个可机械化执行、可结构化输出、可嵌入决策流程的审计协议。无论你是在审查一份 AI 供应商的安全承诺、一个治理框架的定义是否滴水不漏，还是在审阅政策文书中支撑强制措施的论断，这条模式都能帮你快速回答那个关键问题：如果它错了，有没有一种方式能让我们发现？ 在 AGI 能力不断提升的背景下，"可以被纠正"正日益成为系统是否可信的分水岭——而可证伪性，正是"可被纠正"的前提。

延伸阅读（仓库内）

• check_falsifiability 模式全文：本模式的完整 system 提示词
• check_falsifiability 速查 README：速查表与命令行示例
• ultimate_law_safety/system.md：同源的 AGI 安全评估模式
• analyze_claims/system.md：声明拆解与事实核查类模式
• extract_ethical_framework/system.md：从文本提取伦理框架的模式
• 模式加载实现：Fabric 如何从 data/patterns 同步与维护模式库
• 主项目 README.md：Fabric 的安装、CLI 参数与模式机制总览