一组彼此独立的多列开关面板，只有一列全部点亮，其余停在半开位置

一、把“可用面”从一句开关改成六栏表

一家终端厂商宣布，它的设备端智能能力随一个系统测试版面向中国大陆上线，开发者可先在开发者测试版中使用，但只有手机可用，平板与电脑不在首批设备序列内，厂商明确在获得必要批准之前不会在当地的其他设备上推出。使用条件里，系统语言与语音助手语言都要设为简体中文或英语；语音助手、写作工具与视觉智能三处接入了一家第三方模型企业的模型；另有一批能力和一项图像生成能力明确不在这一批推出。把这些条件抄成一句“该地区已开放”，交付时就丢掉了全部可核对性。洹拓做同类能力开放面的登记时，第一件事是把它拆成六栏，逐栏写清判定依据从哪里来、由谁维护、变更后通知谁。

栏位 判定依据从哪里来 由谁维护 变更后通知谁
设备序列 上游公布的首批设备类型与机型系列清单 上游发布配置，本地只做镜像 资产台账与运维岗
语言 系统语言与语音助手语言两处设置都要命中 终端设置项，用户可自行改写 接入方需自测，无推送
地区 购买地区，或设备定位加账户国家地区两条件之一 第三方服务侧判定 无主动通知，靠探测发现
功能子集 逐项功能的登记状态，不是能力品牌整体 上游公告与内部清单共同维护 客户成功与售前
登记面 服务备案条目与设备进网许可信息新增条目 合规岗 法务与投标支持
第三方接入 是否自主选择开通、登录路径、数据留存条款 采购与数据安全 数据处理责任人

六栏彼此独立，任何一栏不满足都会得到“用不了”，但界面必须给出两种不同结论。这里要立一条纪律：把“未开放”和“不可用”分开。“未开放”说的是这个功能项在本市场或本批根本不承接，判定对象是功能；“不可用”说的是功能已开放，但眼前这台设备、这一次调用没满足条件，判定对象是这次请求。两者混用，运维会把产品面问题报成配置故障，客户会在合同里买到一句无法兑现的话。区分可以落到返回结构上：“未开放”返回不带重试语义的固定结论，“不可用”附带缺哪一栏的原因，允许条件补齐后重试。

二、功能子集要登记成三种状态

同一能力品牌下，功能项是分批推进的。这一批在手机上启用的是较早的一组功能集合：实时翻译，覆盖消息、电话、视频通话以及搭配无线耳机使用；照片处理，含消除、用自然语言搜索、制作回忆影片；写作工具，含校对、改写、总结文本；生成式表情；视觉智能，含提问、视觉搜索、与图片中的文字互动并生成摘要；通知的摘要、减少打扰与优先通知；邮件的优先邮件、摘要与智能回复；信息的摘要与智能回复；备忘录与电话的转写内容摘要；语音助手更强的语言理解与输入文字交流。而另有一批语音助手能力与其他智能功能不随这一批推出，还有一项图像生成功能不在当地推出。

于是至少存在三种彼此不同的登记状态：本批可用、明确不在本批、不进入本市场。三种状态要分开记、分别维护生效范围，不接受“以官方公告为准”这种写法。公告是一句话，清单是几十行，客户问的永远是其中一行。对外描述与内部清单的一致性核对，最小字段是四个：功能名、可用状态、生效范围、依据来源。依据来源要具体到是哪一次公告、哪一轮接口探测，不能只写“官方说法”。核对动作挂在发布流程上：每批上游公告落地后，把对外文案里出现的每个功能名在内部清单里找一遍，找不到的那条按缺陷处理，而不是当成笔误放过。

三、机型门槛写在机型而不是版本号上

厂商给的门槛是某个机型系列及更新机型，不是某个系统版本号。这个选择本身就是一条工程信息：端侧模型能否承载，取决于设备的算力与内存，而同一个系统版本号覆盖的设备里内存档位可以差出数倍。把门槛写成版本号，一定会出现“版本达标但装不下”这类假故障，还会让存量设备在版本号升级后被误判成合格。

据此，准入判定的正确做法是按设备能力位与机型清单双判，而不是按用户自报。能力位是设备自陈的一组硬件特征，机型清单是上游公告的白名单，判定取两者交集；用户自报、界面文案、销售话术都不进判据。尤其不要把设备名称字符串当机型判据，一次品牌改名或一次别名变更就会误伤整批设备。交付验收表里我们固定加一栏：能力位命中而机型清单未命中的样本数量。这个数不为零，说明清单与实际硬件之间正在漂移，需要向上游报差异而不是自己放宽判据。

