之前在技术社区刷到弗朗索瓦·肖莱François Chollet关于 AI 生物安全风险的一段公开讨论发现不少开发者对“AI 会不会被用来制造生物威胁”这个话题存在两极分化的理解一边认为大模型已经具备制造大规模威胁的能力另一边则认为纯属过度恐慌。作为长期做 AI 应用落地的工程师我梳理了一下肖莱公开表达过的观点、背后的技术论据以及对我们日常开发工作的实际影响。这篇文章不是新闻稿也不是观点辩论而是一份偏工程视角的解读方便做 AI 研发、安全合规和平台风控的同学建立一套可用的判断框架。1. 先认识弗朗索瓦·肖莱1.1 Keras 框架与他的技术背景弗朗索瓦·肖莱是 Keras 深度学习框架的作者目前主要研究方向是深度学习、机器智能和 AI 安全评估。对国内开发者来说Keras 并不陌生它早期以高层 API 的形式大幅降低了神经网络的搭建成本很多人的第一个图像分类模型就是用 Keras 写出来的。Chollet 的背景和纯学术研究者不太一样他有大量工程经验同时又长期聚焦“智能的定义”和“智能的测量”这类偏理论的问题。这种工程与理论并重的背景让他在讨论 AI 风险时不太容易陷入单纯的“科幻式恐慌”或“技术乐观主义”而是会回到“模型到底能做什么、不能做什么”这个原点上。1.2 ARC-AGI 与他对 AI 智能的定义肖莱开源过 ARC-AGI 基准测试集。这个基准的核心思想是智能体应当具备在少量示例下快速适应新任务的能力而不是在海量数据中记住已有模式。ARC-AGI 里的题目对人类来说往往很容易图形变换规律一眼就能看出来但当时的大模型得分很低。这个现象被很多人引用肖莱也借此反复强调一个判断当前大语言模型表现出的“知识丰富度”和“真正的智能”是两回事。模型可以写出像模像样的回答但面对从未见过的新问题它并不具备稳定的推理和泛化能力。这个判断非常重要因为它直接决定了后续他对 AI 生物安全风险的态度。如果你认为大模型只是“高级文本联想机”那么它被直接用来制造生物威胁的门槛就会高很多如果你认为大模型已经是“近乎通用的问题解决者”那么风险评估就会完全不同。1.3 为什么 AI 从业者关注他的安全观点现在做 AI 应用开发的团队普遍要面对三类问题模型能力边界在哪里、产品上线后会不会被恶意利用、合规审查怎么通过。肖莱的观点不是单纯的理论探讨他给了一套可以用于实操的判断逻辑评估任何 AI 安全风险先看模型实际能力而不是想象中能力风险要按“链条”评估而不是只看某个环节讨论安全问题时数据和实验证据优于叙事。这套逻辑对做模型选型、风控策略、安全评估的工程师来说有直接参考价值。下面我们先把“AI 生物安全风险”这个概念拆开。2. AI 生物安全风险到底是什么2.1 概念边界“AI 生物安全风险”并不是一个严格的学术术语它在公开讨论中通常指人工智能系统被人恶意使用或自主决策时对生物安全尤其是公共卫生安全造成威胁的可能性。具体来说常见的讨论场景包括场景风险描述信息获取通过大模型快速获取危险生物制剂的制备方法方案设计用模型设计具有更强传播力或致病力的生物序列实验辅助模型为不具备专业背景的人提供具体实验步骤规模化扩散利用 AI 优化传播路径、制造混乱或逃避检测自主实验室未来 AI 驱动自动化实验设备降低恶意操作门槛注意这里说的“风险”既包括恶意攻击者主动利用 AI也包括善意的生物研究中因为模型输出不准确而导致的意外事故。后者虽然在动机上不同但在安全影响上同样值得关注。2.2 风险传导链条要评估 AI 在生物安全中的作用不能笼统说“AI 可能被滥用”而要把一条完整的风险链路拆出来。通常可以拆成五个阶段知识获取攻击者需要知道从哪些公开资料中获取关键信息方案设计把零散信息整合成可行的实验方案原料与设备获得对应的生物材料、化学试剂和实验设备实验验证在真实环境中反复试错完成可复现的操作规模扩散让最终产物产生大范围影响。在这条链条中AI 的角色并不是均匀的。大模型对第 1、2 阶段可能有帮助但对第 3、4 阶段的帮助有限因为涉及物理世界操作模型无法直接执行对第 5 阶段的影响更多取决于传播机制而非模型能力。2.3 为什么现在讨论变多了近两年讨论升温有三个技术背景第一大语言模型的信息整合能力确实变强了。过去需要大量检索才能拼凑出的专业信息现在通过多轮对话就能获得一份结构完整的文档。第二AI 在生命科学领域的应用快速增加。蛋白质结构预测、基因序列分析、药物分子设计这些工作已经在用深度学习模型加速其中一些模型本身就有双用途属性。第三自动化实验设备开始出现。虽然“AI 全自动生物实验室”还没有真正成熟但“模型生成方案 自动化设备执行”的组合让研究者重新审视风险链条。理解了这些背景再来看肖莱的具体观点会清晰很多。3. 肖莱的核心观点拆解3.1 能力评估是第一位的肖莱在公开讨论中反复强调一个原则“在谈论风险之前先评估能力。”他认为很多关于 AI 生物安全风险的讨论都基于一种预设语言模型已经能够像一位资深生物学家一样完成复杂的推理和实验设计。但他认为当前的大模型并不具备这种能力。他常用的类比是语言模型只是在文本分布上做概率预测。它能生成“看起来专业的 DNA 序列描述”或“看起来合规的实验流程”但生成这些文本并不等于理解背后的生物机制更不等于能在实验室中复现。从工程角度看这个判断可以转化成一句话我们不能仅仅因为模型输出在语言上“正确”就认为它在现实世界中有效。3.2 “最后一公里”问题肖莱观点里最核心的一个论点是“最后一公里”问题。具体来说即使大模型能够输出一份看起来完整的威胁方案从方案到现实威胁之间还隔着大量物理实验实验需要真实的生物材料、试剂和设备实验过程存在大量不可预测的变量需要不断调整参数结果需要经过多轮验证而不是文本生成一次就能成功专业操作依赖“默会知识”即教科书上不会写的经验细节。因此他认为当前 AI 系统无法替代这“最后一公里”的物理实现过程。攻击者真正需要的不是一份文本方案而是实验室能力和反复试错的成本。3.3 知识可及性不等于新增风险肖莱还提出过一个值得思考的论据如果风险来自“知识可及性”那么很多关键知识其实早已公开。生物教科书、学术论文、专利文档、公开数据库里一直都可以查到双用途研究的相关内容。在这个前提下需要追问的是大模型到底“新增”了什么风险如果说大模型只是把已经公开的信息做了整合那它相比搜索引擎的优势是“效率提升”而不是“知识解锁”。风险从“需要专业检索能力”变成“需要会写提示词”门槛确实降低了但并没有从“不可能”变成“可能”。3.4 对极端风险叙事的态度肖莱对“AI 即将制造下一次大流行”这类极端叙事持谨慎态度。他多次提醒这类说法如果缺少可验证的技术证据容易把公众注意力和监管资源引向错误方向。不过他也明确表示这并不意味着 AI 安全不值得关注。他的观点更接近应该把精力放在可以验证、可以测量的具体风险上而不是围绕不可能发生的极端场景建立恐慌。这种“基于证据的安全评估”思路恰恰是工程团队应该学习的。4. 技术论证能力边界在哪里4.1 文本生成与湿实验的鸿沟要理解为什么大模型在生物安全链条中作用有限需要先认识到“文本生成”和“湿实验”之间存在本质鸿沟。大模型的所有输出都来自训练数据中的文本模式。它没有在真实物理环境中操作过移液枪、培养箱或显微镜也没有亲眼见过细胞在特定条件下的真实反应。它生成的是“对文本的预测”而不是“对实验结果的预测”。举个通俗例子一个模型读过大量菜谱后可以生成一份看起来完整的“红烧肉”步骤。但如果你让它真的做出这道菜它不知道火候差异、食材含水量、锅具导热性这些实际操作因素。生物实验的复杂度和不确定性远高于做菜因为每一批细胞状态、每一种试剂的批次、每一个实验室的环境都可能影响结果。4.2 模型输出与已验证知识的区别在专业领域模型输出的最大问题不是“完全错误”而是“看起来正确但实际不可靠”。这种不可靠性有两种表现第一种是幻觉。模型可能生成一段在语法、术语上都很专业的序列描述但其中包含着实质性的错误。对于不具备专业能力的用户来说很难发现这些错误。第二种是表面合理性。模型可能综合了多篇论文的信息但生成的内容缺乏可重复性验证。在生物实验中“可重复性”是底线要求文本层面的合理性远不足以支撑真实操作。从安全角度来说这种不可靠性实际上构成了一种“天然障碍”攻击者如果完全依赖模型输出很可能得到一份无法落地的方案。当然这不能成为放松安全防护的理由但能帮助我们更理性地评估风险等级。4.3 模型幻觉带来的双面影响值得注意的是模型幻觉对安全的影响是双向的。一方面幻觉降低了模型作为“专业工具”的可靠性从而降低了它被用于恶意目的的直接价值。一个无法稳定输出正确序列方案的系统很难成为攻击者依赖的核心工具。另一方面幻觉也带来了新的风险如果 AI 被用在生物研究辅助场景中研究人员可能因为信任模型输出而忽略实验验证导致实验事故。这两种影响提醒我们在做 AI 安全评估时不能只看“模型会不会被恶意利用”还要看“模型在正常使用中会不会因为错误输出造成危害”。4.4 能力是动态的评估要持续进行肖莱也明确承认当前的能力评估只是阶段性的。随着模型在工具调用、长程推理、多模态理解等方面的能力提升AI 在风险链条中的角色可能发生变化。比如如果未来模型能够稳定调用外部工具完成信息检索、数据分析、文档生成并且具备更强的推理一致性那么它在“方案设计”阶段的能力会显著增强。再比如如果自动化实验设备与 AI 系统的接口成熟模型的角色可能从“提供方案”延伸到“控制实验流程”。这个变化会显著改变风险链条的评估结果。因此一个负责任的技术团队应该把安全风险评估做成持续过程而不是一次性的上线检查。5. 面向 AI 开发者的安全实践无论我们对风险程度持什么判断工程上都有一个基本原则默认采用安全设计。下面分享一套我们在实际项目中用过的 AI 应用安全评估方法。5.1 上线前的安全自评框架在做 AI 应用上线评估时建议团队按以下维度自查模型能力模型是否具备生成与生物、化学、安全相关高危险内容的能力业务场景当前业务场景是否涉及生物信息、医药研发、安全分析等敏感领域用户范围产品面向大众还是受限的专业用户输出可控性模型输出是否经过过滤、审核和人工复核审计能力系统是否记录了完整的输入输出日志能否追溯到具体用户这些维度可以组合成一个简单的风险等级判断业务场景越敏感、用户范围越开放、输出可控性越弱风险等级越高。5.2 一个简单的风险评估脚本示例为了便于团队落地我们通常会把上面的评估维度做成一个可配置的脚本。下面是一个简化示例重点是提供一种工程化思路而不是完整的商业安全工具。# 文件路径risk_assessment.py # 功能根据业务维度计算 AI 应用的基础风险评分 # 说明这是一个用于内部评审的简化示例实际使用请按业务扩展 def assess_risk( domain: str, user_scope: str, output_control: bool, has_audit: bool, model_capability: str ) - dict: 简单风险评分分数越高风险越大 domain: 业务领域 user_scope: open 表示公开用户closed 表示受限用户 output_control: 是否对模型输出做二次过滤 has_audit: 是否有审计日志 model_capability: 模型能力等级如 low / medium / high score 0 reasons [] # 1. 业务领域权重 domain_weights { general: 1, education: 2, code: 2, bioinfo: 5, security: 5, } domain_score domain_weights.get(domain, 1) score domain_score reasons.append(f业务领域 {domain}权重 {domain_score}) # 2. 用户范围 if user_scope open: score 2 reasons.append(面向公开用户风险增加) else: score 0 reasons.append(面向受限用户风险可控) # 3. 输出控制 if not output_control: score 2 reasons.append(缺少输出过滤风险增加) else: reasons.append(已配置输出过滤) # 4. 审计能力 if not has_audit: score 1 reasons.append(缺少审计日志追溯困难) # 5. 模型能力 capability_weights {low: 1, medium: 2, high: 3} capability_score capability_weights.get(model_capability, 1) score capability_score reasons.append(f模型能力 {model_capability}权重 {capability_score}) # 风险等级 if score 5: level 低 elif score 8: level 中 else: level 高 return { score: score, level: level, details: reasons, } if __name__ __main__: result assess_risk( domaingeneral, user_scopeopen, output_controlTrue, has_auditTrue, model_capabilitymedium, ) print(风险评分:, result[score]) print(风险等级:, result[level]) for item in result[details]: print( -, item)运行这个脚本需要 Python 3.6 以上环境直接执行即可看到输出结果。实际的评估维度会复杂得多但这个示例可以帮助团队建立“将安全评估量化”的意识。5.3 Red Teaming 与安全测试方法论除了静态评估动态安全测试同样重要。在 AI 应用领域这种测试通常被称为 Red Teaming即由专门的安全测试团队模拟攻击者视角尝试绕过模型的输出限制。Red Teaming 的工程化流程通常包括明确测试边界定义哪些主题属于高风险内容设计测试用例覆盖直接提问、间接诱导、角色扮演、多轮语境叠加等场景记录模型输出判断模型是否遵守安全策略迭代修复针对绕过成功的案例增加输入过滤或输出约束回归验证修复后重新运行完整用例集确认没有引入新问题。需要强调的是Red Teaming 测试用例的设计必须在合规框架内进行测试团队不应真的生成危险内容而是通过模型“是否拒绝回答”“是否引导至安全方向”来判断安全策略的有效性。最终目的是验证防护机制而不是学习危险方法。5.4 部署阶段的防护措施在模型完成评估和测试后部署阶段仍然不能掉以轻心。推荐的防护措施包括输入侧过滤对用户输入进行关键词和意图识别拦截明显的高风险请求输出侧过滤对模型输出进行二次审核匹配高风险主题时直接拦截权限分级对高能力模型或高风险场景设置更高的调用权限审计日志记录每一次调用的用户、时间、输入摘要和输出摘要保证可追溯熔断机制当系统检测到异常集中的风险请求时自动触发限流或暂停服务。这些措施不一定全部要上团队可以根据业务场景选择组合。核心原则是安全设计要嵌入整个产品链路而不是依赖模型自己“拒绝回答”。6. 这场讨论给我们的启示6.1 区分不同维度的 AI 风险关于 AI 安全的讨论最常犯的错误是把不同类型的风险混为一谈。结合肖莱的讨论我建议把 AI 风险至少分成三类第一类是“使用风险”即现有模型已经表现出偏见、幻觉、隐私泄露等问题这类风险已经发生需要靠工程手段持续治理。第二类是“误用风险”即模型被攻击者用于恶意目的。这类风险取决于能力、可及性和物理场景约束需要逐链条评估。第三类是“远期风险”即未来更强大的 AI 系统可能出现的失控或滥用。这类风险存在很大不确定性很难用当前数据验证。不同风险的正确处理方式不同。处理使用风险靠产品和算法优化处理误用风险靠权限和监控处理远期风险靠研究和政策储备。混淆这三类风险会导致资源错配。6.2 技术评估先于叙事肖莱的讨论带给我们最大的工程启示是在 AI 安全问题上坚持“技术评估先于叙事”。在一个新功能上线前团队往往面临来自各方的压力产品方希望尽快发布安全方希望充分评估管理层希望控制成本。在这种情况下基于可测量指标的评估流程比基于感觉的讨论更有效。具体做法可以是把“能力边界”拆成可验证的子问题比如“模型能否通过某个专业测试”“模型能否调用外部工具完成某类任务”“模型输出在专业场景上的准确率是多少”。每一个子问题都有数据支撑讨论就不容易空转。6.3 从“不可知论”中走出来面对 AI 安全这种充满未知的话题一种常见的态度是“无法验证因此不必认真”。另一种则是“存在风险因此必须全面禁止”。这两种态度都不是良好的工程态度。更务实的选择是承认不确定性但为可验证的风险建立防护机制为不可验证的风险保留监控和调整空间。这就像做容灾设计你无法预知所有故障模式但可以通过备份、监控、演练来提升系统的整体韧性。对 AI 开发者来说这意味着即使你认为当前模型不具备制造生物威胁的能力仍然应该做好输出过滤和审计即使你认为未来 AI 可能带来新的风险也不需要在今天为不确定的未来停止所有技术探索。7. 总结与后续学习方向通过这篇文章我们梳理了几个关键点第一弗朗索瓦·肖莱在 AI 生物安全风险上的核心判断建立在能力评估之上。他不会因为模型能生成“看起来专业”的内容就认为模型具备真实的专业操作能力。第二AI 生物安全风险是一个链条问题包含知识获取、方案设计、材料准备、实验验证和规模扩散等多个环节。AI 在不同环节的作用差异很大不能一概而论。第三无论对风险程度怎么判断工程上都应该默认采用安全设计。风险自评、Red Teaming、输出过滤、审计日志、熔断机制这些手段都是团队可以直接落地的。如果你对 AI 安全这个方向感兴趣下一步可以关注三个技术方向一个是 AI 安全评测方法比如各类红队测试基准和评估框架一个是生物信息学与 AI 的交叉应用理解模型在蛋白质结构、基因序列等任务上的真实能力边界还有一个是 AI Agent 安全尤其是未来模型具备工具调用能力后如何在执行链条上设置安全边界。这些方向不需要你成为安全专家但如果你在 AI 应用团队工作掌握这些基础评估方法能在很大程度上避免“只有恐慌、没有对策”的局面。希望这篇文章能帮你建立一套自己的判断框架。