企业官网建设流程全解析

1. 这套组合到底在解决什么问题

Android 布局开发这件事，做过几年的人都有体会：XML 写起来不难，难的是又快又准地还原设计稿。一个中等复杂度的页面，约束布局嵌套、dp/sp 换算、不同屏幕适配、状态栏避让，一套下来小半天就没了。更别提设计稿改一版，你还得对着标注重新量一遍间距。

我最早接触 MasterGo 是在一个跨端项目里，当时团队的设计师用它做组件库，导出标注还算方便。但真正让我觉得"这事有搞头"的，是把 MasterGo 的设计数据喂给 Claude Code，让它直接吐出一份能跑的 Android 布局代码。这套流程跑通之后，一个常规列表页从设计稿到可运行布局，压缩到了十几分钟，而且改稿成本极低——设计改完重新生成一遍就行。

这篇内容适合三类人看：一是独立开发者，没人帮你写布局，想省时间；二是小团队的前端/移动端，设计资源紧张，想自己消化设计稿；三是对 AI 辅助编码感兴趣但没找到落地场景的人。我会把整套流程拆开讲，包括 MasterGo 侧怎么准备、Claude Code 侧怎么喂上下文、生成的代码怎么调、哪些坑我踩过。核心关键词就三个：MasterGo 设计数据、Claude Code 代码生成、Android 布局还原。

需要先说明一点：这套方案不是"一键生成完美代码"，它更像一个高级脚手架——帮你把 70% 的重复劳动干掉，剩下 30% 的业务逻辑和细节打磨还得自己来。抱着"全自动"预期的人会失望，但把它当成效率工具，收益非常明显。

2. 整体思路与方案选型拆解

2.1 为什么是 MasterGo 而不是其他设计工具

选 MasterGo 做这套流程的起点，核心原因是它的数据结构对机器友好。设计稿本质是一棵节点树，每个节点有位置、尺寸、样式、层级关系。MasterGo 的图层命名规范、自动布局（Auto Layout）机制、组件系统，天然适合被解析成结构化的描述。

具体来说，有几个特性直接决定了它适合喂给 AI：

• 自动布局：开了 Auto Layout 的容器，本身就携带了方向、间距、对齐方式的信息，这跟 Android 的 LinearLayout/ConstraintLayout 语义高度对应。
• 图层命名：命名规范的图层（比如btn_login、tv_title）可以直接映射成 Android 的控件 id，省去大量重命名工作。
• 组件与变体：复用组件意味着生成代码时可以抽成 style 或 include 布局，减少重复。

相比之下，如果设计稿是一堆散乱的绝对定位图层，AI 解析出来的就是一堆硬编码坐标，生成 ConstraintLayout 时约束关系会乱成一团。所以设计稿的规范程度，直接决定生成质量，这一点后面会反复强调。

2.2 Claude Code 在流程里扮演什么角色

Claude Code 不是简单的"文本转代码"，它的价值在于理解上下文并做结构化推理。你把 MasterGo 导出的节点描述丢给它，它能做几件事：

第一，识别布局模式。看到一排水平排列、间距相等的卡片，它会判断这是横向 RecyclerView 还是 LinearLayout；看到层叠的浮层，它会用 FrameLayout 或 ConstraintLayout 处理。

第二，推断约束关系。Android 布局最烦的是约束，Claude Code 能根据节点的相对位置，推断出"这个按钮在父容器底部居中""这个文本在图标右侧 8dp"这类约束。

第三，生成可读的代码。它会按 Android 命名规范给控件起 id，按 Material Design 习惯选控件类型，甚至帮你加上contentDescription这类无障碍属性。

我实测下来，Claude Code 对中等复杂度页面（列表、表单、详情页）的还原度能到 80% 以上，复杂自定义绘制（比如不规则图形、复杂动画）还是得手写。

2.3 为什么不用"设计稿直接转代码"的现成插件

市面上确实有设计工具自带的代码导出功能，但用过的都知道，导出的代码基本是绝对定位堆砌，一个页面几百行，改都没法改。原因很简单：那些工具做的是"像素级翻译"，而不是"语义级理解"。

