2026 年 9 月 8 日，OpenAI 公開一份 Navier–Stokes existence and smoothness problem 的解答，主張一個仍在訓練、能力明顯高於 GPT-6 Astra 的內部模型，透過大規模代理系統找到了有限時間奇異點的構造。這件事目前還不能簡化成「AI 已經正式解開千禧年難題」：OpenAI 已經公開論文與 Lean 形式化證明，Clay Mathematics Institute 也在 9 月 12 日以「apparently been settled」形容目前的進展，但正式的數學審查、成果歸屬與獎項程序都還沒有結束。Clay 現行規則本來就要求候選解答先在合格出版管道發表，至少經過兩年，並取得全球數學界普遍接受後，才進入獎項評估。換句話說，目前比較準確的描述是：AI 系統已經產出一份足以讓數學界認真進入驗證程序的候選解答，而且速度快得有點離譜。

這件事真正值得一般 AI 使用者注意的地方，其實不是 Navier–Stokes 方程式本身。過去幾年使用生成式 AI，最常討論的是回答準不準、文章寫得好不好、模型會不會 hallucination；這次直接把問題往前推了一大截。當一套 AI 系統可以在幾天內產出過去需要以年為單位累積的研究成果，人類接下來遇到的麻煩，很可能不是沒有東西可以交，而是東西交得太快，根本來不及確認每一份到底能不能信。這個落差在數學裡特別顯眼，因為至少還有形式化證明工具可以幫忙檢查；換成研究摘要、商業策略、簡報、行銷分析或公司內部決策，很多工作連這一層都沒有。

這次真正改變研究方式的，是 1 萬個代理同時找答案

OpenAI 公布的流程並不是「把 Navier–Stokes 丟給一個超級模型，88 小時後模型吐出答案」。9 月 1 日開始的實驗原本同時攻擊多個尚未解決的千禧年難題，代理被拆成不同群組，分別探索不同方向，也另外處理一些相對簡化的相關問題。其中接近 100 個代理先花約 50 小時得到三維 Euler 方程式無外力版本的有限時間爆破解答，OpenAI 隨後判斷 Navier–Stokes 是最有希望繼續推進的方向，才把其他任務的資源移過來，並把 Euler 的成果交給後續代理當作素材。不同群組各自探索一段時間後，OpenAI 再利用 Codex 整理各組最有用的中間結果，重新餵回後續研究。最後找到 Navier–Stokes 解答的群組，規模大約是一萬個同時運作的代理。

從第一批代理啟動算起，大約 88 小時後，系統在 9 月 5 日得到解答；接著又由 GPT-6 Astra 花約 17 小時完成 Lean 形式化與驗證。單就 Navier–Stokes 這條研究線，代理之間總共交換約 270 萬則訊息，產生約 1,300 億個 output token；把同期嘗試的其他問題一起算進去，則是 490 萬則訊息與約 3,000 億個 output token。這組數字也修正了一個很容易出現的誤會：AI 研究並不是已經便宜到可以忽略成本。這次的做法非常吃算力，只是它把大量搜尋路線壓縮到同一段牆鐘時間裡。以前可能由不同研究者分散幾年摸索的方向，現在可以同時開幾千條路試，失敗的丟掉，有東西的再互相合併。

所以真正出現變化的，不只是模型推理能力，而是研究的基本單位。傳統使用 ChatGPT 的方式比較像一條線：提出問題、得到回答、追問、修改，再往下一步走。這次更接近大規模搜尋系統，同一時間讓大量代理各自推不同假設，再把有效結果重新組合。對一般工作來說當然不需要一萬個代理，但同樣的邏輯已經可以縮小使用：複雜決策不一定要逼一個對話一路想到最後，反而可以分成不同假設、資料來源與反方路線並行處理，最後再做交叉檢查。

OpenAI 到底證明了什麼？不是「所有流體一定會爆掉」

Navier–Stokes 方程式源自十九世紀 Claude-Louis Navier 與 George Gabriel Stokes 的研究，用來描述水、空氣等流體的運動。Jean Leray 在 1934 年已經證明某種廣義解可以存在，長期留下來的問題則是：三維不可壓縮流體從平滑狀態開始之後，解會不會永遠保持平滑，還是可能在有限時間內產生奇異點。Clay Mathematics Institute 在 2000 年把這個問題列入七個千禧年難題之一。

這裡有一個很容易被新聞標題省略的細節。Clay 的正式題目其實列了 A、B、C、D 四種可以成立的方向，證明其中一個就足以處理正式的 Millennium Problem。A、B 處理的是沒有外力時，解是否能永遠保持平滑；C、D 則允許加入符合條件的平滑外力，要求構造出會在有限時間失去平滑性的反例。OpenAI 這次主張完成的是 C 與 D：流體一開始完全靜止，施加的外力保持平滑，整個過程的能量也維持有限，但速度仍能在有限時間內變得無界，也就是形成奇異點。這不是靠塞進一個無限大的外力把答案硬做出來，難點正好在於外力本身必須保持正常，奇異性卻由方程式內部的動態逐漸形成。

