OPC/goauto
2
0
Fork 0
Code Issues 192 Pull Requests Actions Packages Projects Releases Wiki Activity

T44 采购规格 AI 匹配与实时规格回传（决策变更） #46

New Issue
Open
opened 2026-08-18 15:20:06 +08:00 by ila · 8 comments
ila commented 2026-08-18 15:20:06 +08:00
Owner
Copy Link
Copy Source

基本信息

  • 类型：决策变更 / 跨工单规则修订
  • 所属 MVP / 版本：PDD 自动采购 MVP
  • 阶段：待实施；本单是本次决策的唯一事实来源，被影响的工单与 AGENTS.md 依此修订
  • 提出时间：2026-08-18
  • 来源：用户对话

原始需求摘要

用户要求：当 PDD 商品规格不全或从未采集时，采购过程中先实时采集该商品全部颜色与尺码提交服务端，再调用 AI 匹配接口把 SYB 目标颜色尺码与 PDD 实际规格做匹配，依据匹配结果继续采购；目标是尽量不因 PDD 商品未采集或采集数据过期而导致采购失败。用户明确说明：采购商品单价不高（实测 NT$239~559），愿以个别错误换取人工参与的显著减少。

用户进一步指出：采购时实时采集规格的作用不仅服务当次采购，其本身就是一次商品信息更新，目的是把最新的 PDD 商品信息提交给 admin。

为什么需要本工单

该需求与三处已确认规则冲突，其中两处位于已验收或已关闭的工单中，不能静默修改：

  1. AGENTS.md 永久规则第 14 行：「不猜测规格，不点击相近候选」。
  2. #32（已验收、已关闭）：「Shopee 与 PDD 规格名称不一致，映射由 shopee_products 维护；Agent 不得猜测缺失映射」。
  3. #40（Stage A 原型 2026-08-18 刚验收）：多处表述「系统不会猜测或自动填充缺失映射」「不自动猜测替换值」。

本工单集中记录决策与理由，作为修订上述规则的依据，保证审计链完整。不直接修改已关闭的 #32 正文，改为在本单声明取代关系，并在 #32 的 Wiki 任务归档页追加「后续变更」指针。

需要修改的既有规则

# 位置 现行 修订为
1 AGENTS.md:14 永久规则 「…不使用 OCR/VLM，不猜测规格，不点击相近候选。」 保留「明确失败」与「不使用 OCR/VLM」；规格匹配改为：Agent 本地仍不得自行猜测或点击相近候选，但允许由服务端 AI 匹配接口决策后下发精确规格，Agent 只执行下发结果
2 #32 数据关系规则 「Agent 不得猜测缺失映射」 映射缺失时允许进入 AI 匹配路径；匹配结果必须落库留痕并标记来源
3 #34 「校验 Shopee 到 PDD 商品及规格映射，缺失时明确失败」 缺失时先进入 AI 匹配分支；AI 无结果才明确失败
4 #42 「规格缺失…时明确失败」；验收标准「规格…不满足时停止，不点击相近候选」 同上；验收标准改为「按服务端下发的精确规格执行，Agent 不自行挑选候选」
5 #40 正文与已验收原型 「不自动猜测替换值」「系统不会猜测或自动填充缺失映射」 人工映射优先；缺失或失效时由 AI 匹配补齐并标记来源。原型需相应修改并重新验收
6 #41 正文与原型（未验收） 「比对不上标记存疑，均不猜测、不自动新增规格值」 存疑明细可交由 AI 匹配处理

保持不变的边界

  • 禁止支付：任何自动支付实现、入口或测试仍然禁止。
  • 不使用 OCR/VLM：AI 匹配的输入是无障碍控件树提取的结构化文本，不是截图，该护栏完整保留。
  • 不保存原始控件树与设备截图；防重复下单；地址后缀 _cg{task.id} 规则；task_id + task_attempt_id 幂等；设备与 PDD 账号级互斥。

做什么

0. 统一流程：一条主链路 + 一个兜底，不按场景分支

用户总结的三个常见场景——(1) PDD 规格已完整采集；(2) 规格不全；(3) 只有一个商品链接——经分析不应实现为三条分支，理由是「PDD 数据是否完整」这一判断在系统内不可靠计算：我们没有 ground truth，只知道自己采到了多少个规格值，无法知道 PDD 实际存在多少个。

改用执行时的确定性观察作为分支依据：

服务端用现有档案做 AI 匹配 → 得到目标规格（如「浅蓝 / L」）
Agent 进入规格面板，直接定位目标规格
  ├─ 找到 → 直接选中，不做全量遍历        【快路径，覆盖场景 1】
  └─ 找不到 → 判定档案已过期
        → 触发全量遍历采集规格与颜色价格   【慢路径，覆盖场景 2、3】
        → 提交服务端写回档案 → 重新 AI 匹配 → 下单

场景 3（仅有链接）因档案无规格，AI 匹配无目标可给，天然直接进入慢路径，逻辑自洽，无需额外判断。

采集模块与其步骤保持不变：慢路径复用 #26 已实现的规格面板蛇形遍历与尺码续页能力，只是在采购流程中按需触发，不新建采集实现。

1. 采购时实时规格探测（同时是一次商品信息更新）

  • Agent 打开 PDD 商品页、进入规格面板后，全量回传当前颜色、尺码及颜色对应价格。
  • 该回传按 #31 已有语义写回 pdd_product：遍历完整为 completed → 全量覆盖商品规格与颜色价格；遍历不完整或达到上限为 completed_partial → 只合并不删除。
  • 完整性判定复用 #26（已验收）实现的规格面板蛇形遍历、尺码续页与遍历上限证据，不新发明判定方式。
  • 风险依据：#26 实测出现过「商品 236231603269 只采到颜色、未采到实际存在的尺码」。若不区分完整与部分而一律全量覆盖，将删除数据库中实际存在的规格值。
  • 回传数据标记来源为采购探测，与定时采集任务的结果区分，便于追溯。
  • 快路径也要回传：即使未做全量遍历，也回传本次实际看到的目标规格及其价格，按 completed_partial 语义只合并不删除，保证档案持续更新。
  • 时效兜底：同一 PDD 商品超过 N 天未做过全量刷新时，下次采购强制走慢路径全量遍历。N 值放系统配置（go-admin sys_config），不写死。

2. AI 规格匹配

  • AI 匹配在服务端执行，会发生两次时机：
    1. 派发前：用现有档案匹配，产出目标规格供 Agent 定位（快路径的依据）；
    2. 慢路径回传后：用刚采集到的实时规格重新匹配，产出最终下单规格。
  • 触发慢路径重新匹配的条件：
    1. 人工映射缺失；
    2. PDD 商品档案无规格数据（从未采集、采集失败，或商品为 pending 状态）；
    3. Agent 在规格面板中定位不到派发时下发的目标规格（档案过期，执行时确定性观察）。
  • 输入：SYB 目标颜色与尺码 + 可用的 PDD 规格。
  • 候选集必须限定为实时回传中 selectable 为真的规格，不得从全量规格匹配，避免匹配到售罄不可选项。
  • 输出：精确规格 + 置信度 + 理由。
  • AI 无匹配结果时明确失败，不选默认值、不降级猜测。
  • 同一 task_attempt_id 的匹配结果必须固化，重试不得产生不同答案，否则破坏幂等。

3. 慢路径采用「两趟执行」，不新增 Agent 中途等待能力

