本地代码入口看不到，或预览一直空白？
本周先确认账号已获准、能使用 Mac 版 Beta 桌面应用且有仓库权限；三项齐备后，再按“连接仓库—小范围改 UI—检查差异—建分支并提 PR”推进。截至 2026 年 10 月 7 日，这项能力仍是逐步开放的闭测功能；Windows 用户可考虑通过远程 Mac 使用所需的 Mac 应用，但 PR 仍必须经过团队原有的工程评审。(Figma 官方测试版说明)
这篇适合已获测试资格、要修改现有网页界面的设计师，以及需要临时使用 Mac 版 Beta 应用的 Windows 协作者。
负责审核的工程师或产品负责人，也可以用本文核对仓库配置、分支交接和人工审核责任。
最后更新于 2026 年 10 月 7 日；资格、平台支持和操作流程核对自 Figma 官方帮助中心及官方博客。测试版规则可能调整，开始前请重新确认当前页面。
先判断这项本地代码能力是否适合当前任务
Figma Make 本地代码功能针对的是已有网页项目中的 UI 修改与协作，不是从零开发一款应用，也不是处理后台、API 或基础设施任务。官方将该能力列为闭测，并说明需要已获准的账号和 Mac 版 Beta 桌面应用；测试资格通过逐步开放方式发放，提交申请不代表一定获准。(Figma 本地代码功能介绍)
先按下面的分支做决定：
- ✅ 账号已获准、Mac 版 Beta 应用可用、已有仓库权限，任务是调整现有网页界面：继续按本文流程操作。
- ⚠️ 还没有获准，或只有 Windows 电脑：先确认账号状态和 Mac 环境；远程 Mac 可能满足应用运行环境，但不能代替 Figma 资格审批。
- ❌ 任务涉及新建应用、后台逻辑、API、基础设施或大型架构改动：不要把闭测功能当成完整开发方案，改由工程团队按既有流程处理。
| 开始前要核对 | 继续的条件 | 不满足时的处理 |
|---|---|---|
| Figma 账号 | 该账号已获得本地代码闭测资格 | 查看账号关联邮件或官方资格说明；未获准就先暂停 |
| Mac 环境 | 可运行 Mac 版 Beta 桌面应用 | Windows 用户评估远程 Mac；不要默认网页版能完成本地代码流程 |
| 目标仓库 | 有权访问团队指定的 Git 仓库 | 请仓库管理员开通权限，不要只凭仓库地址尝试克隆 |
| 任务范围 | 修改现有网页中的界面 | 后台、基础设施和新应用任务转给工程师 |
仓库接入前：确认谁负责一次性配置
能打开仓库网页，不一定意味着应用能成功启动项目。设计师需要有代码库访问权限；此外，每个仓库通常还要由工程师完成一次性设置，让应用知道如何安装依赖、启动开发服务器并确认预览已就绪。Figma 的设置文档将 GitHub 列为原生支持，并说明 GitLab、Bitbucket 在闭测期间通过 SSH 提供部分支持。(Figma 本地代码设置说明)
| 代码托管平台 | 克隆与推送分支 | PR 操作 | 开始前要留意 |
|---|---|---|---|
| GitHub | 应用内支持 | 可在应用内创建 | 组织管理员需完成相应应用授权；用户仍要完成自己的身份验证 |
| GitLab | 通过 SSH 部分支持 | 需转到平台网页创建 | 检查 SSH 认证和项目访问权限 |
| Bitbucket | 通过 SSH 部分支持 | 需转到平台网页创建 | 检查 SSH 认证和项目访问权限 |
以上是当前闭测的支持边界，不代表平台以后会一直保持相同功能。GitLab 与 Bitbucket 的 PR 创建需回到各自平台；平台帮助文档分别介绍了网页端创建合并请求或拉取请求的操作。(GitLab 创建合并请求说明) (Bitbucket 创建拉取请求说明)
权限、预览和配置是三类不同问题，建议分开排查：
- 仓库页面提示无权访问或出现 404：先请仓库所有者确认账号是否被授权。
- 仓库能克隆但预览无法加载：请工程师核对仓库根目录的
.figma/make配置与项目启动流程。 - 页面能打开却不是目标项目：核对预览网址和开发服务器端口；其他项目已占用同一端口时，预览可能指向错误的开发服务器。(Figma 本地代码设置与排障说明)
第一步：用本地仓库或远端克隆打开项目
启动 Mac 版 Beta 桌面应用后，按手头项目状态选择入口：
- 项目已在当前 Mac 环境中：在 Make 文件中选择打开本地文件夹，启动新会话并选中项目目录。
- 需要从远端取得项目：选择克隆仓库，输入仓库地址并选定本地保存位置。私有仓库必须由当前账号获准访问。
- 首次接入该仓库：如果应用提示添加配置文件，先确认这是团队认可的仓库配置，再按提示运行设置。
- 等待预览加载：确认出现的是目标项目，而不只是一个能显示内容的页面。
- 预览未自动出现：先检查配置脚本、依赖安装和开发服务器状态，再核对预览地址；不要把启动失败直接归因于界面改动。
本地仓库和远端克隆是不同入口，但都依赖有效仓库权限与可运行的项目配置。若项目需要额外服务、交互式启动确认或工程师掌握的密钥，应先让工程师处理，不要绕过团队访问规范。
第二步：先对照真实页面，再发起小范围修改
预览加载后，先在目标页面找到需要修改的具体组件。属性面板适合调整布局、颜色、字体和间距；画面标注适合指出某个元素及其上下文；自然语言描述则可补充交互意图。Figma 的官方介绍覆盖了这些方式，但生成结果仍要以实际页面和代码差异为准。(Figma Make 工作流案例)
可以把任务写成“位置＋现状＋目标＋限制”，例如：“只调整商品卡片的标题与按钮间距；保留现有组件结构、颜色变量和移动端布局。”先改一个边界清楚的界面问题，预览通过后再开始下一个。这样一旦出现意外变更，更容易定位是哪次操作造成的。
修改后做两轮核对：
- 看页面：文字是否溢出，间距和层级是否符合目标，交互状态是否仍合理。
- 看代码差异：改动是否落在预期组件与文件，是否误改共享组件、依赖文件、环境配置或无关页面。
预览截图不能证明代码只影响当前画面。一个组件可能被多个页面复用；若差异触及共用组件，先让工程师确认影响范围，再决定是否继续。Figma 的工作流案例也展示了看似局限于单页的控件可能被多个流程复用。
第三步：检查本地提交，确认分支再推送
分支可以把这项改动与团队主线隔离；提交记录则保存每次代码变更的节点，方便回看和追踪。Figma 说明，本地修改会保留为本地提交，建立 PR 后仍由团队按原有开发流程审核。
提交前按顺序检查：
- [ ] 分支名称能让工程师看懂，例如
fix/product-card-spacing。 - [ ] 变更范围与任务描述一致；发现无关文件时，先停下来查原因。
- [ ] 页面关键状态已在预览中复核，包括修改前后涉及的状态。
- [ ] 运行项目已有、且与本次改动相符的检查；不确定命令时先问工程师。
- [ ] 提交说明写清改了什么，不把未经核实的行为描述成已完成。
应用内为改动记录提交，并不代表团队已经审查或批准它。不要直接把改动合并到主分支，也不要把自动生成的代码视为可免检代码。团队可以在 PR 中查看文件、差异和提交记录，并要求修改后再审。(GitHub 审查拉取请求说明)
第四步：按平台创建 PR，并把交接信息写完整
在 GitHub 上，闭测功能支持从应用内创建 PR；GitLab 和 Bitbucket 则需要先推送分支，再前往对应平台网页创建请求。不要因为三者都使用 Git，就把应用内的操作路径当成通用做法。
PR 描述建议包含以下内容：
- 分支名与目标分支：明确本次改动从哪里来、准备合入哪里。
- 改动摘要：写明修改了哪个界面元素，以及预期解决的问题。
- 验收信息：附上有助于评审的预览截图或页面说明，并列出已执行的项目检查。
- 待确认事项：标注组件是否复用、交互是否需工程师确认，以及尚未验证的状态。
PR 是请求团队审查代码改动，不是自动发布。审阅者仍需查看差异、留言、批准或要求修改；修改后的提交也要继续经过团队流程。
Windows 设计师要不要用远程 Mac？
如果你以 Windows 为主力设备，但已获本地代码测试资格，且项目必须通过 Mac 版 Beta 应用完成，可把远程 Mac 作为运行环境候选。它不能补发资格，也不能自动解决仓库授权、团队安全策略或代码评审责任。
- 若账号已获准、仓库权限已确认，且只是短期处理界面改动：可先评估临时 Mac 环境，再用一个范围明确的网页任务验证完整流程。
- 若账号未获准或组织登录方式受限：先处理资格与身份验证，租用 Mac 本身不会消除这类限制。
- 若项目依赖本地设备接口、需持续处理大型代码任务，或团队要求特定本地环境：先比较本地 Mac 与远程工作的适配度，不要预设远程环境必然合适。
- 若需要稳定、长期的专用环境：比较自购 Mac 与按需使用的成本和维护责任；是否值得租，取决于实际使用频率与项目要求。
我们不会在没有代表性项目实测的情况下，替远程 Mac 的连接体验、应用可用性或文件交接作性能承诺。准备评估时，可先查看 MESHLAUNCH 的 Mac 环境信息，并对照 MESHLAUNCH 服务页面确认实际服务说明。若测试资格、仓库权限和任务边界都满足，远程 Mac 才是 Windows 设计师尝试这段 Mac 工作流的候选方式；PR 的代码检查、评审与发布仍应由团队负责。