企业官网建设流程全解析

这两年做Android开发，我拿到设计师的MasterGo链接后，基本是这样一个循环：打开标注面板，对着尺寸、色值、圆角、间距一个数值一个数值地抄到XML里，再手动画约束，跑一次模拟器，截图发给设计师，对方回一句“间距好像差了2dp”，我再回去改。这事重复到第三个页面的时候，我实在受不了了，决定把“设计稿转布局”这个环节完整地交给Claude Code来做。结果比我预想的顺：它能读懂设计文档，能直接改工程里的XML，能和我讨论约束逻辑，甚至能主动帮我补上资源引用。这篇就是我从头到尾跑通这套流程的完整记录，包括工具配置、信息提取、Prompt组织、复杂页面处理和踩坑清单，照着做就能复现。

整个流程的核心不是让AI替你思考怎么设计，而是让它替你做“从设计稿数值到Android布局代码”的翻译和落地。MasterGo负责把设计意图结构化地输出，Claude Code负责理解这份结构并生成贴合工程规范的XML和配套资源。你会发现，真正花时间的环节不是“写代码”，而是“说清楚需求”。

1. 为什么我从手写XML转向这套组合

1.1 传统还原流程的三大痛点

先说最让人抓狂的痛点：重复劳动。做客户端开发的都知道，一个中大型App少说几十个页面，每个页面的间距、字号、颜色在标注面板里一目了然，但落实到XML里就是机械的三件套：对着数值敲、敲完预览、发现有偏差再敲。这个过程极其消磨耐心，尤其当你连续还原三四个页面的时候，眼睛对“2dp偏差”这种信息会逐渐失去敏感度。

第二个痛点是设计稿更新后的同步成本。设计师改了一个按钮的背景色或者某个页面的间距，不会单独通知你“我只改了这几处”，而是直接把整个页面的标注更新掉。你得重新过一遍全稿，逐项对比，才能找出变化点。一天来回几次，开发精力全耗在这上面。

第三个痛点是团队里没有统一的设计token机制。很多时候，设计稿里写的是具体的十六进制色值，而工程里可能已经有了一套colors.xml封装。开发时要手动查找“这个颜色是否已经存在”，找不到就新建，时间一久，资源文件里冗余色值越堆越多。这三件事单独看都能忍，凑在一起就是每天白天的黄金时间被吃掉大半。

1.2 为什么偏偏是MasterGo和Claude Code

选择MasterGo，不是因为它功能花哨，是因为它天生适合做“设计信息向工程侧转移”这件事。标注面板数据完整、切图导出支持Android资源目录、设计变量能统一管理颜色和字号，最关键的是它在线协作，设计师更新完画板，我看到的永远是实时数据。相比其他工具需要本地装客户端或插件，它的门槛更低，团队内外用起来都顺手。

Claude Code在我这套工作流里的定位不是普通代码生成器，而是一个能常驻在工程目录里的智能协作伙伴。普通的“设计稿转代码”插件或网页工具我试过不少，它们的通病是给一段一次性代码就完事，完全不管你的工程结构、命名规范和资源组织方式。Claude Code不一样，它可以直接读取项目源码、搜索现有资源文件、理解你之前的布局风格，然后生成风格一致的XML。我在真实项目中反复用它生成和修改布局，它不会把工程搞得一团糟，反而会主动提出用dimens.xml统一间距、把硬编码颜色提升为资源引用这类建议。

另一个选择它的重要理由是“可迭代”。手写XML时代，改一个圆角要重新编译跑模拟器看效果；用Claude Code，我可以直接在对话里说“登录按钮的圆角从8dp改成12dp，并且给按压态加一个selector”，它会把相关文件改好，我再去做验证。这个“直接改文件和反复迭代”的能力，是静态生成工具完全不具备的。

1.3 这套工作流适合哪些人和项目

适合人群我总结下来有三类。第一是客户端开发，尤其是要频繁对接设计稿的中坚力量，能把时间从抄数值转移到布局结构和交互逻辑上；第二是独立开发者，自己既做设计又写代码，用这套流程可以省掉“自己给自己标注”的尴尬；第三是新手开发者，看AI生成高质量XML的过程中，能直观理解ConstraintLayout的约束关系、资源引用的最佳实践。

