中国快递查询 China Express Tracker

强制通过浏览器自动化访问 https://www.kuaidi100.com/ 页面查询快递，并直接读取页面上的实时结果。

本 skill 的首要目标是“直接给结果，同时保证准确率”。查询链路固定为 https://www.kuaidi100.com/ 官方页面，不考虑其他接口、其他官网或其他降级方案。

兼容性目标：

• - 兼容用户直接给单号、给物流短信、给截图转写文本、给“帮我查下这个快递”这种自然语言
• 兼容 openclaw 运行在支持浏览器自动化的桌面环境
• 兼容官网查询页要求手机号后四位、验证码、滑块、人机验证等场景
• 兼容 openclaw 以自然语言执行 skill 时可能出现的推断偏差，尽量用明确约束减少自由发挥

触发时机

以下情况使用本 skill：

• - 用户提供快递单号，询问物流状态
• 用户粘贴快递短信/通知文本，要求解读
• 用户需要判断快递单号属于哪家公司
• 用户同时管理多个包裹，需要汇总状态
• 用户只提供收件信息片段、运单号片段或“SF/中通/京东到了没”这类口语化问题

总原则

• - 强制使用浏览器自动化访问 INLINECODE2
• 只以 https://www.kuaidi100.com/ 页面实时展示结果为准
• 宁可返回“不确定/暂无信息”，也不要输出高置信度的错误物流结论
• 不使用第三方免费聚合接口、快递公司官网或历史查询结果作为替代来源
• 如果页面需要人工验证，必须如实告知，不要切换到其他来源

第零步：输入规范化

在识别和查询前，先做输入规范化，提高通用性和兼容性。

规范化要求：

• - 去掉首尾空格、换行、制表符
• 保留数字和字母原文，不要擅自改写字符
• 英文字母统一视为不区分大小写，但请求时尽量保留用户原始单号
• 若文本中出现多个疑似单号，逐个提取并分别查询
• 若文本中同时出现手机号、订单号、取件码、运单号，只把最像快递单号的内容作为候选

提取规则：

• - 优先提取包含明显前缀的串，例如 SF、JD、JT、YT、YD、ZT、DS、INLINECODE11
• 其次提取长度合理的字母数字混合串
• 对纯数字串保持谨慎，不要因为看起来像单号就直接判定公司
• 用户给的是整段短信时，先提取候选单号，再打开 https://www.kuaidi100.com/ 查询，不要只根据短信语义直接编造物流状态

第一步：识别快递公司

默认策略：提取出单号后，直接在 https://www.kuaidi100.com/ 查询。公司识别只用于辅助理解结果，不作为切换查询站点的依据。

只有在以下“强特征前缀”出现时，才允许直接确定 company_code：

以下情况一律禁止直接猜公司，应优先要求用户补充公司信息，或列出多个官方查询入口供用户自行打开：

• - 纯数字单号
• 仅凭长度才能判断的单号
• 多家公司可能复用的前缀或格式
• 用户只提供了物流短信片段，没有明确单号前缀

准确率规则：

• - 不要把“12位纯数字”“13位纯数字”“10位纯数字”直接映射到任何公司
• 若用户明确指定公司名称，只把它当作辅助信息，不要改用其他站点查询
• 若无法可靠识别公司，也仍然先在 https://www.kuaidi100.com/ 页面查询

第二步：浏览器自动化查询

强制查询步骤：

1. 1. 打开 INLINECODE43
2. 将用户单号输入查询框
3. 触发查询
4. 等待页面稳定并出现该单号对应的查询结果
5. 读取页面上的快递公司、当前状态、最新时间、最近 1 到 3 条轨迹

查询要求：

• - 每次都必须重新打开或刷新 https://www.kuaidi100.com/，确保是本次实时查询
• 必须确认页面展示的单号与用户输入完全一致
• 必须确认页面结果已经更新，不是上一次搜索残留
• 若页面有弹窗、广告、悬浮层，应先关闭再读取结果
• 若需要展开时间线或滚动查看最新轨迹，应先完成这些交互

第三步：结果校验

把以下情况视为“结果不可信”，不得直接输出确定性物流结论：

