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