接了设计稿转 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 环境与账号准备

在正式开始之前，需要把这些东西准备齐：

这里最关键的一点是：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.gradle

docs/page-spec/下每个页面放一份导出的设计规格，Claude Code 可以按需读取，不用把整个设计文件都塞进上下文里。

3. 从设计稿到 Android 布局的核心流程

3.1 第一步：把设计稿转成可喂给 AI 的材料

在 MasterGo 里，选中整个页面 Frame，通常能找到复制信息或导出数据的能力。我会导出三样东西：

1. 整页截图，按 1x 导出，避免超大图把上下文塞满。
2. 页面结构数据，包含 Frame 内各节点的名称、类型、位置、宽高、填充色、字体、字号、字重、间距。
3. 需要切出的图片资源，比如图标、插画、照片，统一导出 2x 和 3x，或矢量 SVG。

这里有个细节：截图不可省。AI 只靠结构化数据对空间感受不够直观，把截图放在旁边，Claude Code 可以在写布局时同步对比视觉结构，效果比纯文本规格好不少。我一般会把截图路径告诉它，例如“设计稿截图在 docs/page-spec/login-page.png，对应的规格在 docs/page-spec/login-page.md”。

结构化的规格大致长这样：

# 登录页设计规格 基准画板：375 x 812 逻辑像素 - 顶部 Logo 区：y=88，x=137.5，w=100，h=100 - 标题「欢迎回来」：x=24，y=220，字号 28，字重 Bold，颜色 #1A1A1A - 说明文字：x=24，y=260，字号 15，字重 Regular，颜色 #666666 - 输入框 1（手机号）：x=24，y=320，w=327，h=52，圆角 12 - 输入框 2（验证码）：x=24，y=388，w=327，h=52，圆角 12 - 登录按钮：x=24，y=472，w=327，h=52，圆角 26，填充色 #4F6CFF - 协议文案：x=24，y=548，字号 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 version="1.0" encoding="utf-8"?> <androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" android:layout_width="match_parent" android:layout_height="match_parent"> <ImageView android:id="@+id/logoImage" android:layout_width="100dp" android:layout_height="100dp" android:src="@drawable/ic_logo" app:layout_constraintTop_toTopOf="parent" app:layout_constraintStart_toStartOf="parent" app:layout_constraintEnd_toEndOf="parent" android:contentDescription="@string/app_logo_desc" /> <TextView android:id="@+id/titleText" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="@string/welcome_back" android:textSize="28sp" android:textStyle="bold" android:textColor="@color/text_primary" app:layout_constraintTop_toBottomOf="@id/logoImage" app:layout_constraintStart_toStartOf="parent" android:layout_marginStart="24dp" android:layout_marginTop="32dp" /> ... </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，目标宽度 360：

327 × 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：

导出时按这个密度表存放，之后让 Claude Code 在 layout 里引用公共资源名，不要引用带密度后缀的路径。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

整理一下实践过程中陆续遇到的问题，可以直接按问题排查：

这些坑大多不是 AI 的锅，而是提示词里没有把工程约束讲清楚。把约束写清楚，踩坑率能直接下降七成。

5.2 让生成结果更稳的几个习惯

• 小步快跑，不要一次生成整个页面。逐模块来：先头部，再内容区，再底部操作栏。每个模块确认视觉效果后再拼装。一次生成整页，一旦结构不满意，改起来比手写还慢。
• 把设计规格拆成文件而不是全部贴进对话。长对话上下文会被稀释，尤其当设计规格特别长时，AI 容易出现前后矛盾。给文件路径比复制粘贴几万字符靠谱得多。
• 用版本管理兜底。每次生成都提交一次改动，如果这版不满意，直接还原，再换一版提示词重来。这是我对抗“生成结果不可控”的最后防线。
• 让 Claude Code 参与验收。生成后让它跑一下测试编译，必要时让它检查 lint 输出和资源引用是否完整。一个编译通过但 lint 一堆警告的布局，长期来看是技术债。
• 不要盲信，关键交互必须自己过一遍。点击区域够不够大、无障碍标签有没有、键盘弹起后的滚动效果，这些 UI 体验细节，AI 无法从静态设计稿推出来。这些地方我从来不会全权交给它。

我现在基本形成了一套固定流程：MasterGo 里把设计稿命名和变量收拾干净，导出页面规格和截图，Claude Code 在工程目录里读完规格先出结构树，我确认后才开始生成资源文件，最后编译预览再迭代。用这套方法，常规页面从拿到设计稿到能跑起来的首版，平均基本能控制在二十分钟左右。

最后分享一个我一直在用的小习惯：每次把 Claude Code 生成的代码提交前，我都会对着设计稿在真机上过一遍，尤其是深色模式和不同字号下的表现。这个环节别省，因为静态设计稿不会告诉你系统字体放大 1.5 倍之后布局会不会崩，也不会告诉你无障碍焦点顺序是否合理。AI 能帮我们省掉量尺寸、写样板代码的时间，但在体验问题上，人的判断永远是兜底的那道线。