企业官网建设流程全解析

1. 从“开发模式真香”到“原生App翻车现场”

先聊一个我最近的真实感受：Figma的开发模式确实香，香到什么程度呢？我们团队去年把设计交付流程全面迁到了Figma上，前端同学不用再拿蓝湖逐像素对标注，也不用在Zeplin里面反复切图导出，直接在画布上点两下就能拿到CSS、iOS或Android的样式代码。从工具链的“顺滑感”来说，这确实是过去五年里设计研发协作效率提升最明显的一波。

但香归香，只要一做原生App项目，尤其是那种涉及复杂交互、系统组件、多机型适配的客户端需求，Figma开发模式那点“所见即所得”的美好幻觉就会迅速破灭。我这不是吐槽工具不好用，而是想认真聊聊一个被很多人忽视的事实：开发模式再怎么进化，它也只是一个“信息查看器”，替代不了真正的设计沟通和标注。特别是原生App开发里，设计到实现之间那道跨越不掉的鸿沟，恰恰是Bug的高发区。

这篇文章写给谁呢？给那些正在用Figma做设计交付的UI/UX设计师，给被各种“明明样式都对但就是有Bug”折磨的前端或客户端开发，也给刚入行、觉得“有了开发模式就不需要设计规范文档”的年轻同学。我会结合自己在原生App项目里踩过的坑，把Figma开发模式的边界、原生App的开发特殊性、以及一套更为务实的协作方式，一次性讲透。

2. 开发模式到底解决了什么，又没解决什么

2.1 开发模式的设计初衷：降低“取样式”的成本

Figma开发模式是2022年Figma Config大会上正式亮相的功能，它的核心目标就是那一个：把设计稿变成“可读性更强的代码参考”。在开发模式下，选中任意一个图层，右侧面板会直接列出该图层的属性：

• 颜色、字体、字号、行高、字重
• 圆角、边框、阴影、模糊等视觉效果
• Spacing、Padding、Margin的数值
• 导出切图的资源（PNG、SVG、WebP等）
• 对应的CSS、iOS（Swift）和Android（XML）代码片段

这个信息密度和便捷度，坦白说，比当年的标注插件（比如Measure、Specctr）要强得多。以前我用Measure的时候，每张图都得手动激活标注模式，导出的HTML文件还经常乱码，开发同学看完一脸懵。现在Figma开发模式是原生的、实时的、和设计稿完全同步的，任何一次设计修改，开发端打开就是最新状态，不存在版本不同步的问题，这个体验确实是过去不可想象的。

但请注意，我刚才特意用了“参考”这个词。开发模式给出的代码片段，本质上是对设计属性的“翻译”，不是对设计意图的“传达”。它能告诉你“这里用了16号字、行高24、字重Regular”，但它不会告诉你“为什么标题是主标题层级，为什么这里留白要比默认间距大”。这种藏在设计背后的逻辑——层级、节奏、语义、状态变化——恰恰是开发模式完全覆盖不到的盲区。

2.2 前端的“标记语言翻译器”与客户端的“系统级适配器”

还有一个很关键的认知偏差在于：很多团队看到开发模式能直接输出CSS或Swift代码，就想当然地认为“前端可以直接抄了”。这是对前端开发和客户端开发差异的误解，尤其是在原生App场景下，这个偏差会直接转化成线上的各种诡异Bug。

Web前端的核心工作，是把设计稿用HTML/CSS/JavaScript“翻译”成浏览器能渲染的页面。浏览器的渲染引擎（Chrome、Safari、Firefox）虽然也各有差异，但大体上遵循的是同一套CSS规范（W3C标准），所以设计稿上的margin、padding、flex布局等属性，在Web端确实有很高的可还原度。Figma给出的CSS代码，离线上代码之间的距离，通常只差一个“组织命名结构”和“媒体查询适配”的工作。

原生App客户端开发则完全是另一套逻辑。同样一个App，iOS跑在UIKit/AppKit上，Android跑在View系统或Compose上，两套框架对UI的渲染机制、测量过程和布局规则存在根本性差异。Figma开发模式只能给出一个“理想化”的数值，比如setFrame:或layout_width="match_parent"，但它无法替你做这些事：