本节取代此前拟定的「Agent 暂停 → 上报 → 等待指令 → 恢复」方案。 该方案需要新增执行模型、等待期间延续设备租约、AI 接口超时兜底、断网后恢复中间态等一整套机制，失败面显著扩大。

改为复用 #34 / #42 已有的 task_attempt 机制，把一次同步等待拆成两次独立尝试：

第一趟 attempt：打开商品页 → 全量遍历采集规格与价格 → 提交服务端 → 本趟正常结束
                （任务进入「已采集，待重新派发」状态，释放设备）
服务端      ：离线完成 AI 匹配，不占用设备与租约
第二趟 attempt：重新派发 → Agent 按下发的精确规格直接选中 → 设置数量 → 下单

要求与收益：

  • 不新增 Agent 暂停/恢复执行模型；#42 的演练基线无需扩展该能力。
  • 不需要等待期间延长设备租约，也不需要 AI 接口超时与中间态恢复机制——每一趟都是完整、可独立幂等重试的执行。
  • 「一个任务多次尝试」在 #34（task_id + task_attempt_id 幂等）与 #42（Room 持久化 attempt_id）中已是一等概念，直接复用。
  • 服务端仍需一个表示「已采集、待重新派发」的任务状态，但它是普通的可派发态，不是需要保活的等待态，实现复杂度远低于 awaiting_spec_decision。
  • 代价：慢路径下设备需打开商品页两次。结合第 0 节的快路径，多数订单不会进入慢路径，该代价按需付出。

3b. pending 商品的身份校验

  • #42 要求「验证商品身份」「商品不一致时明确失败」，但 #31 的 pending 商品只有 URL 与 goods_id，没有标题与店铺。
  • 规则：pending 商品的身份校验只依赖 goods_id，不做标题比对。否则将出现拿空标题比对而必然失败的情况。
  • 首次采购探测写回标题与店铺后，商品按 #31 规则转为 active，后续恢复正常的身份校验。

4. 任务留痕与可追溯

  • purchase_tasks 增加 spec_source：manual_mapping / exact_match / ai_match。
  • 保存 AI 匹配的输入输出快照：候选列表、最终选择、置信度、模型版本。
  • 支持按 spec_source = ai_match 批量检索，便于事后一次性排查与纠错。

5. 金额护栏（复用既有机制）

  • 用户的决策前提是「采购商品单价不高」。该前提须固化为可执行约束，而非口头假设。
  • 复用 #42 已有的「订单总价上限」输入与「价格超限时明确失败」机制：AI 匹配得出的规格必须通过总价上限校验才允许下单，超限一律失败转人工。不新增机制。
  • 实时探测拿到的最新颜色价格正好用于该复核，比过期快照准确。

6. 连带效应

  • 规格覆盖写回后须立即重算 #40 的映射失效状态：规格变化可能使既有映射目标消失，此时标记失效正当其时。

不做什么

  • 不实现自动支付、免密支付或支付状态自动识别。
  • 不使用 OCR/VLM，不保存原始控件树与截图。
  • 不允许 Agent 在本地自行猜测规格或点击相近候选；决策权仅在服务端。
  • 不在 AI 无结果时选择默认值或降级匹配。
  • 不修改已关闭的 #32 正文，只声明取代关系。

文档影响

  • AGENTS.md 永久规则第 14 行
  • Wiki Business-Rules-and-Glossary：新增 AI 规格匹配规则条目
  • Wiki Android-Agent-API-Contract：实时规格回传与规格决策下发接口
  • Wiki Product-Requirements-Overview / Delivery-Issues
  • #32 Wiki 任务归档页追加「后续变更」指针
  • #34、#40、#41、#42 正文修订

验收标准

  • 六处规则修订全部完成，且 #32 的取代关系在归档页可追溯。
  • 三种触发条件均可进入 AI 匹配路径，含 pending 状态且无规格的 PDD 商品。
  • AI 候选集仅来自实时回传中可选的规格。
  • AI 无结果时任务明确失败，不产生猜测性下单。
  • 同一 task_attempt_id 重试得到相同匹配结果。
  • 快路径可直接定位目标规格并下单，不触发全量遍历。
  • 慢路径按两趟执行完成，第一趟结束即释放设备，不占用租约等待服务端。
  • 两趟之间任务状态可正常派发，task_attempt_id 幂等成立。
  • pending 商品仅以 goods_id 校验身份，探测写回后转为 active。
  • 超过配置天数未全量刷新的商品，下次采购强制走慢路径。
  • 实时探测按完整/部分正确写回商品档案，部分结果不删除既有规格值。
  • AI 匹配任务可按 spec_source 批量检索。
  • 超出订单总价上限的 AI 匹配结果不会下单。

风险和回退

  • 主要风险：AI 匹配错误将导致真实下错单。用户已知悉并接受该风险，依据为单价低（NT$239~559）且人工成本更高。金额护栏与可追溯打标是缓解手段。
  • AI 决策不可复现是固有代价；通过保存输入输出快照与模型版本部分缓解。
  • 两趟执行使慢路径下设备打开商品页两次，单任务耗时增加；相较中途等待方案，换取的是不引入保活等待态与中间态恢复逻辑。
  • 两趟之间存在时间差，规格仍可能在此期间变化；第二趟定位不到规格时按既有失败路径处理，不再自动重试采集，避免无限循环。
  • 回退方式：spec_source 打标使得关闭 AI 匹配路径后，既有任务仍可解释；规则修订可按本单反向回滚。

实施顺序

必须按「规则 → 原型 → 代码」三阶段推进。依据 AGENTS.md 双门禁：「新页面、独立用户功能、重大交互或导航变化必须先制作 QuantUX 或其他可审阅原型；用户确认文字需求、原型和覆盖范围后才能编写生产代码」。原型不得排在服务端或 Agent 实施之后。

阶段一：规则修订（文字需求）

  1. AGENTS.md:14 永久规则修订。
  2. #32 Wiki 任务归档页追加「后续变更」指针，声明被本单取代的规则（不改已关闭工单正文）。
  3. #34、#40、#41、#42 正文按本单「需要修改的既有规则」表逐条修订。
  4. Wiki Business-Rules-and-Glossary 增补 AI 规格匹配规则条目。

阶段二：原型更新与验收（设计证据）

  1. #40 原型修订并重新验收（优先级最高）。该原型 2026-08-18 已验收通过，正作为实现依据，但本单已使其中「系统不会猜测或自动填充缺失映射」「不自动猜测替换值」等表述失效。已验收但内容过时的原型风险最高，须优先纠正。修订内容：规格值来源增加「自动匹配」「AI 匹配」，状态增加「待确认」；新增「一键确认全部精确匹配」入口与「名称相同不代表尺寸相同」的警示；映射失效复核由「只标记不替换」改为「AI 给候选、人工确认」。
  2. #41 原型修订并首次验收。趁尚未验收，先移除「均不猜测、不自动新增规格值」等已失效表述，避免带过时内容走验收。
  3. 采购侧原型缺口评估（2026-08-19 修正对象）：此前记为「#35 原型缺口」，经核对应区分两部分。
    • 创建流程：已由 #41 Stage A 原型第 9、10 屏覆盖并于 2026-08-19 验收，归属 #44（非 #35），无需另建原型。
    • 任务详情展示：本单引入的 spec_source、AI 匹配快照（候选 / 置信度 / 理由）、两趟执行的 attempt 历史，需在采购任务详情页展示，而 #32 原型仅有框架版、不含这些字段。该部分归属 #35，实施前需评估是否补 Stage A 原型。

