Flutter UI生成实战：用Cursor和MCP将设计稿转代码

Flutter项目写多了，你会发现一个很现实的问题：大部分UI开发时间并没有花在“设计”上，而是花在“把设计稿翻译成代码”上。尤其碰到那种间距差2像素、颜色换个透明度、字号调小一档的修改，来回折腾的纯粹是体力活。这个痛点在我用了Cursor配合MCP（Model Context Protocol，模型上下文协议）之后有明显改善。最近我花了几周时间，把团队的Flutter UI生成流程从“人肉翻译设计稿”改成了“AI读取设计稿结构+按企业规范生成代码”，整个过程里踩了不少坑，也沉淀了一套相对完整的落地方法，写出来和大家聊聊。

这套方案解决的核心问题是：AI能不能在理解设计稿的基础上，直接产出符合团队现有架构和代码规范的Flutter UI代码，而不是生成一堆“能看但没法用”的玩具代码。如果你所在团队已经在用Flutter，同时想引入AI辅助UI开发，或者你正在调研Cursor和MCP的实际用法，这篇内容应该能给你省下不少摸索时间。

1. 为什么是Cursor + MCP这套组合

1.1 Cursor到底解决了什么问题

先说说Cursor。很多人把Cursor简单理解成一个“内置了Chat的VS Code”，这个理解不算错，但低估了它。在Flutter开发场景里，Cursor真正值钱的是Agent模式，也就是它能跨文件、多步骤地理解和修改整个项目结构。比如我让它“给登录页加上Loading状态”，它不是只在当前文件里插一段代码，而是会去看你的状态管理怎么写的、Loading组件在哪、样式是按什么规范组织的，然后按照项目现有模式来完成改动。

这和传统的Tab补全、单文件内联问答完全不在一个层级。UI开发场景里，页面的组成部分往往是分散的：组件在components目录、颜色在theme文件、网络状态在store里。Agent模式意味着AI能把这些分散的信息串起来，生成的代码才可能贴合工程实际。

1.2 MCP协议是在补哪一块短板

仅凭Cursor本身，还解决不了一个核心问题：AI看不明白设计稿的准确结构。你直接把设计稿截图丢给AI，它只能“猜”间距、字号、颜色值，猜错两个像素你是发现不了的，等发到真机上才发现整体比例不对，再回头修，成本就高了。

MCP解决的就是这个连接问题。你可以把MCP理解成一个标准化的USB接口，让AI可以通过统一的协议去读取外部工具的数据。在UI生成场景里，MCP Server一端连着Figma或者蓝湖，一端连着Cursor，Cursor里的AI就能直接获取设计稿的节点结构、样式参数、标注信息，而不是对着图片猜。

这里有个关键认知：MCP并不是Cursor独有的东西，它是一个开放协议，Claude Desktop、其他支持MCP的客户端都可以用。Cursor只是比较早地把这个能力内置成了比较顺滑的交互形态。理解这一点，你就能明白为什么团队里有人用别的IDE也能复用同一套MCP配置。

1.3 Figma和蓝湖的MCP方案怎么选

国内团队设计协作工具基本分两派：用Figma的，以及用蓝湖的。两个都有对应的MCP Server可用。

Figma官方提供了MCP Server，能读取文件结构、获取节点信息、拉取样式数据，适合设计稿本身在Figma里维护得比较规范的团队。蓝湖那边也有开放的MCP接入方案，好处是直接对接蓝湖的标注数据，很多国内团队的设计交付流程本身就是建立在蓝湖上的，切换到MCP的成本更低。

这里我给的选型建议是：如果团队的设计交付已经形成了一套标注规范，优先用蓝湖MCP，因为它直接读取标注数据，和开发手里的设计稿信息完全一致；如果团队更看重设计源头的数据结构化程度，选Figma官方MCP，它的图结构数据更完整，class name、组件实例、样式变量都能拿到。两者不是对立关系，如果你的项目两个平台都在用，可以在MCP配置里同时挂上两个Server。

2. 环境搭建：从Cursor配置到MCP调试

