2026-10-17

上下文才是新的设计稿（Figma Specs 和"同一份文档"这件事）

Figma Specs 把 Markdown 变成团队与编码 Agent 共读的“真相文档”，配合 MCP 形成闭环。

大多数团队以为自己缺的是更好的 AI。

不是。

他们缺的是一份大家都在读的文档。

散落的 Markdown

这两年，几乎每个和编码 Agent 打交道的人都养成了一个习惯：写 .md。

• 给 Agent 的项目说明，一个 .md
• 产品需求，一个 .md
• 设计规范，又一个 .md

写的时候很认真。

然后它们就躺在某个人的本地文件夹里。

设计师看不到工程师那份。工程师看不到 PM 那份。Agent 只能读到你那天恰好粘进 prompt 里的那一份。

结果是这样的：每个人都在给机器喂上下文，但没有人在维护同一份上下文。

这不是工具问题。

这是一个默认习惯：把上下文当成一次性的输入，而不是一份需要多人维护的资产。

你给 Agent 什么，它就成为什么。你给它五份互相矛盾的文档，它就成为五个互相矛盾的同事。

（这句是我自己的概括，不是 Figma 的话。）

Figma 做了什么

据 Figma 官方博客 10 月 15 日的文章《Introducing Specs: Markdown as a medium》，Figma 推出了一个叫 Specs 的东西。署名的有三位：PM Luke Zhang、技术负责人 Johnny Dallas（博客称他 2026 年初随 Gather.town 团队加入）、设计 Aosheng Ran。

说白了：Markdown 被搬到了画布上。

据官方博客和帮助文档，用法是这样的：

• 把任意 .md 文件拖到画布上，它就成为一个 Spec
• 按 D 键，或者点工具栏图标，可以新建一个
• Spec 里能嵌 FigJam 文件、frame，或者任意画布节点
• 文字和设计并排放，不再是"文档在这边，图在那边"

然后是 Agent 那一层。

据官方博客，Figma agent 能读写 Spec 里的评论。你可以让它对每一条没解决的评论回复修改建议，每段对话单独成一个线程，可以并行跑。

还有连接器：

• 用 GitHub 连接器，从代码库起草技术 spec
• 用 Hex 连接器跑数据分析，把结果作为评论贴在对应的问题旁边

最后是交付。复制 Spec 的链接，放进编码 Agent 的 prompt。据官方博客，通过 Figma MCP server，Markdown、frame 引用、图表、code layers、Code Connect 片段会一起被带过去。博客配图里举的例子是 Codex。

真正的变化不在功能

功能清单谁都会列。

值得注意的是 Figma 换了一个默认假设。

过去的假设：设计稿是真相，文档是附件。

现在的假设：文档是真相，设计稿嵌在文档里。

这听上去只是顺序问题。

但它决定了 Agent 读到的是什么。

一个编码 Agent 看不懂"你懂的"。它看不懂会议上那句"这里再圆一点"。它只读得懂写下来的东西，以及写下来的东西指向的那些节点。

所以在 Agent 时代，谁拥有那份被读的文档，谁就拥有方向。

这就是 taste 落地的地方。

生成已经很便宜了。代码能生成，界面能生成，文案能生成。稀缺的是判断：做什么，不做什么，边界在哪里，哪条评论该采纳。

这些判断如果只存在于你的脑子里，Agent 就用不上。

写进 Spec，它就成了团队的、也是机器的上下文。

一个闭环

据 Figma 官方博客的描述，Figma 工程师 Noah Finer 做 Specs 这个功能本身时，走的就是这条路：

1. 先写 spec
2. 嵌进 FigJam 流程图
3. 收同事的评论
4. 通过 MCP 交给编码 Agent
5. 一边写代码，一边用 MCP 把进展回写到 spec

注意第 5 步。

文档不是交出去就结束了。它是活的。代码在变，文档跟着变。

博客还提到 Intuit 的设计师 Mark Harvey 用 Spec 给一套新图标集做文档，研究员 Mike Blight 把它用在"探索、汇总、继续"的循环里。这些都是 Figma 自己挑出来的用例，当作参考就好，不是第三方调研。

MCP 那一侧也写得很具体。据 Figma 的 MCP skills 帮助文档：

• figma-spec skill 让 Agent 能读、建、改 Spec，不管 Spec 是单独的文件，还是嵌在 Design 或 FigJam 文件里
• 修改是定点改，不是整篇重写，评论会保持挂在原来那段文字上
• 写入需要远程 MCP（https://mcp.figma.com/mcp）和这个文件的编辑权限
• Spec 的评论工作流，文档写的是"即将支持"，现在还不能当成已有功能

"定点修改而非整篇重写"这一条，我觉得是整套设计里最有分寸的地方。

整篇重写意味着每次 Agent 动手，人都得重新读一遍全文。

定点修改意味着人只需要看改了哪一段。

前者让人变成校对员。后者让人留在导演的位置上。

怎么用它才不浪费

如果你只是把它当成"画布上多了个文本框"，那它就只是个文本框。

下面几条是我的建议，不是 Figma 的官方用法。

1) 先写判断，再写需求

需求谁都写得出来："做一个设置页"。

判断才有价值："设置页只放三个开关，其余的都藏进高级选项，因为我们的用户不喜欢被选择淹没"。

Agent 能执行需求。只有判断能让它做对。

2) 把评论当成决策日志

评论不是用来聊天的。

每一条被解决的评论，都是一次被记录下来的取舍。Figma agent 能读写这些评论，意味着这份日志也会成为它的上下文。

写评论的时候，假设下一个读它的是一个对项目一无所知、但执行力极强的同事。

3) 一份 Spec，一个方向

不要把五个功能塞进一份 Spec。

上下文越杂，Agent 越会平均用力。平均用力的结果，就是平庸。

4) 让代码回写文档

Noah Finer 那个闭环的关键不是"交给 Agent"，而是"回写"。

如果代码改了，文档没改，下一个 Agent 读到的就是过时的真相。

过时的真相比没有真相更危险。

现在能用到什么程度

据 Figma 官方博客，Specs 目前是 open beta，覆盖 Web、桌面和移动端，正在向付费计划逐步开放，未来几周陆续到账。

同一周还有几件相关的事，也都来自 Figma 官方：

• code layers 进入 open beta，可以用 Extract designs 把代码原型的状态转回可编辑的设计层
• Figma agent 正式 GA
• MCP 新增 20 个集成

拼在一起看，方向很清楚：设计、文档、代码之间的那堵墙，Figma 想把它拆成一条双向的路。

能不能拆成，要看 beta 之后的实际体验。现在下结论太早。

最后

工具在变得越来越聪明。

但聪明的工具会放大一切，包括你的混乱。

如果你的团队有五份互相矛盾的 .md，再好的 Agent 也只会更快地把矛盾写成代码。

所以问题从来不是"用哪个 Agent"。

问题是：你们有没有一份所有人，包括机器，都在读、都在改、都承认的文档？

如果没有，先写那一份。

其他的，都可以晚一点。

来源：Figma 官方博客；Figma 帮助中心。Specs 目前为 open beta；Spec 评论工作流为官方所说“即将支持”，并非现有功能。