OpenAI 與學術合作夥伴發表的一份新實地報告主張，AI 寫碼工具正逐漸成為科學界一個被忽視但重要問題的解方：維護與現代化研究軟體。許多實驗室都依賴這些軟體，但很少有團隊有時間妥善支援。研究人員在八個案例研究中，使用寫碼代理來更新安裝系統、將舊程式碼移植到較新的框架、最佳化效能，甚至把老舊工具改寫成新語言。

核心發現比起勝利宣言，更像是一種警示。根據報告，Codex、Claude Code、GPT-5.5 與 GPT-5.2 等系統能加速實作工作，有時幅度相當大，但不能被信任來判定最終軟體在科學上是否正確。實務上，這把瓶頸從撰寫程式碼，轉移到設計測試、驗證輸出，以及分配長期維護責任。

報告指出哪些地方改變了

The Decoder 將這份報告描述為實地記錄，而非正式的代表性研究；它主要聚焦在生物相關軟體。這很重要，因為許多研究工具最初只是為單一論文或專案撰寫的程式碼，後來卻被嵌入更廣泛的工作流程中，但缺乏商業軟體常見的人力與工程紀律。

在這種情境下，當任務清楚、且驗證目標能事先定義時，寫碼代理似乎最有用。例子之一是 cyvcf2，一個用來讀取基因資料的 Python 函式庫，報告中提到 GPT-5.5 被用來把過時的建置與安裝設定換成較現代的版本。

更複雜的例子是 MHCflurry，一個用於預測免疫細胞可能辨識哪些目標的免疫學模型。根據報告，Claude Code 與 Codex 在將約 10,000 行程式碼從 TensorFlow 移植到 PyTorch 的過程中，交替擔任實作與審查角色。這類遷移通常對維護性與效能都很必要，但也很冒險，因為科學軟體可能看起來運作正常，卻產生微妙錯誤的輸出。

最具野心的案例是 rustar-aligner，也就是用 Rust 重寫的 STAR。STAR 被廣泛用來將定序讀段比對到基因組位置，而報告指出原始程式碼庫超過 20,000 行 C 與 C++，且已不再 सक्रिय 維護。在對 10,000 筆短酵母細胞定序讀段的測試中，根據報告的比較標準，rustar-aligner 在單端情況下與 STAR 一致率達 99.815%，在雙端情況下達 99.883%。作者也表示，兩個工具都沒有出現另一個工具完全無法比對的讀段。

大幅加速伴隨著代價

報告強調的效能提升相當可觀，但都來自個別專案，而非跨多個團隊的受控基準測試。

RustQC 將 15 個品質控制工具整合成單一程式，據稱讓一個大型資料集的執行時間從 15 小時 34 分鐘縮短到 14 分 54 秒，也就是快了 60 倍以上。另一個專案 HelixForge 則以 GPU 版本取代 BamSurgeon，用於合成基因組資料生成。報告引用的測試中，使用一位捐贈者的資料與一段 1,000 萬鹼基對的基因組區域時，整個流程比 BamSurgeon 快了 59.6 倍，主要運算步驟則快了 98.6 倍。

其他專案雖然沒那麼戲劇化，仍然值得注意。在基因組組裝工具 hifiasm 中，GPT-5.5 據稱在研究者先建立獨立訓練與驗證資料集後，找出了可讓真實人類基因組資料的執行時間縮短近 15% 的最佳化。在 HI.SIM 中，GPT-5.2 以及之後更新的模型最佳化了程式的不同部分，在不改變輸出的情況下，總執行時間大約改善了 31%，報告如此表示。

這些結果暗示，AI 代理在研究工程中的短期實用角色，不是自動化科學，而是程式碼現代化、依賴修補、效能調校與框架遷移。對於管線脆弱的實驗室來說，即使效益不如報告中的最佳案例，也可能相當有意義。

模型在哪裡失敗了

報告最重要的訊息是：當軟體承載科學假設時，通過測試或輸出看起來合理都還不夠。

bayesm 的案例研究說明了這個問題。據稱其 Rust 重寫版本運作速度是原始版本的兩到二十倍，但兩種進階方法的早期版本仍有錯誤，而且僅靠輸出很難察覺。在其中一個案例中，寫碼代理把一個控制參數顛倒了，並使用了目標值的倒數。另一個計算錯誤也漏掉了。研究人員是在對數千個已知結果的合成資料集進行詳細校準之後，才發現這些問題。

bayesm 的第二種方法 HART 產生的結果大致看似合理，但仍包含多項缺陷，包括過於昂貴的計算，以及比例設定錯誤的修正因子。這個例子的教訓很嚴厲：軟體可以在數值上看似穩定，甚至在科學上看似合理，卻仍可能以會影響下游解讀的方式出錯。