2.1 Cursor安装、中文设置与项目导入

Cursor的安装本身很常规，从官网下载对应系统的版本，登录账号就能用。免费版够日常体验，但做代码生成这种高频操作，我建议直接用Pro版，Agent模式的请求量上限会宽裕很多。

关于中文界面这个话题，很多国内开发者一上来就折腾插件汉化。其实Cursor的多语言支持一直在完善，安装后在Settings里找到Languages选项，切换到简体中文重启就生效了。我个人的建议是IDE界面没必要汉化，因为团队协作时大家截图交流、分享快捷键、讨论菜单项，用的多半是英文词汇，保持英文界面反而降低沟通成本。真正应该“汉化”的是你给AI写的提示词，让AI用中文理解你的需求，再输出英文代码，这个在3.2部分会细说。

把已有的Flutter工程导入Cursor很简单，直接用File > Open Folder打开项目根目录。这里提醒一下：打开的目录会决定AI能看到的上下文范围。如果你给它开的是整个仓库，它会看到大量无关代码，影响生成准确度；如果开的是某个Flutter app的独立工程，上下文更干净，生成质量会明显提升。

2.2 MCP Server配置实例

Cursor里配置MCP Server的方法，不同版本稍有差异，但逻辑是一致的：在项目根目录下维护一个配置文件（比如.mcp.json），声明要接入的Server。下面是我项目里Figma和蓝湖同时挂载的对照样板：

{ "mcpServers": { "figma": { "command": "npx", "args": ["-y", "figma-developer-mcp", "--stdio"], "env": { "FIGMA_API_KEY": "your_figma_personal_token" } }, "lanhu": { "command": "npx", "args": ["-y", "lanhu-mcp-server"], "env": { "LANHU_ACCESS_TOKEN": "your_lanhu_token", "LANHU_PROJECT_ID": "your_project_id" } } } }

配置完成后，在Cursor的MCP面板里检查Server状态是否显示Connected。如果显示错误，多半是环境变量没识别到，或者npx后面那个包名不对，去npm registry核对一下最新的包名比较靠谱，这些包迭代很快，网上教程写的包名经常会过期。

2.3 Figma Token获取步骤

Figma的Personal Access Token很容易找，但也容易掉坑里。登录Figma后，打开Settings，在Account选项卡里找到Personal Access Tokens，点Generate new token。授权范围按需勾选，做UI代码生成只需要只读权限就够了，比如File content相关的Read权限，不要勾选写权限，避免Token泄露后被恶意修改设计稿。

生成后Token只显示一次，一定要先复制存好。很多人栽在这一点：没保存就刷新了页面，只能重新生成一个。Token本质上等同于你Figma账号的通行证，建议存在密码管理器里，别直接写在代码仓库里。用本地环境变量或者Cursor的Secrets功能管理，都比明文写在mcp.json里安全得多。

2.4 Windows下两个高频报错处理

我的主力开发机是Windows，Flutter环境配好之后，在Cursor里折腾MCP和代码生成时连续撞上两个经典报错，这里直接给结论，给后来人省点时间。

第一个是“unable to find suitable visual studio toolchain”。这不是Cursor的问题，而是Flutter在Windows上做原生插件编译时，需要调用Visual Studio的C++工具链，你的机器上没装或者没装全。解决方法是打开Visual Studio Installer，给已安装的VS版本勾选“使用C++的桌面开发”工作负载，等安装完成重启，再让Flutter执行flutter doctor确认环境变绿。

第二个是“you are applying flutter's main gradle plugin imperatively using the apply script”这种Gradle警告。这是Flutter Android工程的build.gradle里还在用旧的apply script方式加载Gradle插件，Flutter官方推荐改用plugins DSL声明式引入。虽然目前还只是警告，不影响编译，但团队项目里堆多了这种技术债，以后升级Gradle或Flutter版本时会很难受。把settings.gradle里加上插件声明，再在app模块的build.gradle里改用plugins块，就能消掉这个警告。

3. 企业级规范适配的关键设计

3.1 裸生成的代码为什么不能直接用

