美团跑腿下单 Skill#

⚠️ 输出规范：

1. 严禁向用户展示任何技术细节，包括但不限于：英文字段名、JSON 结构、命令行内容、脚本路径、技术参数。执行过程中的中间状态不展示，只展示用户需要知道的结果。

2. 只展示用户意图相关的信息：地址摘要（"从 xxx 送到 xxx"）、物品名称、费用卡片、预计时效、操作结果。费用卡片按固定模板逐行展示（见 Step 5）。

3. 所有输出必须格式化展示，严格换行：每个字段独占一行，用空行分隔。禁止将多条信息挤在一行。

4. 手机号必须真实：脱敏号码（含 ****）严禁传入下单接口，真实号码获取规则详见 Step 3。

5. 严禁在回复任何位置展示内部过程描述（开头、中间、结尾均禁止）。如"地址簿拉取成功""POI搜索到了多个结果""匹配不到地址簿""同时还需要确认""一起问""已匹配该地址"等均属内部过程，严禁出现。用户只需要看到问题、选项和结果，不需要知道后台做了什么操作。

⚠️ 强制重读：每次会话第一次触发时，必须重新读取本文件，不得依赖历史记忆。

When to Use#

帮取送、帮买、餐厅取号、医院帮忙、其他取号、帮搬装、帮扔杂物、其他帮忙。用户说出"跑腿"、"帮我送"、"帮我取"、"帮忙"等意图时触发。

When NOT to Use#

询问其他非跑腿业务场景，跨城远距离配送或者用户明确表示不下单时。

风险提示与免责声明#

本 Skill 通过开放平台接口实现跑腿下单功能。

• 调用方应确保所使用的 AI 助手已在中国大陆完成安全备案，并符合相关法律法规要求

• 调用方应审慎评估 AI 对需求的理解偏差风险，使用本人账号授权操作，确认订单预览后再提交

• 如发现异常订单或 AI 行为异常，请立即联系美团客服处理

---

场景识别与分流#

收到用户请求后，首先判断属于以下哪种场景，后续流程按对应分支执行：

• 帮取送：从 A 地取件送到 B 地，需要取件地址 + 收件地址 + 取送物品信息
• 帮买：骑手代购商品，需要购买方式 + 收件地址 + 购买物品信息
• 帮忙（以下场景统一归为帮忙）：餐厅取号、医院帮忙、其他取号、帮搬装、帮扔杂物、其他帮忙。只需一个地址，不涉及物品信息

---

安全门控#

⚠️ 跑腿下单是 真实消费、不可逆操作：

1. 强制两步确认：先预览展示费用卡片，等用户明确回复"确认"后才提交。

2. 信息完整性（按场景区分必填项）：

   • 帮取送：取件地址、收件地址、取件电话、收件电话、物品信息（需查 params.md 品类表映射 goodTypes/goodTypeNames/goodsWeight）（5 项）
   • 帮买：送达地址 + 电话 + 购买方式（指定购买地址 or 就近购买）+ 物品信息（ --purchase-detail）（4 项）
   • 帮忙：帮忙地址 + 电话（2 项）

缺失任何必填项 不允许询价和提单。电话获取规则详见 Step 3。

1. 金额异常拦截：费用 > 100 元时需额外向用户确认。

---

工作流程#

Step 0：鉴权检查（自包含授权）

本 Skill 内置了 pt-passport 授权工具，无需依赖外部 Skill。

0.1 安装 pt-passport CLI（每次会话执行一次）

bash

bash "$(dirname "$0")/../passport-auth/scripts/install.sh"

若无法定位路径，用 glob_file_search 搜索 passport-auth/scripts/install.sh 找到绝对路径后执行。安装成功或已是最新则继续。

0.2 检查缓存的授权 Token

bash

pt-passport get-token --client_id ac76c22d257c4c6d9164719eea64ed4b > /dev/null 2>&1
echo $?

• 退出码 0（缓存命中）→ 取出 Token 执行 login 验证： bash

  TOKEN=$(pt-passport get-token --client_id ac76c22d257c4c6d9164719eea64ed4b)
  MCP_ACCESS_TOKEN="$TOKEN" sh run.sh login
  
  

  • 已登录 → 直接进入 Step 1
  • AUTH_FAILED → 走下方授权流程

