如何將 Figma 留言接到 Linear Issue
把設計回饋和工程任務接起來 – 把 Figma 留言連到 Linear issue，不再手動在分頁間複製貼上情境。
By Ellis Keane · 2026-03-31
大概是在我第四次看到設計師留了一串很完整的 Figma 留言，結果坐在三公尺外的工程師兩天後又開了一張幾乎一樣的 Linear issue 時，我就不再把這件事當成溝通問題了。這是管線問題。這兩個工具之間的管路，根本不像大家以為的那樣存在。
原生的 Figma Linear 整合有提供連結嵌入和從 frame 建 issue 的外掛，這些都很實用。但那種「Figma 裡一串按鈕 hover state 討論，默默變成兩週工程黑洞，直到 sprint retro 才有人把點連起來」的情境 – 這個缺口，多數工具其實沒補到。這篇就在講這件事：如何把 Figma 留言接到 Linear issue，而且不靠某個人記得去做。
Linear 的 Figma 整合到底做了什麼（還有沒做什麼）
原生整合真正做得好的就兩件事，其他基本沒有。
Linear 內嵌 Figma 連結。 把 Figma URL 貼到任何 Linear issue 或留言中，它會轉成可互動預覽。要注意一個點：Linear 文件提到，App 內可互動預覽只支援公開分享的 Figma 檔。私有設計檔（也就是大多數情況）通常只會顯示縮圖加靜態連結。
Figma 的 Linear 外掛。 在 Figma 裡就能建立 Linear issue，並自動連到特定 frame、page 或 section。team、status、assignee、project 都可以直接設，不用切分頁。也可以連到既有 issue，當設計變更碰到進行中的工作時特別好用。
Linear 的 Figma 整合是一座單向橋：它很會把設計情境推進 Linear。它不會把工程情境拉回 Figma，也不會自動把兩邊留言串連起來。
它做不到的事：
- Figma 留言不會自動建立 Linear issue。每次都要有人手動跑外掛。
- Linear issue 更新不會回流到 Figma。工程師改了狀態、加了 blocker、調整範圍，設計師不主動去看 Linear 就不會知道。
- 沒有跨工具搜尋。「我們到底在哪裡討論導覽改版？」可能在 Figma 留言、Linear issue，或者（老天保佑）兩邊都有。
設定 Figma 到 Linear 的工作流程
整體設定大概三分鐘。完整版本看 Linear 的 Figma 整合文件，這裡給短版：
- [ ] 在 Linear workspace 設定中啟用 Figma 整合（兩邊都需要 admin 權限）
- [ ] 從 Figma Community 安裝官方 Linear 外掛（避免第三方版本 – 常在 API 更新後壞掉）
- [ ] 測試：選一個 frame，執行 Linear 外掛建立 issue，確認有回連到該 frame
- [ ] 測試：把 Figma 檔案連結貼進 Linear issue，確認嵌入有正常渲染
- [ ] 檢查設計檔分享權限 – 私有檔案只會顯示靜態連結，不是可互動預覽
這能解決最直覺的路徑：設計師看見任務，設計師開 issue，工程師拿到情境。問題通常出在「留言當下還看不出是不是任務」。
分類問題才是關鍵
這個情境，幾乎會打爆我看過的每一套 Figma 到 Linear 工作流程：
設計師在 frame 留言：「這個 loading state 沒有涵蓋我們聊過的 empty state，要不要補 skeleton screen？」三個人在 Figma 串裡回覆，決策也做了。結果沒人開 Linear issue，因為當下看起來比較像設計討論，不像任務。
兩個 sprint 後，工程師把功能做完但沒做 skeleton screen。QA 提 bug。大家在 Slack 花二十分鐘追「這件事到底討論過沒」。有 – 在 Figma，而且留言串還在，只是已經 resolved、也被忘了。
title: "一則 Figma 留言如何變成 Sprint 阻塞" 10:14 AM|ok|設計師在 Figma 留下 hover state 留言 10:32 AM|ok|Figma 留言串兩則回覆，團隊達成共識 10:33 AM|missed|沒有建立 Linear issue – 當下被視為設計討論 Day 3|ok|工程師完成功能，但沒有做該變更 Day 8|amber|QA 回報缺漏行為為 bug Day 8|missed|Slack 花了二十分鐘才重新找到 Figma 留言串
問題不是大家忘記用 Linear 外掛。真正的問題是設計回饋本來就有光譜，而「這是不是任務」通常是事後才被判斷，常常要等到有人發現東西沒做。
三個實用判斷： 看一串 Figma 留言時，問三件事：（a）它是否影響既有 Linear issue 的驗收標準？（b）它是否描述了還沒有人提報的新工作？（c）它是否包含會改變範圍的決策？只要任一為是，就該轉成可追蹤 issue。這不會 100% 命中，但能讓團隊對「這則留言很重要」有共同語言。
真的有效的是什麼（還有沒效的是什麼）
建議組合：原生外掛 + 輕量慣例 + 安全網。 當設計師已經明確知道是工作項目（元件要更新、bug 要提、頁面要新做）時，先用 Figma 的 Linear 外掛。再加上一個簡單留言慣例（我們團隊會用 Action: 前綴，或直接 tag 對應工程師）去標註意圖，不要引進太重流程。同時要接受有些事一定會漏掉 – 建一個每週檢查：把最近 Figma 留言串和 sprint board 一起看，找出超過一週仍未解決、且可能對應既有 issue 的討論。這是完美解法嗎？不是，它是人工止血方案 – 但這是我目前用過最可靠的人工止血方案，也能幫你撐到分類層可以自動化。
有效的做法
- 明確任務走原生外掛 – 設計師確定是任務時，Linear 外掛最快最直接
- 留言慣例 – 用
Action: 或 @工程師 這種簡單標記傳達意圖
- 每週留言–看板對照 – 把未解 Figma 留言串對照 sprint board
常見失敗
- 大規模人工分流 – 忙碌 sprint 期間，靠人類判斷每則留言很容易崩
- Zapier 關鍵字自動化 – Figma webhook 事件很多（回覆、resolve、表情反應），噪音高，過濾規則維護成本大
- 直接忽略缺口 – 期待大家「兩邊自己看」不是策略
替代方案：Zapier 或 Make。 你可以設定「有新 Figma 留言就建 Linear issue」。實務上的難點是 Figma webhook 會噴大量留言事件 – 回覆、resolved thread、emoji 反應都會觸發。過濾不夠就會把 Linear 淹沒，變成每個人按個讚都開一張 issue，這種「進展」絕對讓你懷疑職涯選擇。過濾做太多，又會落入規則維運地獄，regex 逐漸和團隊真實留言習慣脫節。小團隊、留言模式固定時可行，但通常最後會變成某個人的兼職維運工作。
替代方案：語意訊號情報。 與其把每則留言都路由成 issue，不如用能理解兩邊語意的系統，判斷 Figma 留言串是否和既有 Linear issue 重疊，或新留言是否暗示未被追蹤的工作。這就是我們在 Sugarbug 做的方向 – 原生擷取 Figma 與 Linear、分類兩邊訊號，透過知識圖譜浮現連結，讓設計討論和工程任務的關聯不再靠人記得按按鈕。
目標不是把每則 Figma 留言都變成 Linear issue。而是當留言真的代表工作時，這個連結不需要靠任何人的記憶。 attribution: Chris Calo
常見問題
把訊號情報送進你的收件匣。
Q: 我可以直接從 Figma 留言建立 Linear issue 嗎？ A: 可以，但不是自動。你要先安裝 Figma 的 Linear 外掛，而且每次都要有人手動執行。它能把 issue 連到特定 frame，也可設定 team、status、assignee、project，不用切分頁。真正的缺口是：當下看起來不像任務的留言，通常不會有人主動建單。
Q: Sugarbug 會自動把 Figma 留言接到 Linear issue 嗎？ A: Sugarbug 原生擷取 Figma 與 Linear，分類各自訊號，並透過知識圖譜把兩邊連起來。當 Figma 留言提到 Linear 正在追蹤的工作時，Sugarbug 會自動浮現這個連結，不需要手動綁定。
Q: 為什麼 Figma 留言通知不會出現在 Linear？ A: 因為現在是單向整合。Linear 可以嵌入 Figma 預覽，也能透過外掛建立 issue，但 Figma 留言串不會流進 Linear 當通知。更新也不會鏡像回去 – 若工程師改了 issue 狀態，設計師還是得自己去 Linear 看。
Q: 我要怎麼判斷哪些 Figma 留言該變成 Linear issue？ A: 用三個判斷：它是否影響既有 issue 驗收標準？是否描述了還沒人建立的新工作？是否包含改變範圍的決策？任一為是，就建議放進 Linear 追蹤。