AI 该不该
慢下来？

AI 该不该慢下来？先说清楚，慢在哪里

减速倡议把研发节奏推到台前。它能否带来改变，要看多出来的时间用来做什么，以及谁能检查。

假设一家公司决定把新模型晚一个月发布。这个月里，训练是否继续？模型是否已经交给内部团队写代码、做研究？外部评估者能看到哪个版本？如果这些问题没有答案，日历上的延期很难说明风险发生了什么变化。

Dario Amodei 九月发表的文章提出三步方案：引入嵌入式第三方评估者，再推动行业与全球协调。Anthropic 承诺推进第一步，拟让外部评估团队持续接触内部工作，并保留发表重要发现的权利。原文尚未公布实际进驻的团队与日期。^[1]

这让“慢一点”有了可以追问的内容。过去，公众往往只能看到模型发布时附带的报告；如果外部人员能够接触开发过程，他们就有机会核对报告之外的事情：训练出了什么问题，哪些问题解决了，哪些决定仍然带着争议。

模型晚几天亮相容易观察。组织有没有减少未经验证的操作，则要沿着开发记录往里看。本刊更看重后者。

发布、训练和内部使用，有三只钟

假设一家实验室暂缓开放新模型的公共接口，却继续让它参与下一代系统的开发。用户接触不到它，研发活动仍可能继续加速。另一家公司保持普通产品更新，却冻结一项权限广、难以撤销的内部试验。两者都可以被描述成“调整节奏”，含义完全不同。

因此，一份有用的承诺应当标出对象：暂停哪类训练，限制哪种能力，减少哪些内部用途，还是仅推迟外部发布。还应说明条件改变后怎样恢复，而非只给一个新的日期。

IAPS 九月十一日的政策备忘录建议把重要内部部署纳入监督，理由正是部分先进系统在公开发布前已经参与内部工作。^[10] 这是政策建议，尚不能作为现行统一规则使用；但它把一个容易被发布会遮住的环节点了出来。

普通团队也会遇见较小的版本：对外系统还没上线，员工已经把候选模型接进资料库。项目表上写着“测试中”，实际权限却接近正式服务。状态标签无法代替对真实使用范围的检查。

承诺需要留下可核对的东西

假设评估者只看到了最终模型的一份成绩单。他可以评价那份结果，却无法知道团队是否尝试过另一个版本，又为什么放弃它。若只能在实验室指定的场景里检查，结论也只能覆盖那些场景。

一月的前沿 AI 审计论文主张，第三方应在安全安排下接触非公开信息，审查范围包括内部部署和组织实践；作者还提出分层的审计保证框架。^[5] 这是一项研究构想，不是拿到某张证书就能适用的通行标准。

沿着这个思路，外部检查需要知道自己看不到什么。某类日志因客户隐私不能开放，可以说明限制，并选择其他证据；如果一项关键决定完全不可核实，报告就应保留这个缺口。读者才有办法区分“已经检查”和“接受了对方的解释”。

检查发现问题以后，谁能要求整改也很重要。若报告只能交给原来决定赶工的人，独立性仍可能停在观察层。负责修复的人、再次检查的条件和恢复使用的责任，应当一起写清楚。

多出来的时间，要变成具体工作

一次延期可以用来补测遗漏场景、检查环境配置、修复日志缺口，也可能只是给报告增加几页文字。两者占用相同日历时间，产生的结果差很多。

可以要求每项延期对应一个待解决的问题。例如：确认测试环境无法触及外部对象；验证停止指令能否结束已启动的任务；核对模型更新后原先限制是否仍然有效。问题关闭时留下证据，没有关闭就继续限制相关用途。

作决定的人需要说明，现在缺少哪项证据，准备如何补齐，以及在此之前允许系统做什么。相关问题关闭，才有理由恢复对应的用途。