因此，「OpenAI 只解了 forced case，所以沒有碰到真正的 Clay 題目」這種說法並不準確，因為 C、D 本來就在 Clay 的官方問題定義裡；但另一個方向也要講清楚：沒有外力的 A、B 並沒有因此被解決。就算目前公布的 C、D 最後完全成立，數學上仍然可以繼續問，在沒有外力介入的三維 Navier–Stokes 裡，到底會不會出現有限時間爆破。這兩件事可以同時成立，不需要硬選一邊。

Lean 很重要，但它不是「按下執行就宣布數學結案」

OpenAI 同時公開 Lean 4 的形式化證明與 GitHub repository，這是整件事裡非常實際的一步。公開 repository 的 metadata 顯示主要 Navier–Stokes 定理沒有留下 sorry，列出的公理是 Lean／Mathlib 常見的 propext、Classical.choice與 Quot.sound；專案也加入 Comparator challenges，把自己的定理陳述拿去與來自 Formal Conjectures 的獨立 Navier–Stokes 形式化陳述比較。其他研究者可以把 repository 抓下來重新 build，而不是只能面對一份一百多頁的 PDF 從頭人工檢查。

不過，Lean 解決的是「形式系統裡的這串推導有沒有成立」，不是一次包辦所有學術驗證。仍然需要確認形式化的定義是否忠實對應紙本論文、形式化定理是否真的對應 Clay 要求的 C／D、使用的假設有沒有被正確轉譯，以及論文對數學意義與原創性的說明是否站得住腳。OpenAI 自己放在 formalization.yaml 裡的 review status 目前也是 self-assessed，所以比較好的理解方式，是 Lean 把原本非常難人工檢查的一大部分工作變成可重跑的機器檢查，但沒有讓獨立審查消失。

這個差別對一般知識工作其實很重要。AI 產生的東西能不能驗證，最好拆成不同層次看：格式有沒有符合要求是一層、資料是不是出自原始來源是一層、推論有沒有跳步又是另一層，最後才是結論在實際情境裡能不能成立。只寫一句「已驗證」很容易把這些不同事情混在一起。

學術圈真正爭論的，是研究速度突然超過原本的合作規則

OpenAI 也沒有隱瞞為什麼會在 9 月 1 日突然把大量資源投入這些題目。官方說法是，當時聽到有人可能已經解決兩個 Millennium Problems 的傳聞，因此決定讓新的內部模型大規模測試所有仍未解決的千禧年問題。後來才知道，傳聞與 NYU 數學家 Tristan Buckmaster 及 Anthropic 的 Levent Alpöge 有關；兩人當時正在研究與流體爆破相關、但不同的 forced Euler 問題。這也讓原本單純的 AI 數學成果，迅速變成優先權、作者署名與研究資料使用方式的爭議。

Buckmaster 公開的時間線指出，他和 Alpöge 已經在這條研究方向工作相當長一段時間，背後的方法又建立在 Diego Córdoba、Luis Martínez-Zoroa 等數學家的既有研究上。他也直接承認，AI 讓他們的研究速度大幅增加，但生成的內容並不代表可以直接發表，其中一份 Euler 論文甚至被他自己形容成「AI slop」，並為倉促的呈現品質道歉。這個細節比「AI 寫的論文很厲害」更有參考價值：生成速度先上來之後，整理、理解、查錯與把內容寫到其他專家能真正閱讀的程度，工作量並沒有一起消失。

至於 OpenAI 是否使用到 Buckmaster 未公開的 Codex 內容，目前不能直接下結論。OpenAI 在 9 月 10 日更新官方說明，表示經調查後確認，Buckmaster 在公告前兩個月的 Codex prompts 不可能影響這次系統，包括透過模型訓練；OpenAI 也表示兩邊的 Euler 證明不同，Buckmaster 與 Alpöge處理的是有外力版本，OpenAI 則另外得到無外力 Euler 的結果。這並沒有讓優先權與作者歸屬爭議自動消失，但至少把「OpenAI 已被證實使用對方私人研究」這種說法排除在目前可確認的事實之外。

European Mathematical Society 在 9 月 10 日的公開聲明也沒有只討論證明對錯，而是直接把問題拉到人機合作、作者身份、研究信用與研究工具取得是否公平。Terence Tao 這幾天談得更直接，他擔心當一個「有人正在研究某題」的傳聞就足以引來龐大的 AI 算力，研究者未來反而會降低公開分享尚未成熟研究方向的意願。這類問題以前不是不存在，只是 AI 把搶先完成成果所需要的時間突然壓短之後，原本靠慣例與互信維持的合作方式開始承受新的壓力。

Clay 沒有「跟不上」，它現在的慢反而有必要

