Figma Specs：把设计图和「为什么这样做」放在一起

Figma 是团队共同设计界面和原型的工具。设计图能展示按钮放在哪里、页面看起来怎样，却不一定说明点击以后应该发生什么。需求写在文档里，修改意见留在聊天中，开发者收到的可能只有一张画面。

Figma 在 10 月 15 日介绍的 Specs就是为这些说明提供一个共同编辑的地方。它可以单独成为文档，也可以放在 Figma Design 或 FigJam 画布上，与设计画面、流程图等材料相邻。已有的 Markdown 文件——一种用普通文本标记标题和列表的文档——也可以拖入画布。

它适合产品经理、设计师和开发者共同说明一项需求。例如报名页面不仅有一个「提交」按钮，还要说明人数满了怎么办、重复提交怎么处理。Specs 把这类决定放到画面旁边，方便共同查看和讨论。

官方帮助列出的支持范围是 Professional、Education、Organization 和 Enterprise；在文件内创建与编辑还需要文件编辑权限。Specs 处于逐步开放的公开测试阶段，符合条件的账号也可能还没看到入口。

先把要做的事写下来

以下用报名页面作为示例任务。在已有设计文件中，从工具栏选择 Spec，或按 D 创建。也可以先建立独立 Spec 文件，再放回画布。写清这次要解决的问题：让参与者提交报名，并知道是否成功。

1. 写出关键行为。 建议先列「填写、提交、成功、无法提交」几个情况，再补各自的提示内容。这是组织需求的一种方法，不是 Specs 自动生成的固定模板。
2. 把相关画面放到说明旁。 在 Spec 中输入 /，从内容块列表选择 Figma file embed 来嵌入文件；在 Design 或 FigJam 中，也可以把内容在 Spec 与画布之间拖动。将报名画面与说明对应起来。相比贴一张无来源截图，团队更容易找到正在讨论的设计对象。
3. 在具体位置讨论。 对「人数已满」的提示留下评论，说明要确认的问题。把讨论后的决定写回正文；保留问题与决定的区别，避免后来的人把一条建议当成已确定需求。
4. 按阅读任务切换视图。 需要比较说明和界面时留在画布；要连续整理长文时，点击 Spec 右上角的 View as scrollable page（滚动页面）或 Open full-screen editor（全屏编辑）。工具不要求长文一直挤在一小块画布里。
5. 交给实现者，再核对结果。 团队可以直接阅读 Spec。代码助手需要连接 Figma MCP，并使用 figma-spec skill 来读取相关说明，接入条件见官方指南。MCP 是让工具与 AI 交换资料的连接方式，skill 则是指导助手处理 Specs 的操作说明。交接时说明需要做的范围，完成后回到页面逐项检查报名流程。

官方指南说明，直接手工写作不消耗 AI 积分，使用 Figma agent 处理 Specs 则会消耗，数额与任务和读取资料有关。FigJam 中的相应规则，要等其 agent 开始消耗积分后才适用；不能把它当作所有外部代码助手的统一收费规则。先把自己的判断写清楚，再决定哪些整理工作交给 AI，有助于控制工作范围。

减少的不是文档数量，而是找关系的工作

同一句「这里要提示失败」，离开具体页面就很难理解。Specs 让文字、设计对象和讨论出现在同一工作环境中，读者可以沿着说明找到对应画面，再回来看理由。

这种关系对后来加入项目的人尤其有用。他们不必先猜「这里」指哪张图，才能理解决定。它仍需要团队整理：如果塞入所有旧稿，却没有说明哪些已采用，同一个地方也会变乱。值得借鉴的是把材料与用途对应起来，而不是尽可能把资料堆到一起。

让讨论可以变成可继续修改的决定

评论适合提出问题，正文适合保存当前决定。一个问题得到回答后，如果只藏在长长的评论串里，接手的人仍要重新梳理。Specs 提供共同写作和评论的环境，让团队可以把讨论结果归回说明。

在报名例子中，「满员以后是否允许候补」是待确认问题；团队确认后，正文应写成明确的行为。这个整理动作是人的工作。AI 可以参与讨论和汇总，但产品能容纳讨论，不等于所有分歧会自动解决。

同一份说明，可以按不同任务阅读

画布适合比较多个对象，全屏文档适合逐段写作。Specs 允许在两种阅读方式间移动，使说明既能贴近画面，也能独立读完。产品介绍强调的，正是规划、设计和实现之间的资料流动。

交给代码助手时，团队不必从零重新描述项目背景；仍要确认助手拿到的是本次要实现的内容。可借鉴的原则是：先让人能找到、读懂和修改决定，再把它作为 AI 的输入。说明越具体，检查最终结果就越有依据。