• 判断该用AutoLayout的哪种约束关系（等宽、等高、比例、安全区）
• 判断该用LinearLayout、RelativeLayout还是ConstraintLayout
• 处理不同屏幕尺寸下的自适应规则（iPhone SE到iPhone 15 Pro Max）
• 适配系统字体缩放、深色模式、无障碍字号
• 处理安全区（Safe Area）、状态栏、底部Home Indicator、刘海屏的遮挡

这些是原生App开发里绕不开的坑。每一条处理不好，都会在真机测试阶段冒出一堆“看起来莫名其妙”的Bug，比如某个控件在iPhone 14上跑到了刘海下面，或者Android大字体模式下文字截断成省略号。而这些，Figma开发模式不可能给你答案——因为它压根不参与系统渲染，它只是一个标记了数值的平面图纸。

2.3 代码片段“可用性”的误导性

我经常跟团队里的人说一句话：开发模式里的代码，只能当“数字参考”，不能当“代码答案”。Figma给出的Swift代码片段，经常是这样一个东西：

label.text = "Button" label.font = UIFont.systemFont(ofSize: 16, weight: .regular) label.textColor = UIColor(red: 0.13, green: 0.13, blue: 0.13, alpha: 1.0)

这段代码看起来没毛病，但它默认的是一个已经创建好的UILabel实例，而实际开发中你要考虑的是这个Label的复用、AutoLayout约束、点击事件、可访问性标识（accessibilityIdentifier）等等。Figma给不了你完整的上下文依赖，就像你在Google Maps上看到了目的地的具体坐标，但导航过程还是得靠自己的车感和路况判断。

更麻烦的是，在深色模式下，设计稿里那个UIColor(red: 0.13, ...)可能并不适合原样使用，因为深色模式要求的是语义化颜色（semantic color），比如UIColor.label、UIColor.secondaryLabel这类动态颜色。Figma开发模式的代码输出是基于绝对值的，它不知道你的App是支持深色模式的，也不知道你在设计系统里定义了哪些语义色。如果开发同学照单全收，后果就是：深色模式下一片刺眼的白块或黑块，吐槽Bug的声音接踵而至。

3. 原生App开发的“Bug温床”：开发模式最容易忽视的5个隐性断层

3.1 交互状态与操作反馈的缺失

设计稿和开发模式能展示的，永远只是“静态界面”。就算Figma出了Prototype和Smart Animate，它模拟的也只是“单一交互路径的过渡效果”，不是真实的系统交互逻辑。但原生App的用户体验恰恰建立在严密的交互状态机之上：按钮有Normal、Pressed、Disabled、Loading、Selected、Focus等状态，输入框有Empty、Active、Filled、Error、Disabled状态，列表有加载中、加载完成、加载失败、下拉刷新、上拉加载更多、空数据等状态。

开发模式只告诉你“最终长什么样”，但没有任何信息能告诉你“从初始状态到最终状态，中间经历了哪些状态变化”。这直接导致一个高频Bug：设计师只做了正常态和按压缩放（通常是一个scale(0.98)的效果），开发实现时忘记加禁用态，用户连点两次按钮就提交了重复订单。排查起来，既不是Figma的错，也不全是开发的锅——而是整个链路里缺失了“交互状态标注”这种深层沟通。

3.2 事件传递与手势冲突的不可见

原生App开发中有一类Bug特别隐蔽、特别难修，那就是手势冲突。UITableView的滑动、UICollectionView的点击、页面边缘的侧滑返回、导航栏的pop手势、ScrollView嵌套时的多层滚动……这些事件在Figma开发模式里是完全没有对应物的。

