这个夏天，AI 新闻里的“突破”几乎按天刷新：模型超过安全专家、系统展现惊人能力、厂商披露遭遇攻击。Timnit Gebru 和 Emily M. Bender 提醒我们，热闹的发布节奏并不等于可靠的证据链。来源摘要提到，Anthropic 曾宣称 Claude Mythos 寻找软件漏洞的能力超过大多数安全专家；OpenAI–Hugging Face 遭到入侵后，Anthropic 和 Meta 也披露了类似遭遇。真正需要核查的，不只是模型跑出了什么分数，还包括比较对象、测试条件、基础设施安全和厂商选择性披露的信息。
“超过专家”不是一个完整的技术结论
一句“模型比大多数安全专家更强”，至少藏着五个没有自动得到回答的问题：
- 专家是谁：是初级分析师、漏洞赏金猎人，还是长期从事代码审计的研究员？样本有多大？
- 任务是什么：寻找人为植入的缺陷、已公开漏洞，还是未知的真实漏洞？
- 资源是否相同：人类和模型分别获得多少时间、上下文、工具调用次数与提示优化？
- 如何计算成功：只统计召回率，还是同时计算误报、重复报告和不可利用的问题？
- 结果能否复现：测试集、模型版本、系统提示、采样参数和评分程序是否公开？
以漏洞发现为例，模型生成十份看似可信的报告，其中一份指向真实缺陷，并不一定优于工程师提交一份经过验证、带复现步骤和影响分析的报告。误报会消耗审计时间；缺少可利用性判断的“发现”，也很难直接转化为安全收益。
因此，基准测试只能支持与测试范围相匹配的结论。它不能自动证明模型在陌生代码库、真实权限边界和持续变化的生产环境中仍然有效。
模型能力与系统安全必须分开核查
来源摘要把能力宣称和厂商遭遇攻击放在同一段时间线上，这一点很重要：一个模型可能在评测中表现突出，但围绕它的账号、令牌、模型仓库、插件、依赖包或部署流程仍可能成为薄弱环节。
核查安全事件时，不应仅凭“被黑”两个字推断攻击路径。需要等待或寻找更具体的信息：
- 被影响的是模型本身、托管平台，还是开发者账号？
- 攻击者是否获得了权重、密钥、数据或发布权限？
- 事件由模型能力导致，还是传统的凭据泄漏、供应链或访问控制问题？
- 厂商披露的是完整影响范围，还是已经确认的一小部分？
- 是否提供时间线、修复措施、受影响版本和独立调查结果？
同样，厂商主动披露值得肯定，但披露行为本身不能证明其产品更安全。不同公司披露意愿不同，也会造成“新闻数量等于事故数量”的错觉。公开报道只能作为观察窗口，不能直接当作完整统计样本。
把发布稿改写成可证伪的声明
面对“突破”，一个有效动作是删掉形容词，把宣传语改写为带边界的技术声明。
例如：
在数据集 D、固定工具集合 T 和时间预算 B 下，模型版本 M 找到了 N 个经人工确认的漏洞；与具有明确资历分布的人类对照组相比，其准确率、召回率和单位成本分别为 X、Y、Z。
这句话仍不代表生产价值，但已经可以被检查。至少，读者知道该索要哪些材料：数据集构造、污染检查、对照组招募方法、盲测流程、原始输出、误报定义、统计区间和失败案例。
还要特别检查三类常见跳跃：
| 已有证据 | 不应直接推出 |
|---|---|
| 在封闭基准上得分更高 | 能替代现实岗位中的专家 |
| 生成了疑似漏洞描述 | 已验证漏洞可复现、可利用 |
| 厂商披露了一次攻击 | 已完整解释根因和影响范围 |
怀疑宣传并不意味着反向武断。不能因为某次演示证据不足，就断言模型毫无价值；更合理的结论是降低置信度，并明确还缺什么证据。
可以这样实践：为每个 AI 声明建立核查卡
下面的脚本不是来源中提供的工具，而是一种可直接改造的团队实践。把每项分数改为 0、1 或 2：分别表示“未提供”“部分提供”和“充分提供”。它不会自动判断真假，只用于暴露证据缺口。
cat > audit_claim.py <<'PY'
# 0 = 未提供，1 = 部分提供，2 = 充分提供
claim = '模型寻找软件漏洞的能力超过大多数安全专家'
checks = {
'明确任务与适用范围': {
'score': 1,
'question': '测试针对哪类代码、漏洞和运行环境？',
},
'定义比较对象': {
'score': 0,
'question': '专家样本的资历、人数和招募方式是什么？',
},
'控制资源与工具': {
'score': 0,
'question': '模型与人类是否获得相同时间、工具和上下文？',
},
'报告误报与不确定性': {
'score': 0,
'question': '准确率、误报率、置信区间和失败案例在哪里？',
},
'公开复现材料': {
'score': 0,
'question': '模型版本、提示、数据和评分代码能否获取？',
},
'提供独立复现': {
'score': 0,
'question': '是否有无利益关联的第三方得到相近结果？',
},
}
score = sum(item['score'] for item in checks.values())
maximum = 2 * len(checks)
print(f'声明：{claim}')
print(f'证据完整度：{score}/{maximum}')
print('\n仍需追问：')
for name, item in checks.items():
if item['score'] < 2:
print(f"- [{item['score']}/2] {name}：{item['question']}")
if score < maximum * 0.4:
print('\n建议：暂按未经充分支持的宣传性声明处理。')
elif score < maximum * 0.75:
print('\n建议：可以继续评估，但不要外推到生产环境。')
else:
print('\n建议：证据较完整，下一步进行内部复现和风险测试。')
PY
python audit_claim.py
团队可以把核查卡提交到代码仓库，与模型评测脚本、数据版本和审批记录一起维护。真正有用的不是总分，而是每个零分项对应的追问。对于高风险应用，还应增加隐私、授权、供应链、回滚方案和人工复核等维度。
采用新模型前的最小检查清单
面对下一条“重大突破”，可以先完成以下动作：
- 找到原始技术报告，而不是只读新闻稿或社交媒体摘要。
- 确认模型、数据集、提示和评分器的具体版本。
- 检查训练数据污染、基准泄漏与人为挑选案例的可能性。
- 同时阅读成功样例、失败样例、误报和置信区间。
- 区分模型能力、产品体验与整套系统的安全性。
- 在自己的数据和约束下做小规模盲测，不直接采用厂商结论。
- 为不可复现、缺少对照组或只展示最佳结果的声明降低置信度。
AI 炒作最容易利用的是评价语句中的省略：省略比较条件、省略失败次数、省略系统边界，也省略了谁承担错误成本。技术团队不必拒绝所有新能力，但应该坚持一个简单规则：结论可以大胆，证据必须具体；证据越不完整，部署范围就应越小。