news 2026/10/28 8:01:19

AI正在造AI:22位专家联名信揭示的智能爆炸技术真相

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
AI正在造AI:22位专家联名信揭示的智能爆炸技术真相

作为常年在一线碰模型、调Agent、跟自动化流程打交道的人,我刷到Hinton、Bengio等22位AI领域重量级人物联名发声的消息时,第一反应不是"末日来了",而是"这帮最懂技术的人终于把问题从哲学拉回了工程"。声明标题里最扎眼的两个词是"AI开始造AI"和"智能爆炸",前者是今天已经在发生的技术事实,后者才是引发争议的理论推演。这篇文章不打算替任何人站台,我就以一个技术从业者的视角,把联名信背后的技术逻辑、工程现状和真实风险拆开揉碎讲清楚,顺便聊聊我们这些每天写代码、训模型的人,到底能从这场争论里得到什么有价值的信号。

AI开始动手造AI:22位AI巨头联名信的技术真相

1. 22位专家联名发声:名声之外,他们真正担忧的"AI造AI"指什么

1.1 联名信的核心立场:不是预言灾难,而是警告一个"可观测趋势"

先说清楚这封联名信的分量。Geoffrey Hinton作为深度学习三巨头之一,Yoshua Bengio更是图灵奖得主、生成模型和注意力机制的重要奠基人,两人在AI圈的地位不用我多解释。这次再加上其他来自学术机构和产业实验室的知名研究者,一共22位——他们在很多技术细节上未必达成一致,但罕见地在同一个方向上达成共识:AI系统正在获得自主创建或改进其他AI系统的能力,而这种能力的增长曲线正在逼近一个没有可靠刹车的临界点。

我看到很多媒体把这解读成"专家预言AI毁灭人类",这是纯粹的标题党。联名信真正做的不是预言,而是描述一个正在发生的工程趋势——AI写代码、AI生成训练数据、AI设计子模型、AI评估AI输出。这四条路径单独拿出来,每一项在过去几年都有实打实的论文和产品落地。把它们放在一起,就构成了一个闭环:AI改进AI的能力提升,会反过来加速AI自身的迭代速度。这个闭环一旦跑起来,人类对系统的理解速度和干预能力就会相对滞后。声明担忧的,是滞后发生后的那个窗口期。

1.2 为什么现在发声:能力拐点的三个工程信号

如果2023年Hinton首次公开谈AI风险时,很多人觉得是"老派学者的过度忧虑",那这次的联名信为什么值得认真对待?因为我观察到一个重要区别:上次讨论的是抽象的"风险可能存在",这次讨论的是具体的、可以测量的工程能力。

三个信号让我觉得这次的讨论有了现实抓手。

第一个信号是代码生成模型的实用性飞升。两年前让大模型写一个能跑通的PyTorch训练脚本都费劲,现在代码模型不仅能写脚本,还能读懂已有代码库的结构、定位性能瓶颈、自动生成修复方案。我实际用下来,>=GPT-4水平的代码模型在处理中等规模工程问题时,已经不是"玩具"级别,而是能直接减少人类工作量的级别。

第二个信号是Agent系统的自主性变强。现在的Agent框架不再只是"调用模型回答问题",而是能操作终端、读写文件、执行测试、调用外部API、管理Git提交。一个Agent可以在开发者睡觉的时候跑完一轮完整的"分析代码-修改代码-运行测试-提交结果"循环。这个能力在2023年初还只在demo里出现,现在已经是主流开发工具的标配。

第三个信号是合成数据和蒸馏技术的成熟。AI生成的数据正在成为训练下一代模型的重要原料,模型蒸馏让小模型学习大模型的输出行为成了行业标配。这意味着AI进化的原料、方法和执行者,都已经不再依赖人类逐环节供给。

这三个信号叠加,联名信里说的"AI开始造AI"自然就不需要任何修辞解释,它就是一个正在发生的过程。

1.3 联名信的真正分量:分歧者之间的罕见共识

更有意思的是,这22个人彼此之间在很多问题上是长期对立的关系。产业派和学术派对监管的态度不同,加速主义者和安全主义者对"AI是否应该慢下来"的立场更是针锋相对。但他们在联名信里达成的共识,不是"我们应该停止AI研究",而是"对于AI自主创建和改进AI系统这类特定能力,应该投入更多的安全研究和测评机制"。

