即使你和我過去寫程式時一樣排斥 semver(語意化版本)，你仍可以把開源軟體的發布想成曾經遵循固定幾個步驟的過程。會有一個進行開發的分支，而這個分支往往還沒準備好讓人穩定使用。接著你會把開發凍結一段時間（即使在此期間，工作仍可在另一個新的不穩定分支上繼續），修復錯誤，請大家來測試。在某個時間點，回報的錯誤數量開始下降，你的團隊與使用者開始相信，在未來幾週內已經沒有明顯、容易被發現的重大缺陷：這時你就會把這個分支稱為 2.4 或其他版本號，然後就此定版。

然而現在，有了 AI coding(AI 寫程式)，改變的不只是開發本身，使用軟體這件事本身也受到了影響：不只是你能要求 AI 對軟體做某些修改，軟體的接收者本身也能這麼做。這在主要使用者是程式設計師的軟體領域中尤其明顯，但更廣泛來說也是如此，因為愈來愈多具備技術傾向的使用者都能使用 AI 與 coding agents(寫程式代理)。

正因為有了這樣的變化，僅僅擁有一條經過打磨、包羅萬象的穩定分支，以及一條所有功能都還在進行中的不穩定分支的想法，可能已不再是正確的做法。程式碼儲存庫也可以是一個完成的產品，但如果它是圍繞某個特定問題、示範如何處理事情的樣板，或許會更有用。也許使用者會為了針對特定的需求、硬體或要解決的特定問題進行特化而修改程式碼。而且，對一般大眾而言過於不穩定或未經證實的東西，對另一群使用者來說卻可能是正好需要的。

以 Redis 為例。數週以來，我一直在反覆改進一個能為有序集合帶來大幅記憶體節省的 PR。這個工作如果被接受，將會影響到每一位 Redis 使用者，從完全不了解 Redis 運作方式的人，到這些年來甚至曾貢獻過程式碼的使用者都有。從微不足道的使用情境，到在有序集合上節省 50% 記憶體就能每年省下大筆雲端費用的使用情境皆是如此。對於最後這類使用者而言，擁有最終產品（在經過我為了打磨出「就是能用」的成果而進行的所有測試與設計變更之後，還得冒著它或許根本不會被合併進程式碼庫的風險）可能還不如從一開始就拿到一個完成度 95% 的分支來得有吸引力。那是他們可以測試、調整、反覆改良，甚至針對手邊問題進一步特化的程式碼。

或許 DwarfStar 更能說明程式碼儲存庫應該更像是好的範例，而非涵蓋功能矩陣每一塊拼圖的完成品。以 local inference(本地推論)來說，就 DwarfStar 這個特例而言，就有許多種類的 GPU、模型、伺服器模式、代理模式、CLI、SSD streaming(SSD 串流)、tensor and pipeline distributed execution(張量與管線分散式執行)。要在所有地方測試所有組合是非常複雜的。然而，只要有了兩個穩固的 tensor parallel graph execution(張量平行圖執行)範例，強大的 coding agent 就能推斷出如何為其他後端／模型組合實作同樣的功能。同樣地，只要引擎已經夠完整地支援兩種模型，第三種模型就能以近乎自動化的方式來實作，利用現有的程式碼庫作為 coding agents 的護欄來引導實作。

這並不代表像 DwarfStar 這樣的專案就不需要開箱即用，而是它可以專注於把一組功能支援得非常好，讓這些功能可以被外推到更多使用者能自行涵蓋的情境中。這也意味著另一件事：只有 main 與 unstable 已經不夠了。許多實驗性分支可能會成為專案不可或缺的一部分。舉例來說，昨天 Laguna S.1 模型發布了。從紙面上看起來很有意思，不過：它真的夠好嗎？新的 DeepSeek v4 Flash checkpoints(檢查點)會不會讓它對 DwarfStar 來說變得不再那麼重要？現在還很難說。然而，為了共同形成一個看法，發布一個包含此模型實作的分支是個不錯的折衷：大家會去嘗試，會用他們的 coding agents 去改良，社群也能共同形成對其是否值得合併的判斷。此外，今天我注意到，多虧了 DwarfStar 內部程式碼語料庫所形成的軌道，這個實作由 GPT 5.6 Sol 在約兩小時內就自動完成了。實作 DS4 與 GLM5.2 時，我花了大量心力去引導、閱讀模型卡與那些模型注意力機制實作的細節。現在卻直接就成功了。GPT 5.6 固然更強大，但它也在現有的原始碼中找到了大量優質的範例。

如今的軟體比以往任何時候都更具可塑性。在某種程度上，這意味著它可以用更流動的方式發布。同時，這也意味著文件本身不該只是寫給人看的，也要讓 coding agents 能夠理解如何修改系統。究竟會如何演變，以及在穩定性、可用性與功能這幾個維度之間，平衡點究竟會落在哪裡，我目前還不清楚，但我相信我們開發者需要睜大眼睛，看清楚這一切將走向何方。