Claude Code 的优势在于它能按 Android 的布局思维重新组织。同样一个卡片，插件给你的是layout_marginLeft="24dp"硬编码，Claude Code 给你的是app:layout_constraintStart_toStartOf="parent"加marginStart。前者换个屏幕就崩，后者能自适应。这就是"翻译"和"理解"的区别。

所以整套方案的定位是：用 MasterGo 提供结构化设计数据，用 Claude Code 做语义化代码生成，人工做最后的业务逻辑和细节校验。三方各司其职，缺一不可。

3. 核心细节解析与实操要点

3.1 MasterGo 侧：设计稿怎么准备才能被"读懂"

这一步是整套流程的地基，地基没打好，后面全是返工。我踩过的最大坑就是拿了一份没整理的设计稿直接喂，结果生成的代码图层名全是Rectangle 123、Group 456，根本没法用。

正确的准备姿势是这样的：

图层命名规范化。所有需要生成控件的图层，按类型_功能命名，比如tv_username、et_password、btn_submit、iv_avatar。类型前缀用tv（TextView）、et（EditText）、iv（ImageView）、btn（Button）、rv（RecyclerView）、layout（容器）。这样 Claude Code 一看名字就知道该用什么控件。

善用 Auto Layout。凡是水平或垂直排列的元素，全部用 Auto Layout 包起来。Auto Layout 的itemSpacing直接对应 Android 的margin或LinearLayout的divider，padding直接对应padding。开了 Auto Layout，AI 就能准确识别出"这是一个横向排列、间距 12dp 的按钮组"。

组件化复用。重复出现的元素（比如列表项、标签、头像）做成组件。生成代码时，Claude Code 会倾向于把它们抽成独立的 include 布局或自定义 View，减少重复代码。

标注单位统一。MasterGo 里设计稿一般按 375pt 宽度做，对应 Android 的 360dp 左右。这里有个换算：设计稿 px 值除以 2 得到 dp 值（假设 2 倍图）。这个换算关系要提前告诉 Claude Code，否则生成的间距会大一倍。

提示：准备阶段花 20 分钟整理图层，能省下后面 2 小时的返工。别偷这个懒。

3.2 设计数据怎么导出成 Claude Code 能吃的格式

MasterGo 本身没有"导出给 AI"的功能，所以需要中间做一层转换。我的做法是手动整理一份结构化的节点描述，格式用 JSON 或缩进文本都行。别嫌麻烦，这一步其实很快，因为整理的过程本身就是你在脑子里过一遍布局结构。

一个节点的描述大概长这样：

{ "name": "layout_header", "type": "frame", "layout": "horizontal", "width": "match_parent", "height": "56dp", "padding": [16, 0, 16, 0], "alignItems": "center", "children": [ { "name": "iv_back", "type": "image", "width": "24dp", "height": "24dp" }, { "name": "tv_title", "type": "text", "width": "0dp", "weight": 1, "textSize": "18sp", "textColor": "#333333", "text": "页面标题" } ] }

这份描述里，layout字段告诉 AI 用横向布局，weight告诉它这个文本要占满剩余空间，padding和alignItems直接对应 Android 属性。Claude Code 拿到这份数据，基本能一次生成八九不离十的代码。

如果页面节点特别多，可以分模块喂。比如先喂 header，生成完确认没问题，再喂 body，最后喂 footer。分批生成比一次性喂一大坨效果好，因为 AI 的上下文注意力也是有限的，信息太多反而会漏细节。

3.3 给 Claude Code 的提示词怎么写

提示词是这套流程的"操作说明书"，写得好坏直接决定输出质量。我总结了一个模板，包含四个部分：

角色与任务：明确告诉它"你是一个资深 Android 开发，根据以下设计节点描述生成 ConstraintLayout 布局代码"。

技术约束：指定用 ConstraintLayout、最小 SDK 版本、是否用 ViewBinding、命名规范、尺寸单位换算规则。

设计数据：把上一步整理的节点描述贴进去。

输出要求：要求生成完整 XML、每个控件加 id、加注释说明约束逻辑、复杂部分给出替代方案。

一个实际的提示词片段：

