拼多多自动发货（方案 A）实施步骤

架构：飞书群收物流信息 → 多维表格任务板 → 本机轮询 → RPA/浏览器自动化拼多多发货 → 回写状态
约束：不走拼多多开放平台 API、不接 ERP；发货仅操作商家后台网页。
日期：2026-07-25

1. 目标与边界

1.1 要达成的效果

供应商在飞书群发送物流信息（姓名、手机、地址、快递单号等）。
系统自动落入飞书多维表格，状态为「待处理」。
发货电脑常驻一个轮询程序，拉取「待处理」任务。
用浏览器自动化打开拼多多商家后台：按姓名匹配订单；同址可合并发货；异址用手机+地址确认；填入运单号并确认发货。
回写表格状态为「已发货」或「失败」，必要时在群里告警。

1.2 不做的事

不调用拼多多开放 API / 不安装第三方打单 ERP。
不让 AI 在量产时每次临场决定是否点「发货」（AI 只用于探路与录制流程）。
匹配不唯一或信息不足时：禁止自动发货，只标记失败并通知人工。

1.3 业务匹配规则（固化进自动化）

收到：姓名 + 快递单号（每条消息一个单号；通常含手机、地址）
  → 在拼多多「待发货」中按姓名搜索
      → 0 条：失败「未找到订单」
      → 1 条：对该单发货
      → N 条：
            → 收货地址相同：走页面「合并发货」，共用这一运单号
            → 地址不同：用手机号 + 地址二次匹配
                  → 唯一：发该单（或该址下的合并集）
                  → 仍 0/多：失败「需人工」

2. 总体架构

供应商
  │ 发群消息 / 填群表单（推荐表单更稳）
  ▼
飞书群
  │ 自建应用订阅消息 或 表单提交
  ▼
飞书多维表格（任务板）
  字段：姓名、手机、地址、快递公司、运单号、状态、失败原因、原始消息、创建时间…
  │
  │ 本机定时 GET「状态=待处理」
  ▼
本机 Worker（Python 等）
  │ 将行改为「处理中」→ 调用浏览器发货脚本 → 回写「已发货/失败」
  ▼
拼多多商家后台（浏览器自动化）

3. 飞书侧实施步骤

3.1 创建多维表格（任务板）

飞书新建「多维表格」，命名如：拼多多发货任务。
建议字段：

字段名	类型	说明
任务ID	自动编号 / 文本	唯一标识，便于日志
姓名	文本	收件人姓名
手机	文本	完整手机号
地址	文本	完整收货地址
快递公司	文本	如顺丰/中通；可空，页面再选
运单号	文本	每条任务一个
状态	单选	`待处理` / `处理中` / `已发货` / `失败` / `已取消`
失败原因	文本	匹配失败、页面异常等
原始消息	文本	群里原文，便于核对
处理机器	文本	可选，哪台电脑领了任务
开始处理时间	日期时间	可选
完成时间	日期时间	可选
拼多多订单号	文本	发货成功后回填，可选

建视图：
- 待处理队列：筛选 状态 = 待处理，按创建时间升序。
- 失败待审：筛选 状态 = 失败。
- 今日已发货：筛选 状态 = 已发货 + 今天。

3.2 创建飞书自建应用

打开飞书开放平台 → 创建企业自建应用。
开通权限（按实际能力勾选，名称以控制台为准），典型包括：
- 获取与发送单聊、群组消息相关权限（若用群消息解析）。
- 多维表格：读、写记录。
- 查看群信息（若需限制只处理指定群）。
发布应用版本，并在企业内启用。
将应用机器人拉进「物流发货」专用群。
记录：App ID、App Secret、多维表格 app_token、数据表 table_id。

安全：Secret 只放本机环境变量或本地配置文件，不要提交到 Git。

3.3 消息如何进入表格（二选一，可并行）

方式一：群表单 / 信息收集（更推荐）