阶段三：代码实施

  1. 实时规格探测与写回（可独立交付，同时惠及 #31 商品档案）。
  2. AI 匹配接口与服务端匹配分支（#34）。
  3. 两趟执行所需的任务状态与派发调整（#34）；Agent 侧无需新增等待能力，#42 仅需按下发规格执行。
  4. #40、#41 页面按已验收原型实施。
## 基本信息 - 类型：决策变更 / 跨工单规则修订 - 所属 MVP / 版本：PDD 自动采购 MVP - 阶段：待实施；本单是本次决策的唯一事实来源，被影响的工单与 `AGENTS.md` 依此修订 - 提出时间：2026-08-18 - 来源：用户对话 ## 原始需求摘要 用户要求：当 PDD 商品规格不全或从未采集时，采购过程中先实时采集该商品全部颜色与尺码提交服务端，再调用 AI 匹配接口把 SYB 目标颜色尺码与 PDD 实际规格做匹配，依据匹配结果继续采购；目标是尽量不因 PDD 商品未采集或采集数据过期而导致采购失败。用户明确说明：采购商品单价不高（实测 NT$239~559），愿以个别错误换取人工参与的显著减少。 用户进一步指出：采购时实时采集规格的作用不仅服务当次采购，**其本身就是一次商品信息更新**，目的是把最新的 PDD 商品信息提交给 admin。 ## 为什么需要本工单 该需求与三处已确认规则冲突，其中两处位于已验收或已关闭的工单中，不能静默修改： 1. `AGENTS.md` 永久规则第 14 行：「不猜测规格，不点击相近候选」。 2. `#32`（已验收、已关闭）：「Shopee 与 PDD 规格名称不一致，映射由 `shopee_products` 维护；**Agent 不得猜测缺失映射**」。 3. `#40`（Stage A 原型 2026-08-18 刚验收）：多处表述「系统不会猜测或自动填充缺失映射」「不自动猜测替换值」。 本工单集中记录决策与理由，作为修订上述规则的依据，保证审计链完整。**不直接修改已关闭的 #32 正文**，改为在本单声明取代关系，并在 #32 的 Wiki 任务归档页追加「后续变更」指针。 ## 需要修改的既有规则 | # | 位置 | 现行 | 修订为 | |---|---|---|---| | 1 | `AGENTS.md:14` 永久规则 | 「…不使用 OCR/VLM，不猜测规格，不点击相近候选。」 | 保留「明确失败」与「不使用 OCR/VLM」；规格匹配改为：**Agent 本地仍不得自行猜测或点击相近候选**，但允许由服务端 AI 匹配接口决策后下发精确规格，Agent 只执行下发结果 | | 2 | `#32` 数据关系规则 | 「Agent 不得猜测缺失映射」 | 映射缺失时允许进入 AI 匹配路径；匹配结果必须落库留痕并标记来源 | | 3 | `#34` | 「校验 Shopee 到 PDD 商品及规格映射，缺失时明确失败」 | 缺失时先进入 AI 匹配分支；AI 无结果才明确失败 | | 4 | `#42` | 「规格缺失…时明确失败」；验收标准「规格…不满足时停止，不点击相近候选」 | 同上；验收标准改为「按服务端下发的精确规格执行，Agent 不自行挑选候选」 | | 5 | `#40` 正文与已验收原型 | 「不自动猜测替换值」「系统不会猜测或自动填充缺失映射」 | 人工映射优先；缺失或失效时由 AI 匹配补齐并标记来源。**原型需相应修改并重新验收** | | 6 | `#41` 正文与原型（未验收） | 「比对不上标记存疑，均不猜测、不自动新增规格值」 | 存疑明细可交由 AI 匹配处理 | ## 保持不变的边界 - **禁止支付**：任何自动支付实现、入口或测试仍然禁止。 - **不使用 OCR/VLM**：AI 匹配的输入是无障碍控件树提取的结构化文本，不是截图，该护栏完整保留。 - 不保存原始控件树与设备截图；防重复下单；地址后缀 `_cg{task.id}` 规则；`task_id + task_attempt_id` 幂等；设备与 PDD 账号级互斥。 ## 做什么 ### 0. 统一流程：一条主链路 + 一个兜底，不按场景分支 用户总结的三个常见场景——(1) PDD 规格已完整采集；(2) 规格不全；(3) 只有一个商品链接——经分析**不应实现为三条分支**，理由是「PDD 数据是否完整」这一判断在系统内不可靠计算：我们没有 ground truth，只知道自己采到了多少个规格值，无法知道 PDD 实际存在多少个。 改用**执行时的确定性观察**作为分支依据： ``` 服务端用现有档案做 AI 匹配 → 得到目标规格（如「浅蓝 / L」） Agent 进入规格面板，直接定位目标规格 ├─ 找到 → 直接选中，不做全量遍历 【快路径，覆盖场景 1】 └─ 找不到 → 判定档案已过期 → 触发全量遍历采集规格与颜色价格 【慢路径，覆盖场景 2、3】 → 提交服务端写回档案 → 重新 AI 匹配 → 下单 ``` 场景 3（仅有链接）因档案无规格，AI 匹配无目标可给，天然直接进入慢路径，逻辑自洽，无需额外判断。 **采集模块与其步骤保持不变**：慢路径复用 `#26` 已实现的规格面板蛇形遍历与尺码续页能力，只是在采购流程中按需触发，不新建采集实现。 ### 1. 采购时实时规格探测（同时是一次商品信息更新） - Agent 打开 PDD 商品页、进入规格面板后，全量回传当前颜色、尺码及颜色对应价格。 - **该回传按 `#31` 已有语义写回 `pdd_product`**：遍历完整为 `completed` → 全量覆盖商品规格与颜色价格；遍历不完整或达到上限为 `completed_partial` → 只合并不删除。 - 完整性判定复用 `#26`（已验收）实现的规格面板蛇形遍历、尺码续页与遍历上限证据，不新发明判定方式。 - **风险依据**：`#26` 实测出现过「商品 236231603269 只采到颜色、未采到实际存在的尺码」。若不区分完整与部分而一律全量覆盖，将删除数据库中实际存在的规格值。 - 回传数据标记来源为采购探测，与定时采集任务的结果区分，便于追溯。 - **快路径也要回传**：即使未做全量遍历，也回传本次实际看到的目标规格及其价格，按 `completed_partial` 语义只合并不删除，保证档案持续更新。 - **时效兜底**：同一 PDD 商品超过 N 天未做过全量刷新时，下次采购强制走慢路径全量遍历。N 值放系统配置（go-admin `sys_config`），不写死。 ### 2. AI 规格匹配 - AI 匹配在服务端执行，会发生两次时机： 1. **派发前**：用现有档案匹配，产出目标规格供 Agent 定位（快路径的依据）； 2. **慢路径回传后**：用刚采集到的实时规格重新匹配，产出最终下单规格。 - 触发慢路径重新匹配的条件： 1. 人工映射缺失； 2. **PDD 商品档案无规格数据**（从未采集、采集失败，或商品为 `pending` 状态）； 3. Agent 在规格面板中定位不到派发时下发的目标规格（档案过期，执行时确定性观察）。 - 输入：SYB 目标颜色与尺码 + 可用的 PDD 规格。 - **候选集必须限定为实时回传中 `selectable` 为真的规格**，不得从全量规格匹配，避免匹配到售罄不可选项。 - 输出：精确规格 + 置信度 + 理由。 - **AI 无匹配结果时明确失败**，不选默认值、不降级猜测。 - 同一 `task_attempt_id` 的匹配结果必须固化，重试不得产生不同答案，否则破坏幂等。 ### 3. 慢路径采用「两趟执行」，不新增 Agent 中途等待能力 **本节取代此前拟定的「Agent 暂停 → 上报 → 等待指令 → 恢复」方案。** 该方案需要新增执行模型、等待期间延续设备租约、AI 接口超时兜底、断网后恢复中间态等一整套机制，失败面显著扩大。 改为复用 `#34` / `#42` 已有的 `task_attempt` 机制，把一次同步等待拆成两次独立尝试： ``` 第一趟 attempt：打开商品页 → 全量遍历采集规格与价格 → 提交服务端 → 本趟正常结束 （任务进入「已采集，待重新派发」状态，释放设备） 服务端 ：离线完成 AI 匹配，不占用设备与租约 第二趟 attempt：重新派发 → Agent 按下发的精确规格直接选中 → 设置数量 → 下单 ``` 要求与收益： - **不新增** Agent 暂停/恢复执行模型；`#42` 的演练基线无需扩展该能力。 - **不需要**等待期间延长设备租约，也不需要 AI 接口超时与中间态恢复机制——每一趟都是完整、可独立幂等重试的执行。 - 「一个任务多次尝试」在 `#34`（`task_id + task_attempt_id` 幂等）与 `#42`（Room 持久化 `attempt_id`）中已是一等概念，直接复用。 - 服务端仍需一个表示「已采集、待重新派发」的任务状态，但它是**普通的可派发态**，不是需要保活的等待态，实现复杂度远低于 `awaiting_spec_decision`。 - 代价：慢路径下设备需打开商品页两次。结合第 0 节的快路径，多数订单不会进入慢路径，该代价按需付出。 ### 3b. `pending` 商品的身份校验 - `#42` 要求「验证商品身份」「商品不一致时明确失败」，但 `#31` 的 `pending` 商品只有 URL 与 `goods_id`，没有标题与店铺。 - 规则：**`pending` 商品的身份校验只依赖 `goods_id`，不做标题比对**。否则将出现拿空标题比对而必然失败的情况。 - 首次采购探测写回标题与店铺后，商品按 `#31` 规则转为 `active`，后续恢复正常的身份校验。 ### 4. 任务留痕与可追溯 - `purchase_tasks` 增加 `spec_source`：`manual_mapping` / `exact_match` / `ai_match`。 - 保存 AI 匹配的输入输出快照：候选列表、最终选择、置信度、模型版本。 - 支持按 `spec_source = ai_match` 批量检索，便于事后一次性排查与纠错。 ### 5. 金额护栏（复用既有机制） - 用户的决策前提是「采购商品单价不高」。该前提须固化为可执行约束，而非口头假设。 - **复用 `#42` 已有的「订单总价上限」输入与「价格超限时明确失败」机制**：AI 匹配得出的规格必须通过总价上限校验才允许下单，超限一律失败转人工。不新增机制。 - 实时探测拿到的最新颜色价格正好用于该复核，比过期快照准确。 ### 6. 连带效应 - 规格覆盖写回后须**立即重算 `#40` 的映射失效状态**：规格变化可能使既有映射目标消失，此时标记失效正当其时。 ## 不做什么 - 不实现自动支付、免密支付或支付状态自动识别。 - 不使用 OCR/VLM，不保存原始控件树与截图。 - 不允许 Agent 在本地自行猜测规格或点击相近候选；决策权仅在服务端。 - 不在 AI 无结果时选择默认值或降级匹配。 - 不修改已关闭的 `#32` 正文，只声明取代关系。 ## 文档影响 - [ ] `AGENTS.md` 永久规则第 14 行 - [ ] Wiki `Business-Rules-and-Glossary`：新增 AI 规格匹配规则条目 - [ ] Wiki `Android-Agent-API-Contract`：实时规格回传与规格决策下发接口 - [ ] Wiki `Product-Requirements-Overview` / `Delivery-Issues` - [ ] `#32` Wiki 任务归档页追加「后续变更」指针 - [ ] `#34`、`#40`、`#41`、`#42` 正文修订 ## 验收标准 - [ ] 六处规则修订全部完成，且 `#32` 的取代关系在归档页可追溯。 - [ ] 三种触发条件均可进入 AI 匹配路径，含 `pending` 状态且无规格的 PDD 商品。 - [ ] AI 候选集仅来自实时回传中可选的规格。 - [ ] AI 无结果时任务明确失败，不产生猜测性下单。 - [ ] 同一 `task_attempt_id` 重试得到相同匹配结果。 - [ ] 快路径可直接定位目标规格并下单，不触发全量遍历。 - [ ] 慢路径按两趟执行完成，第一趟结束即释放设备，不占用租约等待服务端。 - [ ] 两趟之间任务状态可正常派发，`task_attempt_id` 幂等成立。 - [ ] `pending` 商品仅以 `goods_id` 校验身份，探测写回后转为 `active`。 - [ ] 超过配置天数未全量刷新的商品，下次采购强制走慢路径。 - [ ] 实时探测按完整/部分正确写回商品档案，部分结果不删除既有规格值。 - [ ] AI 匹配任务可按 `spec_source` 批量检索。 - [ ] 超出订单总价上限的 AI 匹配结果不会下单。 ## 风险和回退 - **主要风险**：AI 匹配错误将导致真实下错单。用户已知悉并接受该风险，依据为单价低（NT$239~559）且人工成本更高。金额护栏与可追溯打标是缓解手段。 - AI 决策不可复现是固有代价；通过保存输入输出快照与模型版本部分缓解。 - 两趟执行使慢路径下设备打开商品页两次，单任务耗时增加；相较中途等待方案，换取的是不引入保活等待态与中间态恢复逻辑。 - 两趟之间存在时间差，规格仍可能在此期间变化；第二趟定位不到规格时按既有失败路径处理，不再自动重试采集，避免无限循环。 - 回退方式：`spec_source` 打标使得关闭 AI 匹配路径后，既有任务仍可解释；规则修订可按本单反向回滚。 ## 实施顺序 必须按「规则 → 原型 → 代码」三阶段推进。依据 `AGENTS.md` 双门禁：「新页面、独立用户功能、重大交互或导航变化必须先制作 QuantUX 或其他可审阅原型；**用户确认文字需求、原型和覆盖范围后才能编写生产代码**」。原型不得排在服务端或 Agent 实施之后。 ### 阶段一：规则修订（文字需求） 1. `AGENTS.md:14` 永久规则修订。 2. `#32` Wiki 任务归档页追加「后续变更」指针，声明被本单取代的规则（不改已关闭工单正文）。 3. `#34`、`#40`、`#41`、`#42` 正文按本单「需要修改的既有规则」表逐条修订。 4. Wiki `Business-Rules-and-Glossary` 增补 AI 规格匹配规则条目。 ### 阶段二：原型更新与验收（设计证据） 5. **`#40` 原型修订并重新验收**（优先级最高）。该原型 2026-08-18 已验收通过，正作为实现依据，但本单已使其中「系统不会猜测或自动填充缺失映射」「不自动猜测替换值」等表述失效。**已验收但内容过时的原型风险最高**，须优先纠正。修订内容：规格值来源增加「自动匹配」「AI 匹配」，状态增加「待确认」；新增「一键确认全部精确匹配」入口与「名称相同不代表尺寸相同」的警示；映射失效复核由「只标记不替换」改为「AI 给候选、人工确认」。 6. **`#41` 原型修订并首次验收**。趁尚未验收，先移除「均不猜测、不自动新增规格值」等已失效表述，避免带过时内容走验收。 7. **采购侧原型缺口评估（2026-08-19 修正对象）**：此前记为「#35 原型缺口」，经核对应区分两部分。 - **创建流程**：已由 #41 Stage A 原型第 9、10 屏覆盖并于 2026-08-19 验收，归属 **#44**（非 #35），无需另建原型。 - **任务详情展示**：本单引入的 `spec_source`、AI 匹配快照（候选 / 置信度 / 理由）、两趟执行的 attempt 历史，需在采购任务详情页展示，而 `#32` 原型仅有框架版、不含这些字段。该部分归属 **#35**，实施前需评估是否补 Stage A 原型。 ### 阶段三：代码实施 8. 实时规格探测与写回（可独立交付，同时惠及 `#31` 商品档案）。 9. AI 匹配接口与服务端匹配分支（`#34`）。 10. 两趟执行所需的任务状态与派发调整（`#34`）；Agent 侧无需新增等待能力，`#42` 仅需按下发规格执行。 11. `#40`、`#41` 页面按已验收原型实施。
ila commented 2026-08-18 15:40:00 +08:00
Author
Owner
Copy Link
Copy Source