如果项目是大型App，页面层级很深、设计规范已经沉淀成一套完整的主题系统，这套流程同样能用。关键是第一步要把设计变量和工程资源映射清楚，让AI在生成时直接引用现有主题，而不是放飞自我地硬编码。当然，如果你的设计稿本身还没有规范，颜色靠手选、间距靠感觉拉，那不管用什么工具都会很痛苦。我的建议是先把设计变量梳理一遍，再上这套工作流。

2. 从零搭建工具链：MasterGo与Claude Code的接入要点

2.1 工具清单与最简配置

跑这套流程只需要四样东西：能访问MasterGo设计稿的账号、一个配置好Android SDK的工程、能运行Claude Code的终端环境，以及一份想把重复劳动干掉的心态。前两样大部分Android开发者都有，重点在第三样。

Claude Code的安装环节我不多展开，跟着官方快速开始文档走就行，几分钟能装好。最需要确认的是两件事：一是在终端里能正常输出CLI版本号，二是已经完成账号登录。我之前跳过登录直接跑，结果项目目录里它始终无法正常工作，卡了很久才发现问题。安装完成后，在Android工程根目录下执行一次简单的对话，确认它能读取目录结构，工具链就算通了。

工程侧我建议提前做两件小事。第一，在项目根目录新建一个docs/design/目录，专门存放从MasterGo导出的设计规格文档，这样Claude Code每次都能快速定位；第二，在CLAUDE.md里写好项目基础约定，比如“主色调见colors.xml”“间距统一走dimens.xml”“布局文件命名使用snake_case”。这个文件是Claude Code在项目环境下默认会关注的说明文档，把所有工程规范写进去之后，每次会话它都会自动带着这些背景知识，生成结果更不容易跑偏。

2.2 在Android工程中让Claude Code“看到”设计稿

很多人第一次用这个组合时最常见的困惑是：一个命令行工具，怎么给它看设计稿？其实渠道很多，我在实际使用中总结出最稳定的是两条。

第一条是结构化文本输入。MasterGo的标注面板里，每种元素的尺寸、颜色、间距、字体都是一段文本信息，你选中画板里的图层，把关键数值复制整理成结构化的设计规格，再通过Prompt发给Claude Code。这种方式信息密度高、不含糊，AI不用“猜”颜色到底是偏白还是纯白，生成出来的结果基本一次到位。

第二条是设计环境截图。在MasterGo中切到画板页面，把目标界面用浏览器截图工具保存为PNG，然后在Claude Code的会话里把图片路径给它，它不仅能识别界面整体布局，还会结合你同时提供的规格文本做交叉验证。我在实际项目中通常两种方式都用：先给截图让AI建立全局印象，再给结构化数值约束细节。缺了截图，AI容易把元素间距的比例理解错；缺了规格文本，纯看截图又很难精确到1dp的差异。

2.3 三种输入方式选哪个

如果只选一种，我强烈推荐结构化文本为主、截图为辅。结构化文本是让AI理解“精确需求”的通用语言，截图则是帮助它建立“视觉上下文”的辅助资料。仅仅把截图丢给AI而不给数值，生成的布局大概率会出现靠运气找尺寸的情况——比例能对上，但字号、边距很难精确匹配设计稿。

第三种方式是把MasterGo画板的导出JSON传给AI。MasterGo支持把设计稿数据导出为JSON格式，里面包含所有元素的绝对坐标、尺寸、层级关系。这种方式优点是完全无损，缺点是信息量太大，直接丢给AI会让它陷入信息过载，反而抓不住重点。我在只有一个简单页面时会用JSON，复杂页面一律用整理过的规格文本。经验是：给AI的信息要像给同事看的需求单一样精炼，而不是把原始数据整个倒给它。

3. 给AI说清楚设计稿：信息提取与Prompt组织

3.1 MasterGo标注里必须采集的七类数值

经过几次翻车，我把每次从MasterGo提取信息时“必查”的项目固定成了一个清单，这样既能减少漏项，又能保证给AI的信息结构稳定。我整理成了一张对照表，每次设计稿还原都按这个模板取数：

这个清单的好处是我每次整理设计规格时不用临时去想还有哪些没看，按表格逐项过一遍即可。真正做到“提取完整设计信息后再开始写Prompt”，AI翻车的概率会大幅下降。

3.2 我把Prompt模板固定成了这样

信息采集完之后，我一般会填充下面这个固定模板再发给Claude Code：

