Metadata

name: MT-Paotui-For-Client
description: 美团跑腿下单助手。支持场景：① 帮取送（A地取件送到B地，支持品类：餐饮、文件、生鲜、蛋糕、鲜花、数码、服饰、快递、五金、汽配等）② 帮买（代购商品）③ 帮取号（餐厅取号、医院挂号、其他取号）④ 帮搬装/帮扔杂物/其他帮忙（骑手到指定地址帮忙）。触发词：跑腿、下跑腿单、美团跑腿、同城配送、取号、挂号、排号、排队、帮搬、帮买、帮扔、帮忙、扔垃圾、寄文件、叫骑手、骑手帮忙、送东西、帮取、配送、帮送、买东西。

美团跑腿下单 Skill

⚠️ 输出规范：

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

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

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

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

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

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

When to Use

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

When NOT to Use

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

风险提示与免责声明

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

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

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

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

场景识别与分流

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

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

安全门控

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

强制两步确认：先预览展示费用卡片，等用户明确回复"确认"后才提交。
信息完整性（按场景区分必填项）：
- 帮取送：取件地址、收件地址、取件电话、收件电话、物品信息（需查 params.md 品类表映射 goodTypes/goodTypeNames/goodsWeight）（5 项）
- 帮买：送达地址 + 电话 + 购买方式（指定购买地址 or 就近购买）+ 物品信息（--purchase-detail）（4 项）
- 帮忙：帮忙地址 + 电话（2 项）
缺失任何必填项不允许询价和提单。电话获取规则详见 Step 3。
金额异常拦截：费用 > 100 元时需额外向用户确认。

工作流程

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

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

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

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

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

0.2 检查缓存的授权 Token

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

退出码 0（缓存命中）→ 取出 Token 执行 login 验证：
```
TOKEN=$(pt-passport get-token --client_id ac76c22d257c4c6d9164719eea64ed4b)
MCP_ACCESS_TOKEN="$TOKEN" sh run.sh login
```
- 已登录 → 直接进入 Step 1
- AUTH_FAILED → 走下方授权流程
退出码 1（无缓存）→ 走下方授权流程

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

pt-passport auth get-code --client_id ac76c22d257c4c6d9164719eea64ed4b

解析输出：

AUTH_LINK: <url> → 生成二维码并展示给用户：
```
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（用户已授权，会立即返回）：

pt-passport auth poll-token --client_id ac76c22d257c4c6d9164719eea64ed4b

成功后取出 Token 验证登录：

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 条，先问后列，格式：

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

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

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

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

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

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

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

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

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

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

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

Step 3：地址确认

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

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

用户明确指定的真实电话 → 使用用户指定的

地址簿选序号 → 调用 get_address_info --address-id 获取真实号码

新地址场景 → 从地址簿取最近使用的地址调 get_address_info 获取真实号码

get_address_info 返回的号码仍含 **** → 才向用户追问

地址簿为空 → 向用户询问手机号

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

帮取送场景：需要取件地址 + 收件地址，两个地址都确认后进入 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 生成收银台支付链接：

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 已成功返回），登录态判断交给用户点击时的真实页面，不做任何预验证。同一条消息内发送双支付链接 + 登录链接 + 条件引导：

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

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

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

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

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

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

第三步：对话兜底

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

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

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

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

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

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

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

⚠️ 三条规则：

登录链接始终随支付链接一并发送，用户点击时按页面实际情况自助判断是否需要。

用户登录后原支付链接直接可用，无需重新生成。

只发收银台链接，严禁引导去美团 App 支付；链接用 Markdown 超链接格式，严禁裸露 URL。手机端和电脑端收银台链接始终成对发送；移动端收银台不支持电脑端支付，PC 端收银台不支持手机端支付，因此两案都发。

Step 7：订单状态查询

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

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

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

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

取消订单引导：

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

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

详细参考文档

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

美团跑腿

安装技能

美团跑腿下单 Skill

When to Use

When NOT to Use

风险提示与免责声明

场景识别与分流

安全门控

工作流程

帮取送预览模板

帮买预览模板

帮忙预览模板

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

Step 7：订单状态查询

详细参考文档

360 行为纵深安全审计引擎

美团跑腿

安装技能

美团跑腿下单 Skill

When to Use

When NOT to Use

风险提示与免责声明

场景识别与分流

安全门控

工作流程

帮取送 预览模板

帮买 预览模板

帮忙 预览模板

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

Step 7：订单状态查询

详细参考文档

帮取送预览模板

帮买预览模板

帮忙预览模板