减速也有代价。一个本来可以帮助使用者的功能会推迟交付，团队仍要支付维护和研究成本。讨论这些代价，最好落到具体功能和人群；笼统地说“所有进步都会受阻”，与笼统地说“等待总是值得”，都没有完成比较。

别把预测印成倒计时

Amodei 对未来六至十二个月的严重网络风险作出了警告。^[1] 这是他的预测，不是已经测得的发生时间。报道可以介绍为什么有人主张改变节奏，却不应把预测包装成确定即将到来的事件。

同样，有人支持第三方检查，不代表他接受所有行业协调方案。可验证的审计、能力阈值、研发限制和国际安排，是几项可以分别讨论的选择。

本刊的判断是：先让检查对象和证据渠道具体起来，比只争论“加速派”与“减速派”更有用。接下来值得看的，是外部团队实际获得了什么访问、发现了什么问题，以及哪些决定因此改变。

从倡议到审计，中间还隔着哪些安排？

AI 前线｜把签署公告、研究方案和公司承诺放回各自的位置。

加州：为第三方评估建立框架

加州政府九月九日宣布签署两项法案：SB 813 建立独立验证组织框架，AB 1405 建立 AI 审计员登记及相关独立性、透明度标准。^[3]

这条消息回答的是制度建设走到哪一步。它没有自动回答每一家公司何时接受何种检查，也不能概括成“所有模型现在都要先领许可证”。对使用者来说，更值得关注的后续是具体适用范围、执行安排与公开检查结果。

一种旧方案：先划定哪些模型属于前沿

Demis Hassabis 七月十四日提出建立前沿 AI 标准机构的构想，以不断更新的能力测试识别前沿模型，并设想由独立专家和开源代表参与；非前沿模型可不纳入这一流程。^[4]

这是七月的政策方案，本期把它作为背景比较。它试图避免把所有软件、所有模型放进同一套检查程序。真正实施时，阈值附近的模型如何处理、测试何时更新、开发者如何申诉，都需要进一步设计。

公司承诺：下一步看实际访问

本期封面故事介绍的嵌入式评估，把观察位置推进到了企业内部。判断其落实情况，可以看外部团队是否已经进入、覆盖哪些系统，以及哪些结论允许公开。

这三条路线分别提供制度框架、分类方法和企业内部入口。后续报道需要继续往下核对：规则由谁执行，阈值如何确定，检查发现是否带来了整改。

写着“模拟环境”，机器为什么还能走出去？

技术拆解｜一次旧事故披露说明，测试边界必须落实到实际环境。

Anthropic 七月三十日披露，回查 141,006 次可能取得互联网访问的评估运行后，发现三起涉及真实组织的事件，共涉及六次运行。提示词称环境是模拟且没有互联网，实际配置却允许联网。测试也未启用正式对外服务的全部监测与分类器保障。^[2]

这是一份厂商事故回顾，不能把三除以总运行数当成正式产品的事故概率。本文只讨论它暴露的一项问题：给模型的环境说明，可能与机器真正拥有的能力不一致。

描述环境和限制环境，是两种操作

假设测试说明写着“只能处理这份副本”，但程序持有的账号可以修改整个工作区。模型遵守说明时，一切看起来正常；一旦理解出错或工具行为超出预期，副本之外的数据仍然暴露在实际权限中。

文字要求告诉助手应该做什么。权限和网络安排决定它能够触及什么。两者一致，测试才容易解释；两者不一致时，即便结果没有出错，也只能说明这次没有触发问题。

因此，验证环境时应当检查实际连接和权限，而非让模型复述一遍“我知道这是测试”。后者检查了回答，没有检查边界。

一层隔离之外，还有依赖

假设程序本身没有直接联网权限，却能调用一个外部服务。那个服务可能继续读取地址、下载内容或写入另一个系统。判断边界，需要沿实际调用路径查看，而不是停在第一个运行容器。

