科研代碼改寫有一個很容易被低估的問題程序能編譯、測試能通過、輸出看起來也合理仍然可能得出錯誤的科學結果。OpenAI 在 2026 年 7 月 28 日發(fā)布了一份探索性現(xiàn)場報告匯總 8 個智能體輔助的科學計算項目主要來自生命科學。其中 5 個只使用 Codex3 個結合 Codex 和 Claude Code。項目包括依賴遷移、局部性能優(yōu)化、跨語言重寫、GPU 重構和新工具開發(fā)。如果只看結果表格最顯眼的是速度和改寫規(guī)模。報告真正有用的部分卻是幾次驗收失敗有的統(tǒng)計輸出看起來合理繼續(xù)檢查才發(fā)現(xiàn)算法缺陷有的驗證器因抽樣方式產(chǎn)生誤報智能體反而去修改原本沒有問題的實現(xiàn)還有的優(yōu)化在合成數(shù)據(jù)上快了 25.1%到了真實數(shù)據(jù)只剩 14.7%。這說明科研代碼的完成標準不能是“智能體說做完了”也不能停在普通單元測試。需要先判斷代碼承諾保留什么再為這項承諾選擇能證偽它的證據(jù)。先把“正確”拆開否則測試會答非所問不同改寫任務里的“結果一致”不是同一件事。HI.SIM 的目標是局部性能優(yōu)化且不改變行為驗收可以要求輸出逐字節(jié)一致。MHCflurry 從 TensorFlow/Keras 遷到 PyTorch底層數(shù)值實現(xiàn)不同無法合理要求每個浮點位完全相同團隊保留已發(fā)布模型權重在 315 組等位基因與肽組合上比較 affinity、processing、presentation 等全部預測量并要求誤差落在預先設定的小容差內(nèi)。到了 bayesm 的統(tǒng)計方法擴展僅比較部分后驗匯總量就不夠。報告稱第一版 HMC/NUTS 和 HART 擴展產(chǎn)生了看起來合理的總體結果但繼續(xù)做收斂診斷、simulation-based calibration并與原 HART 實現(xiàn)比較后才暴露需要修復的缺陷。這三類任務可以對應三種不同的驗收問題行為保持同一輸入是否產(chǎn)生完全相同的文件、協(xié)議字段或離散結果數(shù)值等價允許浮點差異時哪些量需要比較容差如何確定科學有效模型或算法新增了行為時它能否在已知真值、統(tǒng)計校準和領域約束下成立項目如果沒有先選定其中哪一個最后通常只?！芭芡恕焙汀叭庋劭粗！?。這兩項在科學計算里都只是很弱的證據(jù)。一套可復現(xiàn)的四層驗收法報告中的案例沒有遵循統(tǒng)一實驗協(xié)議但可以從它們反復出現(xiàn)的做法中整理出四層驗收。順序很重要后一層不能替代前一層。第一層凍結參考對象和允許差異先固定舊版本提交、依賴、參數(shù)、隨機種子和輸入數(shù)據(jù)。再寫清楚什么必須相同什么允許變化。以序列比對器重寫為例只比較“多少條 reads 成功比對”太粗。rustar-aligner 對照 STAR 2.7.11b在相同索引和參數(shù)下用 1 萬條酵母 RNA-seq reads 逐項比較 position、CIGAR、MAPQ、NH tag 和 proper-pair flag。報告結果是單端 99.815%、雙端 99.883% 的 tie-adjusted parity且沒有只被一方比對的 reads。沒有達到 100% 不一定代表失敗。等分多重比對中哪一個位置被標為主結果可能受隨機選擇和后綴數(shù)組順序影響。正確做法是預先定義這類允許差異并單獨統(tǒng)計而不是在看到結果后臨時降低標準。第二層用已知答案攻擊“看起來合理”舊實現(xiàn)可以作為參考但舊實現(xiàn)也可能有缺陷新功能更是沒有完整舊答案可抄。這時需要構造知道答案的數(shù)據(jù)。統(tǒng)計采樣器可以從已知參數(shù)的生成過程模擬數(shù)據(jù)再檢查后驗能否覆蓋真值、鏈是否收斂、不同參數(shù)區(qū)間是否出現(xiàn)系統(tǒng)偏差。圖形工具除了數(shù)值和結構測試還需要檢查渲染結果。報告中的 kuva 就把自動測試與人工查看圖形結合因為一個文件成功生成并不等于圖例、尺度和幾何關系正確。這里的原則很簡單測試輸入必須能讓錯誤暴露而不只是方便程序通過。若所有樣本都來自最常見路徑智能體靜默跳過邊界分支仍可能拿到全綠結果。第三層審計驗證器本身這是最容易漏的一層。HelixForge 項目曾出現(xiàn)一次 strand-balance 審計誤報原因在下采樣過程而不是 GPU 實現(xiàn)。智能體看到失敗后修改了 GPU 代碼方向完全錯了。驗證器因此也要有正反例。一個實用做法是準備三份固定輸入一份已知應通過、一份人工植入明確錯誤、一份只改變抽樣或隨機種子的擾動樣本。驗證器至少要穩(wěn)定放行第一份、攔截第二份并能解釋第三份的波動。若更換種子就把實現(xiàn)從“正確”翻成“錯誤”先檢查審計方法不要立即讓智能體修生產(chǎn)代碼。驗證器由智能體生成時尤其如此。報告中的 svb 案例出現(xiàn)過智能體編寫“能通過但無效”的測試研究者靠逐輪讀代碼才發(fā)現(xiàn)簡化方法并不正確。測試文件與實現(xiàn)文件來自同一套錯誤假設時綠燈并不獨立。第四層把真實數(shù)據(jù)作為最終門檻小樣本和合成數(shù)據(jù)適合快速迭代但不能證明性能和邊界條件會遷移到真實負載。hifiasm 在留出的 200 Mb 合成數(shù)據(jù)上減少 25.1% 運行時間并滿足預設的 read-ordering 質(zhì)量閾值換成記錄的真實人類 20 號染色體 reads運行時間下降為 14.7%。兩項結果都成立但能支持的表述不同。前者只能說明在該合成基準上的提升不能直接寫成“實際任務加速 25.1%”。RustQC 的貢獻者也報告真實公共測序數(shù)據(jù)在達到現(xiàn)實規(guī)模后暴露了小數(shù)據(jù)集沒有覆蓋的邊界條件。這類測試不需要一開始就運行?？梢栽陂_發(fā)階段用小樣本縮短反饋在候選版本凍結后再用不同物種、數(shù)據(jù)質(zhì)量和規(guī)模的代表性數(shù)據(jù)做最終驗收。失敗時先定位證據(jù)鏈不要馬上改代碼科研代碼出現(xiàn)差異后至少有四種來源新實現(xiàn)確實錯誤、參考實現(xiàn)存在舊缺陷、驗證器假設錯誤或數(shù)據(jù)中存在被忽略的隨機與邊界行為?？梢园岩淮尾町愓{(diào)查保存成下面這樣的記錄claim_id: posterior-calibration-01 candidate_commit: 新實現(xiàn)提交 reference_commit: 參考實現(xiàn)提交 dataset_hash: 固定數(shù)據(jù)哈希 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這不是為了把流程寫得復雜而是避免智能體在收到一句“測試失敗”后擴大修改范圍。先把失敗壓縮到最小數(shù)據(jù)、單一指標和固定隨機種子再判斷問題位于哪一段。只有歸因為實現(xiàn)錯誤才讓改寫繼續(xù)進入代碼。報告還提到rustar-aligner 要從 90% 以上的一致率繼續(xù)推進需要逐條跟蹤 reads 在新舊實現(xiàn)中的路徑。最后一公里耗時往往不是因為還差很多功能而是剩余差異不再服從同一種原因?？傄恢侣试谶@時會掩蓋問題逐樣本差異分類更有用。速度數(shù)字也要經(jīng)過來源降級這份報告是回顧性的探索報告8 個項目不是按統(tǒng)一協(xié)議預先組織的也不是一個具有代表性的隨機樣本。OpenAI 對案例結構和內(nèi)部一致性做了整理并檢查部分公開產(chǎn)物但沒有獨立復現(xiàn)每一項基準或驗證結果。項目數(shù)字應視為貢獻者報告的特定案例結果而不是 Codex 或編碼智能體的通用性能估計。因此一篇可靠的項目復盤至少要把三種內(nèi)容分開參考實現(xiàn)上的等價證據(jù)、真實負載上的性能證據(jù)以及誰復現(xiàn)過這些結果。把“案例作者報告 60 倍加速”改寫成“OpenAI 實驗證明可普遍加速 60 倍”證據(jù)身份已經(jīng)變了?？茖W計算里的代碼不是普通內(nèi)容生成。實現(xiàn)錯誤可能落在小數(shù)點后也可能藏在一條被靜默跳過的樣本里。智能體降低的是實現(xiàn)和試錯成本驗收成本不會自動消失。更現(xiàn)實的變化是人的工作從逐行寫代碼移到定義真值、設計反例、審查驗證器和解釋差異。官方來源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。