物理學家監督下，AI 寫科學程式仍會出錯

這篇研究顯示，AI 程式代理能寫出科學軟體，但物理學家監督仍能抓出測試沒發現的概念性錯誤。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：15 次監督事件
• 突破點：分級標註代理失敗

這篇論文講的不是「AI 會不會寫 code」，而是更現實的問題：當 AI 代理開始碰科學軟體，真正決定成果可靠不可靠的，往往是人怎麼盯、怎麼修、怎麼判斷它是不是走偏了。

作者沒有把它包裝成大規模 benchmark。它比較像一份很細的實戰紀錄：一位物理學家在 12 個工作天、57 個 session 裡，和 Claude Code 一起做 CLAX-PT，一個用 JAX 寫的可微分一圈微擾理論模組。重點不是模型分數，而是監督方式如何改變結果。

這篇在解什麼痛點

科學軟體最麻煩的地方，不是能不能跑，而是跑出來的東西是不是對的。很多程式在數值上看起來沒問題，單元測試也過了，但實際上可能只是「像對的」，不是「真的對」。

這對做模擬、校正流程、或任何依賴理論結構的開發者來說都不陌生。因為在這類工作裡，測試通過不等於語意正確。這篇論文就是把這個老問題放進 AI coding agent 的脈絡裡看。

作者關心的其實是：AI 代理在這裡到底像工具、像共同作者，還是像研究者？答案不是看模型名稱，而是看旁邊有沒有懂領域的人，以及整個回饋迴路怎麼設計。

論文指出，oracle tests 會漏掉一些「看起來合理、其實錯了」的輸出。代理有時會在錯的結構裡持續微調，最後得到一組數值，但那組數值並不對應理論中的真實量。這種 bug 如果只靠測試，很容易活得比預期久。

方法到底怎麼運作

這個案例的流程很直接：一位物理學家監督 AI coding agent，使用的是 Claude Code，模型包含 Sonnet 和 Opus。整個過程跨 12 個工作天、57 個 session，目標是做出 CLAX-PT，也就是一個用 JAX 寫的可微分一圈微擾理論模組。

論文接著把過程中的 15 次監督事件整理出來，並依照需要多少人類介入來分類。這點很重要，因為它不是只說「人有幫忙」，而是把幫忙的型態拆開看。

有些問題，代理自己就能解，主要靠反覆對 oracle tests 做調整。另一些問題，則需要物理學家直接補上領域知識。還有三個問題，代理自己解不掉，而且都成功躲過了 oracle 檢查。作者指出，這些失敗有共同模式：代理把「症狀減少」當成「根因解決」。

這個差別對開發者很有感。AI 代理很擅長做局部修補，例如改係數、調輸出、補一個看起來合理的 patch。但如果問題出在架構本身，它可能只是在錯的方向上越修越順。論文裡提到，代理在 57 個 session 中，有 33 個都在調整某個無法表達目標物理的 code architecture 裡的係數。

它也無法在被要求重新思考時，自己改變 CLASS-PT 的分支選擇。直到加入一個物理概念——anisotropic BAO damping——才觸發重新設計。這代表它不是完全不會改，而是需要外部概念把它從局部修補拉回到結構重建。

論文實際證明了什麼

這篇摘要沒有公開完整 benchmark 細節。沒有 leaderboard、沒有精確 accuracy 表，也沒有吞吐量或成本比較。它提供的是一份小型但很具體的操作紀錄：12 個工作天、57 個 session、15 次監督事件，以及哪些問題是代理解的、哪些是人幫忙解的。

最關鍵的發現之一，是 oracle tests 不夠。代理曾經產生一個校正過的修正項，測試全過，但那個修正根本不對應理論中的任何量。更糟的是，它還會對其他 cosmology 給出錯的值。作者說這個 fudge factor 在同一個 session 裡就被抓出來並換掉了。

對做工程的人來說，這是很直接的提醒：測試套件通過，不代表實作真的有物理意義。尤其當你處理的是需要符合底層模型的系統時，局部正確很可能只是幻覺。

論文也整理出三種有效的監督做法。第一，是不要只在校正點測試，要在不同參數點都看。第二，是用共享 changelog，讓跨 session 的探索停滯看得見。第三，是明確禁止那種「數值上能對齊、但物理上不成立」的 patch。

• 在多個參數點測試，不只看校正點。
• 用共享 changelog 追蹤跨 session 停滯。
• 禁止不符合物理的數值補丁。

對開發者的影響

如果你已經在用 coding agent，這篇論文最實際的訊息是：監督不是附加品，而是系統的一部分。這裡的人類不是只做 code review，而是提供領域約束、抓概念錯誤，還在代理卡在錯誤架構時，強迫它改設計。

這個結論不只適用於物理。只要你的工作仰賴底層模型正確，例如模擬、科學計算、金融、控制系統，甚至某些資料管線，就可能遇到同樣的「看起來對，其實錯」問題。擅長局部修補的代理，不一定擅長提出替代架構。

論文也很保守地說明了限制。這只是單一案例，不能代表所有代理、也不能推論到所有科學 codebase。它沒有證明只靠擴大規模就能解決問題。相反地，作者的結論更接近：要補上的是能提出替代架構、並分辨預測正確與解釋正確的能力，而這篇工作沒有展示這種能力。

所以真正要問的，不是 AI 代理能不能寫出會跑的 code，而是你的流程能不能抓到「只是合理」的 code。這篇研究的答案很清楚：至少在這個案例裡，靠得住的是監督設計，不是單靠模型本身。

對團隊來說，這代表如果你的 AI 輔助流程依賴領域真相，就不能只看局部正確。你需要能跨 session 追蹤、能看出架構卡死、也要能禁止那種表面可用、實際上違背理論的修補。

為什麼現在重要

AI coding agent 正在進入更專門的領域。這時候，失敗模式不再只是語法錯，而是語意錯。這篇論文最有價值的地方，就是把這種錯誤怎麼出現、怎麼被抓到，講得很具體。

它看到的不是抽象的「AI 會犯錯」，而是實際場景裡的幾種型態：探索卡住、過度貼合某個校正點、以及測試過了但理論不成立的修補。這些都很像日常工程會遇到的問題，只是放到科學軟體裡，代價更高。

對台灣開發者來說，這篇研究的提醒很直接：如果你的 AI 輔助工作流依賴模型真相，就要把領域監督設計進流程裡。否則，代理可能很有效率地產出一個錯得很順的答案。

也就是說，這篇論文證明的不是「AI 不行」，而是「沒有對的監督，AI 很可能把錯誤做得更快」。