1. 这套组合到底在解决什么问题Android 布局开发这件事做了几年的人都有一个共同感受写 XML 不难难的是反复调。一个列表项设计稿上看着简单真写起来要处理约束关系、适配不同屏幕、处理长文本截断、处理点击态和按压态一套下来少说半小时。如果页面多、改版频繁这种重复劳动会吃掉大量时间。我最近在几个中小型项目里试了一条新路子用MasterGo做设计稿的整理和标注提取再把结构化的描述喂给Claude Code让它直接产出可用的 Android 布局代码。整套流程跑下来一个中等复杂度的页面从设计稿到能跑的布局时间大概能压到原来的三分之一左右。这篇就把我踩过的坑、验证过的做法完整写出来。先说清楚这套方案适合谁。如果你是自己接活或者小团队开发设计资源有限经常要自己对着设计稿写布局那这套流程收益很明显。如果你在大团队里设计规范已经沉淀成组件库那这套更多是作为补充手段用来处理那些非标准页面。不适合的场景也要说在前面高度依赖自定义 View、复杂动画、或者设计稿本身混乱无规范的硬套这套流程反而更慢。核心逻辑其实就一句话把设计意图翻译成结构化的自然语言描述再让模型把描述翻译成代码。中间这一步是关键很多人直接丢一张截图给模型出来的代码质量参差不齐问题就出在缺少结构化描述这一环。MasterGo 在这里的价值是它能提供相对规整的图层结构、间距数值、颜色值这些是模型能稳定利用的输入。2. 整体流程设计与工具选型考量2.1 为什么是这两个工具的组合先解释一下工具选型的逻辑不然后面操作起来会不知道为什么这么设计。MasterGo 这类设计工具的核心优势在于图层语义化。一个做得规范的设计稿图层命名是title、subtitle、avatar、action_button这种而不是矩形 1、编组 23。图层名本身就是语义信息模型读到avatar就知道这是个头像位读到action_button就知道这是个操作按钮。这一点比纯截图识别强太多截图识别只能靠视觉推断容易把图标认成图片、把按钮认成文本。Claude Code 的优势在于长上下文和代码理解能力。Android 布局代码有它自己的约束体系ConstraintLayout 的约束链、LinearLayout 的权重分配、margin 和 padding 的区别这些模型如果理解不到位生成的代码就是能编译但布局错乱。Claude Code 在这方面的表现相对稳定尤其是给它足够的上下文示例之后。两者结合MasterGo 负责把设计说清楚Claude Code 负责把话说成代码。中间需要一个转换环节就是设计描述的结构化整理这一步目前还得人工参与但工作量不大。2.2 完整流程的四个阶段整个流程我拆成四个阶段每个阶段都有明确的输入输出阶段输入输出主要工作设计整理原始设计稿规范化的设计稿图层重命名、组件化、标注补全描述提取规范化设计稿结构化文本描述按层级写出布局意图代码生成结构化描述布局代码模型生成 人工校验联调修正布局代码可运行页面真机预览、微调这四个阶段里第一阶段最容易被忽略但它决定了后面所有环节的质量。我见过太多人跳过整理直接提取结果模型拿到一堆Frame 12、Group 8的图层名生成的代码里变量名全是view1、view2后期维护成本极高。2.3 方案的优势与边界这套方案最大的优势是可复现。一旦你把描述模板固定下来同样的描述结构可以套用到不同页面模型输出的代码风格也会趋于一致。这对小团队来说很重要相当于用一套描述规范替代了代码规范的一部分职能。边界也要说清楚。第一它处理不了设计稿本身的问题如果设计稿间距混乱、颜色不统一生成的代码也会带着这些问题。第二它对交互逻辑无能为力点击跳转、数据绑定这些还是得自己写。第三复杂自定义绘制、贝塞尔曲线、粒子效果这类模型生成的代码基本不能用还是得手写。提示这套流程的定位是加速标准布局的产出不是替代布局开发。把它用在列表项、详情页、表单页这类结构规整的页面上收益最大。3. 设计稿整理与描述提取的实操细节3.1 图层规范化决定成败的第一步打开设计稿第一件事不是急着提取而是过一遍图层树。我通常按这个顺序处理把自动布局Auto Layout用起来让间距和排列关系显式化重命名关键图层用英文小写加下划线比如user_avatar、item_title把重复出现的结构做成组件比如列表项、标签、按钮检查颜色和字号是否用了样式Style而不是散落的硬编码值为什么强调自动布局因为自动布局会把间距 16、垂直排列、左对齐这些信息变成结构化的属性提取的时候直接读就行。没有自动布局的话你得靠肉眼量间距误差大还费时间。图层命名这块我的习惯是只给需要生成代码的图层命名装饰性的分割线、背景色块可以保持默认。命名太多反而干扰模型判断它会纠结哪些该生成、哪些该忽略。3.2 结构化描述的写法模板描述提取是整套流程的核心。我摸索出来的模板大概长这样按层级组织页面用户详情页 根容器垂直 LinearLayout背景色 #FFFFFF 区块1顶部信息栏 容器水平 LinearLayout高度 72dp内边距 左右16dp 子元素1头像 ImageView尺寸 48x48dp圆角 24dp 子元素2文本组垂直 LinearLayout左边距 12dp权重 1 子元素2.1用户名 TextView字号 16sp颜色 #1A1A1A最大行数 1 子元素2.2签名 TextView字号 13sp颜色 #888888最大行数 1超出省略 子元素3操作按钮 ImageView尺寸 24x24dp 区块2内容列表 容器RecyclerView顶部边距 16dp ...这个模板的关键在于每个元素都写清楚类型、尺寸、间距、颜色、文本约束。模型拿到这样的描述基本不需要猜直接映射成代码就行。有几个细节值得单独说。权重weight要明确写出来因为这是 LinearLayout 里最容易出错的地方模型不知道哪个元素该撑开就会平均分配。最大行数和省略方式也要写Android 里maxLines和ellipsize是分开设置的不写清楚模型可能只设一个。圆角要写清楚是四角统一还是单独设置cardCornerRadius和background加 shape 是两种不同实现。3.3 描述提取的常见误区我踩过的坑里有三个特别典型。第一个是描述太笼统。写一个卡片里面有标题和内容模型只能瞎猜尺寸和间距。正确做法是每个数值都写出来宁可啰嗦也不要模糊。第二个是混入交互描述。写点击这个按钮跳转到设置页模型会试图生成点击监听代码但布局文件里不该有这些。布局描述只写视觉结构交互逻辑单独处理。第三个是层级关系不清。用缩进表示层级是对的但缩进要一致而且每个层级要标明容器类型。我见过有人用空格缩进但没写容器模型只能默认用 FrameLayout结果布局全叠在一起。注意描述里出现的所有数值单位要统一。Android 里尺寸用 dp、字号用 sp混用会导致不同密度屏幕上显示异常。描述阶段就写清楚单位模型生成时不容易出错。4. 代码生成环节的提示词设计与参数控制4.1 提示词的基本结构给 Claude Code 的提示词我固定成三段式角色设定 输入描述 输出要求。角色设定部分明确告诉它你是一个 Android 布局开发熟悉 ConstraintLayout 和 Material Design 规范。这一步不是形式主义它会影响模型选择哪种布局容器。设定了之后模型更倾向于用 ConstraintLayout 而不是嵌套一堆 LinearLayout。输入描述部分直接把上一步整理好的结构化文本贴进去。如果页面复杂可以分区块贴让模型逐块生成再合并。输出要求部分要写清楚这几点使用 ConstraintLayout 作为根布局除非有特殊需求所有尺寸用 dp字号用 sp颜色值用十六进制带 alpha 通道的用八位文本统一用string/引用不硬编码图片统一用drawable/引用需要加tools:命名空间用于预览这几条写进去之后生成的代码基本可以直接用不需要大改。4.2 关键参数的传递方式有些参数模型容易搞错需要在提示词里特别强调。约束关系的写法。ConstraintLayout 里layout_constraintStart_toStartOf和layout_constraintLeft_toLeftOf在 LTR 语言下效果一样但规范上推荐用 Start/End。提示词里明确要求用 Start/End生成的代码更规范。链式约束Chain。多个元素水平排列且需要均分时要用链。提示词里可以写三个按钮水平均分使用 spread 链模型就知道该怎么写。Guideline 的使用。设计稿里如果有按比例分割的布局比如上下 3:7 分用 Guideline 比嵌套布局更高效。提示词里可以写使用水平 Guideline位置在 30% 处。Barrier 的使用。多个元素对齐到最宽的那个时用 Barrier。这个模型有时候会忘提示词里可以主动提。4.3 生成结果的校验清单代码生成出来别急着往项目里贴先过一遍这个清单检查项常见问题处理方式根布局类型默认用了 LinearLayout改成 ConstraintLayout尺寸单位混用了 px全部改 dp/sp文本硬编码直接写了中文提取到 strings.xml图片引用用了占位图替换成实际资源名约束完整性元素没有约束补全约束或加 tools 属性预览属性缺少 tools:text补上便于预览这个清单过一遍基本能过滤掉八成的问题。剩下的就是真机跑起来看效果微调间距和对齐。4.4 一个完整的生成示例拿一个简单的列表项举例。描述是这样的列表项水平 ConstraintLayout高度自适应内边距 16dp 头像 ImageView尺寸 48x48dp圆角 24dp左边约束到父容器 标题 TextView字号 16sp颜色 #1A1A1A左边距 12dp右边约束到箭头左边 副标题 TextView字号 13sp颜色 #888888在标题下方左边对齐标题 箭头 ImageView尺寸 20x20dp右边约束到父容器垂直居中生成的代码大概是这样androidx.constraintlayout.widget.ConstraintLayout xmlns:androidhttp://schemas.android.com/apk/res/android xmlns:apphttp://schemas.android.com/apk/res-auto xmlns:toolshttp://schemas.android.com/tools android:layout_widthmatch_parent android:layout_heightwrap_content android:padding16dp ImageView android:idid/avatar android:layout_width48dp android:layout_height48dp android:srcdrawable/ic_avatar_placeholder app:layout_constraintStart_toStartOfparent app:layout_constraintTop_toTopOfparent app:layout_constraintBottom_toBottomOfparent / TextView android:idid/title android:layout_width0dp android:layout_heightwrap_content android:layout_marginStart12dp android:textSize16sp android:textColor#1A1A1A android:maxLines1 android:ellipsizeend app:layout_constraintStart_toEndOfid/avatar app:layout_constraintEnd_toStartOfid/arrow app:layout_constraintTop_toTopOfid/avatar tools:text标题文本 / TextView android:idid/subtitle android:layout_width0dp android:layout_heightwrap_content android:textSize13sp android:textColor#888888 android:maxLines1 android:ellipsizeend app:layout_constraintStart_toStartOfid/title app:layout_constraintEnd_toEndOfid/title app:layout_constraintTop_toBottomOfid/title tools:text副标题文本 / ImageView android:idid/arrow android:layout_width20dp android:layout_height20dp android:srcdrawable/ic_arrow_right app:layout_constraintEnd_toEndOfparent app:layout_constraintTop_toTopOfparent app:layout_constraintBottom_toBottomOfparent / /androidx.constraintlayout.widget.ConstraintLayout这段代码基本可以直接用需要改的就是资源引用和文本内容。注意layout_width0dp配合约束实现撑开这是 ConstraintLayout 的标准写法比match_parent更灵活。5. 常见问题排查与实战避坑经验5.1 生成代码布局错乱的排查思路布局错乱是最常见的问题排查按这个顺序走第一步看约束是否完整。每个元素至少要有水平和垂直方向的约束缺一个就会跑到左上角。用 Android Studio 的布局检查器能看到哪些元素没有约束。第二步看宽高设置。0dp在 ConstraintLayout 里表示由约束决定如果约束不完整0dp会导致元素不可见。这种情况改成wrap_content先看能不能显示再补约束。第三步看嵌套层级。如果用了多层嵌套检查每层的宽高和方向。嵌套过深不仅影响性能也容易出错。能用一层 ConstraintLayout 解决的不要嵌套。第四步看 margin 和 padding。这两个容易混margin 是元素外部的间距padding 是元素内部的间距。设计稿上的间距如果是元素之间的距离用 margin如果是元素内部内容到边界的距离用 padding。5.2 模型理解偏差的修正技巧模型有时候会理解偏比如把权重 1理解成固定宽度把垂直居中理解成顶部对齐。遇到这种情况不要重新生成而是在提示词里补充反例。比如模型总是把权重写成固定宽度就在提示词里加一句权重 1 表示该元素撑满剩余空间使用layout_width0dp配合约束实现不要写固定宽度。给了明确的反例模型下次就记住了。还有一种情况是模型生成的代码风格不统一有的用 ConstraintLayout 有的用 LinearLayout。这是提示词不够明确导致的把统一使用 ConstraintLayout写进输出要求并且强调除非我明确要求否则不要用其他布局容器。5.3 真机适配的注意事项生成的代码在预览里看着没问题真机上可能出问题。几个高频的适配点长文本截断。预览里的文本是固定的真机上文本长度不定。所有可能超长的文本都要加maxLines和ellipsize否则会撑破布局。不同密度屏幕。dp 和 sp 本身能适配大部分情况但如果用了固定像素值或者图片尺寸没做多套在高密度屏幕上会模糊或过大。深色模式。颜色值如果硬编码深色模式下不会自动切换。规范做法是用颜色资源在values-night里定义深色版本。RTL 语言。如果应用要支持阿拉伯语等 RTL 语言约束要用 Start/End 而不是 Left/Right否则布局会镜像错乱。提示生成代码后至少在两种不同尺寸的设备上跑一遍一种小屏一种大屏。很多适配问题在小屏上才暴露出来。5.4 常见问题速查表问题现象可能原因解决方法元素跑到左上角缺少约束补全水平和垂直约束元素不可见宽高为 0dp 且约束不完整补约束或临时改 wrap_content间距不对margin 和 padding 混用按设计稿重新判断文本被截断缺少 maxLines 或宽度不够加 maxLines 和 ellipsize深色模式颜色不对颜色硬编码改用颜色资源布局层级过深嵌套太多用 ConstraintLayout 扁平化预览正常真机错乱文本长度或屏幕尺寸差异真机调试加适配约束5.5 我踩过的几个典型坑第一个坑是过度依赖模型生成。有次一个页面比较复杂我直接把描述丢进去让它一次生成结果代码结构混乱改起来比自己写还慢。后来改成分区块生成再合并每个区块单独生成、单独校验最后拼起来效率反而高。第二个坑是描述里的数值没写单位。有次写间距 16模型理解成了 16px生成出来在高密度屏幕上间距小得几乎看不见。后来所有数值都带单位dp 和 sp 分清楚就没再出过这个问题。第三个坑是忽略了设计稿的组件复用。设计稿里同一个卡片出现了五次我傻乎乎地生成了五份代码。后来学乖了先在 MasterGo 里把重复结构做成组件描述里写使用组件 X生成代码时用include或者自定义 View 复用代码量少了一大半。第四个坑是没处理空状态和加载状态。生成的代码只考虑了有数据的情况真机上数据为空时页面一片空白。后来在描述里主动加上空状态显示占位图、加载中显示进度条模型就会把这些分支也生成出来。6. 效率提升的进阶玩法6.1 建立自己的描述模板库跑通几个页面之后你会发现很多结构是重复的。列表项、表单行、卡片、标签栏这些都可以沉淀成描述模板。下次遇到类似结构直接套模板改数值就行不用从头写描述。我的做法是在笔记软件里建一个模板库按结构类型分类。每个模板包含结构描述、常用参数范围、对应的提示词片段。用的时候复制粘贴改一改几分钟就能出一份描述。6.2 批量生成与版本管理如果一个页面有多个相似区块可以批量生成。把多个区块的描述放在一个提示词里让模型依次生成用注释分隔。这样比一个个生成快而且风格统一。生成的代码要纳入版本管理。我的习惯是每次生成后先提交一版然后在上面改。这样如果改坏了可以回退到生成版本重新来。生成版本和最终版本分开提交方便追溯哪些是模型生成的、哪些是人工调整的。6.3 与现有项目的融合策略生成的代码要融入现有项目有几个注意点。命名规范要统一如果项目里用tv_title这种前缀命名生成代码后要批量改一下。资源引用要检查模型生成的drawable/ic_arrow_right可能项目里没有要替换成实际存在的资源。主题和样式要继承如果项目有统一的主题生成的布局要确保能正确继承。我通常的做法是生成代码后先在一个独立的测试模块里跑通确认没问题再合并到主项目。这样避免污染主项目的代码库。6.4 什么情况下该放弃这套流程不是所有页面都适合这套流程。遇到这几种情况我建议直接手写页面有大量自定义绘制比如图表、进度环、特殊形状页面交互复杂布局和逻辑高度耦合设计稿本身不规范图层混乱、间距随意页面需要极致性能优化比如长列表的复杂 item硬套流程的结果是生成代码的时间加上修正时间比手写还长。判断标准很简单如果描述这个页面的时间超过了手写代码的时间就不值得用这套流程。7. 一些实操后的个人体会跑了十几个页面之后我最大的感受是这套流程的价值不在于生成代码而在于强迫你把设计意图想清楚。写描述的过程其实就是把模糊的视觉感受转化成明确的结构定义。很多时候写着写着就发现设计稿里有些地方自己也没想明白比如两个元素到底谁对齐谁、间距到底是多少。这些问题在写代码时也会遇到但写描述时暴露得更早改起来成本更低。另一个体会是模型生成的代码质量和描述的详细程度强相关。描述里写一个按钮生成的就是一个普通按钮描述里写一个高度 44dp、圆角 22dp、背景色 #007AFF、文字白色 16sp 居中、左右内边距 24dp 的按钮生成的就是一个可以直接用的按钮。多花两分钟写详细能省十分钟改代码。最后说一个心态上的调整。刚开始用这套流程时我总想着一步到位希望模型一次生成完美代码。后来发现这不现实也不必要。把它当成一个高级的代码补全工具生成一个 80 分的初稿自己花几分钟改到 95 分这个节奏是最舒服的。追求 100 分的一次性生成反而会陷入反复调提示词的泥潭。这套流程我还在持续优化后面打算把常用的描述模板整理成一套标准再试试能不能把颜色和字号的提取也自动化。有新的进展再写出来分享。