腾讯设计

中文

English

中文

English

外观

本地 MCP 免费打通 Claude + Kimi：双端开发者的同源实战 ​

本文来自「Ardot 案例征集活动」｜作者：独立开发者 @郭子御

遇到了什么问题 ​

先说一个上游背景：这款相册 App 起初是纯 vibe coding——根本没有设计稿，UI 全靠 AI 直出。短期内确实快，但很快 UI 就极度发散、不可控：同一个页面两种圆角、三套绿色，AI 每次都在旧代码上继续自由发挥。

我这才意识到必须把 UI 的事实来源（SSOT）从代码手里夺回来，转移到设计稿 + design tokens 的描述里。

于是我尝试从 Android 代码反向还原出一套设计稿放进 Figma，却很快撞上 Figma 的瓶颈（见下方第三个痛点）；直到找到 Ardot 才把设计稿完整还原出来，再由设计稿正向实现 iOS 端。此后双端就按「Android 定稿 → 画布固化 → iOS 跟随」的节奏持续迭代，Ardot 完全胜任了这种工作模式。

具体来说，双端 + AI 编程的开发模式下，三个痛点越来越尖锐：

  • UI 一致性失控——Android 改一处间距，iOS 忘同步；AI 助手「读对端源码翻译」的对齐方式被证明不可靠，两端实现互相污染。
  • 规范文档腐化——色值、圆角靠人工文档维护，没人更新，形同虚设。
  • Figma 通路贵且受限——Figma 其实也提供了 MCP / Dev Mode 同步能力，但绑定付费席位、调用受限，对独立开发者成本过高；多数时候 AI 还是只能看我手动贴的截图，信息损耗巨大。

解题思路：四个关键判断 ​

没有急着找工具，先把问题拆开想了一层。四个判断决定了后面所有动作：

判断一：不一致的根因是「事实源不唯一」，不是人不细心

双端各看各的，靠自觉同步必然腐化。所以必须先有唯一事实源（SSOT）：画布定稿，iOS 只读设计规范，不读 Android 源码。

判断二：AI 读不到画布，一切「对齐」都是空谈

选设计工具的第一标准变成「AI 能不能低成本直接读」。Figma 的 MCP 要付费席位，而 Ardot 本地 MCP 免费不限次、画布数据能被 AI 原生消费，这是选它的决定性理由。

判断三：规范靠人维护必然形同虚设

要机器可校验才有约束力：变量双向 check、快照 diff 入版本库，让「设计变了」这件事本身可被 AI 感知。

判断四：迁移风险用试点控制

先迁一个文件验证组件和变量无损，再全量搬，不在第一步就 all-in。

想清楚这四点，后面的动作就是顺水推舟：迁移（Step 1）→ 立 SSOT（Step 2）→ MCP 打通（Step 3）→ 多模式验证（Step 4）。

怎么用 Ardot 解决 ​

Step 1 迁移：.fig 直接导入 ​

Ardot 支持导入 .fig 文件（客户端首页「导入文件」入口），我把 Figma 里的设计稿整体搬了过来，组件和自动布局基本无损，迁移成本比预想低得多。

迁移后的 Ardot 真实画布：商店宣传图按 EN / zh-TW / zh-CN 三语排布，右侧面板可见「本地 MCP · 已连接」

画布中的相册页设计帧与最终上架 Google Play 的同一页面

Step 2 确立 SSOT：画布即规范 ​

把 Ardot 画布定为唯一的 UI 事实来源（SSOT）：Android 页面定稿后，iOS 只读 Spec，不读对端源码。画布上覆盖相册、搜索、Chat、人物、设置、本地模型等全部核心页面。

Ardot 编辑器内预览：Editor 页承载全部核心页面设计帧，左侧为页面与图层树，右侧为属性面板

相机帧、Chat 帧、设置帧（均为画布导出）

Step 3 MCP 打通 AI 工具链（关键一步） ​

Ardot 提供 MCP 服务器（云端 / 本地双形态），我用本地 MCP（免费、不限次数，客户端打开设计文件即在后台提供服务），在 Claude Code 和 Kimi 两个 AI 编程工具里同时接入，让 AI 直接读画布。

3.1 两个工具各怎么配置 ​

本地 MCP 地址固定为 http://127.0.0.1:50501/api/v1/mcp。两个工具各加一段配置即可，半小时内全部跑通：

bash
# Claude Code：一行命令接入
claude mcp add --transport http ardot http://127.0.0.1:50501/api/v1/mcp
json
// Kimi：写入项目 .kimi-code/mcp.json
{
  "mcpServers": {
    "ardot": {
      "url": "http://127.0.0.1:50501/api/v1/mcp",
      "enabled": true,
      "toolTimeoutMs": 120000
    }
  }
}

配置后回 Ardot 右侧面板确认「本地 MCP · 服务状态：已连接」（见 Step 1 画布截图右栏），再让 AI 随便执行一句「在画布里创建一个红色矩形」验证连通。

3.2 围绕画布写了三个自动化脚本 ​

三个脚本本身是在这条流水线里由 AI 辅助编写、我逐行 review 后提交入库的——这也印证了标题：AI 不只消费画布，也参与搭建消费画布的管道。