在群内用飞书「表单」或多维表格「表单视图」收集：姓名、手机、地址、快递公司、运单号。
提交后直接成为表格一行，状态 默认「待处理」。
优点：字段结构化，几乎不用 NLP；供应商按表单填即可。

方式二：群里自由文本 + 应用解析

自建应用订阅「接收消息」类事件（事件订阅需配置请求网址；可用云函数/轻量服务，不必用本机穿透）。
收到指定群文本后：
- 按模板正则提取字段；或调用一次 LLM 抽字段。
- 调用多维表格 API 新增记录，状态=待处理，原始消息=全文。
建议供应商固定模板：

text

姓名：张三
手机：13800138000
地址：广东省深圳市南山区xx路xx号
快递：顺丰
单号：SF1234567890123

解析失败：在群里回复「格式不对，请按模板重发或改用表单」，且不要写入「待处理」。

3.4 事件订阅小服务放哪

推荐：任意可公网访问的小服务（云函数、1 核 VPS、飞书长期可用的自动化能力若满足也可）。
职责仅限：验签 → 解析 → 写多维表格 → 快速返回成功。
不要在回调里同步跑拼多多 RPA。

4. 本机 Worker 实施步骤

4.1 环境准备

固定一台 Windows/macOS 发货机（建议 Windows + Chrome，拼多多商家后台兼容性更好）。
安装 Python 3.11+（或你熟悉的运行时）。
安装浏览器自动化依赖（量产后用 Playwright 等固化脚本；探路阶段可用 AI 浏览器 Agent）。
Chrome 保持已登录 拼多多商家后台（mms / 商家版后台），建议独立浏览器用户数据目录，避免与日常浏览互相踢登录。
配置环境变量示例：

bash

FEISHU_APP_ID=cli_xxx
FEISHU_APP_SECRET=xxx
FEISHU_BITABLE_APP_TOKEN=bascnxxx
FEISHU_BITABLE_TABLE_ID=tblxxx
POLL_INTERVAL_SECONDS=20

4.2 轮询逻辑（必须实现的状态机）

每轮：

用飞书 API 查询 状态 = 待处理，按创建时间取 1 条（或小批量串行，不要并行多开浏览器发货，除非你很清楚并发风险）。
先把该行改为 处理中，写入 处理机器、开始处理时间（乐观锁，防双机抢单）。
若改状态失败（已被别人领走），跳过。
调用本地发货脚本，传入：姓名、手机、地址、快递公司、运单号。
根据返回码回写：
- 成功：已发货 + 完成时间 +（可选）订单号。
- 失败：失败 + 失败原因；可选发飞书群消息 @负责人。
休眠 POLL_INTERVAL_SECONDS，进入下一轮。
可选巡检：处理中 超过 N 分钟仍未完成 → 改回 失败（超时），避免卡死。

4.3 幂等与安全

同一 运单号 若表格里已有「已发货」，新任务直接标失败「单号重复」。
发货脚本内部：页面确认已变成已发货后再回报成功。
匹配分支严格按第 1.3 节；不确定就失败，不要猜。

5. 拼多多浏览器自动化（量产）

5.1 推荐路径

阶段 1（探路）：用 AI + 浏览器（Chrome MCP / browser-use / Skyvern 等）走通人工发货路径，记录 URL、按钮文案、异常弹窗。
阶段 2（固化）：把稳定步骤写成 Playwright（或影刀）脚本，由本机 Worker 调用。
阶段 3（值守）：只跑固化脚本；页面大改时再用 AI 探路更新脚本。

5.2 脚本应覆盖的页面步骤（清单）

