周一早会产品把新一版 Axure 原型图拖进群里标注得相当细首页轮播、分类入口、个人中心、一个悬浮的客服球。前端同学看了一眼第一句话不是“这个交互怎么做”而是“这些 px 是按什么基准标的后面要是用 mpx 出小程序是不是还得再换算一遍”会议室安静了两秒。这不是段子。我见过太多团队原型图画得越精美开发落地时反而越容易返工。原因不是美工不好而是“原型”和“跑起来的代码”之间藏着一整条翻译链单位换算、状态补全、组件划分、异常兜底。谁先意识到这条链的存在谁的流程就是稳的。标题里那句“勇夺双金”与其当成某个奖项不如理解成两块真正的金牌一块属于原型层——把单位、状态、交互边界定稳一块属于实现层——用 mpx 这类增强型小程序框架把原型稳定翻译成可运行的小程序。两个都稳工作流才能谈得上如鱼得水。1. 原型不是一张高保真图片而是一份交互契约1.1 为什么很多原型图到最后只是“一张图片”很多团队对原型的理解是“提前画好的界面”。于是评估原型好坏的标准变成了“像不像最终产品”。Axure 拉一堆组件、AI 工具一键生成、再套一个手机壳模板视觉上很唬人。但产品评审会一旦开起来大家讨论的永远是“这个按钮应该大一点”“那个颜色不够突出”而不是“库存不足时这个页面到底怎么提示”。这说明原型被当成了 UI 图而不是交互契约。原型的核心价值是在写代码之前把业务假设验证一遍。这是它在产品研发流程里不可替代的位置。WMS 系统原型图就是一个很典型的例子入库、出库、盘点、库存调整这么多流程真正要紧的不是界面漂不漂亮而是每一步操作之后系统把状态改成什么、给操作员什么样的反馈、哪些人有哪些权限。可信数据空间这类偏企业级的产品原型里最值钱的反而是那些看不见的东西数据权限边界、审批流、审计记录、异常提示。这些画清楚开发才不会“自由发挥”。用一个硬件领域的类比FPGA 原型验证就是在芯片流片之前先把 RTL 设计放到 FPGA 上跑一遍用便宜得多的手段提前暴露设计问题。产品原型也是同一个思路——用最低成本把“设计上的不确定性”提前抖出来而不是等到代码写完、上线之后才发现流程是断的。原型阶段多花一天开发阶段大概率能省三四天。1.2 工具选择别被“AI 一键生成”带偏市面上原型工具很多Axure 依然是做高保真交互的常青树轻量化的在线工具适合快速验证AI 原型设计工具这两年也冒出来不少能根据文字描述直接生成页面。经常有人问“AI 输出原型能不能直接导出 Axure 格式”——这取决于具体工具的导出链路和团队的协作方式别指望 AI 能替代人的判断。我的建议是先用一个最低标准筛选工具团队能不能在同一个原型上留注释原型能不能导出清晰的说明文档版本迭代之后历史版本能不能找回来这三个问题比“能不能一键生成”重要得多。网上能下载到一堆“Axure 手机原型”模板但直接套模板最大的坏处是你只拿到了界面壳没有拿到里面的状态逻辑。而那份状态逻辑才是原型的本体。工具是手段判断力才是关键。AI 能帮你把一张页面快速拼出来但“这个流程在什么条件下会断”这件事仍然需要懂业务的人把它定义清楚。2. 从 PX 到 PT 再到 rpx单位不统一的坑是原型链上第一个雷2.1 同一个 10在不同端里不是同一个 10先说道理再说操作。PX像素是屏幕上最小的物理显示单位。PT 是苹果在设计坐标系里用的逻辑点一个 PT 在不同屏幕密度下对应不同数量的物理像素。Android 那边用 DP/DIP逻辑类似。微信小程序又搞了一套 rpx以 750rpx 等于屏幕宽度为基准一套设计稿往不同屏宽上套。也就是说你原型里随手写的“10px”在 iOS、Android、小程序里含义完全不同。最常见的换算场景是“px 转 pt”。以 iPhone 6/7/8 那代机型为例逻辑宽度是 375pt物理像素宽度是 750px也就是 2x视觉上 1pt 等于 2px。到了 3x 的机型1pt 就是 3px。所以“设计稿里标的 10px 在手机上到底多大”必须先问一句设计稿的基准宽度是多少目标设备的倍率是多少脱离这两个前提去谈 px等于没谈。单位所属阵营一句话理解典型基准px物理屏幕最小物理像素点不同设备不同ptiOS 设计逻辑点与倍率无关iPhone 375pt 宽dp/dipAndroid 平台密度无关像素360dp 常见基准rpx微信小程序750rpx 平铺整个屏幕宽度设计稿按 750px 出看到这里你就明白为什么开发接到带 px 标注的原型会先愣一下不是看不懂而是不知道这套 px 是按哪个基准写的。单位问题不是开发的事是原型阶段就该定下来的事。2.2 悬浮窗口、弹层、边框细节里的单位陷阱“悬浮窗口一般设多少 px”这类问题没有标准答案真正决定答案的是你的基准宽度、设计倍率和交互可用性。举个例子。设计稿按 750px 宽度出悬浮球直径标 96px那么在小程序里用 rpx 就直接写 96rpx因为它天然按 750 等分。但如果设计稿是 375pt 逻辑宽度而开发在 Android 设备上按 dp 做又要换算一遍。最稳的做法是团队里只允许存在一套基准比如约定“设计稿统一 750px 宽”小程序侧直接转 rpxiOS 侧按 2x 逻辑宽转 ptAndroid 侧按 360dp 的常见基准适当缩放。规则一旦定死开发就不需要每次重新猜。还有一类细节特别容易踩坑边框和分割线。1px 边框在 2x 屏幕上要画成 0.5pt 才不会显得发虚在小程序里通常用更细的单位或 transform 缩放处理。悬浮窗的层级、点击热区、滑动冲突也都是原型里不画清楚、开发就得现场发挥的地方。这些问题看着小但一个页面上出现十处观感就会差一大截。2.3 在原型阶段就立好“设计基线”单位换算不是开发拿着计算器现场算而是在原型阶段就形成一套约定。我建议至少做三件事定死基准宽度全团队统一一个设计稿宽度比如 750px 或 375pt写进原型说明的首页。标注带单位原型里的尺寸、字号、间距都要写“数值单位”不要只写数字。把常用值变成 token颜色、字号、圆角、间距抽成一组命名变量原型标注引用 token 而不是裸数值。Axure 里可以通过全局变量、样式模板把这些约束固化下来。这一步做扎实开发拿到原型时手里的信息就是“可直接翻译的输入”而不是“需要猜的草稿”。所谓“稳如老狗的原型”本质上就是把这种不确定性提前拆干净。3. 原型链与状态补全能点通不等于能用3.1 借 JS 原型链理解“原型”为什么必须完整前端同学对原型链都不陌生一个对象通过__proto__向上查找属性和方法链路越完整行为越可靠。产品原型其实也一样——你给页面补的状态“方法”越齐全它进入开发后的行为才越稳定。很多原型只画了快乐路径用户打开页面、看到数据、点击按钮、流程走完。加载中呢空数据呢接口超时呢权限不足呢按钮被连点两次呢这些状态没画开发就只能自己脑补。结果就是同一个“列表页”不同开发写出来的空态、报错、防重复提交逻辑都不一样。这不是开发偷懒是输入不完整。原型链不完整对象调用方法会报错产品原型不完整开发实现就会“各自发明”。3.2 一份合格原型至少要把五类状态画全状态原型里要体现开发要知道正常态完整布局、数据、交互主流程怎么走空数据态空列表、无搜索结果的提示文案、占位图、下一步入口加载态骨架屏、loading 样式加载时机、失败重试错误态接口失败、提交失败的提示错误码、重试逻辑、兜底页面边界态超长文本、极窄屏、权限不足截断规则、溢出处理、禁用状态一个简单判断标准如果原型评审会上你只能演示“点击之后页面变好”这个方向那异常方向大概率没人聊过。把这些状态补全看起来是画图工作量变大了实际上是提前把开发期间最大的返工源头拆掉了。3.3 企业级系统尤其要把“不能怎样”画清楚WMS、可信数据空间这类系统字段多、流程长、权限重原型的重点早就不是 UI 好看而是规则明确。举个例子一张入库单同时被两个人打开一个人改完提交另一个人再提交会发生什么这种并发问题产品原型里如果能用一条提示规则定义清楚比如“单据已被他人修改请刷新后重试”研发侧就不会各自发明一套方案。这也解释了为什么“产品原型设计文档”在企业项目里比原型图本身更重要。图负责表达界面文档负责表达规则。两者缺一开发都得猜。做企业级系统的团队我建议把“异常流评审”固定成原型评审会的必选项而不是想起来才补。4. 用 mpx 把原型翻译成小程序第二块金牌在实现层4.1 mpx 解决的是“一套逻辑多处运行”的重复劳动现在聊实现层。mpx 是一个面向小程序场景的增强型跨端框架这类框架的核心目标不是把小程序变成网页 H5而是让你用一套业务代码输出到多个小程序平台同时尽量保留小程序原生能力和体验。为什么团队会选这类框架最直接的理由是重复劳动太痛了。微信小程序来一套支付宝小程序再来一套页面逻辑大部分一样却要维护两份代码、改两遍 bug、对齐两套发布流程。mpx 这类框架做的事情就是把“多份代码”压缩成“一份代码 构建配置”。当然选择框架是要付代价的引入构建链、学习框架约定、依赖社区维护。所以它不是“所有团队都该上”的银弹而是“多端需求真的存在、团队有基础工程能力”时的合理选项。如果只做一个平台的一次性活动页原生小程序更省事。4.2 从原型到 mpx一种可复用的映射方法拿到一份状态完整的原型怎么翻译成 mpx 代码我一般按四步走页面映射原型里的每一个页面对应到小程序的一个页面路由跳转关系写成页面路径配置。组件映射原型里出现超过一次的区块——悬浮球、卡片、弹层、列表项——抽成自定义组件。状态映射原型里跨页面共享的信息登录态、筛选条件、购物车放进全局 store只属于页面的状态留在页面内部。事件映射原型的点击、滑动、下拉刷新对应到页面或组件的事件方法。这个顺序的价值在于先拆边界再写代码。你写出来的不是一堆页面而是一个“页面组装组件、组件消费状态”的结构化应用。原型画得好不好在这个步骤里会直接体现——状态都补全了的原型映射起来基本不费劲只画了快乐路径的原型到这里就开始各种“我也不知道这里该怎么处理”。4.3 一个悬浮球的落地示例原型里最常见的悬浮元素就是“返回顶部 客服”的悬浮球。用小程序的方式落地核心是三点定位、尺寸、层级。示意代码具体语法以你选用的框架版本和平台文档为准view classfloat-ball bind:taponFloatTap text classfloat-iconTOP/text /view.float-ball { position: fixed; right: 32rpx; bottom: 120rpx; width: 96rpx; height: 96rpx; border-radius: 50%; background: #1677ff; color: #fff; z-index: 100; display: flex; align-items: center; justify-content: center; }对应的事件方法里判断当前页面滚动位置、执行回到顶部或唤起客服的调用。这里的单位用的是 rpx因为设计稿按 750px 出不用再做二次换算。悬浮球的点击热区建议不小于 88rpx保证手指好点。别小看这个悬浮球它的层级、滚动冲突、页面切换时的显隐逻辑都是原型里最容易漏、实现时最容易出 bug 的点。注意上面的代码是示意结构不是可以直接复制的完整组件。真正的 mpx 项目还要考虑组件注册、样式隔离和平台差异落地方案务必以官方文档和你的运行环境为准。4.4 为什么“稳”比“能跑”更重要mpx 这类框架真正的价值不是让第一个页面跑起来而是让第十个、第五十个页面依然跑得稳。稳定来自几个前提依赖版本锁得住构建链路可重复组件边界清楚改一个页面不炸另一个页面状态管理有约定跨页通信不靠全局变量满天飞日志、埋点、异常上报在项目初期就接上。如果只是 demo 级验证默认配置通常够用。但要放进真实业务就要把版本管理、权限控制、发布流程、监控这些工程化拼图一块块补上。这也是我一直说的原型稳、框架稳最后还要工程流程稳三步缺一不可。5. 踩坑清单与排查链路问题先从输入查起5.1 现象一原型看着没问题实现出来对不上这种问题先不要急着改代码按顺序排查看单位原型里的 px 是按什么基准标的和实现单位是否一致看状态空数据、加载、异常这些状态原型里有没有定义开发是不是在自由发挥看交互细节悬浮窗的层级、点击热区、滑动冲突原型里有没有明确大多数“实现和原型不符”根因不是前端不行而是输入缺了一角。直接从代码层找原因容易修完一个又一个最后发现是源头就没定清楚。5.2 现象二mpx 项目编译或运行异常如果 mpx 项目本身出问题我建议按这个顺序查先看报错信息本身。是编译期的模块找不到、语法不支持还是运行期的 API 不存在、组件未注册再查环境。Node 版本、框架版本、构建配置、目标平台这些是否匹配很多奇怪问题源于“本机没问题CI 上挂了”。查项目结构。页面路径有没有写进配置组件有没有注册样式隔离有没有导致样式丢失最后查平台容器限制。小程序对包体大小、API 兼容、webview 能力都有硬约束框架能帮你写业务但平台边界绕不开。排查层关键问题常见动作现象报错、白屏、样式错乱、交互失效收集完整报错和复现路径环境版本、系统、构建链是否一致锁定依赖版本对比可运行环境配置页面、组件、路由是否注册检查 app.json / 项目配置代码逻辑、数据流、事件绑定从入口到组件逐层定位平台包体、API、容器限制查阅官方平台约束文档排查这件事最怕乱试。先确定是哪一层坏了再决定修哪里。顺序反了往往是越改越乱。5.3 给自己留一张三层验收清单我习惯在项目上线前过一遍三层验收输入层原型标注完整、单位统一、状态补全工程层构建通过、日志正常、异常有兜底验收层真机不同屏幕密度下核对布局特别是悬浮窗、弹层、边框这类细节。这张清单不是给别人看的是给自己兜底的。原型再好最终要经得起真机这一关。原型阶段的“稳”只有通过真机验收才真正转化成了用户体验的“稳”。6. 把一次幸运沉淀成一套可复用流程6.1 一个四步流程从原型到稳定上线把前面所有内容收拢一下就是四步定基线约定设计稿宽度、单位体系、命名 token画全状态正常、空数据、加载、错误、边界全画出定组件与单位高频区块组件化标注统一带单位用框架翻译mpx 或同类框架按页面、组件、状态、事件映射。每一步都有明确产出物基线是一份团队约定文档状态是一组原型页面组件是一套组件库最后是能跑、能发布、能监控的小程序工程。步骤产出物验收标准定基线设计规范文档团队能说出通用单位画全状态完整原型异常态不靠脑补定组件与单位组件库、设计 token同一元素只维护一处框架翻译小程序工程真机验收通过这套流程最大的好处是让“从原型到上线”这件事从一次性的经验变成可复制的方法。第二个需求来的时候你不需要重新踩一遍第一个需求的坑。6.2 这套方法的适用边界这套流程适合什么样的团队你在做小程序而且有多端需求或潜在多端需求团队规模不大产品和开发能坐在一起把规范定下来原型迭代频繁希望减少“改图→改码”的沟通损耗。不适合什么样的团队只做单一平台、一次性活动页直接用原生小程序更省事团队没有任何工程化基础连基本构建链都没有先别急着上跨端框架产品重度依赖某些平台的私有能力框架抽象会带来额外兼容成本。工具是服务于业务的。mpx 也好Axure 也好AI 原型工具也好都只是链路里的一环。真正决定流程稳不稳的是团队愿不愿意在项目早期把规范、状态、单位、边界这些“看不见的地方”定下来。6.3 回到开头那句话回到文章开头那个周一早会。如果团队已经把原型基线定好、状态画全、单位统一