最近看到一個有趣的訊號：開始有人把設計語言整理成給 coding agent 讀的規格檔。這件事表面上像是前端工程或設計系統的小題目，但我覺得它其實踩到 AI coding 下一階段的核心——不是再多寫幾句 prompt，而是讓 AI 進入工作流之前，先拿到一份穩定、結構化、可以被引用的設計上下文。
過去我們讓 AI 幫忙寫程式，最常餵給它的是需求描述、錯誤訊息、某幾個檔案，頂多再加上 README。這在 prototype 階段很夠用。你要它補一個函式、改一個 API、產一段測試，模型通常可以靠附近程式碼推理出風格，靠幾次對話把方向修正回來。
可是只要場景拉大一點，問題就出現了。AI 會寫出能跑的程式，但不一定寫出「像這個產品」的程式；會生出漂亮的畫面，但不一定符合既有設計語言；會照需求新增元件，但可能無意間破壞資訊層級、狀態語意或操作節奏。這不是模型笨，而是我們把很多真正重要的知識留在人腦、會議、截圖、口頭默契和散落的舊 PR 裡。
人類工程師在團隊待久了，會慢慢吸收這些隱性規則：這個系統的表格什麼時候可以 inline edit，什麼時候一定要開視窗；危險操作要放在哪裡；空狀態要怎麼寫；錯誤訊息要講原因還是講下一步；主要按鈕一頁能不能有兩個；手機版哪些欄位可以收起來。這些規則不見得都寫在文件裡，但它們構成產品的一致性。
AI coding agent 沒有這種「在公司混久了」的能力。它每次接任務，都像一個很聰明但剛進團隊的外包工程師。你如果只丟一句「幫我做一個設定頁」，它可能會完成，但完成方式會帶著模型訓練資料裡的平均審美，而不是你的產品脈絡。這就是為什麼我覺得 agent-readable design spec 很值得注意。
這裡的重點不是檔名叫什麼，也不是要不要多一個標準。重點是：我們開始承認 AI 需要的上下文，不只包含「程式如何編譯」，也包含「產品如何長得像自己」。README 通常描述專案怎麼啟動；issue 描述這次要做什麼；API 文件描述資料怎麼交換；但設計規格描述的是更細的判斷：什麼可以變、什麼不能變、什麼是慣例、什麼是例外。
從 CTO 的角度，我會把這件事看成工程管理問題，而不是單純前端文件問題。因為一旦 coding agent 變成團隊日常的一部分，文件就不只是給人看的知識庫，而是會直接影響產出品質的控制面。寫得模糊，AI 就會自由發揮；寫得過細，維護成本會高到沒人更新；寫得跟程式脫節，AI 反而會引用過期規則，製造另一種技術債。
好的設計上下文應該像 guardrail，不是像百科全書。它不用描述世界上所有 UI 原則，而是要回答這個產品裡最容易踩錯的選擇。例如：表單送出後的狀態流程是什麼；刪除、取消、作廢在語意上怎麼分；列表操作要批次還是單筆；權限不足時要隱藏按鈕還是顯示 disabled；資料還沒同步完成時畫面要承認不確定，還是假裝已完成。
這些東西如果只靠 prompt 補，會很累。每次任務都重講一次，容易漏，也不容易形成團隊共識。比較好的做法是把它變成 repo 裡穩定存在的上下文，讓 agent、工程師、設計師都能引用同一份規則。當規則改了，就像改 API contract 一樣進版控、review、留下原因。
我也會避免把它做成純粹的設計宣言。AI 真正需要的是可操作的規則與範例。與其寫「介面要簡潔」，不如寫「列表頁預設只放查詢條件、主要表格與單一主要操作；進階設定收進次要區塊」。與其寫「錯誤訊息要友善」，不如寫「驗證錯誤要指出欄位與修正方式；系統錯誤要保留追蹤碼，但不要把堆疊丟給使用者」。抽象價值觀很適合人類討論，具體規則才適合 agent 執行。
這件事也讓我重新看待設計系統。以前設計系統常被理解成元件庫、顏色、字級、間距和 Storybook；現在它可能還要多一層「給 AI 的操作語意」。不只是 Button 長怎樣，而是什麼情境該用主要 Button；不只是 Modal 怎麼排，而是哪些決策不能用 Modal 草率處理；不只是元件 API，而是流程語意與例外邏輯。
當然，這不代表有了設計規格，AI 就會自動變成資深工程師。上下文只是降低犯錯機率，不是免驗收證書。真正的流程還是要有測試、review、preview、可回滾，尤其是牽涉權限、資料異動和流程狀態的地方。但如果沒有這層上下文，review 就會一直卡在「不像我們家的東西」這種難以自動化、也難以累積的反覆修正。
我現在會把 AI coding 的成熟度分成兩段。第一段是會寫：能讀懂需求、改對檔案、通過測試。第二段是寫得像：符合產品風格、流程語意、團隊慣例與長期維護方向。前者靠模型能力和工具鏈，後者靠上下文治理。
很多團隊導入 AI coding 時，會急著比較哪個模型比較會寫、哪個 IDE 外掛比較順、哪個 agent 可以跑比較久。這些都重要，但如果 repo 裡沒有清楚的設計上下文，AI 的產出就會像一群技術很好的短期人力，各自把事情做完，卻慢慢把產品一致性磨掉。
所以我對這類 agent 可讀設計規格的期待不是「讓 AI 取代設計師」或「讓工程師不用思考」。剛好相反，它逼我們把過去靠默契維持的東西講清楚。講清楚之後，人更容易對齊，AI 也比較不會亂猜。
AI coding 下一階段的競爭，不只是誰能生成更多程式碼，而是誰能把團隊的判斷整理成可被機器穩定使用的上下文。程式碼會變多很容易；產品還能不能保持一致，才是真正的管理題。