OpenCode Figma MCP 配置：连接设计文件前先做 7 个检查

Figma MCP 适合 OpenCode 在编码时读取组件名、选中 frame、间距、token、文案或设计系统意图。若设计稿尚未稳定、人工描述已经足够，或仓库里已有明确组件规范，就不必急着接入 MCP。

不要因为 MCP 看起来强大就安装。每启用一个 MCP 都会增加工具描述、认证面和上下文消耗。如果只是比较截图或写设计说明，Figma 链接加人工摘要通常更安全；如果团队经常把 Figma frame 落成代码，集成才更有价值。

博客、包列表或社媒里的命令都只能当线索，必须回到服务所有者的官方文档核对。第一次配置时，最关键的来源是 Figma Dev Mode MCP 说明和 OpenCode MCP 配置说明。端点、OAuth、Dev Mode 要求可能独立变化。

推荐顺序是：确认 Figma MCP 路径，确认 OpenCode 的 MCP 配置形态，决定写入全局配置还是仓库 opencode.json，再记录认证方式。这样能让实验配置保持可审计，不会悄悄变成没人维护的基础设施。

全局配置很方便，但会让 Figma 工具出现在每个 OpenCode 会话里。对设计集成来说，这通常不是最佳默认值。一个仓库对应一个产品或设计系统时，更适合项目配置；只有设计转代码 agent 需要 Figma 时，则放进 agent 范围更稳。

更保守的默认值是项目或 agent 范围。服务名用 figma_design 这类可读名称，不常用的条目保持 disabled，并记录它支持哪些 Figma 文件或团队。不要为了一个组件任务给出过宽团队级权限。

如果 Figma MCP 路径支持 OAuth，优先用 OAuth；如果官方文档要求 token，则用环境变量引用。不要把真实 token 写进 opencode.json。配置文件应该暴露服务名、header 名和意图范围，而不是暴露凭据本身。

需要 token 时，从能读取目标设计上下文的最小权限开始。如果 token 出现在日志、命令历史、截图或工单里，立即轮换。团队流程中，凭据归属和撤销路径比某个人的临时 token 更重要。

第一次验证必须是只读。运行 opencode mcp list，主动完成认证，确认工具可见，再让 OpenCode 总结一个已知 frame 或选中组件。先和 Figma 人工对照，再让它改代码；错误 frame、过期选择或权限缺失在写文件前更容易发现。

一条有用的验证记录应包含服务名、认证方式、测试用 Figma 文件或团队、只读 prompt、预期工具前缀和回滚命令。把这条记录放进项目 setup 文档，后续设计转代码失败时可以从证据开始排查。

1. 范围决定 Figma MCP 写入哪里
2. 认证通过 OAuth 或环境变量提供 token
3. 列出运行 opencode mcp list 查看工具
4. 只读先总结一个已知设计对象

好的提示词会说明设计对象、目标组件或路由、允许修改的文件和输出预期。例如：让 OpenCode 读取某个 Figma frame，对照现有 Button 组件，先给最小 diff 方案，再执行编辑。这比一句“把这个 Figma 页面做出来”安全得多。

让代码保持可审查：先要短计划，再做小改动，然后跑格式化或测试。若设计里间距、字体或状态不明确，要求 OpenCode 明确假设，而不是偷偷发明规则。设计上下文有价值的前提，是编码边界仍然清楚。

把问题拆成五层：Figma 访问、MCP 服务可用性、OpenCode 配置、模型工具可见性、仓库权限。401 多半是认证；看不到工具通常是配置或发现失败；设计回答含糊可能是文件错、选择过期或上下文里工具太多；代码 diff 坏了也未必是 Figma 的问题。

一次只改一层。先确认 Figma 源，再确认 MCP list/debug 输出，再跑只读 prompt，最后只改一个低风险组件。如果 agent 开始忽视设计约束，先禁用无关 MCP，再用更小上下文对比同一 prompt。

OpenCode MCP, OpenCode Ollama, OpenCode 会话存储. 当通用 MCP 页不足以处理 Figma 设计上下文时，使用这篇专门配置指南。