4.7 KiB
cmbuyer
自动化采购系统。网页端负责建单与人工决策，桌面端驱动 Android 手机在拼多多完成 选规格和下单。
系统只创建待付款订单，任何情况下都不自动付款。
它做什么
一笔外部订单进来，采购人员需要去拼多多找到同款、选对颜色尺码、下单、把订单号抄回系统。 cmbuyer 把这个过程自动化，人只在两个点介入：机器选对了吗和付不付款。
手工填链接（MVP） ／ Excel · ERP（V2）
│
v
web 端（Go） 建单 · 试选确认 · 下单授权 · 审计
│ HTTP
v
desk 端（Python） 领任务 · 跑流程 · 回传
│ ADB（USB / WiFi）
v
Android 手机（拼多多 App）
两趟执行
MVP 只做任务自带商品链接的情形，分两趟跑完：
| 趟次 | 做什么 |
|---|---|
| 第一趟 · 试选 | 开商品 → 精确勾选颜色分类和尺码 → 读单价 → 截图 → 退出释放手机 → 回传 |
| 人工确认 | 人在网页端看「机器选对了吗」→ 确认并锁定单价 |
| 第二趟 · 下单 | 重新开商品 → 重新选同一规格 → 三道价格闸门 → 提交订单一次 → 转「待付款」 |
为什么分两趟：一台手机是瓶颈，不能停在规格面板上等人。代价是走两遍，换来手机不空闲， 且第二趟能抓住价格变动。
三道价格闸门：① 第一趟规格面板读价 ② 第二趟重读必须与授权价一致 ③ 订单确认页「实付款」不超上限。任一道读不到或不通过即停，转人工。
价格只在规格面板和订单确认页读——别处的价格文本被拆成多个节点、带券后前缀、 实付价与原价混在一起，不可靠。
现在处于什么阶段
Phase 0 · 地基。仓库目前只有文档，尚未开始编码。
下一步：先并行完成 T-005（网页端 MVP 原型）与 T-006（桌面端 MVP 原型）并由人确认，
再进入 T-001 / T-002 骨架和生产实现。
详见 docs/current-state.md。
生死线是 M2：真机能按链接打开商品、精确勾选颜色分类和尺码、读到该 SKU 单价。 前序项目正是卡在这里，M2 不通过之前不要写页面。
从哪读起
| 你是 | 读这个 |
|---|---|
| AI coding agent | AGENTS.md → docs/00-ai-start-here.md |
| Claude Code | CLAUDE.md |
| 想了解业务 | docs/01-vision.md → docs/02-requirements.md |
| 想了解技术结构 | docs/04-architecture.md |
| 全部文档 | docs/README.md |
十一条安全边界
以下每条都必须有单元测试证明，不得在任务中放宽：
- 不点击任何支付、免密支付、先用后付或扣款控件
- 提交订单四条件：授权未消费且服务端提交围栏已建立 + 闸门二通过 + 闸门三通过 + 控件唯一，只点一次；围栏后只调和，不释放、不重试
- 订单确认页上除提交与返回外零点击
- 规格按维度精确匹配，防前缀碰撞，找不到即停
- 数量设置后必须读回复核
- 三道价格闸门，任一道读不到或不通过即停
- 第一趟绝不下单——试选路径不得引用下单函数
- 检测到外部支付交接立即停止，不读取不保存凭据
- 检测到验证码 / 风控 / 人脸 / 短信校验立即停止，不绕过
- 只读非敏感摘要，不提取收货地址原文、手机号、支付凭据
- 授权一次性，重复提交幂等；点击后无论结果一律不重试
完整说明见 docs/04-architecture.md 第四节。
与前序项目的关系
cmbuyer 是 cmroubao（Go 后端 + Android AccessibilityService）与 cmpdd
（Python + uiautomator2）的合并重启，取各自已验证的一半：
- 保留 cmroubao 的后端任务生命周期、设备侧 API 形状、下单授权状态机、ERP 对接、管理 Web
- 保留 cmpdd 的 uiautomator2 真机自动化、按维度精确选规格、订单确认页读取、付款闸门
- 丢弃自研 Android APK 与 AccessibilityService 感知层
前序项目是设计依据，不是事实来源。 其中的页面判据必须在本项目用真机重新验证。
技术栈
| 端 | 栈 |
|---|---|
| web | Go 1.23+ / gin / html/template / SQLite / goose |
| desk | Python 3.11+ / uiautomator2 / PySide6 / Pillow |
| 设备 | Android 手机 + 拼多多 App，ADB over USB 或 WiFi |