# 项目愿景

## 一、核心目标

cmbuyer 要解决：**采购人员为了履约一笔外部订单，必须手工去拼多多找到同款商品、选对
颜色尺码、下单，再把订单号抄回系统——这个过程重复、易错、且无法追溯。**

> 让采购人员把「买什么」一次说清楚，由系统驱动手机完成找货、选规格和下单，人只在
> 两个关键点介入：**挑哪一个**和**付不付款**。

它不是无人值守的抢购脚本，也不是绕过平台规则的爬虫。它是一个**带人工闸门的采购执行
工具**：机器负责重复劳动，人保留花钱的决定权。

## 二、目标用户

- **采购管理员**：在网页端建单、复核候选商品、签发下单授权、查看执行证据。
- **采购执行员**：在桌面端连接手机、启动批次、处理需要人工接管的任务、完成付款。
- **ERP 对接身份**：只读同步第三方系统的货运单与商品明细，不参与采购决策。
- **系统管理员（后续）**：人员、设备、权限和审计策略管理，MVP 不提供完整界面。

## 三、产品原则

遇到取舍时，以这些原则为准：

- **人保留花钱权**：系统只创建待付款订单，**任何情况下都不自动付款**。
- **找不到就转人工**：规格、价格、标题读不到或对不上时停下来交给人，绝不近似匹配、
  绝不猜测。宁可少做，不可做错。
- **先走确定路径**：MVP 只做已知商品链接的情形。图片搜索推到 V2，且届时其唯一职责
  是产出 `goods_id`，不在搜索结果页上做价格或规格判断。
- **人站在不可逆动作正前方**：机器先试选并回传，人看过之后才授权下单。
- **价格只在可靠位置读**：规格面板和订单确认页。别处的数字一律不信。
- **失败要可诊断**：不能只返回「失败」，必须有步骤、错误码、截图和页面快照。
- **证据分层**：人工决策需要的证据上传服务端，完整执行轨迹留在桌面端本地。

## 四、核心价值主张

| 价值点 | 用户得到什么 |
| --- | --- |
| 消除重复劳动 | 不再逐条手工搜索、选规格、抄订单号 |
| 决策集中可控 | 所有「买哪个」的决定收敛到网页端一处，有据可查 |
| 资金边界清晰 | 系统能下单不能付款，误操作不会直接造成损失 |
| 执行可追溯 | 每笔采购留下候选、截图、授权理由和订单核对记录 |
| 批量顺序执行 | 一次导入多条，按顺序跑，遇到问题停在该停的地方 |

## 五、不做什么（非目标）

- **不自动付款。** 不在本项目任何版本内规划，除非另行完成资金与合规评审。
- 不绕过验证码、风控、人脸、短信校验或平台限流。
- 不在外部支付页（微信等）读取、保存或输入任何凭据。
- MVP 不支持拼多多以外的平台。
- MVP 不做多设备负载均衡、复杂审批链、财务对账和退款。
- 不做后台推送后立即执行；桌面端主动领取。
- 不承诺对所有拼多多版本和所有商品类目通用。

> MVP 的具体功能范围与验收标准，见 [需求](02-requirements.md)。

## 六、与既有项目的关系

cmbuyer 是 `cmroubao` 与 `cmpdd` 两个前序项目的合并重启，取各自已验证的一半：

| 来源 | 保留 | 丢弃 |
| --- | --- | --- |
| `cmroubao` | Go 后端的任务生命周期、设备侧 API 形状、下单授权状态机、ERP 货运对接、管理 Web | Android AccessibilityService 感知层、自研 APK |
| `cmpdd` | uiautomator2 真机自动化、按维度精确选规格、订单确认页读取、付款闸门、`TaskSource`/`ResultSink` 抽象 | 单机 Excel 工作流作为唯一入口、桌面端持有全部业务权威 |

**不要把这两个仓库当作事实来源直接引用。** 它们是设计依据，代码需重新实现并重新验证；
凡是护栏（精确匹配、唯一控件、转人工），必须连同**理由**一起搬过来。