回顧：我拒絕了什麼
上一篇文章的核心論點很簡單：AI 的能力邊界不等於你應該給它的權限邊界。
OpenClaw 能控制你的電腦、讀寫檔案、執行 shell command、自我進化。能力驚人，但 Cisco 的資安團隊在第三方 skill 裡發現了資料外洩，local model 的判斷力不足以支撐自主操作。四行風險矩陣，四個 No。
我走開了。但問題還在：design handoff 依然是人工作業，PM 依然在手動拆 Jira ticket。
轉折：OpenAB + MCP 改變了遊戲規則
OpenAB 是一個開源社群專案（我是 contributor），用 Rust 寫的 ACP harness。它把 Discord/Slack 訊息橋接到 AI coding agent（Claude、Codex、Gemini），讓團隊在聊天頻道直接跟 AI 互動。
關鍵差異在於 MCP（Model Context Protocol）——它讓 AI agent 透過標準化協議存取外部工具，但不給自主權限。Agent 能讀 Figma spec、能開 Jira ticket，但每一步都在你定義的範圍內。
┌────────────────────────────────────────────────────┐
│ │
│ OpenClaw 模式 OpenAB + MCP 模式 │
│ │
│ AI ──► 檔案系統 AI ──► Figma (read-only) │
│ AI ──► Shell AI ──► Jira (scoped API) │
│ AI ──► 自我修改 AI ──► 你定義的 MCP tools │
│ AI ──► 訊息平台 │
│ │
│ 權限：ALL 權限：你說了算 │
│ │
└────────────────────────────────────────────────────┘
AI generates. Humans authorize. 這個原則沒變，但現在我有了工具讓它在安全邊界內做有用的事。
實際場景：設計師貼 Link，工程師收到 Ticket
每天的場景長這樣——設計師在 Discord 頻道貼了一個 Figma link：
Designer:
這個頁面要開發了
https://www.figma.com/design/xxxxx/Product-Dashboard?node-id=1001-2001
AI Agent:
讀取完成。這個 frame 包含 3 個主要 component：
1. HeaderNav — 水平 Auto Layout, gap 16px, 背景 #FFFFFF
2. ProductCardList — Grid layout 3 欄, gap 24px
3. FilterSidebar — 垂直 Auto Layout, width 280px
已在 Jira 建立：
Epic: PROJ-301 Product Dashboard - 商品列表頁
├── Story: PROJ-302 HeaderNav（附 Figma spec）
├── Story: PROJ-303 ProductCardList（附 Figma spec）
└── Story: PROJ-304 FilterSidebar（附 Figma spec）
Engineer:
PROJ-302 我來做
PM:
（什麼都不用做）
操作流程：三步驟，讓 AI 讀懂你的設計
不要直接丟整個 Figma 檔案連結。按這個順序效果最好：
Step 1：選取 frame，取得 node-id
在 Figma 中點選你要的 frame，瀏覽器網址列會自動帶上 node-id：
https://www.figma.com/design/xxxxx/My-Design?node-id=1001-2001
^^^^^^^^^^^^^^^^
這段很重要，不能省
Step 2：請 AI 讀取結構化 spec
貼 URL 給 bot，搭配這段 prompt：
讀取這個 Figma node 的：
1. 所有子 component 名稱和階層
2. Auto Layout 設定（direction, gap, padding）
3. 顏色和字型 token
https://www.figma.com/design/xxxxx/My-Design?node-id=1001-2001
AI 透過 Figma MCP 讀取結構化資料，回傳 component tree、layout 參數、design token。
Step 3：附上截圖，讓 AI 匹配視覺
Figma MCP 讀到的是結構資料，不是畫面。截圖讓 AI 同時「看到」設計：
（貼上 Figma 截圖）
上面是這個畫面的截圖，搭配剛才讀到的 Figma spec，幫我：
1. 確認每個 component 對應截圖中的哪個區塊
2. 補充 MCP 沒讀到的視覺細節（圖片、icon、陰影）
3. 整理成完整的開發 spec
只用 MCP → 有結構沒畫面，漏視覺細節
只用截圖 → 有畫面沒數值，spacing 靠猜
兩個一起 → 最完整
從 Figma 到 Jira：自動化開票的實戰
我的專案是一個 Product Dashboard，Figma 裡分成兩大模組：
模組 | Node 數量 | 對應 |
|---|---|---|
Advertiser | 6 個 frame | 1 Epic + 6 Stories |
Brand | 6 個 frame | 1 Epic + 6 Stories |
一個指令，12 張 Jira ticket 自動建好，每張 ticket 的 description 都帶上 Figma spec：
讀取 Figma file xYz1A2B3cDeFgHiJkLmNoP 以下 node，
每個 node 讀取 component 結構、Auto Layout、顏色和字型 token，
然後在 Jira 建立 ticket，把 spec 寫進 description。
Advertiser: 1001-2002, 1001-2001, 1001-2003,
1001-2004, 1001-2005, 1001-2006
Brand: 1001-3001, 1001-3002, 1001-3003,
1001-3004, 1001-3005, 1001-3006
分成兩個 Epic：Advertiser 和 Brand，每個 node 一張 Story。
踩坑紀錄
真實世界不是 demo。以下是我實際踩到的問題：
Figma Rate Limit（429 Error）
Figma API 有頻率限制。Starter 方案一個月只有 6 次 MCP 呼叫——幾乎沒法用。
方案 | 限制 |
|---|---|
Starter（免費） | 6 次/月 |
Pro | 200 次/天 |
Organization | 200 次/天 |
Enterprise | 600 次/天 |
解法：升級 Pro、指定 node-id 減少呼叫、搭配截圖降低 API 依賴。
MCP 認證問題
.mcp.json 裡的 ${ENV_VAR} 語法不會被 Claude CLI 展開。花了一小時 debug 才發現。解法：token 直接寫在 .claude/settings.local.json，加進 .gitignore。
OpenAB mcpServers 覆蓋
OpenAB 在 session/new 時預設傳 mcpServers: []，會覆蓋 agent 自己的 MCP 設定。解法：MCP 設定放 .claude/settings.local.json，不受 OpenAB 影響。
10 分鐘設定指南
1. 準備 Token
Token | 來源 | 過期 |
|---|---|---|
Figma Personal Access Token | Figma Settings → Generate | 不過期 |
Jira API Token | id.atlassian.com → Create | 不過期 |
Discord Bot Token | Developer Portal → Bot | 不過期 |
2. MCP Server 設定
{
"mcpServers": {
"figma": {
"command": "npx",
"args": ["-y", "figma-developer-mcp", "--stdio"],
"env": {
"FIGMA_API_KEY": "figd_your_token"
}
},
"jira": {
"command": "npx",
"args": ["-y", "@aashari/mcp-server-atlassian-jira"],
"env": {
"ATLASSIAN_SITE_NAME": "your-company",
"ATLASSIAN_USER_EMAIL": "[email protected]",
"ATLASSIAN_API_TOKEN": "your_token"
}
}
}
}
3. OpenAB Config
建立 config.toml：
[discord]
bot_token = "${DISCORD_BOT_TOKEN}" # Discord bot token（從環境變數讀取）
allowed_channels = ["YOUR_CHANNEL_ID"] # 限定 bot 只在這些頻道回應
[agent]
command = "claude-agent-acp" # ACP adapter（見下方支援列表）
args = []
working_dir = "/path/to/your/project" # Agent 的工作目錄，也是讀取 .mcp.json 的位置
env = {} # 需要傳給 agent 的環境變數
# OpenAB 支援多種 AI coding agent，換 command 就能切換：
#
# | Agent | command | args |
# |-------------|----------------------|-----------------------------------|
# | Claude Code | claude-agent-acp | [] |
# | Codex | codex | ["--acp"] |
# | Gemini | gemini | ["--acp"] |
# | OpenCode | opencode | ["acp"] |
# | Copilot CLI | copilot | ["--acp", "--stdio"] |
# | Cursor | cursor-agent | ["acp"] |
# | Kiro | kiro-cli | ["acp", "--trust-all-tools"] |
[pool]
max_sessions = 5 # 同時最多幾個對話 session
session_ttl_hours = 4 # Session 閒置多久後回收
[reactions]
enabled = true # Discord 訊息上顯示狀態 emoji（👀🤔🔥✅）
remove_after_reply = false # 回覆後是否移除 emoji
設定重點：
bot_token用${VAR}語法，OpenAB 會從環境變數展開allowed_channels填你要讓 bot 回應的 Discord 頻道 ID（開發者模式 → 右鍵頻道 → 複製 ID）working_dir要指向你的專案目錄，agent 會在這裡讀寫檔案command用claude-agent-acp可以直接用 Claude CLI 的登入認證，不需要另外放 API key
4. 安裝 & 啟動
# 安裝 Rust（如果沒裝過）
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# 安裝 Claude ACP adapter
npm install -g @agentclientprotocol/claude-agent-acp
# Clone OpenAB 並 build
git clone https://github.com/openabdev/openab.git
cd openab
cargo build --release
# 設定環境變數
export DISCORD_BOT_TOKEN="your_discord_bot_token"
# 啟動
./target/release/openab run /path/to/your/config.toml
啟動後在 Discord 頻道 @bot 就能互動了。
AI 生成 Code 時，前端工程師要注意什麼
AI 能從 Figma spec 生成前端 code，但不代表你可以直接 merge。2026 年 React 有 42% 的 code 是 AI 生成的——但剩下 58% 的價值在於你知道什麼是 AI 不會幫你做的。
AI 做得到 | AI 做不到，你要做 |
|---|---|
從 spec 生成 component skeleton | 驗證 token 是否對上 design system |
基本 JSX + CSS | 響應式行為、breakpoint 邏輯 |
Static render | State management 架構（server vs client state） |
Happy path data fetching | Error handling、retry、loading state |
一次性 render | useEffect cleanup、subscription unsubscribe |
AI 是初稿產生器，不是你的替代品。 越懂底層的工程師，review AI 產出越快——這是 2026 年前端工程師的核心價值。
不只 Figma + Jira：MCP 的擴展性
這篇文章聚焦在 Figma → Jira 的 pipeline，但 MCP 的威力在於同樣的模式可以套用到任何工具。
┌─────────────────────────────────────────────────────────┐
│ OpenAB + MCP │
│ │
│ 今天： │
│ Figma ──► AI Agent ──► Jira │
│ │
│ 明天： │
│ Figma ──► AI Agent ──► Linear (issue tracking) │
│ Notion ──► AI Agent ──► Jira (PRD → tickets) │
│ Figma ──► AI Agent ──► Notion (spec → doc) │
│ Linear ──► AI Agent ──► GitHub PR (auto-implement) │
│ │
│ MCP server 是 plugin，加一個 = 多一條 pipeline │
│ │
└─────────────────────────────────────────────────────────┘
想像一下這些場景：
Linear + MCP
PM 在 Linear 建了一個 issue，AI agent 自動讀取 issue description，去 Figma 找對應的設計稿，生成前端 code 的初稿，開一個 GitHub PR。工程師只需要 review + merge。
Notion + MCP
產品需求文件（PRD）寫在 Notion 裡。AI agent 讀取 Notion page，自動拆成 Jira/Linear ticket，每張 ticket 的 description 從 PRD 裡對應的段落生成。PM 寫完 PRD，ticket 就自動開好了。
全串聯
PRD (Notion) → Tickets (Linear/Jira) → Design Spec (Figma) → Code (GitHub PR)
↑ │
└──────── AI Agent 串聯整條 pipeline ───────────┘
每一段都是一個 MCP server，每一段的權限都是你定義的——Notion 唯讀、Linear scoped write、Figma read-only、GitHub PR only。
這不是幻想。 MCP server 生態已經有 Notion、Linear、GitHub、Slack、Confluence 的實作。差別只在於有沒有人把它們串起來。
MCP × ACP：企業 AI 的下一個戰場
如果你只看到 Figma → Jira 這條 pipeline，你看到的是冰山一角。
MCP（Model Context Protocol） 定義了 AI agent 如何存取工具。ACP（Agent Client Protocol） 定義了人如何跟 AI agent 溝通。這兩個協議加在一起，就是企業 AI 基礎設施的標準化層。
┌─────────────────────────────────────────────────────────────┐
│ │
│ Enterprise AI Stack (2026+) │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────────┐ │
│ │ People │────►│ ACP │────►│ AI Agents │ │
│ │ (Teams) │ │ Protocol │ │ (Claude, │ │
│ └───────────┘ └───────────┘ │ Codex, etc) │ │
│ └───────┬───────┘ │
│ │ │
│ ┌───────▼───────┐ │
│ │ MCP │ │
│ │ Protocol │ │
│ └───────┬───────┘ │
│ │ │
│ ┌─────────┬───────┬───────┼────────┐ │
│ ▼ ▼ ▼ ▼ ▼ │
│ Figma Jira Linear Notion GitHub │
│ │
└─────────────────────────────────────────────────────────────┘
現在每家企業都在問：「我們要怎麼導入 AI？」
答案不是買一個 chatbot。答案是建立 AI agent 與企業工具鏈之間的標準化介面。誰先把 MCP + ACP 的基礎設施建好，誰就掌握了 AI 在組織內的流動方式。
這跟 10 年前的 API economy 一樣——當時大家在問「我們需要 API 嗎？」，現在沒有 API 的公司根本活不下去。MCP 和 ACP 就是 AI 時代的 API。 今天是 Figma + Jira，明天是你公司裡每一個產生或消費資料的工具。
早佈局的公司，會在 AI agent 能力爆發時直接受益。晚佈局的公司，會發現自己的工具鏈是 AI 的孤島。
從 Cloud 到 Local：不只是省錢，是生存問題
2026 年 4 月，Anthropic 一夕之間停權了一間公司 60+ 個 Claude 帳號。沒有預警、沒有明確違規說明，60 個員工的日常工作流直接中斷。申訴管道？填一張 Google Form。
這不是個案。2026 年 1 月，Anthropic 部署技術限制，封鎖所有第三方工具透過 subscription token 使用 Claude——OpenCode、Cline 等工具一夕失效。再往前看，2025 下半年 Anthropic 停用了 145 萬個帳號，其中只有 1,700 個申訴成功翻案。
當你的整個團隊依賴單一 AI 供應商，你就有了一個 single point of failure。 這不是技術問題，是營運風險。
這篇文章用的是 Claude（cloud API），但 OpenAB 不綁定任何一家。config.toml 裡換一行 command，就能切到不同的 agent backend。
我之前為了讓地端 AI（Ollama）也能接入 ACP 生態，自己用 Rust 寫了一個 acp-bridge——把 OpenAI 相容 API 轉成 ACP 協議。現在這件事更簡單了，OpenCode 原生支援 ACP，直接 opencode acp 就能把地端模型接上 OpenAB，不需要額外的 bridge。
┌─────────────────────────────────────────────────────────────┐
│ │
│ Agent Backend Options │
│ │
│ Cloud: │
│ ├── Claude Code (claude-agent-acp) │
│ ├── Codex (codex --acp) │
│ ├── Gemini (gemini --acp) │
│ └── Copilot (copilot --acp --stdio) │
│ │
│ Local: │
│ ├── OpenCode (opencode acp) ← Ollama, local models │
│ └── acp-bridge (legacy, Rust) ← OpenAI-compatible API │
│ │
│ Same OpenAB. Same MCP. Same Discord. │
│ Only the brain changes. │
│ │
└─────────────────────────────────────────────────────────────┘
這意味著什麼？同一套 OpenAB + MCP 基礎設施，白天用 Claude 跑高精度任務，晚上切到地端模型跑不能外洩的內部資料。 程式碼不用改、MCP server 不用改、Discord 頻道不用改——換一行 config 就好。
對企業來說，這就是 no human code 的起點：
PRD (Notion)
↓ AI reads
Tickets (Linear/Jira)
↓ AI reads design
Spec (Figma)
↓ AI generates
Code (GitHub PR)
↓ Human reviews
Production
Where's the human coding? Only at the review gate.
不是「AI 取代工程師」。是工程師從寫 code 變成 review code，從執行者變成品質守門人。前端工程師的價值不在打字速度，在於你知道 AI 產出的東西哪裡會出錯。
產品的下一個形態：不只是 UI，是 MCP + ACP 介面
再往遠一點看。
過去 20 年，企業推產品的標配是：前端 + 後端 + UI/UX。使用者透過瀏覽器或 app 操作介面，介面呼叫 API，API 存取資料庫。
但當 AI agent 成為主要的「使用者」時，介面不再是 UI，而是 MCP server。
┌─────────────────────────────────────────────────────────────┐
│ │
│ Past: Product = UI + API + Database │
│ │
│ Human ──► Browser ──► REST API ──► Database │
│ │
│ Future: Product = MCP Server + ACP Interface │
│ │
│ Human ──► ACP ──► AI Agent ──► MCP ──► Service │
│ │
│ The "frontend" is the AI agent. │
│ The "API" is the MCP server. │
│ The "UX" is the prompt design. │
│ │
└─────────────────────────────────────────────────────────────┘
Figma 已經推出官方 MCP server。Atlassian 也有了。Notion、Linear、GitHub 都有了。他們不是在做慈善——他們在搶佔 AI agent 的入口。
當你的產品沒有 MCP server，AI agent 就碰不到你。你的服務就不存在於 AI 的工作流裡。就像 2010 年沒有 mobile app 的公司，使用者在手機上找不到你。
未來企業推產品時要思考的不再只是「UI 好不好用」，而是：
我的服務有 MCP server 嗎？ AI agent 能不能直接存取？
我的服務支援 ACP 嗎？ 能不能被編排進 multi-agent workflow？
我的 MCP 權限模型設計好了嗎？ 哪些資料可讀、哪些可寫、scope 怎麼切？
這才是 MCP + ACP 真正的戰場——不是工具串接，是產品架構的根本轉變。
這篇文章用 Figma + Jira 這兩個最多人用的工具當切入點，但真正的故事更大。下一篇我會介紹如何在地端建置完整的 AI agent 基礎設施——Ollama + OpenCode + OpenAB，零雲端依賴，完整資料主權。再下一篇，Notion → Linear 的 pipeline。
敬請期待。
從 OpenClaw 的 No 到 OpenAB 的 Yes
半年前的結論：AI generates. Humans authorize.
這個原則沒有變。變的是工具成熟了。
OpenClaw 要你把整台電腦的控制權交出去。OpenAB + MCP 讓你精確定義 AI 能碰什麼：Figma 唯讀、Jira scoped API、不碰檔案系統、不碰 shell。同樣的能力，安全的邊界。
Design handoff 不應該是人工作業。設計師的時間應該花在設計，PM 的時間應該花在決策，工程師的時間應該花在寫 code——不是花在對 spec、抄顏色、手動開票。
不完美。Rate limit 會卡、MCP 設定會踩坑、AI 讀 Figma 偶爾會漏東西。但這是一個方向——讓重複的事情被自動化，讓人專注在需要判斷力的事情上。
專案開源：
English：English Article
Blake Hung — 9 年前端工程師，定義架構、用 AI 實作。用 Rust 和開源工具建構 AI agent ecosystem，OpenAB contributor，acp-bridge 作者。上一份作業是拒絕 OpenClaw，這一份是讓 AI 在安全邊界內做有用的事。下一份——地端 AI 基礎設施，然後 Notion 和 Linear。