原本很容易把 Clay 的等待程序理解成「制度落後於技術」，但查過規則後，這樣寫其實不太公平。Clay 要求合格出版、至少兩年的等待期，以及全球數學社群的普遍接受，本來就是刻意把速度壓下來。9 月 12 日的公告也用了相當保守的文字，只說 Navier–Stokes 問題「apparently been settled」，同時表示正確性與成果歸屬的評估程序會刻意保持不急。

在 AI 已經可以把候選答案大量往前推的情況下，這種慢不一定是效率問題。反而可能變成必要的安全閥。過去人類研究慢，產出與審查的速度差距還有限；現在生成系統可以同時探索幾千條路，審查者卻還是一篇一篇讀、一道一道重跑。真正可能出問題的地方，是後面的驗證能力沒有同步擴張，而不是審查者突然變慢。

對知識工作者來說，現在比較需要補的是驗證工作流

這次事件不能直接推論所有工作都要改成一萬個 AI 代理，也不能說產出的邊際成本已經接近零。OpenAI 自己公開的算力規模正好說明相反的事：高階 AI 搜尋仍然可以非常昂貴。比較確定的變化，是同一段時間裡可以產生的候選答案、假設、草稿與分析路線快速增加，而人類能消化與確認的量沒有跟著同倍率成長。

數學至少有 Lean。軟體還有單元測試、整合測試、型別系統與 CI。資料分析可以檢查公式、重新執行查詢、比對原始資料。麻煩的是策略簡報、競品研究、市場分析、內容文章與會議摘要這些工作，它們很容易產生「看起來沒有問題」的成品，卻沒有一個可以按下去就告訴使用者哪裡錯的 checker。這也是日常 AI 工作流比較需要處理的地方。

把驗證層加進日常 AI 工作，可以先做這五件事

1. 生成之前先寫驗收條件。 複雜任務開始前先定義什麼情況才算完成，例如所有數字必須能追回原始來源、涉及日期的資訊必須確認更新時間、重要推論至少要有一條反方檢查、無法確認的內容不能改寫成肯定句。這一步看起來多花幾分鐘，實際上是在避免後面拿著一份漂亮的答案重新猜「到底哪裡需要查」。
2. 重要問題不要只跑一條路。 同一個問題可以拆成資料查找、反例搜尋、支持論點與反對論點幾條線平行處理，再比較它們在哪裡互相衝突。這不需要一萬個代理，三到五條獨立路線通常已經會看到不少差異。真正該優先檢查的地方，往往就是不同路線無法得到同一個答案的位置。
3. 來源資料庫不要只存網址。 Notion 或其他知識庫至少可以記錄「主張、原始來源、發布日期、擷取日期、驗證狀態、是否有其他來源支持、最後一次複查時間」。如果一條結論半年後又被拿出來使用，先看最後驗證時間，比重新相信當初的 AI 摘要安全很多。尤其 AI、法規、價格與產品功能這類變動快的資訊，更需要這個欄位。
4. 把能自動驗證的部分真的自動化。 數字可以寫 assertion，程式可以跑測試，表格可以做 reconciliation，文章裡的 URL 可以檢查是否失效，引用可以確認日期與來源，結構化資料也可以做 schema validation。不是所有內容都能像 Lean 一樣形式化，但只要能把其中 20% 到 30% 變成機器可以自動判斷的條件，人工審查就少掉一大批低價值工作。
5. 高風險內容保留最後一道人工簽核。 金額、合約、法律、醫療、公開聲明、研究結論與會影響公司決策的數據，不適合因為 AI 已經做完前面 95% 就順手把最後 5% 也自動發布。真正需要人工確認的內容可以變少，但最好明確留下這個狀態，而不是讓工作流在沒有人注意的情況下直接從「生成完成」跳到「對外發布」。

Navier–Stokes 這次最值得帶回日常工作的，其實很務實。AI 已經可以把「先產一個可能答案」這件事做得非常快，甚至快到研究制度開始需要重新思考怎麼分配注意力；但一份答案從「生成完成」變成「可以相信」，中間還是有很長的一段工作。OpenAI 自己最後也選擇把論文、Lean repository 和可以重跑的形式化成果一起公開，而不是只發一篇新聞稿宣布模型成功。

日常使用 AI 也可以往同一個方向走。重要結果旁邊留下來源，能測的東西直接測，不能測的地方標明誰確認過、什麼時候確認過。生成能力接下來還會繼續往上走，工作流如果只有「產出」而沒有「驗證」這一步，最容易發生的不是沒有內容可用，而是錯的東西也一起被做得更快。

常見FAQs

SUPPORT FENGNIII

喜歡這篇文章嗎？

如果這篇內容對你有幫助，可以透過小額贊助支持本站持續整理更多日文、韓文、旅行與數位工具內容。

小額支持本站

付款將由藍新金流安全處理