举个我自己遇到过的案例：我们做iOS端的一个商城首页，设计稿里顶部轮播图支持横向滑动，下面紧挨着一个支持上下滚动的商品列表。设计师在Figma原型里用Smart Animate把切换效果做得很顺滑，但真正实现时，UIScrollView嵌套UITableView，手势响应链上一路冲突——横向滑动经常被系统误判为纵向滚动。调试了整整两天，最后靠自定义UIGestureRecognizerDelegate才解决。这个问题的根源，不是设计稿画得不好，而是设计沟通里压根没有“事件行为”这一层信息，开发模式能给你的只有静态的颜色和坐标。

3.3 字体、行高和文本渲染的跨平台差异

如果你只用Web开发的经验来看Figma开发模式，你会觉得那不就是CSS里那套font-size、line-height吗？拿到App端就会发现问题。

• iOS的UILabel默认行高，和Figma里设定的line-height并不总是完全一致，尤其当字体比较大或设置了多行文本时，首行和尾行的间距会出现细微偏差。
• Android的includeFontPadding属性，默认就是带上下额外Padding的，如果开发同学不了解这个设置，文字垂直居中永远是偏的。
• 自定义字体在不同系统上的fallback规则不同，某些字体文件在中英文混排时，行高基线完全对不上，导致中英文文本上下错位。

这些差异单看数值是没用的，必须靠真机逐一验证。而开发模式不可能替你做这些验证，更加剧了“设计稿上明明是对的，真机上一堆问题”的错位感。我曾见过一个新入职的开发同学，对着Figma开发模式里的line-height参数较劲了半个下午，反复调整UILabel的行高，但真正的罪魁祸首其实是系统字体和设计字体在ascent/descent指标上的差异。

3.4 系统组件与自定义控件之间的“技术债”

原生App的界面，要么基于系统自带控件（UINavigationBar、UITabBarController、TextView等），要么用完全自绘的自定义控件，要么两者混合使用。系统组件自带一套默认行为，比如导航栏的毛玻璃效果、TabBar的系统返回按钮文案、CollectionView的Cell复用机制。开发模式只能给出视觉样式，不会提醒你这些系统行为已内置，更不会提醒你应该通过系统API来控制，而非完全重写自定义控件。

很多Bug恰恰来自“过度自定义”：设计师看到系统TabBar样式普通，要求定制成某种品牌色风格，开发同学一看Figma开发模式里的形状和阴影参数，撸起袖子就从零手绘了一套TabBar。结果呢？新TabBar在某些低版本系统上出现动画卡顿、点击区域偏移、badge位置错乱等问题。这些在Web开发里根本不存在的问题，在原生App开发中是家常便饭。而Figma开发模式只会让你觉得“代码都给我了，照着实现就行”，从而忽略了系统组件本身的复杂性和适配成本。

3.5 多机型适配与动态字体缩放的不可见性

原生App运行在几百上千种不同尺寸、分辨率和系统版本的设备上。iPhone SE（4.7英寸）、iPhone 12 mini、iPhone 14 Pro Max、各种Android中低端机的屏幕密度，全部都是开发模式“看不见”的东西。设计稿在Figma里可能只有一个iPhone 15 Pro（393 x 852）的画板，开发模式基于这个画板给出的尺寸和间距，也只适用于这个理想容器。

但真实场景是，客户端的UI必须用AutoLayout或ConstraintLayout去做自适应布局。这里立刻就有无数个坑：某个横向排列的按钮组，在最大屏上正常，在最小屏上宽度溢出；某个固定高度的卡片，在系统开启特大字体模式时，内部文字换成两行，卡片被内容撑破；某个底部弹出的ActionSheet，在带Home Indicator的机型上，底部安全区高度从0变成34pt，控件被小白条挡住。

开发模式不会告诉你哪些约束是“可变”的、哪些是“固定”的，它只会机械地给出当前画板下的数值。在实际开发中，你必须靠标注、注释或口头沟通来明确：哪个元素是固定宽高，哪个元素是弹性伸缩，哪些间距是动态计算的。一旦这些信息缺失，开发就大概率只会照数值死做，然后QA在真机测试时提回一大堆“不同机型布局错乱”的Bug。而且这类Bug通常优先级还不低——因为它们涉及到核心功能的可用性，改起来又牵一发动全身，非常耗时。