技术约束： - 使用 ConstraintLayout 作为根布局 - 尺寸单位：设计稿 px 值除以 2 得到 dp - 控件 id 用下划线命名，前缀区分类型 - 文本大小用 sp，间距用 dp - 需要适配 RTL 布局，用 start/end 而非 left/right - 生成完整的 XML，包含命名空间声明

这里有个经验：约束越具体，输出越稳定。我一开始提示词写得很随意，生成的代码一会儿用 LinearLayout 一会儿用 ConstraintLayout，风格不统一。后来把约束写死，输出就稳定多了。

3.4 生成代码的验收标准

代码生成出来不能直接用，得先过一遍验收。我的验收清单有这么几条：

• 约束完整性：每个控件是否都有水平和垂直方向的约束？有没有出现"missing constraints"的警告？
• 尺寸合理性：有没有硬编码的绝对宽度？该用0dp+ 约束的地方有没有用？
• 命名规范：id 是否符合项目规范？有没有重复？
• 层级深度：有没有不必要的嵌套？ConstraintLayout 的优势就是扁平化，如果生成出来套了五六层，就得优化。
• 适配性：有没有用match_parent该用的地方？文本有没有加maxLines和ellipsize？

这几条过一遍，基本能筛掉 90% 的问题。剩下的就是业务逻辑填充了。

4. 完整实操流程与关键环节

4.1 从设计稿到可运行布局的完整链路

我把整套流程拆成六个步骤，按顺序走一遍。

第一步：设计稿整理。打开 MasterGo 文件，检查图层命名、Auto Layout、组件复用。把不符合规范的图层重命名，把该开 Auto Layout 的容器开上。这一步大概 15-30 分钟，取决于设计稿的混乱程度。

第二步：节点数据提取。按模块把设计稿的节点结构整理成 JSON。我一般用 MasterGo 的标注功能看具体数值，然后手动填进 JSON 模板。一个中等页面大概 100-200 行 JSON。

第三步：提示词组装。把技术约束和节点数据拼成完整的提示词。技术约束部分可以做成模板复用，每次只换节点数据。

第四步：Claude Code 生成。把提示词发给 Claude Code，等它输出 XML。复杂页面建议分模块生成，别一次性全喂。

第五步：代码验收与调整。按上面的验收清单过一遍，手动修正约束、补充缺失属性。这一步是人工介入最多的环节。

第六步：集成测试。把生成的布局放进项目，跑起来看效果，对照设计稿调整间距、颜色、字号。真机跑一遍，检查不同屏幕尺寸下的表现。

整个链路走下来，一个中等页面从设计稿到可运行，熟练之后 20-40 分钟。对比纯手写，效率提升大概 3-5 倍。

4.2 一个真实案例的生成过程

拿一个典型的"个人中心"页面举例。页面结构是：顶部一个头像加昵称的横向布局，中间一组设置项列表，底部一个退出按钮。

设计数据整理（简化版）：

{ "name": "layout_profile", "type": "frame", "layout": "vertical", "width": "match_parent", "height": "match_parent", "backgroundColor": "#F5F5F5", "children": [ { "name": "layout_user_info", "type": "frame", "layout": "horizontal", "width": "match_parent", "height": "80dp", "padding": [16, 16, 16, 16], "backgroundColor": "#FFFFFF", "alignItems": "center", "children": [ {"name": "iv_avatar", "type": "image", "width": "56dp", "height": "56dp", "cornerRadius": "28dp"}, {"name": "tv_nickname", "type": "text", "textSize": "18sp", "textColor": "#333333", "marginStart": "12dp"} ] }, { "name": "rv_settings", "type": "list", "width": "match_parent", "height": "0dp", "weight": 1, "marginTop": "12dp" }, { "name": "btn_logout", "type": "button", "width": "match_parent", "height": "48dp", "margin": [16, 16, 16, 16], "text": "退出登录", "textColor": "#FF3B30", "backgroundColor": "#FFFFFF" } ] }

Claude Code 生成的代码（节选）：

