刚刚，Claude四周重写30个生物模型，ScienceIDE已规模化训练AI科学家

机器之心发布 就在刚刚，Anthropic 发布了一项引发关注的研究：在不到四周时间里，Claude 优化了 30 多个开源生物分子模型。 其中包括 AlphaFold3、Boltz-2、Chai-1、ESMFold2、RFdiffusion 等已经广泛使用的科学模型。 结果显示，在允许少量数值精度变化的情况下，任务平均加速约 4 倍；在要求输出完全一致时，平均加速接近 2 倍。相关代码也同步开源。 更值得关注的是完成这项工作的方式。 代码优化主要由 Claude 自己完成，背后监督它的是两名 Anthropic 技术人员。他们理解生物建模，但并不具备传统意义上的推理优化或 GPU kernel 工程背景。 这件事的意义不难理解。科学家每天使用的计算工具变快、变省，同样的时间和预算就能支撑更多数字实验。让 AI 加速已有的科学软件，是加速科学研究最直接的一条路径。 不过，这份报告回答了 "AI 能不能做到"，却留下了另一个问题： AI 写出的科学代码，距离充分发挥硬件性能，还有多远？ 几乎在同一时间，一个开源项目试图回答 Claude 留下的问题：如果 AI 能优化科学代码，如何让这种能力被持续学习、复用，并迁移到更多科研领域？ 9 月 17 日，AItonomy Foundation 发布了它的第一个开源项目 ScienceIDE，赞助方为 PhAI Labs 与阿里 Qwen。这是一套把世界上的科学代码库转化为可执行、可验证学习环境的基础设施。 技术报告：ScienceIDE: Turning World’s Scientific Codebase into Agent Learnable Environments arXiv链接： https://arxiv.org/abs/2609.19134 开源代码：https://github.com/aitofound/ScienceIDE 模型：https://huggingface.co/collections/AItonomy/scienceide-model-series 项目页：https://aitonomy.org/projects/scienceide 图 1：ScienceIDE 把科学工作与智能体学习连接起来。下图左下为环境与任务分布，右下为 ScienceIDE-Hard 评测结果。 一段跑得通、却慢了三倍的代码 在筹备这个项目的过程中，团队在等离子体物理与天体物理的代码上做过一次实验，结果指向了上面那个问题。 实验的对象是 PLUTO。 这是等离子体物理和天体物理领域一套广泛使用的高性能科学计算代码，代表性论文发表于 2007 年，至今已有近二十年。它覆盖流体力学、磁流体力学、相对论流体力学与相对论磁流体力学等多个物理系统，支持不同的坐标几何、物理模块与数值算法。这样的代码库本身就可以被看作一种计算物理基础设施。 它的复杂度不体现在代码量上。以其中的流体和磁流体计算为例，Godunov 型激波捕捉格式需要把空间重构、网格界面的黎曼求解器和时间推进组织成完整的计算流程，每一步都有自己的数据依赖、访存模式和数值稳定性要求。磁流体模拟还要处理磁场无散条件，约束输运与散度清理等方法把额外的物理约束直接带进了数值实现。这些都不是工程细节，而是必须在迁移中被保住的科学内容。 PLUTO 团队自己也在做 GPU 化。2025 年发表的 gPLUTO 论文介绍了一套以 C++ 完全重写、通过 OpenACC 实现 NVIDIA GPU 加速的新实现。 AItonomy 的团队则尝试在 M1 Ultra、A100 和 H100 上重新实现 PLUTO 的磁流体力学模块。在 A100 的一次测试中： AI 生成的第一版实现已经能够运行，并在当时检查的算例上得到符合预期的物理结果； 但相对团队使用的 128 核 CPU 节点配置，它的速度提升还不到 5 倍； 随后，团队用一两天时间与 AI 一起分析瓶颈，调整数据布局、内存访问、kernel 组织以及不必要的数据搬运。在不改变所求解物理问题的前提下，这套 GPU 实现的速度又提高到第一版的接近 3 倍。 也就是说，AI 已经把代码 "写出来" 之后，仍然留下了数倍的性能空间。 对于复杂的科学计算代码，一次性生成的实现距离充分利用硬件，往往还有很长一段路。而要继续挖掘这部分空间，AI 必须能够测量、诊断、修改、验证，再根据结果继续迭代。 这不是 "换个更好的提示词" 能解决的问题。数据布局应如何匹配线程访问？相邻线程能否形成合并访存？哪些中间结果值得缓存，哪些可以重算以减少内存流量？kernel fusion 能否减少启动开销，又会不会增加寄存器压力、影响 occupancy？这些都需要通过 profiling 和实际运行来判断。 GPU 的理论峰值算力只是起点。科学代码的实际性能，取决于数值算法、数据移动和并行执行方式能否与硬件匹配。 跑得通，不等于算得对 性能优化始终伴随着另一个问题：改写后的程序，还能否可靠地回答原来的研究问题？ 这件事在 Anthropic 自己的报告里有一个很好的例证。 为了测试优化的极限，他们让 Claude 在单个 8 卡 B300 节点上预测 31,000 到 70,000 token 以上的完整病毒衣壳和蛋白区室。推理全部跑通了，这本身就是此前需要多节点集群才能做的事。但报告写得很直接：这些结构没有被正确预测。报告分析指出，预测结构发生坍塌，模型在训练上下文近两个数量级之外缺乏泛化能力。 程序能跑，不代表科学上正确 。判断一个科学结果对不对，要拿它去和科学参考答案比对，而不是看程序有没有报错退出。 放到科学代码加速这件事上，这条判据是很具体的。质量与能量的守恒误差是否可控？磁场散度是否满足所选数值方法的要求？激波位置、波传播速度和关键物理量是否与参考结果一致？不同的科学问题，验收标准也不一样。 不把这些定下来，一个程序完全可以通过少算几步、降低分辨率或跳过重要过程变快，同时失去原来的用途。ScienceIDE 把这一点称为科学等效性，并把它写成了任务是否算完成的判据。 把科学代码库变成可以学习的环境 如果一次成功的优化只是一个交付物，那它就只能被使用，不能被学习。ScienceIDE 想解决的是后一件事。 科学代码库本身已经保存了大量人类知识，但这些知识分散在源代码、编译配置、测试算例，以及研究者没有写下来的经验里。要让 AI 从中学习，需要把它们组织成能够执行、能够反馈、能够判定结果的环境。 具体做法是：由领域专家定义科学算例与验收标准，再与 AI 一起把代码库整理成可执行环境。在这些环境里，AI 完成任务、运行程序、检查科学结果，而经过验证的交互经验被用于评测、监督微调和强化学习。 ScienceIDE 的目标，是把科学代码库保存的大量可执行的领域知识组织成智能体能够执行、获得反馈并学习的环境。 目前论文报告的集合包含来自 27 个科学代码库的 64 个环境、2,812 个任务，以及 1,076 项可执行的科学检查，覆盖天体磁流体、空间等离子体、海洋气候、引力 N 体、光子学与电磁、材料、量子、相对论、粒子探测器、免疫学等方向。任务被分为加速、修复、发