技能介绍

你需要解决什么问题

当你从 CSV、表单或第三方系统把联系人推进 CRM，或者准备触发下游消息工作流时，电话号码字段通常非常混乱。同一个用户可能被写成 +86 138 1234 5678、008613812345678、(86)138-1234-5678，也可能只写了 13812345678，甚至带上分机号、空格、括号和全角字符。这类脏数据直接入库会带来几个工程问题：CRM 里出现重复联系人、短信或 WhatsApp 模板消息发送失败、营销自动化规则匹配不到正确受众，或者客服系统里的呼叫路由把号码识别成错误国家。如果下游系统要求严格的 E.164 格式，这些输入还会被数据库字段长度限制、API 参数校验或第三方消息网关直接拒绝。

这个技能如何工作

这个技能不负责电话投递、呼叫路由或营销活动编排，它只做一件事：在数据进入 CRM 或消息工作流之前，把混乱的电话号码输入清洗、校验并规范化成一个稳定的 E.164 值。

它以 libphonenumber-js 为核心库，围绕电话号码解析、国家规则校验和格式归一化三个环节展开。典型流程是：

先对输入做初步清洗，去掉空格、括号、短横线、全角符号等视觉噪音，但保留可能影响号码含义的关键信息。
根据用户所在国家、地区码或号码前缀推断国家代码，例如把 13812345678 结合 CN 上下文补成 +86 138 1234 5678。
调用 libphonenumber-js 的解析与校验能力，按对应国家的号码长度、号段规则和有效格式做验证。
如果号码可以通过校验，技能会返回标准化的 E.164 值，例如 +8613812345678；如果无法解析或明显无效，则不会产出可落库的规范化结果。
输出结果适合直接写入联系人字段、触发下游消息模板参数，或作为 CRM 导入前的预清洗步骤。

适用边界与注意点

这个技能的适用场景是数据清洗和格式规范化，不是电话外呼、短信网关调用、呼叫中心路由或营销活动编排。如果你需要真正发送消息或发起呼叫，仍需把规范化后的 E.164 号码交给下游通信服务处理。

使用时需要环境具备 Node.js 和 npm。由于原始资料未提供可自动提取的源码级安装或使用说明，建议在敏感业务流程中运行前先审查上游 libphonenumber-js 项目和技能文档。对于分机号、多号码字段、国家码缺失且无法推断的输入，仍需结合业务规则做额外判断，不能把规范化结果当作唯一数据质量兜底。