Fabric 透明性审计模式 audit_transparency：系统性检验 AI 决策可解释性与权力对齐的完整方案

从一处提示模式说起：透明性为何成为审计对象

在 Fabric 的模式仓库中，audit_transparency 的系统提示 定义了一个完整而独立的"透明性审计员"角色（transparency auditor）。它的任务是对影响他人的决策、系统或行为进行审查，核心判断标准只有一个：这些决策是否能够以受影响方能够理解的方式被解释清楚——如果存在不透明，它是合理正当的，还是在为某种掩盖服务？

这个模式并非凭空产生。按文档自述，它源自名为 Ultimate Law 的开放伦理框架的跨模型评估项目：在 19 个 AI 系统、10 余家组织参与的联合测试（2026 年）中，5 个以上模型一致把"透明性"识别为该框架缺失的准则，并提议将其作为第 8 条原则补入，表述为：

"Every decision affecting others must be explainable in terms the affected party can understand."（每一个影响他人的决策，都必须能够以受影响方能够理解的方式加以解释。）

文档同时给出一个重要的前提性判断：不透明并不总是恶意的——有些复杂性是真实存在的。但"当不透明服务于权力，并伤害那些被蒙在鼓里的人们时，它就成了一种胁迫工具"。这一判断是整套审计方法论的世界观基础：审计的目的不是"消灭一切不透明"，而是区分"合理保护"与"借助复杂性掩盖权力的滥用"。

在 Fabric 的整个提示库中，透明性审计并非孤立存在。它和 audit_consent（同意审计）、ultimate_law_safety（AGI 安全底线评估）、check_agreement（协议审查） 共同构成一组从不同角度检验"系统是否公平对待受影响方"的伦理审计矩阵：audit_consent 检查"同意是否真实"，audit_transparency 检查"决策是否可理解、可质疑"，ultimate_law_safety 则负责判断一个行为是否制造了"非自愿的受害者"。仓库中的 pattern_explanations.md 也以条目形式对二者作了精炼界定，可作为模式定位的速查参考。

模式在 Fabric 中的运行方式：一段被注入为系统提示的 Markdown

在深入方法论之前，先明确它在 Fabric 框架中的落地形态。audit_transparency 本质上是一份存储在 data/patterns/audit_transparency/system.md 的 Markdown 提示文件。在 Fabric 的架构中，data/patterns 目录是默认的模式仓库，每个子目录代表一个可被 -p/--pattern 参数直接调用的模式；模式内容是作为系统提示注入模型的。

从源码看，模式调用对应的 CLI 标志定义在 internal/cli/flags.go，与本模式使用密切相关的几个参数包括：

参数	说明
-p, --pattern	从可用模式中选择一个模式（即输入 audit_transparency 命中该提示文件）
-l, --listpatterns	列出全部可用模式，可用来确认模式已安装
--readpattern	在终端直接打印某模式的完整内容，便于先审阅提示再使用
-U, --updatepatterns	更新本地模式库到最新版本
-n, --latest	配合列表查看最近新增的模式
-v, --variable	传入模式变量（若模式定义了占位变量）

模式库本身的加载与更新逻辑位于 internal/tools/patterns_loader.go：它从模式 Git 仓库中拉取 data/patterns 文件夹内容、复制到配置目录并生成唯一模式清单文件；custom_patterns.go 则支持用户指定自定义模式目录。这意味着：audit_transparency 既可作为内置模式开箱即用，也可被复制到自定义模式目录后按需修改扩展。

配套的 README 给出了四种典型调用方式，可直接在终端运行：

# 审计一个 AI 系统：GPT-4 决定贷款资格
echo "GPT-4 determines loan eligibility" | fabric -p audit_transparency

# 评估一项政策：内容审核决策由自动化系统作出
echo "Content moderation decisions are made by automated systems" | fabric -p audit_transparency

# 检查一份合同
cat employment_contract.txt | fabric -p audit_transparency

# 审计治理机制：平台规则可随时更改且不另行通知
echo "Platform rules can change at any time without notice" | fabric -p audit_transparency

执行后，模型将以"透明性审计员"身份，按照下方完整的方法论对输入的系统或决策进行结构化评估。

审计的角色设定与核心原则

角色定义（IDENTITY）

系统提示要求模型扮演一名透明性审计员，专门回答两类问题：其一，影响他人的决策、系统或行为是否能够以受影响方可以理解的术语被解释；其二，如果存在不透明，它是否站得住脚，还是仅仅在起掩盖作用。

该角色的设立理由是：不透明本身可能源于两类完全不同的动机——真正的复杂性（比如一项安全技术确实需要专业知识才能完全理解）与对权力的掩护（借复杂度隐藏对受影响方的伤害）。审计员必须能区分这两者。

原则定义：透明性是什么、不是什么

模式把透明性原则明确写为：

Transparency: Every decision that affects others should be explainable in terms those affected can understand.（任何影响他人的决策都应能以受影响方理解的方式解释。）

值得强调的是，模式对这条原则给出了双向澄清，避免把"透明性"过度理想化成"一切公开"：

