我最近完整跑通了“MasterGo + Claude Code 生成 Android 布局”这条链路，第一步做完我就觉得，以前很多项目里最耗时的“设计稿到代码”环节，终于可以换一种方式了。以前拿到设计稿，要先量间距、取色号、抠图、写 XML、再对着标注一点点调；现在用 MasterGo 把设计信息结构化，再交给 Claude Code 生成初始布局，最后在 Android Studio 里做校验和微调，整个过程快了不少。这篇文章想把我实操过程中涉及的思路、提示词、参数换算、踩坑记录从头到尾写清楚，给正在探索这条路的 Android 开发一个可以直接参考的完整指南。
如果你是独立开发者，或者是团队里负责设计交付和客户端实现的同学，这套流程尤其适合你。它并不会完全替代开发，但能把“翻译设计稿”这层枯燥且容易出错的工作大幅压缩，让你把精力放在真正的业务逻辑和交互细节上。
1. 为什么要把设计工具和 AI 编程助手放在一起
先说结论：这套流程真正解决的问题，不是“能不能自动写代码”，而是“设计稿里那些信息如何无损地传递到代码里”。设计稿本质上是一棵图层树，里面包含容器、文本、图片、间距、颜色、圆角、阴影等结构化信息，而这些信息恰好也是布局代码需要的输入。只要把信息的传递通道打通，AI 生成代码的准确率会高很多。
1.1 传统设计稿转布局的痛点
过去从设计稿到 Android 布局，最让人头疼的还不是写控件本身，而是信息在传递过程中不断失真。设计师在设计稿里用了一个 16px 的间距，开发在实现时可能因为没看标注，直接凭感觉敲了一个 12dp；设计稿里某个按钮的颜色是浅一点的品牌色，开发在代码里可能引用了另一个相近但明显偏深的色值。这些问题在视觉走查阶段才会暴露，返工成本非常高。
另一个痛点是重复劳动。一个商品列表页面里的卡片，结构大同小异，但每换一个页面就要重新写一遍 XML。再加上 Android 布局里常用的 ConstraintLayout、GuideLine、链式约束这些概念，和设计稿里的自动布局、编组之间没有一一对应的直观关系，新人要理解起来需要时间，老人写多了又容易麻木。
还有一类场景是多人协作。设计师更新了某个组件的样式，如果命名不规范、没有变更记录，开发很难知道哪些页面受了影响。即便知道，也需要手动去每个布局文件里改。久而久之，代码里的样式和设计稿里的变量就开始脱节。
1.2 这套组合带来的工作流变化
把 MasterGo 和 Claude Code 放在一起之后，工作流变成这样：MasterGo 负责输出“结构化设计信息”，包括标注、切图、样式变量、图层层级关系；Claude Code 负责把这份信息翻译成 Android 代码。我把它理解为“AI 翻译 + 人工校对”，而不是“AI 全自动”。
传统工作模式大概是：收到设计稿 → 手动量尺寸 → 写 XML → 跑模拟器调位置 → 和设计师确认 → 再改。调整一次间距就要重新走一遍流程。现在则变成：整理设计稿 → 提取关键信息 → 编写提示词 → 生成初版布局 → 在预览里走查 → 针对有问题的地方追问修改。两步之间省掉了大量“对着标注抄数字”的时间。
这套组合也改变了生成代码的粒度。以前自动生成布局的工具我也试过，很多停留在“把设计稿里的绝对坐标翻译成 AbsoluteLayout”的层面，几乎不可用。但现在 Claude Code 能理解“这是一个商品卡片，底部有一个按钮，按钮应该右对齐”这样的语义，它生成的代码会倾向于使用 ConstraintLayout 和相对约束，这已经接近真正工程师写出来的结构了。
2. 前置准备：梳理设计稿与搭建使用环境
很多人问我的第一句话是：要不要准备什么特殊的开发板、模型配置？其实都不用。真正需要提前准备的，反而是设计稿本身。设计稿理得不干净，后面 AI 再怎么聪明也会被带偏。
2.1 设计稿该整理到什么程度
我自己的标准是：至少做到“图层能读”。MasterGo 里的每个图层都有一个名字，如果名字是“Frame 12”“Group 38”，那 AI 拿到手也不知道这个区域是干嘛用的。反之，如果叫“productCard_img_main”“productCard_tv_price”，那 AI 很容易判断出这里应该放 ImageView，那里应该是 TextView。
分组也很关键。把同一个模块下的所有元素放进一个画板或编组里，比如“productCard”组下面放图片、标题、价格、按钮。这样信息层级和布局层级天然对应，AI 在推断嵌套关系时就有了依据。我建议设计师或者开发在交付前做一遍命名检查，不需要把所有图层都改得完美，至少主容器、图片、文本、按钮这几类要有语义化命名。
另一个容易忽略的是单位。MasterGo 默认使用 px 作为设计单位，但 Android 布局需要的是 dp 和 sp。好在 MasterGo 的标注面板里可以切换显示单位，交付时最好统一成“dp/sp”查看，这样导出的信息可以直接用。如果你拿到的设计稿只有 px 标注，也不要急着手动除以屏幕密度，我建议直接让 Claude Code 根据设计稿提供的换算基准去处理，后面我会详细讲怎么在提示词里约束这一点。
2.2 Claude Code 的使用环境准备
Claude Code 需要一个能读到你项目目录的环境，所以我习惯先打开一个已有 Android 工程，确保目录结构是正常的，然后再启动工具会话。工程里最好保持相对干净的代码风格，如果项目里既有旧的 Java 代码又有新的 Kotlin 代码，AI 生成的风格容易混乱，建议新建模块或者在指定目录下工作。
在正式开始前，我会把这次要生成的页面拆成一个“独立任务”。比如只生成“商品列表里的卡片布局”，而不是一次性让它生成五个页面。任务越小，反馈越精确。针对单个组件或者单个页面生成的布局，变量少，AI 容易把约束关系处理对。
最后，准备一份设计提取产物。我通常会用两种形式：一张设计稿截图，加一个 Markdown 格式的信息清单。截图用于视觉参考，信息清单用于精确描述尺寸、间距、颜色。两份文件放到工程目录里，或者直接在提示词中描述清楚。你不需要把整个设计稿文件塞给 AI，那样信息量太大反而不利于输出。
3. 核心实操：从 MasterGo 提取设计信息到生成 Android 布局
我拿一个最常见的“商品卡片”来演示完整流程。这个卡片有四个元素：商品图片、标题、价格、加购按钮。卡片整体宽度占满屏幕，左右内边距 16dp，图片宽高比 4:3，标题和图片之间的间距 12dp，价格在标题下方 8dp，按钮在右下角。
3.1 从设计稿中获取可交付的信息
在 MasterGo 中打开这个卡片画板，右键元素或进入标注模式，逐项读取以下信息：卡片背景填充色、圆角值、阴影参数、内边距；图片尺寸、圆角；标题的字号、字重、文本颜色；价格的字号、字重、颜色；按钮的宽高、圆角、背景色和文本色。
不要只记数值，还要看看层级。MasterGo 左侧的图层列表里，order 从上到下代表了渲染顺序。比如图片在标题上面，那在布局里图片就应该放在标题上方；按钮在右下角，那它就相对父容器 End 和 Bottom 对齐。这些信息我会整理成一段描述文字，或者一个简单的 Markdown 表格。
图片资源这里有个关键选择：如果设计稿里的图标是矢量形状，导出时优先选 SVG，然后在 Android 里转成 VectorDrawable；如果是位图，导出 PNG 或 WebP，注意选择适当的分辨率。截图则放在工程目录下作为视觉参考，提醒 Claude Code “这只是一个示意，不要直接把截图作为布局背景”。
3.2 编写高还原度的生成提示词
提示词是这套流程里最值得花时间的地方。我见过不少人把设计稿截图丢给 AI，然后只说一句“生成布局代码”，结果返回的代码要么层级嵌套极深，要么颜色全部硬编码。原因不是 AI 不行，而是需求描述太模糊。
我的写法是这样：
你是资深 Android 开发工程师。请根据下面设计稿信息，在 app/src/main/res/layout 下生成 fragment_product_card.xml。 要求： 1. 根布局使用 ConstraintLayout，尽量平铺层级，减少嵌套。 2. 尺寸用 dp，字体用 sp，所有颜色、字号、间距引用 res/values 下的资源，不要硬编码。 3. 商品卡片包含图片、标题、价格、加购按钮。图片宽高比 4:3，使用 ImageView 的 scaleType="centerCrop"。 4. 标题在图片下方 12dp；价格在标题下方 8dp；按钮右下角对齐。 5. 卡片内边距 16dp，背景圆角 12dp，背景色参考 @color/brand_card_bg。 6. 生成后请检查约束是否闭环，确保每个控件都能唯一定位。需要注意，提示词要包含“约束是否闭环”这一点。AI 生成 XML 时最容易出的问题，就是某个控件只设置了 Top 和 Start 约束，但缺少 End 或 Bottom，最终在预览里跑飞。明确要求它检查后，这种情况会少很多。
另外，把设计信息清单直接贴在提示词里。比如：图片宽度 356dp、高度匹配 4:3 比例；标题字号 16sp、字重 Medium；价格字号 14sp、颜色 #FF6A00；按钮宽度 88dp、高度 36dp。信息给得越具体，生成的布局就越接近设计稿。
3.3 在工程中落地方案与资源细化
生成完布局文件后，我不会直接合入主干。第一步是打开 Android Studio 的 Layout Preview，看布局是否存在资源缺失或者约束冲突。初版布局大概率会有些小毛病，比如按钮和价格重叠，或者标题被截断，这都属于正常现象。
我习惯把 Claude Code 生成的 XML 先复制到一个临时文件，确认大体结构没问题后，再替换正式文件。这样不会污染现有代码，也比较容易对比。接着检查它引用的资源：如果颜色、字号、间距都是硬编码在 XML 里的，我会一次性把生成结果反馈给 AI，让它“将硬编码值抽取到 colors.xml、dimens.xml、strings.xml”，然后对比修改后的结果。
资源抽出来之后，再跑一遍模拟器或者真机。这一步主要是看视觉还原度和交互细节，比如按钮的可点击区域是否够大、文本在系统字体放大两档后会不会溢出。这些在静态预览里看不出来，必须实际跑一下。
4. 技术细节：布局结构、资源规范与还原技巧
从设计图层到 Android 控件，不是简单的“一对一复制”，而是要理解容器和约束的关系。设计稿里的画板对应布局根节点，编组对应中间容器，也可能只是约束集合。判断方式很简单：如果这个组有背景、内边距、圆角等视觉表现，它就该是一个嵌套容器；如果它只是一个纯分组，那 AI 生成的代码就应该把内部元素直接平铺到外层 ConstraintLayout 里，而不是多套一层。
4.1 从设计图层到 Android 控件的映射思路
常规映射关系可以参考这张表：
| 设计稿图层 | Android 控件/布局 | 备注 |
|---|---|---|
| 画板 / 顶层容器 | ConstraintLayout / LinearLayout | 优先使用 ConstraintLayout |
| 带背景与圆角的容器 | CardView 或带 background 的布局 | 阴影效果可用 elevation 代替 |
| 文本图层 | TextView | 用 textAppearance 统一样式 |
| 图片占位 | ImageView | scaleType 按需求设置 |
| 按钮 | Button / MaterialButton | 关注最小可点击高度 48dp |
| 输入框 | EditText / TextInputLayout | 关注 hint 和错误提示 |
举例来说，设计稿里有一个带阴影的圆角卡片容器，里面包含图片和文字。如果直接给这个容器加 background 并写死 dp 值，生成结果能跑，但不好维护。更好的做法是提取一个 shape 到 drawable 目录，然后让多个卡片引用同一个背景资源。这种抽象，AI 只要提示到位也能完成。
这里插一段我实际生成的 XML 片段，展示最基本的商品卡片结构：
<androidx.constraintlayout.widget.ConstraintLayout android:id="@+id/card_root" android:layout_width="match_parent" android:layout_height="wrap_content" android:background="@drawable/bg_product_card" android:padding="16dp"> <ImageView android:id="@+id/iv_product" android:layout_width="0dp" android:layout_height="0dp" android:contentDescription="@string/product_image" android:scaleType="centerCrop" android:src="@drawable/ic_placeholder" app:layout_constraintDimensionRatio="4:3" app:layout_constraintEnd_toEndOf="parent" app:layout_constraintStart_toStartOf="parent" app:layout_constraintTop_toTopOf="parent" /> <TextView android:id="@+id/tv_title" android:layout_width="0dp" android:layout_height="wrap_content" android:layout_marginTop="12dp" android:textAppearance="@style/TextAppearance.Product.Title" app:layout_constraintEnd_toEndOf="parent" app:layout_constraintStart_toStartOf="parent" app:layout_constraintTop_toBottomOf="@id/iv_product" /> <TextView android:id="@+id/tv_price" android:layout_width="wrap_content" android:layout_height="wrap_content" android:textAppearance="@style/TextAppearance.Product.Price" app:layout_constraintStart_toStartOf="parent" app:layout_constraintTop_toBottomOf="@id/tv_title" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintVerticalChainStyle="packed" /> <Button android:id="@+id/btn_add" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="@string/add_to_cart" app:layout_constraintEnd_toEndOf="parent" app:layout_constraintTop_toBottomOf="@id/tv_title" /> </androidx.constraintlayout.widget.ConstraintLayout>这段代码的问题在于，btn_add 和 tv_price 都相对 tv_title 的底部排列，实际预览里有可能重叠。遇到这种情况，我的处理方式是让价格和按钮之间建立相对约束，或者把按钮改为相对卡片底部 End 对齐，再加一个 margin。这就是为什么生成完必须检查约束闭环。
4.2 风格资源与设计变量的对接
MasterGo 的样式变量和 Android 的资源文件，本质上都在解决同一个问题：避免把值写死。设计稿里定义了一套色板、字号、间距，代码里就应该用 colors.xml、textAppearance、dimens.xml 来承载这套体系。
我的做法是先把设计稿里的样式变量同步到工程里。比如品牌主色 #FF6A00，在 colors.xml 里定义成 brand_primary；标题字号 16sp、字重 600，在 styles.xml 里定义成 TextAppearance.Product.Title。然后让 Claude Code 在生成代码时优先引用这些 token，而不是直接写十六进制色值和文字大小。
这套做法的好处在改版时特别明显。假设设计师把品牌主色从橙色改成蓝色，只需要改 colors.xml 里的一个值，所有引用这个 token 的布局自动更新。如果代码里全部是硬编码色值，那就只能全局搜索替换，改漏一个就是事故。
还有个小技巧：把设计稿里的间距做成以 4dp 为基准的递进数组，比如 spacing_4、spacing_8、spacing_12、spacing_16。Claude Code 在生成布局时会优先选用这些“取整后的标准值”，视觉上更统一，也方便后续调整。
4.3 自适应布局与多屏适配
设计稿通常是固定尺寸的画板，但 Android 设备千变万化。要让生成的布局在不同屏幕上看起来都正常，需要把“固定坐标”转化为“相对约束”。
我在提示词里通常会强调：布局宽度尽量使用 0dp 配合 ConstraintLayout 的链式约束；图片不能写死高度，要用 app:layout_constraintDimensionRatio 保持比例；按钮通过 End 和 Bottom 约束定位，想居中就用垂直链加 bias；文本使用单行省略号或者 maxLines，防止内容过长时撑破布局。
这种相对约束的思路，AI 理解起来其实很快，但前提是你在提示词里给它明确的约束规则。如果不提，它可能贪方便直接生成“width=300dp, height=200dp”这种死代码，换一台小屏手机就出问题。所以宁可多写几句要求，也不要后期在真机上一个个调适配。
5. 常见问题与排查方法
我在实际过程中遇到过不少问题，下面这些是最容易踩的坑，每一个都有具体现象和解决办法。
5.1 层级过深与约束冲突
初版生成的 XML，最常见的毛病是嵌套层级过深。明明一个 ConstraintLayout 就能解决的问题，AI 会生成好几层嵌套的 LinearLayout。根因是设计稿里存在大量分组，AI 默认把每个分组都翻译成了一个容器，于是层级爆炸。布局层级一多，性能会下降，预览时看起来也乱。
遇到这种情况，我会直接要求 AI“重构该布局，使用更扁平的层级结构，移除非必需的嵌套容器”。如果它还是处理不好，就手动把中间容器删掉，把子元素直接放到根布局并用约束定位。约束冲突的排查我一般借助 Android Studio 的 Layout Inspector，它会标出哪些约束缺失或冲突，比肉眼找快得多。
5.2 尺寸、间距和字体不对齐
这个坑大多出在单位换算上。设计稿里标注的是 px，生成的代码里写的是 dp，如果 AI 没有做换算，数值就会偏大很多。比如设计稿标注字体 24px，在 3x 屏幕上对应 8dp 左右，但 AI 可能直接把 24dp 写进去，导致文字巨大。
我在提示词里会明确写出“当前设计稿以 375x812 为基准，像素密度为 3x，请将 px 标注换算为 dp/sp”。如果 MasterGo 可以直接切到 dp 标注，那就直接在信息清单里填写 dp 值，省得让 AI 猜。字体不对齐的另一个来源是 fontFamily 不同，设计稿用的字体和 Android 默认字体不一样，这部分只能靠设计师提供可用的替代字体资源，或者接受系统字体。
5.3 图标与图片资源处理不当
设计稿里的图标，如果导出成 PNG 再作为 ImageView 的 src，放大之后必然模糊。正确的做法是：在 MasterGo 里把矢量图标导出为 SVG，然后用 Android Studio 的 Vector Asset 工具转成 VectorDrawable。Claude Code 生成不了图片资源，但它可以生成 vector drawable 的 XML 文件，只要你把 SVG 的 path data 提供给它。
图片占位资源也是一个常见坑。设计稿里的图片区域，可能只是灰色占位符，但 AI 偶尔会把占位符当成最终图片写进布局里。我会明确告诉它：“这个区域是运行时由业务数据填充的，占位符仅用于预览，请使用 @drawable/ic_placeholder。”这样最终的布局不会依赖设计稿截图。
5.4 生成的布局在真机上显示异常
静态预览一切正常，真机上却出了问题，这类情况通常和系统设置有关。系统字体缩放比例调大后，原本刚刚好的 TextView 可能换行或溢出；深色模式下，如果布局没有适配深色主题，某些背景色会变成默认深色；还有不同厂商设备的屏幕圆角、刘海、手势导航条，都可能遮挡内容。
我现在养成一个习惯：每生成一个页面的布局，都会去真机上走一遍“视觉还原验收清单”。清单包含六项：间距是否与标注一致；图片比例是否正确；文本是否出现截断；按钮点击区域是否足够大；深色模式下是否可读；小屏设备上是否出现横向滚动。这套清单也可以写进提示词里，让 Claude Code 在生成代码时主动规避这些问题。
6. 这套流程后续还可以怎么扩展
这套流程跑通之后，后面能做的事其实不少。我自己用下来，最大的变化是“从自己写代码”变成了“提需求、审代码”。顺着这个方向继续走，还可以把它做成一整套团队协作的方法论。
6.1 沉淀团队级的 Prompt 模板和设计规范
第一次用完，我就把提示词存成了模板。后续每一个新页面，只需要替换设计信息和页面名称，其他要求保持一致。这样生成出来的代码风格会更统一，团队成员接手也更轻松。
如果团队里用 MasterGo 比较规范，可以进一步把图层命名规范固化下来。比如主容器统一叫 “xxPage”，卡片统一叫 “xxCard”，图片用 “img_” 前缀，文本用 “tv_” 前缀。这不仅是给 AI 看的，也是给人类开发看的。一套规范两边受益。
6.2 反向工作流与自动化空间
我现在探索的另一个方向，是把 XML 布局反向翻译成 Compose 代码。Claude Code 能读懂 XML 和 Kotlin 代码，告诉它“把这份 XML 翻译成 Jetpack Compose 实现，保持相同的布局结构和视觉表现”，它通常能输出可用的 Composable 函数。这给老项目向 Compose 迁移提供了一条低成本的辅助路径。
更进一步，MasterGo 里的样式变量如果维护得好，甚至可以写脚本自动生成 colors.xml、dimens.xml 和 themes.xml。设计系统一旦源头统一，开发侧的资源文件就不用手动同步了。这个方向有自动化空间，但需要设计和开发之间建立一套严格的变更流程。
6.3 给团队落地的一些建议
最后给想把这个流程引入团队的朋友几个建议。
从小模块开始试验。不要一上来就让 AI 生成整个首页，先让它在商品卡片、列表项、设置页单元这类小组件上跑一遍，积累成功案例。
人工审核是底线。生成代码不能直接合入主干，至少要过一遍代码规范和视觉走查。AI 能提高效率，但代码质量的责任仍然在开发者手里。
把这份指南分享给设计师。让设计师了解图层命名和分组方式对下游开发的影响，他们同意优化命名之后，你会发现整个交付过程顺畅很多。我用下来的真实体会是，最花时间的往往不是生成，而是把坐标系、单位、资源这些基础信息统一好。基础打好了，AI 才能像一个熟悉你项目的开发一样工作。