你是这个Android项目的资深布局工程师。请基于以下设计规格生成XML布局。 项目背景：本项目使用ConstraintLayout作为根布局，所有尺寸使用dp，字号使用sp， 颜色和字符串必须引用资源文件，禁止硬编码。 设计规格： 页面目标：登录页 根布局：ConstraintLayout，宽高match_parent，背景颜色#FFFFFF 1. 顶部标题 文案：欢迎回来 字号：24sp 字重：bold 颜色：@color/text_primary 位置：距顶部72dp，水平居中 2. 手机号输入框 高度：52dp 水平边距：24dp 背景：填充#F5F5F5，圆角8dp，无边框 提示文案：请输入手机号 位置：标题下方48dp 3. 登录按钮 高度：48dp 水平边距：24dp 背景：填充#FF7A00，圆角8dp 文案：登录 字号：16sp 颜色：白色 位置：输入框下方32dp 额外要求： - 控件ID使用含义清晰的前缀，如tv开头为TextView，et开头为EditText - 所有尺寸值统一写入dimens.xml，颜色写入colors.xml

这个模板看起来朴素，但实际效果很好。关键在于它把“让AI扮演的角色”“硬性规范”“设计数值”“额外要求”四件事拆得清清楚楚。我让AI先明确自己的身份和底线，再提供精确到数的规格，它生成代码时就不会左右为难。早期我用过一段没有模板的对话，结果是让它自由发挥，生成的布局虽然能看，但命名风格和资源管理与工程格格不入，后续改造成本不低。

3.3 用设计变量打通AI与项目资源

MasterGo的设计变量功能在我这套工作流里价值被低估了。设计师在MasterGo里创建的颜色变量通常有稳定的命名，比如brand/primary、text/primary、surface/background。我在第一次构建项目时，会和设计师约定好：设计稿里的变量名和工程里colors.xml的资源名保持映射关系，比如brand/primary对应brand_primary。

这样做的直接好处是：Claude Code在生成代码时，看到设计规格里写着“颜色变量brand/primary”，它自然会去colors.xml里找同名资源并引用，而不是创建新的十六进制硬编码。对一套持续迭代的设计系统来说，这等于打通了从设计到代码的“同声传译”，后续就算设计稿改色，我们只需要改colors.xml里的一个值，整个App所有用到这个变量的页面都会同步更新。

我在实际项目中甚至会把dimens.xml也纳入这个映射体系。设计师一般把间距分为space/s、space/m、space/l，我们就对应建space_s、space_m、space_l资源。规格文本里不带具体数值，直接给变量名，生成代码的质量和可维护性会好很多。

4. 一个登录页的完整还原实录

4.1 设计规格：先把它写成人能读懂的文档

为了让你直观感受整个流程，我拿一个登录页作为示例，完整走一遍从设计稿到XML的过程。

设计稿内容很简单：白色背景，顶部一句“欢迎回来”，下面依次是手机号输入框、验证码输入框、登录按钮、忘记密码链接。我按清单提取完信息之后，整理成了一份设计规格文档，放在docs/design/login_page.md里。文档里写清楚了每个控件的精确尺寸、相对位置、颜色、字号和圆角。

这份文档是给Claude Code看的，也是给未来的自己看的。如果哪天布局要调整，直接改这个文档再丢给AI，比重新打开设计稿对照要快得多。整理文档的过程中，我还会顺手把需要新增的图片资源列出来，例如“密码可见性切换的图标需要两张：show.png和hide.png”，然后在MasterGo里切图导出，放到工程的drawable-xhdpi和drawable-xxhdpi目录。

4.2 第一次生成：看AI如何理解约束

我把写好的设计规格、截图路径和工程结构说明一起发给了Claude Code。它先读取了CLAUDE.md里的项目约定，然后查看了colors.xml和dimens.xml，开始生成activity_login.xml。第一轮出来的代码结构基本符合预期，根布局是ConstraintLayout，标题居中约束到父布局顶端，输入框约束到标题下方，按钮又约束到输入框下方。

第一轮代码里有几个地方让我注意到了：按钮的高度用的是设计稿里的52dp，但设计稿里按钮实际看起来比输入框略矮，我重新查了标注，发现确实是我自己在文档里写错了，不是AI的问题。还有一个细节是AI主动把输入框的背景写成了一个独立的drawable文件，而不是直接给EditText设置android:background="#F5F5F5"，这样方便后续统一处理聚焦状态，符合工程最佳实践。

