Figma 在 Config India 推出 Specs（open beta）：把 .md 檔拖上畫布就能變成多人協作的規格書，可嵌入設計框、FigJam 與 code layers，Figma agent 能回覆留言，coding agent 也能透過 MCP 讀取整份脈絡。給想把「需求、設計、開發」接成一條線的團隊一份上手筆記。
每個專案都有一份傳說中的規格書。它叫 PRD_final_v7.docx，躺在某個雲端資料夾；設計稿在 Figma，討論在聊天群組，工程師手上的需求則是三週前截的圖。等到上線前一天，大家才發現：原來我們做的是三個不同的產品。
2026 年 10 月 15 日，Figma 的 Luke Zhang（產品經理）、Johnny Dallas（軟體工程師）與 Aosheng Ran（產品設計師）在官方部落格發表 Specs，副標很直白：「Markdown as a medium」。這是 Config India 2026 的發表之一，目標是讓規格書不再是孤島，而是住在設計稿旁邊、人和 AI 代理都能一起改的文件。
為什麼是 Markdown？
Figma 的觀察是：隨著和 AI 代理協作越來越普遍，越來越多產品團隊用 Markdown 工作，它已經是分享脈絡的事實標準。但 Markdown 也有明顯缺點：檔案通常放在個人電腦上、只有一個人在用，彼此之間的關聯很脆弱，跟產生它的專案也幾乎沒有連結。
大部分脈絡是短暫的，但有些會演變成需要反覆修改、多人協作的關鍵輸入。Specs 想解決的就是這一段：一個多人協作的容器，讓脈絡可以在 Figma 內外自由移動。
Specs 能做什麼？
根據官方部落格與說明中心，重點有這幾項：
- 拖進來就是規格書：把任何
.md檔拖到畫布上就會變成 spec；也可以按鍵盤D或點工具列的 Specs 圖示新增。 - 文字與設計並排：可以把 FigJam 檔、畫布上的設計框或任何節點嵌入 spec，取代截圖和過期連結。從 spec 拖出去的元素也能保留 Figma 屬性。
- AI 代理當同事：Figma agent 能讀取並回覆留言，你可以請它對每一則未解決留言提出修正建議，同時隊友也在同一份文件討論；每段對話有自己的討論串，可以平行進行。
- 連接器帶入外部脈絡：起草技術規格時，可用 GitHub 連接器從程式碼庫拉資料；PRD 裡有資料能回答的問題，可以請 agent 用 Hex 連接器跑分析，把結果留成留言。
- 一鍵交給 coding agent：複製 spec 連結貼進 coding agent 的提示，透過 Figma MCP 伺服器，Markdown、設計框參照、圖表、code layers 與 Code Connect 片段都會一起帶過去。
- 多版本並行：可以複製 spec，讓每個人先做自己的版本，再一起收斂方向。
真實團隊怎麼用
部落格裡幾個例子很有參考價值。
Figma 工程師 Noah Finer 在開發 Specs 這個功能本身時，就先寫了一份 spec，列出處理邊界情況的指導原則，嵌入 FigJam 流程圖，再分享給同事留言。定稿後，他把 spec 和同事的留言透過 MCP 一起交給 coding agent；開發過程中，又用 MCP 回頭更新畫布上的原始 spec，甚至讓代理畫新的流程圖嵌進去，再送給負責 code review 的同事。
Intuit 的資深產品設計師 Mark Harvey 在設計新的一組圖示時，直接在圖示旁邊放一份 spec，每個項目記錄檔名、分類、搜尋標籤與描述。他說，用 Specs 帶入結構一致、格式整齊的文件，讓設計檔對非設計師來說更容易理解。
研究員 Mike Blight 則用它收斂討論：大家用便利貼、留言和標註推敲方向，他把決策和尚未解決的問題整理進 spec，下一輪探索就從這份脈絡出發。他把這稱為「飛輪」：一起探索、整合成果、讓工作持續前進。
同場加映：code layers 與 Payload
Specs 不是單獨登場。同一天，code layers 進入 open beta，開放所有方案逐步取得。code layer 承載真實、可執行的程式碼，可以把設計變成畫布上的互動原型；反過來，也能用 Extract designs 把 code layer 的當前狀態轉回可編輯的設計圖層。
說明中心也寫明，code layers 在 open beta 期間會使用 AI 點數，但付費方案在 2026 年 11 月 4 日前，建立與編輯 code layers 本身不扣點。另外，Payload 成為 Figma Make 的原生後端，Figma MCP 伺服器也新增讀寫與建立 Specs 的能力。
對工作室與客戶專案的意義
我們幫客戶做網站時，最常出問題的不是技術，而是「大家以為的需求不一樣」。Specs 提供的是一個把需求、設計與實作脈絡放在同一張畫布上的機會。幾個導入建議：
- 先定 spec 範本：例如「目標、使用者情境、頁面清單、驗收條件、未決問題」，讓每個專案的規格長得一樣，新人和客戶都好讀。
- 驗收條件寫成可檢查的句子：「表單送出後 3 秒內顯示成功訊息」比「表單要好用」更適合交給人，也更適合交給 AI 代理。
- 把決策和未決問題分開：學 Mike Blight 的做法，已定案的寫進正文，還在吵的列在「待討論」區，避免代理把草案當定案實作。
- 敏感資料不要放：客戶的帳密、金鑰、個資不該出現在規格書，尤其是會被代理讀取的文件。
- 注意成本與方案：Specs 目前開放給付費方案，使用 agent 會消耗 AI 點數，導入前先估算團隊用量。
- 保留版本紀錄：重要里程碑時，把 spec 匯出或同步一份到專案儲存庫，避免 beta 功能變動造成資料遺失。
實戰範例：一份官網改版 spec 長這樣
以下是我們會放在設計稿旁邊的簡化範本。重點不是格式多漂亮，而是讓設計師、工程師、客戶和 AI 代理讀完都能得到同一個答案：
# 官網改版：產品頁
## 目標
- 讓訪客在 30 秒內找到「預約諮詢」按鈕
- 產品頁跳出率比改版前下降
## 使用者情境
- 從 Google 搜尋進站、用手機瀏覽的潛在客戶
- 已有合作、想下載型錄的經銷商
## 頁面與元件
- 首屏主視覺（嵌入設計框：Product Hero）
- 規格比較表（嵌入設計框：Spec Table）
- 預約表單（嵌入 FigJam：表單流程圖）
## 驗收條件
- 手機版首屏內可見預約按鈕
- 表單送出後顯示成功訊息並寄出通知信
- 所有圖片都有替代文字
## 未決問題
- 比較表是否顯示價格？（等待客戶確認）
把它放在畫布上之後，設計框和流程圖就不再是「請參考附件」，而是直接嵌在對應段落裡；coding agent 拿到連結時，也會一併讀到這些參照。
你可能會問
Q：我們沒有付費方案，可以用 Specs 嗎？
A：說明中心列出 Specs 開放給 Education、Professional、Organization、Enterprise 與 Government 方案，並在接下來幾週逐步開放，沒看到請稍候。
Q：使用 Specs 要花 AI 點數嗎？
A：在 Specs 裡使用 agent 會消耗 Figma AI 點數，每次提示後可以查看用量；FigJam 的 agent 仍在封閉測試，參與者在 FigJam 用 agent 建立 Spec 目前不扣點。
Q：Specs 會取代 Notion 或 Google Docs 嗎？
A：官方沒有這樣說。Specs 的定位是「住在畫布上、跟設計與程式碼連在一起」的規格容器；一般行政文件放原本的工具，跟產品實作直接相關的規格再放進 Specs，比較務實。
Q：AI 代理會不會亂改規格？
A：Figma agent 是透過留言和你的提示協作，每段對話有獨立討論串。建議仍由專案負責人定稿，把「誰能決定」寫清楚。
結語
Specs 的價值不在於多了一種文件格式，而在於它承認了一件事：在 AI 代理參與開發之後，規格書本身就是產品的一部分。寫得清楚的脈絡，會直接變成更好的設計、更準的程式碼。
下次開案，不妨先在畫布上放一份 spec，把設計稿、流程圖和驗收條件都擺在旁邊。等上線前一天，你會感謝當初那個多寫了三行「未決問題」的自己。
來源：Introducing Specs: Markdown as a medium（Luke Zhang、Johnny Dallas、Aosheng Ran，Figma Blog，2026/10/15）。
延伸參考：What's new from Config India 2026（Figma Learn - Help Center）。