这不意味着每次都要重新设计基础设施。成熟的权限、隔离和日志机制应优先复用。关键是给当前任务建立清单：哪些对象允许接触，哪些依赖会继续发起动作，哪些记录能够证明限制确实生效。

如果团队不能确认某条路径，就先不要把它视为已经封闭。可以减少工具、使用纯模拟返回，或暂时取消写入能力，让试验在已知范围内继续。

检查器也要有自己的对照

假设测试脚本报告“没有访问范围外对象”。这个结果可能是真的，也可能因为日志没有记录到相应动作。要分辨两者，需要知道检查器遇到一个确定违规的模拟事件时，会不会报警。

这种对照应放在隔离测试设施中，只使用虚构对象和受控记录。它验证的是检查器能否识别问题，不需要对真实外部系统发起探测。

同理，停止任务后，可以检查队列是否仍有待执行动作、已经写入的对象是否保留、后台工作是否继续。停止生成一段文字和停止整条工作流，可能发生在不同位置。

修复以后，再运行同一个问题

发现环境说明与实际配置不一致时，修复记录可以分成三项：哪里描述错了，哪里限制错了，哪项检查没能发现。分别处理，才能避免只把提示词改得更严厉，却留下原来的技术通路。

修复完成后，重跑原先暴露问题的案例，再补一个相邻情形。例如，原案例是访问了错误对象，相邻情形可以是对象在运行中变更了权限。只验证原来的单一路径，很容易漏掉同类故障的另一种入口。

最终应保留一条能被复查的链：环境配置、测试输入、实际动作、检查结果及修复后的变化。它比一句“已经加强安全”更容易交给下一位维护者。

给外部审阅者准备一包能检查的证据

实战手记｜用一次虚构的文档整理任务，试着把评估从口头介绍变成可复查记录。

假设团队准备让助手整理一份虚构项目的周报。任务只读取测试资料，生成草稿，不发送消息、不更新正式项目。下面是一份审阅准备方案，尚未在具体产品上实测。

第一页，写允许的动作

说明资料来自哪个测试目录，哪些文件允许读取，草稿放在哪里。再写三个明确限制：不能联系人员，不能写入正式系统，资料不够时保留缺口。

范围要能对应到工具权限。若账号实际上还能读取其他目录，就把这个差异列为待处理问题，不能靠“平时不会用到”从记录中删掉。

同时保存模型版本、应用版本、主要设置和执行时间。若以后只能记得使用了某个品牌，许多差异就无法解释。

第二页，说明什么算完成

准备几份虚构材料：一份原计划、一份后发修改、一条未确认建议，以及一份名称相似但属于其他项目的文件。用独立编号区分对象。

预期结果写在另一份文件里：采用修改后的安排，保留建议的未确认状态，不把相似项目的内容混入。评估过程中不要把对照答案直接提供给待测系统。

这组材料用于看清几种错误，不足以估计全面的可靠性。如果同事对预期结果有分歧，先修正业务规则，再测试模型。否则数字只是在替团队尚未解决的意见分歧计数。

第三页，保留实际发生的动作

给审阅者查看输入副本、工具调用、返回值、生成草稿和最终对象状态。敏感字段先替换成虚构内容，但应保留关联关系，否则审阅者无法判断同一对象是否被重复处理。

把“模型说已经完成”和“系统里确实生成了草稿”分别记录。服务中断时，先核查对象是否存在，再决定是否重试。一次口头报错可能发生在写入之后，盲目重跑会产生第二份对象。

审阅者应当能够沿着任意一个结论找到输入依据。如果某段结论只能追溯到模型自己写的解释，就把证据缺口标出来。

第四页，让审阅者挑一个例外

不要只让对方观看准备好的顺畅演示。可以让审阅者在同一安全范围内选择一项变更：撤回其中一份材料，改一个项目编号，或者把某项安排改成待确认。

测试环境必须继续限制在虚构资料中。异常输入的目的，是检查系统怎样处理变化，不是授权它寻找其他真实数据来补答案。

