700号码保护试点：平台、运营商和商户各自负责什么

摘要

本文以工信部号码保护试点文件、两家平台的公开说明以及一份云服务接口文档为样本，区分码号核配、业务接入和具体订单通话三个层面。分析关注的是各方负责什么，以及商户怎样查验自己实际接入的服务。

样本覆盖哪三层

本文的观察时间为二〇二六年十一月十四日。政策样本包括工信部信管函〔二〇二五〕一三〇号及二〇二六年十一月十一日的批复消息。平台样本选取外卖和网约出行，因为批复列明这两类是优先探索的高频场景。外卖规则来自美团，网约出行功能描述来自滴滴安全页面。技术样本为阿里云接口目录，用于确认绑定关系可如何表达。个人信息保护法用于核对业务收集和处理个人信息的约束。反诈预警资料则用来限定前端提示的含义。样本均来自原发布方，本文没有接入这些服务发起测试订单，也无法观察不同城市、订单类型和时间段的实际覆盖。

工信部十一月公布已向十家试点企业核配七〇〇专用码号资源。这个数字的单位是获得该次批复的企业，统计时点是公告发布之日。平台、城市和订单的使用数量需要不同的数据。媒体报道中的来电场景可作为观察线索，实际采用哪种业务，应回到订单页和服务方所能提供的记录。

谁负责哪一步

<table> <thead><tr><th>层级</th><th>公开资料可确认</th><th>接入时还应问什么</th></tr></thead> <tbody> <tr><td>监管与码号</td><td>工信部公布试点、规划十五位使用号码并核配码号资源</td><td>合同主体和服务方是否对应公布名单及实际接入关系</td></tr> <tr><td>基础与应用平台</td><td>基础平台提供通信能力，应用平台按业务需求建立中间号及绑定</td><td>建立、修改、解绑以及失败通知各由哪方负责</td></tr> <tr><td>业务平台</td><td>订单内提供启用或联系入口，按业务规则处理号码有效期</td><td>哪些配送或出行场景适用，入口故障时怎样回到官方渠道</td></tr> <tr><td>商户和履约人员</td><td>根据获得的授权，在履约场景使用平台提供的联系方式</td><td>能否访问历史号码，争议时通过哪个流程补交材料</td></tr> </tbody> </table>

把参与方区分开有直接的采购价值。例如，商户发现配送员在订单结束后无法再次接通电话，先要判断是否是业务规则中的正常到期。假如订单还处于配送中，也要先检查是否发生改派、入口失效或该订单不在已接入范围。解决问题时，应向能够核对订单状态的业务平台提供订单时间、联系动作和失败提示，由平台根据责任分工定位。直接让员工反复拨打已经失效的号码，只会多留下几次失败记录。

什么叫一条有效的绑定

普通对外电话面向能够拨通的来电者。订单里的临时联络则先建立参与方、号码和业务场景之间的关系。阿里云接口目录列出的七〇〇 AXB 是一对一关系，双方分别通过中间号联系对方。目录中还列出 GXB，用号码组表达一定范围内的呼叫关系。公开目录能够说明接口所表达的能力，供应商的账户开通、具体使用范围和故障处理仍需查当期合同与接入规则。

如果同一订单由骑手甲改派给骑手乙，验证重点是改派之后谁能发起通话，以及上一条绑定何时结束。对商户来说，需要先确认平台提供的是可随时呼入的公开业务入口，还是面向一段履约流程的临时联系。把订单中间号抄进门店的常用通讯录，既可能在下一次需要时无法使用，也会让员工误以为该号码可以联系以前的顾客。

美团外卖保障规则明确提及订单内虚拟号码的有效期以及过期后的限制。滴滴安全说明则公开描述乘客和车主互相看不到真实手机号的功能。两份材料各自说明本方公开的功能。能否在某笔业务中用到七〇〇，仍应核对当期平台和订单实际显示。做行业研究时，可以比较两种场景的联系对象和结束条件，但没有依据给这两家平台排覆盖率或者保护水平的名次。

一次验收怎样留下可回查证据

第一步在确认授权的测试环境里列出最小样本。外卖至少覆盖订单创建、商户联系、骑手联系、改派、订单结束。出行则可按接单、上车前联系、取消、行程结束列出。每一步先写清预期的可见界面和联系对象，随后记录测试日期、入口、终端和结果。使用专门测试号码，避免把真实订单和实际用户的号码、地址带进验收表。

