淘宝、1688、京东、拼多多这类购物 App 的自动化，不应该被定义成“自动点击到付款”，而应该被定义成“在严格边界内完成可审计的购物任务状态流转”。
先把目标拆级
| 级别 | 能力范围 | 推荐程度 |
|---|---|---|
| L0 | 搜索、比价、提取商品信息、汇总截图 | 强烈推荐，最容易稳定 |
| L1 | 自动筛选、进详情、选 SKU、加购、领券 | 强烈推荐，MVP 主线 |
| L2 | 到确认订单页，等待人工确认 | 强烈推荐，最实用的“半自动下单” |
| L3 | 自动提交订单，但不自动支付 | 谨慎，需状态机和审批 |
| L4 | 自动支付完成闭环 | 不推荐作为通用方案 |
对大多数真实业务，L2 就已经很有价值。
推荐的购物状态机
boot
-> login_check
-> home_ready
-> search_input
-> search_results
-> product_detail
-> sku_selection
-> cart_or_buy_now
-> coupon_review
-> checkout_review
-> approval_required
-> completed / blocked
每个状态建议允许的动作
login_check
- 判断是否已登录
- 如果未登录，只允许进入人工登录或受控登录子流程
- 不允许 Agent 自主试探密码、验证码、短信码
search_results
- 滚动结果页
- 根据关键词、价格、店铺、销量、自营/官方、发货地筛选
- 把候选商品列表结构化保存
product_detail
- 读取价格、券信息、店铺信息、配送信息
- 检查是否存在默认变体陷阱
- 保存“备选 SKU 列表”
sku_selection
- 只允许选预设允许的规格区间
- 若规格导致超预算，直接回退
- 选中结果写回任务状态，而不是只留在页面里
checkout_review
- 比对金额、券、地址、运费、配送方式
- 一旦出现地址变动、支付方式变动、实名信息弹层，必须阻塞
approval_required
- 输出最终确认摘要
- 由人确认后才能继续
- 继续动作可以是“提交订单”或“打开待支付页”
面向淘宝 / 1688 / 京东 / 拼多多的差异化建议
| 平台 | 更适合优先自动化的能力 | 风险更高的环节 |
|---|---|---|
| 淘宝 | 搜索、比价、详情页解析、加购、券选择 | 页面变化快、营销弹窗多、支付链路复杂 |
| 1688 | 货盘搜索、规格对比、询价、加购、采购确认 | 企业采购规则、起订量和物流规则复杂 |
| 京东 | 自营筛选、配送时效、售后信息、加购 | 活动规则多、地址/配送依赖更强 |
| 拼多多 | 多规格比价、拼单规则识别、活动标签读取 | 页面噪音大、营销链路强、风控更敏感 |
最稳的业务闭环不是 UI-only
路径 A：完全 UI 驱动
优点：
- 接入快
- 不依赖平台 API 权限
缺点：
- 稳定性受页面改版、弹窗、登录、风控影响极大
- 很难把“订单”变成强结构化对象
路径 B：API 主链路 + UI 补位
更推荐。
适用场景：
- 你有商家/供应链/采购权限
- 能拿到官方开放平台接入资质
- 订单、商品、库存、价格最好通过接口处理
可参考入口：
这里的关键思想是：
- 商品搜索、下单、订单回写尽量走 API
- 只有优惠券、运营后台、人机确认、临时页面才交给手机 Agent
任务入参建议
建议你的任务系统不要接自然语言裸文本就直接执行，而是先解析成结构化输入：
{
"platform": "jd",
"keyword": "65W 氮化镓充电器",
"constraints": {
"max_price": 149,
"shop_type": "self_operated",
"quantity": 1
},
"allowed_actions": [
"search",
"filter",
"open_detail",
"select_sku",
"add_to_cart",
"go_checkout"
],
"approval_required_before": [
"submit_order",
"pay"
]
}
关键风控栅栏
- 遇到验证码，直接暂停
- 遇到短信验证，直接暂停
- 遇到支付页，直接暂停
- 遇到收货地址修改，直接暂停
- 遇到身份证/实名信息页，直接暂停
- 遇到账号异常、设备风险、二次确认，直接暂停
MVP 应该做到什么
P0
- 读取商品信息
- 搜索并筛选
- 详情页提取价格与 SKU
- 自动加购
P1
- 自动到确认订单页
- 输出最终确认摘要
- 人工确认后允许提交订单，但不支付
P2
- 针对单一平台、单一账号体系做更深集成
- 优先转向官方开放平台主链路
验收口径
购物自动化不能只看“成功率”，还要看：
- 到确认页成功率
- 平均步数
- 弹窗处理成功率
- 失败可解释率
- 人工接管后的恢复效率
- 是否产生误操作
最后的建议
如果你现在就要做“购物 App 可以自动购物”的版本，我建议这样定义产品目标：
- 支持淘宝、1688、京东、拼多多四个平台的搜索、筛选、详情页理解、加购与确认页到达。
- 在真实付款前，必须进入人工确认。
- 一旦获得某个平台的开放平台资质，再把主交易链路迁到 API。
这样做能最大化实用价值，同时把工程、风控和合规风险压到可控范围。