系列: 與 AI 一起學寫程式

在晶片到貨之前驗證硬體

在 AR2 Gen1 晶片到貨之前就建好的驗證測試框架。

驗證你還沒拿到的硬體 從 AR1+ 到 AR2 Gen1——晶片出貨前測試框架已全綠 模擬軌跡AR1+ 時代 + 規格書 驗證測試框架(在 CI 中) 熱 + 電源 Wi-Fi 7 穩定性 感測器啟動 CI 冒煙測試 + 指標 藏在功能旗標後面——AR1+ 路徑依然全綠 AR2 Gen1 晶片還沒放上桌面 在零件出貨之前,就抓出介面漂移、缺少的匯出、壞掉的感測器流程 77 個 commit,獻給一台我還摸不到的裝置
沒有裝置的測試框架仍然是測試框架——而撰寫它的過程,會逼著規格書變成具體的數字。

等待晶片的傳統答案是坐著乾等。現代的答案是先把硬體下游的一切都建好,在零件到貨之前就讓它們全部變綠——這樣你的硬體就能在 RakuAI 上比競爭對手更快出貨。

一個我在工作週裡反覆咀嚼的決定,在週末開始時已經等在廚房餐桌上了。把產品目標從 AR1+ 轉向 AR2 Gen1。在晶片到貨之前,把新規格下游的一切都建好,這樣當晶片真的到貨時,驗證從第一天就開始,而不是第九十天。

每一個硬體產品都會經歷這樣一個階段:規格書存在、驗證計畫存在、測試框架存在,而實際的晶片不存在。傳統的答案是坐著乾等。現代的答案是先把硬體下游的一切都建好,並在零件出貨之前讓它們全部變綠。

這個週末就是這樣。目標平台正式從 AR1+ 轉向 AR2 Gen1,而工程上的回應是在我們任何人碰到新平台之前,立刻把新平台將會需要的驗證基礎設施建起來。

落地了什麼

五件事,全部在這個週末落地:

  • AR2 Gen1 裝置啟動與感測器整合基礎設施
  • Wi-Fi 7 連線與追蹤穩定性測試套件
  • 熱與電源驗證框架
  • 帶有指標分析與報告的 CI 冒煙測試
  • AR2 Gen1 硬體驗證文件與量產標準規格書

全部都由功能旗標把關,讓 AR1+ 的程式路徑依然運作,現有執行環境中沒有任何東西倒退。落地這些 PR 的代理把枯燥的紀律做對了:每個新檔案都藏在建置旗標後面,每個 API 新增都不破壞相容性,每個測試都在 CI 裡執行,即使沒有 AR2 裝置可以對著跑。測試用模擬來跑。模擬的品質足以抓出介面漂移、缺少的匯出,以及壞掉的感測器流程。

這是一個 77 個 commit 的週末。那些 commit 大多數是獻給一台我還摸不到的裝置。

為什麼這樣做是合理的

有幾個理由。

跟著硬體一起出貨的硬體驗證,就是晚了六個月才落地的硬體驗證。這個週末寫好的熱與電源框架,會在第一台 AR2 開發套件抵達我桌上的那一天就派上用場,而不是三個月之後。這個平台的第一個熱回歸問題,會被一個已經存在的測試抓到,而不是靠某個人注意到裝置在發燙。

沒有裝置的測試框架仍然是測試框架。它對著模擬的感測器軌跡運行。那些軌跡來自 AR1+ 時代和規格書。它們並不完美。它們能抓出介面錯誤、整合錯誤、指標收集錯誤。它們抓不到只有在真實晶片上才會出現的錯誤。這沒關係。它們抓得到的錯誤,正是我們原本會在真實硬體時間的第一週花在追捕上的那些錯誤,而現在我們不必了。

撰寫測試框架的過程會讓規格書變得清晰。在週日晚上落地的量產標準文件裡,有一半在週末開始時只是模糊的意圖。撰寫驗證測試逼著規格書變成具體的數字。畫格預算。熱包絡。Wi-Fi 7 穩定性門檻。是測試框架讓文件變得銳利。那才是真正的交付物。

代理如何處理這次轉向

從 AR1+ 到 AR2 Gen1 的轉向,第一次並沒有處理得乾淨。週末進行到一半時,代理落地了一個 PR,在新程式路徑應該寫「AR2」的地方引用了「AR1+」。它之所以落地,是因為議題的描述沒有標出這次改名。修正是一個獨立的 PR,標題是「Fix AR1+ vs AR2 device discrepancy in documentation and copilot instructions」,它掃過 121 處各自獨立的引用,把它們統一起來。

這種事在單一人類撰寫所有程式碼時不會發生,因為那個人會邊寫邊改名。它會發生在代理驅動的工作流程裡,當代理接手一個早於改名的議題,並忠實地寫下舊名稱。補救方法是讓代理讀取作為輸入的文件與當下的現實完全同步,並把改名 PR 當成獨立的工作來寫。

我正在打造一個系統,讓代理的文件同時也是團隊的文件。當文件說謊時,代理會朝同一個方向說謊。這是我想做對的工作流程特性,不是缺陷。

具體來說,Wi-Fi 7 測試套件

這是這個週末最讓我自豪的一項。

AR2 Gen1 規格假設用 Wi-Fi 7 連線來做卸載渲染與有線運算。實務上 Wi-Fi 7 不如 Wi-Fi 6E 穩定,而且失效模式不一樣。這個週末寫好的測試套件刻畫了整組失效模式(吞吐量下降、間歇性丟失、重新認證風暴),並為執行環境在每一種情況下的行為劃定邊界。執行環境無法容忍每一種失效。測試套件的工作,是明確指出執行環境在哪些失效下優雅降級、在哪些失效下大聲失敗。

這很重要,因為使用者正在體驗的 AR 不能在連線閃斷時卡頓。執行環境必須退回本地渲染一個畫格、或兩個、或二十個,取決於閃斷的持續時間,並在連線恢復時重新收斂。這套邏輯原本只以模糊意圖的形式存在於規格書裡。過了這個週末,它以測試案例的形式存在。

我希望合作夥伴從中看到什麼

兩件事。

如果你是正在考慮 AR 眼鏡的硬體夥伴,這顆引擎隨附的驗證框架,將會是它能在你的硬體上比競爭對手更快出貨的原因之一。這個框架是可移植的。新增一個裝置目標只需要幾百行程式碼,加上裝置專屬的測試向量。昂貴的部分已經先付清了。

如果你是正在考慮延遲敏感的裝置端推論的 AI 實驗室,AR2 Gen1 規格假設的延遲預算已經公開。從感測器到渲染的端對端追蹤正在埋設儀測,所以當你的模型必須塞進那個預算時,你可以看到實際上還剩多少預算留給推論。那就是我想在十一月和你進行的對話。

一個週末 77 個 commit。以文件收尾,這是正確的週末收尾方式。

在一個為你的晶片準備就緒的執行環境上出貨

可移植的驗證框架意味著新增一個裝置目標只需要幾百行程式碼加上測試向量——昂貴的部分已經先付清了。帶著你的硬體來吧。

← 所有文章