打开发货/订单中心（待发货列表）。
用「收件人姓名」搜索（若后台无姓名搜索，则用列表筛选/搜索框可达等价能力）。
读取结果行：收件人、手机、地址、订单号。
分支：
- 0 行 → 返回失败。
- 1 行 → 进入发货。
- 多行且地址规范化后相同 → 勾选后合并发货（若无合并，则同址逐单填同一运单号，二选一写死一种策略）。
- 多行地址不同 → 用手机、地址过滤到唯一集合再发。
选择物流公司、填运单号、确认发货。
校验订单状态变为已发货（或列表中消失/标记已发）。
截图保存到本地 logs/日期/任务ID.png（失败必截）。

5.3 「地址相同」判定建议

去掉空格、中英文标点差异后再比。
或比「省市区 + 明细前 N 字 + 手机号」组合。
宁可判成不同址走人审，不要误合并。

6. 验收清单

[ ] 表单/群消息能稳定写入「待处理」。
[ ] 本机轮询能领取任务并置「处理中」。
[ ] 单订单：姓名唯一 → 自动发货成功 → 表格「已发货」。
[ ] 同名同址多单：合并或逐单同运单号策略符合预期。
[ ] 同名异址：仅手机+地址命中的那单发货。
[ ] 故意缺字段 / 故意同名冲突 → 「失败」+ 群通知，无误发。
[ ] 登录过期 / 验证码：脚本失败可感知，不假报成功。
[ ] 重复运单号：拒绝二次发货。

7. 运维建议

发货机勿休眠；屏幕锁不影响无头/有头策略需实测拼多多是否强校验。
每周抽查「失败待审」视图。
拼多多改版后：先跑 AI 探路提示词更新选择器，再上线固化脚本。
日志保留至少 30 天（任务ID、运单号、截图）。

8. AI 探路提示词（给 Chrome MCP / browser-use 等）

使用方式：在已登录拼多多商家后台的浏览器里，把下列提示词交给 Agent。
目标：摸清路径与元素，输出「可交给 Playwright 固化」的步骤说明；不要在探路时对真实大额订单批量确认发货（可用测试单或停在确认按钮前）。

8.1 总览探路

text

你是电商后台 RPA 探路助手。当前 Chrome 已登录拼多多商家后台。

任务：找出「待发货订单 → 按收件人信息匹配 → 填写物流单号完成发货」的完整人工路径。

请逐步操作并记录：
1. 从首页到「待发货/发货管理/订单发货」的导航路径（菜单文案、URL 变化）。
2. 列表页有哪些搜索/筛选：是否支持按收件人姓名、手机、订单号搜索。
3. 列表每一行可见字段（姓名、手机、地址、商品、订单号等）及对应 DOM 特征（角色、文本、稳定选择器线索）。
4. 单笔发货按钮入口与发货弹窗/页面结构：物流公司如何选择、运单号输入框、确认按钮。
5. 是否存在「合并发货」：如何多选、入口文案、限制条件（是否要求同地址）。
6. 发货成功后的页面反馈（Toast、状态文案、列表变化）。
7. 常见阻断：登录过期、滑块、权限、必填校验文案。

输出格式（Markdown）：
- 导航路径
- 选择器/文案清单（尽量给出稳定的文本+属性，而不是绝对坐标）
- 推荐自动化步骤伪代码（if/else 按：0 命中 / 1 命中 / 同址多单 / 异址多单）
- 风险点与需要人工确认的步骤
- 建议的 Playwright 用例名称列表

约束：
- 不要提交真实发货，除非我明确提供「测试订单号」并授权；默认停在点击「确认发货」之前。
- 每一步先观察再点击；失败就换定位策略并记录原因。

8.2 节点：搜索收件人

text

目标：在拼多多待发货列表中，用收件人姓名搜索订单。

输入变量：
- recipient_name = 「{{姓名}}」

步骤要求：
1. 进入待发货列表。
2. 找到搜索框或筛选，输入 recipient_name 并触发搜索。
3. 等待结果刷新，统计结果行数。
4. 抽取每一行的：订单号、收件人、手机、完整地址（尽可能）。
5. 输出 JSON：
{
  "search_field": "...",
  "result_count": 0,
  "rows": [{"order_id":"","name":"","mobile":"","address":""}],
  "selectors": {"search_input":"...","result_row":"..."},
  "notes": "..."
}

