AI 寫出一篇科研論文，你敢用嗎？
想像一下。
你把一個科研問題交給 AI：尋找一種降低大型模型推理成本的新方法。
幾個小時後，它傳回一篇完整論文、一套實驗程式碼、一組 Benchmark 資料，以及一個看起來很新的演算法。
論文結構完整，圖表漂亮，實驗結果也很驚豔：推理速度提升 35%。
問題來了：你相信嗎？
你可能會先打開程式碼，確認裡面是否真的實作了論文描述的方法；再檢查實驗日誌，看看 35% 是實際跑出來的，還是模型從某次中間實驗裡挑出來的；最後還要逐條核對引用，確認那些名字很像真的論文確實存在。
然後你發現程式碼裡沒有那個演算法、實驗結果也無法重現，甚至引用的論文都查不到。
最尷尬的是，這篇論文讀起來依然可能非常專業。
ScientistOne 想解決的，不是讓 AI 更會寫論文
2026 年 5 月，Google Cloud AI Research 團隊發布了一篇 arXiv：ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence。
這項工作的重點並不只是再做一個更強的 AI Scientist，它更關注的是如何讓 AI 生成的研究可以被稽核。
論文團隊稽核了 5 個自動研究系統在 5 類前沿系統研究任務中生成的 75 篇論文。結果很有意思：
- 有的系統，虛假引用比例達到 21%；
- 有的系統，論文分數重新驗證後的通過率只有 42%；
- 不同系統的方法與程式碼一致率只有 20% 到 80%。
換句話說，一篇論文可能寫得很好，演算法也可能真的跑出了不錯的結果，但論文裡的數字、方法、程式碼和引用並不一定屬於同一條事實鏈。
這有點像一個程式設計師交付了漂亮的技術文件、完整的測試報告和一份能執行的程式碼，唯一的問題是：三者寫的不是同一個系統。
ScientistOne 給出的核心方案叫：Chain-of-Evidence（CoE）證據鏈
它的基本就是每一個重要 Claim，都必須能夠沿著一條被記錄的證據鏈，回到它的原始依據。
從「生成答案」到「生成可驗證的知識」
普通 Agent 的輸出過程通常是：
使用者問題 -> Agent 執行 -> 最終答案
比如它告訴你：新演算法讓準確率提升了 10%。到這裡任務就結束了。
而 CoE 關心的不是這句話夠不夠像結論，而是它後面有沒有一條完整鏈路：
Claim：準確率提升 10%
↓
Evidence：evaluation log 中的指標
↓
Artifact：評測腳本、訓練程式碼、資料版本
↓
Grounding Source：真實實驗執行結果
↓
Verification：重新執行並計算指標
所以 CoE Agent 最終交付的，不應該只是一段文字，而是一個可以被審查的知識單元。
別人不需要因為它「說得很像真的」而相信它。
別人可以順著證據鏈，自己去檢查它是不是真的。
CoE 怎麼運作：先給研究中的 Claim 分類
論文把科學聲明分成四類：
Citation Claim 引用聲明
Numerical Claim 數值聲明
Methodological Claim 方法聲明
Conclusion Claim 結論聲明
不同 Claim，需要不同的證據。
如果 AI 說「某篇研究提出了某個方法」，它需要關聯到真實存在、實際讀取過的論文。
如果 AI 說「準確率提升 10%」，它需要關聯到評測輸出和實驗日誌。
如果 AI 描述了一種新的 Attention 最佳化方法，它需要關聯到程式碼中真正實作該方法的模組。
如果 AI 得出一個研究結論，它需要明確依賴哪些已經被驗證的數值聲明和方法聲明。
這一步看起來只是把自然語言結構化，實際上非常關鍵。
因為「我們的方法效果很好」沒有辦法直接驗證，但下面這個聲明可以：
{
"type": "numerical",
"claim": "模型準確率由 81.2% 提升到 89.4%",
"evidence": "runs/exp_042/evaluation.log#L118",
"metric": "top-1 accuracy"
}
只有 Claim 被結構化，驗證才有明確的對象。
ScientistOne 不是最後再補引用，而是從一開始就記錄證據
這是我覺得 ScientistOne 最值得關注的地方。
很多 Agent 設計會在論文快寫完時，再讓另一個 Agent 檢查引用、修數字、補證據。
這很像程式碼上線前一天才開始補測試：不是完全沒用，但大量上下文已經丟了，最後只能靠猜。
ScientistOne 的思路是讓證據跟著研究過程一起產生。
它的系統大致分成三段：
Problem Investigator
文獻檢索、全文閱讀、生成有來源的研究簡報
↓
Discovery Engine
平行探索方案、執行實驗、保留評測結果與日誌
↓
Paper Writer + Claim Verifier
基於已有產物寫作，並逐條驗證 Claim
在文獻階段，它從學術資料庫檢索論文，閱讀完整 PDF，並記錄來源資訊。
在實驗階段，它把程式碼、Evaluator 分數、執行日誌和消融實驗結果一起保存。
在寫作階段，每個帶有數字或引用的句子，都要提前綁定具體證據。Claim Verifier 再檢查論文裡的數字能不能在日誌中找到、引用是否支持原句、方法描述是否與實驗記錄一致。
沒有來源，或者證據標記不合法的 Claim，會被直接刪除。
這不是讓 AI 在答案後面隨手貼幾個連結。
它是在研究發生的同時，建立一份可以回放、可以檢查的證據帳本。
Verification，而不只是 Provenance
記錄來源並不等於完成驗證。
一個檔案存在，不代表裡面的資料正確。
一篇論文真實存在，也不代表它支持目前這句話。
一段程式碼能夠執行，更不代表它實作了論文聲稱的方法。
所以 ScientistOne 還設計了一套 CoE Integrity Audit，專門檢查四類問題：
Score Verification
論文報告的分數能否重新跑出來
Specification Violation
方案是否鑽了評測規則的漏洞
Reference Verification
引用是否真實存在
Method-Code Alignment
論文描述的方法是否真的出現在程式碼裡
按照專案公開的資料，ScientistOne 在這組實驗中實現了：
- 337 條參考文獻中，虛假引用為 0；
- 12 篇可重複評測的論文，分數驗證全部通過；
- 15 篇論文中，14 篇通過方法與程式碼一致性檢查。
這些資料來自論文團隊自己的實驗，目前論文也還是預印本，因此不應該直接理解成「AI 自動研究已經可靠」。
但它至少說明了一個很重要的方向，可靠性不能只靠模型自覺，必須被做成系統中的檢查機制。
這和軟體工程很像，程式碼不能因為開發者說「我覺得沒問題」就上線。
AI 生成的研究，也不能因為語言通順、圖表漂亮就自動獲得信任。
CoE 和 RAG 到底有什麼區別？
看到這裡，很多人可能會問：這不就是 RAG 加引用嗎？
不完全是。
RAG 主要解決模型去哪裡找外部知識？
CoE 主要解決模型生成的這個 Claim，如何被證明？
RAG：
Document → Retrieval → Answer
CoE：
Claim → Evidence → Artifact → Verification
RAG 可以給模型提供真實文件，也可以幫助答案附上引用，但它不天然保證：
- 引用真的支持目前 Claim；
- 論文中的數字來自實際執行結果；
- 方法描述和提交程式碼一致；
- 最終結論能沿著中間產物回溯。
因此 CoE 不是 RAG 的替代品。
它更像是加在 RAG、工具調用、程式碼執行和論文寫作之上的一層可信度基礎設施。
我對此的總結是，
RAG 解決資料從哪裡來。
CoE 繼續追問結論憑什麼成立。
寫在最後
過去幾年，我們一直在解決如何讓模型知道更多。
所以有了 RAG、Vector Database、Knowledge Graph 和更長的上下文。
現在 Agent 開始自己搜尋、寫程式碼、跑實驗、生成報告，新的瓶頸出現了：它不僅要給出結果，還要保留結果是如何產生的。
ScientistOne 和 Chain-of-Evidence 的價值，不是又造出了一個更會寫論文的 AI，而是把 AI 研究的評價標準往前推了一步。從結果像不像真的，走向結論能不能被驗證。
這可能也是 Agent 進入真實世界必須補上的一課。可信並不意味著它永遠正確，而是當它出錯時，我們能夠沿著證據找到問題；當它正確時，我們也不必只憑感覺相信。
真正值得信任的 Agent，不只是會給出答案，還要讓人隨時能夠檢查：它為什麼正確，又可能錯在哪裡。