AI 代理協作研究整數乘法：GitHub 的新界線，為何不能當成實際倍速？
整數乘法研究社群以 AI 代理協作探索理論界線，在 X 引起討論。本文說明條件式複雜度界線、GitHub 證據與人工審查，避免把指數改善寫成實際運算倍速。
AI 代理可以同時嘗試不同方向，研究社群也開始把這種分工用在數學問題。
整數乘法界線的 GitHub 專案，最近因密集的社群提案在 X 引起關注。
參與者描述使用 Codex 與 Claude 協助搜尋、計算與整理證據。
專案同時保留書面論證、有限檢查與條件假設。
這些更新是值得追蹤的研究工作，不能直接寫成所有電腦乘法已經加速。
理解它的關鍵，是分清理論界線與實際執行時間。
整數乘法研究，問的是規模變大時要做多少工作
兩個整數相乘看似簡單，但當數字非常長，演算法需要的工作量就成為理論問題。
複雜度界線描述的是輸入規模增大時，所需資源如何成長，而不是某臺電腦今天跑幾毫秒。
這個社群專案沿用 OpenAI 公開研究的框架，探索在特定計算模型與假設下，能否改進界線。
相關公式使用 κ 表示對對數指數的節省量。在這個形式中，κ 增大會降低該指數。
10 月 11 日查閱的主儲存庫已審結果，κ 約為 0.00072357159，比前一個已審結果的指數節省量提高約 1.90%。
這仍是帶有條件假設的理論參數，並不表示實際運算快了 1.90%，也不能混用未審候選的數字。
因此，社群說某個參數改善了幾倍，不代表日常乘法或任何程式同樣快了幾倍。
這個區分讓研究成果回到它真正回答的問題，也避免被誇大的速度描述帶偏。
多個代理，協助探索不同候選方法
參與者的 X 原文描述，以多個 Codex 與 Claude 代理平行測試不同策略。
GitHub 的提案則留下程式、參數、論證與審查紀錄，讓不同方向可以被比較與組合。
提案在這裡稱為 PR，是送到儲存庫供維護者查看的變更請求，提交不等於已被接受。
這種協作能增加搜尋與計算的嘗試數量，但也需要管理重複結果、錯誤與相互依賴。
代理產生一個漂亮候選，仍要有人檢查它是否使用了相同假設、是否漏算成本。
所以，平行化增加的是探索能力，證明責任並沒有因此消失。
通過有限檢查，和完整定理成立有不同範圍
專案 README 把目前結果放在條件式研究框架中，並說明審查與驗證的範圍。
有限檢查可以確認特定參數、電路或算術證書，但不會自動證明整個無限規模的演算法定理。
如果論證依賴上游研究成立，這個假設也需要保留，不能在摘要裡消失。
不同分支還可能保留先前結果與新候選，數字較大不一定表示已通過同等審查。
因此，閱讀時應先找「目前接受的結果」「候選狀態」與「依賴的假設」，再看排行榜。
這比從最新貼文挑一個數字更能理解研究真正走到哪裡。
GitHub 紀錄，讓協作有可以回看的證據
開放協作的價值，是讓別人能查看想法如何演變，而不只看到最終宣稱。
讀者可以從提案連回來源、證書與審查，分辨哪些改進已被採納、哪些仍待處理。
若某個候選被新方法取代，先前工作仍可能提供重要想法，不能只把功勞歸給最後一次提交。
這也提醒團隊，AI 協作研究需要清楚記錄人與模型各自做了什麼，以及哪些判斷仍由維護者確認。
想把類似方式用於自己的研究，應先準備可檢查的目標與判斷方法，再增加平行探索。
若沒有可靠的驗證，更多代理可能只會更快產生更多未證實的結論。
常見問題
這表示日常整數乘法已經大幅加速嗎？
不表示。本文討論的是特定假設下的理論界線，沒有對日常程式提供普遍實測倍速。
GitHub 測試全部通過，就能認定定理成立嗎？
不能。有限測試與算術檢查有自己的範圍，完整論證與上游假設仍需要審查。
這個專案由誰維護？
本文使用的主要儲存庫由 Douglas Colkitt 維護，包含多位社群貢獻者與 AI 協助，不把它歸為單一作者的全部成果。
結語
這個案例展示了 AI 代理與開放研究如何一起探索候選。保留假設、證據與審查狀態，才會讓快速協作累積成可以信任的知識。
延伸閱讀：OpenAI 公開 722 份 AI 數學稿件：372 組成果與 Lean 驗證怎麼看？
延伸閱讀：Meta Muse Spark 協作六篇數學論文：五項未解問題有了答案，AI 做了什麼？