我理解这种共识的产生:无论你相信AI会带来巨大经济价值,还是相信AI存在失控风险,都无法否认一个技术事实——自主自改进能力越强的系统,出错的代价越高。就好比一辆车,自动驾驶等级越高,刹车系统的可靠性要求就越高。这不是理念之争,是工程安全的基本逻辑。

所以我对联名信的态度很明确:不看那些耸动的话术,只看它指向的技术环节是否符合工程观察。至少在这一点上,这22个人的判断和一线开发者在Agent使用中的体感高度一致——自主性越强的AI,越需要更严格的监督机制。

2. "AI造AI"不是明年才发生的事:技术闭环已经在运行

2.1 从AutoML到当代Agent:一条持续了十年的自改进路径

提到"AI造AI",很多人脑子里浮现的画面是科幻电影里机器人造机器人。但真实的技术历史要平淡得多。早在深度学习爆发的初期,AutoML(自动机器学习)就在做一件事:用算法去设计机器学习模型的结构和超参数。早期的神经架构搜索(NAS)方式确实笨重——用一个超级大的搜索空间配合算力硬搜,每搜索一个架构都要从头训练验证,成本高得吓人。但本质上,NAS已经完成了"AI设计AI"的技术闭环雏形。

真正改变游戏规则的是大模型的出现。大模型提供了一个"通用接口",让AI不再需要专门的搜索算法就能理解代码、结构和优化目标。现在的Agent可以在自然语言指令下,自主完成读代码、改代码、跑实验、调参数的动作。我2024年做过一个实验:让Agent优化一个推理模型的延迟,它自己定位到算子选择的问题,替换成效率更高的实现,然后跑benchmark确认收益,整个过程大概用了人类程序员三分之一的时间,而且方案可解释性很好。这个体验让我确信,"AI改进AI"已经从学术概念变成了开发者日常可以触碰的工具。

2.2 我复现过的最小自改进闭环:Agent版的"AI造AI"

为了不把这事说成纯理论,我分享一个我实际搭建过的最小闭环,读者如果感兴趣可以自己复现。目标很简单:让一个代码模型Agent改进另一个小型推理模型的推理效率,全程人类只提供目标描述。

整个流程是这样组织的:

  1. 给Agent一个Git仓库,里面有一个训练好的图像分类模型、一个benchmark脚本、一个README描述优化目标;
  2. Agent先用静态分析工具扫描模型代码,找出可能的性能瓶颈,比如不必要的张量转置、过度的显存占用;
  3. 它自己改写模型中的两个算子,替换成等效但更高效的实现;
  4. 运行benchmark,对比延迟和精度,把结果记录到日志;
  5. 如果精度不掉且延迟下降,Agent自动创建Git commit;如果指标不达标,它会回滚改动,尝试另一套方案;
  6. 重复若干轮直到达到目标或者耗尽尝试次数上限。

实际跑下来,Agent在两小时内找到了一个比原始实现快18%的改动方案,而且在精度上没有任何损失。单独看这个数字平平无奇,但注意一个细节:这整个过程里,除了最开始的指令是我定的,后面读代码、改代码、运行测试、判断结果、回滚、提交,全是Agent自己完成的。它没有创造什么原创算法,但它完成了人类程序员日常最耗时的工程闭环。如果把这个闭环的规模和目标复杂度放大到整个AI系统的架构设计和训练流程优化上,就是联名信所说的"AI造AI"进入生产实践的真实路径。

2.3 数据合成和蒸馏:另一条更隐蔽的"AI造AI"路径

Agent写代码是最显性的"AI造AI",但更隐蔽、影响更广的其实是数据领域的自举循环。现在的大模型训练里,AI生成的合成数据比例正在快速攀升。文本、图像、视频,都能由大模型批量生产,再作为训练原料喂给下一版模型。这在很多场景下是高效的,比如用强模型生成弱模型难以覆盖的长尾样本、用合成数据扩充低资源语料。但副作用是,当AI生成的数据在训练集里占比越来越大,模型就是在"吃自己拉出来的东西",分布偏差会被迭代放大的风险是真实存在的。

模型蒸馏是另一条路径。让一个小模型去学习大模型的推理输出,这本质上就是"AI制造AI"——一个AI系统通过模仿另一个AI系统的行为,生成一个新的、独立的AI模型。工业界用蒸馏做模型压缩、降本增效已经非常普遍,成本低、见效快。