4. 实操心得：在原生App项目里，我如何平衡Figma开发模式与传统标注/沟通

4.1 开发模式可以“看”，但设计规范文档不能省

如果你问我现在团队里到底怎么用Figma开发模式，我的答案很明确：开发模式是“最后一公里的取数工具”，但它前面必须有一整套设计规范文档（Design Spec）作为基础。

这套文档不需要像过去那样用PPT或PDF逐页截图说明，但至少要在Figma里建立一个独立的“规范页面”或“文档页面”，包含这些内容：

• 颜色系统（含语义色、深色模式映射关系）
• 字体阶梯（含字号、行高、字重、系统字体还是自定义字体）
• 间距系统（4/8/12/16/20/24等基准网格）
• 圆角、阴影、描边等视觉元素的统一token
• 组件状态（Normal、Pressed、Disabled、Loading、Selected等）
• 布局适配规则（哪些是fixed，哪些是fluid，哪些是比例关系）
• 交互状态机和页面跳转逻辑

开发模式解决的是“这个按钮当前状态下的尺寸和颜色是什么”，设计规范解决的是“这个按钮在什么状态切换、什么情况下禁用、点击后的行为是什么”。缺了后者，开发就只能靠猜，而猜的过程就是Bug产生的过程。

4.2 注释和说明要落在组件/图层上

Figma的深层通信功能之一，是你可以直接在画布上对任意图层添加注释和说明。我强烈建议设计师在做原生App项目时，把与系统相关的适配规则直接写在对应的Frame或组件的注释里。

举例来说，导航栏那部分，我一般会加类似这样的注释：

该导航栏使用系统UINavigationBar，不自定义 左右按钮间距遵循系统默认的16pt 标题字体使用系统粗体17pt（UIFontTextStyle.headline） 深色模式下背景色使用UIColor.systemBackground 隐藏返回按钮文案，只保留箭头图标

这样开发一选中导航栏组件，在右侧面板里就能直接看到这一大段文字，即使设计规范文档不在手边，也能快速get到关键信息。这种方法虽然简单，但在实操中比单独建文档有效得多——因为信息就长在“设计图的旁边”，开发想看就得看，不需要额外打开一个似乎永远找不到入口的文档。

4.3 用“组件属性（Variants + Component Properties）”驱动开发模式输出更合理的代码

Figma的组件系统和Variants，其实可以在不额外写文档的情况下，把一部分“信息沟通”融入到开发模式里。比如你可以把一个按钮做成一整套组件，包含Primary、Secondary、Ghost三个变体，再加上Disabled、Loading等属性开关。开发同学在开发模式里选中具体变体时，拿到的样式代码就已经是接近最终实现状态的参数。

这种做法的价值在于，诱导开发同学“取数”时自主完成状态选择，避免他们拿着默认状态去实现所有场景。初学者经常忽略的一点是，Figma组件属性面板里不仅能切换显示状态，还能给内部图层写描述性的属性名。比如输入框组件里可以加一个errorMessage: String属性，开发同学在真机里遇到错误提示场景时，就能在属性面板里看到具体的文案和颜色规则。

用这种模式，开发模式在一定程度上就变成了“可配置的动态文档”，比一张静态设计图的信息容量大得多。但也很坦诚地讲，这一套能不能用起来，核心还是团队里有没有人愿意花时间把设计资产组件化。做纯页面视觉稿的团队，直接上手这套思路会比较吃力，建议从高频复用组件（按钮、输入框、弹窗）开始逐步推进。

4.4 一定要走一遍“真机走查”，别把Bug都丢给QA

前面说的都是设计和“标注”的沟通层面，但原生App特有的那类“设备相关Bug”，光靠文档和注释是防不住的。我最想强调的是，设计和开发双方，都需要认认真真地做“真机走查”。

真机走查不是拿设计稿对着手机屏一个个像素比，那是视觉还原对比，虽然有用但远远不够。真正的真机走查是从用户视角出发，把核心操作路径在真机上完整走一遍，关注点包括：