• - 页面上没有出现用户输入的单号
• 页面内容与用户输入的单号或快递公司明显不匹配
• 页面只有营销内容、空白、系统繁忙、加载失败或无轨迹节点
• 页面仍停留在旧查询结果，未完成本次检索
• 页面出现验证码、滑块、手机号后四位、登录要求或其他人工验证
• 当前环境不支持浏览器自动化，无法实际完成查询

输出前校验：

• - 只有在页面明确展示本次查询的物流状态时，才输出状态摘要
• 如果页面需要手机号后四位或验证码，必须明确说“当前查询需要人工验证”
• 如果浏览器自动化不可用，必须明确说“当前环境无法完成该查询”

第四步：格式化输出

CODEBLOCK0

状态 Emoji：✅已签收 / 🚚派件中 / 📍运输中 / 📦已揽件 / ⏳暂无信息 / ⚠️异常

状态判定兼容规则：

• - 已签收、妥投、已代收、已取件 归为 INLINECODE49
• INLINECODE50、驿站取件、丰巢暂存、代收点取件 默认归为 📦 待取件，除非页面明确写明“已签收/已取件完成”
• INLINECODE55、正在派送、派送中 归为 INLINECODE58
• INLINECODE59、转运中、到达分拨中心、离开网点 归为 INLINECODE63
• INLINECODE64、已收件、快件已从寄件地发出 归为 INLINECODE67
• 无记录或 201 归为 INLINECODE69
• 退回、拒收、异常件、派件失败等归为 INLINECODE70

输出风格要求：

• - 先给结论，再给最近 1 到 3 条关键动态
• 不要把所有原始轨迹全文照抄给用户
• 用户只问“到哪了”时，优先回答当前位置和当前状态
• 用户只问“哪家快递”时，优先回答识别结果和置信依据，不必展开全部物流轨迹
• 如果查询被验证码或环境限制阻塞，只输出阻塞原因，不要伪造状态摘要

第五步：异常识别

主动检测并提醒以下情况：

• - 超时未更新：最后一条记录超过 48 小时无新动态
• 退件：context 含"退回"、"退件"、"拒收"
• 地址问题：含"地址不详"、"无法联系"、"无此人"
• 派件失败：含"派件失败"、"不在家"、"改约"
• 疑似页面读取错误：页面内容与用户单号或当前检索结果明显矛盾

第六步：多包裹汇总

用户提供多个单号时，逐一查询后汇总：

CODEBLOCK1

执行流程

CODEBLOCK2

执行约束

这是给 openclaw 使用的 skill，执行时必须遵守以下约束：

• - 强制使用浏览器自动化访问 INLINECODE71
• 不要用经验、旧结果或其他网站替代当前页面结果
• 不要把“猜测到的公司”表述成确定事实
• 不要在没有成功读取 https://www.kuaidi100.com/ 当前页面结果的情况下生成“派件中”“运输中”“已签收”等结论
• 如果已有信息不足以支持结论，应明确说“不确定”或“暂无信息”
• 如果用户手动指定了快递公司，只作为辅助理解，不切换查询站点
• 如果用户给的是模糊描述，先提取单号再查，不要跳过查询步骤直接解释
• 如果输入里有多个单号或多个包裹，不要只查第一个，除非用户明确指定只查其中一个
• 如果页面字段缺失，只输出能被页面支持的部分，不要补写未出现的信息
• 不要把“打开了页面”说成“已经查询成功”
• 如果浏览器自动化失败、无浏览器环境、页面被验证拦截或当前环境无法自动查官网，不要强行给出物流结果
• 不要把旧会话里的查询结果当作当前单号的最新结果
• 不要把其他官网、其他接口或第三方聚合结果当作当前结果

注意事项

• - 页面可能会要求手机号后四位、验证码、登录或滑块验证
• 当前 skill 不考虑其他查询路径，若浏览器自动化不可用则查询失败
• 新单号发货后通常需要 2-4 小时才有首条物流信息
• 物流短信文本只能作为提取单号的辅助信息，不应覆盖页面查询结果
• 如果 https://www.kuaidi100.com/ 页面已有明确结果，以页面结果为准