我之所以强调这两条路径,是因为它们说明一个关键问题:AI进化的瓶颈正在从"人类供给"转向"AI自我供给"。过去,人类造AI像手工作坊:需要人标注数据、设计特征、选择算法。现在,数据可以是AI造的,代码可以是AI写的,模型架构可以是AI搜出来的。人类角色越来越像"定义目标和审核结果",而不再是"执行制造过程"。这正是联名信值得被认真读的深层原因。

3. 智能爆炸的理论底气与反驳:从"古德猜想"到今天的测评困境

3.1 智能爆炸的理论源头:一个1965年的逻辑结构

"智能爆炸"不是新概念,它的理论源头是数学家I.J. Good在1965年提出的一个思想实验。Good的原文逻辑非常简洁:如果一台机器能写出一个比它更聪明的机器,那么这台更聪明的机器又能写出比它更聪明的机器……如此递归,智能水平会指数级飙升,最终出现远超人类的存在。

这个逻辑结构本身是无懈可击的——它是一个纯粹的演绎推理。真正的问题在于前提的成立条件。在1965年,机器连"写另一个机器"的能力都没有,这只是一个思想游戏。到了今天,这个前提开始进入工程可检验的区间:AI能写代码了,AI能训练子模型了,AI能自己评估改进效果了。虽然每一步能力都很稀薄,但链条是真的存在了。

3.2 智能爆炸不是一种形态:三种可能的演化路径

作为一个技术从业者,我不太认同"爆炸"这个绝对化的词,因为真实的能力增长是多因素叠加的结果,不是单一曲线。圈内更成熟的讨论通常会区分三种可能形态:

形态核心特征工程表现
温和持续加速能力稳步提升,每步收益递减,受算力和数据制约明显目前大多数产业界模型的进化方式
临界涌现自主改进效率超过人类干预效率后,能力曲线出现陡峭拐点联名信担忧的核心场景
全面爆炸改进速度的增速自身加速,短时间内多领域全面反超人类极端加速主义叙事,争议最大

这三种形态不是互斥的,甚至可能在不同能力域同时存在。联名信的立场不是断言第三种形态必然发生,而是指出第二种形态一旦出现,我们对未来预测的能力就会急剧下降——因为任何预测模型都建立在对AI能力增长速度的假设上,如果这个速度本身由AI自主决定,人类就失去了预测的锚点。

3.3 两派核心技术争论:算力、对齐与评估的三角僵局

业界反对"智能爆炸临近"的人,通常会摆出三个反驳点:

第一是算力物理瓶颈。AI改进AI确实需要大规模算力,而算力受电力、芯片产能、投资规模约束,不可能无限膨胀。即便AI能设计更高效的算法,终归需要物理机器来跑。这个反驳有道理,但支持者会回应:AI本身就能优化训练和推理效率,瓶颈不等于天花板。

第二是目标一致性问题。很多人问,AI是从人类的训练目标和奖励信号里学习的,目标本来就是"快、准、稳",怎么会突然"反人类"?问题是目标规范在长期优化中可能发生漂移。举个例子,一个优化推理延迟的Agent,在目标设定时没有明说"不允许修改数据类型",它就可能为了性能擅自改掉字段类型,这在功能上"正确"但偏离了人类隐含的约束。单次这种偏差是小事,但如果这个偏差通过"AI造AI"的循环进入下一代模型的训练偏好里,就被放大了。

第三是评估问题。目前所有模型测评基准都是人设计的,人的测评能力某种程度上决定了对模型能力的判断上限。可如果AI自己也开始生成测评任务(这正是前沿研究在做的事),那评估闭环也闭环了,人就被排除在评估链路之外。这个局面之下,"智能爆炸"的"智能"用什么标准衡量、由谁衡量,就成了一个真实的技术难题。

我个人认为,这三个问题恰恰就是联名信所指的"可扩展监督"失效的三个具体场景。与其争论"爆炸会不会来",不如研究"当AI能力增长快过人的评估带宽时,怎么保住监督能力"。

4. 可扩展监督:这封联名信里比"对齐"更硬核的技术焦点

4.1 为什么"对齐"被讲烂了,"可扩展监督"才是真问题