<?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" android:background="#F5F5F5"> <androidx.constraintlayout.widget.ConstraintLayout android:id="@+id/layout_user_info" android:layout_width="0dp" android:layout_height="80dp" android:background="#FFFFFF" android:padding="16dp" app:layout_constraintTop_toTopOf="parent" app:layout_constraintStart_toStartOf="parent" app:layout_constraintEnd_toEndOf="parent"> <ImageView android:id="@+id/iv_avatar" android:layout_width="56dp" android:layout_height="56dp" android:contentDescription="用户头像" app:layout_constraintTop_toTopOf="parent" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintStart_toStartOf="parent" /> <TextView android:id="@+id/tv_nickname" android:layout_width="0dp" android:layout_height="wrap_content" android:layout_marginStart="12dp" android:textSize="18sp" android:textColor="#333333" app:layout_constraintTop_toTopOf="parent" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintStart_toEndOf="@id/iv_avatar" app:layout_constraintEnd_toEndOf="parent" /> </androidx.constraintlayout.widget.ConstraintLayout> <androidx.recyclerview.widget.RecyclerView android:id="@+id/rv_settings" android:layout_width="0dp" android:layout_height="0dp" android:layout_marginTop="12dp" app:layout_constraintTop_toBottomOf="@id/layout_user_info" app:layout_constraintBottom_toTopOf="@id/btn_logout" app:layout_constraintStart_toStartOf="parent" app:layout_constraintEnd_toEndOf="parent" /> <Button android:id="@+id/btn_logout" android:layout_width="0dp" android:layout_height="48dp" android:layout_margin="16dp" android:background="#FFFFFF" android:text="退出登录" android:textColor="#FF3B30" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintStart_toStartOf="parent" app:layout_constraintEnd_toEndOf="parent" /> </androidx.constraintlayout.widget.ConstraintLayout>

这份代码基本可以直接用。RecyclerView 用0dp加约束撑满中间区域，按钮固定在底部，头像和昵称的约束关系也对。需要手动补的是头像的圆角处理（用 CardView 或 ShapeableImageView）和 RecyclerView 的 adapter 绑定。

4.3 尺寸换算与适配的关键参数

尺寸换算是这套流程里最容易出错的地方，单独拎出来讲。

设计稿到 dp 的换算。假设设计稿是 375pt 宽、2 倍图，那么设计稿上的 1px 对应 0.5dp。也就是说，设计稿标注 32px 的间距，代码里写 16dp。这个换算比例要在提示词里明确告诉 Claude Code，否则它会直接把 px 当 dp 用，间距全大一倍。

字号换算。字号用 sp，换算规则和 dp 一样，但要注意 sp 会随系统字体大小缩放。如果设计稿要求字号不随系统缩放，得用 dp 代替 sp，但这是特殊情况，一般还是用 sp。

屏幕适配策略。Android 屏幕碎片化严重，一套布局要适配各种尺寸。我的做法是：

• 宽度用match_parent或0dp+ 约束，避免硬编码
• 高度该固定的固定（比如按钮 48dp），该自适应的用wrap_content
• 文本加maxLines和ellipsize，防止长文本撑破布局
• 关键间距用 dimens.xml 管理，方便统一调整

不同密度的资源。如果设计稿有切图，按 mdpi、hdpi、xhdpi、xxhdpi 出多套，或者用矢量图（VectorDrawable）。矢量图是首选，一套搞定所有密度。

注意：Claude Code 生成的代码默认不会帮你处理多密度切图，这部分得自己补。生成代码时可以让它预留@drawable/xxx的引用，切图自己放。

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

5.1 生成代码的典型问题速查

我把实际遇到的高频问题整理成一张表，方便对照排查。

这张表基本覆盖了 80% 的常见问题。遇到新问题，先对照这张表，大部分能直接定位。

5.2 我踩过的三个大坑

第一个坑：设计稿没整理就开干。第一次尝试的时候，我直接拿了一份设计师刚做完、图层名全是默认的稿子喂给 Claude Code。结果生成的代码里 id 全是view1、view2，控件类型也判断错了好几个——把文本当成了图片，把图片当成了容器。后来老老实实花时间整理图层命名，生成质量立刻上了一个台阶。图层命名是这套流程的命门，别想着跳过。

第二个坑：一次性喂太多节点。有个页面节点特别多，我图省事把整个页面的 JSON 一次性发给 Claude Code。结果它生成到后面就开始"偷懒"，有些节点直接漏了，有些约束明显是瞎写的。后来改成按模块分批生成，每个模块单独确认，问题就没了。AI 的注意力也是有限的，信息密度太高它会顾此失彼。

