科研代码改写有一个很容易被低估的问题程序能编译、测试能通过、输出看起来也合理仍然可能得出错误的科学结果。OpenAI 在 2026 年 7 月 28 日发布了一份探索性现场报告汇总 8 个智能体辅助的科学计算项目主要来自生命科学。其中 5 个只使用 Codex3 个结合 Codex 和 Claude Code。项目包括依赖迁移、局部性能优化、跨语言重写、GPU 重构和新工具开发。如果只看结果表格最显眼的是速度和改写规模。报告真正有用的部分却是几次验收失败有的统计输出看起来合理继续检查才发现算法缺陷有的验证器因抽样方式产生误报智能体反而去修改原本没有问题的实现还有的优化在合成数据上快了 25.1%到了真实数据只剩 14.7%。这说明科研代码的完成标准不能是“智能体说做完了”也不能停在普通单元测试。需要先判断代码承诺保留什么再为这项承诺选择能证伪它的证据。先把“正确”拆开否则测试会答非所问不同改写任务里的“结果一致”不是同一件事。HI.SIM 的目标是局部性能优化且不改变行为验收可以要求输出逐字节一致。MHCflurry 从 TensorFlow/Keras 迁到 PyTorch底层数值实现不同无法合理要求每个浮点位完全相同团队保留已发布模型权重在 315 组等位基因与肽组合上比较 affinity、processing、presentation 等全部预测量并要求误差落在预先设定的小容差内。到了 bayesm 的统计方法扩展仅比较部分后验汇总量就不够。报告称第一版 HMC/NUTS 和 HART 扩展产生了看起来合理的总体结果但继续做收敛诊断、simulation-based calibration并与原 HART 实现比较后才暴露需要修复的缺陷。这三类任务可以对应三种不同的验收问题行为保持同一输入是否产生完全相同的文件、协议字段或离散结果数值等价允许浮点差异时哪些量需要比较容差如何确定科学有效模型或算法新增了行为时它能否在已知真值、统计校准和领域约束下成立项目如果没有先选定其中哪一个最后通常只剩“跑通了”和“肉眼看着正常”。这两项在科学计算里都只是很弱的证据。一套可复现的四层验收法报告中的案例没有遵循统一实验协议但可以从它们反复出现的做法中整理出四层验收。顺序很重要后一层不能替代前一层。第一层冻结参考对象和允许差异先固定旧版本提交、依赖、参数、随机种子和输入数据。再写清楚什么必须相同什么允许变化。以序列比对器重写为例只比较“多少条 reads 成功比对”太粗。rustar-aligner 对照 STAR 2.7.11b在相同索引和参数下用 1 万条酵母 RNA-seq reads 逐项比较 position、CIGAR、MAPQ、NH tag 和 proper-pair flag。报告结果是单端 99.815%、双端 99.883% 的 tie-adjusted parity且没有只被一方比对的 reads。没有达到 100% 不一定代表失败。等分多重比对中哪一个位置被标为主结果可能受随机选择和后缀数组顺序影响。正确做法是预先定义这类允许差异并单独统计而不是在看到结果后临时降低标准。第二层用已知答案攻击“看起来合理”旧实现可以作为参考但旧实现也可能有缺陷新功能更是没有完整旧答案可抄。这时需要构造知道答案的数据。统计采样器可以从已知参数的生成过程模拟数据再检查后验能否覆盖真值、链是否收敛、不同参数区间是否出现系统偏差。图形工具除了数值和结构测试还需要检查渲染结果。报告中的 kuva 就把自动测试与人工查看图形结合因为一个文件成功生成并不等于图例、尺度和几何关系正确。这里的原则很简单测试输入必须能让错误暴露而不只是方便程序通过。若所有样本都来自最常见路径智能体静默跳过边界分支仍可能拿到全绿结果。第三层审计验证器本身这是最容易漏的一层。HelixForge 项目曾出现一次 strand-balance 审计误报原因在下采样过程而不是 GPU 实现。智能体看到失败后修改了 GPU 代码方向完全错了。验证器因此也要有正反例。一个实用做法是准备三份固定输入一份已知应通过、一份人工植入明确错误、一份只改变抽样或随机种子的扰动样本。验证器至少要稳定放行第一份、拦截第二份并能解释第三份的波动。若更换种子就把实现从“正确”翻成“错误”先检查审计方法不要立即让智能体修生产代码。验证器由智能体生成时尤其如此。报告中的 svb 案例出现过智能体编写“能通过但无效”的测试研究者靠逐轮读代码才发现简化方法并不正确。测试文件与实现文件来自同一套错误假设时绿灯并不独立。第四层把真实数据作为最终门槛小样本和合成数据适合快速迭代但不能证明性能和边界条件会迁移到真实负载。hifiasm 在留出的 200 Mb 合成数据上减少 25.1% 运行时间并满足预设的 read-ordering 质量阈值换成记录的真实人类 20 号染色体 reads运行时间下降为 14.7%。两项结果都成立但能支持的表述不同。前者只能说明在该合成基准上的提升不能直接写成“实际任务加速 25.1%”。RustQC 的贡献者也报告真实公共测序数据在达到现实规模后暴露了小数据集没有覆盖的边界条件。这类测试不需要一开始就运行。可以在开发阶段用小样本缩短反馈在候选版本冻结后再用不同物种、数据质量和规模的代表性数据做最终验收。失败时先定位证据链不要马上改代码科研代码出现差异后至少有四种来源新实现确实错误、参考实现存在旧缺陷、验证器假设错误或数据中存在被忽略的随机与边界行为。可以把一次差异调查保存成下面这样的记录claim_id: posterior-calibration-01 candidate_commit: 新实现提交 reference_commit: 参考实现提交 dataset_hash: 固定数据哈希 seed: 20260729 metric: coverage_at_90_interval expected: 0.88..0.92 observed: 0.74 validator_version: sbc-v3 triage: implementation | reference | validator | data evidence: 最小失败样本与诊断图 decision: block这不是为了把流程写得复杂而是避免智能体在收到一句“测试失败”后扩大修改范围。先把失败压缩到最小数据、单一指标和固定随机种子再判断问题位于哪一段。只有归因为实现错误才让改写继续进入代码。报告还提到rustar-aligner 要从 90% 以上的一致率继续推进需要逐条跟踪 reads 在新旧实现中的路径。最后一公里耗时往往不是因为还差很多功能而是剩余差异不再服从同一种原因。总一致率在这时会掩盖问题逐样本差异分类更有用。速度数字也要经过来源降级这份报告是回顾性的探索报告8 个项目不是按统一协议预先组织的也不是一个具有代表性的随机样本。OpenAI 对案例结构和内部一致性做了整理并检查部分公开产物但没有独立复现每一项基准或验证结果。项目数字应视为贡献者报告的特定案例结果而不是 Codex 或编码智能体的通用性能估计。因此一篇可靠的项目复盘至少要把三种内容分开参考实现上的等价证据、真实负载上的性能证据以及谁复现过这些结果。把“案例作者报告 60 倍加速”改写成“OpenAI 实验证明可普遍加速 60 倍”证据身份已经变了。科学计算里的代码不是普通内容生成。实现错误可能落在小数点后也可能藏在一条被静默跳过的样本里。智能体降低的是实现和试错成本验收成本不会自动消失。更现实的变化是人的工作从逐行写代码移到定义真值、设计反例、审查验证器和解释差异。官方来源Scientific computing in the age of agentic AIOpenAI2026-07-28Scientific computing in the age of agentic AI: an exploratory field reportJeremy Li、Alex Rubinsteyn 等2026。