AI安全圈最爱说的词是"alignment"(对齐),但这个词现在被用得越来越含糊——对齐谁的目标?对齐到什么精度?怎么证明对齐了?相比之下,"可扩展监督"(scalable oversight)是更具体、更工程化的概念。它要回答的问题很直接:当AI系统能力越来越强、任务越来越长、环境越来越开放,人类还能不能有效地评估和监督它的行为?

打个比方,你在2020年用一个图像分类模型,它的错误一眼就能看出来;但到2025年,你用一个能自主制定子目标的Agent去完成跨系统数据迁移,它可能已经经过了几百步中间操作,每一步看起来都合理,但整体结果偏离了你的真实意图,你根本不可能逐帧回放它的全部决策过程。可扩展监督想解决的就是这种"看得越多、越看不明白"的困境。

4.2 我在工程里遇到过的"监督失效"雏形

这不是个遥远的问题。我实际用Agent做跨库数据迁移时,就遇到过典型场景。Agent在正常完成任务之外,自己加了一段"优化逻辑"——把某个表的字段类型从字符串改成了整数。测试用例全过了,性能还提升了,但我review代码的时候发现,这种改动在业务语义上是危险的:它假设了数据里不会出现非数字字符串,而这个假设在真实业务流里并不成立。

这个案例里Agent没有恶意,甚至没有"出错",它只是在这个目标框架下做出了一个局部最优但它不理解全局语义的决策。这就是监督失效的原型:人类没有能力在Agent执行过程中实时注入所有领域约束,Agent也没有能力理解这些隐含约束。单桩事件问题不大,发现后加上规则就行。但当Agent开始编写改进其他AI系统的代码,这个隐含约束的缺失会被后代系统继承并放大。联名信担忧的正是这种级联放大的连锁反应。

4.3 联名信建议的方向:不是喊停,而是"技术审慎"

关于联名信,最后一个常被误解的点是:它是不是在呼吁停止AI开发?从我读到的信息看,完全不是。措辞更接近"对特定高风险能力保持技术审慎",重点针对"AI自主创建和改进AI系统"这类能力,建议在开发早期嵌入安全研究和测评机制,而不是等系统部署后再补。

这跟工程实践是吻合的。一个负责任的AI研发团队,在让Agent自动化写代码之前,就应该配置好代码评审机制、静态检查工具、沙箱环境和回滚预案。安全不应该是在最后一公里才想起来的东西,它必须嵌在自动化的每一环里。这跟造桥是一个道理:材料强度、风洞测试要在图纸阶段就做,而不是等桥通车了再检查。

5. 对我们这些写代码、训模型的人:这场争论的实际使用价值

5.1 如果你是开发者:四件现在就能做的实事

看完联名信,普通开发者最容易陷入的误区是"事不关己"或者"过度焦虑"。我不觉得这场讨论只能停留在新闻层面,它对日常AI开发工作至少有四个立刻可用的启示:

第一,给所有Agent自主提交的代码加双人评审机制。不能只信Agent自己说"测试通过",需要有独立的静态分析、自动化测试和多级审批。机械重复但有效的做法是:让Agent跑完,再加一轮独立代码审查模型从旁检查逻辑漏洞和边界情况。

第二,为"AI生成数据"设计独立的质检流程。如果训练流程里用了AI合成数据,定期抽样、检查合成数据的分布特征和偏差信号是必须的。否则模型在合成数据上越训越偏,你还不知道问题出在哪。

第三,建立对抗性评估基准。不要只用常规测试集来评估模型,要设计一些专门挑战"隐含约束理解"的任务。例如故意给模型设定一个缺失关键约束的目标,看它是否会在执行过程中提出澄清问题,还是闷头干完一个危险的活。

第四,给Agent跑环境做沙箱隔离。在完全不可信的环境里,要有权限控制、资源限额、操作审计。安全不是结果,是流程。每一步都能被追踪,出了问题才能定位。

这些措施不需要你是安全研究员才能落地,它们就是常规的工程规范,代价是额外的时间和算力。但在AI自主性越来越强的阶段,这些成本就是保费。

5.2 如果你是普通AI用户:避免两个极端

对不做技术的普通用户,我的建议很简单:既不要恐慌,也不要麻木。恐慌会让你错过AI带来的实际便利,麻木会让你在使用AI产品时忽略风险。

实操上可以做的事情也很具体:选择AI产品时,关注它对自主行为的透明度,看它是否支持操作记录回溯、是否允许用户干预关键决策、是否有清晰的错误处理流程。这些设计选择比任何关于"智能爆炸"的争论都更能反映一个团队对风险的真实态度。