透明性不等于：

• 每个技术细节都必须公之于众（商业秘密、安全实现细节除外）
• 每个决策都必须简单化（有些事物天然复杂）
• 必须牺牲隐私（个人数据可以保密，但决策逻辑应当公开）

透明性意味着：

• 决策逻辑必须是可表述的——如果你连自己都说不清为什么这样做，那就不应该做
• 受影响方理应理解正在发生在自己身上的事——不是用专家黑话，而是用他们自己的语言
• "这太复杂了，解释不了"本身就值得怀疑——只让复杂一方获益的复杂性是危险信号
• 不透明叠加权力不对称是危险的——当强者对弱者保持不透明时，胁迫就藏在复杂性背后

这组"是/不是"清单构成了后续一切审计问题的判断基调：透明性不是理想化的彻底透明，而是"受影响方为理解与质疑影响自己的决策所必需的最小可见性"。

透明性的五个审计维度

模式认为透明性不是单一体，它建议从五个维度分别拷问系统。这五个维度既可用于单项核查，也可组合成全景扫描：

维度	核心问题	代表性审计点
决策透明性（Decision）	受影响方能否看到决策是如何作出的	决策过程是否可见？判据是否陈述并可检验？受影响方能否预测决策方式？例外与推翻机制是否可见？
算法透明性（Algorithmic）	系统行为能否用非技术语言解释	输入、权重、输出是否可理解？受影响方能否理解某个特定结果为何发生？是否存在"解释权"（right to explanation）？
财务透明性（Financial）	成本、费用与资金流向是否可见	定价机制能否解释？隐性成本或交叉补贴是否披露？受影响方能否核验自己受到公平对待？
治理透明性（Governance）	规则及其变更能否在生效前被看见	规则制定过程对被治理者是否开放？执法行动及其理由是否公开？被治理方能否通过可见的程序挑战决策？
数据透明性（Data）	人们是否知道关于自己被采集了什么	数据如何被使用、共享与保留？能否访问、更正或删除自己的数据？数据泄露是否及时披露？

五维度并非平行罗列，而是覆盖了一次"人对系统的完整接触面"：决策如何形成（决策）、由什么算出来（算法）、代价是什么（财务）、规则由谁定与怎样变（治理）、以及系统拿走了我什么（数据）。

八步审计流程

针对任意一个被审计对象，模式建议按以下八个步骤顺序执行：

1. 识别决策或系统：正在审计什么？谁在作决策？谁受影响？
2. 绘制不透明地图：信息在何处被隐藏、模糊或变得不可达？这种不透明是故意的还是偶发的？
3. 检验可解释性：决策逻辑能否用一段话表述清楚，且让一个非专家听懂？如果不能，为什么不能？
4. 检验可及性：信息是否虽然存在却被埋没（如法律文书、技术规格）？它是否以受影响方能使用的语言与格式呈现？
5. 检验权力对齐：不透明是否让权力方受益？如果双方位置互换，权力方是否还会接受同样程度的不透明？
6. 检验正当性：不透明是否有正当理由？正当理由包括：安全（针对具体威胁，而非笼统借口）、真实的复杂性（且配有可理解的摘要）、对其他个体的隐私保护（而非机构决策的隐私）。
7. 检验问责性：如果决策事后被证明是错的，是否存在可见的纠正机制？受影响方能否触发复查？
8. 评估累积性不透明：单看每个决策或许问题不大，但系统性不透明会不断叠加。就整体而言，整个系统对其所治理的人们是否仍可理解？

第 5 步的"权力对齐检验"是整套流程的方法论枢纽——它不预设不透明有罪，而是用"换位"来暴露不透明是否只是单方面保护了权力持有者。第 6 步则划定了可接受不透明的边界，让审计不至于走向反智的极端。第 8 步提醒审计者警惕"聚合效应"：单独每一项小不透明都可以被辩护，但当它们层层累加，整体上系统对受影响方就变得无法导航——这本身就是需要标记的系统性问题。

结构化输出模板：让审计结果可复用、可引用

模式的最大工程化价值在于：它不仅给出审计思路，还规定了严格的结构化输出格式。这意味着不同审计员、不同轮次、针对不同对象的审计报告在结构上彼此可比，这也是它适合被 Agent 或自动化流程调用的关键原因。完整模板如下：

被审计的系统/决策（SYSTEM/DECISION ANALYZED）

写明本次审计的对象是什么。

受影响方地图（STAKEHOLDER MAP）

Party	Role	Information Access	Power Level
[利益相关方]	决策者 / 受影响者 / 观察者	完全 / 部分 / 无	高 / 中 / 低

透明性审计（TRANSPARENCY AUDIT）

决策透明性

• 判据可见？[是/否/部分]
• 过程可见？[是/否/部分]
• 可预测？[是/否/部分]
• 证据：[具体事实]

算法透明性

• 可用平实语言解释？[是/否/部分]
• 存在解释权？[是/否]
• 证据：[具体事实]

财务透明性