參與這些專案的人也明確表達了這種擔憂。cyvcf2 的開發者 Brent Pedersen 寫道，寫碼代理讓快速前進變得容易，但科學仍需要「expert guidance, understanding, taste, and care」。帶領 RustQC 的 Philip Ewels 則將這些系統形容為「eloquent, convincing, and confidently wrong in ways that are easy to miss」。根據 The Decoder 的報導，他沒有讓模型自行評估正確性，而是使用獨立的測試框架。

這種分工在各個案例研究中反覆出現：人類定義目標、接受標準與驗證方法；代理產生實作；之後由專家確認軟體是否真的做對了科學工作。

證據、限制，以及這些主張的來源

這則故事中最強的主張來自一份與 OpenAI 及學術夥伴共同製作的實地報告，如 The Decoder 所述。這些案例研究是參與者的回顧性敘述，而非對研究軟體工作的隨機或代表性調查。這項限制很重要。

因此，RustQC、HelixForge、hifiasm、HI.SIM、bayesm、rustar-aligner、MHCflurry 與 cyvcf2 的效能數字，都是相關團隊回報的專案特定結果。它們應該被視為在嚴格限定條件下「可能做到什麼」的例子，而不是一般性的證明，證明寫碼代理在其他程式碼庫也能可靠交出相同效益。

同樣的謹慎也適用於報告中的經濟估算。作者推測，如果代理能解決 100 個研究套件中四分之一到一半的安裝問題，所節省回來的研究時間價值可能介於 60 萬美元到將近 500 萬美元之間。他們也估計 NumPy 每年可節省約 650 小時的維護時間。這些數字都是報告中的方向性估算，並非外部驗證過的市場資料。

報告也指出一個重要的組織風險：便宜的重寫可能造成碎片化。如果實驗室生成替代版本的速度，快過社群能維護它們的速度，使用者可能被分散，而維護者也會消耗更多時間。這個疑慮在案例中都有出現。有些改進被合回原始專案，但有些沒有。由於 STAR 已不再維護，rustar-aligner 轉向了 scverse。在另一個案例中，FastQC 的作者拒絕以 Rust 重寫版取代原始工具，團隊則改把發現的改進套用到既有的 Java 版本上，做出了同樣三倍的加速。

為什麼這對建構者與企業 AI 團隊重要

對 AI 建構者而言，這份報告強化了把寫碼代理視為基礎設施助理，而不是端到端自主開發者的論點。實用模式不是「代理寫程式碼，直接上線」，而是「代理在嚴格驗證迴圈中提出變更」。這對在醫療、 生技、金融與工業系統等受監管或高風險領域工作的企業 AI 團隊尤其重要。

對評估 Codex、Claude Code、GPT-5.5 或 GPT-5.2 的產品團隊來說，實務上的重點是：可靠性與其說取決於單一模型，不如說取決於周邊流程。獨立測試框架、黃金標準資料集、正式接受標準與人類審查仍然不可或缺。任務能被定義得越清楚，寫碼代理似乎就越能提供價值。

對研究機構與企業買家而言，維護面向甚至可能比純粹的速度提升更重要。許多機構仰賴的是老舊但關鍵的軟體，而原始作者早已離開。如果 AI 寫碼工具能降低升級、框架移植、相依修補或效能調校的成本，它們就可能延長關鍵工具的生命週期。但買家也會承擔驗證與後續維護的責任。

接下來要看什麼

下一個值得觀察的訊號，是這些案例研究方法是否會變成可重複的工作流程。這需要的不只是更好的模型，還包括標準化評估框架、更清楚的責任歸屬模式，以及比較重寫工具與可信基準的更強實務。

也值得觀察的是，是否會有更多社群效法 scverse，為 AI 協助的重寫提供制度化的歸屬，而不是把它們留成一次性實驗。另一個指標是，像 NumPy 或 PyTorch 周邊科學函式庫這類重要專案的維護者，是否會讓代理主導例行維護工作，同時對演算法變更保持更嚴格的人類審查。

最後，模型進步仍然重要。參與 MHCflurry 工作的一位人士據稱表示，2025 年初的早期嘗試失敗，是因為當時可用模型還不夠強。如果這個判斷正確，新一代模型可能會擴大代理能處理的任務範圍。但報告指出，更強的寫碼能力並不能解決更難的科學判斷問題。

Creati.ai 觀點

這份報告出現在 AI 代理辯論的重要時刻，因為它分開了兩個常被混為一談的概念：產生看起來正確的軟體，以及產出科學上可信的軟體。在研究情境中，這兩者並不相同。寫碼代理越有說服力，越容易把實作品質與領域正確性混淆，風險也就越大。

對 AI 產業而言，這指向一個更務實的機會。眼前的市場不是完全自主的研究工程，而是協助專家現代化脆弱軟體堆疊、遷移舊程式碼、縮短維護積壓，同時讓驗證更制度化的工具。把強大的程式碼生成能力，與健全的測試、可追溯性與審查工作流程結合起來的供應商，可能比只賣自主性的廠商創造更持久的價值。