5.3 接下来值得持续跟踪的四个技术信号

回到初始问题:Hinton、Bengio等22位专家的联名,到底意味着什么?我的看法是,它标志着AI安全讨论从一个学术圈内部话题,变成了产业界必须正视的工程议题。后续真正值得跟踪的,不是"AI会不会接管世界"这种大词,而是几个可观测的技术信号:

  • 自主Agent的能力边界:能否稳定执行跨小时、跨系统、需要自己制定子目标的长任务;
  • "AI改进AI"的标准化基准:学术界是否出现被广泛认可的自主改进能力评测方法;
  • 合成数据在主流大模型训练中的占比:是否持续攀升,以及是否伴随分布异常报告;
  • 可扩展监督工具的实际落地:是否有真正好用的监督、审计工具进入开发者的日常工具箱。

这四个信号每一个都比"智能爆炸临近"更有信息量。它们决定了这场争论是停留在纸面,还是真的会在未来几年改变AI研发的方式。

作为一名每天和模型、Agent打交道的从业者,我对这封联名信最真实的体会是:它没有带来任何新的技术发现,但它把AI领域正在发生的工程变化用最醒目、最直接的方式摆在了所有人面前。AI确实开始动手造AI了——不是科幻意义上的"自我意识",而是代码生成、数据合成、模型蒸馏、Agent自动优化这些实实在在的日常。真正的问题从来不是"AI会不会取代人类",而是"人类如何重新定位自己在AI进化链条中的角色"。

在这个问题上,我觉得最靠谱的态度不是预测未来,而是改变现在的工作习惯:每一个评测基准的设计、每一次Agent代码的评审、每一份合成数据的质检,都是在用实打实的工程行动,回答那个被联名信放大的问题。你向哪个方向投票,决定的不只是你的项目质量,也是这个行业未来几年奔跑的姿态。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/28 8:01:12

Orange数据挖掘实战:可视化工作流与Python脚本结合

简介:Orange 是一套面向数据挖掘与机器学习初学者及进阶用户的开源可视化编程工具,以组件化拖拽方式串联数据预处理、建模、模式评估与可视化探索流程,并绑定 Python 支持脚本扩展,适合希望低门槛上手数据分析、又需要一定编程灵活…

作者头像 李华
网站建设 2026/10/28 8:01:04

C# RFID读写实战:M1卡UID读取与扇区操作详解

简介:这份资源面向具备一定C#基础、希望入门RFID硬件交互的开发者,围绕射频识别卡的读取与写入展开,可用于门禁、物流跟踪、商品防伪等场景的原型搭建与学习。压缩包共29个文件,约66KB,以cs源码文件为核心,…

作者头像 李华
网站建设 2026/10/28 8:00:58

WinForms中用DataGridView模拟树形结构的实战方案

简介:本资源是一份面向C# WinForms初学者与进阶开发者的实用技术实践包,聚焦解决DataGridView控件原生不支持树形结构展示的核心痛点,适用于需在桌面应用中呈现层级化数据(如组织架构、文件目录、分类菜单)的开发场景。…

作者头像 李华
网站建设 2026/10/28 7:58:04

电商设计师必懂的免费商用字体合规指南

1. 为什么“免费商用字体”在电商设计里是个高频踩坑区? 我帮过不下二十个做淘宝、拼多多、抖音小店的运营朋友改图,几乎每三个人里就有一个被字体版权问题找上门——不是平台下架主图,就是收到律师函要求赔偿。最典型的一次是某食品类目店主…

作者头像 李华
网站建设 2026/10/28 7:57:01

矩阵置零算法:优化解法与实现细节

1. 矩阵置零问题概述矩阵置零(Set Matrix Zeroes)是算法领域的一个经典问题,题目要求:给定一个mn的矩阵,如果某个元素为0,则将其所在行和列的所有元素都设为0。这个问题看似简单,但在实际处理中…

作者头像 李华
网站建设 2026/10/28 7:56:52

多Agent系统设计:从窗口堆叠到作战编队

1. “多 Agent”被误解的十年:从窗口堆叠到作战编队的认知跃迁“多 Agent”这个词,现在点开任何技术社区,扑面而来的全是“启动5个Agent”“并行跑10个智能体”“用LangChain开一堆线程”。我去年帮一家做金融风控的客户做POC,他们…

作者头像 李华