“程序正常退出”。 理论上，科研代码跑完后，终端上的这行字应该让人放心，但它背后也可能藏着不易察觉的错误。
编译器没有报错，计算按时结束，输出文件也完整地躺在目录里。研究者把新旧结果画在同一张图上：两条曲线起初贴合，随后逐渐分开。程序没有报告任何异常，关键物理量却偏离了参考结果。
光看终端上那一行“程序正常退出”，AI 无法确认这次修改是否符合科学要求。一个名为 ScienceIDE 的项目，正在尝试将科研代码、运行环境以及科学验收规则，组织成可供模型执行、验证和学习的任务。在这个系统里，模型不仅要进入代码库修改并运行程序，系统还会根据最终的科学结果，来判定这次修改是否真正有效。
项目团队在构建这些任务时发现：在具有完整记录的 1,769 个缺陷任务中，有 976 个程序能够顺利编译，并在所有评分配置下正常运行至结束，但最终给出的科学结果却是错的，这一比例高达 55.2%。
有些最难被发现的科研错误，往往长着一张“成功”的脸。
如果 AI 仅仅根据程序“是否顺利跑完”来判断任务有没有完成，它就很容易把错误的结果当成一次成功的尝试。更麻烦的是，这个错误判断一旦被当成训练奖励，模型下一次还会朝着错误的方向继续努力。要让科学经验成为训练材料，首先必须让真实的科学结果来约束 AI 的行动。问题由此更进一步：科学，能否反过来训练下一代 AI？
ScienceIDE 瞄准的正是这道缺口。这项工作由牛津大学、斯坦福大学、普林斯顿大学、加州理工学院、加州大学伯克利分校等 20 所全球顶尖高校的研究者联合完成；项目由非营利组织 AItonomy Foundation 主导发布，PhAI Labs 与 Qwen 参与支持，沐晨科技参与联合研发与技术支持。它尝试将科研代码、运行环境、科学验证和模型训练接口打通，让 AI 在实际的“执行、犯错与修正”循环中，获得真实可信的反馈。
图丨相关论文（来源：AItonomy Foundation）
这也让“IDE”（集成开发环境）这个词有了一层新的含义。传统的 IDE 把编写、运行和调试软件整合进同一个工作空间；ScienceIDE 则更进一步，把科学验证和模型学习也纳了进来。代码和程序只是载体，它真正想要开发的，是模型在真实科学任务中“行动、观察并修正自身”的能力。科学由此有机会成为训练智能的环境。
最危险的失败，可能看起来很“成功”
回到开头提到的那项任务。假设 AI 接到一个要求：修正科研代码中的一处数值偏差。它通读代码，找到一段可疑的实现，改完之后重新编译、运行。整个过程既没报错，新的输出数据也顺利生成了。
然而，真正的问题往往隐藏在程序不会主动报错的地方：比如，某个变量在进入当前模块前其实已经做过归一化，但在模块内部又被重复换算了一次；或者，一份重启文件（restart file）保存的本是上一个时间步的状态，代码却直接把它当作了当前状态；又或者，某个时间基准沿用的是代码库内部的特殊约定，而 AI 却根据教科书上的标准公式，写出了一套看似逻辑自洽、实则冲突的实现。
模型可以熟悉分子动力学，也能写出语法正确的代码，但碰到这些细节时还是容易失手。ScienceIDE 的参考实验表明：公开的物理常数、教材标准公式和通用初始条件，模型修复起来相对容易；真正让模型感到棘手的，恰恰是代码库自身的内部状态：时间步到底如何推进、不同模块间由谁负责归一化、断点重启数据保存在哪一步，以及内部单位是如何逐层换算的。
这也解释了一个现象：为什么通用代码 Agent 进步飞快，而科研领域的 Agent 面前却始终有一道坎。科研代码还需要回答一个额外的问题：功能恢复之后，科学结果是否经得起检验？
常规代码可以利用一套相对低成本、可自动执行的反馈机制。编译器可以迅速指出语法错误，单元测试可以明确某项功能是否恢复，持续集成系统（CI）还会完整记录每次构建过程。模型由此拥有了一个可以低成本连续试错的环境：修改代码、运行、看到报错、再次修改。
2025 年公开的 SWE-smith 研究，正是将这种机制推向了更大规模：研究者先为 Python 代码库搭建运行环境，再自动生成能够破坏现有测试的任务，最终从 128 个代码仓库中提炼出约 5 万个任务实例，用这些执行轨迹去训练软件工程 Agent。
Google DeepMind 的 AlphaEvolve 也是类似的逻辑：让 Gemini 持续提出候选程序，再通过自动化评估进行筛选与迭代。Google 介绍，AlphaEvolve 找到的一个矩阵乘法优化方案，让 Gemini 的相关计算内核提速了 23%，最终将模型的整体训练时间缩短了 1%。在这样的系统里，程序的实际运行表现直接决定了哪条技术路线值得继续探索。
但科学计算却缺少一把同样通用的“尺子”。程序能跑通，只说明计算机把指令执行完了；至于计算结果对不对，还得回到具体的物理量、数值行为和实验条件里去检验。更复杂的是，不同的科学问题往往需要不同的观察对象与容差范围。一套适用于矩阵运算的确定性测试，根本无法直接套用到气候模拟、材料计算或含有随机扰动的物理系统中。
所以说，科学研究能给 AI 提供的资源，除了论文、数据和源代码，更在于研究过程中不断产生的“过程证据”：哪一次尝试改变了结果，哪一项修正恢复了物理守恒，哪一种解释被实验事实所推翻。在过去，这些探索过程大多散落在个人终端的日志里、碎片化的代码版本里，还有研究者自己的经验里。ScienceIDE 想做的事，就是把这些宝贵的过程系统化地组织起来，变成模型可以直接学习的材料。科学除了生产知识，也可能生产训练智能的经验。
图丨科学知识成为可执行环境（来源：AItonomy Foundation）
训练AI之前，先检查“裁判”
要让科学成为可靠的训练环境，首先得保证“题目本身是成立的”，评分规则也确实能区分有效行动与无效尝试。
还是拿前面提到的那项任务举例，研究者得先固定好代码版本、依赖环境和编译方式，准备好输入数据，标清楚需要重点观察的物理量，还得明明白白地给出“怎样的结果才算合格”。ScienceIDE 的做法是：将一个庞大的科研代码库按照科学职责和可执行边界拆分成若干模块，再将每个模块所需的运行环境、科学算例和验证流程完整封装起来。
图丨ScienceIDE 从科研代码库到智能体经验的四步工作流。（来源：AItonomy Foundation）
项目中把这些封装好的模块称为“环境”。容器本身只是技术外壳，环境真正封存的，是专业科学家在其中注入的科学判断。
对于确定性的计算任务，验证器可以根据任务要求比对输出结果；可一旦涉及随机性、混沌效应，或者存在多种合法实现的复杂场景，硬要“数值逐点一致”就不太合理了。这就需要领域专家做出判断：挑选出真正具有物理意义的观测量，决定究竟该比对统计特征、守恒量还是演化趋势，并结合参考基准与数值波动范围设定合理的容差。这些规则有各自的适用条件，也需要接受检验。
这些原本藏在专家脑子里的经验，一旦固化成可执行的代码规则，后面的测试就不用每次都从头讨论了。不同的模型可以进入同一个环境，面对完全一致的科学边界；同一个环境也可以源源不断地衍生出代码修复、功能实现、性能加速和结果复现等各类任务。专家的一次性投入，就此转化为了可反复调用的标准化验证能力。
在 ScienceIDE 中，负责持续生成这些任务的组件被称为“任务工厂”。它可以在代码中主动引入候选缺陷，或者剔除某段关键实现，以此要求 Agent 恢复正确的科学行为。不过，自动生成的任务并不会直接进入题库，因为自动制造一道题并不难，难的是证明这道题是有效且有意义的。
项目团队在天体物理模拟软件 PLUTO 的一组测试中，筛选了 2,533 个候选缺陷，结果发现有 1,488 个缺陷根本没有在评分配置中引发可观测的科学异常，占比达 58.7%。如果把这类任务直接推给模型，模型哪怕什么都不改也能拿到满分，训练系统也就彻底失去了判断“哪次行动真正改善了结果”的能力。题目更多，并不自动意味着模型能学得更多。
因此，每一道生成的修复任务都必须预先跑通一轮对照实验：包含缺陷的程序必须实际运行，并且明确表现出可测量的科学偏差；同时，参考修复方案也必须在完全相同的环境中重新跑通，证明它确实能把正确的科学行为恢复过来。空提交、报错提交，以及仅仅凑出正确输出格式的方案，也都需要接受这样的对照检验。在这个过程中，基础设施本身的故障、任务自身的漏洞与 Agent 解题的失败，也必须被严格区分开来。
到了这一步，ScienceIDE 才开始把一次次试错组织成模型可以学习的经验。
Agent 进入环境后，会经历一个完整的闭环：阅读代码与输入、提出修改方案、触发编译计算、检查输出结果，再根据系统的反馈调整下一步动作。系统同时记录补丁形成过程中的行动与反馈链条：它采取过哪些操作、看到了怎样的计算反馈、在哪几个物理指标上取得了局部进展，以及是哪项证据促使它放弃了最初的推测。
打个比方：模型第一次改完之后，大部分输出都恢复正常了，但还有一个守恒量超出了容差范围，这个具体的数值反馈就会领着它往新的方向去排查。它可能会顺着这个线索继续追踪变量的传递链条，最终发现某处单位换算被重复执行了两次。最终的提交只体现了修复结果，但整条执行轨迹，却完整记录了“证据如何推动下一步行动”。
失败本身不会自动变成经验。一段轨迹是否具备学习价值，关键取决于其中的反馈是否真实可靠，能否支持下一步判断。如果报错的原因出在程序运行环境之外，模型需要明确知道自己撞上的是系统缺陷还是科学难题；如果某次修复确实改善了部分指标，评分机制也应当把这一步进展公允地呈现出来。要是把所有不完美的尝试都简单粗暴地打成一个“未通过”，就等于把科研探索里最宝贵的试错信息又一次抹杀掉了。
经过筛选的成功轨迹可以用于监督微调，执行过程中产生的分级反馈可以成为强化学习的奖励。同一套验证器也能在推理阶段比较多个候选方案。由此，科研软件开始成为 AI 练习行动和修正的环境。
学会一道题，还是学会一种能力？
截至 2026 年 9 月 16 日，ScienceIDE 已经收录了来自 27 个上游开源代码库的 64 个环境定义，总计生成了 2,812 个具体任务，涵盖天体物理、海洋与气候、空间等离子体、材料科学、光子学和量子模拟等 14 个学科领域。
图丨ScienceIDE连接“用科学训练AI”与“用AI加速科学”的双向闭环。（来源：AItonomy Foundation）
这些任务也暴露了科学训练环境中容易被忽略的隐性痛点：任务本身可能会失效，验证逻辑可能会误判，算力预算的设置可能会人为制造虚假的门槛，模型甚至可能通过未曾预料的旁路途径投机拿到参考答案。一个科学任务库只有持续审计这些环节，产生的分数才有意义。模型会沿着奖励寻找进步，奖励本身也必须经得起检验。
静态的基准测试集（Benchmark）虽然能用来考一考模型在公开考题上的表现，却很难持续给模型训练提供源源不断的新养料。ScienceIDE 真正聚焦的，是科学探索经验该如何被规模化生产、自动化验证，并持续转化为可供模型吸收的训练材料。它不仅是在测量模型的能力边界，同时也在持续审视题目和验证规则本身的有效性。
回到科学反哺智能的目标：用这些经验训练出来的模型，真的会变得更强吗？
目前的公开报告里已经设计好了监督微调和强化学习的接入接口，但完整的模型训练收益数据，还得等进一步补充。模型究竟是仅仅记住了特定代码的修复技巧，还是真正学会了在完全陌生的科研代码库中追踪运行状态、构建假设并根据客观证据修正思路？这两种能力有着本质的不同，依然需要严格的分布外实验（out-of-distribution tests）来加以证实。
这也正是 ScienceIDE 下一步必须经受的检验。环境能正常跑通、任务能打出分数，仅仅代表模型学习所需的基础设施已经就绪。只有当模型在新的科研系统里表现出更可靠的行动与修正能力，“科学训练下一代 AI”才从研究判断走向实验结果。
从AI做科学，到科学训练AI
PhAI Labs 支持 ScienceIDE，源于这一研究判断：科学经验有望反哺智能，让模型在知识被生产和检验的过程中学习。
PhAI Labs 在 Discovery Foundation Models（DFM，发现基础模型）框架中，将目标从解决给定问题推进到识别未知、形成问题、构造假设、设计干预，并根据外部证据修正研究方向。在这里，答案不再是终点。一次研究有没有价值，还得看它有没有改变系统对问题的理解，以及这次改变能不能让下一次研究做得更好。
这条路线对验证提出了更高要求。模拟结果跟预期对不上的时候，问题可能出在代码，也可能出在假设、变量选择、测量方式或者问题定义上。模型需要保留多种解释，选择能够区分它们的下一步行动，再让外部证据决定哪一部分需要修改。
当然，DFM 目前依然主要是一套宏观的研究框架与能力演进目标。而 ScienceIDE 的出现，恰好为这一构想提供了一个能够率先落地的切入点：先从逻辑闭环、可严格执行且可检验的科研代码任务做起，训练 AI 学会面对客观结果、读懂试错反馈，并据此调整自己的行为。尽管从“修补科研代码”到“实现开放式科学发现”之间依然道阻且长，但这无疑是一项无法绕过的基础功课——学会依据客观事实，改变自己的主观判断。学会通过已有检验，距离学会探索未知，还有多远？
对于大模型研发团队而言，ScienceIDE 构筑了一个能够横向对比不同 Agent 架构、沉淀高价值执行轨迹、深入探索训练算法的公共基座；而对于深耕科学计算的科研团队来说，过往沉淀下来的大量成熟代码、典型算例与验收指标，都可以经过整理与验证，转化为建设这类训练环境的宝贵资源。那些长期以来高度依赖科学家个体“只可意会”的隐性经验，终于有机会被固化为能够赋能更多AI 系统的可执行、可复用的验证规则。科学团队也由此有机会成为下一代AI训练经验的生产者。
过去，大语言模型主要靠“阅读”人类已经写在书本上的存量知识来学习；后来，通用代码环境的引入，让模型开始学会在“行动与执行”的结果里自我迭代。而 ScienceIDE 想要在此基础上再向前迈进一步：让科研中的行动、检验与修正，持续转化为模型可以学习的经验。
终端屏幕上闪烁的那行“程序正常退出”，只说明计算机把底层的计算指令执行完了。跑出来的科学结果究竟能否站得住脚，终究要接受物理规律与实验逻辑的严格审视；而 AI 究竟能否从这些严谨的审视与反馈中汲取养分、持续进化，才是 ScienceIDE 真正想要回答的核心问题。如果科学能够生产训练智能的经验，那么一次研究的价值，就可能超出它所得到的那个答案。
参考资料：
技术报告：https://phai-labs.com/papers/scienceide/
网页链接：https://aitonomy.org/projects/scienceide
GitHub：https://github.com/aitofound/ScienceIDE
Hugging Face：https://huggingface.co/collections/AItonomy/scienceide-model-series
