130 lines
8.8 KiB
Markdown
130 lines
8.8 KiB
Markdown
<!-- gitea-wiki-mirror:start -->
|
||
generated: true (请先修改 Gitea Wiki，禁止直接编辑本文件)
|
||
wiki_page: PDD-Detail-Rule-Migration-Analysis
|
||
wiki_url: https://git.ilapage.cn/OPC/goauto/wiki/PDD-Detail-Rule-Migration-Analysis.-
|
||
wiki_revision: b1b1b343917e66288f4282bc6b3b90ea4ff3cca0
|
||
synchronized_at: 2026-09-04T11:30:37Z
|
||
<!-- gitea-wiki-mirror:end -->
|
||
|
||
# PDD 商品详情采集规则迁移分析
|
||
|
||
## 结论
|
||
|
||
从 `D:\chengma\cmautobuy\client` 迁移这套能力是合理的，但不能把其中的文字、resource-id 或坐标直接拼成 GoAuto `schemaVersion: 1` 规则。源项目的可靠性来自一套有状态采集算法，而 GoAuto v1 目前只支持唯一节点上的单次 `wait`、`click`、`input`、`back` 和 `extract`。
|
||
|
||
推荐新增 `schemaVersion: 2`、可扩展的类型化动作注册表和高层采集动作：服务端规则管理页面证据、规格别名、阶段钩子、超时和遍历上限；Android Agent 提供经过测试的动作实现，并由策略层按 `ruleType` 授权。规则草案见 [pdd-product-detail-v2.proposed.json](rules/pdd-product-detail-v2.proposed.json)。该文件目前是设计输入，v2 执行器完成前不能导入管理端。
|
||
|
||
## 源项目实际做法
|
||
|
||
正式采集链位于 `client/src/pdd_collect_service.py`，可复用的是以下行为：
|
||
|
||
1. 校验 URL 域名和 `goods_id` 一致性。
|
||
2. 打开链接后持续分类页面，区分商品页、首页、登录、验证码、网络错误、风控和支付页。
|
||
3. 读取商品摘要；有限纵向滚动补采店铺和评价。
|
||
4. 用多项强证据确认规格面板，避免把推荐商品或全屏散落文字误判为规格。
|
||
5. 颜色列表先归左，再按行蛇形遍历；每次点击后丢弃旧树并重新读取节点。
|
||
6. 只有确认颜色已选中，且价格连续两次一致，才建立颜色与价格的关联。
|
||
7. 颜色不可选或价格缺失时保留缺失信息，继续采集其它颜色和尺码。
|
||
8. 尺码只读不点击；横向或纵向滑动到连续两次视口稳定，并校验“尺码（N）”中的数量。
|
||
9. 按颜色价格展开颜色与尺码组合，并限制最大 SKU 数量。
|
||
|
||
源项目正式采集使用 `device.open_url()` 发起深链，不是先控制浏览器。`tools/test_pdd_home_deeplink.py` 只是用固定通用 URL 做只读诊断。因此浏览器“打开拼多多APP”和系统“打开”的步骤应继续采用 GoAuto 已通过一加真机验证的导航链，不能声称它来自源项目正式采集规则。
|
||
|
||
## 不能直接迁移的内容
|
||
|
||
| 源项目能力 | GoAuto v1 现状 | 直接迁移结果 |
|
||
|---|---|---|
|
||
| 同一容器提取多个规格值 | 每步必须唯一匹配 | 多个颜色或尺码会报 `RULE_AMBIGUOUS` |
|
||
| 横向、纵向滚动及边界判断 | 没有滚动动作 | 只能读取当前视口 |
|
||
| 点击后重新获取树 | 线性步骤不表达节点失效 | 容易点击旧节点或错绑价格 |
|
||
| 选中状态、可用状态和 bounds | `UiNodeRef` 只有文本 | 不能确认点击是否生效 |
|
||
| 价格连续两次稳定 | 只读取一次 | 可能记录颜色切换前的旧价格 |
|
||
| 颜色与价格成对累计 | `extract` 只产生独立字符串列表 | 两个数组可能错位 |
|
||
| 规格面板容器和相对位置 | selector 只支持节点自身属性 | 推荐列表可能被误判为规格 |
|
||
| 完整性计数、总时长和 SKU 上限 | 仅有单步超时 | 无法证明遍历完整，也缺少资源上限 |
|
||
|
||
因此，给 v1 增加一批 `extractAll` 步骤仍不能解决关联、滚动和状态确认问题。
|
||
|
||
## 推荐架构
|
||
|
||
```text
|
||
任务规则快照（服务端）
|
||
├─ navigation：浏览器和系统确认层的精确允许动作
|
||
├─ pageEvidence：PDD 包名、Activity 和商品页证据
|
||
└─ collector：pddProductDetailV1 + 别名、超时、次数和 SKU 上限
|
||
│
|
||
▼
|
||
Android 类型化状态机
|
||
页面分类 → 规格入口 → 面板强校验 → 逐颜色确认并采价 → 只读尺码 → 组装结果
|
||
│
|
||
▼
|
||
结构化结果（不含原始控件树和截图）
|
||
```
|
||
|
||
### 为什么采用可扩展动作注册表，而不是任意脚本 DSL
|
||
|
||
Agent 不限制为“只能采集”，而是注册带版本的类型化能力，例如 `swipe.v1`、`pddProductDetail.v1` 和未来的 `pddCreateOrder.v1`。规则可以组合 Agent 已声明支持的动作，因此增加一次已支持的滑动不需要升级 APK；只有出现新动作类型或新页面算法时才升级 Agent。
|
||
|
||
把任意脚本、任意坐标和不受约束的循环开放给服务端仍不可取：它们无法静态校验，可能绕过任务类型边界，也很难证明不会误触付款。类型化动作注册表保留扩展性，同时让服务端校验参数，让 Android 策略层做最终授权。
|
||
|
||
### 服务端可配置内容
|
||
|
||
- 浏览器包名和精确的“打开拼多多APP”/系统“打开”步骤。
|
||
- PDD 商品详情精确包名、Activity 和根节点证据。
|
||
- 颜色、尺码标题的精确别名列表。
|
||
- 页面、选中、价格稳定超时。
|
||
- 最大商品页纵向滑动、规格横向/纵向滑动和最大 SKU 数量。
|
||
- 固定阶段的安全钩子；当前支持语义目标、方向、次数和动作后等待。
|
||
|
||
例如规格面板打开后向上滑动两次，只需更新规则，不需要修改 Agent：
|
||
|
||
```json
|
||
{
|
||
"hooks": {
|
||
"afterSpecPanelOpen": [
|
||
{
|
||
"action": "swipe",
|
||
"target": "specPanel",
|
||
"direction": "up",
|
||
"count": 2,
|
||
"settleMs": 350
|
||
}
|
||
]
|
||
}
|
||
}
|
||
```
|
||
|
||
### Android 固定内容
|
||
|
||
- 动作注册表与参数边界；规则只能引用 Agent 声明支持的能力，不能提交可执行代码。
|
||
- 规格入口默认使用 `safeBottomSpecEntryV1` 策略，不接受规则提供任意坐标。
|
||
- 价格只能使用固定人民币解析器，金额输出为整数分。
|
||
- 每次颜色点击后必须重新获取内存控件树；不能复用旧节点。
|
||
- 若页面暴露 `selected`/`checked` 或“已选”摘要，必须据此确认颜色已选中。
|
||
- 价格必须连续两次读取一致才算该颜色的价格。
|
||
- 尺码只读，不点击；禁止任何提交订单和支付动作。
|
||
- 每个循环都有次数和总时长上限。
|
||
- `collection` 规则不能调用创建订单动作；未来 `purchase` 规则可以调用专用的 `pddCreateOrderV1`，但付款相关动作在最底层始终拒绝。
|
||
|
||
## 相对源项目的优化
|
||
|
||
1. **不复制 XML 解析实现。** GoAuto 直接把 `AccessibilityNodeInfo` 投影为仅存在内存的不可变树模型，避免序列化、落盘和再次解析 XML。
|
||
2. **保留浏览器链。** 源项目直接深链，GoAuto 则继续验证浏览器提示、系统确认和最终 PDD Activity，符合当前设备部署方式。
|
||
3. **能力协商。** 设备注册/心跳应上报 `rule.schema.v2`、`action.swipe.v1` 和 `collector.pdd.product-detail.v1`；服务端不能把 v2 任务发给旧 APK。只比较 `agentVersion` 不够可靠。
|
||
4. **第三维不静默合并。** 若出现颜色、尺码之外的维度，保存已确认的数据并提交 `completed_partial`，在 `missing` 标记不支持维度；不伪造完整 SKU。源项目当前直接失败，和 GoAuto“数据不齐仍提交”的规则不完全一致。
|
||
5. **缺价不伪造 SKU。** 颜色仍进入维度，缺少稳定价格时记录 `price:<颜色>`；不为该颜色生成带虚构价格的 SKU。
|
||
6. **规则能力版本独立。** `schemaVersion` 管契约形状，`collectorId` 管 Android 算法能力，便于以后修复页面适配而不破坏已有任务快照。
|
||
7. **采集与采购分权。** Agent 平台可以扩展到创建订单，但规则必须声明类型；采集规则无权创建订单，采购规则可以在独立高风险流程中创建订单，任何规则都无权付款。
|
||
|
||
## 建议实施顺序
|
||
|
||
1. 定义 v2 规则契约、设备能力协商和服务端校验。
|
||
2. 建立纯 Kotlin 内存节点树与可单测的 PDD 采集状态机。
|
||
3. 接入无障碍服务的滚动、节点刷新、选中与价格稳定读取。
|
||
4. 在管理端提供内置规则模板，避免管理员手写大段 JSON。
|
||
5. 用一加真机验证浏览器到商品页、多个颜色价格、全部尺码和部分结果。
|
||
|
||
## 当前状态
|
||
|
||
T19～T22 已验收：v2 契约、能力协商、Android 商品详情采集器、服务端内置模板和管理端安全编辑表单已经接入。T23 已在一加真机跑通浏览器跳转、规格面板强识别、颜色文字安全点击、逐颜色稳定价格、全部可见尺码读取和颜色 × 尺码 SKU 展开。T24 进一步迁移并强化了源项目的逐行蛇形算法：用规格节点祖先锁定横纵容器、以文字和 bounds 判断视口、等待手势完成、尺码标题滚出后按容器结构续页。任务 23 使用商品 `236231603269` 得到 14 个颜色、8 个尺码、14 个颜色价格和 112 个完整可用 SKU，状态为 `completed`。T23、T24 实施验证完成，等待用户验收。
|