科研代碼改寫有一個很容易被低估的問題程序能編譯、測試能通過、輸出看起來也合理仍然可能得出錯誤的科學結果。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。