看完代码后，我在终端里继续提了几个需求：“手机号输入框需要限制长度，并且输入类型设置为phone”“验证码输入框旁边加一个‘获取验证码’的倒计时按钮”“登录按钮需要引用strings.xml里的登录文案”。这些细节在设计稿里没有体现，但属于业务常识。Claude Code全都按要求处理了，并且在生成的资源文件里补上了对应的字符串和颜色。

4.3 迭代打磨：从“能跑”到“规范”

第一轮生成的代码已经能跑，但离“工程规范”还有一段距离。我做了三件事来收尾。

第一件是把布局里的所有魔数抽成资源。AI一开始直接在XML里写了72dp、48dp、32dp这些边距，我让它统一替换成dimens.xml中的引用，并且按语义命名，比如margin_top_welcome、margin_between_fields。第二件是补充Pressed状态。登录按钮在设计稿里只有静态颜色，我要求它把按钮背景做成selector，普通状态是#FF7A00，按压态是#E06E00，禁用状态是#FFD9B0。第三件是把输入框聚焦时的视觉效果做出来：聚焦时边框变色、加轻微阴影，失焦时恢复默认灰白背景。

这些交互细节都是设计师没有标注的，属于客户端开发的经验范畴。这套工作流能比较舒服地处理这类对话式迭代——你不需要去改动XML文件，只需要在会话里描述期望效果，AI就会定位到对应文件并修改。持续几轮之后，登录页的代码从单纯“还原设计稿”变成了“符合业务实际状态的完整页面”。

4.4 验收：截图对比模拟器与设计稿

代码改完后，我把工程在Android Studio里跑起来，模拟器上打开登录页截图，并把截图和MasterGo里的设计稿并排放在一张图里。逐项核对：标题的字号和颜色是否一致、输入框高度和间距偏差是否在1dp以内、按钮圆角是否和设计稿相近、图标尺寸是否对齐。

这一遍验收我是人工完成的，因为目前任何AI都无法完全取代你亲眼确认“效果是否对”。如果发现问题，我会把对比情况反馈给Claude Code，例如“标题与顶部距离偏小，目前实际约64dp，设计稿是72dp，请检查dimens引用并修正”。AI会顺着问题追踪到底是生成的边距数值不对，还是Android状态栏高度影响了坐标感知。

这一轮跑下来，从整理设计规格到验收完成，一个登录页整体耗时大约40分钟，其中真正写代码的时间基本为零。而传统手写流程，同样的页面从抄数值到调适配，小半天就没了。

5. 复杂页面生成：列表、层级与多尺寸适配

5.1 RecyclerView列表页怎么拆指令

复杂页面不能像登录页那样“一个页面一个输出”就搞定，尤其是RecyclerView列表，至少涉及三个层级：列表本身、item布局、Adapter逻辑。我的做法是把问题拆成三个独立的Prompt，分步让Claude Code处理。

第一步，让它生成item布局。我会把设计稿里的卡片信息整理成规格，重点关注卡片边距、内部元素间距、文字行数限制、图片占位尺寸。这一步只让它产出item_xxx.xml。第二步，让它生成RecyclerView所在的页面布局，包括列表的容器属性、下拉刷新布局、空态视图和加载更多状态。第三步，让它根据item布局编写Adapter，包括ViewHolder绑定、点击事件、数据更新方法。分步生成的好处是每一步都有明确的验收边界，哪一步出问题就只重做哪一步，不会整段推倒。

我试过一次把三个步骤塞进同一个Prompt，结果AI的注意力明显被稀释，item布局里的元素约束关系出了错，列表页本身又漏掉了空态视图。拆开之后，每一步的输入输出都更可控，质量明显提升。

5.2 图片与图标资源：让AI引用正确路径

复杂页面通常伴随大量切图资源。MasterGo里导出Android切图时，可以按屏幕密度自动生成drawable-xhdpi、drawable-xxhdpi等目录。我一般要求设计师在导出时勾选“Android”格式，这样拿到的是可以直接放入Android工程的PNG或WebP文件。

在给Claude Code的规格文本里，我会明确写出每个需要图片的部位对应的资源文件名，例如“用户头像占位图使用img_avatar_placeholder，位于drawable-nodpi目录”。AI在生成XML时就会直接用@drawable/img_avatar_placeholder引用。这一点很关键，如果只写图片位置描述而不给资源文件名，AI可能会去自己创建一个不知道从哪来的引用，编译时就报错。