• 退出码 1（无缓存）→ 走下方授权流程

0.3 发起授权（无缓存或缓存失效时）

bash

pt-passport auth get-code --client_id ac76c22d257c4c6d9164719eea64ed4b

解析输出：

• AUTH_LINK: <url> → 生成二维码并展示给用户： bash

  bash "<SKILL_DIR>/passport-auth/scripts/qrcode-image.sh" "<AUTH_LINK>" "ac76c22d257c4c6d9164719eea64ed4b"
  
  

  读取输出的 QRCODE_IMAGE:<path> 图片路径，用 ![二维码](<path>) 内联渲染。

  按以下格式展示授权信息：

  📱 请用美团 App 扫码授权，或点击链接确认：

  👉 点击授权

  ⏱ 链接有效期 10 分钟，授权完成后告诉我一声。

  ⚠️ 只展示 AUTH_LINK，不要展示 DIRECT_AUTH_LINK。

  展示完链接后等待用户确认授权，在此期间不执行任何需要 Token 的操作（包括拉取地址簿、POI 搜索等），不追问业务信息（包括购买地址、收件地址、物品信息等）。

• 输出 Token: 开头 → 授权已有效，取出 Token 继续

• 输出 ❌ → 按错误码提示用户

0.4 用户确认授权后获取 Token

当用户回复"已授权"或表示已完成扫码后，执行 poll-token 获取并缓存 Token（用户已授权，会立即返回）：

bash

pt-passport auth poll-token --client_id ac76c22d257c4c6d9164719eea64ed4b

成功后取出 Token 验证登录：

bash

TOKEN=$(pt-passport get-token --client_id ac76c22d257c4c6d9164719eea64ed4b)
MCP_ACCESS_TOKEN="$TOKEN" sh run.sh login

• 已登录 → 进入 Step 1
• AUTH_FAILED → 提示用户重新扫码授权

⚠️ Token 安全：严禁将 Token 输出到回复正文、日志或任何用户可见位置，仅在命令执行时内存中使用。

⚠️ 后续所有需要鉴权的命令，都需要将 Token 作为 MCP_ACCESS_TOKEN 环境变量传入。

Step 1：信息预收集（静默，不等用户回复）

从对话中提取已知信息（场景/物品/地址），判断场景分流。 登录确认后 直接进入 Step 2， 严禁 在登录检查前追问用户任何信息。

Step 2：拉取地址簿

登录确认后立即拉取地址簿。

• 用户已提到所有必要地址 → 地址簿模糊匹配/POI 搜索确认，不展示地址簿列表
• 用户提到部分地址 → 已提到的地址直接匹配，未提到的地址展示地址簿让用户选择
• 用户未提地址 → 按最近使用时间展示前 3 条，先问后列，格式：

text

请问{场景动作}？以下是你最近使用的地址簿，可以直接说序号或关键词使用对应地址，也可以直接告诉我新的地址：

① 地址1-门牌号1 　　姓名 · 123****4567

② 地址2-门牌号2 　　姓名 · 134****6789

③ 地址3-门牌号3 　　姓名 · 135****7890

⚠️ 地址簿固定展示 3 条，底部追加一行提示「还有 {总数-3} 个更多地址，说关键词即可」，用户需要其他地址时直接说关键词。

{场景动作} 根据场景替换：帮买用"骑手买{物品}送达哪个地址"，帮取送用"从哪里取件、送到哪里"（用户已说一个地址时：已说收件 → "从哪里取件"，已说取件 → "送到哪里"），帮忙用"骑手去哪里帮忙"。

⚠️ 严禁向用户暴露内部场景判断过程（如"搬冰箱属于帮忙场景"等），直接问用户地址即可。

⚠️ 帮取送部分地址处理：用户只说了一个地址时（如"帮我送文件到融新科技中心"），先匹配已提到的地址，再只针对缺失的地址展示地址簿。问法调整为：已说收件地址 → "请问从哪里取件？"；已说取件地址 → "请问送到哪里？"。不要把已确认的地址再问一遍。

⚠️ 帮买部分地址处理：用户已说送达地址时（如"帮买猫粮送到融新"），直接匹配，不展示地址簿，紧接着问购买方式。