若后台不能按姓名搜：尝试可用的替代筛选，并明确写「无法按姓名搜索，需改策略」。
不要点击发货。

8.3 节点：同址合并判定

text

目标：在当前搜索结果中，判断哪些订单可以合并发货。

输入：上一节点的 rows（含 name/mobile/address/order_id）。

规则：
1. 对 address 做规范化（去空格、统一标点）后分组。
2. 若存在「同一规范化地址」下订单数 ≥ 2，记录为可合并候选。
3. 探查 UI：如何勾选多笔、是否有「合并发货」按钮、按钮在何种条件下可点。
4. 输出：
- 分组结果
- 合并操作逐步 UI 步骤
- 选择器线索
- 若无合并能力：说明改为「逐单填写同一运单号」的点击路径

不要确认发货。

8.4 节点：异址用手机+地址匹配

text

目标：同名多条且地址不同时，用手机号与地址精确匹配目标订单。

输入：
- rows: 搜索结果
- mobile: 「{{手机}}」
- address: 「{{地址}}」

规则：
1. 先按手机号过滤；若手机号带脱敏（如 138****8000），用可见数字做兼容匹配并标注不确定性。
2. 再在剩余结果里用地址包含/规范化相等匹配。
3. 若唯一命中：标出该行及如何进入发货。
4. 若 0 或多条：停止，输出 reason，供人工处理。

输出 JSON：matched_order_ids、match_confidence（high/medium/low）、ui_steps、stop_reason。
不要确认发货。

8.5 节点：填写运单并停在确认前

text

目标：对已选定的订单打开发货界面，填写物流信息，但不要最终提交。

输入：
- order_id 或已选中行
- logistics_company: 「{{快递公司}}」
- tracking_number: 「{{运单号}}」

步骤：
1. 进入发货弹窗/页面。
2. 选择物流公司（记录下拉项如何定位；若需精确编码/别名映射，列出来）。
3. 填入运单号。
4. 识别「确认发货」按钮位置与可点条件。
5. 在点击确认前停止，截图，输出完整 Playwright 风格步骤。

严禁点击最终确认（除非用户消息里出现：CONFIRM_SHIP=YES）。

8.6 节点：成功校验

text

目标：在一次「已授权的测试发货」之后，验证发货是否成功。

输入：order_id、tracking_number

检查：
1. Toast/成功文案
2. 订单状态是否变为已发货
3. 待发货列表是否还能搜到该单
4. 物流单号是否展示正确

输出：success true/false、evidence（文案/状态）、建议的自动化断言语句。

8.7 节点：把探路结果整理成固化规格

text

根据我们刚才探路的全部观察，输出一份《拼多多发货 RPA 规格书》，供开发写成 Playwright：

1. 前置条件（URL、登录态、浏览器配置）
2. 函数：search_by_name(name)
3. 函数：select_orders(rows, mobile, address)  // 含同址合并 / 异址匹配
4. 函数：fill_logistics(company, tracking_no)
5. 函数：confirm_and_verify()
6. 函数：fail(reason) // 截图+返回码
7. 错误码枚举：NO_ORDER / AMBIGUOUS / LOGIN_EXPIRED / UI_CHANGED / VERIFY_FAILED
8. 每个函数的选择器表（主选 + 备选）
9. 明确禁止自动继续的分支

要求：只写确定性步骤，不要保留「你可以尝试」这类模糊语句。

9. 最小落地顺序（建议一周内）

