Browser Shopping Assistant

核心用法

browser-commerce-base 是一套浏览器原生的电商任务工作流，专为 OpenClaw 平台设计。核心模式是状态检查 → 页面聚焦 → 快照交互 → 结构化提取 → 证据留存。用户需先执行 browser status 和 browser start 启动环境，再根据任务风险选择浏览器 profile：openclaw 用于公开浏览、搜索结果、比价截图；user 仅在需要登录态（购物车、优惠券、订单、会员价）时启用；chrome-relay 仅在用户明确要求扩展 attach-tab 流程时使用。

关键提取顺序

1. 平台识别 → 页面类型（搜索/详情/购物车/订单/优惠券/店铺）
2. 商品信息：标题、现价、券后价/会员价、店铺、销量/评分/评论数
3. 履约信息：配送承诺、SKU 规格选项
4. 风险提示 → 链接 + 截图证据

标准页面工作流

• 搜索结果页：快速对比多候选，收集商品卡片、价格、店铺、销量、优惠券信息，截图留存排名证据
• 商品详情页：单商品决策，提取标题、价格、店铺、服务标识，检查 SKU 选择器，注意优惠券/限时促销/会员价变动，截图作为推荐依据
• 购物车/订单/优惠券页：仅在必要时切换 user profile，优先读取/检查而非操作，禁止执行支付或最终下单
• 地理位置敏感页：结合 geolocation 判断配送范围、时效、门店可用性，明确标注位置假设

显著优点

• 平台覆盖广：支持淘宝、京东、拼多多、美团、饿了么、唯品会、SHEIN、大众点评等主流平台
• 安全边界清晰：明确定义 openclaw/user/chrome-relay 三种 profile 的适用场景，降低登录态滥用风险
• 结构化提取：标准化的 11 步提取顺序，确保比价、查券等任务输出一致可复现
• 证据链完整：强制要求截图留存关键页面，便于结果验证和纠纷追溯
• 动态页面适配：针对电商页面高度动态特性，提供 snapshot --interactive、重新快照、requests/errors 检查、response body 解析等调试手段

潜在缺点与局限性

• 无法闭环交易：明确禁止完成支付、最终下单、修改账户/地址/支付方式，仅限观察与推荐
• 登录态依赖外部：user profile 的登录状态由用户浏览器维护，若 Cookie 过期或需要二次验证（短信/扫码），自动化可能中断
• 反爬与风控：电商平台普遍存在验证码、滑块、行为检测，频繁操作可能触发限制
• 价格时效性：优惠券、限时秒杀价格变动快，快照时刻与决策时刻可能存在价差
• 地域差异：库存、配送费、门店可用性高度依赖用户地理位置，输出需明确标注假设

适合人群

• 理性比价消费者：需要在多平台、多店铺间横向对比价格、优惠、服务的用户
• 电商运营/选品人员：需要批量检查竞品价格、促销活动、店铺动态的研究者
• 券后价敏感用户：需要验证优惠券适用性、计算最终到手价的精打细算型消费者
• 订单/库存管理者：需要安全查看购物车、订单状态、配送进度的用户（不替代官方 App）

常规风险

• 隐私泄露：user profile 可能暴露购物车内容、收货地址、订单历史，需在可信环境使用
• 误操作风险：尽管有安全边界，SKU 选择、优惠券领取等操作仍可能产生不可逆的账户变更
• 数据准确性：页面解析依赖 DOM 结构，平台改版或 A/B 测试可能导致提取失败
• 合规边界：大规模自动化数据采集可能违反平台 ToS，建议控制频率并用于个人决策场景