訊息稱 OpenAI 自研 GitHub 替代品：專為 AI 智慧體定製程式碼平臺

就算是最親密的商業盟友，只要對方的伺服器一掛，這層關係立刻就會變得微妙起來。

據 The Information 報道，OpenAI 目前正在內部秘密開發一套程式碼託管系統，作為微軟旗下 GitHub 的替代方案。知情人士透露，這個專案還處於早期階段，距離完工至少還有數月時間。促使 OpenAI 下決心自起爐灶的直接導火索，是 GitHub 最近幾次嚴重的服務中斷。更耐人尋味的是，OpenAI 內部已經在討論，等這套系統在內部跑順之後，考慮向外部客戶開放。

宕機成了導火索，但根子在智慧體

對普通開發者來說，GitHub 宕機可能只是少提交幾次程式碼、摸一會兒魚。但對 OpenAI 這種把海量自動化流程掛在上面的團隊而言，程式碼庫停擺意味著整個研發流水線瞬間癱瘓。

程式碼倉庫從來不只是存程式碼的硬碟。這裡掌管著許可權分配、審計追蹤、持續整合和部署，以及每一次 Pull Request 的人工評審。一旦底層的管道斷了，研發效率會呈斷崖式下跌。

不過，避開別家服務的宕機風險只是表面原因。OpenAI 真正盤算的，很可能是為自家正在成型的 AI 智慧體造一個專屬工作臺。

把程式碼、沙盒與智慧體裝進同一個黑盒

現在的開發模式正在從「AI 幫你補全一行程式碼」，迅速轉向「AI 智慧體直接接單幹活」。比如 OpenAI 此前公佈的 Codex，就是一個雲端軟體工程智慧體，能在隔離的沙盒裡同時跑多個任務、修 Bug、甚至主動發起程式碼合併請求。

問題在於，現有的開發工具鏈全都是為人類設計的。模型執行在一家平臺，程式碼存在微軟 GitHub，測試環境又在另一處，智慧體在各個系統之間來回跳轉，到處都是摩擦和延遲。

如果 OpenAI 擁有自己的程式碼庫，局面就完全變了。從智慧體能訪問哪些許可權、程式碼在哪個安全沙盒裡執行，到依賴包怎麼裝、日誌如何留痕合規，全部都能原生打通。把智慧體、程式碼和審查閉環鎖在同一個系統裡，跑起來自然比到處調介面快得多，也更安全。

為什麼重要

我們認為，OpenAI 這一步走得極其敏銳，但也充滿了危險的火藥味。

對開發者和技術團隊來說，短期內誰也不可能把主力倉庫直接從 GitHub 遷走。程式碼庫的遷移成本極其痛苦，企業的合規審計、身份許可權以及現有的 DevOps 生態有著極強的慣性。但對於那些正準備把日常瑣碎編碼完全交給 AI agent 的團隊，一套從第一天起就原生為智慧體設計的程式碼平臺，誘惑力絕對不小。

對行業而言，這直接戳到了微軟的核心腹地。微軟持有 OpenAI 大量股份，把 GitHub 視作開發者生態裡最重要的一塊護城河。如今 OpenAI 打算自研程式碼庫甚至對外賣服務，無異於直接在關鍵基礎設施上跟大金主搶飯碗。這必然會倒逼 GitHub 加速把自身架構重構成「智慧體優先」，否則很可能會被自家的技術夥伴掏空壁壘。

看起來，山姆·奧特曼團隊的野心正越來越不受盟友框架的約束。只要關鍵生命線受制於人，無論是底層算力晶片還是日常用的開發倉庫，OpenAI 遲早都要握在自己手裡。只是這一次，兩家巨頭表面上的溫情脈脈，恐怕又被撕開了一道清晰的裂痕。