四、语言与地区四个因子分属不同子系统

系统语言、语音助手语言、账户国家地区、设备定位，四项看着都是“设置一下”，实际分属不同子系统，读取方与生效时点都不一样。任何一项被单独改写，就会出现“界面显示可用但调用失败”的组合。

因子 归属子系统 单独被改写后的典型表现 排查次序
设备定位 定位服务，可临时关闭或偏移 时好时坏，与网络环境相关 第一
账户国家地区 账户体系，由服务侧读取 端侧功能正常，第三方接入那三处失败 第二
语音助手语言 助手独立设置项 入口仍在，助手侧功能报不可用 第三
系统语言 终端系统设置 界面文案与入口保留状态不一致 第四

排查顺序按“从最易变到最稳定”排：先看设备定位，它最容易被用户或场景临时改写，是这一格里最常见的意外源；其次看账户国家地区，因为第三方说明其服务走两条路之一，要么在该国大陆购买支持该能力的手机，要么设备定位与账户国家地区均设置为该国，两条路都得查；再次看语音助手语言，它常被漏掉，改了系统语言并不自动改助手语言；最后才动系统语言，代价最大。四因子矩阵的实际意义是：任何“只查一个设置项”的排障话术都不成立，交付文档里要把四格都写成必查项并留下读数。

五、两个登记面各自取证，第三方接入条款落成字段

这条能力此前完成了手机端侧生成式人工智能服务的备案，随后相关机型的进网许可信息中又新增了该能力与第三方模型的备案信息。这是两个登记面、两条链路、两种更新时点：面向生成式能力的安全备案落在服务与能力层面，进网许可信息里新增的条目落在设备型号层面。企业客户做合规证明时不能拿一张替代另一张。取证字段要分开列：备案主体、被备案能力名、关联的第三方模型名、信息新增所在的许可项。前三项在两个面上都有对应但口径不同，第四项只在许可信息面存在，缺了它就说不清覆盖到哪一批机型。

第三方模型接入这一栏是合同面。用户可自主选择是否开通这一集成，开通后可用平台账户或第三方应用账户登录，用户请求及生成的回复不会被该第三方用于模型训练。“不用于训练”这句话要落成三件可核验的事：

  • 承诺适用的功能范围：三处接入点是否全部覆盖，还是只覆盖文本生成而不覆盖视觉智能
  • 是否覆盖转写与图像输入：音频与图像这类非文本输入算不算“请求”，条款要写明
  • 撤回开通后已送出的数据怎么处置：删除时限、备份副本、是否保留去标识化样本

如果这条承诺只写进隐私政策正文而不写进功能说明，举证会非常困难：争议时对方只需回答“政策适用于全部服务”，你无法把承诺定位到某一个功能项上。验收时我们要求把这三个字段抄进功能说明的对应条目，并与登录路径一起存档。

六、入口短暂出现又消失，暴露的是三段控制

公开记录里有一种事故形态：一次系统更新中因软件问题，部分地区少量设备短暂下载并启用了面向其他市场的设备端模型，设置页短暂出现了相应入口，随后入口消失，厂商回应称正式推出仍取决于监管审批。这很容易被解读成文案错误，其实它暴露的是三段彼此独立的控制出现了不一致：客户端资源下载、功能开关下发、界面条件渲染。下载到的资源决定机器里有没有，开关下发决定服务侧让不让用，界面渲染决定入口画不画。三段各自判定，任何一段与另外两段不一致，都会产生“看起来已开通”的假象。

企业侧的自保动作有两条。其一，判定按能力开关的服务端读数，不按界面是否出现，界面是一个渲染结果而不是授权事实。其二，对内部批量设备做一次入口状态与开关读数的一致性抽查，样本要覆盖不同购买地区与不同账户地区的组合，抽查结论留档，作为后续争议里唯一能拿出的自证材料。这条经验反过来也约束我们自己的交付：做分地区灰度时，把“三处都命中才渲染入口”写成一条可断言的规则，让界面读取开关读数而不是自己判断，并把入口出现事件与读数变化事件写进同一张时间线，任何一处不一致在发布当天就该被发现，而不是等用户截图。

#验收清单 #分地区开放 #能力子集差异 #端侧模型备案 #第三方模型接入