对于矢量图标，我倾向于让Claude Code生成VectorDrawable XML，而不是放位图。图标素材来自MasterGo里导出SVG，然后我让AI把它转成VectorDrawable格式，并统一放到drawable/目录。这样图片体积小，还能适配不同分辨率。

5.3 多尺寸适配：在设计规格里提前埋点

Android布局最怕的就是设计稿看着正常，一到小屏或大屏设备就变形。我在设计规格里会提前标注哪些区域需要“弹性适配”。

例如，标题下边距72dp不是固定值，而是需要用Space或者按比例约束；左右边距24dp可以用固定值，因为它在多数屏幕上依然合理；input框高度52dp建议用@dimen/input_height，因为如果后续要适配大屏，可能想增加高度，统一改一个资源就行。遇到较复杂的适配需求，我会直接给AI提出用Guideline按百分比定位，例如“登录卡片垂直居中，并保证在屏幕高度低于640dp时使用滚动布局”。

多尺寸适配的本质是提前在规格层面把“哪些固定、哪些弹性、哪些按比例”划分清楚。AI在生成布局时就会按你设定的边界选择合适的约束方式，而不是所有地方都用固定的margin。这一套下来，我在1x、2x、3x不同分辨率的模拟器上验证过，布局基本都能保持设计稿的观感。

6. 避坑实录：常见问题与我的解法

6.1 尺寸单位混乱，dp变成px

我在早期使用中踩过最频的就是单位问题。设计师在MasterGo里给出的尺寸通常基于375×812的逻辑分辨率画板，数值按dp理解没问题，但我在Prompt里没有强调“所有尺寸必须用dp”，AI生成时就可能把标注数值直接写成px。在低密度设备上，px和dp看起来差不多，一到高密度设备，布局就变得拥挤寒酸。

后来我在CLAUDE.md里明确写了一条硬性约定：全项目布局一律使用dp作为尺寸单位，sp作为字号单位，任何以px结尾的尺寸都要视为错误。同时在每份设计规格文档顶部都重复一遍这条规则，双保险。AI生成完代码，我自查时也会顺手搜索一下px关键词，基本能拦截绝大多数问题。

6.2 生成的代码与工程风格不一致

这个问题在引入工作流初期比较明显。AI生成的布局和项目现有代码风格相差很大，比如现有代码都习惯给ConstraintLayout写对应的tools:context，AI生成的却漏掉了；现有代码控件ID习惯用两个字母缩写前缀，AI喜欢写完整的描述性长ID。风格不一致的代码混在工程里，后续维护很难受。

我的解法是在CLAUDE.md里加入“代码风格示例”区块，从现有工程里摘两段真实XML作为示例放进去，并写明风格要求。AI读项目说明时会参考示例输出，生成风格就会向现有代码靠拢。补上示例后，生成的布局和人手写的基本看不出来差异。

6.3 AI上下文遗忘导致返工

会话太长之后，AI会逐渐遗忘早期的设计约束。最典型的是我第3次迭代时提了“全部用品牌色变量”，但等到第8轮迭代，它又开始在新增控件里使用十六进制色值。不是它不遵守规则，是长对话的注意力分散了。

我的应对方法很朴素：把关键的设计变量和硬性规范独立写入根目录的CLAUDE.md和docs/design/design_constants.md中。每轮对话，我都会让Claude Code先读取这两个文件再干活。这样即使对话很长，关键规则也能反复被加载到上下文中。如果确实发现AI“学坏了”，我会新开一个会话，只带上规范文档和历史关键信息，避免带偏新生成内容。

6.4 控制生成节奏，别让对话烂尾

最后一个经验是对“生成节奏”的控制。我见过不少同事第一次用这类工具时，一口气把一个复杂页面的所有需求全丢给AI，然后被输出的大段代码淹没，验收时无从下手。

我的建议是每次只让AI完成一个小的、明确的增量：先出骨架布局，再填充控件细节，再补交互状态，最后优化资源规范和注释。每完成一步就花十几秒过一眼，确认符合预期再进入下一步。这种“小步快跑”的节奏，AI出错率最低，出问题时定位也最快。说到底，Claude Code不会替你判断什么是对错，但它能成为一款极度高效的放大工具——你愿意花多少心思描述清楚预期，它就能把对应的重复劳动吞掉多少。而你在整个过程中省下来的精力，应该毫无保留地投入到最终的“人工验收”环节。毕竟设计稿还原这件事，最终要过的是屏幕前那双眼睛。