1. 为什么非要把设计工具和 AI 编程绑在一起先交代一下背景。我平时的工作流基本是接到需求后先在 MasterGo 里把界面画出来评审通过后再到 Android Studio 里手写 XML。这个流程最大的问题不在画图而在“从设计稿到布局代码”的这段翻译过程同样的一个间距、一条分割线、一个圆角不同的人翻译出来的代码完全不一样而且这一步极其耗时。尤其是碰到内页、设置页这种信息密集的界面反复调整约束和间距就能磨掉一下午。后来我开始尝试用 Claude Code 做布局生成配合 MasterGo 里整理好的设计稿把之前最耗时的“照着图写 XML”环节直接变成“看图核对、自动产出”。实测下来一个中等复杂度的页面大概二十多个控件、三四个嵌套层级从拿到设计稿到能编译跑起来时间压缩到原来的三分之一左右。这篇文章就把这套实践完整拆开从设计源文件的整理方式、Claude Code 的接入套路、到实际生成 XML 的细节和踩过的坑全部过一遍。适合谁看如果你也在用 MasterGo 之类的设计工具出图平时自己写 Android 布局代码或者正打算把 AI 编程助手引入到日常开发流程里这篇文章应该能帮你避开不少弯路。里面的思路不依赖特定工具版本核心是“怎么让 AI 看懂设计稿、怎么让 AI 产出符合工程规范的代码”。2. MasterGo 侧的准备把设计稿整理到“AI 能看明白”的状态很多人以为把 MasterGo 的截图丢给 Claude Code它就自然能生成完美布局。实际试验过就知道这个想法过于乐观。AI 看图是真的但它看不懂设计稿里的“意图”。一个模块为什么占 12dp为什么按钮右对齐为什么文字只显示两行——这些信息在截图上是没有的需要我们在 MasterGo 侧先做一轮整理和标记。2.1 先打开自动布局别让 AI 靠猜MasterGo 里没有开启自动布局Auto Layout的图层在 AI 眼里就是一堆绝对定位的矩形生成出来的 XML 也只能是“写死”坐标和尺寸的方案。这种方案编译没问题但一旦设备密度变化、内容变长界面就崩了。所以第一步是把设计稿里的关键模块都改成自动布局。开启自动布局之后每个组件的间距规则、对齐方式、内边距信息就都变成了“可读取”的元数据。Claude Code 在理解截图时能明显更准确地推断出“这里应该用 LinearLayout 加权重”“这里应该是垂直排列”“两边间距是否一致”。亲测对比过同一张设计稿开没开自动布局生成的代码质量和可维护性差一个档次。2.2 切图命名要带语义不能是“矩形 56”MasterGo 默认的图层名通常叫“矩形 89”“组合 234”这种名字对 AI 来说毫无意义。在整理设计稿时我习惯把所有关键图层重命名规则很简单模块叫 module_xxx按钮叫 btn_xxx文本叫 txt_xxx图片占位符叫 img_xxx。不需要完美但至少要能看出“这是个什么东西”。这么做的好处是把截图给 Claude Code 之后它在生成代码时能给控件起一个对应的变量名或 id。比如看到图层名叫 txt_user_name它大概率会生成android:idid/txtUserName而不是textColor_123。别小看这一步它直接影响代码的可读性和后续维护成本。更重要的是如果你的设计稿里有多个状态按钮AI 能通过命名理解它们之间的关系而不是每个都是独立的神秘矩形。2.3 用标注补充截图里看不出但代码必须要用的信息截图能传达视觉样式但传达不了所有布局参数。比如某个控件的宽度是“充满父容器”还是“自适应内容”某个文本的行高是多少某个圆角只作用于左半边还是四角一致这些东西只靠看图和猜必然出错。我的做法是在设计稿上用注释文本框把这些关键信息标出来或者在给 Claude Code 的提示里单独列一份“设计约束清单”。一个比较实用的约定是主按钮高度固定 44dp次按钮高度固定 36dp页面左右安全边距 16dp模块间距 12dp卡片圆角 12dp。这些数值我每次都会在提示里明确写一遍Claude Code 就会严格遵守。如果全凭它自己看图推断生成的布局十有八九会在边距和尺寸上跟你较劲改起来比手写还慢。2.4 一次只给一张关键画板别把整个页面丢过去我最早犯的错就是把整个 MasterGo 页面里面包含十几个画板截图一次性丢给 Claude Code让它“照着这个生成 Layout”。结果它很容易把不同画板的元素混在一起或者把不是同一个屏幕上的组件硬塞进一个布局里。正确的做法是一个页面单独导出成一张截图并且只截取它的主界面区域。状态栏这类系统导航区域不需要截进去交给 Android 自身处理。如果界面里包含对话框、弹层、键盘弹起等特殊状态就在文字描述里单独说明不要依赖截图表达。总之输入越聚焦输出越精准。3. Claude Code 侧的准备把工程上下文和规则喂给它Claude Code 本身是一个非常能打的编程助手但它不是“看图说话”工具——它是需要上下文和约束的。这里说的上下文不只是设计截图还包括你的 Android 工程结构、最低支持版本、公司内部的一些代码规范、依赖库版本等。第一次使用如果只丢一张图和一句话它生成的代码大概率是“正确但没法用”的通用答案。3.1 在项目里建一个持续生效的指令文件稳定的工作流不能每次都在对话里临时写一堆要求。我会在项目根目录放一个CLAUDE.md文件把 Android 开发相关的硬性规则写进去。例如最低支持 API 级别、是否使用 ViewBinding、命名前缀、默认 padding 值、是否禁止硬编码、颜色必须引用资源文件等等。Claude Code 读了这个文件之后生成的代码会自动贴合这些规则比每次临时口头约束稳定得多。这个文件的维护需要一点耐心你可以边实践边补充。我最初只写了三行后来逐步加到了二十多行每次生成完代码如果有“它不遵守”的地方就把这条规则补充进去。运行几次之后你会发现生成的代码贴合度越来越高。本质上就是在慢慢建立一个“自动化的代码评审标准”。3.2 把重复出现的提示词沉淀成模板除了项目级规则之外针对“从设计图生成布局”这个具体任务我还会准备一段固定的任务提示词。大致框架是设定角色资深 Android 开发者熟悉 View 体系与 Material Design 规范。说明输入一张设计稿截图以及关键设计规范数值。说明输出完整的layout/*.xml文件使用 ConstraintLayout 或 LinearLayout 合理布局。特殊要求资源引用优先避免魔法数字支持不同屏幕密度命名与设计稿一致。预期格式直接输出 XML 代码块附带必要的布局说明。这段模板在每次生成时直接复用Claude Code 的产出质量会非常稳定。如果你觉得某些步骤生成的代码风格还不够理想就打磨模板里的提示词而不是每次临时改。这个“模板沉淀”的思路跟代码里的封装复用是一样的道理。3.3 明确工程中使用的 View 体系这里需要做个选择你的项目是用传统 XML ViewBinding还是已经开始迁移 Jetpack Compose这两者生成的代码完全不一样。虽然题目是“生成 Android 布局”但如果你让 Claude Code 自由发挥它常常会倾向于生成 Compose 代码因为那是当前比较主流的“新写法”。如果你的项目还在用 XML就必须在提示里明确说明。我自己的项目属于传统 View 体系所以我的模板里明确写了“使用 XML 布局不生成 Compose”。如果你所在的项目打算 Compose 化也可以让它生成 Composable 函数只是我下面提到的 XML 经验会不完全适用。记住这个前提后面所有实操都是基于传统 View 体系的。3.4 准备一个最小可运行的测试工程Claude Code 生成完 XML 之后我建议你有一个最小化的测试工程能直接把生成的布局文件丢进去编译运行。这个工程不需要完整的业务代码但要有正常的资源目录、主题、基本依赖。有了这个环境就能快速验证“这份布局语法是否正确”“约束是否冲突”“预览是否正常”而不用每次改完都拖进大项目里编译省时省力。之所以强调这一点是因为我在实际使用中发现Claude Code 生成的代码第一版通常不会完美到直接可用都会存在几个编译错误或约束冲突。如果有一个单独的测试工程调试反馈速度快非常多。这个测试工程花半小时搭好之后能省回来十几倍的时间。4. 实操全流程从设计稿到可用布局的五个步骤下面这条流程是我反复跑了很多轮之后沉淀下来的稳定路径。每一步都有自己的目的稍微跳步或者敷衍后面就会在细节上出问题所以建议按顺序做。4.1 第一步导出高清晰度截图并先人工看一眼准备好 MasterGo 画板之后导出 PNG 图片。不建议用过低的分辨率但也别太高宽度在 720 到 1080 像素之间比较合适。太高分辨率会让 Claude Code 在读取细节时反而抓不住重点太低了又看不清。如果设计稿是较长的列表页可以按屏幕高度分段多截几张不要拉伸成一张超长图。截图导出后先自己整体扫一眼。确认里面没有不合理的遮挡、遗漏的组件、明显的标注错误。这一步听着多余其实非常关键因为如果你自己都没发现设计稿的问题AI 也会照着错的稿子生成最后返工的还是你。多花一分钟检查能避免后面对话里反复纠正。4.2 第二步组织输入信息写清任务提示打开 Claude Code 之后把之前沉淀好的任务模板拿出来附上设计截图然后补充本次界面的特殊信息。我常用的行文格式是请根据以下设计稿生成 Android XML 布局。 工程要求使用 ConstraintLayout最低 API 26使用 ViewBinding。 设计版式标题区 / 输入区 / 操作区 三部分间距与截图一致。 关键尺寸左右边距 16dp间距 12dp按钮高度 44dp。 请确保无硬编码颜色全部引用 color/ 资源。这段信息的顺序也有一点讲究先说角色和输出目标再说硬性工程约束最后给具体尺寸。这样 Claude Code 在生成时会把约束逐层叠加而不是只盯着截图里的像素值。如果截图里有些元素是“状态栏高度占位”要单独说明“忽略顶部系统状态栏使用系统默认处理”。4.3 第三步让 Claude Code 先描述结构再写代码这里有一个能显著提升质量的小技巧要求 Claude Code 先用人话描述它看到的界面结构整理成布局层级树然后确认无误之后再让它生成 XML。比如层级大致为 ConstraintLayout - TextView标题顶部居中 - LinearLayout垂直包含两个输入框 - Button主操作底部约束到父容器底部这个步骤的角色有点像“设计评审”Claude Code 先把理解复述一遍你能在它写出代码前发现结构理解偏差。比如它把“两个输入框之间的间距”理解成了 24dp而实际设计稿是 12dp这时你直接纠正它的描述它生成的 XML 就会一次到位不用等写完再改。这一步多花一分钟后面省下的绝对不止十分钟。4.4 第四步生成 XML 后立刻做静态自查Claude Code 输出 XML 之后不要直接进工程编译先做静态自查。我一般会快速扫这几个点根布局类型是否合理不要所有页面都用 ConstraintLayout是否存在冲突的方向约束一个控件同时约束了左和右但宽度没有设为 0dp是否使用了硬编码尺寸和颜色id 命名是否和设计稿/提示中的选区一致是否有不必要的嵌套层级静态自查这一习惯养成后你甚至能在编译报错前就发现 90% 的明显问题。尤其是约束冲突这一类问题Claude Code 有时候会生成app:layout_constraintStart_toStartOfparent同时又有android:layout_widthwrap_content这种组合很容易因为内容长度不一而出现异常。看习惯了之后一眼就能识别出来。4.5 第五步进测试工程编译再用模拟器多尺寸验证静态自查没问题之后把文件放进测试工程的res/layout/目录重新编译。如果编译出了资源引用错误大概率是引用了不存在的color/或dimen/把对应资源补上就好。编译通过之后一定要用模拟器或真机看实际渲染效果。我这里强烈推荐至少验证三种屏幕一台较新的旗舰机、一台低端小屏机、一台平板。同一个 XML 在三种屏幕上可能会有完全不同的表现尤其涉及到权重和约束链时。检查的重点是边距是否被拉伸、字数变多时换行是否正常、按钮是否被挤到屏幕外。这一步是本地预览里最容易忽视但实际最影响体验的环节。5. 常见问题与排查技巧实录这套流程跑久了自然积累了不少“翻车”经验。我把高频出现的问题整理成一张速查表每一条都是在真实项目里踩过的不是凭空想象。5.1 单位换算错误导致布局“看起来不对”MasterGo 里的尺寸单位通常是像素而 Android 布局里用的是 dp。在 1x 设计稿下1dp 相当于 1px 的关系只在 160dpi 的屏幕上成立现代设备普遍是 2x、3x 甚至更高。如果 Claude Code 直接照抄截图时看到的像素值写出来的间距会显得特别小。我的处理策略是在提示词里明确说明设计稿的基准设备宽度比如 390dp并要求 Claude Code 把界面宽度理解成 360dp 基准。比如设计稿总宽 390pt这是 MasterGo 的通用逻辑单位那么所有尺寸都按 390 这个基准来算即可。事实上 MasterGo 上的单位在标注模式下通常已经换算过你只需要告诉 Claude Code “设计稿以 dp 为单位直接使用数值”就能避免这类问题。5.2 ConstraintLayout 的约束链写得太紧或太松Claude Code 生成的约束布局偶尔会出现“控件贴边”或“位置漂移”的现象。主要原因在于约束链chain的头部控件设置不对或者某个layout_constraintWidth_percent用得不当。比如它可能给标题文字加了layout_constraintHorizontal_bias0.5但整个链的宽度并没有设置为 0dp结果标题看起来是偏的但又说不清哪里偏。遇到这种问题最快的排查方式是直接把有问题的控件的约束一行一行删掉重写只保留必要的约束。别在原有的代码上打补丁越补越乱。Claude Code 的强大之处在于你告诉它“重新这个区域只使用 start/end 约束”它就能给你一个干净的版本。5.3 资源命名风格不一致如果你在提示里没有明确规定命名规则Claude Code 生成的 id 有时会带textView2、button3这种数字后缀。短期看没有影响但在代码里引用这些 id 的时候非常痛苦且代码评审的时候一定会被要求改掉。所以我的模板里明确写了“id 使用 camelCase语义化且与截图中的图层语义对应”。如果已经生成了不规范的 id不要手动一个个改让 Claude Code 统一批量重命名并同步更新引用点。这个操作它做起来比人快得多。5.4 复杂页面的上下文超载有一次我把一个包含底部弹窗、话题标签区、多状态切换的复杂页面丢给 Claude Code 生成结果它生成的布局代码有 600 多行而且中途出现重复 id 和标签未闭合的问题。后来我把页面拆成“主界面”和“底部弹窗”两个任务分别生成问题立刻减少。经验是单次任务控制的控件数量最好在 30 个以内布局层级不超过 5 层超过就拆。5.5 Claude Code 生成的不一定符合团队规范最后要提醒的是AI 生成的代码是“合理代码”不一定是你们团队的规范代码。比如你的团队要求所有间距引用dimen资源而 AI 默认会用字面量 16dp或者你团队要求 TextView 都指定android:maxLinesAI 可能没写。所以每次生成完走一遍“团队规范自查”很有必要。最好能在提示词里把规范写清楚让 AI 在生成阶段就对齐。6. 我在实际使用中一直在坚持的几个习惯这套工作流的收益不是一天显现的而是随着上下文资料不断沉淀、模板不断打磨慢慢变得越来越顺手。下面这几条是我坚持下来最有价值的习惯分享给大家参考。第一条是MasterGo 设计稿本身也要做“面向 AI 的重构”。不是说 为了 AI 改设计而是要在设计阶段就同步考虑“这套布局未来是什么结构”把分层、命名、间距规则做规整。这样设计稿不只是给人看的也能直接被 AI 翻译成高质量的代码。等于一次设计两处受益。第二条是坚持用截图和文字描述双通道给 Claude Code 输入信息。仅靠截图时它容易陷在具体像素里仅靠文字时它容易跟不上视觉细节。双通道同时给生成的准确性最稳定。就算某一次文字描述没写全截图也能兜底。第三条是对 Claude Code 生成的内容保持“工程化审查态度”。它生成代码的速度快但不代表它理解业务。比如某些控件是“点击后跳转”还是“点击后展示弹窗”在视觉上可能一样但代码上是否需要 onClick 语义只有你自己知道。 AI 是加速器不能替代你对最终质量的责任。建议你下次接到一个新页面时就用这套流程完整跑一遍。先花半小时把 MasterGo 里的图层整理清楚再给 Claude Code 配上几行关键规则最后耐心修一轮约束。跑完一两次之后你就会明显感觉到“从设计稿到布局代码”这条链路真的可以不再是一个负担。