每天早上打開的那個視窗，其實是一層包裝，裡面是一個開放的計畫。

計畫與成品之間隔著什麼

網址列、畫面呈現、開發者工具、分頁排列，在大多數現代瀏覽器上看起來都差不多，這份相似並非巧合。這些地基不屬於任何一家廠商，而是來自一個長年公開的計畫；成品的瀏覽器再往上疊自己的帳號、同步、更新機制與一批自訂功能。

Chromium 就是那個上游計畫。官方站把文書掛在「瀏覽器計畫」這樣樸素的名目下，並且刻意與成品劃清界線：這裡發布的是計畫與程式碼。介面的改動、引擎的改動、開發工具的改動都在公開處發生，所以在此看到的變化，過一陣子往往會出現在好幾款瀏覽器上。

維護由 Google 主導，建置產物與成品出自同一條流程，版本對應關係因此相當清楚。核心以寬鬆授權釋出，允許修改與再散布，這也是多款商業瀏覽器敢拿它當地基的重要原因。

為什麼建置產物要按用途分家

站上把產物按用途分類。面向日常使用的通道跑得快、變化頻繁；越往上游的通道越平静，改動越少。要挑哪一條，取決於這次是想長期相處，還是想提早驗證某一處改動。

另有一整族專供測試的組建，官方說法很直白：當你需要確認某個回報的問題真的修好了，就用這一族。修正一旦標記為已落地，拿對應的組建重現一次就能結案，比等正式版本出來再確認快得多。這類組建的行為與日常成品有差別，文書裡也明講了這一點。

對跑自動化測試的人來說，這個區分最要緊。測試環境要版本固定、行為可預期，而自動更新的通道恰好相反。按測試場景備好的組建正是為此而生，版本號與發布通道一一對應，跨平台對齊版本時也省事。

公開的不只有程式碼

除了程式碼，站上還把設計文書、架構說明與測試素材擺在同一處。這樣安排的用意是讓外部開發者讀到維護者當初的推理，而不是從差異檔反推意圖。對這種規模的計畫而言，這也是留住長期貢獻者的前提之一。

要記得的是，這裡的程式碼與文書一直在動，版號按提交推進，跟成品瀏覽器那種漂亮的大版本號不是一回事。當某一處行為真的要緊時，可靠的依據是對應的文書與變更紀錄，而不是從版號推測。

弄清楚上游在做什麼，是預判瀏覽器下一步會怎麼變的捷徑。

實務提醒：行為有變時先讀文書與變更紀錄，只看版號得不到答案；測試環境與日常瀏覽分開，免得自動更新的通道把結果弄歪；把計畫文書當成理解實作的入口，遇到成品與文書描述不一致的地方，先往這一層找原因。