依据用户的三场景总结，更新流程设计（四项优化）

用户总结了三个常见场景，并给出关键约束：「采集模块和步骤不变，在采购时也根据情况增加数据采集」。顺此推导，工单正文已作四处修改。

1. 三场景合并为一条主链路，不按场景分支

场景 2（规格不全）与场景 3（仅有链接）步骤完全相同，仅起始状态不同；场景 1 与之相差一步采集。

不采用「按数据是否完整分支」，因为该判断在系统内不可靠计算：我们没有 ground truth，只知道自己采到了几个规格值，无法得知 PDD 实际存在多少个。基于算不出来的量做分支，必然不稳定。

改用执行时的确定性观察：Agent 按派发的目标规格去规格面板定位，找得到走快路径，找不到走慢路径。场景 3 因档案无规格、AI 给不出目标，天然进入慢路径。三条分支收敛为一条主链路加一个兜底。

2. 慢路径改用「两趟执行」，取代此前的「Agent 中途等待」

此前拟定的方案需要 Agent 新增「暂停 → 上报 → 等待指令 → 恢复」执行模型，并配套等待期间延续设备租约、AI 接口超时兜底、断网后恢复中间态等机制，失败面显著扩大。

改为复用 #34 / #42 已有的 task_attempt 机制拆成两次独立尝试：第一趟采集完即结束并释放设备，服务端离线匹配，第二趟重新派发直接下单。

