以前谈到 AI 进步，我脑海里的画面是：研究员提出想法，工程师写代码，机器跑实验，然后团队发布一个更强的模型。
现在，有一个问题值得重新想一遍：如果提出部分想法、写实验代码、检查结果的工作，也越来越多地交给 AI，那么进步的速度会怎样变化？
一个更强的模型，可能带来一批更好用的研究助手；这些助手，又可能参与制造下一代模型。研发工具开始参与改进研发工具本身。 这正是"智能爆炸"讨论里最值得理解的那一环。
但我不想把它讲成一条已经写好结局的科幻故事。反馈循环能否持续、究竟快到什么程度、哪些工作仍然需要人，都是还没有被解决的问题。
01｜为什么这个话题又被提起来了
2026 年 9 月 28 日，相关机构发布了《What if automating AI R&D triggers an intelligence explosion?》报告。作者包括 Geoffrey Hinton、Yoshua Bengio 等研究者。报告讨论研发自动化可能引发的加速，也明确保留不确定性；作者观点不必然代表其所属机构。报告发布页
这里先分清两个概念：AI 帮忙完成一些研发任务，是可以逐项观察的现象；这些能力最终是否会引发"智能爆炸"，则是对未来路径的判断。前者有进展，并不能直接证明后者必然发生。
我读这类报告时，最关心的也不是某个惊人的年份，而是它有没有说清楚：什么条件成立时会加速，又有什么条件会让加速停下来。
02｜"AI 研发 AI"，究竟在研发什么
可以先把研发看成一串具体工作：读资料、找问题、提出方案、实现实验、观察结果、复查结论。让 AI 参与其中某几步，与允许它自行改动整个生产系统，是完全不同的安排。
下面是我为了理解这件事整理的任务拆分，不是报告中的实验清单。
| 环节 | 可以让 AI 尝试的工作 | 我仍然想看到的证据 |
|---|---|---|
| 阅读资料 | 比较方法、整理已有结果 | 引用是否支持结论，有没有漏掉反例 |
| 实现实验 | 写训练或评测脚本 | 数据划分、配置、代码版本是否清楚 |
| 排查问题 | 定位性能下降或程序错误 | 修复能否复现，是否改变了评价标准 |
| 比较方案 | 汇总成本、速度与效果 | 比较条件是否一致，失败实验是否保留 |
| 整理结论 | 解释结果、提出下一步 | 哪些是测量结果，哪些只是推测 |
比如，假想一个团队正在优化模型推理速度。AI 可以提出缓存方案、实现代码、跑基准，再生成对比报告。可如果它为了获得更漂亮的速度，偷偷减少了输入长度，那就没有解决原来的问题。
所以我会把任务写成："在同一批输入、同一套质量要求下减少耗时"，并让独立流程验证输出。研发能力不只体现在能做多少事，也体现在能不能留下可检查的结果。
03｜为什么反馈循环可能改变速度
报告提出的核心机制是：AI 越擅长研发，可用的研发能力就越多；这些研发能力又帮助产生更强、更高效的 AI。报告同时讨论了收益递减、算力与数据、难以自动化的环节和实验耗时等限制。报告原文
我会用"团队复用工具"的方式理解它。
假设某个改进让实验脚本更可靠，团队花在修复环境上的时间变少了，于是能比较更多方案。其中又有方案改善工具调用，让下一轮实验更顺利。一个局部改进，经过复用，可能影响后续很多次工作。
不过，不能把这段解释画成一条必然无限上升的曲线。工具被复用多少次、节省多少时间、额外检查会增加多少工作量，都需要测量。循环图表达的是一种机制，不能代替增长预测。
还有一个容易忽略的区别：一份候选方案可以瞬间复制很多份，但它们可能重复犯同一个错误。并行数量增加，不一定等于有效研究能力按相同比例增加。
04｜真正的难点，是整个流程里最慢的那一步
对工程团队来说，最直观的判断方式是看完整流程，而不是只看"写代码快了几倍"。
举一个我自设的简化算例：某项工作需要 10 小时，其中 2 小时写代码、8 小时等待实验。如果把写代码时间减半，总时间是 9 小时，整体提速约 1.11 倍。即使代码瞬间写完，其他条件不变，整个任务也仍然需要 8 小时。
这不是对 AI 研发速度的预测，只是提醒我们：局部能力提升，要通过流程里的其他环节，才能变成最终收益。
我会把需要检查的瓶颈分成四类。
第一是实验资源。候选想法变多之后，是否有足够的机器、数据和时间去验证？排队中的实验不产生结果。
第二是验证能力。输出一百个方案很容易让人兴奋，但谁来确认它们真的改善了目标？如果复核跟不上，增加的可能只是待处理文档。
第三是研究价值。重复别人已经做过的实验，或者只在一个小测试上优化，并不自动构成有价值的进步。
第四是协调。多个助手同时改同一套代码、引用不同版本的数据、各自假设别人已经完成检查，都可能让并行变成返工。
这些是我观察研发流程时会提出的问题，不能被直接当成这篇报告已经测出的结论。
05｜我怎样判断"自动研发"的展示有没有含金量
看演示时，我会先暂时放下聊天窗口里的流畅表达，找四样东西。
明确的起点。 任务是什么，哪些资料预先提供，环境里已经有什么工具，人的帮助到哪里为止？起点不同，结果很难直接比较。
完整的成本。 模型调用只是其中一部分。跑实验、准备数据、人工检查、失败重试，都可能消耗资源。只公布成功那一次的费用，无法解释实际使用成本。
可以复查的结果。 对研发任务，我更希望看到代码版本、实验配置、输入输出和复现说明。截图里的漂亮数字，需要有来源。
失败与适用范围。 一个系统在某类任务上表现好，值得认可；如果换个领域、换批数据或增加任务时长就不稳定，也应该一起交代。
例如，某个助手声称"训练更快了"。我会继续问：模型质量有没有下降？是否用了相同硬件？统计的是完整训练还是某个步骤？首次准备环境的时间算进去了吗？这些问题不是抬杠，而是在确认这个改进能不能带回自己的项目里。
06｜普通开发者现在能做什么
我觉得最实际的做法，是先把自己项目里的一个小研究任务交给 AI，而不是一下子要求它"自主完成所有研发"。
比如挑一个可复现的性能问题，写下基线、输入样例和不能破坏的行为。允许它提出几种方案，分别实现、测量，然后比较结果。把结论保存在仓库里，下一次还能按同一方式重跑。
我会采用这样的任务约定：
text
目标：在保持现有功能正确的前提下，减少指定场景的耗时。
基线：先记录原版本的结果和运行条件。
过程：每次只验证一个主要假设，保存失败记录。
交付：给出代码差异、测试结果、成本和未解决问题。
验收：通过独立检查后，再决定是否采用这个方案。这段约定是我的工程建议，不是能够保证成功的通用提示词。它的作用是把任务边界和判断标准写出来，避免把"做了很多操作"误当成"完成了有价值的改进"。
如果连续几轮都能得到可复用的改善，再逐步增加任务范围。这样我们积累的是一条可观察的效率曲线，而不是对模型能力的印象。
07｜我真正想看到的下一步
"智能爆炸"是一个足够大的问题，大到一篇报告、一场演示都无法给出结论。
我更愿意跟踪几个具体变化：研发任务能连续完成多久，失败需要多少人工介入，复现同一个改进要付出多少成本，以及这些改进有没有进入实际使用。
如果这些指标持续改善，我们就有更充分的理由重新评估未来的速度；如果瓶颈迟迟不动，也应该诚实更新判断。
当 AI 参与研发下一代 AI，我最关心的，是每一轮改进有没有可靠的证据。只有证据跟得上，关于速度的讨论才不会只剩下想象。
你愿意把研发里的哪一步交给 AI？又有哪一步，你一定要自己复核？
本文配图为作者绘制的概念示意；10 小时流程是解释用的假想算例，不是论文实验数据。资料核对日期：2026 年 9 月 29 日。
个人原创解读，转载须注明作者及原文出处。