运行后比较三件事：事实有没有更新，动作有没有超出范围，回复是否准确描述了结果。这几项可以独立出错，分开记录更容易找到修复位置。

最后一页，写下一次检查什么

将发现的问题按后果排列。格式不顺眼可以稍后修；混用对象、错误写入和结果不明时重复执行，通常更需要先处理。每项问题指定一个修复动作，再保存复测结果。

NIST 的 AI RMF Playbook 提供治理、情境识别、测量和管理方面的参考行动，可用来检查团队还遗漏了哪些环节。^[9] 小团队不必为了这次试验复制整套大组织流程，但应有人负责最后的使用决定。

这包证据的价值，在于别人能够指出你没看到的问题。若材料只能支持一次演示，就把使用范围保留在试用阶段；有了可重复检查的结果，再逐步扩大。

望远镜看见的亮点，也可能是仪器留下的痕迹

科技纵深｜NASA 的数据检查项目，让人重新注意测量链条里不那么醒目的工作。

NASA 九月十一日介绍 Artifact InSPECtor，邀请志愿者检查望远镜数据中的伪影，帮助改进 AI 工具。项目目前涉及 Euclid 数据，Roman 的数据计划从 2027 年初加入。^[7]

伪影可能来自杂散光、宇宙射线或探测器与电子系统。屏幕上看见一个明显图样，不代表它对应天空中的同样结构。项目介绍的是识别和检查这些痕迹的方法，没有给出可以直接换算成科学发现提升率的结果。^[7]

先问，信号经过了什么

从天体发出的光到研究者看到的图像，中间经过仪器和处理流程。想知道一个特征意味着什么，既要观察它，也要了解数据怎样产生。

可以用一个日常假设理解：同一台相机拍十张照片，角落总出现同样的亮斑。如果只研究其中一张，亮斑可能被误当成场景的一部分；把多张图和拍摄条件放到一起，就能提出其他解释。

这只是帮助理解的例子，并不代替天文数据的具体处理方法。实际项目中，什么算伪影、如何标注、分歧怎样复核，都需要以研究团队的说明为准。

人的判断也要经过整理

让更多人参与检查，并不意味着每次点击都自动成为正确答案。用于训练或修正系统的反馈，仍然需要明确类别、保存不确定性，并处理不同观察者之间的分歧。

假设一块区域既像真实结构，也像仪器痕迹。要求每个人必须立刻二选一，可能把不确定性藏进标签。允许标记难以判断，并把这些样本留给进一步检查，反而更容易发现类别定义或输入资料的不足。

这也是数据产品中常被低估的部分：不仅要知道最后留下了哪些数据，还要知道哪些数据被排除、为什么排除，以及排除规则改变后能否回看。

一次对准，只回答一个阶段的问题

回看 Webb 望远镜的工程历史：NASA 在 2022 年三月十六日宣布，团队于三月十一日完成精细相位调整阶段，让主镜形成统一星像。当时对准已覆盖 NIRCam，其他科学仪器仍有后续对准工作。^[8]

一个明确里程碑很有价值，恰恰因为它没有试图包办全部验收。读者可以知道哪部分已经验证，哪部分还在继续；后来的进展也有具体的比较起点。

这与“照片已经很好看，为什么还要调试”的直觉不同。工程图像承担的任务可能是检验某项参数，而非展示最终科学产出。展示效果和检查目的需要分别理解。

清理数据，不应抹掉来路

假设一个分析系统把疑似异常值全部删除，最终图表会更整齐。可如果真实变化恰好表现为异常值，清理就可能连同发现一起删掉。

因此，可以保留原始数据、处理版本和排除标记，允许研究者在条件改变时重新分析。对 AI 输出也有类似要求：修正后的结果便于使用，原始记录则帮助解释修正为什么发生。

相比一个更醒目的排行榜，这类工作显得慢。它改善的是后续判断所依赖的材料。一个模型能否帮助科学，既取决于它提出什么，也取决于研究者能否检查它依赖的信号。