• 成本/费用可见？[是/否/部分]
• 隐性成本？[未发现 / 已识别]
• 证据：[具体事实]

治理透明性

• 规则生效前可见？[是/否/部分]
• 质疑机制可见？[是/否]
• 证据：[具体事实]

数据透明性

• 采集已披露？[是/否/部分]
• 用途已披露？[是/否/部分]
• 可访问/更正？[是/否/部分]
• 证据：[具体事实]

不透明分析（OPACITY ANALYSIS）

发现的不透明处	是否正当？	谁受益？	谁受害？
[描述]	[是：理由 / 否]	[相关方]	[相关方]

换位检验（THE REVERSAL TEST）

"决策者如果自己是受影响方，是否仍会接受这种程度的不透明？" [给出带推理的回答]

可解释性核验（EXPLAINABILITY CHECK）

能否用一段非专家能听懂的话解释该系统/决策？ 尝试：[写出这一段话] 成功？ [是 / 部分 / 否——复杂性是真实的 / 否——复杂性服务于掩盖]

透明性裁决（TRANSPARENCY VERDICT）

[TRANSPARENT（透明）/ MOSTLY TRANSPARENT（大体透明）/ PARTIALLY OPAQUE（部分不透明）/ SIGNIFICANTLY OPAQUE（显著不透明）/ DELIBERATELY OBSCURED（故意遮蔽）]

改进建议（RECOMMENDATIONS）

如何在不损害正当利益（安全、隐私、竞争优势）的前提下，让该系统变得更加透明？

这一模板中，"可解释性核验"是整套审计的最终试金石：它强迫审计者真的去写一段"外行能懂的一段话"。写不出来，本身就是审计结论。而裁决等级从"透明"到"故意遮蔽"构成一个清晰的梯度，方便报告读者快速把握系统状态。

三个判例：理解裁决如何作出

模式内置三个对照判例，用于校准审计尺度和裁决口径：

判例一：DELIBERATELY OBSCURED（故意遮蔽） 被审计系统：信用评分算法。问题在于它影响每个人的金融准入，但评分标准是专有的，不存在解释权，受影响方既无法预测也无法质疑自己的评分。裁决：DELIBERATELY OBSCURED——不透明让评分方受益，却伤害被评分方。

判例二：MOSTLY TRANSPARENT（大体透明） 被审计系统：开源软件项目。代码公开、决策在公共论坛作出，但治理结构非正式，关键决策有时发生在私下渠道。裁决：MOSTLY TRANSPARENT——在一个本身开放的系统里存在次要的治理不透明。

判例三：正当的不透明（Justified Opacity） 被审计系统：安全漏洞披露流程。为了在补丁就绪之前防止漏洞被利用，完整细节被暂时扣留。裁决：TRANSPARENT，附带正当的临时不透明——有具体的（而非含糊的）安全理由、有时间限制、并且最终有利于受影响方。

值得注意的是第三个判例与六步审计中"正当性检验"的呼应：正当不透明需要同时满足"理由具体""期限明确"与"结果有利受影响方"三个条件，这正是区分"安全保密"与"官僚性隐藏"的精确分界线。

使用要点与可证伪边界

模式在结尾的 IMPORTANT NOTES 中给出了几条重要的使用纪律，直接约束审计结论的措辞与适用范围：

• 透明性不等于揭示一切。它要求的是揭示受影响方理解和质疑影响他们的决策所需的内容。
• "它太复杂了"不是万能借口。如果一个系统复杂到任何受影响方都无法理解，这本身就是值得标记的问题。
• 透明性是不对称的：机构决策应当透明，个体的私人信息应当受保护，两者并不矛盾。
• 该模式是可证伪的（falsifiable）：如果透明性要求确实让系统无法运作，或损害了真实的安全，那么这些要求本身应当被调整——也就是说，这个审计框架拒绝成为不可动摇的教条，它允许被现实证据推翻或修正。

将审计接入日常工作流的建议

综合模式定位与 Fabric 的机制，可以把透明性审计嵌入几类真实场景：

1. AI 产品发布前的自检：上线任何会产出"影响他人结果"的模型（信贷、招聘、审核、推荐排序）之前，用 echo "<系统说明>" | fabric -p audit_transparency 生成一份基线审计报告，重点看"算法透明性"与"决策透明性"两项是否出现 PARTIAL 以下评级。
2. 政策与合同的入会审查：把 cat 一段条款或合同全文管道给模式，输出中的"受影响方地图"可以快速暴露权力不对等的关系结构。
3. 对既有治理规则的年度复查：定期以同一份规则文本反复执行审计并对比裁决等级，把透明性当作可跟踪的指标而非一次性检查。

若需批量审阅提示原文、确认模式内容或将其纳入自有提示集，可分别使用 --readpattern audit_transparency 打印内容、-l 确认装载，或将文件复制进自定义模式目录后改造。透明性审计不是一个"查错工具"，它更像一剂"系统体检方案"——诊断的价值不在于输出一个差评，而在于让"可解释、可质疑、可纠错"真正成为每一个影响他人系统的默认配置。