我們用 SMART——Specific（具體）、Measurable（可衡量）、Achievable（可達成）、Relevant（具關聯）、Time-bound（有時限）——把每個故事拆成五天，作為每次動手造輪子前的五個檢查問題。

本篇是故事三「你的 I²C、SPI 我看不懂，先幫我包成 AT Command」的 Relevant 篇：這項工作與客戶價值、專案目標及交付有什麼關係？

本篇定位：檢查新增介面是否服務長期架構邊界，而不是短期個人偏好。

當時發生了什麼

轉接層交付後，感測器功能順利上線，我以為這事翻篇了。下一次規劃會議，那位資深工程師又把 AT Command 放回桌上，這次理由全面升級：「以後量產測試說不定用得到」、「客戶哪天可能想用終端機直接下指令」、「多一層彈性總是好的」。沒有一句再提「我看不懂」，聽起來完全像產品規劃了。

組長只問了一句：「除了你，還有誰會用它？」會議安靜了幾秒。負責產測的同事說，治具走既有測試介面，流程早定了；專案經理確認目前的規格書裡沒有任何序列埠整合需求，客戶要的整合介面在網路那一端。把使用者名單認真寫出來，上面只有提案人的名字。

真正的問題在哪裡

一層抽象值不值得存在，其實可以粗算。把它的生命週期成本攤開——設計、實作、測試、文件、除錯工具，加上往後每次改版都要回頭確認它沒被打破——再除以兩個分母：會用它的使用者數，與會重用它的產品線數。分母夠大，成本就被稀釋成合理投資；分母是一個人、一條產品線，這筆錢由團隊全額自己吞。通訊模組廠商養得起那層命令介面，靠的正是分母：一份介面服務數不清的整合者與機種。我們這層的分母，組長一句話當場就數完了。

分母之外還有一個更硬的條件：邊界要真的存在。我們這層的兩側是同一個版本庫裡的兩個資料夾、同一個團隊、同一份出貨映像檔。這裡沒有邊界，只有資料夾的分界。在沒有邊界的地方蓋邊界設施，不是架構，是布景。

再來是語意的耗損。暫存器語意先被驅動翻成型別明確的函式，這一步是增值——領域概念取代了位元欄位；再往上攤平成字串就開始折舊：型別壓扁成文字、錯誤結構壓成數字碼，使用端還得自己解析回來。資訊繞一圈回到原點，每站都可能出錯。「把所有東西包成我熟悉的形式」，真實代價是原系統的語意被一層層磨平。

最值得警惕的是理由的變形。第一次的「我看不懂」至少誠實，被駁回後進化成「以後可能有人需要」——「以後可能」是替抽象層辦簽證時最好用的話，因為它不可證偽。伴隨而來的是維護責任錯位：提案人在應用端，不會維護韌體裡的協定層；韌體團隊要供養一層自己用不到的介面。所以立項當下就得先答一個很不浪漫的問題——提案人哪天離開，這層由誰接手、誰決定該不該下架？答案不能是「到時候再說」，得落成做法：列進介面清單、指定接手團隊，約定每次發布前盤點一次實際使用者，連續幾輪沒人用就走下架流程。

可以怎麼做

Relevant 的檢查只有三題，但每題都得寫下來，也都要有卡得住人的門檻，否則會全答成「應該有吧」。

第一，具名使用者：今天誰要用、依據哪一份需求文件。門檻寫死——至少兩個獨立於提案人的具名使用者，提案人自己不算，「以後可能有人」也不算名字。

第二，邊界測試：介面兩側是否獨立演進。可執行的判準是兩側分屬不同交付單位、不同發布節奏或不同生命週期；永遠一起改版、一起出貨的兩端，配不上一套協定。

第三，維護簽名：文件、測試與版本由哪個團隊負責，寫進工作項目，連同那套盤點與下架程序一起簽。

三題都答得出來才有立項資格；答不出來就進待辦清單，掛上重啟評估的條件。這比當場否決體面，也比默默開工負責。

同時得給熟悉感一條正當的出路，因為學習成本是真的。那次會後我們補了一頁使用範例，也陪他把轉接層的用法從頭走過一遍。教學解決的是人不熟悉，架構解決的是系統有邊界；前者的成本付一次，後者的承諾要付到產品退役。把一個人的學習需求做成整個系統要背一輩子的功能，是這故事裡最安靜的浪費。

今天學到的事

「多一層彈性總是好的」是錯的：彈性不是介面天生的性質，而是一項要有人長期付費維護的功能。一層介面如果只為了讓某個人不必理解原本的系統，它不是產品架構，而是一位支薪到產品退役的私人翻譯。

檢驗方法出乎意料地樸素：把使用者的名字一個一個寫出來，再看那份名單撐不撐得起它的生命週期成本。寫得出具名使用者與穩定邊界的是架構；寫不出來的，是熟悉感的紀念碑。

那天的提案沒被永遠槍斃，是掛著條件進了待辦清單。這也帶出故事三的最後一個問題：那些「先這樣，之後再說」的暫時包裝——包括我們自己那層轉接層——「之後」到底是哪一天？