谁写下“足够安全”，谁承担等待的成本？

另一面｜统一检查可以降低混乱，也可能遗漏标准制定者不熟悉的处境。

假设一套审计需要大量计算资源、持续驻场人员和复杂文档。大企业可能承担得起，大学实验室与小团队却很难准备。标准若没有区分能力、用途和影响范围，合规成本就可能先决定谁有资格参与。

这不能反过来证明审计没有必要。它要求规则同时说明：哪些检查与风险直接相关，哪些材料可以复用，是否存在适合较低风险系统的程序。

总部之外，系统面对的是另一个环境

一篇讨论非洲情境 AI 安全评估的论文指出，在西方环境设计的评估可能漏掉当地风险路径；基础设施、资源、连接性与应对能力都会影响后果。^[6] 这是框架分析，不是所有模型在某个地区更危险的实测结论。

假设同样的错误建议出现在两个服务系统里：一处有人工复核、替代渠道和及时修正，另一处缺少这些条件。模型输出相同，最终影响可能不同。

如果评估只看输出是否符合一套语言模板，而不看用户怎样行动、错误怎样纠正，就可能把这些差异漏掉。当地使用者、维护者和研究者进入评估设计，可以帮助找到总部团队没有遇过的失效方式。

全球安全与国家竞争，要分开陈述

Amodei 的文章在提出国际协调时，也明确主张保护美国及其盟友的领先地位。^[1] 这属于作者的地缘政策立场，不能直接充当某国技术必然更安全、另一国必然更危险的证据。

讨论共同风险，需要能够比较的测试和事故信息；讨论产业竞争，则涉及利益和权力安排。两者会相互影响，但把它们混成一句“为了全人类”，会让不同参与者更难看清需要承诺什么。

一个较窄的共同问题可能更容易讨论：发生越界事件后交换哪些事实，怎样定义严重程度，如何确认修复。它不必预先解决所有竞争分歧，却可以让下一次事故的处置少一些猜测。

被延迟的收益，也要具体

支持放慢危险用途，可以同时支持加快有明确收益、影响范围受控的应用。研究工具、辅助阅读与高权限自动行动，并不承担同一种后果。

假设一个模型能帮助整理公开资料，却还不能稳定处理写入任务。团队可以继续提供整理功能，同时限制写入。这样保留已知收益，也没有把尚未验证的能力一起推出去。

反过来，如果限制宽到连低风险应用也长期无法使用，就应该检查它是否仍服务于原来的风险目标。等待不是免费的，错误发布也不是免费的；两边都需要把成本落到具体的人和工作上。

审计机构公布费用来源和问题选择方式，允许受影响的人提出异议，才有机会发现样本之外的缺口。独立性需要这些安排持续支撑。

下一次续报，等什么证据？

快讯与追踪｜本期把研发节奏与审阅能力连起来，以下变化才足以更新判断。

嵌入式评估：从邀请到实际工作

下一条值得报道的进展，是具体团队的实际进入、访问范围和首次公开发现。仅有更多人物表达支持，尚不能说明评估已经运行。

独立审计：从框架到执行

加州已经签署框架法案，具体实施安排和首批可核查的审计结果仍有待后续跟进。

天文数据：从参加项目到验证改进

Artifact InSPECtor 的后续可关注标注如何汇总、哪些错误得到修正，以及是否有公开评估。Roman 数据计划加入的时间仍应保留“计划”状态。^[7]

上期延伸：练习题之外，还有试验环境

第004期的封面故事讨论可执行训练题的来路。本期技术拆解补上环境这一层：即使题目清楚、工具调用有答案，运行设施仍需与允许的范围一致。

准备自己检查一项工具，可从证据包开始；想比较不同主张，可对照封面故事和另一面。先看每项主张准备改变哪个具体环节，再看它预计带来什么效果。