收益：不新增 Agent 执行模型、不需要保活等待态、不需要中间态恢复；每趟都是完整可幂等重试的执行。代价是慢路径下设备打开商品页两次，但结合快路径，多数订单不会付出该代价。

这一项使 #42 的改造量显著下降——Agent 只需按服务端下发的精确规格执行，不需要理解等待语义。

3. 补充 pending 商品的身份校验规则

#42 要求「验证商品身份」「商品不一致时明确失败」，但 #31 的 pending 商品只有 URL 与 goods_id，没有标题与店铺。原方案未覆盖此点，实施时会出现拿空标题比对而必然失败的情况。

规则定为：pending 商品仅以 goods_id 校验身份，不做标题比对；首次采购探测写回标题店铺后按 #31 规则转 active，恢复正常校验。

4. 快路径也回传，并加时效兜底

用户明确实时采集的目的之一是「把最新 PDD 商品信息提交给 admin」。但快路径不做全量遍历，若完全不回传则档案得不到更新。

  • 快路径回传本次实际看到的目标规格及价格，按 completed_partial 语义只合并不删除；
  • 同一商品超过 N 天未全量刷新时，下次采购强制走慢路径全量遍历，N 值放 sys_config，不写死。

同时更新

  • 验收标准新增 5 条（快路径不触发遍历、两趟执行释放设备、attempt 幂等、pending 身份校验、时效强制刷新）。
  • 风险段落替换：两趟执行的代价改为耗时增加；新增「两趟之间规格仍可能变化，第二趟定位失败按既有失败路径处理，不自动重试采集以避免无限循环」。
  • 实施顺序第 4 步由「Agent 中途等待能力」改为「两趟执行的任务状态与派发调整」。

未变更部分

禁止支付、不使用 OCR/VLM、不保存控件树与截图、AI 无结果即失败、候选集限定为实时可选规格、金额护栏复用 #42 订单总价上限、spec_source 打标可追溯——均保持不变。

## 依据用户的三场景总结，更新流程设计（四项优化） 用户总结了三个常见场景，并给出关键约束：**「采集模块和步骤不变，在采购时也根据情况增加数据采集」**。顺此推导，工单正文已作四处修改。 ### 1. 三场景合并为一条主链路，不按场景分支 场景 2（规格不全）与场景 3（仅有链接）步骤完全相同，仅起始状态不同；场景 1 与之相差一步采集。 **不采用「按数据是否完整分支」，因为该判断在系统内不可靠计算**：我们没有 ground truth，只知道自己采到了几个规格值，无法得知 PDD 实际存在多少个。基于算不出来的量做分支，必然不稳定。 改用执行时的确定性观察：Agent 按派发的目标规格去规格面板定位，**找得到走快路径，找不到走慢路径**。场景 3 因档案无规格、AI 给不出目标，天然进入慢路径。三条分支收敛为一条主链路加一个兜底。 ### 2. 慢路径改用「两趟执行」，取代此前的「Agent 中途等待」 此前拟定的方案需要 Agent 新增「暂停 → 上报 → 等待指令 → 恢复」执行模型，并配套等待期间延续设备租约、AI 接口超时兜底、断网后恢复中间态等机制，失败面显著扩大。 改为复用 `#34` / `#42` 已有的 `task_attempt` 机制拆成两次独立尝试：第一趟采集完即结束并释放设备，服务端离线匹配，第二趟重新派发直接下单。 收益：不新增 Agent 执行模型、不需要保活等待态、不需要中间态恢复；每趟都是完整可幂等重试的执行。代价是慢路径下设备打开商品页两次，但结合快路径，多数订单不会付出该代价。 **这一项使 `#42` 的改造量显著下降**——Agent 只需按服务端下发的精确规格执行，不需要理解等待语义。 ### 3. 补充 `pending` 商品的身份校验规则 `#42` 要求「验证商品身份」「商品不一致时明确失败」，但 `#31` 的 `pending` 商品只有 URL 与 `goods_id`，没有标题与店铺。原方案未覆盖此点，实施时会出现拿空标题比对而必然失败的情况。 规则定为：**`pending` 商品仅以 `goods_id` 校验身份，不做标题比对**；首次采购探测写回标题店铺后按 `#31` 规则转 `active`，恢复正常校验。 ### 4. 快路径也回传，并加时效兜底 用户明确实时采集的目的之一是「把最新 PDD 商品信息提交给 admin」。但快路径不做全量遍历，若完全不回传则档案得不到更新。 - 快路径回传本次实际看到的目标规格及价格，按 `completed_partial` 语义只合并不删除； - 同一商品超过 N 天未全量刷新时，下次采购强制走慢路径全量遍历，N 值放 `sys_config`，不写死。 ### 同时更新 - 验收标准新增 5 条（快路径不触发遍历、两趟执行释放设备、attempt 幂等、`pending` 身份校验、时效强制刷新）。 - 风险段落替换：两趟执行的代价改为耗时增加；新增「两趟之间规格仍可能变化，第二趟定位失败按既有失败路径处理，不自动重试采集以避免无限循环」。 - 实施顺序第 4 步由「Agent 中途等待能力」改为「两趟执行的任务状态与派发调整」。 ### 未变更部分 禁止支付、不使用 OCR/VLM、不保存控件树与截图、AI 无结果即失败、候选集限定为实时可选规格、金额护栏复用 `#42` 订单总价上限、`spec_source` 打标可追溯——均保持不变。
ila commented 2026-08-18 15:48:14 +08:00
Author
Owner
Copy Link
Copy Source