bash
# 画布快照导出：多页聚合为 manifest + 每帧 PNG，纳入 git
$ python scripts/export-ardot-snapshot.py
✓ exported 97 frames → docs/08-UI-SPECS/screens/refs/ardot/

# 设计变量双向校验：画布变量集 vs tokens 文件，零漂移才放行
$ python scripts/sync-ardot-variables.py --check
✓ PoLang Tokens: 0 drift

# 多语言预览：一键切换画布语言变量模式
$ ./scripts/ardot-preview-mode.sh --lang zh-TW
✓ canvas language mode → zh-TW

3.3 「0 drift」具体比对了什么 ​

项目里 token 的事实来源是 design-tokens.json，codegen 出一份 ardot-variables.json（337 个变量，Dark / Light 双模式）；脚本再通过 MCP 的 fetch_variables 把画布上的「PoLang Tokens」变量集拉下来，逐变量、逐模式比对色值与数值。任何一处画布手改或漏同步都会以 drift 报出，归零才允许发版。

3.4 一次真实调用长什么样 ​

以「给 iOS 实现相机页」为例，Claude Code 里的完整链路：

text
我  → 读当前 Ardot 画布的相机页帧，按设计稿生成 SwiftUI 代码
AI  → 调 fetch_editor_state      // 确认当前文件与页面
    → 调 batch_read(camera 帧)   // 拿到图层树：布局/尺寸/间距
    → 调 fetch_variables         // 拿到颜色/字号/圆角 token 值
    → 据此写出 CameraView.swift  // 色值全部来自画布变量，零手抄

同一份画布、同一个 MCP 地址，在 Kimi 里做同样的事：发同样的指令，走同样的 fetch_editor_state → batch_read → fetch_variables 调用链。两个 AI 读的是同一时刻、同一份画布数据，产出自然对齐——这就是「双 AI 同源」的字面意思。

画布中的图标规范表：双端统一 Material / SF Symbols 映射的事实来源，AI 直接经 MCP 读取

AI 实现 iOS 页面时，读的是快照这份唯一基准，而不是另一端的源码。

Step 4 多语言 + 暗黑模式，定稿阶段验排版 ​

利用 Ardot 的变量模式（Modes），同一帧切换 EN / zh-CN / zh-TW 三种语言（选中帧 → 右侧「变量表」面板切换 Language 模式，Step 1 画布截图右栏可见入口），文案在设计阶段就能暴露排版问题，不用等到端上才发现。

同一套机制也覆盖暗黑模式适配：画布上 337 个语义色变量全部绑定 Dark / Light 双模式值，切一下主题模式，整页暗色效果立刻呈现——暗色下的对比度、配图融合度、浅色崩色问题在设计稿阶段就全部验掉，而不是等 iOS / Android 真机各自踩一遍。

多语言与暗黑模式在定稿阶段完成验证

效果如何 ​

三个数字，各自对应一项 Ardot 能力的落地：

97 帧快照、337 变量零漂移、2 个 AI 工具同源

97 帧快照 ← 导出能力 + 本地 MCP

经 MCP 把全画布 11 个页面、97 个帧批量导出为 PNG + manifest 纳入 git，设计变更可 diff、可回溯，AI 也能感知「设计变了」。

337 变量零漂移 ← 变量（Variables）+ 多模式（Modes）

语义色、字号、圆角全部建成 Ardot 变量，并绑定 Dark / Light 双模式值；画布变量集与代码仓库的 tokens 文件双向校验，任何一处手改立即以 drift 报出，归零才放行。

2 个 AI 工具同源 ← 本地 MCP

Claude Code 和 Kimi 经同一个本地 MCP 地址读同一份画布，免费、不限次，谁写的代码都基于同一规范。

最值得单独说的是暗黑模式适配。过去暗色适配要双端各上真机踩一遍；现在 337 个语义色全部双模式绑定后，画布上切一次 Dark / Light 模式，对比度不足、配图不融合、浅色崩色全部当场暴露、当场修掉。这套设计稿落地双端后，暗色适配零返工——多模式变量把一个端上问题彻底前移成了设计问题。

双端 UI 走查从「凭记忆对截图」变成「快照 diff + 脚本校验」；一个人跑通了过去「设计 + 双端开发 + QA」四个角色流转的交付链路。

如今 App 设计图、产品网站设计图、Google Play 商店图三条设计工作流全部跑在 Ardot 上，组件抽象复用（图标、状态栏、输入框等一次建组件、处处实例化，改一处全局生效）。

有什么心得 ​

  • 迁移别怕——.fig 导入足够顺滑，先迁一个文件试跑，确认组件和变量无损再全量搬。
  • MCP 是分水岭——画布数据能被 Claude / Kimi 直接消费，设计稿才真正成为工程链路的一环，而不只是「图」。
  • 快照入版本管理——画布变更重跑导出、提交 diff，设计变更就有可回溯历史，AI 也能感知「设计变了」。
  • AI 时代规范更重要——AI 写码越快，错误扩散越快，只有机器可校验的 Spec（变量 check + 快照 diff）兜得住质量。
  • AI 设计工具的甜点区——vibe coding 项目的 UI 收束。代码堆得越快越需要一张「画布之上、代码之外」的事实源；能把生成、变量、MCP 打通的工具，正好接住这个需求。

Copyright © 1998-2026 Tencent. All Rights Reserved.