最近带一个原生App版本团队里Figma开发模式用得飞起大家都觉得设计交付这步终于可以轻松了。结果测试阶段Bug清单递到我桌上时差点没把我送走——大量还原度问题并不是代码写错了而是设计沟通和标注环节被“开发模式”这个工具给架空了。先把结论放这儿Figma开发模式很好用但它替代不了设计沟通和标注尤其在做原生App的时候把它当成“万能钥匙”反而会坑出更多Bug。这篇文章就围绕我最近的实战复盘展开聊聊开发模式到底能干什么、不能干什么、原生App为什么特别容易翻车以及正确的协作流程长什么样。适合设计师、客户端开发、前端开发和测试同学一起看。1. 开发模式解决的是“给数据”不是“给判断”1.1 开发模式到底做了什么Figma开发模式Dev Mode本质上是一个信息聚合面板。点开之后选中任意图层就能看到尺寸、位置、颜色、字体、圆角、阴影、间距这些参数还能一键导出切图、复制CSS代码、查看变量和组件变体。对比早年用Zeplin、蓝湖或者手动写标注的年代这确实是质的飞跃。省掉了切图上传、标注导出、反复确认“这个颜色是哪个值”的琐碎沟通。以前设计稿和开发之间的信息传递靠人工在图片上画红线和标注框费时费力还容易漏。现在打开Figma选中即所得数据准确性也有了保障。但它解决的是“数据获取”的效率和准确性问题。开发模式把所有视觉参数从设计稿里抽出来像一份完整的配料表。可做菜这件事光看配料表是做不出好菜的——火候、顺序、什么时候放盐这些才是真正体现经验的地方。1.2 “数据齐全”不等于“需求清楚”开发模式给的是一份静态快照。颜色值、字体大小、间距尺寸都是当时的某个设计状态。但一个真实功能背后隐含的是大量判断这个按钮为什么是44pt而不是32pt是因为Apple HIG建议最小点击区域那个列表为什么在超长文本时要有折叠逻辑是因为要保整屏可读性。这些决策背景不会出现在开发模式里。举个例子设计稿里一个卡片阴影效果Figma开发模式里显示的是具体的模糊值、透明度、偏移量。但到了iOS原生实现里shadowOpacity、shadowRadius、shadowOffset这些参数和Figma的写法并不是一一对应直接照抄会出现“阴影过重”或“阴影丢失”的问题。这时候开发通常会来问你“这个阴影要达到什么效果”你需要从视觉感受层面描述而不是再丢一个参数过去。数据只能告诉你“是什么”不能告诉你“为什么”更不能告诉你“边界在哪”。而边界恰恰是最容易出Bug的地方。1.3 设计沟通的真相聊边界、聊状态、聊取舍真正需要沟通的都是开发模式里看不到的东西页面有几种状态空数据、加载中、加载失败、弱网超时每种状态长什么样超长文案怎么处理标题两行截断还是全部展示超出后是省略号还是“展开”按钮系统字体放大后怎么布局用户开了超大字体列表会不会破版暗黑模式要不要适配适配的话阴影、背景色、图片资源怎么换不同屏幕尺寸下间距是等比缩放还是固定值横屏怎么办这些问题没有一个是能靠“打开开发模式看一眼”回答的。所以我一直跟团队强调开发模式解决的是静态信息的传递而设计沟通解决的是动态场景和业务约束的对齐。两者是配合关系不是替代关系。2. 原生App开发里设计Bug为什么反而更多2.1 尺寸换算与切图倍率的陷阱原生App开发里最经典的低级Bug就是尺寸单位换算问题。Figma画板里的单位是ptpoint逻辑点iOS开发也是用pt看起来是一致的但Android用的dp也是逻辑像素和pt虽然原理相似实际在设备上最终显示的物理像素是pt × density。不同机型density不一样有2.0、2.75、3.0如果开发直接把设计稿里的值当成dp写进代码在某些机型上看起来就会忽大忽小。切图资源更是重灾区。Android要求一套图适配不同密度的设备常见做法是输出mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi几套或者用Vector Drawable矢量图。iOS至少要2x、3x两套。在实际项目里经常遇到切图只导了一倍图开发放上去之后图标在真机上一片模糊或者干脆被拉伸变形。换算关系要心里有数以dp和px为例dp px × 160 / dpi也就是在320dpi2倍屏的机型上1dp等于2px。Figma里一个48×48的图标标注写48pt实际在Android需要按不同density输出96px、120px、144px等尺寸。如果开发只拿标注数字写死资源密度都配错界面自然乱套。2.2 字体、行高与渲染引擎的差异另一个高频Bug来源是字体。设计师用MacFigma里默认渲染的是思源宋体、苹方、SF Pro这类字体但开发设备上的字体渲染引擎、系统默认字体、字重映射都和设计环境不一样。尤其是Android平台中文默认字体是思源黑体变体英文默认是Roboto和iOS的苹方在字面率、基线位置、行高上都有差异。这引出几个热门话题里提到的“figma安装字体”——很多设计师在Figma里看到字体显示异常是因为本机没装对应字体Figma用了fallback字体顶替。这个状态下生成的标注字体名可能都是错的开发照着实现上线后和设计稿完全是两个气质。更隐蔽的是行高。Figma的Auto Layout里可以设置固定行高设计稿里一段14号文字配了20的行高看起来舒服。但Android/iOS原生的TextView在默认状态下行高是由字体度量决定的不一定和Figma一致。如果开发没有显式设置lineSpacingExtra或baselineOffset还原出来就会出现文字裁切、行距过大等问题。这种问题开发模式只会告诉你“行高是20”但不会告诉你“这个20在iOS上要用baselineOffset实现在Android上要配置LineHeightStyle”。判断和翻译仍然需要人来完成。2.3 Auto Layout与原生布局引擎的“软件翻译”误差Figma的Auto Layout很强大但它解决的是设计稿内图层的自动排布和原生开发的约束、容器语义完全是两套体系。比如设计稿里一个卡片内部是“头像 姓名 时间”水平排列Figma里用Auto Layout管理看起来间距都是12pt开发如果用原生Constraint一般也能实现。可一旦遇到动态内容比如姓名特别长、系统字号增大、屏幕宽度变化Figma里的Auto Layout规则并不会直接翻译成原生的约束优先级、内容压缩阻力、抗拉伸等级。在这个问题上我见过无数次这样的Bug设计稿里一个Cell是固定高度开发也写死高度结果用户开大字体或多语言翻译后文案变长文字直接溢出边界被截断或者重叠。Figma开发模式给你展示的是绝对坐标和排布关系但原生开发需要的是一套面向“动态内容变化”的布局策略包括约束优先级、固有内容尺寸、最小宽高限制。这些东西没办法从设计稿里直接抄只能在沟通中明确规则。2.4 动效、滚动和原生控件的状态缺失Figma不是笨但它本质上是个静态设计工具。Smart Animate能模拟一点交互动效可真实原生App里的系统行为比如键盘弹起、下拉刷新、滚动回弹、左滑删除、长按菜单、双击点赞、电视遥控聚焦等等在设计稿里根本不会画出来。这些“系统级行为”不在开发模式的信息范围内。开发拿到设计稿只能看到视觉样式看不到行为规则。最后他只能按系统默认行为去实现或者按自己已知的经验去猜测。猜对了皆大欢喜猜错了就是一条Bug键盘弹起来把输入框挡住了、列表滚动到末尾没有留白、下拉刷新控件样式和设计稿不匹配。每一条单看都是小问题攒在一起就变成“整体还原度差”。所以原生App的沟通不能只停留在设计稿本身必须把交互流程、系统控件差异、各种边界状态都摆上台面逐一对齐。3. 标注、评审、组件规范才是治Bug的组合拳3.1 关键标注字段和变量化很多团队做标注时习惯“全标”恨不得每个像素都加一条尺寸线。其实不在多而在关键字段是否齐全、是否结构化。一个原生页面标注里至少要有这几类信息布局约束固定尺寸、自适应、间距、安全区。视觉样式颜色、圆角、边框、阴影、透明度。文本样式字体、字号、行高、字重、最大行数、截断方式。资源不同密度切图、图标命名、加载图、占位图。状态列表normal、pressed、disabled、loading、empty、error。这些字段如果能用Figma Variables和Design Tokens来做会让开发侧映射代码省非常多的力。Figma TokeniOS实现Android实现color/surface/primaryUIColor(named: SurfacePrimary)ColorRes surfacePrimaryspacing/sm8ptConstants.spacing.smR.dimen.spacing_smtypography/title/18_boldUIFont.systemFont(ofSize: 18, weight: .bold)TextStyle(fontSize 18sp, fontWeight Bold)当设计师、开发、测试都遵循同一套Token体系时“颜色值看错”“数值抄错”这类低级Bug会大幅减少。开发模式取数也更有意义因为它取的已经是统一变量名而不是散落的裸数值。3.2 把沟通固化成评审和Checklist设计沟通不能靠口头“过一遍”必须有落点。我比较推荐“设计评审 交互走查 移交Checklist”三件套。设计评审会解决视觉方向和体验目标问题评审对象是整个页面和关键流程。交互走查会顺着用户路径把每个状态、每次点击、每个反馈都翻一遍专门找“空场景”“异常场景”“边界场景”。移交Checklist则是给开发看的确保在动手前已经把规则确认清楚。Checklist的检查项可以包括页面是否定义加载态、空态、失败态和对应的重试交互列表超长内容如何截断或扩展图片加载失败时用什么占位图暗色模式是否适配颜色有没有独立Token系统字体放大后布局是否兼容横屏、分屏、折叠屏是否支持键盘弹出时输入框如何避让返回手势、侧滑、物理返回键的行为是否确认每一页能把这些问完开发和设计之间扯皮的概率就会大幅下降。我在实操中的经验是填写Checklist本身就会逼着双方去想细节很多Bug都是在填表阶段就被“问”出来的。3.3 原生App和Web前端的几个本质差异为什么说尤其原生App开发Bug多因为原生App和Web前端的运行环境差异太大了。Web前端在一个相对标准化的浏览器环境里屏幕比例、渲染引擎、字体都是相对稳定的Figma开发模式里的CSS代码基本可以“抄作业”。但原生App面对的是碎片化设备Android上千种机型刘海屏、挖孔屏、曲面屏、折叠屏iOS也要适配不同时代的设备。系统级能力键盘、手势、通知、权限弹窗、后台回收都会影响页面状态。系统设置字体缩放、显示大小、深色模式、无障碍模式用户改了就得跟上。原生控件行为列表回收、复用、动画调度和Web的DOM渲染完全是两码事。这些差异让原生开发在设计稿还原时必须多做一层“环境适配”的翻译工作。Figma开发模式可以告诉你设计稿长什么样但不会告诉你某个缩放在某台机器上会不会触发系统的导航栏自动隐藏。这也是很多人纠结“figma和axure哪个好用”的题外话工具只是载体关键在于用工具的人有没有把交互状态和异常场景想全。Axure的交互能力更强Figma的视觉和协作体验更好但都不解决“规则没定义清楚”的问题。4. 实操怎么把开发模式用对减少还原度Bug4.1 开发模式是“数据库”不是“需求文档”我在团队里立了一条规矩Figma开发模式只用来查阅视觉参数和导出资源不承担需求定义的角色。所有业务约束、交互状态、动态规则统一落到设计说明、PRD或协作文档里并通过链接关联到对应Frame。这样设计稿页面始终是视觉设计的源头开发模式里的数据作为参考值真正的判断依据在文档里写清楚。开发看一眼是“这个数据对接开发模式”再点开文档链接就能看到“什么时候该显示空状态、超长文案怎么处理、暗黑模式用哪套Token”。这个习惯养好之后团队里不会再出现“开发按标注写结果发现需求根本不是这样”的乌龙。4.2 用组件库和Design Tokens降低偏差减少Bug最有效的手段之一是把常用组件沉淀成可在代码里直接映射的组件和Token。Figma里每个Button组件有不同状态变体normal、pressed、disabled、loading。开发侧同样维护一个对应的Button组件状态名一一对应。样式参数走Design Tokens颜色、字号、间距、圆角全部从Token里取。这样开发模式里看到的就不再是一个个孤立的数值而是一个个有名字的设计变量比如Color/Text/PrimaryFont/Title/18_BoldSpacing/Page/MarginRadius/Card/LargeShadow/Card/Default开发拿到这些变量名直接映射到Swift或Kotlin的常量定义几乎不会出错。即便设计稿后续调整了某个颜色值只需要更新Token全局联动不会再出现改了一处漏了十处的问题。4.3 实战流程一次完整还原度验收分享一下我的团队目前跑得比较顺的还原度验收流程分四个阶段开发前设计评审结束后设计师整理好Figma页面和移交Checklist开发提前把设计稿过一遍确认单位换算、切图资源、动态布局策略有问题在开发前提出。开发中开发完成主体页面后主动走查一遍视觉细节对照开发模式里的参数自查有问题先自己修修不了的记录给设计师。测试阶段测试同学按Checklist逐项验收特别关注不同机型、不同系统版本、字体放大、键盘弹起等场景Bug录入时附上复现路径和截图。上线前回归设计师做最后视觉确认重点看之前提过的问题是否全部修复同时确认资源、真机效果、性能表现都符合预期。这里顺带提一下业务里经常把story、task、Bug混为一谈导致排期和追踪混乱。我的建议很朴素Story描述用户场景和期望结果。Task是由Story拆出来的开发行为。Bug是“预期表现和实际表现不一致”的记录。每个都应该单独建卡别让Bug挂在Story下面吃灰也别让Task代替Bug去追踪缺陷。4.4 AI工具也在介入但沟通仍然不能外包热词里有一串很热闹的Figma MCP、Trae通过Figma开发、Codex辅助生成代码。这些工具确实能提升效率比如MCP协议能让AI直接读取Figma的图层结构、样式变量快速生成初版UI代码Trae这类AI编程工具也能把设计稿转成可运行的页面。但我用下来的感受是AI能帮你节省“从图层到代码”的机械劳动却替代不了“判断设计是否符合业务预期”的决策环节。AI不会问你“这个空态文案为什么是重新加载而不是返回上一页”它只会忠实还原你给它的状态。它也不会主动识别“这个图标在Android上需要矢量图而不是位图”除非你告诉它。所以用了AI工具之后人工沟通这一环反而更重要了。你要把边界、状态、叙事逻辑、业务约束这些“语义信息”喂给AI它才能产出有意义的结果。这也再次说明工具是放大价值的杠杆不是价值的替代品。5. 常见问题与排查技巧实录5.1 “标注都对手机上错位”先从哪查遇到“开发模式看好了真机上一个错位”的情况我的排查顺序是固定的现象可能原因检查方法元素大小不对单位换算错误pt/dp/px确认画板单位和开发代码用的单位图片模糊或拉伸切图倍率不够/选错资源检查2x/3x和Android各密度资源文字被裁切行高设置不一致对比Figma行高和原生实现的lineHeight局部间距忽大忽小未处理安全区或Margin检查safe area和父容器约束1px横线粗细不对半像素四舍五入问题检查layer 0.5pt/1pt在不同屏幕的渲染这个表格基本覆盖了我在原生项目里遇到的80%还原度问题。注意检查顺序很重要先看单位再看资源效率最高。5.2 “Figma生成的CSS代码原生项目里用不上”Figma开发模式里复制出来的代码片段大多数是CSS语境Web项目里确实很香但原生App就要重新翻译一遍。举几个常见的转换Figma/CSS属性iOS/SwiftAndroid/KotlincolorUIColor(hex:)Color(hex)font-size font-weightUIFont.systemFont(ofSize:weight:)Text(fontSize ..sp, fontWeight ..)box-shadowlayer.shadow*属性elevation() 或 outlineSpotShadowColorborder-radiuslayer.cornerRadiusclip RoundedCornerShapepadding/marginconstraints/UIStackViewMargin/LinearLayout params翻译的过程本质上是在做设计意图的转述中间涉及平台特性和渲染差异的适配这也是为什么“开发模式自动生成代码”在原生领域没那么好用。5.3 “来Bug了”的经典现场分享几个我实际见过的经典Bug现场大家看看自己是不是也踩过。第一个是设计稿里一根1px的横线分割线开发用UIView设置了height 1在部分高密度机型上显示成2px粗设置了0.5pt在低密度机型上又显示不出来。后来统一改用系统的hairline最小像素线才解决。这类问题不打开真机看光看Figma标注意识不到。第二个是阴影参数照抄导致不一致。设计稿里一个卡片Figma阴影值是10%透明度、y4、blur8iOS上照抄后用layer.shadowRadius实现结果视觉效果完全不对。原因是Figma的阴影模糊算法和iOS的shadowRadius计算模型不一样需要手工调整数值靠观察对齐视觉感受不能硬抄。第三个是自动布局里明明留了间距真机上一长文本就把按钮挤出去了。这就是前面说的Figma Auto Layout和原生约束语义不匹配的问题。后来我们在Constraint里给按钮加了“内容压缩阻力最高”“抗拉伸优先级最高”才算稳定。第四个是字体缺失导致的静默Bug。设计稿里用了思源黑体Figma开发模式也正常显示但开发本地没装字体模拟器里用系统默认字体渲染结果上线后真机上中文行高和字形比例都和设计稿不一致。查了半天根因是字体资源没有跟设计稿一起交付。5.4 环境类问题也来凑热闹还有一个容易被忽略的点开发环境本身的问题也会放大设计Bug的排查难度。比如有前端同学遇到的“error: cannot find native binding. npm has a bug related to optional dependencies”这类依赖安装报错在原生项目里换依赖、清缓存、重装包就能解决但它会打断开发节奏让还原度Bug的修复时间拉长。这类问题和设计交付无关属于工程师日常会踩的坑。我建议团队遇到这种环境问题单独建技术任务去处理别把它和业务Bug混在一起排期。环境稳定设计Bug的修复链路才会顺畅。毕竟你也不想修复一个圆角问题时还同时折腾半天构建工具。最后再分享一个小技巧我在实际项目里最后留下一个习惯每次设计评审结束时设计师必须输出一页“版本已知问题”清单里面写明当前设计稿还没确认的交互状态、待定文案、未覆盖的异常场景。开发拿到这份清单心里就清楚哪些地方需要预留实现哪些地方要等需求确定后再联调。这个小动作成本极低但效果非常好因为很多Bug不是“做错了”而是“双方默认了不同的前提”。把前提摊开比事后一条条解释要省心得多。工具永远在进步Figma开发模式、MCP、AI编程这些都会越来越强。但设计沟通和标注这件事本质是人和人之间关于判断的对齐。搞清楚了这一点原生App的Bug数量至少能降一个量级。