cmbuyer/docs/01-vision.md

项目愿景

一、核心目标

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

让采购人员把“买什么、买多少、最多多少钱”一次说清楚，并明确点击开始采购；系统驱动手机 精确选规格并创建待付款订单，付不付款始终由人决定。

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

二、目标用户

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

三、产品原则

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

• 人保留花钱权：系统只创建待付款订单，任何情况下都不自动付款。
• 找不到就转人工：规格、价格、标题读不到或对不上时停下来交给人，绝不近似匹配、 绝不猜测。宁可少做，不可做错。
• 先走确定路径：MVP 只做已知商品链接的情形。图片搜索推到 V2，且届时其唯一职责 是产出 goods_id，不在搜索结果页上做价格或规格判断。
• 授权点明确且前置：创建任务不授权；管理员点击“开始采购”才允许创建一笔待付款订单。
• 实时闸门不依赖旧截图：授权后同一设备会话两次读取规格面板价格，并在确认页校验总额。
• 价格只在可靠位置读：规格面板和订单确认页。别处的数字一律不信。
• 失败要可诊断：不能只返回「失败」，必须有步骤、错误码、截图和页面快照。
• 证据分层：人工决策需要的证据上传服务端，完整执行轨迹留在桌面端本地。

四、核心价值主张

价值点	用户得到什么
消除重复劳动	不再逐条手工搜索、选规格、抄订单号
决策集中可控	商品、规格、数量、最高总价和开始采购授权收敛到网页端，有据可查
资金边界清晰	系统能下单不能付款，误操作不会直接造成损失
执行可追溯	每笔采购留下授权、三道闸门、截图、围栏和订单核对记录
批量顺序执行	一次导入多条，按顺序跑，遇到问题停在该停的地方

五、不做什么（非目标）

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

MVP 的具体功能范围与验收标准，见 需求。

六、与既有项目的关系

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

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

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