從 Blade 到 Raku:一個週六橫掃整個程式碼庫的改名

名字是一個承諾。Raku——輕鬆、舒適、人的溫度——是這個執行環境背後的承諾:讓 AI 體驗有人味,而不是機械感。這個週末,它成真了。

我開始打造這個執行環境時,它有一個名字。那個名字是占位用的,那種讓你不必再煩惱命名、可以開始寫程式碼的占位名稱。我挑它的時候就知道它是占位的。真正的名字在等幾件事情塵埃落定。

這個週末,占位名稱卸下了。這個執行環境現在叫 Raku。

為什麼是現在

三個理由。

產品目標穩定了。當執行環境還是 AR1+、然後是 AR2 Gen1、然後可能是三條不同硬體路線之一時,用裝置家族替它命名並不合理。現在 AR 轉向已經定案,引擎可以擁有自己的名字,而不必取決於它在哪台裝置上出貨。

合作夥伴對話正在變得認真。一場變得認真的合作對話,無法容忍程式碼庫裡的占位名稱。供應商不會和一份在某些檔案裡自稱「BladeRuntime」、在另一些檔案裡自稱「AR1+Runtime」的程式碼合作。改名是那些對話能夠再往前走的前提條件。

品牌必須有意義。Raku 在日文裡的意思是輕鬆、舒適、愉悅。它同時也是日本茶陶的一支傳統的名字,那個傳統看重的是不規則和人的手感,而不是機器的精準。這兩者都是關於這顆引擎為何而生的訊號:容易創作、而且讓人感覺有人味而非機械感的體驗。漢字「楽」出現在標誌裡。這個命名選擇不是隨意的。它是公司識別的第一塊。

品牌重塑涉及了什麼

一次橫掃整個程式碼庫的作業。兩個 PR 在背靠背的代理執行中落地了絕大部分。代理做了機械性的苦工,這很好,因為那些苦工的量非常龐大。大致上:

• 程式碼、文件和 CI 裡每一處「ar1-runtime」的引用改為「raku-runtime」
• 品牌和封裝裡每一處「Blade」的引用改為「Raku」
• 原生執行環境函式庫從 ar1plus 改名為 raku
• 所有匯出符號的前綴更新
• 所有 CMake 目標名稱更新
• 所有 include 路徑引用更新
• 所有文件交叉引用更新
• 所有範例應用的 readme 更新
• 標誌與品牌素材換新

兩個 PR。兩者合計大約碰了一百一十個檔案。兩個都在沒有弄壞建置的情況下落地,而那正是最重要的指標。

用這種方式做,我學到了什麼

三件事,對任何計畫在代理打造的程式碼庫裡做全面掃蕩的人都有用。

代理改名比我快,但前提是議題要精確。產出改名主體的那個議題,精確寫明了哪些符號要改、哪些路徑要改、哪些文件要改,以及哪些模式不要動(變更日誌條目、歷史決策紀錄、封存的分支)。代理照著指示做。結果是一次乾淨的改名。而我兩天前試過的那個版本的議題沒那麼精確,改名回來時有三十個地方被代理改得太過火,包括舊 commit 訊息裡那些基於考古目的本該保留的引用。

改名 PR 即使碰到所有東西,也要保持小。做這次改名的兩個 PR 並不低調。它們各自碰了幾十個檔案。它們的「小」,在於它們只做一件事。每個 PR 都是純改名,不混入任何功能變更。把改名和哪怕一個小小的功能變更混在一起,就會讓 PR 變得無法審查,因為人類審查者必須逐行閱讀,才能確定那個功能變更真的只是那個功能變更。純改名十五分鐘就能審完。

品牌必須在改名出貨之前就準備好。這個週末有一半的工作不在程式碼庫裡。而是在挑選新名字、註冊網域、搶下帳號、把漢字定對、設計標誌。程式碼庫的改名是最後一步,不是第一步。如果你先做了程式碼庫改名,然後才發現品牌還沒完成,你就得再來一輪改名。

什麼沒有變

架構沒有變。C API 沒有變。路線圖沒有變。產品目標沒有變。任何人在改名前的週末和改名後的週末閱讀這個程式碼庫,看到的都是同一顆引擎在做同樣的事。

這是正確的那種改名。是標籤的更換,不是方向的改變。

合作夥伴與開發者可以從中看到什麼

如果你是現在正在看這個執行環境的整合者:在我們的倉庫和封裝裡任何你看到「raku-runtime」的地方,那就是上個週末還叫別的名字的同一顆引擎。沒有相容性中斷。C API 沒有改變。SDK 綁定沒有改變。範例應用依然能跑。

如果你想在一個出貨於這顆引擎上的產品展開合作,名字現在穩定了。對話不必再以「我們暫時先這樣叫它,不過」開頭。它可以直接以「這就是 Raku,以及它為何而生」開頭。

如果你在一個 AR2 裝置團隊裡,正在考慮你的平台要瞄準哪個執行環境,這次改名同時也是關於這顆引擎在市場上定位的宣示。Raku 不是「長大了的 AR1+ 執行環境」。它是它自己,有自己的論點,願意在最合適的硬體夥伴上出貨。改名是那份宣示的一部分。

一個安靜的週末——安靜在於沒有任何功能上的改變。正確的那種安靜。