UI 稿改到第八版产品经理终于点头结果开发一句“这间距不对、这圆角不对、这字号不对”又打回重来——这种来回拉扯的消耗做过小程序交付的人应该都懂。设计稿和代码之间那条鸿沟靠人工“量像素”去填效率低还容易出错。这次我拿一套真实的小程序页面做实验用 Trae CN 配合 Figma MCP把设计稿里的图层结构直接喂给 AI让它按设计意图生成微信小程序代码。整套流程跑下来从设计稿到可运行页面中间省掉了大量手工还原的环节。这篇就把完整链路、关键配置、踩过的坑和实测心得一次讲清楚适合正在做小程序交付的前端、独立开发者以及想把设计到代码流程打通的设计师参考。1. 先搞清楚这条链路到底在解决什么问题1.1 传统“设计稿转代码”为什么总是低效大多数人做小程序页面还原流程是这样的设计师在 Figma 里出稿开发打开设计工具逐个图层点开看间距、字号、颜色然后手写 WXML 和 WXSS。一个中等复杂度的页面光是量尺寸就能耗掉一两个小时遇到设计稿有嵌套组件、自动布局、阴影叠加的情况量出来的值还未必准。更麻烦的是设计稿一旦改动开发要重新对一遍之前写的样式可能全部作废。这个流程的根子问题在于设计稿里的信息是“视觉化”的而代码需要的是“结构化”的数值。人眼在两者之间做翻译天然低效且易错。Figma 的图层树其实已经包含了绝大部分布局信息——位置、尺寸、间距、颜色、字体、圆角、阴影这些数据本来就在文件里只是没有一条通道把它们直接送到代码生成环节。1.2 MCP 在这条链路里扮演的角色MCP 全称 Model Context Protocol你可以把它理解成“AI 工具和外部数据源之间的标准插头”。Trae CN 作为支持 MCP 的 AI 编程工具可以通过配置一个 Figma 的 MCP 服务让 AI 在对话过程中直接读取 Figma 文件的结构化数据。注意这里的关键词是“结构化”——不是截图识别不是视觉模型猜而是拿到图层树里的真实数值。这就带来一个本质区别传统 AI 生成代码靠的是“看图说话”模型根据截图猜测布局误差大而 MCP 模式下AI 拿到的是设计稿的原始数据间距是 16 就是 16圆角是 8 就是 8生成出来的代码在数值层面是可信的。这个差别在实际项目里非常明显前者经常出现“看起来差不多但就是不对”的情况后者基本能做到像素级对齐。1.3 这套方案适合谁、不适合谁先说适合的场景中小型微信小程序项目、页面结构相对标准列表、卡片、表单、详情页、设计稿在 Figma 里且图层命名规范、团队愿意在前期花时间配置环境。这类场景下一次配置可以反复受益边际成本很低。不适合的场景也要说清楚设计稿图层混乱、大量使用位图切图、页面有复杂动画和手势交互的这套方案帮不上太多忙因为 MCP 拿到的是静态结构数据动画逻辑还是得手写。另外如果你的项目对代码规范有极严格的定制要求比如必须用特定的组件库封装AI 生成的代码需要二次改造收益会打折扣。提示这套流程的定位是“加速初稿生成”不是“一键交付”。把它当成一个能帮你把 70% 的样板代码写好的助手剩下的 30% 业务逻辑和交互细节仍然需要人来把关。2. 环境准备两个工具、一个服务、三个容易忽略的细节2.1 Trae CN 的安装与 MCP 能力确认Trae CN 是字节推出的 AI 编程工具国内网络环境下可以直接使用这一点对实际落地很关键——很多海外工具在配置 MCP 服务时会卡在网络上Trae CN 没有这个问题。安装过程不复杂官网下载对应平台版本装完登录即可。装好之后第一件事确认 MCP 功能入口在哪里。在 Trae CN 的设置里找到 MCP 相关的配置项不同版本位置可能略有差异但逻辑一致你需要在这里添加一个 MCP Server 的配置。确认这个入口存在是后续所有步骤的前提。如果找不到先升级到较新版本。2.2 Figma 侧需要准备什么Figma 这边需要两样东西一个可访问的设计文件以及一个用于 MCP 服务调用的访问凭证。设计文件建议专门建一个测试用的不要拿正式项目练手避免误操作。文件里的图层命名尽量规范这一点后面会详细讲因为它直接影响 AI 理解结构的准确度。访问凭证的获取路径在 Figma 的账户设置里生成一个个人访问令牌即可。这个令牌相当于让 MCP 服务有权限读取你的设计文件保管好不要提交到代码仓库里。实测中建议把令牌放在环境变量或者本地配置文件里通过配置引用而不是硬编码在 MCP 配置的明文里。2.3 MCP 服务的配置写法与验证MCP 服务的配置通常是一个 JSON 结构核心字段包括服务名称、启动命令、参数和环境变量。以 Figma MCP 为例配置里需要指定服务包的启动方式并把前面拿到的访问令牌通过环境变量传进去。具体写法各版本可能有差异但结构大同小异{ mcpServers: { figma: { command: npx, args: [-y, figma-mcp-server], env: { FIGMA_ACCESS_TOKEN: 你的令牌 } } } }配置写完后重启 Trae CN在 MCP 面板里看这个服务是否显示为已连接状态。这一步是验证的关键如果显示未连接先检查命令是否能正常执行在终端里手动跑一下 npx 那条命令看报错再检查令牌是否有效。实测中常见的失败原因是 Node 环境版本过低导致 npx 拉包失败升级 Node 到较新版本基本能解决。注意配置里的令牌不要截图发到公开渠道也不要在演示时直接展示。养成用环境变量引用的习惯能避免很多不必要的麻烦。2.4 三个容易忽略的细节第一个细节是 Node 版本。MCP 服务大多基于 Node 生态版本太低会出现各种奇怪的启动失败建议 18 以上。第二个细节是网络代理配置如果你的环境需要走代理才能拉取 npm 包要确保 Trae CN 启动 MCP 服务时继承了这个代理设置否则会出现“终端里能跑、工具里跑不了”的情况。第三个细节是文件权限Figma 令牌对应的账户必须对目标设计文件有读取权限共享文件时要确认权限范围。3. 让 AI 读懂设计稿图层规范比配置更重要3.1 图层命名混乱是最大的隐形坑配置跑通之后很多人会迫不及待地拿一个现成设计稿去试结果生成的代码结构一塌糊涂。问题往往不在工具而在设计稿本身。Figma 里默认的图层名是“Frame 123”“Rectangle 45”这种AI 拿到这种命名根本不知道哪个是标题、哪个是按钮、哪个是列表项只能靠位置和尺寸去猜猜错的概率很高。我实测对比过两份设计稿一份图层命名规范“标题栏”“商品卡片”“价格文本”“加入购物车按钮”另一份全是默认命名。同样的提示词前者生成的代码结构清晰、组件划分合理后者生成的代码把整个页面当成一个大容器所有元素平铺可维护性很差。这个差距不是提示词能弥补的因为信息本身就不在设计稿里。3.2 一套可落地的图层命名约定不需要多复杂但要有基本语义。我的做法是给团队定一个简单约定容器类图层用“区块名Container”比如“HeaderContainer”“ListContainer”文本类用“内容语义Text”比如“TitleText”“PriceText”可点击元素用“动作Button”比如“SubmitButton”“AddCartButton”图片用“内容Image”。这套约定不追求完美关键是让 AI 能从名字里读出元素的角色。另外善用 Figma 的组件Component和自动布局Auto Layout。组件化的图层在 MCP 读取时会保留组件信息AI 更容易识别出“这是一个可复用的按钮”。自动布局则直接提供了间距和对齐信息比手动摆放的绝对定位图层更容易转成小程序的 flex 布局。实测下来用了自动布局的卡片生成的 WXSS 基本都是干净的 flex 写法手动摆放的经常出现一堆绝对定位。3.3 用提示词把设计意图讲清楚MCP 让 AI 能读到设计稿但读到的数据和“理解意图”之间还有距离。提示词的作用就是补上这段距离。我的提示词模板大致是这样组织的先说明目标平台微信小程序、技术栈原生 WXML/WXSS 或某个框架、页面类型然后指明要读取的 Figma 文件或节点最后给出结构要求比如“按区块拆分每个区块独立成组件”“样式用 rpx 单位”。一个实测有效的技巧是在提示词里明确告诉 AI“先输出页面结构分析再输出代码”。让它先把图层树翻译成“页面由哪几个区块组成、每个区块包含哪些元素”的文字描述你确认结构没问题再让它生成代码。这一步多花几十秒能省掉后面大量返工。因为结构错了代码写得再漂亮也是白搭。4. 从设计稿到小程序代码的完整实操4.1 第一步让 AI 拉取并解析设计稿结构在 Trae CN 的对话窗口里先发一条指令让 AI 通过 MCP 读取目标设计稿。指令里要包含设计文件的标识文件链接或节点 ID以及你希望它关注的范围。比如只做某个页面就指定那个页面的顶层 Frame不要让 AI 一次性读整个文件信息量太大反而容易抓不住重点。AI 读取后会返回一段结构描述。这时候要仔细看区块划分是否符合预期、元素层级是否正确、有没有把装饰性图层误判成内容元素。发现问题就在这一步纠正比如“第三个区块是商品列表不是轮播图重新分析”。反复几轮把结构对齐后面的代码生成就顺了。4.2 第二步确定技术栈与代码组织方式结构确认后要明确告诉 AI 用什么技术栈。微信小程序原生开发就用 WXML WXSS JS如果团队用 Taro 或 uni-app也要提前说明因为不同框架的模板语法和样式单位处理方式不同。我这次实验用的是原生开发提示词里明确写了“使用原生小程序语法样式单位用 rpx页面结构拆分为独立的自定义组件”。代码组织方式也要说清楚是单页面单文件还是拆成多个组件。对于结构清晰的页面我倾向于让 AI 拆组件比如把“商品卡片”拆成一个独立组件这样复用性好后续维护也方便。拆组件时要注意让 AI 同时生成组件的 json 配置文件声明 component 为 true否则小程序里引用会报错。4.3 第三步生成代码后的第一轮校验AI 生成代码后不要急着往项目里贴。先做三件事第一检查 WXML 的标签闭合和属性拼写小程序对标签规范要求严格一个未闭合的标签就会导致编译失败第二检查 WXSS 里的单位是否统一为 rpx混用 px 和 rpx 在不同机型上会出现适配问题第三检查 JS 里的 data 结构和 WXML 里的数据绑定是否对得上AI 有时会生成绑定但忘了在 data 里声明。这一步的校验花不了几分钟但能挡掉大部分低级错误。实测中AI 生成的代码在结构层面通常没问题问题多出在细节比如把 Figma 里的阴影直接转成 box-shadow 但参数顺序不对或者把渐变背景的颜色值写错。这些都要靠人工过一遍。4.4 第四步在开发者工具里跑起来并微调把代码放进微信开发者工具编译看效果。第一轮大概率会有视觉偏差常见的是间距不对、字号偏大偏小、圆角不一致。这时候不要直接改代码而是回到设计稿核对原始数值确认是 AI 转换时出错还是设计稿本身就有特殊处理比如用了负 margin 做视觉补偿。微调阶段有个高效做法把开发者工具里的实际效果截图连同“哪里不对”的描述一起发给 AI让它针对性修改。比如“商品卡片的左右内边距应该是 24rpx现在看起来偏小检查一下”。这种带具体数值和位置的反馈AI 修正的准确率很高。反复几轮页面就能达到可交付的还原度。5. 实测中踩到的坑与对应解法5.1 坑一MCP 服务显示已连接但读取失败这个坑很典型MCP 面板显示绿色已连接但一发读取指令就报错。排查下来问题出在令牌权限上——令牌本身有效但对应的账户对目标文件只有“查看”权限没有 API 读取权限。解法是让文件所有者把权限调整为可编辑或者用文件所有者账户生成令牌。这个问题的迷惑性在于“已连接”状态只代表服务进程起来了不代表鉴权通过。5.2 坑二生成的样式单位混乱AI 有时会在同一个 WXSS 文件里混用 px 和 rpx尤其是从 Figma 的 px 值直接转换时。小程序的 rpx 是按 750 设计稿宽度换算的如果设计稿是 375 宽度数值要乘 2。AI 不一定知道你的设计稿基准宽度所以提示词里必须明确写“设计稿宽度 375样式统一用 rpx换算时乘以 2”。不写这句生成结果就会飘。5.3 坑三组件引用路径和配置遗漏拆组件时AI 生成的页面 json 里有时会漏掉 usingComponents 声明或者路径写错比如少了相对路径的../。小程序对这块校验严格漏了直接白屏。解法是生成后专门检查每个页面的 json 文件确认组件声明完整、路径正确。另外自定义组件的 json 里必须有component: true这个也经常被漏掉。5.4 坑四图片资源处理不当设计稿里的图片MCP 读到的是图片节点的元信息不是图片文件本身。AI 生成代码时会在 image 标签里填一个占位路径这个路径在你的项目里是不存在的直接跑会显示裂图。解法是提前把设计稿里的图片导出放到项目的静态资源目录然后把生成代码里的路径替换成实际路径。这一步没法完全自动化需要人工介入但工作量不大。5.5 坑五复杂交互逻辑被“想当然”生成AI 看到设计稿里有个“展开更多”的按钮可能会自作主张生成一段展开收起的逻辑但这段逻辑未必符合你的业务需求。实测中遇到过 AI 给一个纯展示的标签加上了点击态样式和事件绑定纯属多余。解法是在提示词里明确“只生成静态结构和样式交互逻辑留空并加注释”把逻辑部分交给人来写避免 AI 过度发挥。6. 把这条链路用顺的几个经验6.1 建立自己的提示词模板库每次从零写提示词很浪费时间。我的做法是把验证有效的提示词存成模板按页面类型分类列表页模板、详情页模板、表单页模板。模板里固定包含技术栈说明、单位换算规则、组件拆分要求、交互逻辑留空这几条。用的时候只改设计稿标识和页面特殊要求效率提升明显。模板积累到五六个之后大部分常见页面都能覆盖。6.2 设计侧和开发侧要提前对齐约定这套流程要真正提效不能只有开发一个人在折腾。设计侧需要知道图层命名规范、组件化要求、自动布局的使用方式开发侧需要知道设计稿的基准宽度、特殊视觉处理的意图。两边提前对齐一次后面每个页面的转换都会顺很多。我见过团队因为没对齐设计稿用了大量手动定位AI 生成的代码全是绝对定位返工成本比手写还高。6.3 把 AI 生成当成“第一稿”而不是“终稿”心态上要摆正。这套方案的价值在于把重复性的样板代码生成出来让你把精力放在业务逻辑和交互细节上。指望它一次生成完美代码不现实也没必要。实测下来一个中等复杂度页面AI 生成初稿能省掉六到七成的结构和样式编写时间剩下的微调和逻辑补充才是体现开发者价值的地方。把这个预期管理好用起来就不会有落差。6.4 版本管理和回滚要跟上AI 生成的代码建议单独提交一个 commit标注清楚“AI 生成初稿”方便后续对比和回滚。微调过程中如果改乱了可以直接回到初稿重新来。另外MCP 配置文件和令牌相关的本地配置记得加进 .gitignore不要混进代码仓库。这些都是小习惯但能避免很多麻烦。最后分享一个实测中很实用的小技巧在让 AI 生成代码之前先让它输出一份“设计稿到代码的映射表”列出每个 Figma 图层对应生成哪个 WXML 标签、用了什么样式类名。这份映射表既是生成代码的依据也是后续排查问题的索引。页面出问题时对着映射表一看就知道是哪个环节出的偏差比盲目翻代码高效得多。这套流程我前后调了大概两周才跑顺前期配置和规范对齐花的时间最多但一旦跑通后面每个页面的转换都是几分钟的事投入产出比很划算。 
长河君 · 2026/11/2 2:49:26 · 阅读 1.2k Trae CN + Figma MCP：设计稿一键生成微信小程序代码实战
UI 稿改到第八版产品经理终于点头结果开发一句“这间距不对、这圆角不对、这字号不对”又打回重来——这种来回拉扯的消耗做过小程序交付的人应该都懂。设计稿和代码之间那条鸿沟靠人工“量像素”去填效率低还容易出错。这次我拿一套真实的小程序页面做实验用 Trae CN 配合 Figma MCP把设计稿里的图层结构直接喂给 AI让它按设计意图生成微信小程序代码。整套流程跑下来从设计稿到可运行页面中间省掉了大量手工还原的环节。这篇就把完整链路、关键配置、踩过的坑和实测心得一次讲清楚适合正在做小程序交付的前端、独立开发者以及想把设计到代码流程打通的设计师参考。1. 先搞清楚这条链路到底在解决什么问题1.1 传统“设计稿转代码”为什么总是低效大多数人做小程序页面还原流程是这样的设计师在 Figma 里出稿开发打开设计工具逐个图层点开看间距、字号、颜色然后手写 WXML 和 WXSS。一个中等复杂度的页面光是量尺寸就能耗掉一两个小时遇到设计稿有嵌套组件、自动布局、阴影叠加的情况量出来的值还未必准。更麻烦的是设计稿一旦改动开发要重新对一遍之前写的样式可能全部作废。这个流程的根子问题在于设计稿里的信息是“视觉化”的而代码需要的是“结构化”的数值。人眼在两者之间做翻译天然低效且易错。Figma 的图层树其实已经包含了绝大部分布局信息——位置、尺寸、间距、颜色、字体、圆角、阴影这些数据本来就在文件里只是没有一条通道把它们直接送到代码生成环节。1.2 MCP 在这条链路里扮演的角色MCP 全称 Model Context Protocol你可以把它理解成“AI 工具和外部数据源之间的标准插头”。Trae CN 作为支持 MCP 的 AI 编程工具可以通过配置一个 Figma 的 MCP 服务让 AI 在对话过程中直接读取 Figma 文件的结构化数据。注意这里的关键词是“结构化”——不是截图识别不是视觉模型猜而是拿到图层树里的真实数值。这就带来一个本质区别传统 AI 生成代码靠的是“看图说话”模型根据截图猜测布局误差大而 MCP 模式下AI 拿到的是设计稿的原始数据间距是 16 就是 16圆角是 8 就是 8生成出来的代码在数值层面是可信的。这个差别在实际项目里非常明显前者经常出现“看起来差不多但就是不对”的情况后者基本能做到像素级对齐。1.3 这套方案适合谁、不适合谁先说适合的场景中小型微信小程序项目、页面结构相对标准列表、卡片、表单、详情页、设计稿在 Figma 里且图层命名规范、团队愿意在前期花时间配置环境。这类场景下一次配置可以反复受益边际成本很低。不适合的场景也要说清楚设计稿图层混乱、大量使用位图切图、页面有复杂动画和手势交互的这套方案帮不上太多忙因为 MCP 拿到的是静态结构数据动画逻辑还是得手写。另外如果你的项目对代码规范有极严格的定制要求比如必须用特定的组件库封装AI 生成的代码需要二次改造收益会打折扣。提示这套流程的定位是“加速初稿生成”不是“一键交付”。把它当成一个能帮你把 70% 的样板代码写好的助手剩下的 30% 业务逻辑和交互细节仍然需要人来把关。2. 环境准备两个工具、一个服务、三个容易忽略的细节2.1 Trae CN 的安装与 MCP 能力确认Trae CN 是字节推出的 AI 编程工具国内网络环境下可以直接使用这一点对实际落地很关键——很多海外工具在配置 MCP 服务时会卡在网络上Trae CN 没有这个问题。安装过程不复杂官网下载对应平台版本装完登录即可。装好之后第一件事确认 MCP 功能入口在哪里。在 Trae CN 的设置里找到 MCP 相关的配置项不同版本位置可能略有差异但逻辑一致你需要在这里添加一个 MCP Server 的配置。确认这个入口存在是后续所有步骤的前提。如果找不到先升级到较新版本。2.2 Figma 侧需要准备什么Figma 这边需要两样东西一个可访问的设计文件以及一个用于 MCP 服务调用的访问凭证。设计文件建议专门建一个测试用的不要拿正式项目练手避免误操作。文件里的图层命名尽量规范这一点后面会详细讲因为它直接影响 AI 理解结构的准确度。访问凭证的获取路径在 Figma 的账户设置里生成一个个人访问令牌即可。这个令牌相当于让 MCP 服务有权限读取你的设计文件保管好不要提交到代码仓库里。实测中建议把令牌放在环境变量或者本地配置文件里通过配置引用而不是硬编码在 MCP 配置的明文里。2.3 MCP 服务的配置写法与验证MCP 服务的配置通常是一个 JSON 结构核心字段包括服务名称、启动命令、参数和环境变量。以 Figma MCP 为例配置里需要指定服务包的启动方式并把前面拿到的访问令牌通过环境变量传进去。具体写法各版本可能有差异但结构大同小异{ mcpServers: { figma: { command: npx, args: [-y, figma-mcp-server], env: { FIGMA_ACCESS_TOKEN: 你的令牌 } } } }配置写完后重启 Trae CN在 MCP 面板里看这个服务是否显示为已连接状态。这一步是验证的关键如果显示未连接先检查命令是否能正常执行在终端里手动跑一下 npx 那条命令看报错再检查令牌是否有效。实测中常见的失败原因是 Node 环境版本过低导致 npx 拉包失败升级 Node 到较新版本基本能解决。注意配置里的令牌不要截图发到公开渠道也不要在演示时直接展示。养成用环境变量引用的习惯能避免很多不必要的麻烦。2.4 三个容易忽略的细节第一个细节是 Node 版本。MCP 服务大多基于 Node 生态版本太低会出现各种奇怪的启动失败建议 18 以上。第二个细节是网络代理配置如果你的环境需要走代理才能拉取 npm 包要确保 Trae CN 启动 MCP 服务时继承了这个代理设置否则会出现“终端里能跑、工具里跑不了”的情况。第三个细节是文件权限Figma 令牌对应的账户必须对目标设计文件有读取权限共享文件时要确认权限范围。3. 让 AI 读懂设计稿图层规范比配置更重要3.1 图层命名混乱是最大的隐形坑配置跑通之后很多人会迫不及待地拿一个现成设计稿去试结果生成的代码结构一塌糊涂。问题往往不在工具而在设计稿本身。Figma 里默认的图层名是“Frame 123”“Rectangle 45”这种AI 拿到这种命名根本不知道哪个是标题、哪个是按钮、哪个是列表项只能靠位置和尺寸去猜猜错的概率很高。我实测对比过两份设计稿一份图层命名规范“标题栏”“商品卡片”“价格文本”“加入购物车按钮”另一份全是默认命名。同样的提示词前者生成的代码结构清晰、组件划分合理后者生成的代码把整个页面当成一个大容器所有元素平铺可维护性很差。这个差距不是提示词能弥补的因为信息本身就不在设计稿里。3.2 一套可落地的图层命名约定不需要多复杂但要有基本语义。我的做法是给团队定一个简单约定容器类图层用“区块名Container”比如“HeaderContainer”“ListContainer”文本类用“内容语义Text”比如“TitleText”“PriceText”可点击元素用“动作Button”比如“SubmitButton”“AddCartButton”图片用“内容Image”。这套约定不追求完美关键是让 AI 能从名字里读出元素的角色。另外善用 Figma 的组件Component和自动布局Auto Layout。组件化的图层在 MCP 读取时会保留组件信息AI 更容易识别出“这是一个可复用的按钮”。自动布局则直接提供了间距和对齐信息比手动摆放的绝对定位图层更容易转成小程序的 flex 布局。实测下来用了自动布局的卡片生成的 WXSS 基本都是干净的 flex 写法手动摆放的经常出现一堆绝对定位。3.3 用提示词把设计意图讲清楚MCP 让 AI 能读到设计稿但读到的数据和“理解意图”之间还有距离。提示词的作用就是补上这段距离。我的提示词模板大致是这样组织的先说明目标平台微信小程序、技术栈原生 WXML/WXSS 或某个框架、页面类型然后指明要读取的 Figma 文件或节点最后给出结构要求比如“按区块拆分每个区块独立成组件”“样式用 rpx 单位”。一个实测有效的技巧是在提示词里明确告诉 AI“先输出页面结构分析再输出代码”。让它先把图层树翻译成“页面由哪几个区块组成、每个区块包含哪些元素”的文字描述你确认结构没问题再让它生成代码。这一步多花几十秒能省掉后面大量返工。因为结构错了代码写得再漂亮也是白搭。4. 从设计稿到小程序代码的完整实操4.1 第一步让 AI 拉取并解析设计稿结构在 Trae CN 的对话窗口里先发一条指令让 AI 通过 MCP 读取目标设计稿。指令里要包含设计文件的标识文件链接或节点 ID以及你希望它关注的范围。比如只做某个页面就指定那个页面的顶层 Frame不要让 AI 一次性读整个文件信息量太大反而容易抓不住重点。AI 读取后会返回一段结构描述。这时候要仔细看区块划分是否符合预期、元素层级是否正确、有没有把装饰性图层误判成内容元素。发现问题就在这一步纠正比如“第三个区块是商品列表不是轮播图重新分析”。反复几轮把结构对齐后面的代码生成就顺了。4.2 第二步确定技术栈与代码组织方式结构确认后要明确告诉 AI 用什么技术栈。微信小程序原生开发就用 WXML WXSS JS如果团队用 Taro 或 uni-app也要提前说明因为不同框架的模板语法和样式单位处理方式不同。我这次实验用的是原生开发提示词里明确写了“使用原生小程序语法样式单位用 rpx页面结构拆分为独立的自定义组件”。代码组织方式也要说清楚是单页面单文件还是拆成多个组件。对于结构清晰的页面我倾向于让 AI 拆组件比如把“商品卡片”拆成一个独立组件这样复用性好后续维护也方便。拆组件时要注意让 AI 同时生成组件的 json 配置文件声明 component 为 true否则小程序里引用会报错。4.3 第三步生成代码后的第一轮校验AI 生成代码后不要急着往项目里贴。先做三件事第一检查 WXML 的标签闭合和属性拼写小程序对标签规范要求严格一个未闭合的标签就会导致编译失败第二检查 WXSS 里的单位是否统一为 rpx混用 px 和 rpx 在不同机型上会出现适配问题第三检查 JS 里的 data 结构和 WXML 里的数据绑定是否对得上AI 有时会生成绑定但忘了在 data 里声明。这一步的校验花不了几分钟但能挡掉大部分低级错误。实测中AI 生成的代码在结构层面通常没问题问题多出在细节比如把 Figma 里的阴影直接转成 box-shadow 但参数顺序不对或者把渐变背景的颜色值写错。这些都要靠人工过一遍。4.4 第四步在开发者工具里跑起来并微调把代码放进微信开发者工具编译看效果。第一轮大概率会有视觉偏差常见的是间距不对、字号偏大偏小、圆角不一致。这时候不要直接改代码而是回到设计稿核对原始数值确认是 AI 转换时出错还是设计稿本身就有特殊处理比如用了负 margin 做视觉补偿。微调阶段有个高效做法把开发者工具里的实际效果截图连同“哪里不对”的描述一起发给 AI让它针对性修改。比如“商品卡片的左右内边距应该是 24rpx现在看起来偏小检查一下”。这种带具体数值和位置的反馈AI 修正的准确率很高。反复几轮页面就能达到可交付的还原度。5. 实测中踩到的坑与对应解法5.1 坑一MCP 服务显示已连接但读取失败这个坑很典型MCP 面板显示绿色已连接但一发读取指令就报错。排查下来问题出在令牌权限上——令牌本身有效但对应的账户对目标文件只有“查看”权限没有 API 读取权限。解法是让文件所有者把权限调整为可编辑或者用文件所有者账户生成令牌。这个问题的迷惑性在于“已连接”状态只代表服务进程起来了不代表鉴权通过。5.2 坑二生成的样式单位混乱AI 有时会在同一个 WXSS 文件里混用 px 和 rpx尤其是从 Figma 的 px 值直接转换时。小程序的 rpx 是按 750 设计稿宽度换算的如果设计稿是 375 宽度数值要乘 2。AI 不一定知道你的设计稿基准宽度所以提示词里必须明确写“设计稿宽度 375样式统一用 rpx换算时乘以 2”。不写这句生成结果就会飘。5.3 坑三组件引用路径和配置遗漏拆组件时AI 生成的页面 json 里有时会漏掉 usingComponents 声明或者路径写错比如少了相对路径的../。小程序对这块校验严格漏了直接白屏。解法是生成后专门检查每个页面的 json 文件确认组件声明完整、路径正确。另外自定义组件的 json 里必须有component: true这个也经常被漏掉。5.4 坑四图片资源处理不当设计稿里的图片MCP 读到的是图片节点的元信息不是图片文件本身。AI 生成代码时会在 image 标签里填一个占位路径这个路径在你的项目里是不存在的直接跑会显示裂图。解法是提前把设计稿里的图片导出放到项目的静态资源目录然后把生成代码里的路径替换成实际路径。这一步没法完全自动化需要人工介入但工作量不大。5.5 坑五复杂交互逻辑被“想当然”生成AI 看到设计稿里有个“展开更多”的按钮可能会自作主张生成一段展开收起的逻辑但这段逻辑未必符合你的业务需求。实测中遇到过 AI 给一个纯展示的标签加上了点击态样式和事件绑定纯属多余。解法是在提示词里明确“只生成静态结构和样式交互逻辑留空并加注释”把逻辑部分交给人来写避免 AI 过度发挥。6. 把这条链路用顺的几个经验6.1 建立自己的提示词模板库每次从零写提示词很浪费时间。我的做法是把验证有效的提示词存成模板按页面类型分类列表页模板、详情页模板、表单页模板。模板里固定包含技术栈说明、单位换算规则、组件拆分要求、交互逻辑留空这几条。用的时候只改设计稿标识和页面特殊要求效率提升明显。模板积累到五六个之后大部分常见页面都能覆盖。6.2 设计侧和开发侧要提前对齐约定这套流程要真正提效不能只有开发一个人在折腾。设计侧需要知道图层命名规范、组件化要求、自动布局的使用方式开发侧需要知道设计稿的基准宽度、特殊视觉处理的意图。两边提前对齐一次后面每个页面的转换都会顺很多。我见过团队因为没对齐设计稿用了大量手动定位AI 生成的代码全是绝对定位返工成本比手写还高。6.3 把 AI 生成当成“第一稿”而不是“终稿”心态上要摆正。这套方案的价值在于把重复性的样板代码生成出来让你把精力放在业务逻辑和交互细节上。指望它一次生成完美代码不现实也没必要。实测下来一个中等复杂度页面AI 生成初稿能省掉六到七成的结构和样式编写时间剩下的微调和逻辑补充才是体现开发者价值的地方。把这个预期管理好用起来就不会有落差。6.4 版本管理和回滚要跟上AI 生成的代码建议单独提交一个 commit标注清楚“AI 生成初稿”方便后续对比和回滚。微调过程中如果改乱了可以直接回到初稿重新来。另外MCP 配置文件和令牌相关的本地配置记得加进 .gitignore不要混进代码仓库。这些都是小习惯但能避免很多麻烦。最后分享一个实测中很实用的小技巧在让 AI 生成代码之前先让它输出一份“设计稿到代码的映射表”列出每个 Figma 图层对应生成哪个 WXML 标签、用了什么样式类名。这份映射表既是生成代码的依据也是后续排查问题的索引。页面出问题时对着映射表一看就知道是哪个环节出的偏差比盲目翻代码高效得多。这套流程我前后调了大概两周才跑顺前期配置和规范对齐花的时间最多但一旦跑通后面每个页面的转换都是几分钟的事投入产出比很划算。