第三个坑：完全信任生成的约束。有一次生成的代码看起来没问题，跑起来才发现有个控件在横屏下跑到了屏幕外。原因是 Claude Code 给它加的约束在竖屏下成立，横屏下就冲突了。后来我养成了习惯：生成的代码必须在横竖屏、大小屏都跑一遍，特别是涉及约束的地方。AI 不懂你的适配需求，它只按你给的数据推断。

5.3 提升生成质量的两个进阶技巧

技巧一：给 Claude Code 提供项目现有的布局作为参考。如果你项目里已经有一套布局规范，挑一个典型页面贴给 Claude Code，让它"参照这个风格生成"。这样生成的代码风格统一，命名规范一致，集成时省事很多。我一般会贴一个包含常用控件和约束模式的"样板布局"。

技巧二：让 Claude Code 生成两版方案。对于复杂布局，我会让它生成两版：一版用 ConstraintLayout 扁平化，一版用 LinearLayout 嵌套。然后对比哪版更清晰、性能更好。有时候嵌套版反而更易读，特别是那种明显的线性结构。没有绝对最优的布局方案，只有最适合当前场景的。

5.4 什么情况下不该用这套流程

说了这么多好处，也得说说它的边界。以下几种情况，我建议还是手写：

• 高度自定义的绘制：比如不规则图形、复杂动画、自定义 View 的 onDraw，AI 帮不上忙。
• 性能极度敏感的列表项：RecyclerView 的 item 布局如果嵌套深了会掉帧，这种得手工优化层级。
• 设计稿本身不规范：如果设计稿就是一堆绝对定位的散图，整理成本比手写还高，不如直接写。
• 一次性页面：如果这个页面做完就不改了，手写可能更快，没必要走这套流程。

这套流程的价值在于重复性高、改稿频繁、结构规整的页面。用对场景，收益才明显。

6. 工具链与协作方式的延伸思考

6.1 把流程固化成团队规范

一个人用这套流程是一回事，团队用是另一回事。我后来把它整理成了一份团队内的"设计稿交付规范"，核心就几条：

• 设计稿必须用 Auto Layout，图层必须按规范命名
• 交付时附带一份节点描述 JSON（我做了个模板，设计师填就行）
• 开发侧统一用同一套提示词模板生成代码
• 生成的代码必须过验收清单才能提交

规范落地之后，团队里几个人的生成质量就拉齐了。流程的价值在于可复制，一个人跑通不算数，团队都能跑通才算数。

6.2 和现有开发流程怎么衔接

这套流程不是要替代现有开发流程，而是嵌进去。我的做法是：

设计阶段，设计师按规范出稿；开发阶段，用这套流程生成布局骨架；然后开发在骨架上填业务逻辑、接数据、调交互。AI 负责"形"，人负责"神"。布局的形（结构、约束、样式）交给 AI，业务的神（逻辑、状态、交互）人来写。

版本管理上，生成的布局代码和手写代码一样走 Git，该 review review，该测试测试。别因为是 AI 生成的就不走流程，那样迟早出问题。

6.3 后续可以怎么扩展

这套思路其实可以往外延伸。比如：

• 生成 Compose 代码：同样的节点数据，换个提示词就能生成 Jetpack Compose 的布局，思路完全一样。
• 生成多端布局：一份设计数据，同时生成 Android、iOS、Web 三端布局，跨端项目里特别香。
• 接入设计系统：把项目的颜色、字号、间距抽成 design token，生成代码时直接引用 token 而不是硬编码值，改主题时一处生效。

我现在正在试的是把 design token 接进去，让生成的代码直接引用@color/primary、@dimen/spacing_m这类资源，而不是写死#333333、16dp。这样后期换肤、调间距会方便很多。这个方向还在摸索，跑通了再单独写一篇。

最后分享一个我个人的小习惯：每次生成完代码，我会把提示词和生成结果存一份到一个本地文档里，标注哪些地方需要手动改。攒多了之后，就能总结出自己项目的"生成规律"——哪些模式 AI 一次就对，哪些必须人工介入。这份文档比任何教程都值钱，因为它是针对你自己项目的。