第二步给异常场景留出一条单独的记录。常见的疑问包括调用超时、号码展示但联系失败、骑手变更后仍看到原先的联系入口、电话权限未授予。一个失败可能来自应用授权、终端设置、业务状态或通信侧。验收可以从可观察的环节缩小范围，但不宜凭一张截图认定根因。实际设计时可以先规定谁接收故障报告、记录哪几个字段、什么时候交给下一层排查。这样即使当天换了值班同事，前一轮核对也能复用。

第三步检查结束动作。订单完成后在哪个界面仍能看到号码，旧号码是否可拨通，投诉或物品遗失有无订单内的重新联系入口，这些要分别问清。结束后的复联可能仍有业务目的，例如协助找回物品，但具体接触方式需要遵循平台提供的流程。出现争议时可保留必要的订单凭证，同时限制访问人员和保存范围。各企业留存依据、期限与告知义务需结合适用规则和自己的实际处理方式核对。

来电显示能回答什么

工信部对号码格式和显性标记的安排，有助于接听者理解自己遇到的是号码保护服务。本文建议把屏幕上的号码当作判断通话类型的一条线索，同时用原有订单或官方应用确认联系对象和业务。合理的履约问题通常与当前订单有关，例如确认取货位置或到达时间。如果请求转到另一笔支付、短信验证码、屏幕共享或者变更收款账户，便已超出普通订单联系所需的信息。用户可结束通话并从熟悉的应用入口回查。商户设计话术也可以尽量减少不必要的信息确认，让顾客更容易在订单页判断来电是否有关。

还有一种需要区分的情形是号码保护和企业公共联络。网站上需要稳定显示业务电话时，企业应先确认公开用途、维护人和变更方式。需要保护个人真实号码的短时会话，则要明确开始、结束和争议处理入口。两类工作都有必要评估可达性，但测试问题不同。一个关注正常营业期间能否让陌生客户联系到机构，另一个关注特定会话双方是否在约定条件下建立联系。用同一条测试脚本笼统写成“电话打通”，会漏掉最重要的业务约束。

接入决定可以分三次确认

技术团队首先用一页纸画出电话从业务平台到应用平台、再到接听人的路径，写清用户在哪一步选择启用、真实号码在哪些环节需要处理。采购和业务团队随后确认服务方、账户条件、可用场景、故障升级和退出方式。最终由实际执行团队拿两种端设备验证所需的联系动作，记录何种异常可回到订单内处理。任何一环没有明确负责人，后续遇到拨不通或号码暴露问题时都会增加定位成本。

验收表的最小交付可以是两份文件。一份写产品功能和合同里允许的范围，注明读到文档的日期。另一份写经过同意的测试记录，注明测试环境、覆盖场景和负责人。两份都应保留可核对的出处，并约定在平台改规则后何时复查。通过这种方式，项目经理可以把宣传语、技术文档和实际验证结果放到同一个决策过程里，避免在采购前过度理解一条产品介绍。

本文对监管文件、接口目录和平台规则进行对照，样本覆盖的是公开可查的规则和能力描述。上线范围、资费、通信链路表现、接听率和隐私保护成效需要另行取得服务侧数据或做经过授权的测试。当前可据本文先完成角色归属和场景验收清单，作为与技术或业务提供方沟通的起点。

可对照公开联系方式怎么分流厘清日常入口，再参考怎样核对一条招聘联系线索理解从原有入口回查身份的思路。

资料来源

工信部 2026 年试点批复，2026-11-11，10家，首批重点场景及来电标识。

工信部 2025 年试点通知，工信部信管函〔2025〕130号，角色、使用位长与码号管理。

美团外卖服务保障，2026-06-04，订单内虚拟号及到期行为。

滴滴安全说明，乘客与司机真实号码互不显示，未承诺每单采用700。

阿里云号码隐私保护接口，700 AXB及GXB接口的功能文档，开通资格另核。

个人信息保护法，最小必要、告知与已公开个人信息的处理边界。

深圳市公安局反诈预警说明，2026-10-16，预警与可疑请求的核实路径。