---
title: "Figma 推出 Specs：Markdown 成為 AI Agent 的規格書，企業該怎麼寫第一份"
description: "Figma 於 2026 年 10 月 15 日推出 Specs，把 Markdown 規格書放上畫布，讓團隊與 AI Agent 共用同一份設計決策與規則。本文整理官方事實，說明 Markdown 為何成為人與 Agent 的共同語言，並教企業不用 Figma 也能寫出第一份 Agent 規格書，附可直接套用的範本。"
canonical: "https://yotron-ai.com/blog/figma-specs-markdown-ai-agent-context"
published: "2026-10-16"
last-updated: "2026-10-16"
---

# Figma 推出 Specs：Markdown 成為 AI Agent 的規格書，企業該怎麼寫第一份

Figma 於 2026 年 10 月 15 日推出 Specs，把 Markdown 規格書放上畫布，讓團隊與 AI Agent 共用同一份設計決策與規則。本文整理官方事實，說明 Markdown 為何成為人與 Agent 的共同語言，並教企業不用 Figma 也能寫出第一份 Agent 規格書，附可直接套用的範本。

> 文／Laban（優創智能 AI 導入工程師）

Figma Specs 是 Figma 於 2026 年 10 月 15 日推出的畫布上 Markdown 規格文件，讓團隊與 AI Agent 共用同一份設計決策、品牌規則與技術脈絡。結論先講：**這次發布真正的訊號不是 Figma 多了一個編輯器，而是 Markdown 已經成為人與 AI Agent 交換工作規則的標準格式**。企業不必等工具，現在就可以把品牌規範、SOP 與驗收標準寫成一份 Agent 讀得懂的規格書。

本文分成三部分：Figma 官方與媒體報導的**已知事實**、我們在導入現場的**編輯分析**，以及企業寫出第一份 Agent 規格書的**步驟與範本**。

---

## 一、已知事實：Figma Specs 做了什麼

以下整理自 [Figma 官方部落格](https://www.figma.com/blog/introducing-figma-specs/)（2026-10-15）與 [TechCrunch](https://techcrunch.com/2026/10/14/figma-announces-new-features-to-define-how-agents-work-on-its-platform/)（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 標準化](/blog/sop-standardization-guide) 是同一件事，只是讀者從新人變成了 AI。

### 意義 3：規格書要能被工具讀到，才會被遵守

Figma 用 MCP server 把 Spec 送進 Agent，關鍵在於「Agent 拿得到」。規格寫得再好，如果放在某人的筆電或沒人記得的雲端資料夾，Agent 每次執行都看不到。MCP 這類協定的角色，可以參考 [MCP、API、CLI 怎麼選](/blog/mcp-api-cli-guide-2026-part-1)。

---

## 三、企業寫出第一份 Agent 規格書的五個步驟

### 步驟 1：挑一個 Agent 常出錯的流程

不要從全公司規範開始。挑一個已經在用 AI、但常需要人工修改的流程，例如社群貼文文案、客服回覆草稿或報價單整理。修改次數最多的地方，就是規格最缺的地方。

### 步驟 2：把資深員工的修改理由寫下來

收集最近 20 次人工修改，問負責的同事「為什麼要改」。這些理由就是規則的原料，例如「不能寫『保證』」「價格一律寫含稅」「回覆不超過三段」。

### 步驟 3：用固定格式寫成 Markdown

以下是可以直接套用的範本：

```markdown
# 客服回覆規格書 v1

## 目的
在 24 小時內回覆客戶詢問，語氣專業、結論先講，不承諾無法兌現的事。

## 不可違反的規則
- 不得承諾退款、賠償或交期，一律寫「將由專人確認後回覆」。
- 不得提及其他客戶的名稱或案例細節。
- 價格一律引用官網公開價，並註明「含稅」。

## 範例
- 正確：「您好，關於您詢問的交期，我們將由專人確認後於今日下班前回覆。」
- 錯誤：「沒問題，保證三天內到貨！」

## 驗收標準
- 回覆不超過三段。
- 第一句直接回答客戶的問題。
- 沒有出現「保證」「一定」「絕對」。

## 維護
- 負責人：客服主管
- 每月檢查一次，新增的修改理由補進「不可違反的規則」。
```

### 步驟 4：放在 Agent 拿得到的地方

依你使用的工具，把規格書放在 Agent 每次都會讀到的位置：ChatGPT 或 Claude 的專案說明、自動化流程的系統提示、程式庫的說明檔，或像 Figma Specs 這種可透過 MCP 讀取的位置。重點是**每次執行都自動帶入**，而不是靠員工記得貼上。

### 步驟 5：用驗收標準檢查，每月更新

規格書上線後，用「驗收標準」那一節逐條檢查 Agent 的輸出，記錄哪些規則常被違反、哪些新的錯誤還沒寫進去。每月由負責人更新一次。Agent 的執行邊界與交付契約怎麼設計，可以參考 [AI Agent 執行契約](/blog/enterprise-ai-agent-execution-contracts-fde)。

**驗收標準**：試行一個月後，同一流程的人工修改次數應比試行前明顯下降；若沒有下降，代表規格寫得太抽象，要回到步驟 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 大應用：程式遷移、夜間任務到財務分析，哪些工作值得先交給它](/blog/claude-opus-5-5-enterprise-use-cases)：Claude Opus 5.5 是 Anthropic 於 2026 年 9 月 22 日發布的旗艦模型，強項是長時間、多步驟的代理任務。本文依官方公告與早期實
- [Claude Opus 5.5 上線：成本降 40%、長任務更穩，企業 AI 導入該怎麼評估與切換](/blog/claude-opus-5-5-launch-enterprise-ai-guide)：Anthropic 於 2026 年 9 月 22 日發布 Claude Opus 5.5，官方表示預設設定下執行成本比 Opus 5 低約 40%，Token
- [MCP、API、CLI 差在哪？AI 系統介面的 2026 白話指南（上）](/blog/mcp-api-cli-guide-2026-part-1)：用實際工作流拆解 CLI、API 與 MCP 的角色差異，說明為什麼 MCP 不是 API 的替代品，以及企業該如何選擇正確介面。本文以一張表比較三種介面，說明