• 不同屏幕尺寸下的布局是否正常
• 系统字体放大到最大时，界面是否还能正常使用
• 深色模式下，所有页面是否有错误的硬编码颜色
• 快速点击、快速滑动时，是否出现卡顿或视图闪跳
• 断网状态、弱网状态下，页面的加载态/失败态是否正确
• 系统返回手势、左滑操作、长按菜单等系统交互是否顺滑

我自己的做法是，在开发提测前，设计师和开发坐在一起，挑两三部有代表性的真机（一部小屏旧机、一部大屏旗舰、一部中端Android或旧款iPhone），花40分钟左右过一遍主要流程。这样做的直接结果是——大量低级Bug在提测前就被干掉了，QA那边一次性通过的版本数量明显上升，设计师和开发之间的互相信任也建立起来了。

这个工作流里有没有Figma开发模式的位置？有，但它只作为“取参考值”的工具，真正的价值来自人和人之间的即时沟通和现场确认。

4.5 代码走查时怎么看待Figma生成代码

偶尔有初级开发问我：“Figma直接生成的那段Swift代码，质量怎么样？”我的答案是：可以作为参考，但绝对不能直接搬。

它的数值是准确的，但代码的组织方式是生硬的：全写在一个viewDidLoad里、没有约束变量、没有适配代码、没有accessibility、没有写死常量管理。真这么用，代码注定没法维护。更关键的是，Figma并不知道你的项目工程用的是什么架构（MVC、MVVM、VIPER还是SwiftUI），也不知道你的通用样式组件库叫Theme还是Style，更不知道你局部状态怎么管理。它生成的代码更像是一份“标注的翻译”，而不是一个“可以融入工程的代码块”。

我建议所有搞原生App开发的团队，建立一套自己内部的“设计Token到代码变量”的映射关系表。比如设计规范里的颜色Token叫ColorBrandPrimary，那么团队代码里就统一用这个名字，不要在代码里到处硬编码色值。否则就算Figma开发模式给出的色值是#FF4D4F，开发在代码里写死之后，以后想统一改品牌色，就会变成全网大搜索的灾难。这是和开发模式无关但被它容易掩盖的问题——代码质量最终还是人的功夫。

5. 常见问题速查：用Figma开发模式做原生App时的高频翻车场景

这张表基本上是我这几年在原生App项目里遇到的高频Bug合集，每一行背后都是血泪教训。值得强调的是，这类Bug在Web开发里大概率不会出现，因为浏览器的标准化已经帮你解决了很多系统差异；但原生App没有这种“中间层”兜底，所以对设计沟通和标注完整度的依赖反而更高。

6. 这套协作方式，后续还能怎么优化

工具和流程都是在跑项目中反复磨出来的。如果你所在的团队正准备全面铺开Figma开发模式，同时又做大量的原生App业务，我建议你用一段时间实验一下上面这套方法，把设计规范、组件化、注释体系和真机走查流程逐步建立起来。初期会有点麻烦，尤其需要设计师在画图之余多花些精力做规范的维护，但坚持两三个迭代之后，提测质量、Bug回收率和跨角色沟通效率都会明显改善。

我自己目前还在尝试的另一个方向，是把Figma的API和团队内部的Bug跟踪系统做联动。设计侧修改某个组件时，能自动关联到过去一段时间内跟该组件相关的Bug单，从而快速定位“是不是设计稿调整引发的回归”，省得在沟通群里反复问来问去。这个做法的主动权不仅在工具侧，更在团队对“设计-开发-测试”这条链路的精细管理上。

最后说一个我个人的看法：工具永远只是辅助，替代不了人对设计意图的理解、对系统复杂性的敬畏、对用户体验细节的执着。Figma开发模式提升的是取数效率，但不提升任何人的专业判断力。一位成熟的原生App开发者，不会因为有了开发模式就放弃阅读设计规范、放弃真机走查、放弃和设计师认真对齐交互逻辑。尤其是碰到Bug的高发区——状态、切换、适配、手势、异常——你更需要依赖的是清楚的沟通标注，而不是点开开发模式就能拿到的那个十六进制色值。