天	事项
Day 1	建多维表格字段与视图；建飞书应用；拉机器人进群
Day 2	先跑通「群表单 → 表格一行」；人工改状态熟悉流程
Day 3	本机 Worker：轮询 + 改状态（先不接发货，只打印任务）
Day 4	AI 探路（第 8 章提示词）产出规格书
Day 5	Playwright 固化快乐路径（单订单发货）
Day 6	补同址/异址分支与失败告警
Day 7	按第 6 章验收清单走查后小流量正式用

10. 最终工具清单（保持精简）

层级	选型
入口	飞书群 + 表单（优先）/ 群文本解析（备选）
任务板	飞书多维表格
调度	本机轮询 Worker
探路	AI + Chrome（MCP / browser-use 等）+ 第 8 章提示词
量产发货	Playwright（或等价 RPA）操作拼多多网页

11. 附录：群内供应商说明（可直接转发）

请按表单提交发货信息；若发文本，请严格使用：

text

姓名：
手机：
地址：
快递：
单号：

注意：

一条消息只对应一个运单号。
手机与地址请与拼多多订单一致，便于自动匹配。
提交后无需重复发送；失败我们会在群里通知。

拼多多自动发货（方案 A）实施步骤 ​

1. 目标与边界 ​

1.1 要达成的效果 ​

1.2 不做的事 ​

1.3 业务匹配规则（固化进自动化） ​

2. 总体架构 ​

3. 飞书侧实施步骤 ​

3.1 创建多维表格（任务板） ​

3.2 创建飞书自建应用 ​

3.3 消息如何进入表格（二选一，可并行） ​

方式一：群表单 / 信息收集（更推荐） ​

方式二：群里自由文本 + 应用解析 ​

3.4 事件订阅小服务放哪 ​

4. 本机 Worker 实施步骤 ​

4.1 环境准备 ​

4.2 轮询逻辑（必须实现的状态机） ​

4.3 幂等与安全 ​

5. 拼多多浏览器自动化（量产） ​

5.1 推荐路径 ​

5.2 脚本应覆盖的页面步骤（清单） ​

5.3 「地址相同」判定建议 ​

6. 验收清单 ​

7. 运维建议 ​

8. AI 探路提示词（给 Chrome MCP / browser-use 等） ​

8.1 总览探路 ​

8.2 节点：搜索收件人 ​

8.3 节点：同址合并判定 ​

8.4 节点：异址用手机+地址匹配 ​

8.5 节点：填写运单并停在确认前 ​

8.6 节点：成功校验 ​

8.7 节点：把探路结果整理成固化规格 ​

9. 最小落地顺序（建议一周内） ​

10. 最终工具清单（保持精简） ​

11. 附录：群内供应商说明（可直接转发） ​

拼多多自动发货（方案 A）实施步骤

1. 目标与边界

1.1 要达成的效果

1.2 不做的事

1.3 业务匹配规则（固化进自动化）

2. 总体架构

3. 飞书侧实施步骤

3.1 创建多维表格（任务板）

3.2 创建飞书自建应用

3.3 消息如何进入表格（二选一，可并行）

方式一：群表单 / 信息收集（更推荐）

方式二：群里自由文本 + 应用解析

3.4 事件订阅小服务放哪

4. 本机 Worker 实施步骤

4.1 环境准备

4.2 轮询逻辑（必须实现的状态机）

4.3 幂等与安全

5. 拼多多浏览器自动化（量产）

5.1 推荐路径

5.2 脚本应覆盖的页面步骤（清单）

5.3 「地址相同」判定建议

6. 验收清单

7. 运维建议

8. AI 探路提示词（给 Chrome MCP / browser-use 等）

8.1 总览探路

8.2 节点：搜索收件人

8.3 节点：同址合并判定

8.4 节点：异址用手机+地址匹配

8.5 节点：填写运单并停在确认前

8.6 节点：成功校验

8.7 节点：把探路结果整理成固化规格

9. 最小落地顺序（建议一周内）

10. 最终工具清单（保持精简）

11. 附录：群内供应商说明（可直接转发）