很多团队用AI生成UI代码，第一版跑起来效果看着不错，结果代码评审时被老手挑出一堆问题：颜色直接写死十六进制、间距拍脑袋定的、组件用Container堆而不是用项目里的通用组件、状态管理用setState一把梭。

这些都是“裸生成”的典型症状。你看得懂代码，但它和你的工程规范完全是两套语言。原因在于，AI默认情况下只会遵循它训练语料里的“普遍最佳实践”，而不会自动知道你们团队约定：颜色必须走AppColors类、按钮必须用PrimaryButton组件、页面状态要用Riverpod管理、路由必须声明在app_router里。

所以企业级适配的本质，不是让AI生成更漂亮的代码，而是让你的工程规范“长”进AI的上下文里。这是整个方案里性价比最高的一步。

3.2 用规则文件约束AI行为

我的做法是在Flutter工程根目录维护一个RULES.md（或者叫AGENTS.md，Cursor会自动读取这个文件），把团队规范里能落到代码层面的规则都写进去。注意不是写那种空泛的“请写出高质量的代码”，而是可执行的、明确的约束。我摘一段我项目里的写法：

# Flutter UI代码生成规则 ## 颜色与主题 - 禁止使用硬编码十六进制颜色，必须引用AppColors类中的常量 - 语义色（成功/警告/错误）必须使用AppSemanticColors ## 组件复用 - 优先使用lib/components目录下的通用组件 - 不存在所需组件时，先声明需要新增的组件，再补充使用 - 禁止用Container+Text拼一个已有组件能表达的功能 ## 布局与尺寸 - 间距基准为8的倍数，避免任意取整数值 - 字体大小禁止直接写数值，使用AppTextStyles常量 ## 状态管理 - 超过两层的状态联动必须使用Riverpod，禁止setState硬传 ## 路由 - 页面跳转必须走AppRouter，禁止直接Navigator.push

这套规则文件写好后，Cursor里Agent模式会自动把它作为上下文的一部分。之后你给的提示词里只需要简短一句“按RULES.md规范生成”，AI就会在生成代码时主动遵守这些约定。实测下来，代码符合度能提升一大截，代码评审时被挑刺的点至少少了一半。

3.3 设计令牌与组件库联动

光有规则还不够，要让AI生成代码时能引用到真实存在的组件和样式，你需要把“设计令牌”喂给AI。设计令牌可以理解为设计系统里最基础的那些原子值：颜色、字体、间距、圆角、阴影等，它们有统一的命名，代码里直接引用对应常量。

我项目里做法是，把AppColors、AppTextStyles、AppSpacing这些核心令牌类文件路径和关键结构写进RULES.md里，并明确告诉AI“颜色从AppColors取，字号从AppTextStyles取”。这样AI读取设计稿上的具体颜色值或字号值后，不是直接生成一个数字，而是会去AppColors里找语义相近的常量来引用。

这里有个细节值得注意：AI找常量的时候如果匹配不上，它会自己new一个出来。所以你的令牌类命名越规范、覆盖越全，AI生成时越不容易“造轮子”。实战里我把常用颜色整理成“主背景”“卡片背景”“主文字”“次要文字”这类语义命名，AI匹配准确率高很多。

组件库那边逻辑也一样。项目里已有的PrimaryButton、AppTextField这类通用组件，我把它们的props说明直接写进规则文件，AI生成页面时会优先用它认识的组件，而不是生成一个陌生的实现。

3.4 状态管理与路由的团队约定

状态管理这块，纯UI页面生成其实不太涉及，但一旦页面里有交互、有数据请求，AI默认行为就很容易跑偏。比如登录页，AI很自然会写一个setState管理loading状态，这在小组件里没问题，但稍大一点的页面就会失控。

我们团队的约定是：超过两层的状态联动必须用Riverpod。这个规则写进RULES.md后，AI就会主动用StateProvider或者FutureProvider来组织状态。生成出来的代码，整个结构会自然落入团队现有的状态管理模式里，后续人工接手维护的成本会低很多。