阶段一（规则修订）完成

实施顺序已先行改为「规则 → 原型 → 代码」三阶段，原因：此前把原型排在服务端实施之后，违反 AGENTS.md 双门禁「用户确认文字需求、原型和覆盖范围后才能编写生产代码」。

1. AGENTS.md:14 永久规则

原条目拆为两条：

- 找不到控件、验证码、风控、人机验证或登录失效时明确失败，不使用 OCR/VLM。
- 规格匹配：Agent 本地不得自行猜测规格或点击相近候选，只执行服务端下发的精确规格；
  人工映射缺失、商品无规格数据或目标规格定位不到时，由服务端 AI 匹配接口决策（见 #46），
  AI 无结果时明确失败。

「不使用 OCR/VLM」完整保留（AI 匹配的输入是无障碍控件树提取的结构化文本，非截图）；「Agent 本地不猜测、不点击相近候选」也保留，只是决策权移至服务端。

2. #32 归档页追加「后续变更」

未修改已关闭工单正文。在 Wiki Task 32 procurement closed loop prototype 追加变更表，声明「Agent 不得猜测缺失映射」被本单取代，并记录变更依据（单价 NT$239~559，用户接受个别错误以减少人工参与）与金额护栏。同时明确列出未变更的规则：禁止支付、不使用 OCR/VLM、不保存控件树截图、地址后缀、防重复下单、幂等、设备与账号互斥。

3. 四张工单正文修订

  • #34：映射缺失/无规格数据/定位不到目标规格时进入 AI 匹配分支，AI 无结果才失败；补充两趟执行所需的「已采集、待重新派发」普通可派发状态（非保活等待态）；task_attempt_id 匹配结果固化。
  • #42：「规格缺失时明确失败」改为触发采集回传并结束本趟；Agent 只按下发规格执行；补充 pending 商品仅以 goods_id 校验身份；验收标准同步调整。
  • #40：映射失效可由 AI 给候选但须人工确认；名称完全相等时自动预填并置于「待确认」，明确「名称相同不代表实物尺寸相同（台湾码与大陆码）」不得自动生效；映射来源区分 manual / exact_match / ai_match。
  • #41：SYB 域自身仍不猜测、不自动新增规格值，但存疑与失败明细可在采购阶段交由服务端 AI 匹配处理，SYB 只如实标记状态、不阻断采购。

四张单正文末尾均追加了指向本单的修订说明。

4. Wiki Business-Rules-and-Glossary

  • 自动化边界：「不猜测缺失数据」限定为采集阶段；新增采购阶段规格匹配由服务端决策的条目。
  • 术语表新增 7 条：虾皮、货运宝 / SYB、AI 规格匹配、快路径 / 慢路径、两趟执行、采购探测、spec_source。

镜像已导出，sync_wiki_docs.py --check 通过。提交 faecd90。

下一步

进入阶段二：优先修订 #40 原型并重新验收（该原型已验收但内容已被本单动摇，风险最高），随后修订 #41 原型并首次验收。

## 阶段一（规则修订）完成 实施顺序已先行改为「规则 → 原型 → 代码」三阶段，原因：此前把原型排在服务端实施之后，违反 `AGENTS.md` 双门禁「用户确认文字需求、原型和覆盖范围后才能编写生产代码」。 ### 1. `AGENTS.md:14` 永久规则 原条目拆为两条： ``` - 找不到控件、验证码、风控、人机验证或登录失效时明确失败，不使用 OCR/VLM。 - 规格匹配：Agent 本地不得自行猜测规格或点击相近候选，只执行服务端下发的精确规格； 人工映射缺失、商品无规格数据或目标规格定位不到时，由服务端 AI 匹配接口决策（见 #46）， AI 无结果时明确失败。 ``` 「不使用 OCR/VLM」完整保留（AI 匹配的输入是无障碍控件树提取的结构化文本，非截图）；「Agent 本地不猜测、不点击相近候选」也保留，只是决策权移至服务端。 ### 2. `#32` 归档页追加「后续变更」 未修改已关闭工单正文。在 Wiki [Task 32 procurement closed loop prototype](https://git.ilapage.cn/OPC/goauto/wiki/Task-32-procurement-closed-loop-prototype) 追加变更表，声明「Agent 不得猜测缺失映射」被本单取代，并记录变更依据（单价 NT$239~559，用户接受个别错误以减少人工参与）与金额护栏。同时明确列出**未变更**的规则：禁止支付、不使用 OCR/VLM、不保存控件树截图、地址后缀、防重复下单、幂等、设备与账号互斥。 ### 3. 四张工单正文修订 - **`#34`**：映射缺失/无规格数据/定位不到目标规格时进入 AI 匹配分支，AI 无结果才失败；补充两趟执行所需的「已采集、待重新派发」**普通可派发状态**（非保活等待态）；`task_attempt_id` 匹配结果固化。 - **`#42`**：「规格缺失时明确失败」改为触发采集回传并结束本趟；Agent 只按下发规格执行；补充 `pending` 商品仅以 `goods_id` 校验身份；验收标准同步调整。 - **`#40`**：映射失效可由 AI 给候选但须人工确认；名称完全相等时自动预填并置于「待确认」，明确「名称相同不代表实物尺寸相同（台湾码与大陆码）」不得自动生效；映射来源区分 `manual` / `exact_match` / `ai_match`。 - **`#41`**：SYB 域自身仍不猜测、不自动新增规格值，但存疑与失败明细可在采购阶段交由服务端 AI 匹配处理，SYB 只如实标记状态、不阻断采购。 四张单正文末尾均追加了指向本单的修订说明。 ### 4. Wiki `Business-Rules-and-Glossary` - 自动化边界：「不猜测缺失数据」限定为采集阶段；新增采购阶段规格匹配由服务端决策的条目。 - 术语表新增 7 条：虾皮、货运宝 / SYB、AI 规格匹配、快路径 / 慢路径、两趟执行、采购探测、`spec_source`。 镜像已导出，`sync_wiki_docs.py --check` 通过。提交 `faecd90`。 ### 下一步 进入阶段二：优先修订 `#40` 原型并重新验收（该原型已验收但内容已被本单动摇，风险最高），随后修订 `#41` 原型并首次验收。
ila commented 2026-08-19 08:54:33 +08:00
Author
Owner
Copy Link
Copy Source

Stage A 原型验收通过

用户 2026-08-19 明确回复「验收通过 SYB 商品和虾皮商品两个模块原型」。两个工单的 Stage A 门禁均已解除，Stage B 代码实施可以开始。

工单保持 open：本次通过的是 Stage A 原型门禁，非整单验收。Stage B（迁移、服务端、Admin 页面、测试与文档）尚未开始。

已确认的原型

工单 App ID 规模 验证
#40 虾皮商品档案 6a83b708191a826306a7eeb1 10 页 / 727 控件 / 71 条流程线 verdict=PASS，越界 0
#41 SYB 商品导入 6a83d7b4191a826306a7eebd 10 页 / 674 控件 / 44 条流程线 verdict=PASS，越界 0

