接了设计稿转 Android 布局这件事过去我都当成体力活打开图拉标注量间距再手写一层层 XML。直到后来我把 MasterGo 和 Claude Code 放进同一条流水线整个流程才从一整个下午压缩到二十分钟左右。这篇文章不是纸上谈兵是我在几个实际页面里跑通的完整做法从设计稿整理、规格导出、提示词设计到生成的代码放进 Android 工程里真正跑起来全程的经验都写在下面。适合正在做客户端开发、被设计稿反复折磨的开发者也适合想给团队提效的前端和设计同学参考。1. 为什么要把 MasterGo 和 Claude Code 绑在一起干活1.1 传统设计交付流程有多折腾做安卓开发的兄弟都有体会接到设计稿之后至少得过这几关全手工测量。要量出某个卡片离屏幕左右边缘的距离、两个按钮之间的间距、文字和图片之间的留白单是这一步就很容易漏掉或者在像素级对齐上反复来回。切图依赖手动。要用到图标或背景得先选中图层再点导出。如果设计文件图层命名混乱找图标本身就要花不少时间。手写 XML 时的“翻译”。设计稿是视觉语言XML 是结构语言。同一个“居中图片加下方按钮”的区域落在 LinearLayout 里是一套写法落在 ConstraintLayout 里又是另一套每个人翻译习惯不一样同一个稿子几个开发写出来风格迥异。多轮对齐。这边改改那边调调像素级对齐全得靠肉眼。工作里最常听到的一句话就是跟设计稿差 2px再改一下。这套流程非常成熟但效率是真的不高。这不是某个人的问题而是设计工具和代码之间天然有隔阂设计文件里的尺寸、颜色、位置信息都锁在视觉层里传到写代码的人手里时已经是一张张切图和截图信息大量丢失只能靠人脑去补。1.2 这套组合拳到底解决了什么MasterGo 本身的设计能力不用多说它的标注、切图、复制节点信息的能力对我来说尤其重要。只要设计稿的命名规范一点我可以直接在 MasterGo 里拿到元素的位置、尺寸、颜色、字体、间距把它们复制成一段结构化文本或 JSON 数据。Claude Code 的强项在于理解上下文并生成具体代码。把上面的规格数据和设计截图喂给它它能在工程目录里直接生成 layout XML、colors.xml、dimens.xml甚至主动考虑深色模式、屏幕适配之类的问题。这套组合解决的痛点很明确测量和换算交给 AI我只需要给出约束条件比如基准设计宽度、目标设备屏幕逻辑宽度。切图不再重复劳动大部分常规图标可以用矢量 drawable 或样式化生成真正需要位图的地方才手动导出。代码风格通过提示词固定团队约定写进去输出稳定性高。迭代改稿很快设计稿某一块动了把最新的规格拉出去让 Claude Code 更新对应片段不用整个页面重写。本质上等于把“设计到代码”之间缺失的翻译环节交给一个既懂设计度量、又懂 Android 工程结构的助手来干而我来做验收、调优和兜底。2. 动手前的准备工作2.1 环境与账号准备在正式开始之前需要把这些东西准备齐工具用途MasterGo 账号打开设计稿、查看标注、导出切图需要有查看或编辑权限Claude Code在项目目录里以命令行方式运行读取上下文并生成或修改代码Android Studio 或本地 Gradle 工程生成代码之后需要跑起来看效果能联网的电脑Claude Code 需要调用远端模型处理任务这里最关键的一点是Claude Code 最好直接在 Android 工程目录里启动。这样它生成的 XML 可以直接写入 res/layout 等位置还能顺带运行构建命令来自查编译错误。直接在这个环境里干活比我复制粘贴到 IDE 再切来切去强得多。如果只是在别的目录里做试验当然也行但生成出来的文件总要手动拷进工程次数一多很容易漏掉资源文件。我现在的习惯是先 cd 到 Android 工程根目录再启动 Claude Code所有对话都以工程为工作目录展开。2.2 让设计稿准备好被“读”这一步常被跳过但它直接决定后面的输出质量。在 MasterGo 里先把这些事做掉给关键图层起名。名字尽量语义化比如login_button_bg、avatar_image。命名会在导出数据和后续提示词里反复出现名字越清晰Claude Code 就越容易理解哪个元素对应哪个功能。建立成组和层级。把同一模块的元素放进同一个 Frame 或 Group例如“顶部导航”、“订单卡片”、“底部操作栏”。这样导出的节点信息自带层级AI 才能准确还原布局嵌套。规范颜色和字体样式。在 MasterGo 里建好颜色变量和文本样式比如把主题色定义为Primary正文样式定义为Body-L。这些变量在后面可以告诉 Claude Code“所有 Primary 颜色对应 colors.xml 中的 brand_primary”。等于提前建立设计到代码的映射关系。检查状态页面。如果页面有空状态、错误状态、按压状态设计稿里最好都有对应的 Frame。AI 生成布局时我可以补上状态切换的约束提示。大多数情况下同一个 XML 里放多状态视图不方便更好的方式是根据可见性来处理这个取决于团队的技术方案。做完这些听起来工作量不小实际操作起来也就十几分钟但换来的收益非常大——之后导出的数据会非常干净AI 的正确率能上一个台阶。2.3 Claude Code 接入准备Claude Code 的使用方式很直接命令行启动后在项目目录下运行它会读取当前项目的文件结构并支持以对话方式下达任务。有两个小技巧分享先初始化项目上下文。刚进工程时可以先让 Claude Code 阅读build.gradle、AndroidManifest.xml、现有res/values下的文件。这样它了解 minSdk、compileSdk、依赖情况比如项目用的是 Material Components 还是纯原生 View 体系这些直接影响生成的 XML 兼容性。准备一个docs/design-mapping.md。把 MasterGo 的规格摘要和本地资源命名映射放在固定文件里让 Claude Code 每次生成前自动读它。比如px 转 dp 的比例、哪些颜色对应哪些资源名、常用间距是 8/16/24。这些信息比在提示词里重复写要稳定得多。我这里实际用的目录结构是这样android-app/ ├── app/ │ ├── src/main/ │ │ ├── java/… │ │ └── res/ │ │ ├── layout/ │ │ ├── values/ │ │ └── drawable/ │ └── build.gradle ├── docs/ │ ├── design-mapping.md │ └── page-spec/ │ └── login-page.md └── build.gradledocs/page-spec/下每个页面放一份导出的设计规格Claude Code 可以按需读取不用把整个设计文件都塞进上下文里。3. 从设计稿到 Android 布局的核心流程3.1 第一步把设计稿转成可喂给 AI 的材料在 MasterGo 里选中整个页面 Frame通常能找到复制信息或导出数据的能力。我会导出三样东西整页截图按 1x 导出避免超大图把上下文塞满。页面结构数据包含 Frame 内各节点的名称、类型、位置、宽高、填充色、字体、字号、字重、间距。需要切出的图片资源比如图标、插画、照片统一导出 2x 和 3x或矢量 SVG。这里有个细节截图不可省。AI 只靠结构化数据对空间感受不够直观把截图放在旁边Claude Code 可以在写布局时同步对比视觉结构效果比纯文本规格好不少。我一般会把截图路径告诉它例如“设计稿截图在 docs/page-spec/login-page.png对应的规格在 docs/page-spec/login-page.md”。结构化的规格大致长这样# 登录页设计规格 基准画板375 x 812 逻辑像素 - 顶部 Logo 区y88x137.5w100h100 - 标题「欢迎回来」x24y220字号 28字重 Bold颜色 #1A1A1A - 说明文字x24y260字号 15字重 Regular颜色 #666666 - 输入框 1手机号x24y320w327h52圆角 12 - 输入框 2验证码x24y388w327h52圆角 12 - 登录按钮x24y472w327h52圆角 26填充色 #4F6CFF - 协议文案x24y548字号 12颜色 #999999含链接「用户协议」注意一定要标注基准画板宽度因为 AI 需要用它来换算 dp 与屏幕宽度的关系。3.2 第二步先出结构树再写 XML不要急着让 Claude Code 直接生成完整 XML那样生成的布局往往结构混乱。比如明明该用水平 LinearLayout 的地方结果塞了一堆 Constraint 约束。我的做法是先让它输出视图结构树请阅读 docs/page-spec/login-page.md 和截图先不要写完整 XML。 输出这个页面的视图层级树要求 1. 标注每个节点的布局容器建议ConstraintLayout/LinearLayout/FrameLayout 2. 标注关键间距和约束关系 3. 说明哪些部分需要抽取为 include 或 ViewStub例如它可能会输出LoginActivity └── ConstraintLayout (根布局, match_parent) ├── ImageView (Logo, 100x100dp, 居中, 距顶 88dp) ├── TextView (标题「欢迎回来」, 28sp, Bold, 左边距 24dp, 顶部约束于 Logo 下方 32dp) ├── TextView (说明文字, 15sp, Regular, 左边距 24dp, 顶部约束于标题下方 12dp) ├── TextInputLayout (手机号输入框, 高度 52dp, 左右边距 24dp, 顶部约束于说明文字下方 32dp) ├── TextInputLayout (验证码输入框, 高度 52dp, 左右边距 24dp, 顶部约束于手机号输入框下方 16dp) ├── Button (登录按钮, 高度 52dp, 左右边距 24dp, 顶部约束于验证码下方 32dp, 圆角 26dp) └── TextView (协议文案, 12sp, 居中, 底部约束于根布局底部 24dp)为什么要多这一步因为我可以在这里快速检查布局方案容器选择对不对是否会有过度嵌套适配方式有没有写死。检查通过之后才进入代码生成这能省下“生成完 XML 再回头改结构”的大量成本。判断容器时我长期用的经验是页面级骨架用 ConstraintLayout灵活表达相对位置和比例约束。结构简单、条目重复的模块用 LinearLayout例如一行里 icon 加 label。覆盖显示用 FrameLayout例如底部弹层、加载浮层。可滚动列表优先 RecyclerView不要手写 ScrollView 套复杂布局性能债后面一定还。3.3 第三步用大模型生成 XML 和资源文件结构树确认后让 Claude Code 按这个结构生成完整代码。我会给它指定输出格式和约束按上面的结构树生成 Android 布局 XML要求 1. 使用 ConstraintLayout 作为根布局使用 MaterialComponents 主题 2. TextView 文字尺寸用 sp间距和尺寸用 dp颜色一律引用 colors.xml 资源 3. 圆角背景用 drawable 资源不要使用 shape 内联属性硬写到 View 上 4. 输入框使用 TextInputLayout TextInputEditText 5. 按钮使用 Button背景引用 drawable/bg_button_primary 6. 同时生成对应的 colors.xml、dimens.xml、styles.xml 增量内容它生成的 XML 大致类似?xml version1.0 encodingutf-8? androidx.constraintlayout.widget.ConstraintLayout xmlns:androidhttp://schemas.android.com/apk/res/android xmlns:apphttp://schemas.android.com/apk/res-auto android:layout_widthmatch_parent android:layout_heightmatch_parent ImageView android:idid/logoImage android:layout_width100dp android:layout_height100dp android:srcdrawable/ic_logo app:layout_constraintTop_toTopOfparent app:layout_constraintStart_toStartOfparent app:layout_constraintEnd_toEndOfparent android:contentDescriptionstring/app_logo_desc / TextView android:idid/titleText android:layout_widthwrap_content android:layout_heightwrap_content android:textstring/welcome_back android:textSize28sp android:textStylebold android:textColorcolor/text_primary app:layout_constraintTop_toBottomOfid/logoImage app:layout_constraintStart_toStartOfparent android:layout_marginStart24dp android:layout_marginTop32dp / ... /androidx.constraintlayout.widget.ConstraintLayout生成完之后我不会直接交付而是让 Claude Code 再自查几轮。这个自审环节非常重要因为 AI 生成代码时容易忽略适配和资源引用问题。让它自己找出代码里可能引发编译失败的 ID 引用和未定义的资源往往比人逐行看更全面。3.4 完整提示词参考我总结了一个能复用的提示词清单按先后顺序塞给 Claude Code第一段设定角色和背景你是资深 Android UI 工程师。我们维护一个原生 Android 工程minSdk 24使用 Material Components 和 ConstraintLayout。本次任务是把设计稿翻译成生产可用的 layout 和资源文件。设计规格文件在 docs/page-spec/login-page.md截图在同目录 login-page.png。第二段拆解任务先阅读设计规格和截图输出视图结构树不要直接生成代码。结构树里说明每个节点的容器建议和关键约束。第三段确认后生成结构树我确认了按它生成 XML。输出到 app/src/main/res/layout/activity_login.xml 和 app/src/main/res/values/design_tokens.xml。名称严格使用英文小写下划线。所有颜色、尺寸、圆角都必须引用资源不允许硬编码。第四段自检与适配用工程上下文检查刚才生成的代码ID 引用是否完整、布局是否存在不必要嵌套、是否适配了宽屏或平板、是否考虑了 RTL。发现问题时直接修改并说明改动原因。这样四段式的对话比一句话“帮我生成登录页”稳定太多。注意看提示词里的几个关键点限定工程上下文、先结构后代码、资源引用约束、自检指令。4. 实际操作中我踩过的坑这部分才是真正的日常。流程理论上很顺但实操中踩过的坑一只手数不过来下面按频率排几个。4.1 尺寸与间距px 和 dp 的千年误会MasterGo 导出默认常用的是逻辑像素设计画板一般以 375 或 390 宽度来画这其实和 Android 里的 dp 很接近但不完全一样。如果画板宽 375目标手机的 dp 宽度通常是 360 左右直接把 24px 翻译成 24dp整体看起来会偏大。我的处理方式在提示词里明确要求“以基准画板宽度 375、目标设备逻辑宽度 360 换算关键尺寸按比例取整”。换算公式本质上是目标dp 设计px × (目标设备逻辑宽度 ÷ 设计画板宽度)例如画板里一个按钮宽度 327px画板 375目标宽度 360327 × 360 ÷ 375 313.92 ≈ 314dp虽然单个数值差得不多但积累到多个控件之后整体观感会明显偏大或偏小。也可以更省事统一让 Claude Code 先做比例换算再决定是保留整数还是用带小数的 dimens。我的习惯是能取整则取整实在取不到整数就保留一位小数。4.2 布局层级AI 太热情嵌套烧性能一个常见翻车点是 Claude Code 生成的布局结构过深。比如简单的设置页它可以给你套三层 LinearLayout 加两层 ConstraintLayout。原因是规格 JSON 里节点层级本来就很深把设计稿里的 Group 原封不动映射到 ViewGroup就会产生不必要的层级。我在结构树确认时会加一句话请在不改变视觉效果的前提下把层级尽量压平能用一层 ConstraintLayout 表达的不要用两层 LinearLayout 包裹。另外可以要求 Claude Code 使用 lint 检查布局层级。生成的 XML 里如果不小心出现三层以上非必要嵌套直接让它重写。经验法则超过五层的 ViewGroup 嵌套就很有可能有性能隐患。虽然大多数页面不至于卡顿但 RecyclerView 的 item 里如果有这种层级滑动时掉帧是必然的。4.3 颜色、字体与组件规范让 Token 从设计一直流到代码设计稿里有几个按钮可能一个用主题色一个用灰色一个用描边样式。如果导出的数据里只是色值而没有语义标记Claude Code 生成时就会把#4F6CFF直接命名为button_blue这种名字没有解释力后续维护很痛苦。我建议提前在 MasterGo 里把颜色变量和文本样式名称定义好并在docs/design-mapping.md写明映射规则- Primary/500 - color/brand_primary - Neutral/100 - color/bg_neutral_100 - Text Primary - color/text_primary - BodyL - textAppearanceBodyLarge - Headline - textAppearanceHeadlineMedium这样生成代码时资源名是带语义的。以后设计师调整主题色我只需要改一行 colors.xml整个应用的颜色跟着变。这个习惯越早养成越好越到多页面、多主题的时候越省力。4.4 图片资源矢量导出与多密度适配设计稿里若有小图标我尽量让 Claude Code 生成 VectorDrawable XML而不是导出 PNG。向量图标体积小、适配好而且可以直接写进 drawable 目录。但要注意MasterGo 导出的 SVG 并不总能无缝变成 Android 的 VectorDrawable渐变、复杂路径、描边可能造成兼容问题。如果图标复杂度不高我可以直接把 SVG 路径贴给 Claude Code让它转成 VectorDrawable。这里有一个小技巧SVG 里的 viewBox 和 Android 里 vector 的 viewportWidth/Height 要对齐否则会缩放错位。如果发现路径怪异多半是这两个值对不上。位图类资源比如插画、照片没有捷径只能导出多密度的 PNG 或 WebP密度档位缩放比例目录MDPI1xdrawable-mdpiHDPI1.5xdrawable-hdpiXHDPI2xdrawable-xhdpiXXHDPI3xdrawable-xxhdpiXXXHDPI4xdrawable-xxxhdpi导出时按这个密度表存放之后让 Claude Code 在 layout 里引用公共资源名不要引用带密度后缀的路径。5. 常见问题与排查技巧实录5.1 高频问题速查表整理一下实践过程中陆续遇到的问题可以直接按问题排查现象可能原因解决办法生成的布局整体偏大或偏小画板宽度与目标逻辑宽度不一致px 没按比例换算成 dp提示词中明确画板宽、目标宽和换算规则把关键间距交给 dimens.xml 集中调整编译报 ID 找不到生成布局时引用了没有同时生成的控件让 Claude Code 自检运行构建命令报错信息直接丢给它图片显示拉伸变形没设置 scaleType 或使用了不适配的尺寸按内容特性指定 centerCrop 或 fitCenter并检查宽高是否硬编码圆角背景不生效把圆角写进了 View 的属性而不是背景资源让 Claude Code 生成独立的 drawable 文件引用或在 MaterialCardView 中使用 cardCornerRadius深色模式下看不清只写了亮色背景没有做 values-night 适配在提示词中加入“需要 values-night 目录的资源”字体样式不统一直接写 textSize 和 textStyle没有引用主题样式要求使用 Material 的 textAppearance 或项目自有样式统一RTL 布局错位提示词没考虑 RTL要求使用 Start/End 而不是 Left/Right并检查 autoMirrored 属性生成的代码风格和团队不一致没有在提示词里写编码规范把团队的编码规范摘要放进 docs/design-mapping.md每次生成前让 Claude Code 遵守这些坑大多不是 AI 的锅而是提示词里没有把工程约束讲清楚。把约束写清楚踩坑率能直接下降七成。5.2 让生成结果更稳的几个习惯小步快跑不要一次生成整个页面。逐模块来先头部再内容区再底部操作栏。每个模块确认视觉效果后再拼装。一次生成整页一旦结构不满意改起来比手写还慢。把设计规格拆成文件而不是全部贴进对话。长对话上下文会被稀释尤其当设计规格特别长时AI 容易出现前后矛盾。给文件路径比复制粘贴几万字符靠谱得多。用版本管理兜底。每次生成都提交一次改动如果这版不满意直接还原再换一版提示词重来。这是我对抗“生成结果不可控”的最后防线。让 Claude Code 参与验收。生成后让它跑一下测试编译必要时让它检查 lint 输出和资源引用是否完整。一个编译通过但 lint 一堆警告的布局长期来看是技术债。不要盲信关键交互必须自己过一遍。点击区域够不够大、无障碍标签有没有、键盘弹起后的滚动效果这些 UI 体验细节AI 无法从静态设计稿推出来。这些地方我从来不会全权交给它。我现在基本形成了一套固定流程MasterGo 里把设计稿命名和变量收拾干净导出页面规格和截图Claude Code 在工程目录里读完规格先出结构树我确认后才开始生成资源文件最后编译预览再迭代。用这套方法常规页面从拿到设计稿到能跑起来的首版平均基本能控制在二十分钟左右。最后分享一个我一直在用的小习惯每次把 Claude Code 生成的代码提交前我都会对着设计稿在真机上过一遍尤其是深色模式和不同字号下的表现。这个环节别省因为静态设计稿不会告诉你系统字体放大 1.5 倍之后布局会不会崩也不会告诉你无障碍焦点顺序是否合理。AI 能帮我们省掉量尺寸、写样板代码的时间但在体验问题上人的判断永远是兜底的那道线。