路由同理。Flutter里页面跳转有无数种写法，团队如果统一用go_router，规则里就明确写禁止Navigator.push。AI读取到这个约束后，生成的页面里涉及跳转的部分会直接使用AppRouter，新人接手时也不用猜这个页面是怎么进来的。

3.5 生成后的自动校验

规则文件约束了AI的生成过程，但总会有漏网之鱼。我建议在代码提交前加一道自动校验，哪怕只是简单的文本扫描。

我现在的做法是在CI脚本里加了一个简单的lint检查，扫描新提交的Dart文件里是否有硬编码颜色（正则匹配0xFF开头的十六进制值）、是否有裸Navigator调用、是否有Container包Text这种片段。有违反的直接让CI挂掉。有了这道关卡，AI生成的代码就必须经过和团队其他成员一样的规范审查，时间久了，AI也会慢慢“学乖”，因为它的输出会被持续反馈修正。

4. 实战：一个登录页从设计稿到Flutter代码

4.1 准备设计稿和MCP连接

理论说多了得落地。我用团队最近做的一个登录页改造来演示完整流程。这个登录页在设计稿里包含：品牌Logo区、手机号输入框、验证码输入框、获取验证码按钮、登录按钮、用户协议勾选，以及“忘记密码”入口。

第一步先确认MCP连接正常。在Cursor的MCP面板里，确认figma server状态是Connected，然后调用工具拉取设计稿文件信息，找到登录页对应的Frame（画板），拿到它的file_key和node_id。这一步我吃了不少亏：一开始拿整个文件的所有节点让AI处理，上下文太大，AI反而抓不住重点。正确做法是先缩小范围，只暴露登录页这个Frame的节点数据。

4.2 提示词怎么写

这一步是整个流程里最值得琢磨的地方。很多人直接丢一句“帮我写个登录页”，AI给你吐出来一堆能跑但没法用的代码。我的提示词模板大致是这个形态：

请根据Figma设计稿中file_key为xxx的登录页Frame，生成lib/pages/login/login_page.dart。 要求： 1. 严格遵循项目根目录RULES.md中的所有约定 2. 页面结构：Column布局，依次排列Logo、手机号输入框、验证码输入框、登录按钮、协议勾选、忘记密码入口 3. 输入框优先使用AppTextField组件，按钮使用PrimaryButton 4. 所有颜色引用AppColors常量，字号引用AppTextStyles 5. 登录状态用Riverpod的AsyncNotifier管理，loading状态展示PrimaryButton的loading属性 6. 校验逻辑：手机号11位、验证码6位，不合法时按钮置灰 7. 无需处理真实网络请求，网络层留接口注释

这里面既有结构信息（从设计稿读取的节点顺序），又有规范信息（RULES.md约束），还有交互逻辑说明（校验规则、状态管理方式）。AI拿到这些后，生成的不再是“图片的像素级复制”，而是一个能直接嵌入现有工程的页面骨架。

4.3 生成效果与手动修正

第一次生成的效果，说实话比我预期的好不少。结构上基本符合要求，组件引用、颜色引用都走的是项目常量，间距也遵循了8像素基准。需要手动修的主要集中在三处：

一是验证码输入框和手机号输入框之间的间距，设计稿上那个间距比较特殊，不是标准的8倍数，AI按规则取整了，这里反而需要人工确认是否有意为之。二是用户协议文本里的超链接处理，AI生成了TextSpan但点击事件留了TODO，需要补上真实的协议页跳转。三是获取验证码按钮的倒计时逻辑，AI在生成代码时只写了静态UI，没把倒计时状态机写进去，需要我手动接上已有的CountdownController。

这些修正量，和从零手写相比大约节省了70%左右的时间。更关键的是，修正过程中没有发生“推倒重来”的情况，整体结构是稳的，改的都是局部细节。

4.4 FVM与请求封装的配合

有人可能会问，生成登录页的时候要不要连真实接口？我的建议是第一次生成先不接，把UI骨架和交互状态做好，让AI生成的部分是纯UI层的。真正接接口时，可以让AI参考项目里现有的请求封装模式来写具体调用。

