一顆按鈕先被現編了出來：AI 生成的組件，是一套沒被設計完的庫存介面

（話題背景：掘金作者「秋天的一陣風」於 2026 年 9 月 17 日發文，討論 AI 寫程式碼越快、專案組件越亂的治理方案。）

先從一個具體畫面看起。你讓 AI 寫一顆提交按鈕，它幾秒鐘交出一個元件；隔壁同事讓它寫「儲存並提交」，它又交出另一個。兩顆按鈕長得幾乎一樣，同樣的圓角、同樣的留白，只有檔名和入參不同。等程式碼進了 PR，評審才發現：又重複了。

這是那篇文章的核心場景，也是一個很典型的設計問題。AI 產出的是視覺上幾乎相同的兩個物件，但在系統層面上，它們是兩份獨立的實作。問題不出在按鈕本身的形、色、材，而出在專案沒有一套讓 AI 讀得懂的「庫存介面」。

臨時工看不見倉庫

文章把 AI 比喻成一個能力很強、但完全不了解你專案的臨時工。這個比喻在設計上很精確。AI 不知道專案裡已經有封裝好的 SubmitAction，不知道配色、圓角、間距都該走統一的 CSS 變數，因為這些約定從來沒有被整理成一種它可以載入的格式。

設計系統的原始承諾，是把視覺決策集中管理：一組 token、一份元件清單、一套文檔。但這套承諾長期以來是寫給人看的。設計師翻 Figma，工程師翻 Storybook，靠的是人的主動查閱。AI 上場之後，這套以人為讀者的介面突然失效了，因為 AI 在呼叫寫檔工具之前，不會主動去逛元件目錄。

文章點出三個痛點：AI 看不見存量、預設新寫、事後補救太貴。對應到介面設計的語言，就是輸入端缺少上下文、預設行為走了最省事的路、錯誤回饋來得太晚。這三件事任何一件單獨看都不嚴重，疊在一起就讓業務目錄堆滿同質化元件，等到要全域換主題色或統一互動邏輯時，維護成本直接失控。

關鍵字搜尋為什麼攔不住換皮組件

很多人第一反應是用 IDE 全域搜尋，輸入 Button 看看有沒有現成的。文章指出這只能攔住「長得一模一樣」的程式碼。真正麻煩的是換皮、異形、同源的隱性重複。

文章舉了幾種漏檢場景。命名體系分裂：舊元件叫 FfBtn，新元件統一叫 ActionTrigger，關鍵字對不上。實作形態不同：同樣功能的元件，一個用 Vue 單檔寫，一個用 render 函式工廠寫，文字差異巨大。還有 DOM 結構不同但職責一致：一個用原生 button，一個用帶按鈕角色的 div，語義結構相異，業務功能完全重合。

這其實和視覺設計裡的「近似」判斷是同一回事。兩個畫面擺在一起，人眼一眼就看出佈局雷同，但如果只比對像素座標，可能因為一個用 padding、一個用 margin 而判定不同。表面文字的比對抓不住結構層的同源，這正是文章主張用 AST 結構指紋與向量檢索做近似匹配的理由：比對的對象應該是結構，不是字串。

這個思路和我們先前討論過的Java 切面編程的程式碼排版設計有相近的底層邏輯：把散落各處的重複，收攏到一個可以被統一審視的層次。差別在於 AOP 是在程式執行層做橫切，這裡是在生成與合入的流程層做攔截。

生成之前，先把庫存排好

文章給出的治理方案，核心是把約定從「給人看的文檔」改造成「給機器讀的清單」。具體做法是寫一支腳本自動掃描元件目錄，把名稱、路徑、props、用到的全域樣式變數全部解析出來，生成一份標準 JSON 庫存。配套的措施是在 AI 呼叫寫檔、改檔工具之前強制載入這份清單，無論鉤子叫 PreToolUse 還是 before_submit，精神都一樣：前置攔截，把存量約束塞進上下文。

從設計的角度看，這一步做的事情和一家品牌整理視覺規範沒有本質差異。元件卡上記錄的 props 對應規範裡的使用情境，tokensUsed 欄位對應規範裡的色彩與間距 token。差別在於格式：給人看的規範可以靠範例與敘事，給機器讀的規範必須是確定性的結構化資料。

文章還強調事後補救的成本結構：程式碼已經落盤、進了 diff，再回頭做複用優化，AI 生成的成本白花，還得搭上人工清理與重構的時間。所以治理重心放在生成前與 CI 階段，而不是等 PR 評審才靠人眼發現。這和Shopify Helix 遷移系統的 checkpoint 設計分享同一個原則：把驗收點前移，讓問題在便宜的位置被攔下，而不是在昂貴的位置被發現。

設計系統的讀者換人了

回到觀點。這篇文章表面上在談工程工具鏈，實際上點出了一個正在發生的介面轉移：設計系統的主要讀者，正在從人換成機器。

過去十年，設計系統的成敗取決於文檔寫得好不好、範例全不全、開發者願不願意翻。這套以說服人為目標的介面，在 AI 生成成為前端標配之後，需要被重新設計成一份可以被強制注入上下文的結構化庫存。清單要先存在，掃描要先跑完，攔截要先發生，AI 才有機會在那顆提交按鈕被現編出來之前，看見倉庫裡已經有的那一顆。

文章裡最值得記下的一句判斷是：治本的路子不是調提示詞、訓 AI 乖一點，而是改造工程工具鏈。換成設計的語言來說，行為問題最終要在系統層解決，而不是靠對單一使用者的道德勸說。當產出速度由機器決定時，約束也必須由機器可讀的介面來承擔，這才是那顆被重複造出來的按鈕，真正留下來的課題。