---
title: 关于 verifiable.pro
dek: 我们报道什么、如何核实，以及你如何核验我们的工作。
published: 2026-10-20
updated: 2026-10-23
---
## verifiable.pro 发布什么 {#overview}

verifiable.pro 围绕 AI 系统的可核验声明，发布新闻简报、分析、解读与指南。我们的报道从可信执行环境（TEE）出发。TEE 是一种由硬件隔离、用于运行代码的环境。本页说明我们的工作方式。本站的重点与目标见 [verifiable.pro 的定位与目标](/vision/)。

## 报道什么，怎样报道 {#coverage}

一项进展如果改变了外部人员能核实 AI 系统的哪些方面，我们就报道。不改变这一点的发布，我们不跟进。

新闻简报依据一手来源撰写，即机构自己发布的公告、论文、标准或技术文档。如果不得不依赖其他媒体的报道，简报会写明是哪家媒体。分析文章从引用的证据出发展开论证，我们的解读单独放在“为何重要”框中。解读文章说明一个概念，以及它仍需信任什么。指南把一次核查拆成带核查表的编号步骤。

每篇文章都标注“本站刊发”日期，即文章在 verifiable.pro 上线的日期。新闻简报还标注“来源日期”，即一手来源上的日期。因此，如果一篇简报今天刊发，报道的是上个月发布的标准，它会同时显示这两个日期。