这里顺带说下FVM。团队项目多、Flutter版本不统一的时候，FVM（Flutter Version Management）几乎是必须的。Cursor打开项目时默认会找系统PATH里的dart和flutter，如果你的项目用FVM锁定了一个特定Flutter版本，需要在Cursor的终端配置里把FVM的路径指过去，否则AI执行flutter analyze或者跑测试时用的版本可能和项目锁定版本不一致，会出现“本地能编译、CI挂了”这类诡异问题。

请求封装这块，我们团队封装了一个统一的HttpClient，所有网络请求都走它，自动附带token、统一错误处理、统一loading状态。规则文件里我也加了一条：涉及网络请求时，必须调用lib/core/network里的封装方法，禁止直接用dart:io或第三方库裸发请求。这样AI生成带接口调用的页面时，不会给你“发明”一个新的请求工具类。

5. 常见问题速查与排查实录

5.1 高频问题速查表

这段时间实操下来，我整理了一张遇到概率最高的故障对照表，给遇到类似问题的人一个快速入口：

5.2 MCP连接不上的排查路径

MCP连接失败是大家问得最多的，我单独说一下排查思路。Windows系统下，最常见的是npx路径问题。Cursor的MCP服务启动时，用的可能不是你在当前终端里配置的PATH，导致npx找不到。解决办法是在MCP配置里写npx的绝对路径，Windows下通常是C:\Program Files\nodejs\npx.cmd，写绝对路径后就稳定了。

其次是网络问题。Cursor要访问Figma API，蓝湖MCP也需要联网调接口，某些网络环境下可能需要配置代理。这里注意，代理地址不能随便填，要填真实可用的代理服务地址，设置错了反而连不上。不过这个话题就到此为止，我只说一句：企业网络环境通常有统一的网络策略，找团队的网管确认可靠的连接方式最稳妥。

最后是版本兼容问题。MCP社区活跃，Figma官方MCP和蓝湖MCP都在快速迭代。如果你用的Cursor版本比较旧，可能对MCP的某些新特性支持不完整，如果功能始终不起效，升级Curor到最新版再试一下，多半能解决。

5.3 生成代码与现有项目冲突的处理

AI生成代码和现有项目冲突，主要集中在两个层面。第一层是文件覆盖冲突。AI在Agent模式下会自己创建文件，如果你让它在已有login_page.dart的文件里生成，它有可能会整个覆盖而不是局部替换。我的习惯是让AI优先把新代码生成到_draft目录或者生成到临时文件，人工review确认无误后再手动替换正式文件。这个小习惯能避免很多悲剧。

第二层是依赖冲突。AI如果觉得需要用某个第三方库，它会在pubspec.yaml里自动加依赖。这里一定要人工确认版本是否和项目现有依赖冲突。我遇到过AI引入一个新版本的状态管理库，和团队正在用的版本不兼容，导致整个项目range error报错，折腾了半天。现在我的做法是：在提示词里明确写“禁止新增第三方依赖，如确需新增，需先说明理由并暂停操作”，把依赖变更的主动权拿回手里。

写在最后的实操体会

这套流程我跑了几周下来，最大的感受是:AI代码生成这事儿,瓶颈不在模型本身的能力,而在你愿不愿意花时间去“教育”它适应你自己的工程土壤。RULES.md这个文件是我们费心思最多的地方,但它的价值不只在AI生成场景——团队新成员入职,先读一遍这份文件,对工程规范的理解速度也比以前快很多。

最后再分享一个小技巧。我在RULES.md里特意加了一条“如果规则互相冲突,以代码里注释标记的优先级为准”。这是因为我发现AI在不同规则冲突时,经常会选择一个看似合理但实际违背团队本意的方案。有了优先级声明,AI在犹豫的时候会倾向于先问要不要跳过,而不是自作主张。这个小改动,把生成过程中的不确定性降了一截。如果你也想在团队里推进AI辅助UI开发,建议从自己维护的一个小页面开始,先把规则文件调顺了,再逐步铺开。