Figma Specs 開放 Beta：把 Markdown、設計與 AI 代理接成共同規格
Figma Specs 把 Markdown、設計參照與團隊討論放進共同規格。看懂 MCP 代理交接、Beta 開放權限、手動編輯與 AI 點數差別，再用小功能驗證成果。
Figma Specs 想解決的，是需求文件、設計畫面與 AI 代理各自握有一部分資訊，卻沒有共同依據的問題。
Figma 在十月十五日的 Config India 發表這項功能，把 Markdown 文字帶進可共同編輯的畫布，也能參照設計與圖表。Markdown 是用簡單符號標示標題、清單與程式區塊的文字格式。
Specs 讓設計意圖、討論與技術條件放進同一份可協作的規格，供團隊與代理讀取。
但有了共同文件，不代表每個決定已經確認，也不代表代理生成的程式可以直接上線，交接與驗收仍要清楚。
對常在文件與設計之間反覆補充背景的團隊，Specs 值得從一個小功能試起，觀察它能否減少漏掉條件的返工。
要理解它改變了哪一段工作，先看文字與畫布如何放在一起。
Figma Specs 與一份 Markdown 文件差在哪裡？
Specs 把可協作的規格放在工作旁邊，文字可以直接參照設計與圖表。
Markdown 適合把需求寫成清楚的文字，卻需要另外交代那些文字指向哪個畫面。當畫面有多個版本，接手的人便可能對著錯的版本實作。
Figma 官方公告介紹的做法，是把既有 .md 檔拖進畫布，並在規格中嵌入設計框、節點或 FigJam 圖表，讓文字與視覺參照一起閱讀。
FigJam 是 Figma 的協作白板，適合整理流程與想法。節點則是畫布上的個別物件，因此規格能指到特定內容，不必只靠整張截圖猜位置。
假設團隊要做課程報名頁，文件寫「完成後顯示確認訊息」，設計稿卻同時保留兩種成功畫面。若未標明採用哪一版，代理就得自行選擇。
把確認畫面放到對應規則旁邊，便能讓接手者知道同一個狀態應呈現什麼。文字負責說明行為，畫面則補上位置與呈現方式。
把意圖寫出來，畫面才有解釋依據
即使畫面選對了，接手者仍可能不知道按鈕為什麼停用。例如名額已滿與資料未填完整都可能讓按鈕變灰，但後續處理完全不同。
因此，規格要補上停用的原因，以及使用者接著能做什麼。這樣即使設計日後調整顏色，工程師仍能保留原來要解決的問題。
PRD 是產品需求文件，通常說明要替誰解決什麼問題，以及這次準備做到哪裡。它能幫團隊判斷一個看似方便的新增功能，是否偏離原本目標。
在報名頁案例中，目標若是讓已決定參加的人完成報名，規格就應優先交代提交與確認。首頁動畫再漂亮，也不能替代這段行為。
共同畫布讓這些材料更容易相互參照，但內容改了之後，仍需要確認文字與畫面的意思一致。放在同一處，提供的是核對位置與討論依據。
參照放在一起之後，還要讓團隊對內容形成共同決定。
Introducing Specs: a new medium for markdown that brings context into, out of, and across Figma AND it’s collaborative AND has unique-to-Figma visual features
— Figma (@figma) October 15, 2026
Live from Config India pic.twitter.com/i3F4FwAu4I
團隊如何從討論整理出可採用的規格？
評論與共同編輯能保存討論，但已決定與仍待選擇的內容應分開寫清楚。
否則，同事提出「也許能支援候補」時，工程師可能把它當成這次必做的需求。討論保留得越完整，越需要交代哪些話已經成為交付條件。
可以先在規格中寫出已採用的行為，再把尚未決定的選項放在對應位置。這是團隊整理文件的方法，接手者讀到的仍應是一份清楚的工作約定。
假設報名名額已滿，團隊決定先顯示額滿訊息，候補功能留待之後。接手者便知道這次需要完成前者，不必為後者猜測資料欄位與通知流程。
但決定也要說明理由。暫時不做候補仍留下未來討論的空間，但若課程本來就不接受候補，後續設計就應維持同樣限制。
評論留下過程，正文承接最後的決定
代理可以協助整理意見，但整理得順暢不代表每個衝突都已解決。當兩則評論提出相反要求，仍要有人確認究竟採用哪個方向。
例如一位同事希望提交後立即清空表單，另一位希望保留資料以便修正。團隊應先釐清成功與失敗狀態，才知道兩個要求是否真的互相排斥。
若提交成功，畫面可以轉到確認狀態；若只是連線失敗，保留輸入則有助重試。原本看似矛盾的評論，可能其實在談不同情況。
決定寫回正文後，工程師就能讀到可採用的規則，評論則保留討論脈絡。接手者因此不必從整串對話重新推理一次。
當需求後來改變，也應同步指出受影響的畫面與條件。只改一句按鈕文案，可能仍留下先前的成功提示，讓兩處說法互相衝突。
若規格同時服務設計與工程，也可以寫出這次不處理的範圍。例如手機版只調整表單排列，付款流程仍沿用既有方式，接手者就能集中完成已確認的變更。
這段範圍也方便後續審查，因為新增的按鈕或通知都能對回原來需求。出現額外行為時，團隊可以先決定是否採用，再更新交付內容。
規格足夠明確，代理才有合適的依據可以接手。
AI 代理與 MCP 如何讀取及更新 Specs？
MCP 讓連接的代理讀寫規格及相關設計背景，但不會自動決定產品應該怎麼做。
MCP 可以理解成 AI 工具連接外部系統的共同介面。它讓代理透過工具取得資料或提出修改，讀到什麼與能改什麼，仍與連線設定和權限有關。
官方 Specs 指南說明，連接 Figma MCP 的程式代理可透過 figma-spec skill 讀取、建立及更新規格。Skill 是提供代理處理特定任務的操作指引。
這讓交接可以從一段指令加上規格連結開始，但指令仍要說清楚這次工作。例如只處理報名失敗的提示，就應限制修改範圍，避免連成功流程一起改動。
代理讀完後，可以先說明它理解的行為與例外，讓團隊在生成程式之前確認。若理解已經偏離，修正規格通常比等整頁完成後再找原因更直接。
寫回規格，保留實作遇到的新問題
實作時也可能發現原先沒寫的限制。假設後端無法立即確認名額，代理應把這個落差交回討論，而非自行把「報名成功」改成另一種承諾。
後端是接收資料與處理業務規則的服務。畫面能顯示一段成功文字，和服務真的建立報名紀錄，是兩個需要接起來的結果。
如果團隊確認先顯示處理中的狀態，就應把等待與失敗條件補回規格。下次換人維護時，才知道這段設計是有原因的安排。
官方也介紹由設計整理規格、由規格產生 code layer 的工作方式。Code layer 是放在畫布上執行的程式內容，可以用來探索互動。
但互動能跑之後，資料是否正確保存、錯誤能否恢復，仍要按產品要求檢查。共同規格提供驗收依據，生成畫面只是這段流程中的成果之一。
延伸閱讀：Capy 接上 Paper：關掉筆電後，雲端代理如何從設計畫布做到 Pull Request？
串接能力之外，實際能否使用還要看帳號、權限與開放進度。
開放範圍、權限與 AI 點數怎麼看？
Specs 正在分批開放測試，手動編輯與使用代理的點數安排也不同。
截至二〇二六年十月十五日，官方說明它以 open beta 陸續開放，也就是公開測試階段仍在逐步提供。不同帳號可能在不同時間看到入口。
方案可先按付費方案陸續開放理解，指南另列教育方案，實際還需確認帳號與權限。團隊不應只因其他 AI 功能可用，就預設 Specs 已經開通。
取得入口後，也需要檔案的編輯權限才能修改。若同事只要確認規格，應先確定能看到相同文件與參照，才不會把權限問題誤認成內容遺漏。
Specs 可作為獨立檔案，也能放在 Figma Design 或 FigJam，並支援網頁、桌面與手機。團隊可依討論場景選位置，但仍應明確指向本次採用的規格。
手動寫改與請代理處理，費用不同
直接手動撰寫和編輯 Spec 內容，不會消耗代理的 AI 點數。使用代理處理 Specs 則會耗用 Figma AI credits，用量受任務複雜度與背景內容影響。
官方提供每次提示後的用量收據，因此可以觀察一次整理或修改用了多少點數。需要比較成本時，應連同人工檢查時間一起記錄。
FigJam 代理截至當日仍屬封閉測試，參加者透過它建立 Spec 暫不耗點數，這是特定測試安排。一般 Specs 代理用量仍按前述說明理解。
Config India 官方功能說明中的十一月四日前優惠，針對付費方案的 code layer 建立與編輯。它沒有把其他代理工作一起列為免費。
因此，估算試用成本時，要看實際請代理完成哪些任務。把一份長文件重新整理與手動修一個字，工作方式和計費條件並不相同。
知道可用條件與成本後，就可以用小功能驗證它是否改善交接。
怎麼用一個小功能測試規格交接？
先固定要交付的行為、畫面與例外，再觀察另一位同事能否照規格完成。
可以沿用假設的報名頁，但這次只測提交失敗時的處理。範圍縮小後，團隊才看得出問題來自規格遺漏，還是實作沒有遵守已寫的條件。
先寫清楚失敗後保留哪些輸入、使用者看到什麼訊息，以及重試後如何確認結果。這些規則會直接影響使用者能不能完成報名。
再把對應畫面放在規則旁邊，請未參與討論的同事解釋一次。如果他仍不確定失敗後能否重試，就表示這份文件還需要補充。
記下疑問與返工，才能知道改善在哪裡
接著才讓代理或工程師實作，並用同一組情況核對。若文字寫保留輸入，畫面卻清空資料，就能指出具體落差，而非只說結果不符合期待。
除了正常提交，也可以模擬連線中斷後重試，觀察是否出現重複紀錄。這是報名流程的驗收案例，並非 Specs 自動提供的檢查功能。
每次多問的問題都值得留下，因為它能指出原先沒交代清楚的條件。但提問變少也要配合完成結果看，否則可能只是接手者直接猜了答案。
比較時可保留原本文件的交接方式，再記錄新方式需要補充什麼。若新文件仍常指到錯誤畫面，便應先修參照與版本安排，暫緩擴大使用。
反過來，若接手者能按同一份規格解釋行為、完成實作並通過例外測試，團隊就有理由把做法延伸到相近功能，而非立即搬進全部文件。
最後可請另一位同事接續修改同一功能，確認他是否能找到原來的決定與原因。因為共同規格會被持續使用，第一次展示完成之外，也應看後續變更能否沿用。
若每次改動都必須找原作者口頭解釋，便表示重要背景還沒留進文件。把這些缺口補齊，下一次交接才有累積，而非重新開始。
能讓接手者少問一輪仍做對，才是共同規格值得保留的成果。
延伸閱讀：Builder.io Visual Edit 把真實網頁搬進設計畫布：畫面改好了，程式也跟著改了嗎？
Figma Specs 常見問題
Figma Specs 會取代所有 Markdown 文件嗎？
它提供 Figma 內的協作與畫布參照。若文件主要服務程式庫或其他流程，仍可保留原本位置，再挑需要共同討論的部分整理進規格。
手動編輯 Specs 會用掉 AI 點數嗎？
直接寫改內容不耗代理點數，但請代理整理、生成或修改內容會耗用，FigJam 封閉測試另有特定例外。
有 Figma 付費帳號就一定看得到嗎？
截至十月十五日仍是分批開放的公開測試，帳號取得時間可能不同，編輯還需要檔案權限。
代理完成規格後，產品就能直接上線嗎？
規格能交代要做什麼，正式產品仍需要實作與驗收，尤其要確認資料處理及例外流程符合原本需求。
先完成一次交接，再決定是否擴大使用
如果團隊已經在 Figma 討論畫面，卻常漏掉背後的行為條件，Specs 值得從一個功能試起。交接後能照規格做對，才有把它擴大成共同工作方式的依據。
免費訂閱 AI 郵報，持續追蹤 AI 設計與代理工具的新功能、使用條件及實際驗收方法。