虚构的情形放在带斜线底纹的“示例”框中，这样就不会被误当作报道。本站的配图同样不构成证据，报道的证据在文章的来源里。首页的画面是为本站制作的概念示意图，不描绘任何真实的人物、产品、系统或事件。画面旁各层的标签列出真实公司、产品和机构的标志与名称，只是作为各层的举例，不代表背书。文章开头的配图通常是真实的照片。有的照片只是示意，表现的是与报道对象同类的事物，例如一座数据中心，这类照片的图注会写明照片没有表现什么。照片的来源和处理方式见[我们如何选用照片和制作插图](#illustrations)。文章配有照片时，链接预览显示这张照片；其他链接预览使用自动生成的卡片，卡片上是标题和一幅图案，本站页面上不显示这些卡片。

## 如何核实声明 {#verification}

每篇新闻简报的末尾都有“我们核实了什么”框。框中写明我们打开了哪些一手来源、在哪一天打开，以及哪些内容未能确认。

厂商的安全声明，我们作为厂商的说法来报道。一家公司称其服务“经远程证明”或“私密”，这个词告诉读者的是这家公司的说法，我们的措辞会保留这一区别。

我们还把一种机制保护什么与它能确立什么区分开来。TEE 的设计目标是隔离其中运行的软件。远程证明报告是关于加载了哪些软件的证据。两者都不能说明软件的行为是正确的。当报道依赖这类边界时，分析会把它写明，通常放在“这不能说明什么”框中。

## 如何自行核验本站页面 {#integrity}

一个讨论验证的网站，应当让读者能够核验它自己的文字。每篇文章都是一个纯文本的 Markdown 文件。本站构建时，会为每个源文件计算 SHA-256 摘要。摘要可以看作文件确切内容的简短指纹。每篇文章都在文末的验证记录中显示自己的摘要。[站点清单](/manifest.json)是全部源文件的列表，其中也记录了这一摘要以及源文件的地址。清单自身的摘要就是清单中的 `digest` 字段，页脚提供了清单的链接。

要确认某篇文章公开的源文件与记录的摘要一致，可以下载源文件并计算它的摘要：

```bash
curl -s https://verifiable.pro/articles/<slug>/zh.md | shasum -a 256
```

结果应当与这篇文章验证记录中的摘要相同，也与清单中的对应条目相同。若要一次核对所有条目，可以在本站源代码仓库的副本中运行 `python3 tools/verify_manifest.py https://verifiable.pro`。

摘要一致，说明你拿到的文字就是本站在构建时记录的文字。它不能说明报道内容正确。如果某个旧版本在构建之前就被替换了，摘要也无法揭示它。正因如此，更正也会记录在文章本身之中。

## 我们如何使用 AI 工具 {#ai}

本站文章由基于 Anthropic Claude 模型的程序起草。程序每天检索一手来源，就发现的进展起草新闻简报，这些简报署名“verifiable.pro 快讯”。解读、分析与指南由程序围绕选题查阅资料后起草，署名“verifiable.pro 研究”。AI 工具还用于中英文互译，并协助挑选文章开头的配图、撰写图片说明。

每篇文章的署名写明由谁起草。程序的这两个署名旁都附有“自动采编”标签，便于读者把它们与真人的署名区分开；真人的署名写作“作者：”加其名字。有人提交选题并留下希望署名的名字时，署名处还会写明“提交者”及其名字。

编辑决定哪些稿件得以发布，并对每篇文章负责。发布前，编辑对照引用来源核查每一项事实陈述。如果文章报道的公司提供了我们所用的 AI 工具，文章会附利益披露。

## 我们如何选用照片和制作插图 {#illustrations}

每篇新闻简报开头都有一幅配图，通常是一张真实的照片。其他文章也可能配有图片。我们只从许可允许转载的来源选用照片：维基共享资源（Wikimedia Commons）、美国政府网站，以及 Unsplash 和 Pexels 两个图库。许可限于公有领域（美国联邦政府的作品即属此类）、CC0、CC BY 和 CC BY-SA，以及 Unsplash 和 Pexels 各自的许可。每张照片下方的署名行写明作者和来源，并链接其许可和来源页面。如果许可要求注明改动，署名行还会说明我们裁剪了照片并调整了色彩。

找不到报道对象本身的照片时，我们选用一张表现同类事物的示意照片，例如一座数据中心或一枚芯片，并在图注中写明照片没有表现什么。图注只采用来源对照片的说明，不添加来源没有给出的人名、地点或日期。我们不用 AI 生成的图像或由不同场景、对象拼合而成的图像充当照片，也从不改动照片的内容。景深合成的图像仍算作照片：它把同一拍摄对象在不同对焦距离拍下的多帧画面合而为一，使对象处处清晰。本站源代码仓库中的 `tools/photos.py` 把每张照片裁成同样的 3:2 画幅，并为所有照片统一施加一种柔和的调色：饱和度和对比度略微降低，带一点暖色调，使这些照片看起来属于同一组。它还会去除相机记录的元数据，例如拍摄地点。AI 工具协助我们寻找候选照片、起草替代文字和图注，编辑在发布前逐一核查每张照片及其许可和文字。

每张照片的信息以 `illustration.json` 文件的形式与文章一同公开，包括署名、许可、来源、下载日期、裁剪范围、调色方式，以及所发布文件的 SHA-256 摘要，[站点清单](/manifest.json)也列出了这些摘要。摘要一致，说明文件正是本站构建时记录的文件，但不能说明报道内容正确。

文章开头也可以改用概念示意图，由代码根据公开的场景描述绘制。本站的生成程序 `tools/illustrate.py` 把场景描述转成 SVG 图像，画风与首页的画面一致；场景描述以 `illustration.json` 文件的形式与文章一同公开。我们借助 Anthropic 的 Claude 模型起草场景描述、替代文字和图注，编辑在发布前逐一核查每幅图及其文字。

任何人都可以重新绘制这些示意图，并与公开的版本比对。每段场景描述都记录了对应图像的 SHA-256 摘要，站点清单也列出了场景描述和图像各自的摘要。在本站源代码仓库的副本中（检出 `/build.json` 所列的提交），下载一段公开的场景描述，重新绘制并计算结果的摘要：

```bash
curl -s https://verifiable.pro/articles/<slug>/illustration.json -o illustration.json
python3 tools/illustrate.py --spec illustration.json --out redrawn.svg
shasum -a 256 redrawn.svg
```

结果应与场景描述中记录的摘要以及清单中该图像的条目一致。运行 `python3 tools/illustrate.py --check` 会重新绘制仓库中的每一幅图，并报告不一致的图像。摘要一致，说明这幅图正是代码根据该描述画出的图像，但不能说明报道内容正确。

这些插图不描绘真实的事件、人物或产品。它们用通用的图形表示报道涉及的 AI 系统组成部分，例如硬件、软件或一项核查，每条图注都写明了画面没有表现什么。报道的证据在文章的来源里，不在配图里。

## 站内助手 {#assistant}

verifiable.pro 的页面顶部有一个“提问”按钮。它会打开一个小助手，回答关于本站报道的问题。助手依据本站已发布的页面和数据中的段落作答。每条回答都会列出所依据的页面，方便你打开原文对照。

助手目前以演示模式运行。你的浏览器在本站公开的索引中检索，并用匹配的段落拼出回答。整个过程不使用语言模型，你输入的内容也不会发送到任何地方：问题留在页面里，对话只保存在当前浏览器标签页中，关闭即清除。演示回答是从本站页面摘出的段落，并标注为演示回答。

回答的质量取决于它引用的段落，而助手可能选错段落。它不会替你核实声明，也不是信息来源。引用时请以文章及其一手来源为准。演示回答不附带任何形式的远程证明。

我们计划让助手在 GPU 机密计算环境中运行语言模型。在这种部署下，模型运行的环境由硬件隔离，其设计目标是把宿主机和云服务运营方挡在外面。硬件还会为所加载的软件与配置签署一份证明报告。段落仍由你的浏览器从本站公开文件中选取。因此，服务端收到的只有你的问题、此前的对话内容、你提问时所在页面的地址以及这些段落。和任何网络服务一样，它也能看到请求从哪个网络地址发出。

浏览器会获取这份证明报告，自行核对力所能及的部分。随后，浏览器会逐项标明：服务端对其运行环境的说法中，哪些已在本机核对，哪些只是服务端的报告。在浏览器真正完成这些核对之前，助手只会把服务端的说法标为“服务端报告”，绝不标为“已验证”。即使证明报告核对无误，它说明的也只是作答环境加载了哪些软件，不能说明回答本身正确。

## 资源库收录什么 {#resources}

资源库列出论文、标准、规范、工具、基准与机构。一个条目被收录，是因为它能帮助读者核实某项关于 AI 系统的声明。收录不代表背书或认证。“链接核查于”记录我们最近一次打开该链接的日期。如果某个收录项目由编辑开发或合著，条目中会写明，并标为维护者项目。

## 本站由谁编辑 {#editor}

verifiable.pro 由 USC SEPT Lab 维护，编辑为 **Mengyuan Li**。本站不接受付费报道，也不为任何事物提供认证。这里的文章是报道，不是对所述系统的担保。

## 更正 {#corrections}

请告诉我们哪一句有误，以及与之相矛盾的一手来源。你可以公开提交，也可以私下反映。公开提交的方式是在本站的[源代码仓库](https://github.com/sept-usc/verifiable-pro)中提交更正议题（任何人都能读到的报告）。私下反映请发邮件至下方地址。每篇文章末尾的“核查或更正本页”框可以直接打开这样的议题，并预先填好页面地址。确认有误后，我们会修正文章，更新其“更新于”日期，并在文末列出这条更正及其日期。修正也会改变文章源文件的摘要。

## 参与 {#contribute}

本站的文字、数据与代码都在公开的 [GitHub 仓库](https://github.com/sept-usc/verifiable-pro)中。要推荐一条新闻、一个来源、一项资源库条目或一个术语，首选的方式是在那里提交议题。我们也欢迎修改 Markdown 源文件的拉取请求（即修改提议）。仓库中的[贡献指南](https://github.com/sept-usc/verifiable-pro/blob/main/CONTRIBUTING.md)说明了步骤与审核规则（英文）。如果你更习惯用邮件，请附上链接，并用一两句话说明它能帮助读者核实什么。中英文均可。

## 相关刊物 {#related}

[Audit Commons](https://auditcommons.org/) 是一个关于 AI 审计的编辑型网站。它的主题与本站相邻：它关注 AI 系统如何接受审计；verifiable.pro 关注的则是证据，外部人员可以借助这些证据核实关于 AI 系统的声明。

## 联系方式 {#contact}

致信编辑：hello@verifiable.pro

## 转载 {#license}

本站尚未为原创文字与插图选定转载许可。维护者选定后会在此说明。在此之前，如需转载，请先联系我们。引用内容、其他机构的标志与链接来源仍遵循其所有者的条款，每张照片仍适用其署名行写明的许可。