Figma Specs 开启公测：把需求、设计与 AI 编码上下文放到一起

当团队开始让 AI 参与产品开发，需求文档、设计稿和代码之间的关联会变得更加重要。Figma 于 2026 年 10 月 15 日推出 Specs，把书面需求与画布里的设计上下文放在一起，并开始分批开放公测。对于产品经理、设计师和开发者，这提供了一个值得试用的协作入口。官方发布说明。

Specs 把哪些内容放在一起？

根据发布说明，团队可以将 Markdown 文件拖入画布，并在规格文档中嵌入设计画框、FigJam 内容等上下文。团队确定方向后，可通过 Figma MCP 让编码代理读取规格及相关引用。这里的价值在于让文字说明与设计依据保持联系，减少交接时反复整理材料的负担。最后这一点是工作流层面的分析，实际收益仍需项目验证。功能与工作流介绍。

谁能用？需要注意哪些费用？

Figma 帮助中心列出的适用计划包括 Professional、Education、Organization 和 Enterprise；操作需要文件编辑权限。功能在未来数周逐步开放，同一团队成员可能在不同时间获得入口。

直接撰写或编辑 Specs 不消耗 AI credits；调用代理处理 Specs 会消耗额度，具体取决于任务和上下文等因素。帮助中心另注明，FigJam 中相关消耗随其代理额度机制启用而适用。因此，试用时应区分手动协作和代理调用，并以账户内当前规则为准。查看使用条件与额度说明。

建议从一个小需求开始试

以下是试用建议，方便团队检验它是否适合自己的流程。可以选择一个边界清楚的页面改动，例如优化列表筛选或增加表单提示，避免一开始就迁移整套文档。

1. 写清目标与不做的内容。说明用户遇到了什么问题、这次改动覆盖哪些场景，以及明确排除的范围。
2. 把设计依据放在需求旁边。附上相关画框或流程图，明确当前采用哪一个方案，避免代理自行挑选旧版本。
3. 先解决开放问题，再交给代理。字段含义、异常状态、权限和验收条件应由团队确认。缺少结论时，把它标记为待决事项。
4. 交接后检查实现与规格是否一致。用实际结果反向核对文档，并记录偏差原因，观察下一轮交接是否改善。

工具把上下文集中之后，仍需要明确责任

一份内容丰富的规格文档，也可能包含彼此矛盾的决定。团队仍需约定谁有权确认需求、哪个版本进入开发、代理修改由谁审核。接入代码库或其他资料时，还应检查访问范围，避免把与当前任务无关的数据交给代理。

评估 Specs 时，可以记录需求澄清次数、返工原因和从评审到交付的时间。比起只看生成速度，这些指标更能说明共享上下文是否真正帮助团队减少误解。