离线导出均为零外链单文件，位于 prototypes/。

本次验收覆盖的关键设计

  • 展示术语：虾皮（Shopee）、SYB（顺云宝 ERP）、货运单（SYB 内单据）三者边界清晰；程序标识符保持 shopee_* / syb_*。
  • 规格映射三种来源：人工 / 精确匹配 / AI 建议，均需人工确认；一键确认仅对精确匹配生效，AI 建议须逐条确认；附「名称相同不代表实物尺寸相同」警示。
  • 采购在 SYB 商品列表发起：勾选 → 创建采购 → 逐条校验确认 → 批量结果；一条明细 = 一个独立任务，不合并不拆单；相关页面标注由 #35 实现。
  • 解析状态只如实标记：存疑不阻断采购（AI 直接用 SYB 原始颜色尺码匹配 PDD 实际规格），仅解析失败阻断。
  • 批量软删除含引用检查与部分成功反馈；shopee_item_id 唯一约束需与软删除并存。
  • 搜索框支持粘贴多行批量查询，附命中/未找到统计；✕ 只清搜索、重置清全部条件。

遗留项（Stage B 实施时处理，不阻塞本次验收）

  1. 「重新解析」的范围提示：该按钮可勾选到已成功解析的行，规则变更后重跑存在把原本正确的结果改错的风险，需在实施时补充范围提示或限定为仅对失败/存疑行生效。
  2. 「重新解析」缺结果反馈：当前直接跳转解析错误清单，未返回「成功 / 仍失败 / 跳过（人工已修正）」的逐条统计，与本项目既有的批量操作反馈模式（#45、#40 批量删除、#41 导入结果）不一致。
  3. details[].id 全局唯一性未验证：现有 HAR 仅含一张货运单的两条明细，样本不足。唯一键当前保守取「货运单号 + 来源明细ID」组合，安全但索引偏宽。
  4. #35 原型缺口：#46 引入的 spec_source、AI 匹配快照、两趟执行的 attempt 历史需在采购任务详情页展示，#32 原型仅有框架版，#35 实施前需评估是否补 Stage A 原型。

文档同步

Wiki Product-Requirements-Overview 与 Delivery-Issues 已更新为「Stage A 原型 2026-08-19 已通过，Stage B 待实施」；镜像已导出并通过一致性检查。prototypes/README.md 标记四份原型均可作为实现依据。提交 80434ec。

同时将 #40 标题由「T38 Shopee 商品档案、PDD 关联与规格映射」改为「T38 虾皮商品档案、PDD 关联与规格映射」，与术语决策一致。

#46 阶段进度

  • 阶段一 规则修订：已完成
  • 阶段二 原型更新与验收：已完成（第 7 项 #35 原型缺口评估留待 #35 实施前）
  • 阶段三 代码实施：可以开始
## Stage A 原型验收通过 用户 2026-08-19 明确回复「验收通过 SYB 商品和虾皮商品两个模块原型」。两个工单的 Stage A 门禁均已解除，Stage B 代码实施可以开始。 **工单保持 open**：本次通过的是 Stage A 原型门禁，非整单验收。Stage B（迁移、服务端、Admin 页面、测试与文档）尚未开始。 ### 已确认的原型 | 工单 | App ID | 规模 | 验证 | |---|---|---|---| | #40 虾皮商品档案 | `6a83b708191a826306a7eeb1` | 10 页 / 727 控件 / 71 条流程线 | `verdict=PASS`，越界 0 | | #41 SYB 商品导入 | `6a83d7b4191a826306a7eebd` | 10 页 / 674 控件 / 44 条流程线 | `verdict=PASS`，越界 0 | 离线导出均为零外链单文件，位于 `prototypes/`。 ### 本次验收覆盖的关键设计 - 展示术语：**虾皮**（Shopee）、**SYB**（顺云宝 ERP）、**货运单**（SYB 内单据）三者边界清晰；程序标识符保持 `shopee_*` / `syb_*`。 - 规格映射三种来源：`人工` / `精确匹配` / `AI 建议`，均需人工确认；一键确认仅对精确匹配生效，AI 建议须逐条确认；附「名称相同不代表实物尺寸相同」警示。 - 采购在 SYB 商品列表发起：勾选 → 创建采购 → 逐条校验确认 → 批量结果；**一条明细 = 一个独立任务**，不合并不拆单；相关页面标注由 #35 实现。 - 解析状态只如实标记：**存疑不阻断采购**（AI 直接用 SYB 原始颜色尺码匹配 PDD 实际规格），仅解析失败阻断。 - 批量软删除含引用检查与部分成功反馈；`shopee_item_id` 唯一约束需与软删除并存。 - 搜索框支持粘贴多行批量查询，附命中/未找到统计；✕ 只清搜索、重置清全部条件。 ### 遗留项（Stage B 实施时处理，不阻塞本次验收） 1. **「重新解析」的范围提示**：该按钮可勾选到已成功解析的行，规则变更后重跑存在把原本正确的结果改错的风险，需在实施时补充范围提示或限定为仅对失败/存疑行生效。 2. **「重新解析」缺结果反馈**：当前直接跳转解析错误清单，未返回「成功 / 仍失败 / 跳过（人工已修正）」的逐条统计，与本项目既有的批量操作反馈模式（#45、#40 批量删除、#41 导入结果）不一致。 3. **`details[].id` 全局唯一性未验证**：现有 HAR 仅含一张货运单的两条明细，样本不足。唯一键当前保守取「货运单号 + 来源明细ID」组合，安全但索引偏宽。 4. **#35 原型缺口**：#46 引入的 `spec_source`、AI 匹配快照、两趟执行的 attempt 历史需在采购任务详情页展示，#32 原型仅有框架版，#35 实施前需评估是否补 Stage A 原型。 ### 文档同步 Wiki `Product-Requirements-Overview` 与 `Delivery-Issues` 已更新为「Stage A 原型 2026-08-19 已通过，Stage B 待实施」；镜像已导出并通过一致性检查。`prototypes/README.md` 标记四份原型均可作为实现依据。提交 `80434ec`。 同时将 #40 标题由「T38 Shopee 商品档案、PDD 关联与规格映射」改为「T38 虾皮商品档案、PDD 关联与规格映射」，与术语决策一致。 ### #46 阶段进度 - 阶段一 规则修订：**已完成** - 阶段二 原型更新与验收：**已完成**（第 7 项 #35 原型缺口评估留待 #35 实施前） - 阶段三 代码实施：**可以开始**
ila commented 2026-08-19 09:45:46 +08:00
Author
Owner
Copy Link
Copy Source

三工单边界核对结果（#35 / #41 / #44）

用户 2026-08-19 要求核对 #35、#41、#44 的边界。核对发现四个问题，均已修复。

职责划分（收敛后）

工单 职责
#41 T39 SYB 数据域：导入、解析、明细数据与列表本身
#44 T42 全部采购任务创建能力：SYB 列表勾选与批量入口、单条入口、创建确认页、创建结果页
#35 T33 已存在任务的管理：任务列表、任务详情、执行状态、重新采购、有效订单选择、物流回填

问题一：#41 原型的归属标注错误（已修复）

#41 Stage A 原型第 9、10 屏及列表页的采购入口说明，此前标注「本页由 #35 实现」。经核对 #44 正文——「SYB 商品列表左侧勾选后批量创建」「表头全选只选择当前页」「不可创建行禁用并显示原因」「每条分别创建一个任务，禁止合并」「批量结果逐条显示」——与该原型逐条对应，归属应为 #44。

