就算你跟過去寫程式的我一樣，對語意化版本避之唯恐不及，你大概還是會把開放原始碼軟體的發布想成是一套固定的流程。有一個分支專門用來開發，而這個分支往往還沒準備好讓人穩定使用。接著你會把開發凍結一段時間（即使在這段期間，新的開發工作仍可以在另一個不穩定的分支上繼續進行），修掉錯誤、請大家來測試。到了某個時間點，回報的錯誤開始變少，你的團隊和使用者也開始相信，接下來幾個星期內應該不會再輕易發現明顯的重大缺陷：這時你就把這個分支標為 2.4 或其他版本號，這樣就完成了。

然而現在，隨著 AI 寫程式的出現，改變的不只是開發本身，使用軟體這件事本身也受到了影響：不只是你能要求 AI 對軟體做出某些修改，拿到軟體的使用者本身也能這麼做。這一點在主要使用者就是程式設計師的軟體領域尤其明顯，但廣義來說也是如此，因為越來越多熟悉技術的使用者都已經能使用 AI 和寫程式代理人。

因為這樣的轉變，只維護一個精雕細琢的穩定分支、加上一個什麼都還在進行中的不穩定分支，這種想法或許已經不再是正確的做法。程式碼儲存庫可以是一個完成的產品，但如果把它當作圍繞某個特定問題該如何實作的範本，或許會更有用。使用者可能會為了特定需求、硬體或要解決的特定問題，去修改程式碼以符合自身情境。而對一般大眾來說太不穩定或未經驗證的東西，對另一群使用者而言，反而可能是恰到好處的選擇。

以 Redis 為例。過去幾個星期以來，我一直在反覆修改一個能為 sorted set 大幅節省記憶體的 PR。這份工作如果被接受，將會影響到每一位 Redis 使用者，從完全不了解 Redis 運作原理的人，到這些年來甚至曾貢獻過程式碼的使用者都有。涵蓋的情境從再瑣碎不過的用途，到那種能在 sorted set 上節省 50% 記憶體、等於每年直接省下一大筆雲端帳單的用途。對最後這類使用者而言，比起拿到經過所有測試與設計調整、打磨到「就是能用」程度的最終成品（而且還不一定真的會被合併進程式碼庫），從第一天起就拿到一個完成度 95% 的分支，或許還更有吸引力。那是他們可以測試、調整、反覆改進，甚至為手邊問題進一步特化的程式碼。

或許 DwarfStar 更能說明，為什麼程式碼儲存庫應該是好的範例，而不是試圖涵蓋功能矩陣中每一塊拼圖的完成品。以本地推論來說，就 DwarfStar 的情況而言，你會遇到各式各樣的 GPU、模型、伺服器模式、代理人模式、CLI、SSD 串流，以及張量與管線分散式執行。要在所有地方測試所有組合非常複雜。然而，只要你有兩個紮實的張量平行圖執行範例，夠強的寫程式代理人就能推論出如何為其他後端／模型組合實作同樣的功能。同樣地，一旦你有了一個能好好支援兩種模型的引擎，第三種模型的實作幾乎就能自動完成，只要把現有的程式碼庫當作寫程式代理人的護欄來引導實作即可。

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

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