⚠️ 帮忙部分地址处理：用户已说帮忙地址时（如"帮我搬冰箱到朝来"），直接匹配，不展示地址簿，直接进入预览。

⚠️ 地址列表每条独占一行，地址与联系人之间用全角空格分隔，不堆砌多地址到一行。

Step 3：地址确认

• 选序号 → 使用地址簿的坐标、地址、门牌号、姓名等信息，跳过 POI 搜索
• 说关键词 → 地址簿模糊匹配，匹配不到才调用 POI 搜索
• 新地址 → 调用 POI 搜索
• 用户在任意时刻明确说了取件人或收件人电话 → 覆盖已有电话，使用用户指定的
• 两个地址均需 POI 搜索时 → 并行发起 两条搜索
• 两个地址都从地址簿选择时 → 并行发起 两条 get_address_info

⚠️ 电话获取规则（默认不主动询问电话，自动从地址簿取最近使用的真实号码）：

1. 用户明确指定的真实电话 → 使用用户指定的
2. 地址簿选序号 → 调用 get_address_info --address-id 获取真实号码
3. 新地址场景 → 从地址簿取最近使用的地址调 get_address_info 获取真实号码
4. get_address_info 返回的号码仍含 **** → 才向用户追问
5. 地址簿为空 → 向用户询问手机号

严禁主动询问电话，用户没说就默认取地址簿最近使用的真实号码。帮取送场景中取件人和收件人的电话都需要按上述规则获取，不主动追问。

帮取送场景：需要取件地址 + 收件地址，两个地址都确认后进入 Step 4。

⚠️ 取件地址和收件地址可以相同，用户确认后直接使用， 严禁质疑（如"取件和收件地址一样哦，确定吗？"）。

帮买场景：先确认收件地址，再询问购买方式：

• 若用户已提供购买地址 → 使用该地址
• 若用户未提供 → 询问："请问有指定地址购买还是骑手就近购买？"

帮忙场景：只需要一个地址（帮忙地址），不要问"从哪搬到哪"，只问"去哪里帮忙"。取件地址和收件地址均填该地址， 不向用户说明这个逻辑。

Step 4：物品信息与参数构造

帮取送场景：

• Step 1 已收集物品信息 → 直接使用
• 用户有模糊描述（如"一些东西"、"食物"）→ 直接根据描述匹配最接近的品类，无法匹配的按"其他"处理， 不追问
• 完全没有任何物品信息 → 追问："请问需要帮您送什么东西？"
• 根据物品类型查阅 references/params.md 得到 goodTypes/goodTypeNames/goodsWeight 及服务类型参数

帮买场景：

• Step 1 已收集购买物品 → 直接使用，不需要查阅物品类型，整理记录即可
• 未收集 → 追问："请问需要帮您购买什么物品？"

帮忙场景：

• 不询问、不收集、不展示任何物品信息
• 将用户描述的帮忙内容（如"帮扔垃圾"、"帮取号"等）填入备注字段，让骑手了解具体需求
• 直接进入 Step 5

Step 5：预览 → 确认 → 提交

第一步：调用 delivery_preview 预览（只展示费用，不提交）

帮取送场景需并行询价两次：

• --service-type 1003（普通送）→ 获取普通送的费用、时效
• --service-type 4033（1对1急送）→ 获取 1v1 急送的费用、时效

两次询价返回各自独立的 orderToken、 _deliveryFee、 estimateTime。展示时以普通送完整信息为主，底部追加 1v1 急送对比行（使用两次结果的差值）。用户确认时按所选服务提交：默认普通送；用户选 1v1 急送（如回复"要急送""用1v1"）则用 4033 那次询价返回的 orderToken/ _deliveryFee 提交，不得用普通送的 token。

帮买场景 单次询价： --business-type 2 + --business-type-tag（指定购买地址传 0，就近购买传 1 且 --sender 与 --recipient 同址）+ --purchase-detail，不传 --service-type。 帮忙场景 单次询价，固定传 --service-type 4033。完整参数说明和示例见 references/commands.md。

从接口返回结果中提取实际值，按以下模板逐行展示。 所有字段的值必须来自预览接口的实际返回，严禁使用示例值或硬编码值。

⚠️ 预览返回的 orderToken、 _deliveryFee、 _previewTotal、 _couponViewId 需要保存，用户确认后提交时必传。 _couponViewId 已经过 URL 编码，提单时直接使用即可。

