Claude Code + MasterGo：Android 布局全自动生成实践-北京尧图网络

做过设计稿还原的人应该都体验过那种“量尺寸量到眼瞎”的崩溃。设计师在 MasterGo 里把间距、字号、圆角调得清清楚楚开发这边却要拿着标注一点点换算最后还原度还总是被吐槽。前阵子我在一个跨团队项目里尝试了Claude Code MasterGo 的配合把设计稿转 Android 布局的流程做得几乎全自动今天把整套可复现的实践过程整理出来希望能帮你把这条链路彻底跑通。这篇指南适合三类人被高频改稿折磨的 Android 开发者、想缩短设计到开发交付周期的团队负责人、以及正在尝试 AI 辅助编码但苦于不知道怎么跟设计数据打交道的同学。我会按照“数据准备 → 工作流搭建 → 案例实录 → 坑点复盘 → 生产化思考”的顺序把一个页面从 MasterGo 设计稿到可编译 XML 的完整过程掰开揉碎地讲清楚。1. 从设计稿到代码这条链路到底卡在哪先说一个反直觉的结论AI 生成 Android 布局这件事最大的瓶颈从来不是 AI 能力而是你喂给它的数据形态。大多数团队尝试失败是因为直接把设计稿的截图或者原始导出的庞大 JSON 丢给模型然后期待它像人一样“看懂”界面。这从一开始就走错了路。1.1 传统人工还原的三大痛点做过几轮设计还原的人都知道纯手工转化设计稿有几个绕不开的麻烦标注信息的二次换算。MasterGo 里一个按钮距离左侧 48px但是开发要在不同屏幕密度下工作px 转 dp、文字字号转 sp这些计算琐碎且容易出错。只要有一个数值换算错整个页面的对齐关系就会在真机上现出原形。嵌套结构认知偏差。设计工具里的 Frame / Group 层级和 Android 的 ViewGroup 体系不是一一对应的。设计师为了排版方便套了三层画板开发如果原样翻译成三层 LinearLayout不仅性能受影响代码也没法看。这里需要的是“结构的语义化翻译”而不是物理复制。改稿循环成本过高。设计稿调整间距、换主题色这些小事落到开发侧就是重新量、重新改、重新自测。高频改动下一个页面花在“翻译设计稿”上的时间可能远超真正写逻辑的时间。这些痛点的共同本质是设计数据没有经过结构化预处理就进入了编码环节导致人或者 AI 都只是在做低效的“看图猜数字”。1.2 为什么选 MasterGo 作为数据源头MasterGo 在设计数据导出上有几个很适合喂给 AI 的特性支持页面级别导出 JSON 结构每个图层节点的类型、坐标、尺寸、填充色、字体信息都是结构化字段而不是光栅图。可以定义设计变量颜色、字号、间距 Token导出后直接映射 Android 的values/colors.xml、dimens.xml这是后续规范化的根基。内置自动布局能力节点间的排列关系在 JSON 里有明确体现方便 AI 识别“这是个水平排列的按钮组”而不是“只是坐标碰巧对齐的一组矩形”。我给 AI 的方案从一开始就不是让它“看设计稿”而是让它“读结构数据”。MasterGo 的导出物经过一层压缩脚本处理后就是一份干净、语义化、体积可控的布局摘要。1.3 为什么用 Claude Code 而不是普通的对话式 AI普通 AI 对话窗口最大的问题是“无状态且脱离工程”。你让它生成一个 XML它给你一段代码块你复制进项目发现字体资源没引用、背景色和主题冲突、约束链少了一条于是又复制报错信息回去让它改。一个页面来来回回几十轮效率还不如手写。Claude Code 不一样它是能直接工作在你的项目目录里的编程代理。我常用的方式包括让它直接读取工程里的layout_spec.json、colors.xml、styles.xml它能看到整个 Android 工程的上下文而不仅仅是你贴给它的那一段话。它支持连续多轮修改同一文件比如生成activity_profile.xml之后你可以直接说“把列表项的圆角统一改成 16dp”它会精准定位并修改而不是整文件重写。它可以执行命令比如跑 Gradle 编译验证不过我的实际经验是尽量避免让它跑完整 Build成本高且容易失控这个后面专门讲。所以工具组合的核心逻辑是MasterGo 负责把设计稿变成结构化数据Claude Code 负责把结构化数据变成工程代码中间那一层压缩和转换脚本则是整条流水线是否好用的胜负手。2. MasterGo 里先整理出一份“AI 能读懂的布局摘要”第一版的方案我犯过一个错直接从 MasterGo 导出全量 JSON然后让 Claude Code 直接读。结果那个文件动辄 20MB层级嵌套几十层模型处理起来上下文爆炸不说里面还有大量对布局生成毫无意义的属性比如特效的 blendMode、导出配置的 scale 等。后来我总结出一句话给 AI 的数据压缩到什么程度都不过分关键是保留什么、砍掉什么必须从生成代码的需求反推。2.1 从导出 JSON 到 layout_spec.json 的字段裁剪思路MasterGo 导出的原始 JSON 里每个节点通常包含 id、name、type、bound、style、fills、strokes、effects、layout、exportSettings 等几十个字段。但是对于 Android 布局生成真正要保留的最小组大约如下字段用途说明name节点名用于映射 Android 控件 id 和注释命名越是语义化越好type节点类型TEXT、RECTANGLE、FRAME、INSTANCE 等决定生成什么控件bounds全局坐标和尺寸已经由脚本转成 dp包含 x、y、width、heightvisible可见性隐藏节点直接过滤或标记 gonefills填充色取第一个有效填充转成#AARRGGBBstrokes描边用于生成边框颜色和宽度cornerRadius圆角映射shapedrawable 或 MaterialCardView 的半径text/fontSize/fontWeight/lineHeight文本信息直接生成TextView的文字内容与字号行距layout自动布局信息识别 Flex 方向的排列方式辅助约束布局设计backgroundColorframe 级容器背景用于生成布局根节点的背景色以我实际用过的一个 Node 脚本为例核心逻辑就是遍历节点树做筛选和单位换算// compress-layout.js -- 把 MasterGo 导出的原始 JSON 压缩为布局摘要 const fs require(fs); function compressNode(node, density 3, baseX 0, baseY 0) { const b node.bound || {}; const x (b.x ?? 0) - baseX; const y (b.y ?? 0) - baseY; const result { name: node.name, type: node.type, x: Math.round(x / density * 100) / 100, y: Math.round(y / density * 100) / 100, width: Math.round((b.width ?? 0) / density * 100) / 100, height: Math.round((b.height ?? 0) / density * 100) / 100, visible: node.visible ! false, }; if (node.style) { if (node.style.fontSize) { result.fontSize Math.round(node.style.fontSize / density * 100) / 100; result.fontWeight node.style.fontWeight; result.text node.characters || ; } const fill node.fills node.fills.find(f f.type SOLID f.visible ! false); if (fill fill.color) { result.backgroundColor rgbaToHex(fill.color, fill.opacity ?? 1); } if (node.style node.style.cornerRadius) { result.cornerRadius Math.round(node.style.cornerRadius / density * 100) / 100; } } if (node.children node.children.length) { result.children node.children .filter(child child.visible ! false) .map(child compressNode(child, density, b.x || 0, b.y || 0)); } return result; } function rgbaToHex(color, opacity) { const r Math.round(color.r * 255).toString(16).padStart(2, 0); const g Math.round(color.g * 255).toString(16).padStart(2, 0); const b Math.round(color.b * 255).toString(16).padStart(2, 0); const a Math.round(opacity * 255).toString(16).padStart(2, 0); return #${a}${r}${g}${b}.toUpperCase(); } const raw JSON.parse(fs.readFileSync(process.argv[2], utf-8)); const spec { pageName: raw.name || page, designWidth: 1080, designDensity: 3, nodes: (raw.children || []).map(child compressNode(child, 3)), }; fs.writeFileSync(layout_spec.json, JSON.stringify(spec, null, 2));这个脚本有几个很关键的细节都是实战打磨出来的坐标转成相对于最外层 Frame 的相对坐标。原始 JSON 里大量子节点的 x/y 是相对于父容器的Claude Code 在读的时候很容易绕晕。我干脆在压缩阶段就把所有坐标统一成“页面内容区坐标”这一步能减少大模型大量无效计算。把密度参数直接写进产物。我基于 1080 设计稿、3x 密度换算。生成出来的数值已经是 dpClaude Code 直接写进 XML 就行不需要在 prompt 里再解释换算公式。实测至少省了一半的“它问一句、你答一句”的往返。所有颜色统一转成带 alpha 位的 HEX。Android 的颜色资源要带透明度比如#CCFF0000。如果原设计稿里我们只给 RGB那生成的背景色在深色模式下容易出问题。这个脚本统一格式后续 AI 就不会猜。2.2 图片资源单独导出别指望 AI 帮你“找图”布局摘要里不会保留位图数据MasterGo 的位图节点在 JSON 里通常只给一个 ref 或 resourceName真正的内容需要单独导出。这一步必须在进入 Claude Code 之前完成因为模型没法替你从设计稿里“抠图”。我建议的导出规范挨个选中位图节点按Android或PNG格式导出密度至少给xxhdpi尽量xxxhdpi免得适配问题。导出文件名必须和节点 name 保持一致比如ic_avatar_default.png这样 JSON 里的 name 字段能直接映射成 Android 资源引用drawable/ic_avatar_default。如果是背景图或者不规则形状优先导出透明底 PNG如果设计稿里做了圆角裁切建议让设计师提供未裁切的源图圆角用 Android 的ShapeableImageView实现这样日后改圆角不必重新导图。提示这一层如果出了幺蛾子AI 再聪明也无能为力。Claude Code 生成代码时会默认引用drawable/下的资源你资源缺失编译就报错。所以我在团队里定的规矩是先进资源导出再跑布局生成。2.3 语义化命名是 AI 理解的隐形成本压缩脚本可以处理数据但处理不了混乱的命名。如果设计稿里的图层叫“矩形 1127”、“组 56”、“Frame 334”那生成出来的 XML 里就会有一堆id/rect_1127、id/frame_334对着这样的代码做后续维护会非常崩溃。理想情况下设计稿里每个可交互或可见的节点应该采用类似btn_profile_edit、tv_user_name、iv_avatar、list_menu_container这样的命名规范。如果现有设计稿命名混乱我有两个替代方案在压缩脚本里加一个 name 映射表把已知的混乱名字手工映射成规范 id一劳永逸。在生成 XML 后让 Claude Code 基于语义推断控件用途来重命名 id比如把rect_7788识别为按钮后改成btn_7788再通过批量查找替换更新引用。3. Claude Code 接活的条件让它在工程里能有据可依很多人的误区是安装了 Claude Code 之后像跟普通 AI 聊天一样上来就说“帮我生成一个登录页面布局”。然后它生成的代码要么风格跟你的工程体系完全不一致要么引用了不存在的主题属性。问题不在工具在于你根本没有给它“工程上下文”。3.1 先搭一个 Android 工程骨架作为工作台为了跑通流程我建议单独建一个“AI Layout Workbench”实验工程或者在你的主工程里开一个experiment/目录。理由是实验过程中生成的 XML 很可能有错误直接污染主工程会让版本管理很痛苦。工作台至少需要这些文件让它读取app/src/main/res/values/colors.xml— 主题色、语义色app/src/main/res/values/dimens.xml— 常用间距、圆角、字号app/src/main/res/values/styles.xml— 按钮、输入框等基础控件样式app/src/main/AndroidManifest.xml— 让模型了解包名和需要注册的 ActivityClaude Code 的优势在于它能自主读取这些文件。我在进入项目目录后会先输入类似下面的开场指令请先浏览这个 Android 工程的 res/values 目录和 AndroidManifest.xml 理解我的主题、颜色、字体、间距体系。之后我会给你 layout_spec.json请严格基于这套工程风格生成布局不要引入工程里不存在的自定义属性。第一次跑通之后我发现它生成的 XML 质量明显不一样了。它会优先用?attr/colorPrimary而不是硬编码色值会用dimen/page_margin而不是捏造 15dp、17dp 这种不规整数字。这个效果非常明显值得先花五分钟搭上下文。3.2 约定一套生成规则比反复纠正更省事我强烈建议在工程根目录放一个AI_LAYOUT_RULES.md作为长期约束文件每次启动 Claude Code 时让它先读这个文件。这相当于把团队的 Android 编码规范喂给它。我目前用的规则文件核心内容大致如下根布局默认使用ConstraintLayout除非是列表项或滚动容器避免嵌套层级超过三层。控件间距优先使用ConstraintLayout的Guideline百分比和0dp约束链严禁用大量margin堆砌。所有尺寸单位必须是 dp文本字号必须是 sp。文本内容如果包含{{变量名}}格式的占位符原样保留不要生成android:text死数据。圆角统一的控件优先使用MaterialCardView或者 shape drawable而不是每个控件单独写background。凡是在工程styles.xml中已有对应样式的控件例如AppButton.Primary必须使用stylestyle/...不允许重复定义颜色、圆角、边框。这些规约不是从文档抄来的是我在实验过程中反复遇到问题后形成的实战经验。比如“不要用 margin 堆砌”这一条就是因为模型默认倾向于给每个子控件写上下左右 margin结果屏幕旋转或字体缩放之后整个布局直接放飞自我。3.3 把 layout_spec.json 放到工作台里在压缩脚本产出的layout_spec.json准备好后我通常把它和文本资源放在同一个目录并给 Claude Code 明确的读取路径我在 docs/design/layout_spec.json 里有页面布局的结构化描述现在请你读取它并结合 AI_LAYOUT_RULES.md 和 res/values 下的资源文件生成完整的 Activity 布局res/layout/activity_profile.xml。要求 1. 优先复用已有样式资源 2. 控件的 android:id 必须语义化 3. 用注释标明每个控件对应设计稿中的节点名 4. 涉及图片控件的部分引用已导出的 drawable 资源名。这里要再次强调它真正需要的是已经压缩过的、坐标已统一的 JSON。如果你把整个原始 JSON 丢给它那它就像让一个新来的开发去读一套完全没有整理过的设计文件能干活但会浪费大量时间在理解结构上。4. 一次完整的页面生成实录从 layout_spec.json 到可编译 XML说再多理论不如跑一遍流程。下面我用一个虚构的个人中心页面模拟项目X作为案例完整演示从 MasterGo 数据到可编译 XML 的全过程。4.1 页面数据的结构化表达示例假设这个页面主结构是顶部个人信息卡片头像、昵称、描述、中间一排功能入口按钮收藏、历史、设置、下方一个列表三行菜单。经过压缩脚本处理后layout_spec.json的结构大概是这样的节选{ pageName: profile_page, designWidth: 1080, designDensity: 3, nodes: [ { name: header_card, type: FRAME, x: 24, y: 48, width: 352, height: 120, backgroundColor: #FFFFFFFF, cornerRadius: 16, children: [ { name: iv_avatar, type: ELLIPSE, x: 24, y: 24, width: 72, height: 72 }, { name: tv_user_name, type: TEXT, x: 112, y: 32, width: 180, height: 28, text: {{user_name}}, fontSize: 18, fontWeight: BOLD }, { name: tv_user_desc, type: TEXT, x: 112, y: 68, width: 180, height: 20, text: {{user_desc}}, fontSize: 13 } ] } ] }可以看到这个 JSON 已经把设计稿里的节点抽象成代码直接可用的等级了。坐标是 dp、文本占位符保留、颜色已是 HEX、圆角已经归类。对 Claude Code 来说读起来几乎没有歧义。4.2 生成结果长什么样Claude Code 读取 JSON、遵循规则文件后生成的核心 XML 片段如下简化了部分约束以保持可读性androidx.constraintlayout.widget.ConstraintLayout android:layout_widthmatch_parent android:layout_heightmatch_parent android:paddingHorizontaldimen/page_margin com.google.android.material.card.MaterialCardView android:idid/header_card android:layout_width0dp android:layout_heightwrap_content app:cardBackgroundColorcolor/surface app:cardCornerRadius16dp android:layout_marginTop16dp app:layout_constraintTop_toTopOfparent androidx.constraintlayout.widget.ConstraintLayout android:layout_widthmatch_parent android:layout_heightwrap_content ImageView android:idid/iv_avatar android:layout_width72dp android:layout_height72dp android:srcdrawable/iv_avatar android:layout_margin24dp app:layout_constraintStart_toStartOfparent app:layout_constraintTop_toTopOfparent/ TextView android:idid/tv_user_name android:layout_width0dp android:layout_heightwrap_content android:layout_marginStart16dp android:text{% raw %}{{user_name}}{% endraw %} android:textColorcolor/text_primary android:textSize18sp android:textStylebold app:layout_constraintStart_toEndOfid/iv_avatar app:layout_constraintTop_toTopOfid/iv_avatar app:layout_constraintEnd_toEndOfparent/ TextView android:idid/tv_user_desc android:layout_width0dp android:layout_heightwrap_content android:layout_marginStart16dp android:layout_marginTop4dp android:text{% raw %}{{user_desc}}{% endraw %} android:textColorcolor/text_secondary android:textSize13sp app:layout_constraintStart_toEndOfid/iv_avatar app:layout_constraintTop_toBottomOfid/tv_user_name app:layout_constraintEnd_toEndOfparent/ /androidx.constraintlayout.widget.ConstraintLayout /com.google.android.material.card.MaterialCardView /androidx.constraintlayout.widget.ConstraintLayout这不是我手写的是它一轮生成的成果。可以看到它已经自动把设计稿里的白色卡片映射成了MaterialCardView引用了工程里的color/surface和dimen/page_margin而不是硬编码。这个效果证明了一个判断只要给的数据足够结构化、规则足够明确AI 生成代码的质量是可以跟中级开发媲美的。4.3 编译期修正的常规操作生成不等于收工编译验证是一定要做的。我让 Claude Code 生成完后会先在 Android Studio 里 Sync 并编译把报错信息回贴给它。常见的问题有这么几类图片资源名不一致JSON 里的iv_avatar和实际导出的 drawable 文件名大小写不一致导致drawable/iv_avatar引用失败。解决办法是统一命名规范导出前就检查。主题属性不存在比如它生成了?attr/textPrimary但工程里根本没有这个自定义 attr。我会让它在读取colors.xml后能用color/text_primary就不用?attr/。ConstraintLayout 约束链断裂某些控件只约束了 start 没约束 end在边界情况下会出现宽度异常。修正后让它重新检查一遍所有0dp宽控件的左右约束是否成对出现。我特别建议大家不要手动去改这些错误而是把编译错误原样丢回给 Claude Code让它自己修复。它能理解和修改现有文件的上下文通常会在几轮内解决。4.4 给列表项和重复组件单独建立模板在生成RecyclerView的 item 布局时第一次尝试会比较容易翻车。因为layout_spec.json里往往只有一条列表项的结构重复数据在 MasterGo 里是复制的 node模型容易为每个重复项生成独立布局导致 item 和 adapter 对不上。我的做法是设计稿里每类列表项只导出一份样本结构然后在 prompt 里明确说明类表项结构只有一个样本请为每一种列表项生成独立的 item 布局例如 item_menu.xml。列表容器本身只生成 RecyclerView 框架不要生成具体的 item 内容。这样生成的代码结构非常干净主页面的 Activity 布局负责放RecyclerView单独的item_*.xml文件负责列表单项。Claude Code 在查了你的工程后还会自动给出ListAdapter的 Diff 实现片段整个链路就很丝滑了。5. 实测中踩过的几个坑以及绕过方式这套流程我前后跑了几十个页面踩坑记录攒了一堆。挑几个最有代表性的按“症状 → 原因 → 绕过方案”的方式讲清楚。5.1 坐标错乱不是模型笨是数据源就没对第一次跑通之后我试着一个复杂的页面结果生成出来的 TextView 全都叠在左上角。排查下来发现是压缩脚本的问题MasterGo 的原始 JSON 里部分节点的bound是相对于父容器的而部分节点又是全局坐标。我最初的脚本统一减了baseX/baseY但遇到嵌套 Frame 时会重复减两次坐标就全乱了。绕过方案压缩脚本里对坐标做统一的“拍平”处理从根节点开始递归累计偏移让每个节点的 x/y 始终是相对页面根布局的全局坐标。另外我在脚本里加了断言生成的 JSON 里所有坐标值必须在0 ~ designWidth / density范围内超了直接报错。5.2 颜色丢失深色主题一开全暴露另一个高频问题设计稿里某按钮本来有背景色但生成出来的按钮却是透明的一开深色模式按钮和背景糊成一片。原因是压缩脚本里对 fills 的处理不够细致只取了第一个 fill但 MasterGo 里经常同一节点有两三层 fill第一层是透明渐变底色。绕过方案在压缩脚本里做聚合优先取非透明的、最上层的颜色如果节点同时有fills和strokes分别生成背景色和描边色如果 fill 是渐变就没法用纯色映射那就统一走 shape drawable 的渐变生成需要额外由 Claude Code 根据gradient字段生成 drawable 文件。5.3 嵌套过深AI 很容易变成“结构翻译器”最开始我给的规则不够强硬Claude Code 倾向于完美复刻设计稿的节点层级。结果一个页面生成了 7 层嵌套的布局NestedScrollView 套 LinearLayout 再套 ConstraintLayout既卡又不优雅。绕过方案在AI_LAYOUT_RULES.md里强制规定普通页面根布局只允许一到两个 ViewGroup纯装饰性 Frame净容器且无背景色、无圆角直接合并掉圆角用 ShapeableImageView 而不是嵌套一层裁剪容器。加上这条之后生成的布局明显更像是一个有经验的工程师写的。5.4 图片溢出或变形density 的锅设计稿里的一张头像图是 72×72dp但导出的 PNG 是 216×216px3x生成的 XML 里ImageView如果直接 match_parent 就会糊。更隐蔽的问题是 aspectRatio 变形一些海报类 ImageView 被写死宽高比例完全忽略了设计稿的图片裁切方式。绕过方案在 prompt 里增加固定声明——“凡涉及图片默认使用android:scaleTypecenterCrop宽度 0dp 且高度固定或按比例具体裁切区域参考 MasterGo 导出的裁剪节点。”经过几次补充后图片相关的生成错误率大幅下降。5.5 一个快速排查对照表症状可能原因解决办法控件全部重叠在左上角压缩脚本坐标偏移重复计算统一按全局坐标拍平加断言按钮透明无背景fills 聚合逻辑漏了颜色多条 fill 取最上层非透明色根布局嵌套 5 层以上规则文件没限制 ViewGroup 深度强制合并装饰性 Frame图片模糊或比例变形density 换算或 scaleType 缺失统一 centerCrop 明确宽高字号或间距很奇怪模型没看到 dimens 规范让它先读 dimens.xml 再生成6. 这套流程想真正上生产还差哪几步单页跑通只是开始真正把这条链路推进到“团队日常可用”的级别我还在补齐几个关键环节。这里也分享一些正在实验的方向。6.1 把设计变量直接映射成 Android 主题目前我们依赖 Claude Code 在生成时“看到”colors.xml后自觉使用主题色。更可靠的做法是在数据源头解决MasterGo 里维护一套 Design Tokens导出时直接生成 Android 的colors.xml、dimens.xml甚至themes.xml。例如{ color: { primary: #FF7A4D, surface: #FFFFFFFF, text_primary: #FF17191C }, spacing: { page_margin: 16, card_padding: 24 } }用一个简单脚本转换成资源文件然后在规则文件里明确让 AI 优先使用这些变量。这套思路跑通以后设计改主色调Android 这边几乎零成本同步。6.2 让设计变更走“差异更新”而不是全量重写早期每轮改版都要重新生成整个页面改动面很大。后来我在 MasterGo 里改了设计稿重新导出layout_spec.json然后让 Claude Code 对比上次的 spec 做增量 diff请先读取 docs/design/layout_spec_v2.json对比 docs/design/layout_spec_v1.json 找出设计稿变化的部分只修改对应布局文件和资源不要动其他无关区域。这一招极大地降低了回归风险。模型对文件级 diff 的理解能力足够而且它会主动检查修改是否影响现有 id 引用、样式资源等相邻依赖比自己手动 Diff 再合并省心不少。6.3 补一道机器可跑的还原度回归光靠人眼比对一次两次还行量产之后很难保证一致性。我现在在做一个简单的回归脚本把生成的 XMLbounds抽取出来和设计稿数据做坐标比对输出偏差列表。更轻量的方案是你自己写一个 UI 测试遍历页面所有 View 拿到实际坐标和layout_spec.json里的期望值做断言。虽然做不到像素级视觉比对但至少能捕捉 80% 的错位、漏控件、尺寸错误。设计稿一变回归测试就挂开发就知道哪些地方需要改这比靠测试小姐姐肉眼找问题高效得多。6.4 团队协作层面的前提条件最后必须泼一盆冷水这套流程对设计稿质量的要求可能会超出很多团队的现状。如果图层命名混乱、元素没有走自动布局、各种装饰性 Frame 满天飞那么无论压缩脚本写得多么好生成结果都会耗在“清理垃圾”上。我在团队里做的推动是先统一设计稿的规范再谈自动化。主要抓三点所有可见元素必须有语义化命名禁止“矩形 123”“组 45”列表重复项只保留一个样本其余用自动布局排列颜色、字号、间距一律引用 Design Token不手工填数值。当设计稿质量达到这个水平之后AI 能省下的不止是“写代码”的时间更重要的是“重新沟通”的时间。设计师和开发不再为一个 4dp 的间距差异来回讨论因为设计稿的数据本身就是唯一事实来源。我在实际测试中发现最有价值的不是“一键生成完整页面”这个科幻场景而是那种“改了设计稿之后自动同步所有相关布局”的日常节奏。Claude Code 不是来替代开发的它更像一个极其熟悉你工程规范、可以通宵帮你翻译设计稿的初级工程师。它做的活你最终还是要审一遍但至少“量尺寸、写死布局、刷屏改颜色”这类纯机械的体力活终于可以从我的待办清单里划掉了。如果你也想试试建议从一个小页面入手把压缩脚本和规则文件先建好跑通了再慢慢加页面复杂度。

Claude Code + MasterGo：Android 布局全自动生成实践

相关推荐

PatchPae2原理详解：如何破解Win8.1 32位4G内存限制

路径遍历漏洞深度解析：从5个真实案例到三层防御体系

PyTorch搭建模型全流程：从数据加载到训练部署的实战指南

更多资讯

非合作博弈下的居民负荷分层调度与双层鲸鱼算法求解

数控加工仿真软件3.7实战指南：刀路验证与避坑技巧

上位机与汇川PLC的Modbus TCP通讯：视觉结果回写与联调避坑指南

大年初七晨听歌：一小时的选曲逻辑与实操记录

多厂商网络设备登录配置全解析：Console、Telnet、SSH与Web实战

别再背Docker命令了：从镜像到Compose的实战心法

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？