超越 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 评论形式出现在已构建完成的工作上时––这正是让工程师心灰意冷、让设计师倍感沮丧的原因。
将信号情报直接发送到您的收件箱。