⚠️ 如果 delivery_preview 返回错误码，查阅 references/errors.md 中对应错误码的处理方式并执行。

预览返回的字段说明： serviceType =服务类型， deliveryServiceType =配送服务类型（如 1对1急送/普通送，有值时展示）， senderAddress =取件地址， senderPhone =取件电话， recipientAddress =收件地址， recipientName =收件人， recipientPhone =收件电话， goodsName =物品名称， distance =距离， feeDisplay =配送费展示， estimateTime =预计时效， feeDetails =费用明细。

---

帮取送 预览模板#

帮取送默认展示普通送完整信息，底部追加 1v1 急送对比行。询价两次（service-type 1003 + 4033），使用两次结果差值填充对比行。

🛵 服务类型 {serviceType}

📦 取件地址 {senderAddress} · {senderPhone}

🏠 收件地址 {recipientAddress} · {recipientPhone}

🎁 物品 {goodsName}

📝 备注要求 {简要概括用户要求}

📍 距离 {distance}

💰 配送费 {feeDisplay}

🕐 预计时效 {estimateTime}

---

⚡ 【更快更安心】 还可以选择 1v1 急送，预计快 {普通送时效分钟数 - 1v1时效分钟数} 分钟送达，配送费 {1v1配送费} 元

请确认信息，帮你下单吗？

帮买 预览模板#

🛵 服务类型 {serviceType}

🏪 购买地址 {businessTypeTag=0时展示 senderAddress；businessTypeTag=1时展示"就近购买"}

🏠 收件地址 {recipientAddress} · {recipientPhone}

🛍️ 物品 {purchaseGoodDetail，即 --purchase-detail 传入的值（预览响应不回传此字段，取自本地记录的购买需求）}

📝 备注要求 {简要概括用户要求}

📍 距离 {distance}（仅 businessTypeTag=0 时展示，就近购买时不展示此行）

💰 配送费 {feeDisplay}

🕐 预计时效 {estimateTime}

---

帮忙 预览模板#

（适用于：餐厅取号、医院帮忙、其他取号、帮搬装、帮扔杂物、其他帮忙）

⚠️ 帮忙场景 不展示配送方式（如"1对1急送"），只展示服务类型名称。

🛵 服务类型 {serviceType}

📍 帮忙地址 {senderAddress} · {senderPhone}

📝 备注要求 {简要概括用户要求}

💰 帮忙服务费用 {feeDisplay}

🕐 预计时效 {estimateTime}（展示时将"送达"替换为"完成帮忙"）

---

⚠️ 帮忙场景 不展示物品信息（🛍️ 行），改为展示「备注要求」。

「备注要求」展示规则：帮搬装写具体搬运物品（如"搬冰箱"），其他帮忙场景简要总结用户需求。如果服务类型已能概括用户需求（如"餐厅取号"本身已明确），则 不展示 备注要求行。

⚠️ 优惠券条件展示：

• 无优惠券时（ _couponViewId 为空）：预览正常展示 💰 配送费 {feeDisplay}，不提优惠券。

• 有优惠券时（ _couponViewId 非空， _deliveryFee ≠ _previewTotal）：

  • 配送费行展示： 💰 配送费 {_previewTotal} 元（已用红包减免 {_deliveryFee - _previewTotal} 元）
  • 不展示 feeDetails 费用明细
  • 预览后追加一句： 帮你使用红包优惠了 {_deliveryFee - _previewTotal} 元！

帮取送预览后追加 1v1 急送对比行，然后统一询问： 请确认信息，帮你下单吗？

帮买和帮忙预览后直接问： 确认下单吗？

⚠️ 确认判定规则：只有用户明确回复"确认""下单""好的""可以"等确认意图时才提交订单。用户回复的其他内容（如"放到前台就行""别按门铃""放门口"等配送要求）是 追加备注，不是确认下单。收到追加备注后：填入 --remark 参数，重新询问 确认下单吗？，严禁直接提交。

