超越 Figma 評論的設計與工程交接
為何僅靠 Figma 評論無法彌合設計與工程交接的鴻溝，以及真正適合小團隊的有效方法。
By Ellis Keane · 2026-04-06
最好的設計與工程交接工具是工程師從不打開的那個
設計師在完善 Figma 交接上投入越多––auto-layout、design tokens、dev mode 注釋、元件文件––實際的設計與工程交接往往越糟糕。不是因為設計工作差––通常很出色––而是因為所有努力都存在於一個工程師勉強打開、快速瀏覽、然後關掉去建構他們以為自己看到的東西的工具裡。
我在兩邊都待過。我從設計師開始（嗯，「設計師」––我在新罕布夏州做典當行網站，所以對這個頭銜要寬容一點），現在為 Sugarbug 編寫大部分工程程式碼。設計與工程交接問題不是工具問題，而是工作流問題。資訊是存在的，只是在錯誤的時間出現在錯誤的地方。
典型的設計與工程交接大概是這樣的：設計師花三天時間打磨一個 Figma 框架，添加十二條解釋間距決策和邊緣案例的評論，@提工程師，然後等待。工程師打開 Figma，盯著框架看大約九十秒，心想「好，明白了」，關掉標籤頁，然後建構出一個 80% 正確、20% 錯誤的東西––那 20% 的問題要再花一週來回溝通才能解決。那十二條評論？最多讀了四條。
設計與工程交接不是扔過牆的檔案，而是需要存在於工程師工作場所的上下文––在 issue 裡、在 PR 裡、在程式碼裡––而不是他們只訪問一次的設計工具裡。
為何 Figma 評論不適合交接
我每天都用 Figma，而且真的很喜歡（這在這個時候大概已經是性格缺陷了）。但 Figma 評論是為設計師之間的協作優化的，而不是為設計與工程交接––這種差異比大多數團隊意識到的更重要。
根本的不匹配在於：Figma 評論在空間上錨定於框架和元件，它們存在於設計檔案內部。但工程師不在設計檔案裡工作––他們在 Linear issue、GitHub PR 和 IDE 裡工作。當設計師在框架上留下「這個下拉選單在 640px 以下的行動裝置視口應該收起」的評論時，這條資訊就被困在 Figma 裡了。它不會變成任務。它不會出現在工程師的工作流中。它存在於一個工程師必須記得去訪問的平行宇宙裡，而（這才是真正重要的部分）訪問 Figma 並不像查看 Linear 或審查 PR 那樣是工程師自然工作循環的一部分。
結果可想而知：關鍵設計決策丟失了，不是因為任何人粗心，而是因為資訊在錯誤的工具裡。就像在某人居家辦公時把便利貼留在他們的桌上。
設計師留下上下文的地方
- Figma 評論 – 空間錨定，附著於框架
- Figma dev mode 注釋 – 詳細但需要打開 Figma
- Slack 訊息串 – 對話式，一週後無法搜尋
- Design system 文件 – 全面但 sprint 中途很少被查閱
工程師真正查看的地方
- Linear issue 描述 – 開始前閱讀的第一件事
- GitHub PR 描述 – 實作過程中的參考
- 程式碼注釋 – 在 review 時發現
- IDE – 他們 90% 時間在的地方
真正有效的方法（來自兩者都做的人）
在過去一年建構 Sugarbug 的過程中，我既是設計師又是（主要是）工程師，這意味著我有過把工作交給自己卻仍然丟失上下文的不尋常經歷。如果我無法記住上週二自己的設計決策，一個獨立的工程師就更不可能從 Figma 評論串裡捕捉到所有資訊了。
以下是我們團隊設計與工程交接流程中真正有效的方法––沒有一條涉及寫更好的 Figma 評論。
1. 將設計決策寫入 issue，而不是設計檔案
在工程師開始建構之前，設計上下文需要存在於 Linear issue 中（或者團隊使用的任何工具裡）。不是附上「查看設計」的 Figma 檔案連結––那是一種逃避，每個人都知道。issue 應包括：
- 是什麼： 截圖或匯出的框架（不是 Figma 連結––而是工程師不用打開其他工具就能看到的 PNG）
- 為什麼： 關鍵決策背後的原因。「我們選擇了 slide-over 面板而不是 modal，因為使用者需要在編輯時參考列表」––一句話節省了三輪「為什麼不用 modal？」的往復
- 邊緣案例： 行動裝置上會怎樣？長文字會怎樣？沒有資料時會怎樣？如果你想到了，寫下來。如果沒想到，說出來（說實話，「我還沒想好空狀態」比沉默有用得多）
2. 設計審查在 issue 中進行，而不是在 Figma 裡
當我在實作過程中收到設計回饋時，我希望它在 Linear issue 訊息串裡，而不是作為一條我可能兩天都不會看到的 Figma 評論。issue 是我工作的單一可信來源––如果回饋在那裡，我下次查看 issue 時就會看到，而這每天發生好幾次。如果它在 Figma 裡，我只有在碰巧打開那個檔案時才會看到，而這可能永遠不會發生。
這不是說永遠不要用 Figma 評論。它們非常適合設計師之間的協作、注釋特定視覺細節，以及關於設計本身的對話。但一旦回饋變成了「工程師需要改變什麼」，它就需要轉移到工程工作流中。
stat: "大多數" headline: "當我們依賴 Figma 評論進行交接時，評論在 48 小時以上內未被看見" source: "我們團隊 3 個月非正式追蹤的經驗"
3. 用截圖而不是假設來關閉循環
設計與工程交接驗證最廉價的形式是截圖。當工程師完成一個元件的實作後，他們把截圖貼到 PR 或 issue 裡並@設計師。「這符合嗎？」花十秒鐘，並在發布前捕捉到 20% 的偏差。無需開會，無需 Figma 對比儀式––就是一張 PNG 和一個問題。
我們開始對每個 UI PR 都這樣做，「這與設計不符」的對話數量降到幾乎為零。剩下的對話是設計沒有覆蓋的真實邊緣案例，這沒問題––那是應該討論的事情，而不是「你用了 16px 內邊距而不是 12px」這類基礎問題。
4. 讓上下文在工具之間自動流動
這是我要提到 Sugarbug 的地方，因為我們就是為了解決這個具體問題而建構它的。我們的設計師在 Figma 裡留下關於間距變更的評論。Sugarbug 捕捉到該評論，將其關聯到相關的 Linear issue 和 GitHub PR，工程師在自己的工作流中看到它，無需打開 Figma。設計與工程交接不再是手動複製貼上的儀式，而是自然發生的事情。
但如果你沒有使用 Sugarbug（大多數人沒有，我們還在發布前），手動版本是：指派一個人擔任「交接橋梁」，每天查看 Figma 評論並將相關回饋複製到 Linear issue 中。這很乏味，但有效，而且比希望工程師記得查看 Figma 好得多。
如果我無法記住上週二自己的設計決策，一個獨立的工程師就更不可能從 Figma 評論串裡捕捉到所有資訊了。 attribution: Chris Calo
你的設計與工程交接檢查清單
如果你從這篇文章裡只帶走一件事，讓它是這個：解決方案不是更好的工具（至少主要不是––儘管我正在建構一個，所以請對此持保留態度）。解決方案是建立關於設計決策存放在哪裡的規範，並確保那個「哪裡」在工程師的自然工作流內部。
- [ ] 將關鍵框架作為 PNG 匯出到 Linear issue（不只是 Figma 連結）
- [ ] 在 issue 描述中為每個重大設計決策寫下「為什麼」
- [ ] 列出已知的邊緣案例（行動裝置、空狀態、長文字）––或明確標記尚未解決的內容
- [ ] 將實作回饋從 Figma 評論移至 issue 訊息串
- [ ] 在每個 UI PR 獲得設計審批之前要求截圖
- [ ] 如果沒有自動連接 Figma 和 Linear 的工具，指派一個「交接橋梁」負責人
常見問題
Q: Figma 評論為何無法勝任設計與工程交接工具？ A: Figma 評論存在於設計檔案內部，與工程工作流脫節。工程師在 Linear、GitHub 和 IDE 中工作––而不是在 Figma 裡。框架上的評論不會自動變成任務，除非有人手動複製，而那個手動步驟正是設計與工程交接失敗的地方。這不是人的問題，而是工具邊界的問題。
Q: Sugarbug 能自動將 Figma 評論關聯到 Linear issue 嗎？ A: 是的––這是我們建構它要解決的具體問題之一。Sugarbug 抓取 Figma 評論並將其關聯到相關 Linear issue 和 GitHub PR，這樣設計回饋就會出現在工程師的工作流中，無需任何人在工具間複製貼上。我們自己每天都在用，而且（說實話）考慮到這個想法有多簡單，效果好得有點不好意思。
Q: 小團隊最佳的設計與工程交接流程是什麼？ A: 在工程師開始建構之前，將設計決策寫入 Linear issue。包含原因，而不僅僅是視覺效果。如果在實作過程中出現邊緣案例，在 issue 訊息串中討論––而不是放在工程師需要專門去找的 Figma 評論裡。最簡單的流程往往是最持久的。
Q: 工程已經開始後，如何處理設計變更？ A: 像對待範圍變更一樣處理：在 issue 中記錄清晰的變更前後，解釋原因，並讓工程師在承諾之前評估實作成本。最糟糕的交接失敗發生在設計變更以隨意的 Figma 評論形式出現在已建構完成的工作上時––這正是讓工程師心灰意冷、讓設計師倍感沮喪的原因。
將訊號智慧直接發送到您的收件匣。