企业官网建设流程全解析

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 生成结果的校验清单

代码生成出来，别急着往项目里贴，先过一遍这个清单：

这个清单过一遍，基本能过滤掉八成的问题。剩下的就是真机跑起来看效果，微调间距和对齐。

4.4 一个完整的生成示例

拿一个简单的列表项举例。描述是这样的：

列表项：水平 ConstraintLayout，高度自适应，内边距 16dp 头像 ImageView，尺寸 48x48dp，圆角 24dp，左边约束到父容器 标题 TextView，字号 16sp，颜色 #1A1A1A，左边距 12dp，右边约束到箭头左边 副标题 TextView，字号 13sp，颜色 #888888，在标题下方，左边对齐标题 箭头 ImageView，尺寸 20x20dp，右边约束到父容器，垂直居中

生成的代码大概是这样：

<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="wrap_content" android:padding="16dp"> <ImageView android:id="@+id/avatar" android:layout_width="48dp" android:layout_height="48dp" android:src="@drawable/ic_avatar_placeholder" app:layout_constraintStart_toStartOf="parent" app:layout_constraintTop_toTopOf="parent" app:layout_constraintBottom_toBottomOf="parent" /> <TextView android:id="@+id/title" android:layout_width="0dp" android:layout_height="wrap_content" android:layout_marginStart="12dp" android:textSize="16sp" android:textColor="#1A1A1A" android:maxLines="1" android:ellipsize="end" app:layout_constraintStart_toEndOf="@id/avatar" app:layout_constraintEnd_toStartOf="@id/arrow" app:layout_constraintTop_toTopOf="@id/avatar" tools:text="标题文本" /> <TextView android:id="@+id/subtitle" android:layout_width="0dp" android:layout_height="wrap_content" android:textSize="13sp" android:textColor="#888888" android:maxLines="1" android:ellipsize="end" app:layout_constraintStart_toStartOf="@id/title" app:layout_constraintEnd_toEndOf="@id/title" app:layout_constraintTop_toBottomOf="@id/title" tools:text="副标题文本" /> <ImageView android:id="@+id/arrow" android:layout_width="20dp" android:layout_height="20dp" android:src="@drawable/ic_arrow_right" app:layout_constraintEnd_toEndOf="parent" app:layout_constraintTop_toTopOf="parent" app:layout_constraintBottom_toBottomOf="parent" /> </androidx.constraintlayout.widget.ConstraintLayout>

这段代码基本可以直接用，需要改的就是资源引用和文本内容。注意layout_width="0dp"配合约束实现撑开，这是 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_width="0dp"配合约束实现，不要写固定宽度"。给了明确的反例，模型下次就记住了。

还有一种情况是模型生成的代码风格不统一，有的用 ConstraintLayout 有的用 LinearLayout。这是提示词不够明确导致的，把"统一使用 ConstraintLayout"写进输出要求，并且强调"除非我明确要求，否则不要用其他布局容器"。

5.3 真机适配的注意事项

生成的代码在预览里看着没问题，真机上可能出问题。几个高频的适配点：

长文本截断。预览里的文本是固定的，真机上文本长度不定。所有可能超长的文本都要加maxLines和ellipsize，否则会撑破布局。

不同密度屏幕。dp 和 sp 本身能适配大部分情况，但如果用了固定像素值或者图片尺寸没做多套，在高密度屏幕上会模糊或过大。

深色模式。颜色值如果硬编码，深色模式下不会自动切换。规范做法是用颜色资源，在values-night里定义深色版本。

RTL 语言。如果应用要支持阿拉伯语等 RTL 语言，约束要用 Start/End 而不是 Left/Right，否则布局会镜像错乱。

提示：生成代码后，至少在两种不同尺寸的设备上跑一遍，一种小屏一种大屏。很多适配问题在小屏上才暴露出来。

5.4 常见问题速查表

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 分的一次性生成，反而会陷入反复调提示词的泥潭。

这套流程我还在持续优化，后面打算把常用的描述模板整理成一套标准，再试试能不能把颜色和字号的提取也自动化。有新的进展再写出来分享。