第二步：用户确认后调用 submit_order 提交。必须传入预览返回的 orderToken、 _deliveryFee（配送费原价）、 _previewTotal（优惠后实付金额），以及 _couponViewId（如有优惠券，已 URL 编码可直接使用）。所有地址、物品参数必须与预览时完全一致，不得修改任何参数。 帮买场景下 --purchase-detail 必须传入（与询价时一致），否则骑手无法获知购买需求。 帮取送和帮忙场景下 --service-type 必须传入（与询价时一致：帮取送 1003/4033，用户选 1v1 急送时用 4033 询价的 token 和费用提交，帮忙固定 4033，帮买不传）。如有追加备注，通过 --remark 参数传入。

⚠️ 如果 submit_order 返回错误码，查阅 references/errors.md 中对应错误码的处理方式并执行。

下单成功后， submit_order 返回结果中包含 orderId、 tradeNo、 payToken（如接口有返回），需保存这些字段用于后续支付流程。

下单成功后直接进入 Step 6 支付引导， 不向用户展示订单号。

---

Step 6：支付引导（H5 收银台）#

下单成功后，引导用户通过收银台完成支付。 submit_order 返回的 orderId、 tradeNo、 payToken 用于构造收银台链接。

第一步：生成支付链接

调用 get_pay_url 生成收银台支付链接：

bash

MCP_ACCESS_TOKEN="$TOKEN" sh run.sh get_pay_url \
  --trade-no "${tradeNo}" \
  --pay-token "${payToken}" \
  --order-id "${orderId}"

返回结果包含两个链接：

• mobilePayUrl：移动端 H5 收银台（支持美团支付、微信支付、支付宝）
• pcPayUrl：PC 端收银台（支持微信扫码、支付宝、外卡支付）

第二步：发送支付链接（登录链接随附，条件引导）

链接本身有效（ get_pay_url 已成功返回），登录态判断交给用户点击时的真实页面，不做任何预验证。同一条消息内发送双支付链接 + 登录链接 + 条件引导：

text

请在 15 分钟内点击链接完成支付，支付成功后就会有骑手接单啦：

📱 [点击支付]({mobilePayUrl})

💻 [点击支付]({pcPayUrl})

如果是首次支付或提示登录失效，请先点击下方链接，登录收银台后再次点击上方支付链接（登录后关闭页面即可）：

🔗 [登录收银台](https://passport.meituan.com/useraccount/ilogin)

支付后可以随时找我查询订单状态哦～

第三步：对话兜底

用户反馈登录失败或支付页面有问题（要登录/打不开/登录后仍提示失效/支付方式不可用）→ 不质疑用户，按以下格式引导先登录再点支付链接：

text

遇到登录或页面问题的话，请先点击下方链接完成登录（登录后关闭页面即可）：

🔗 [登录收银台](https://passport.meituan.com/useraccount/ilogin)

登录后请再次点击下方支付链接完成支付，原链接直接可用～

📱 [点击支付]({mobilePayUrl})

💻 [点击支付]({pcPayUrl})

支付后可以随时找我查询订单状态哦～

⚠️ 三条规则：

1. 登录链接始终随支付链接一并发送，用户点击时按页面实际情况自助判断是否需要。
2. 用户登录后原支付链接直接可用，无需重新生成。
3. 只发收银台链接，严禁引导去美团 App 支付；链接用 Markdown 超链接格式，严禁裸露 URL。手机端和电脑端收银台链接始终成对发送；移动端收银台不支持电脑端支付，PC 端收银台不支持手机端支付，因此两案都发。

---

Step 7：订单状态查询#

用户可随时询问订单进度，调用 get_order_status 查询：

bash

MCP_ACCESS_TOKEN="$TOKEN" sh run.sh get_order_status \
  --order-id "${orderId}"

返回结果中 order.orderStatus.text 为订单状态文本， order.auditStatus.text 为审核状态文本。

严格规则： 只展示接口返回的状态字段和文本， 严禁自行推测或添加接口未返回的信息（如接口未返回"支付状态"，不得推断用户是否已支付）。

取消订单引导：

当前 skill 不支持取消订单命令。当用户要求取消订单时，引导用户手动取消：

text

如果你想取消订单，请打开美团App或跑腿微信小程序 → 订单列表 → 找到这笔{物品}订单 → 点击取消。

---

详细参考文档#

• references/commands.md — 所有命令及参数
• references/params.md — 地址、物品、业务类型参数参考
• references/errors.md — 错误码与异常处理