已更正 3 处标注，导出文件中「由 #35 实现」残留 0 处，verdict=PASS。提交 1cd32a4。

问题二：#35 与 #44 都声称拥有创建确认页（已收敛）

  • #35 原文：「创建采购任务确认：PDD账号/设备、目标规格、映射规格、数量和 _cg{task.id} 提示」
  • #44 原文：「批量确认和结果」

按能力而非入口切分：创建是一个完整能力，拆到两个工单会导致确认页被实现两遍或互相等待。创建能力整体归 #44，#35 收敛为管理已有任务。两张工单正文均已更新并注明移交关系。

问题三：#44 状态过期（已更新）

原写「阶段：待实施；受 #32 原型审核门禁阻塞」。实际 #32 已于 2026-08-18 验收，#40、#41 原型已于 2026-08-19 验收，三个前置门禁全部解除，#44 现为可实施状态。

问题四：本单阶段二第 7 项记错对象（已修正）

「#35 原型缺口」应拆为两部分：创建流程已由 #41 原型覆盖且归属 #44，无需另建原型；任务详情展示 spec_source、AI 匹配快照与两趟 attempt 历史的部分才归 #35，实施前需评估。正文第 7 项已改写。

## 三工单边界核对结果（#35 / #41 / #44） 用户 2026-08-19 要求核对 #35、#41、#44 的边界。核对发现四个问题，均已修复。 ### 职责划分（收敛后） | 工单 | 职责 | |---|---| | **#41** T39 | SYB 数据域：导入、解析、明细数据与列表本身 | | **#44** T42 | **全部采购任务创建能力**：SYB 列表勾选与批量入口、单条入口、创建确认页、创建结果页 | | **#35** T33 | **已存在任务的管理**：任务列表、任务详情、执行状态、重新采购、有效订单选择、物流回填 | ### 问题一：#41 原型的归属标注错误（已修复） #41 Stage A 原型第 9、10 屏及列表页的采购入口说明，此前标注「本页由 #35 实现」。经核对 #44 正文——「SYB 商品列表左侧勾选后批量创建」「表头全选只选择当前页」「不可创建行禁用并显示原因」「每条分别创建一个任务，禁止合并」「批量结果逐条显示」——与该原型逐条对应，**归属应为 #44**。 已更正 3 处标注，导出文件中「由 #35 实现」残留 0 处，`verdict=PASS`。提交 `1cd32a4`。 ### 问题二：#35 与 #44 都声称拥有创建确认页（已收敛） - #35 原文：「创建采购任务确认：PDD账号/设备、目标规格、映射规格、数量和 `_cg{task.id}` 提示」 - #44 原文：「批量确认和结果」 按**能力**而非**入口**切分：创建是一个完整能力，拆到两个工单会导致确认页被实现两遍或互相等待。创建能力整体归 #44，#35 收敛为管理已有任务。两张工单正文均已更新并注明移交关系。 ### 问题三：#44 状态过期（已更新） 原写「阶段：待实施；受 #32 原型审核门禁阻塞」。实际 #32 已于 2026-08-18 验收，#40、#41 原型已于 2026-08-19 验收，**三个前置门禁全部解除**，#44 现为可实施状态。 ### 问题四：本单阶段二第 7 项记错对象（已修正） 「#35 原型缺口」应拆为两部分：创建流程已由 #41 原型覆盖且归属 #44，无需另建原型；任务详情展示 `spec_source`、AI 匹配快照与两趟 attempt 历史的部分才归 #35，实施前需评估。正文第 7 项已改写。
ila commented 2026-08-21 16:13:27 +08:00
Author
Owner
Copy Link
Copy Source

已建立 #62 作为本决策工单的首个独立实施单元：服务端确定性规格标准化匹配、AI Provider 设置与 AI 兜底。#62 当前处于原型待审核状态，未经用户确认不会编写生产代码。

已建立 #62 作为本决策工单的首个独立实施单元：服务端确定性规格标准化匹配、AI Provider 设置与 AI 兜底。#62 当前处于原型待审核状态，未经用户确认不会编写生产代码。
ila commented 2026-08-21 17:29:50 +08:00
Author
Owner
Copy Link
Copy Source

子工单进展（2026-08-21）

#62「采购规格标准化匹配与 AI Provider 设置」已由用户验收通过并关闭。已交付服务端确定性 → AI 规格决策、首次规格探测后的同一决策、管理员 Provider 设置及 Android/采购员隔离；任务归档见 Task-62。

#46 其余事项（实时规格写回、快/慢路径完整联调、映射失效与时效规则）仍需各自按独立工单继续，未在 #62 中关闭。

## 子工单进展（2026-08-21） #62「采购规格标准化匹配与 AI Provider 设置」已由用户验收通过并关闭。已交付服务端确定性 → AI 规格决策、首次规格探测后的同一决策、管理员 Provider 设置及 Android/采购员隔离；任务归档见 [Task-62](https://git.ilapage.cn/OPC/goauto/wiki/Task-62-%E9%87%87%E8%B4%AD%E8%A7%84%E6%A0%BC%E6%A0%87%E5%87%86%E5%8C%96%E5%8C%B9%E9%85%8D%E4%B8%8E-AI-Provider-%E8%AE%BE%E7%BD%AE.-)。 #46 其余事项（实时规格写回、快/慢路径完整联调、映射失效与时效规则）仍需各自按独立工单继续，未在 #62 中关闭。
ila commented 2026-08-21 17:29:54 +08:00
Author
Owner
Copy Link
Copy Source

子工单进展（2026-08-21）

#62「采购规格标准化匹配与 AI Provider 设置」已由用户验收通过并关闭。已交付服务端确定性 → AI 规格决策、首次规格探测后的同一决策、管理员 Provider 设置及 Android/采购员隔离；任务归档见 Task-62。

#46 其余事项（实时规格写回、快/慢路径完整联调、映射失效与时效规则）仍需各自按独立工单继续，未在 #62 中关闭。

## 子工单进展（2026-08-21） #62「采购规格标准化匹配与 AI Provider 设置」已由用户验收通过并关闭。已交付服务端确定性 → AI 规格决策、首次规格探测后的同一决策、管理员 Provider 设置及 Android/采购员隔离；任务归档见 [Task-62](https://git.ilapage.cn/OPC/goauto/wiki/Task-62-%E9%87%87%E8%B4%AD%E8%A7%84%E6%A0%BC%E6%A0%87%E5%87%86%E5%8C%96%E5%8C%B9%E9%85%8D%E4%B8%8E-AI-Provider-%E8%AE%BE%E7%BD%AE.-)。 #46 其余事项（实时规格写回、快/慢路径完整联调、映射失效与时效规则）仍需各自按独立工单继续，未在 #62 中关闭。
ila commented 2026-08-29 20:46:35 +08:00
Author
Owner
Copy Link
Copy Source

进度同步（2026-08-29）：用户已验收并关闭与替换及规格匹配相关的 #129、#130、#131、#132、#147、#148、#149。#46 正文记录的其余实时规格回传与完整联调范围仍需单独核对，保持开放。

进度同步（2026-08-29）：用户已验收并关闭与替换及规格匹配相关的 #129、#130、#131、#132、#147、#148、#149。#46 正文记录的其余实时规格回传与完整联调范围仍需单独核对，保持开放。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
admin ila
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: OPC/goauto#46