文／Laban（優創智能 AI 導入工程師）
Figma Specs 是 Figma 於 2026 年 10 月 15 日推出的畫布上 Markdown 規格文件，讓團隊與 AI Agent 共用同一份設計決策、品牌規則與技術脈絡。結論先講：這次發布真正的訊號不是 Figma 多了一個編輯器，而是 Markdown 已經成為人與 AI Agent 交換工作規則的標準格式。企業不必等工具，現在就可以把品牌規範、SOP 與驗收標準寫成一份 Agent 讀得懂的規格書。
本文分成三部分：Figma 官方與媒體報導的已知事實、我們在導入現場的編輯分析，以及企業寫出第一份 Agent 規格書的步驟與範本。
一、已知事實：Figma Specs 做了什麼
以下整理自 Figma 官方部落格（2026-10-15）與 TechCrunch（2026-10-14，Figma 首場印度 Config 活動報導）。
1. Specs：放在畫布上的 Markdown 規格書
Figma 官方說明，越來越多產品團隊用 Markdown 和 Agent 協作，Markdown 已是分享脈絡的事實標準；但 Markdown 檔通常存在個人電腦裡、彼此關係脆弱、和產生它的專案脫節。Specs 想解決這個問題：
- 在 Figma 或 FigJam 按
D或點工具列的 Specs 圖示即可建立；也可以直接把現有的.md檔拖進畫布。 - Spec 可嵌入 FigJam 檔、畫面框架或畫布上的任何元素，讓文字與設計並排，而不是靠截圖或過期連結。
- 可以複製多份 Spec，讓每位成員各自修改後再對齊方向。
- 支援網頁、桌面與行動版，即日起以公開測試版提供給付費方案。
2. Agent 怎麼用 Specs
- Figma Agent：可讀寫 Spec 中的留言，例如請它為每則未解決的留言提出修正建議；Figma Agent 本身已正式開放使用。
- 程式開發 Agent：透過 Figma MCP server，Codex 等 Agent 可以讀取 Spec 及其連結的全部內容，包含 Markdown、畫面框架、圖表、程式碼圖層與 Code Connect 片段。使用者只要把 Spec 連結貼進 Agent 的提示中。
- 連接器：例如用 GitHub 連接器從程式庫帶入脈絡，或用 Hex 連接器讓 Agent 分析產品數據，再把結果以留言寫回 Spec 中提問的位置。
官方部落格提到，Figma 工程師在開發 Specs 功能本身時，就是先寫一份 Spec 定義邊界情況的處理原則，經同事留言後，再透過 MCP server 交給自己的 Agent 實作，並在開發過程中讓 Agent 回頭更新 Spec。
3. 同場發表的其他功能
依 TechCrunch 報導與 Figma 官方說明：
- Figma 的目標之一，是讓自家與第三方 Agent 在用 AI 創作時更能遵守品牌的設計規則；團隊可以把設計庫、程式庫與設計準則集中起來，讓 Agent 參照。
- 程式碼圖層（code layers） 進入公開測試，可在畫布上用程式碼做出可互動的原型。
- Figma MCP server 新增支援 20 多項工具與整合。
- 將去年收購的開源 headless CMS Payload 整合進 Figma Make。
TechCrunch 也引述 Figma 設計長 Loredana Crisan 的說法：現在產出的程式碼行數是過去的 17 倍，但發布次數只增加 1.3 倍；她認為很多程式碼是為了探索產品該長什麼樣子而寫，不是為了上線。這是 Figma 的主張，不是第三方統計，但它點出了一個值得注意的現象。
二、編輯分析：對企業的三個意義
以下是我們根據上述事實與導入經驗所做的判斷，不是 Figma 的說法。
意義 1：Agent 的輸出品質，取決於你給的規則寫得多清楚
AI 的輸出本質上不確定，Figma 自己也承認這一點，才推出工具把 Agent 導向更可預測的結果。企業使用 AI 時最常見的問題不是模型不夠聰明，而是規則只存在資深員工的腦袋裡：品牌用色、客服回覆的語氣、報價單的格式。人看得出來哪裡不對，Agent 不會。
意義 2：Markdown 是目前最低成本的共同語言
Figma 選擇 Markdown，而不是自創格式，是因為它已經是人與 Agent 之間的共通格式。軟體開發團隊早就在程式庫中放 AGENTS.md、CLAUDE.md 這類說明檔，告訴 Agent 專案規則與禁止事項。這個做法完全可以移植到非技術部門：一份寫給 Agent 看的行銷規範、客服 SOP 或採購流程。它和我們過去談的 SOP 標準化 是同一件事，只是讀者從新人變成了 AI。
意義 3：規格書要能被工具讀到，才會被遵守
Figma 用 MCP server 把 Spec 送進 Agent，關鍵在於「Agent 拿得到」。規格寫得再好，如果放在某人的筆電或沒人記得的雲端資料夾，Agent 每次執行都看不到。MCP 這類協定的角色，可以參考 MCP、API、CLI 怎麼選。
三、企業寫出第一份 Agent 規格書的五個步驟
步驟 1：挑一個 Agent 常出錯的流程
不要從全公司規範開始。挑一個已經在用 AI、但常需要人工修改的流程，例如社群貼文文案、客服回覆草稿或報價單整理。修改次數最多的地方，就是規格最缺的地方。
步驟 2：把資深員工的修改理由寫下來
收集最近 20 次人工修改，問負責的同事「為什麼要改」。這些理由就是規則的原料，例如「不能寫『保證』」「價格一律寫含稅」「回覆不超過三段」。
步驟 3：用固定格式寫成 Markdown
以下是可以直接套用的範本：
# 客服回覆規格書 v1
## 目的
在 24 小時內回覆客戶詢問，語氣專業、結論先講，不承諾無法兌現的事。
## 不可違反的規則
- 不得承諾退款、賠償或交期，一律寫「將由專人確認後回覆」。
- 不得提及其他客戶的名稱或案例細節。
- 價格一律引用官網公開價，並註明「含稅」。
## 範例
- 正確：「您好，關於您詢問的交期，我們將由專人確認後於今日下班前回覆。」
- 錯誤：「沒問題，保證三天內到貨！」
## 驗收標準
- 回覆不超過三段。
- 第一句直接回答客戶的問題。
- 沒有出現「保證」「一定」「絕對」。
## 維護
- 負責人：客服主管
- 每月檢查一次，新增的修改理由補進「不可違反的規則」。
步驟 4：放在 Agent 拿得到的地方
依你使用的工具，把規格書放在 Agent 每次都會讀到的位置：ChatGPT 或 Claude 的專案說明、自動化流程的系統提示、程式庫的說明檔，或像 Figma Specs 這種可透過 MCP 讀取的位置。重點是每次執行都自動帶入，而不是靠員工記得貼上。
步驟 5：用驗收標準檢查，每月更新
規格書上線後，用「驗收標準」那一節逐條檢查 Agent 的輸出，記錄哪些規則常被違反、哪些新的錯誤還沒寫進去。每月由負責人更新一次。Agent 的執行邊界與交付契約怎麼設計，可以參考 AI Agent 執行契約。
驗收標準：試行一個月後，同一流程的人工修改次數應比試行前明顯下降；若沒有下降，代表規格寫得太抽象，要回到步驟 2 補範例與具體規則。
四、結語：先把規則寫下來，工具會跟上
Figma 把 Markdown 規格書做成產品功能，說明「給 Agent 一份清楚的規則」已經從工程師的技巧，變成所有團隊都需要的基本功。工具會一直換，但一份寫清楚目的、規則、範例與驗收標準的規格書，換到哪個 Agent 都用得上。
如果你的團隊已經在用 AI，但常常需要花時間修正輸出，歡迎與我們聯繫，我們可以協助你從一個流程開始，把資深員工的經驗寫成 Agent 讀得懂的規格。
參考來源
- Figma，〈Introducing Specs: Markdown as a medium〉，2026-10-15：https://www.figma.com/blog/introducing-figma-specs/
- TechCrunch，〈Figma announces new features to define how agents work on its platform〉，2026-10-14：https://techcrunch.com/2026/10/14/figma-announces-new-features-to-define-how-agents-work-on-its-platform/
相關推薦與延伸閱讀
- Claude Opus 5.5 企業 6 大應用：程式遷移、夜間任務到財務分析，哪些工作值得先交給它：Claude Opus 5.5 是 Anthropic 於 2026 年 9 月 22 日發布的旗艦模型，強項是長時間、多步驟的代理任務。本文依官方公告與早期實
- Claude Opus 5.5 上線：成本降 40%、長任務更穩，企業 AI 導入該怎麼評估與切換：Anthropic 於 2026 年 9 月 22 日發布 Claude Opus 5.5，官方表示預設設定下執行成本比 Opus 5 低約 40%，Token
- MCP、API、CLI 差在哪？AI 系統介面的 2026 白話指南（上）：用實際工作流拆解 CLI、API 與 MCP 的角色差異，說明為什麼 MCP 不是 API 的替代品，以及企業該如何選擇正確介面。本文以一張表比較三種介面，說明