应统一概念模型而非统一控件外观
别名: 概念模型 · 对象身份 · 控件皮肤 · 任务结构
概念解释
跨平台真正需要一致的，是对象还是不是同一个、任务怎么拆、状态叫什么：草稿是什么、分享会带走哪些字段、已下单和已支付是不是两步。不需要一致的，是唤起这些对象的控件外观——iOS 导航栏里的返回箭头和 Android 的系统返回加顶栏，可以仍是同一条概念栈。统一皮肤（两端画成一模一样的自定义返回图标）是在错误的层上求同：用户识别的是「这还是那份草稿」，不是「返回按钮的形状和品牌手册上的一样」。
它处理的是「一致应该发生在哪一层」，不是「两端做成同一套像素会一起犯规」，也不是品牌色该铺在内容还是框架上。概念模型是产品自己的语言；控件外观是平台已经借给用户的词。
机制
人把界面当成对真实对象的操作。对象身份（这一封邮件、这一张草稿、这一笔订单）一旦在两端对不上——一端能撤回、一端变成删除，一端叫「相册」、一端叫「空间」——跨端用户会认为那是两个产品。控件怎么画并不进入这套身份核对：系统开关和品牌开关如果都表达开/关，对象模型是同一的；画成同一颗胶囊却一端是开关一端是按钮，对象模型已经裂了。
外观层交给平台，是因为那一层的「词」用户已经在系统里学过，应用再教一遍没有增量。概念层必须由产品自己教，而且只能教一套：两端如果对象边界不同，教的成本会按平台翻倍，还无法互相转移。因此正确的统一是一份对象词典加一份任务结构，外加两套平台壳；错误的统一是一份壳加两套悄悄分叉的对象。
边界
强平台绑定的能力（iOS 的系统分享扩展、Android 的意图、微信里的卡片消息）在概念上也不能强行对齐成同一个动作——硬叫成同一名称会掩盖两端实际带走的字段不同。游戏和品牌营销若本来就把控件当视觉表达，概念模型很薄，统一外观的伤害低于统一一个并不存在的对象层。无障碍名称应跟概念走（「草稿」「发送」），而不是跟皮肤走（「蓝色胶囊」）；皮肤统一反而会让读屏在两端读到无法对应系统控件类型的词。跨平台框架若把系统控件包装成同一外观，概念层仍应独立维护，不能因为壳统一了就以为对象已经统一。
怎么落地
- 先写一份两端共用的对象与任务词典（对象、状态、动作、失败分别叫什么、边界在哪），再为每个平台选系统控件来表达这些词。
- 禁止把「两端按钮长得一样」当作一致的验收标准；验收「同一对象在两端能否被认出、同一动作是否改变同一状态」。
- 平台特有的动作保持特有名称和特有出口，不要为了词典整齐而起一个两端都在撒谎的名字。
- 验证：不给截图，只把对象词典读给用过两端的人听，问「这还是不是同一个产品」。再让他们分别在两端指出「草稿」和「分享」，核对指出的是同一对象、带走的字段是否符合词典。任何一端要靠按钮形状才能认出对象，都说明统一做在了皮肤上。