1. 这套组合到底在解决什么问题设计稿到代码之间的那道墙做过 Android 开发的人都懂。设计师在工具里画完界面导出标注图开发对着标注一个个写 XML宽高、间距、颜色、圆角、阴影全是手工活。一个中等复杂度的页面光布局就能耗掉大半天改一版设计再重来一遍。更别提那些嵌套层级深、约束关系绕的界面写到最后自己都理不清哪个 View 套在哪个 View 里面。MasterGo 加 Claude Code 这套组合核心思路就是把这堵墙拆掉。MasterGo 负责产出结构化的设计数据Claude Code 负责把这些数据翻译成可用的 Android 布局代码。整个链路不需要你手动量像素、不需要你逐个写属性设计稿改完重新生成一遍就行。这套流程适合谁用如果你是一个人扛一个 App 的独立开发者或者小团队里前后端一把抓的全栈选手再或者你是个 Android 新手对 ConstraintLayout 的约束关系还不太熟这套方法能帮你省掉大量重复劳动。但如果你对布局性能有极致要求或者项目里有一套非常严格的代码规范需要逐行 review那生成出来的代码还是得自己过一遍不能直接无脑用。我实测下来的感受是简单页面基本可以做到生成即用复杂页面大概能省掉百分之六七十的布局编写时间剩下的时间花在微调和适配上面。这个投入产出比已经相当可观了。2. 整体方案设计与工具链拆解2.1 为什么选 MasterGo 而不是其他设计工具MasterGo 在这套流程里的角色是“结构化数据源”。它跟 Claude Code 配合的关键在于MasterGo 的设计文件可以通过插件体系导出成 JSON 格式的节点树每个节点包含位置、尺寸、样式、层级关系等完整信息。这些信息就是 Claude Code 生成布局代码的原材料。选 MasterGo 有几个实际原因。第一它的插件生态比较开放你可以自己写导出插件也可以直接用社区里现成的导出工具。第二它的图层命名和分组逻辑比较规范导出的节点树结构清晰不会出现一堆“矩形 1”“编组 23”这种无意义命名。第三它的自动布局功能跟 Android 的 Flexbox 思路很接近设计师用自动布局画的界面导出后的约束关系天然就适合转成 ConstraintLayout 或 FlexboxLayout。当然其他设计工具也能做类似的事情但 MasterGo 的插件开发门槛相对低你不需要去逆向它的文件格式官方提供了完整的插件 API 文档。这一点对于想自己定制导出逻辑的开发者来说很关键。2.2 Claude Code 在链路中扮演什么角色Claude Code 不是简单的“设计稿转代码”工具。它的价值在于理解上下文。你给它一份 JSON 节点树它不只是做字段映射而是会分析这个界面的结构意图哪些元素应该用 ConstraintLayout 的约束关系来表达哪些应该用 LinearLayout 的权重来分配哪些地方适合用 Guideline 做辅助定位。举个例子设计稿里有两个按钮水平排列中间有固定间距。如果只是机械映射可能会生成一个 LinearLayout 里面放两个 Button用 margin 控制间距。但 Claude Code 会判断这个场景更适合用 ConstraintLayout 的链式约束因为这样在横屏或者不同屏幕宽度下表现更稳定。这种判断能力是它跟普通模板工具的本质区别。另外Claude Code 支持多轮对话。你可以先让它生成一版然后告诉它“把外层改成 ConstraintLayout”“这个 TextView 加个 maxLines 限制”“颜色值统一用 colors.xml 里的引用”它会基于上一版代码做增量修改而不是每次从头生成。这个交互方式在实际开发中非常顺手。2.3 完整链路的三个关键环节整个流程可以拆成三个环节设计稿整理、数据导出与清洗、代码生成与适配。设计稿整理这一步最容易被忽视但恰恰是最影响最终效果的。设计师如果图层命名混乱、分组逻辑随意导出的 JSON 节点树就会很难读Claude Code 理解起来也费劲。所以我在实际操作中会先花十分钟跟设计师对齐命名规范页面根节点叫什么、列表项怎么命名、可复用组件怎么标记。这一步做完后面所有环节都顺畅。数据导出与清洗环节我会写一个简单的 Node.js 脚本把 MasterGo 插件导出的 JSON 做一轮预处理。主要做三件事把绝对定位转成相对约束、把重复的样式值提取成变量、把图片资源替换成占位符。这轮清洗能大幅提升 Claude Code 生成代码的准确率。代码生成与适配环节我会把清洗后的 JSON 和一段系统提示词一起发给 Claude Code。提示词里会写明项目用的技术栈比如“用 Kotlin ConstraintLayout不要用 DataBinding”、命名规范比如“id 用 snake_case”、以及一些项目特有的约束比如“最小支持 API 24”。这样生成出来的代码基本不需要大改。3. 核心细节解析与实操要点3.1 设计稿整理阶段的关键操作设计稿整理不是简单地让设计师“好好命名”而是有一套具体的操作规范。我在实际项目中总结了几条硬性要求执行下来效果很明显。第一条所有可交互元素必须用组件Component的形式存在。按钮、输入框、卡片这些重复出现的元素在 MasterGo 里做成组件后导出的 JSON 里会带有 componentId 字段。Claude Code 看到这个字段就知道这是一个可复用组件生成代码时会自动提取成独立的布局文件或者自定义 View而不是在每个用到的地方重复生成一遍。第二条图层命名用英文加下划线不要用中文和空格。比如“登录按钮”写成“btn_login”“用户头像”写成“iv_avatar”。这个命名会直接变成生成代码里的资源 id如果命名不规范后面还得手动改一遍。我试过让设计师用中文命名结果生成的代码里 id 全是拼音可读性很差。第三条自动布局的间距用统一的间距系统。比如所有间距都是 4 的倍数4dp、8dp、12dp、16dp、24dp。这样导出的 JSON 里间距值很规整Claude Code 生成代码时可以直接映射到 dimens.xml 里的标准间距值而不是每个地方都写一个硬编码的数字。注意设计稿整理这一步不要跳过。我见过太多人直接拿原始设计稿去导出结果生成的代码里全是魔法数字和混乱的层级嵌套改起来比自己重写还累。3.2 JSON 节点树的结构与字段含义MasterGo 插件导出的 JSON 节点树每个节点包含以下核心字段{ id: node_001, name: btn_login, type: FRAME, x: 24, y: 480, width: 327, height: 48, layoutMode: HORIZONTAL, primaryAxisAlignItems: CENTER, counterAxisAlignItems: CENTER, itemSpacing: 8, paddingLeft: 16, paddingRight: 16, paddingTop: 12, paddingBottom: 12, cornerRadius: 8, fills: [{type: SOLID, color: {r: 0.2, g: 0.4, b: 0.9, a: 1}}], children: [] }这里有几个字段需要特别关注。layoutMode表示这个节点是否启用了自动布局值为 HORIZONTAL 或 VERTICAL。如果这个字段存在说明设计师用了自动布局生成代码时应该优先考虑 FlexboxLayout 或者 ConstraintLayout 的链式约束。如果不存在说明是绝对定位需要根据 x、y、width、height 反推约束关系。primaryAxisAlignItems和counterAxisAlignItems对应的是主轴和交叉轴的对齐方式直接映射到 Android 的 gravity 或者 constraint 的 bias 值。itemSpacing是子元素之间的间距对应 LinearLayout 的 divider 或者 ConstraintLayout 的 margin。fills数组里的颜色值是 0 到 1 的浮点数需要转换成 Android 的十六进制颜色值。转换公式很简单Math.round(r * 255)得到红色分量以此类推然后拼成#AARRGGBB格式。3.3 提示词工程怎么跟 Claude Code 说清楚需求跟 Claude Code 交互提示词的质量直接决定生成代码的质量。我经过多次迭代总结出一个比较稳定的提示词模板你是一个资深 Android 开发工程师。请根据以下设计稿 JSON 数据生成对应的 Android 布局代码。 技术要求 - 使用 Kotlin 语言 - 布局文件用 XML根布局优先使用 ConstraintLayout - 如果节点有 layoutMode 字段优先考虑 FlexboxLayout - 所有尺寸使用 dp字体大小使用 sp - 颜色值提取到 colors.xml尺寸值提取到 dimens.xml - 图片资源用 drawable/ 占位符代替 - id 命名使用 snake_case前缀遵循 Android 规范btn_、tv_、iv_、et_ 等 - 最小支持 API 24 设计稿 JSON 数据如下 [粘贴清洗后的 JSON]这个模板里每一行要求都有实际意义。比如“优先使用 ConstraintLayout”是因为 ConstraintLayout 在复杂布局下的性能表现更好而且约束关系比嵌套 LinearLayout 更扁平。“颜色值提取到 colors.xml”是为了后续换肤和统一管理。“id 命名规范”是为了生成的代码能直接融入现有项目。我试过不给这些约束直接让 Claude Code 自由发挥结果它有时候用 LinearLayout 嵌套三层有时候用 RelativeLayout风格不统一后面还得手动统一一遍。给了明确约束之后生成代码的一致性好了很多。3.4 从 JSON 到 XML 的映射规则Claude Code 在生成代码时内部有一套映射逻辑。我通过观察生成结果反推出了它常用的映射规则了解这些规则有助于你预判生成结果也方便你在提示词里做针对性调整。JSON 字段Android 对应说明layoutMode: HORIZONTALFlexboxLayout flexDirectionrow水平自动布局layoutMode: VERTICALFlexboxLayout flexDirectioncolumn垂直自动布局primaryAxisAlignItems: CENTERjustifyContentcenter主轴居中counterAxisAlignItems: CENTERalignItemscenter交叉轴居中itemSpacingFlexboxLayout 的 margin 或 divider子元素间距cornerRadiusapp:cardCornerRadius 或 background 的 shape圆角fillsandroid:background 或 tint填充色x, y, width, heightConstraintLayout 的约束绝对定位转约束对于没有 layoutMode 的节点Claude Code 会根据 x、y 坐标和父节点的关系来推断约束。比如一个节点的 x 值是 24父节点宽度是 375那它大概率会生成layout_constraintStart_toStartOfparent加上marginStart24dp。如果 x 值是 187接近父节点宽度的一半它可能会用layout_constraintStart_toStartOfparent和layout_constraintEnd_toEndOfparent加上layout_constraintHorizontal_bias0.5来实现居中。4. 完整实操流程与核心环节实现4.1 环境准备与工具安装先把手头的工具链搭起来。你需要准备的东西不多但每一样都得装对版本。MasterGo 这边注册账号后新建一个设计文件或者打开已有的设计稿。在插件市场里搜索“JSON Export”或者类似的导出插件安装到你的账号下。如果找不到合适的现成插件可以自己写一个MasterGo 的插件开发文档里有完整的示例代码核心逻辑就是遍历当前页面的节点树把每个节点的属性序列化成 JSON。Claude Code 这边你需要一个能访问 Claude API 的环境。我一般是在本地用 Node.js 写一个脚本把提示词和 JSON 数据拼在一起调用 API 后把返回的代码写到文件里。这样比在网页端手动复制粘贴效率高得多尤其是需要批量处理多个页面的时候。本地开发环境就是标准的 Android 项目Android Studio 最新稳定版Kotlin 插件装好Gradle 版本跟项目匹配就行。我建议单独建一个模块或者一个分支来放生成的代码方便对比和回滚。4.2 导出设计稿数据并清洗打开 MasterGo 设计稿选中你要导出的页面或画板运行导出插件。插件会生成一个 JSON 文件里面是完整的节点树。这个文件通常比较大一个中等复杂度的页面大概有几百个节点JSON 文件可能有好几 MB。拿到原始 JSON 后先做一轮清洗。我写了一个 Node.js 脚本主要做以下几件事const fs require(fs); // 读取原始 JSON const raw JSON.parse(fs.readFileSync(raw_design.json, utf8)); // 递归清洗节点 function cleanNode(node) { const cleaned { id: node.id, name: node.name, type: node.type, x: Math.round(node.x), y: Math.round(node.y), width: Math.round(node.width), height: Math.round(node.height), }; // 只保留有意义的样式字段 if (node.layoutMode) { cleaned.layoutMode node.layoutMode; cleaned.primaryAxisAlignItems node.primaryAxisAlignItems; cleaned.counterAxisAlignItems node.counterAxisAlignItems; cleaned.itemSpacing node.itemSpacing; } if (node.cornerRadius) cleaned.cornerRadius node.cornerRadius; if (node.fills node.fills.length 0) { cleaned.fills node.fills.map(f ({ type: f.type, color: f.color ? { r: Math.round(f.color.r * 255), g: Math.round(f.color.g * 255), b: Math.round(f.color.b * 255), a: f.color.a } : null })); } // 递归处理子节点 if (node.children node.children.length 0) { cleaned.children node.children.map(cleanNode); } return cleaned; } const cleaned cleanNode(raw); fs.writeFileSync(cleaned_design.json, JSON.stringify(cleaned, null, 2));这个脚本做了几件关键的事把浮点数坐标取整去掉冗余字段把颜色值从 0-1 浮点数转成 0-255 整数。清洗后的 JSON 体积能缩小一半以上而且可读性大幅提升。提示清洗脚本里可以根据项目需要加更多规则。比如把连续多个相同样式的节点合并、把图片节点替换成占位符、把文本内容提取到 strings.xml 的映射表里。规则越细后面生成代码的准确率越高。4.3 调用 Claude Code 生成布局代码清洗完数据后把 JSON 和提示词拼在一起发给 Claude Code。我一般用 Node.js 脚本批量处理核心代码如下const Anthropic require(anthropic-ai/sdk); const fs require(fs); const client new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY }); async function generateLayout(jsonPath, outputPath) { const designJson fs.readFileSync(jsonPath, utf8); const prompt 你是一个资深 Android 开发工程师。请根据以下设计稿 JSON 数据生成对应的 Android 布局代码。 技术要求 - 使用 Kotlin 语言 - 布局文件用 XML根布局优先使用 ConstraintLayout - 如果节点有 layoutMode 字段优先考虑 FlexboxLayout - 所有尺寸使用 dp字体大小使用 sp - 颜色值提取到 colors.xml尺寸值提取到 dimens.xml - 图片资源用 drawable/ 占位符代替 - id 命名使用 snake_case前缀遵循 Android 规范 - 最小支持 API 24 设计稿 JSON 数据如下 ${designJson}; const response await client.messages.create({ model: claude-sonnet-4-20250514, max_tokens: 8192, messages: [{ role: user, content: prompt }] }); const code response.content[0].text; fs.writeFileSync(outputPath, code); console.log(Generated: ${outputPath}); } generateLayout(cleaned_design.json, activity_login.xml);这段代码的关键在于提示词的构造。我把所有项目规范都写死在提示词里这样每次生成的结果风格一致。如果你有多个页面要处理可以把这段逻辑包在一个循环里遍历所有清洗后的 JSON 文件。生成出来的代码通常包含三部分布局 XML、colors.xml 的增量内容、dimens.xml 的增量内容。我会把后两部分手动合并到项目的资源文件里布局 XML 直接放到对应的 res/layout 目录下。4.4 生成代码的适配与微调Claude Code 生成的代码不能直接无脑用有几类问题需要手动处理。第一类是约束冲突。设计稿里有些元素的定位关系在 JSON 里表达得不完整生成代码时可能会出现约束不足或者约束过度的情况。比如一个元素同时有layout_constraintStart_toStartOfparent和layout_constraintEnd_toEndOfparent但宽度又设了固定值这就会导致约束冲突。遇到这种情况我会根据设计稿的实际意图保留一个约束把另一个改成对应的 margin。第二类是文本内容。设计稿里的文本是占位文案生成代码时会直接写死在android:text属性里。我会把这些文本提取到 strings.xml然后在布局文件里用string/引用。这一步虽然繁琐但为了后续的国际化支持不能省。第三类是图片资源。生成代码里用drawable/占位符代替了实际图片你需要把设计稿里的图片导出按照生成的占位符名称放到 drawable 目录下。我一般会让设计师把图片资源单独打包命名跟设计稿里的图层名一致这样对应起来很快。第四类是深色模式适配。如果项目需要支持深色模式生成代码里的颜色值需要提取到values/colors.xml和values-night/colors.xml两套。我会在提示词里加上“颜色值使用主题属性引用”的要求让 Claude Code 生成?attr/colorPrimary这样的引用而不是硬编码颜色值。4.5 一个完整页面的实操记录我拿一个登录页面做了完整测试。设计稿包含顶部 Logo、标题文字、两个输入框手机号、密码、一个登录按钮、底部注册链接。整个页面在 MasterGo 里用了自动布局图层命名规范间距都是 8 的倍数。导出 JSON 后清洗脚本跑了 0.3 秒生成了一个 12KB 的清洗后文件。发给 Claude Code 后大概 15 秒返回了生成结果。生成的布局文件是一个 ConstraintLayout 根布局里面嵌套了一个垂直的 FlexboxLayout 放 Logo 和标题下面是一个垂直的 LinearLayout 放输入框和按钮底部注册链接用 ConstraintLayout 的底部约束定位。我检查了一遍发现两个问题输入框的 hint 文字没有生成因为设计稿里输入框是空状态没有占位文字登录按钮的圆角在 JSON 里是 8但生成代码里写成了 8dp 的 cornerRadius实际项目里按钮用的是 MaterialButton应该用app:cornerRadius属性。这两个问题手动改一下总共花了不到两分钟。整个流程从导出到可用代码大概五分钟。如果纯手写这个页面我估计要四十分钟左右。效率提升还是很明显的。5. 常见问题与排查技巧实录5.1 生成代码层级嵌套过深怎么办这是最常见的问题。Claude Code 有时候会生成三层甚至四层的嵌套布局比如 ConstraintLayout 里面套 LinearLayoutLinearLayout 里面又套 ConstraintLayout。嵌套过深会影响渲染性能尤其是在列表项里。排查思路先看 JSON 数据里节点的层级关系。如果设计稿本身就是多层嵌套的那生成代码嵌套深是正常的需要从设计稿层面优化。如果设计稿层级很扁平但生成代码嵌套深那就是 Claude Code 的理解出了问题。解决方法在提示词里加一条“布局层级不超过三层优先使用 ConstraintLayout 的扁平化约束”。如果还是不行可以手动把内层布局的约束提升到外层用 ConstraintLayout 的 barrier 或者 guideline 来替代嵌套。我试过一个极端案例一个卡片列表项生成代码嵌套了五层。后来发现是设计稿里每个元素都单独分组了导出 JSON 后每个分组变成一个 Frame 节点Claude Code 就把每个 Frame 都转成了一层布局。解决办法是在清洗脚本里把单子节点的 Frame 合并到父节点减少无意义的层级。5.2 颜色值和尺寸值提取不准确有时候生成代码里的颜色值跟设计稿对不上或者尺寸差了 1dp。这通常是两个原因造成的。一是颜色值的转换精度问题。设计稿里的颜色是浮点数转成整数时如果四舍五入的规则不一致就会差 1。比如 0.5 乘以 255 等于 127.5有的地方取 127有的地方取 128。我在清洗脚本里统一用Math.round保证一致性。二是尺寸值的单位问题。设计稿里的尺寸可能是 pt 或者 px导出时没有转换成 dp。Android 里 1dp 约等于 1pt但不完全相等。如果设计稿用的是 375px 宽度的画板那 1px 约等于 1dp在 mdpi 下。但如果画板宽度是 750px那 1px 等于 0.5dp需要做换算。我在清洗脚本里会根据画板宽度自动计算缩放比例统一转成 dp 值。提示在提示词里明确写“所有尺寸值已经是 dp 单位直接使用”可以避免 Claude Code 再做一次单位换算导致偏差。5.3 生成的 id 命名不符合项目规范Claude Code 默认生成的 id 命名有时候会用驼峰有时候会用下划线风格不统一。如果项目有严格的命名规范需要在提示词里写清楚。我一般会给出具体的命名规则和示例比如“id 命名使用 snake_case按钮用 btn_ 前缀文本用 tv_ 前缀图片用 iv_ 前缀输入框用 et_ 前缀。例如btn_login、tv_title、iv_avatar、et_phone。”如果生成结果还是不对可以在清洗脚本里做一轮后处理用正则把不符合规范的 id 批量替换掉。我写过一个简单的替换脚本把驼峰转下划线然后根据节点类型加前缀效果还不错。5.4 复杂交互组件的处理方式设计稿里有些组件是有交互状态的比如按钮的按下态、输入框的聚焦态、复选框的选中态。这些状态在静态设计稿里通常只展示了默认态导出 JSON 后也只有默认态的数据。处理方式有两种。一种是在提示词里说明“按钮需要生成 selector包含默认态和按下态”然后手动补充按下态的颜色值。另一种是在 MasterGo 里把组件的所有状态都画出来导出时每个状态作为一个独立的节点Claude Code 会根据节点名称里的状态标识自动生成 selector。我倾向于第二种方式虽然设计稿工作量增加了但后续生成代码的自动化程度更高。命名规则可以约定为btn_login_normal、btn_login_pressedClaude Code 看到这种命名就知道要生成 selector。5.5 常见问题速查表问题现象可能原因排查方法解决方式布局嵌套过深设计稿分组过多检查 JSON 节点层级清洗脚本合并单子节点 Frame颜色值偏差浮点转整数精度问题对比设计稿和生成代码的颜色值统一用 Math.round 转换尺寸偏差单位换算错误检查画板宽度和缩放比例清洗脚本统一转 dpid 命名不规范提示词未明确规范检查生成代码的 id 字段提示词加命名规则或后处理替换约束冲突JSON 定位信息不完整检查生成代码的约束属性手动调整约束或补充 margin文本未提取提示词未要求检查 android:text 属性提示词加“文本提取到 strings.xml”图片资源缺失未导出图片检查 drawable 目录按占位符名称导出图片5.6 几个我踩过的坑第一个坑是 JSON 文件太大导致 API 超时。一个复杂页面的 JSON 可能有几 MB直接发给 Claude Code 会超出 token 限制。解决办法是在清洗脚本里做分页处理把页面拆成几个区块分别生成代码后再合并。或者只保留必要的字段把调试用的元数据全部删掉。第二个坑是设计稿里的隐藏图层。MasterGo 里有些图层是隐藏的但导出 JSON 时默认会包含。这些隐藏图层生成代码后会变成不可见的 View白白增加布局层级。我在清洗脚本里加了一个过滤规则把 visible 为 false 的节点直接跳过。第三个坑是字体大小单位。设计稿里的字体大小有时候是 px生成代码时如果直接写成 sp在不同密度屏幕上显示效果会不一致。我统一在清洗脚本里把字体大小转成 sp转换比例跟尺寸的 dp 转换保持一致。第四个坑是自动布局的换行处理。MasterGo 的自动布局支持换行wrap但导出的 JSON 里没有明确的换行标识。Claude Code 生成代码时可能会用 FlexboxLayout 的 flexWrap 属性但有时候会漏掉。我在提示词里加了一条“如果节点有多个子元素且总宽度超过父容器宽度考虑使用 flexWrap”效果好了很多。6. 进阶技巧与效率提升6.1 批量处理多个页面的流水线搭建单个页面手动跑一遍流程还能接受但如果一个 App 有几十个页面手动操作就太慢了。我搭了一个简单的流水线把整个流程自动化。流水线的核心是一个 Node.js 脚本它做以下几件事监听指定目录下的 JSON 文件变化一旦有新文件就自动触发清洗和生成流程生成结果按页面名称分类输出到不同的目录。同时脚本会维护一个映射表记录每个页面用到的颜色值和尺寸值最后统一生成 colors.xml 和 dimens.xml。这个流水线跑起来之后设计师改完设计稿导出 JSON 放到指定目录几分钟后就能拿到全套布局代码和资源文件。我实测下来十个页面的批量处理大概需要三到五分钟比手动一个个处理快了一个数量级。6.2 建立项目级的提示词模板库不同项目的技术栈和规范不一样每次都要重新写提示词很麻烦。我建了一个提示词模板库按项目类型分类新项目模板、老项目维护模板、特定 UI 框架模板比如 Material Design、Cupertino 风格。每个模板里预置了该项目的技术栈、命名规范、资源管理方式、最小 API 版本等信息。用的时候只需要把 JSON 数据拼接到模板后面就行。模板库用 Git 管理团队里每个人都可以贡献和更新模板保证整个团队的生成代码风格一致。6.3 生成代码的质量校验生成代码不能直接提交需要过一遍质量校验。我写了一个简单的校验脚本检查以下几项布局层级是否超过三层、是否有硬编码的颜色值、是否有硬编码的尺寸值、id 命名是否符合规范、是否有未提取的文本内容。校验不通过的代码会标记出来人工确认后再决定是修改还是重新生成。这个校验脚本帮我拦住了不少低级问题尤其是在批量处理的时候避免了大量返工。6.4 跟版本控制系统的配合生成的代码我建议单独建一个分支或者一个目录来管理。每次生成后用 Git diff 对比一下跟上一版的差异确认没有意外改动后再合并到主分支。如果设计稿频繁改动可以给每次生成打一个 tag记录对应的设计稿版本。这样后面如果发现布局有问题可以快速定位到是哪个版本的设计稿导致的。我在实际项目中的体会是这套流程最大的价值不是完全替代手写布局而是把开发者从重复劳动中解放出来把精力放在交互逻辑、性能优化和适配这些真正需要人脑思考的事情上。生成代码的质量大概能到“可用”的水平剩下的“好用”和“稳定”还是得靠开发者自己打磨。但即便如此效率提升也是实实在在的。 
长河君 · 2026/10/20 12:27:31 · 阅读 1.2k MasterGo + Claude Code：Android 布局代码自动生成实战
1. 这套组合到底在解决什么问题设计稿到代码之间的那道墙做过 Android 开发的人都懂。设计师在工具里画完界面导出标注图开发对着标注一个个写 XML宽高、间距、颜色、圆角、阴影全是手工活。一个中等复杂度的页面光布局就能耗掉大半天改一版设计再重来一遍。更别提那些嵌套层级深、约束关系绕的界面写到最后自己都理不清哪个 View 套在哪个 View 里面。MasterGo 加 Claude Code 这套组合核心思路就是把这堵墙拆掉。MasterGo 负责产出结构化的设计数据Claude Code 负责把这些数据翻译成可用的 Android 布局代码。整个链路不需要你手动量像素、不需要你逐个写属性设计稿改完重新生成一遍就行。这套流程适合谁用如果你是一个人扛一个 App 的独立开发者或者小团队里前后端一把抓的全栈选手再或者你是个 Android 新手对 ConstraintLayout 的约束关系还不太熟这套方法能帮你省掉大量重复劳动。但如果你对布局性能有极致要求或者项目里有一套非常严格的代码规范需要逐行 review那生成出来的代码还是得自己过一遍不能直接无脑用。我实测下来的感受是简单页面基本可以做到生成即用复杂页面大概能省掉百分之六七十的布局编写时间剩下的时间花在微调和适配上面。这个投入产出比已经相当可观了。2. 整体方案设计与工具链拆解2.1 为什么选 MasterGo 而不是其他设计工具MasterGo 在这套流程里的角色是“结构化数据源”。它跟 Claude Code 配合的关键在于MasterGo 的设计文件可以通过插件体系导出成 JSON 格式的节点树每个节点包含位置、尺寸、样式、层级关系等完整信息。这些信息就是 Claude Code 生成布局代码的原材料。选 MasterGo 有几个实际原因。第一它的插件生态比较开放你可以自己写导出插件也可以直接用社区里现成的导出工具。第二它的图层命名和分组逻辑比较规范导出的节点树结构清晰不会出现一堆“矩形 1”“编组 23”这种无意义命名。第三它的自动布局功能跟 Android 的 Flexbox 思路很接近设计师用自动布局画的界面导出后的约束关系天然就适合转成 ConstraintLayout 或 FlexboxLayout。当然其他设计工具也能做类似的事情但 MasterGo 的插件开发门槛相对低你不需要去逆向它的文件格式官方提供了完整的插件 API 文档。这一点对于想自己定制导出逻辑的开发者来说很关键。2.2 Claude Code 在链路中扮演什么角色Claude Code 不是简单的“设计稿转代码”工具。它的价值在于理解上下文。你给它一份 JSON 节点树它不只是做字段映射而是会分析这个界面的结构意图哪些元素应该用 ConstraintLayout 的约束关系来表达哪些应该用 LinearLayout 的权重来分配哪些地方适合用 Guideline 做辅助定位。举个例子设计稿里有两个按钮水平排列中间有固定间距。如果只是机械映射可能会生成一个 LinearLayout 里面放两个 Button用 margin 控制间距。但 Claude Code 会判断这个场景更适合用 ConstraintLayout 的链式约束因为这样在横屏或者不同屏幕宽度下表现更稳定。这种判断能力是它跟普通模板工具的本质区别。另外Claude Code 支持多轮对话。你可以先让它生成一版然后告诉它“把外层改成 ConstraintLayout”“这个 TextView 加个 maxLines 限制”“颜色值统一用 colors.xml 里的引用”它会基于上一版代码做增量修改而不是每次从头生成。这个交互方式在实际开发中非常顺手。2.3 完整链路的三个关键环节整个流程可以拆成三个环节设计稿整理、数据导出与清洗、代码生成与适配。设计稿整理这一步最容易被忽视但恰恰是最影响最终效果的。设计师如果图层命名混乱、分组逻辑随意导出的 JSON 节点树就会很难读Claude Code 理解起来也费劲。所以我在实际操作中会先花十分钟跟设计师对齐命名规范页面根节点叫什么、列表项怎么命名、可复用组件怎么标记。这一步做完后面所有环节都顺畅。数据导出与清洗环节我会写一个简单的 Node.js 脚本把 MasterGo 插件导出的 JSON 做一轮预处理。主要做三件事把绝对定位转成相对约束、把重复的样式值提取成变量、把图片资源替换成占位符。这轮清洗能大幅提升 Claude Code 生成代码的准确率。代码生成与适配环节我会把清洗后的 JSON 和一段系统提示词一起发给 Claude Code。提示词里会写明项目用的技术栈比如“用 Kotlin ConstraintLayout不要用 DataBinding”、命名规范比如“id 用 snake_case”、以及一些项目特有的约束比如“最小支持 API 24”。这样生成出来的代码基本不需要大改。3. 核心细节解析与实操要点3.1 设计稿整理阶段的关键操作设计稿整理不是简单地让设计师“好好命名”而是有一套具体的操作规范。我在实际项目中总结了几条硬性要求执行下来效果很明显。第一条所有可交互元素必须用组件Component的形式存在。按钮、输入框、卡片这些重复出现的元素在 MasterGo 里做成组件后导出的 JSON 里会带有 componentId 字段。Claude Code 看到这个字段就知道这是一个可复用组件生成代码时会自动提取成独立的布局文件或者自定义 View而不是在每个用到的地方重复生成一遍。第二条图层命名用英文加下划线不要用中文和空格。比如“登录按钮”写成“btn_login”“用户头像”写成“iv_avatar”。这个命名会直接变成生成代码里的资源 id如果命名不规范后面还得手动改一遍。我试过让设计师用中文命名结果生成的代码里 id 全是拼音可读性很差。第三条自动布局的间距用统一的间距系统。比如所有间距都是 4 的倍数4dp、8dp、12dp、16dp、24dp。这样导出的 JSON 里间距值很规整Claude Code 生成代码时可以直接映射到 dimens.xml 里的标准间距值而不是每个地方都写一个硬编码的数字。注意设计稿整理这一步不要跳过。我见过太多人直接拿原始设计稿去导出结果生成的代码里全是魔法数字和混乱的层级嵌套改起来比自己重写还累。3.2 JSON 节点树的结构与字段含义MasterGo 插件导出的 JSON 节点树每个节点包含以下核心字段{ id: node_001, name: btn_login, type: FRAME, x: 24, y: 480, width: 327, height: 48, layoutMode: HORIZONTAL, primaryAxisAlignItems: CENTER, counterAxisAlignItems: CENTER, itemSpacing: 8, paddingLeft: 16, paddingRight: 16, paddingTop: 12, paddingBottom: 12, cornerRadius: 8, fills: [{type: SOLID, color: {r: 0.2, g: 0.4, b: 0.9, a: 1}}], children: [] }这里有几个字段需要特别关注。layoutMode表示这个节点是否启用了自动布局值为 HORIZONTAL 或 VERTICAL。如果这个字段存在说明设计师用了自动布局生成代码时应该优先考虑 FlexboxLayout 或者 ConstraintLayout 的链式约束。如果不存在说明是绝对定位需要根据 x、y、width、height 反推约束关系。primaryAxisAlignItems和counterAxisAlignItems对应的是主轴和交叉轴的对齐方式直接映射到 Android 的 gravity 或者 constraint 的 bias 值。itemSpacing是子元素之间的间距对应 LinearLayout 的 divider 或者 ConstraintLayout 的 margin。fills数组里的颜色值是 0 到 1 的浮点数需要转换成 Android 的十六进制颜色值。转换公式很简单Math.round(r * 255)得到红色分量以此类推然后拼成#AARRGGBB格式。3.3 提示词工程怎么跟 Claude Code 说清楚需求跟 Claude Code 交互提示词的质量直接决定生成代码的质量。我经过多次迭代总结出一个比较稳定的提示词模板你是一个资深 Android 开发工程师。请根据以下设计稿 JSON 数据生成对应的 Android 布局代码。 技术要求 - 使用 Kotlin 语言 - 布局文件用 XML根布局优先使用 ConstraintLayout - 如果节点有 layoutMode 字段优先考虑 FlexboxLayout - 所有尺寸使用 dp字体大小使用 sp - 颜色值提取到 colors.xml尺寸值提取到 dimens.xml - 图片资源用 drawable/ 占位符代替 - id 命名使用 snake_case前缀遵循 Android 规范btn_、tv_、iv_、et_ 等 - 最小支持 API 24 设计稿 JSON 数据如下 [粘贴清洗后的 JSON]这个模板里每一行要求都有实际意义。比如“优先使用 ConstraintLayout”是因为 ConstraintLayout 在复杂布局下的性能表现更好而且约束关系比嵌套 LinearLayout 更扁平。“颜色值提取到 colors.xml”是为了后续换肤和统一管理。“id 命名规范”是为了生成的代码能直接融入现有项目。我试过不给这些约束直接让 Claude Code 自由发挥结果它有时候用 LinearLayout 嵌套三层有时候用 RelativeLayout风格不统一后面还得手动统一一遍。给了明确约束之后生成代码的一致性好了很多。3.4 从 JSON 到 XML 的映射规则Claude Code 在生成代码时内部有一套映射逻辑。我通过观察生成结果反推出了它常用的映射规则了解这些规则有助于你预判生成结果也方便你在提示词里做针对性调整。JSON 字段Android 对应说明layoutMode: HORIZONTALFlexboxLayout flexDirectionrow水平自动布局layoutMode: VERTICALFlexboxLayout flexDirectioncolumn垂直自动布局primaryAxisAlignItems: CENTERjustifyContentcenter主轴居中counterAxisAlignItems: CENTERalignItemscenter交叉轴居中itemSpacingFlexboxLayout 的 margin 或 divider子元素间距cornerRadiusapp:cardCornerRadius 或 background 的 shape圆角fillsandroid:background 或 tint填充色x, y, width, heightConstraintLayout 的约束绝对定位转约束对于没有 layoutMode 的节点Claude Code 会根据 x、y 坐标和父节点的关系来推断约束。比如一个节点的 x 值是 24父节点宽度是 375那它大概率会生成layout_constraintStart_toStartOfparent加上marginStart24dp。如果 x 值是 187接近父节点宽度的一半它可能会用layout_constraintStart_toStartOfparent和layout_constraintEnd_toEndOfparent加上layout_constraintHorizontal_bias0.5来实现居中。4. 完整实操流程与核心环节实现4.1 环境准备与工具安装先把手头的工具链搭起来。你需要准备的东西不多但每一样都得装对版本。MasterGo 这边注册账号后新建一个设计文件或者打开已有的设计稿。在插件市场里搜索“JSON Export”或者类似的导出插件安装到你的账号下。如果找不到合适的现成插件可以自己写一个MasterGo 的插件开发文档里有完整的示例代码核心逻辑就是遍历当前页面的节点树把每个节点的属性序列化成 JSON。Claude Code 这边你需要一个能访问 Claude API 的环境。我一般是在本地用 Node.js 写一个脚本把提示词和 JSON 数据拼在一起调用 API 后把返回的代码写到文件里。这样比在网页端手动复制粘贴效率高得多尤其是需要批量处理多个页面的时候。本地开发环境就是标准的 Android 项目Android Studio 最新稳定版Kotlin 插件装好Gradle 版本跟项目匹配就行。我建议单独建一个模块或者一个分支来放生成的代码方便对比和回滚。4.2 导出设计稿数据并清洗打开 MasterGo 设计稿选中你要导出的页面或画板运行导出插件。插件会生成一个 JSON 文件里面是完整的节点树。这个文件通常比较大一个中等复杂度的页面大概有几百个节点JSON 文件可能有好几 MB。拿到原始 JSON 后先做一轮清洗。我写了一个 Node.js 脚本主要做以下几件事const fs require(fs); // 读取原始 JSON const raw JSON.parse(fs.readFileSync(raw_design.json, utf8)); // 递归清洗节点 function cleanNode(node) { const cleaned { id: node.id, name: node.name, type: node.type, x: Math.round(node.x), y: Math.round(node.y), width: Math.round(node.width), height: Math.round(node.height), }; // 只保留有意义的样式字段 if (node.layoutMode) { cleaned.layoutMode node.layoutMode; cleaned.primaryAxisAlignItems node.primaryAxisAlignItems; cleaned.counterAxisAlignItems node.counterAxisAlignItems; cleaned.itemSpacing node.itemSpacing; } if (node.cornerRadius) cleaned.cornerRadius node.cornerRadius; if (node.fills node.fills.length 0) { cleaned.fills node.fills.map(f ({ type: f.type, color: f.color ? { r: Math.round(f.color.r * 255), g: Math.round(f.color.g * 255), b: Math.round(f.color.b * 255), a: f.color.a } : null })); } // 递归处理子节点 if (node.children node.children.length 0) { cleaned.children node.children.map(cleanNode); } return cleaned; } const cleaned cleanNode(raw); fs.writeFileSync(cleaned_design.json, JSON.stringify(cleaned, null, 2));这个脚本做了几件关键的事把浮点数坐标取整去掉冗余字段把颜色值从 0-1 浮点数转成 0-255 整数。清洗后的 JSON 体积能缩小一半以上而且可读性大幅提升。提示清洗脚本里可以根据项目需要加更多规则。比如把连续多个相同样式的节点合并、把图片节点替换成占位符、把文本内容提取到 strings.xml 的映射表里。规则越细后面生成代码的准确率越高。4.3 调用 Claude Code 生成布局代码清洗完数据后把 JSON 和提示词拼在一起发给 Claude Code。我一般用 Node.js 脚本批量处理核心代码如下const Anthropic require(anthropic-ai/sdk); const fs require(fs); const client new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY }); async function generateLayout(jsonPath, outputPath) { const designJson fs.readFileSync(jsonPath, utf8); const prompt 你是一个资深 Android 开发工程师。请根据以下设计稿 JSON 数据生成对应的 Android 布局代码。 技术要求 - 使用 Kotlin 语言 - 布局文件用 XML根布局优先使用 ConstraintLayout - 如果节点有 layoutMode 字段优先考虑 FlexboxLayout - 所有尺寸使用 dp字体大小使用 sp - 颜色值提取到 colors.xml尺寸值提取到 dimens.xml - 图片资源用 drawable/ 占位符代替 - id 命名使用 snake_case前缀遵循 Android 规范 - 最小支持 API 24 设计稿 JSON 数据如下 ${designJson}; const response await client.messages.create({ model: claude-sonnet-4-20250514, max_tokens: 8192, messages: [{ role: user, content: prompt }] }); const code response.content[0].text; fs.writeFileSync(outputPath, code); console.log(Generated: ${outputPath}); } generateLayout(cleaned_design.json, activity_login.xml);这段代码的关键在于提示词的构造。我把所有项目规范都写死在提示词里这样每次生成的结果风格一致。如果你有多个页面要处理可以把这段逻辑包在一个循环里遍历所有清洗后的 JSON 文件。生成出来的代码通常包含三部分布局 XML、colors.xml 的增量内容、dimens.xml 的增量内容。我会把后两部分手动合并到项目的资源文件里布局 XML 直接放到对应的 res/layout 目录下。4.4 生成代码的适配与微调Claude Code 生成的代码不能直接无脑用有几类问题需要手动处理。第一类是约束冲突。设计稿里有些元素的定位关系在 JSON 里表达得不完整生成代码时可能会出现约束不足或者约束过度的情况。比如一个元素同时有layout_constraintStart_toStartOfparent和layout_constraintEnd_toEndOfparent但宽度又设了固定值这就会导致约束冲突。遇到这种情况我会根据设计稿的实际意图保留一个约束把另一个改成对应的 margin。第二类是文本内容。设计稿里的文本是占位文案生成代码时会直接写死在android:text属性里。我会把这些文本提取到 strings.xml然后在布局文件里用string/引用。这一步虽然繁琐但为了后续的国际化支持不能省。第三类是图片资源。生成代码里用drawable/占位符代替了实际图片你需要把设计稿里的图片导出按照生成的占位符名称放到 drawable 目录下。我一般会让设计师把图片资源单独打包命名跟设计稿里的图层名一致这样对应起来很快。第四类是深色模式适配。如果项目需要支持深色模式生成代码里的颜色值需要提取到values/colors.xml和values-night/colors.xml两套。我会在提示词里加上“颜色值使用主题属性引用”的要求让 Claude Code 生成?attr/colorPrimary这样的引用而不是硬编码颜色值。4.5 一个完整页面的实操记录我拿一个登录页面做了完整测试。设计稿包含顶部 Logo、标题文字、两个输入框手机号、密码、一个登录按钮、底部注册链接。整个页面在 MasterGo 里用了自动布局图层命名规范间距都是 8 的倍数。导出 JSON 后清洗脚本跑了 0.3 秒生成了一个 12KB 的清洗后文件。发给 Claude Code 后大概 15 秒返回了生成结果。生成的布局文件是一个 ConstraintLayout 根布局里面嵌套了一个垂直的 FlexboxLayout 放 Logo 和标题下面是一个垂直的 LinearLayout 放输入框和按钮底部注册链接用 ConstraintLayout 的底部约束定位。我检查了一遍发现两个问题输入框的 hint 文字没有生成因为设计稿里输入框是空状态没有占位文字登录按钮的圆角在 JSON 里是 8但生成代码里写成了 8dp 的 cornerRadius实际项目里按钮用的是 MaterialButton应该用app:cornerRadius属性。这两个问题手动改一下总共花了不到两分钟。整个流程从导出到可用代码大概五分钟。如果纯手写这个页面我估计要四十分钟左右。效率提升还是很明显的。5. 常见问题与排查技巧实录5.1 生成代码层级嵌套过深怎么办这是最常见的问题。Claude Code 有时候会生成三层甚至四层的嵌套布局比如 ConstraintLayout 里面套 LinearLayoutLinearLayout 里面又套 ConstraintLayout。嵌套过深会影响渲染性能尤其是在列表项里。排查思路先看 JSON 数据里节点的层级关系。如果设计稿本身就是多层嵌套的那生成代码嵌套深是正常的需要从设计稿层面优化。如果设计稿层级很扁平但生成代码嵌套深那就是 Claude Code 的理解出了问题。解决方法在提示词里加一条“布局层级不超过三层优先使用 ConstraintLayout 的扁平化约束”。如果还是不行可以手动把内层布局的约束提升到外层用 ConstraintLayout 的 barrier 或者 guideline 来替代嵌套。我试过一个极端案例一个卡片列表项生成代码嵌套了五层。后来发现是设计稿里每个元素都单独分组了导出 JSON 后每个分组变成一个 Frame 节点Claude Code 就把每个 Frame 都转成了一层布局。解决办法是在清洗脚本里把单子节点的 Frame 合并到父节点减少无意义的层级。5.2 颜色值和尺寸值提取不准确有时候生成代码里的颜色值跟设计稿对不上或者尺寸差了 1dp。这通常是两个原因造成的。一是颜色值的转换精度问题。设计稿里的颜色是浮点数转成整数时如果四舍五入的规则不一致就会差 1。比如 0.5 乘以 255 等于 127.5有的地方取 127有的地方取 128。我在清洗脚本里统一用Math.round保证一致性。二是尺寸值的单位问题。设计稿里的尺寸可能是 pt 或者 px导出时没有转换成 dp。Android 里 1dp 约等于 1pt但不完全相等。如果设计稿用的是 375px 宽度的画板那 1px 约等于 1dp在 mdpi 下。但如果画板宽度是 750px那 1px 等于 0.5dp需要做换算。我在清洗脚本里会根据画板宽度自动计算缩放比例统一转成 dp 值。提示在提示词里明确写“所有尺寸值已经是 dp 单位直接使用”可以避免 Claude Code 再做一次单位换算导致偏差。5.3 生成的 id 命名不符合项目规范Claude Code 默认生成的 id 命名有时候会用驼峰有时候会用下划线风格不统一。如果项目有严格的命名规范需要在提示词里写清楚。我一般会给出具体的命名规则和示例比如“id 命名使用 snake_case按钮用 btn_ 前缀文本用 tv_ 前缀图片用 iv_ 前缀输入框用 et_ 前缀。例如btn_login、tv_title、iv_avatar、et_phone。”如果生成结果还是不对可以在清洗脚本里做一轮后处理用正则把不符合规范的 id 批量替换掉。我写过一个简单的替换脚本把驼峰转下划线然后根据节点类型加前缀效果还不错。5.4 复杂交互组件的处理方式设计稿里有些组件是有交互状态的比如按钮的按下态、输入框的聚焦态、复选框的选中态。这些状态在静态设计稿里通常只展示了默认态导出 JSON 后也只有默认态的数据。处理方式有两种。一种是在提示词里说明“按钮需要生成 selector包含默认态和按下态”然后手动补充按下态的颜色值。另一种是在 MasterGo 里把组件的所有状态都画出来导出时每个状态作为一个独立的节点Claude Code 会根据节点名称里的状态标识自动生成 selector。我倾向于第二种方式虽然设计稿工作量增加了但后续生成代码的自动化程度更高。命名规则可以约定为btn_login_normal、btn_login_pressedClaude Code 看到这种命名就知道要生成 selector。5.5 常见问题速查表问题现象可能原因排查方法解决方式布局嵌套过深设计稿分组过多检查 JSON 节点层级清洗脚本合并单子节点 Frame颜色值偏差浮点转整数精度问题对比设计稿和生成代码的颜色值统一用 Math.round 转换尺寸偏差单位换算错误检查画板宽度和缩放比例清洗脚本统一转 dpid 命名不规范提示词未明确规范检查生成代码的 id 字段提示词加命名规则或后处理替换约束冲突JSON 定位信息不完整检查生成代码的约束属性手动调整约束或补充 margin文本未提取提示词未要求检查 android:text 属性提示词加“文本提取到 strings.xml”图片资源缺失未导出图片检查 drawable 目录按占位符名称导出图片5.6 几个我踩过的坑第一个坑是 JSON 文件太大导致 API 超时。一个复杂页面的 JSON 可能有几 MB直接发给 Claude Code 会超出 token 限制。解决办法是在清洗脚本里做分页处理把页面拆成几个区块分别生成代码后再合并。或者只保留必要的字段把调试用的元数据全部删掉。第二个坑是设计稿里的隐藏图层。MasterGo 里有些图层是隐藏的但导出 JSON 时默认会包含。这些隐藏图层生成代码后会变成不可见的 View白白增加布局层级。我在清洗脚本里加了一个过滤规则把 visible 为 false 的节点直接跳过。第三个坑是字体大小单位。设计稿里的字体大小有时候是 px生成代码时如果直接写成 sp在不同密度屏幕上显示效果会不一致。我统一在清洗脚本里把字体大小转成 sp转换比例跟尺寸的 dp 转换保持一致。第四个坑是自动布局的换行处理。MasterGo 的自动布局支持换行wrap但导出的 JSON 里没有明确的换行标识。Claude Code 生成代码时可能会用 FlexboxLayout 的 flexWrap 属性但有时候会漏掉。我在提示词里加了一条“如果节点有多个子元素且总宽度超过父容器宽度考虑使用 flexWrap”效果好了很多。6. 进阶技巧与效率提升6.1 批量处理多个页面的流水线搭建单个页面手动跑一遍流程还能接受但如果一个 App 有几十个页面手动操作就太慢了。我搭了一个简单的流水线把整个流程自动化。流水线的核心是一个 Node.js 脚本它做以下几件事监听指定目录下的 JSON 文件变化一旦有新文件就自动触发清洗和生成流程生成结果按页面名称分类输出到不同的目录。同时脚本会维护一个映射表记录每个页面用到的颜色值和尺寸值最后统一生成 colors.xml 和 dimens.xml。这个流水线跑起来之后设计师改完设计稿导出 JSON 放到指定目录几分钟后就能拿到全套布局代码和资源文件。我实测下来十个页面的批量处理大概需要三到五分钟比手动一个个处理快了一个数量级。6.2 建立项目级的提示词模板库不同项目的技术栈和规范不一样每次都要重新写提示词很麻烦。我建了一个提示词模板库按项目类型分类新项目模板、老项目维护模板、特定 UI 框架模板比如 Material Design、Cupertino 风格。每个模板里预置了该项目的技术栈、命名规范、资源管理方式、最小 API 版本等信息。用的时候只需要把 JSON 数据拼接到模板后面就行。模板库用 Git 管理团队里每个人都可以贡献和更新模板保证整个团队的生成代码风格一致。6.3 生成代码的质量校验生成代码不能直接提交需要过一遍质量校验。我写了一个简单的校验脚本检查以下几项布局层级是否超过三层、是否有硬编码的颜色值、是否有硬编码的尺寸值、id 命名是否符合规范、是否有未提取的文本内容。校验不通过的代码会标记出来人工确认后再决定是修改还是重新生成。这个校验脚本帮我拦住了不少低级问题尤其是在批量处理的时候避免了大量返工。6.4 跟版本控制系统的配合生成的代码我建议单独建一个分支或者一个目录来管理。每次生成后用 Git diff 对比一下跟上一版的差异确认没有意外改动后再合并到主分支。如果设计稿频繁改动可以给每次生成打一个 tag记录对应的设计稿版本。这样后面如果发现布局有问题可以快速定位到是哪个版本的设计稿导致的。我在实际项目中的体会是这套流程最大的价值不是完全替代手写布局而是把开发者从重复劳动中解放出来把精力放在交互逻辑、性能优化和适配这些真正需要人脑思考的事情上。生成代码的质量大概能到“可用”的水平剩下的“好用”和“稳定”还是得靠开发者自己打磨。但即便如此效率提升也是实实在在的。