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

功能：SYB 商品页批量 AI 匹配单个规格，工具栏精简为单行布局 #188

New Issue
Open
opened 2026-09-01 11:36:52 +08:00 by ila · 8 comments
ila commented 2026-09-01 11:36:52 +08:00
Owner
Copy Link
Copy Source

Gitea MCP 未向当前会话暴露，按仓库规则回退项目根目录安全配置与 Gitea API 创建本工单；凭据未写入工单、代码或日志。

原始需求摘要

来源：用户于 2026-09-01 提出，在 SYB 商品页「创建采购」按钮左边加一个「AI 匹配」按钮，批量匹配当前勾选的 SYB 货运单商品各自需要的单个规格（不是虾皮商品的全部规格表）与 PDD 商品规格。讨论后确认：

  • AI 匹配结果按现有 SetMapping 规则写成 pending（不新增"AI 结果可免人工直接生效"的例外），需要人工确认后才能被「创建采购」识别为可用；本单不实现自动确认，是否放宽为高置信度自动确认是需要用户单独决定的选项，本单不默认采用。
  • 为了给新按钮腾出位置，工具栏顺带整理：创建 PDD 采集（N）、创建采购（N） 的括号计数改为更轻量的角标样式（不是直接删除计数——用户确认计数含义与页面已有的「已选择 N 条」不同，需要保留，只是不再用突出的括号正文形式）；创建 PDD 采集 简化为 创建采集（去掉 "PDD" 前缀，与相邻的"创建采购"已经能区分含义）。目标是让查询相关控件和这些按钮尽量在同一行，不占两行。

目的：解决 #164 之前讨论中发现的真实缺口——批量「创建采购」内部只做确定性匹配（previewOneDeterministic），需要 AI 才能判定的 SYB 订单会被直接跳过标成"颜色待匹配"，此前唯一的解决路径是逐条进虾皮商品详情页用 #172 的 AI 匹配按钮处理，跟批量采购的操作节奏脱节。

基线与已核实事实

代码基线：6ab2f62（2026-09-01，含 #186 抽屉内联改动）。核验日期 2026-09-01。

  • purchase/batch.go:233-266（BatchCreate）对每个待创建的 SYB 订单先跑 previewOneDeterministic（仅确定性匹配，不含 AI），!preview.Eligible 时直接 continue，不会调用到 s.Create()——意味着 match_worker.go 里那套"创建任务后自动排队 AI 匹配"的机制，对批量创建路径里需要 AI 才能解决的订单从未被触发。
  • 前端 syb-products/index.vue:186（purchaseCandidates）在客户端就已经把 processStage !== 'purchase_ready' 的行排除在「创建采购」按钮计数之外，处于 color_mapping 阶段的行目前唯一的处理入口是单行「去匹配」链接（processNextAction === 'open_mapping'，runPurchaseNextAction 里 openShopeeDetail），跳到虾皮商品详情页走 #172 的人工/AI 匹配流程。
  • shopeeproduct/service.go:389-391（SetMapping）文档注释明确："An exact-name match or an AI suggestion is always written as pending regardless of what the caller sends; only a manual mapping may start confirmed"——AI 来源的映射结果无论置信度多高，写入时一律 pending，没有例外。match_worker.go 里达到 AutoConfirmMinConfidence 阈值即采用的 AI 结果，只写入对应采购任务自己的快照字段（mapped_color_snapshot 等），从未写入或影响过 shopee_product.specs_json 里的 Mapping，因此不构成"AI 结果可以免人工直接持久化为 confirmed"的先例。本单如果要让批量 AI 匹配的结果直接可用，必须遵守 SetMapping 现有规则写成 pending，再走既有 ConfirmMapping 完成人工确认，不能绕过。
  • purchase/service.go:127-138（confirmedMappings）判定"是否已解决"，只认 Mapping.Status == confirmed；pending 状态的映射不会让 previewOneDeterministic/confirmedMappings 判定为已解决，因此仅仅写入 pending 还不足以让「创建采购」通过，必须补一步人工确认。
  • 工具栏当前一行内容（syb-products/index.vue:6-15）已经很拥挤：已选择 N 条、店铺 autocomplete、订单号多行输入框、解析状态/处理阶段两个下拉、查询、重置、创建采购（N）、创建 PDD 采集（N），共 8 个控件挤在同一 el-form :inline="true" 行内，再加一个「AI 匹配」按钮会更紧张，实际能否不换行取决于目标浏览器宽度，无法仅凭代码静态判断，需要在标注截图/实测中确认。
  • 全仓复用组件核实：颜色/尺码规格建议已有的 aimatching.SuggestBatch（#172，server/app/goauto/aimatching/suggest.go）是"短编号绑定、批量单次调用"的通用批量建议能力，但其设计对象是一个虾皮商品的全部规格值；本单需要的是多个虾皮商品各自一个规格值，语义不同，不能直接套用同一个函数签名，需要新的服务方法组织输入（每个 SYB 订单贡献一个来源短编号，候选集合是各自关联 PDD 商品的对应维度规格），但可以复用 aimatching.Resolve（server/app/goauto/aimatching/service.go，确定性优先、AI 兜底，即 match_worker.go 已经在用的同一逻辑）按订单逐个调用，不必新增批量 prompt。

判断边界

  • 已确认（2026-09-01 修订，用户重申后采纳）：本单为「AI 匹配」这一个批量入口新增"达到置信度阈值即免人工直接 confirmed"的例外，通过独立写入路径实现，不改变 SetMapping 通用接口的既有强制 pending 规则；未达阈值的结果不享受此例外，仍需人工处理。此为用户在明确了解"当前 SetMapping 从未允许 AI 来源直接 confirmed"这一事实后做出的决定。
  • 已确认：工具栏按钮的计数不能整体删除（含义与"已选择 N 条"不同，删除会让用户误以为"点了就是全选中的都处理"），改为更轻量的视觉呈现（小号/浅色角标），不再用突出的括号正文形式。
  • 已确认：创建 PDD 采集 简化为 创建采集。
  • 已确认：目标是查询控件和按钮尽量同一行，但能否真正不换行取决于实际视口宽度，本单以"标注截图在目标分辨率下验证"为准，不作为可以脱离实测的绝对承诺。

目标

  1. SYB 商品页新增「AI 匹配」按钮，位于「创建采购」左边，对当前勾选中处于 color_mapping 阶段的行，批量解析各自需要的单个颜色/尺码规格。
  2. 解析结果达到 AutoConfirmMinConfidence 阈值时，通过独立写入路径直接落成 confirmed（不经过通用 SetMapping 的强制 pending 规则，SetMapping 本身及其现有调用方——包括 #172——不受影响、不修改）；未达阈值时仍按 SetMapping 现有语义写成 pending，留给人工在虾皮商品详情页用 #172 处理。
  3. 结果以纯提示性弹窗展示：处理了多少条、多少条直接匹配成功（已 confirmed）、多少条置信度不足留给人工处理（pending）、多少条解析失败及原因；一个「关闭」按钮，不需要勾选或点击确认。
  4. 达到阈值直接 confirmed 的映射，能让 previewOneDeterministic/confirmedMappings 立即判定为已解决；关闭结果弹窗后自动刷新 purchaseReadiness，「创建采购」按钮的候选数与可用性立刻反映最新状态，用户可以直接点「创建采购」，无需额外操作。
  5. 工具栏文案与视觉精简：创建 PDD 采集（N） → 创建采集 + 轻量角标 N；创建采购（N） → 创建采购 + 轻量角标 N；为「AI 匹配」按钮腾出位置，尽量让查询控件与这些按钮保持同一行。

非目标

  • 不修改 SetMapping 本身的通用接口行为；本单新增的自动确认能力必须走独立的写入路径，不能让 SetMapping 对其余调用方（含 #172）也开始允许 AI 来源直接 confirmed。
  • 不修改 #172 的虾皮商品详情页 AI 匹配逻辑本身，只是复用其确认动作（ConfirmMapping）以及匹配引擎（aimatching.Resolve）。
  • 不修改 BatchCreate/previewOneDeterministic 的既有判定逻辑，本单让更多订单"提前具备 confirmed 映射"，从而自然通过既有检查，不改检查本身。
  • 不改变「已选择 N 条」的含义和位置。
  • 不强制保证在任意浏览器宽度下都不换行；只以标注截图验证的目标分辨率为准。
  • 不涉及创建订单、支付、修改地址；不涉及权限、并发、数据库结构变化（除新增匹配结果的临时展示状态，不新增持久化表）。

前置依赖与并行性

  • 依赖 #172 已落地的 ConfirmMapping、aimatching.Resolve、置信度阈值配置，均已存在，无需等待。
  • 与 #164、#165、#178、#179、#184、#185、#186、#187 均无代码重叠，可并行；#186 的抽屉内联改动已落地（6ab2f62），本单在其基础上继续，不冲突。

固定实施方案

1. 服务端

  • 新增方法（如 purchase.Service.SuggestSpecMatches 或放在 shopeeproduct 包）：接收 SYB 订单 id 列表，逐个查出各自关联的虾皮商品、目标颜色/尺码、关联 PDD 商品的候选规格值，跳过已经是 confirmed 的（无需重复解析），对其余的调用 aimatching.Resolve。
  • 每个订单的解析结果落到对应虾皮商品的规格表，写入逻辑不经过通用 SetMapping，而是本单新增的独立写入路径：
    • matched.Decision.Confidence >= AutoConfirmMinConfidence（aimatching 设置里已有的同一个阈值，与 #172、match_worker.go 共用同一字段）时，直接写入 Mapping{PDDValue, Source: matched.Source, Status: confirmed, Confidence, Reason}；
    • 未达阈值（含确定性匹配失败、AI 未启用、AI 调用失败等）时，仍按 SetMapping 既有语义写 pending（或不写，留给人工从头处理），不享受自动确认。
    • SetMapping 函数本身及其"AI/exact_match 来源强制 pending"的规则不做任何修改，本单的独立写入路径是新代码，不是放宽 SetMapping 的参数或分支。
  • 返回每个订单的处理结果：跳过（已 confirmed）、自动确认成功（附来源、置信度、理由）、留待人工（置信度不足，附理由）、解析失败（无候选/AI 不可用等，附原因）。
  • 不新增批量确认接口——按修订后的方案，本单不需要人工确认这一步。

2. 前端

  • syb-products/index.vue 工具栏新增「AI 匹配」按钮，禁用条件参考"当前勾选中是否存在 color_mapping 阶段的行"。
  • 点击后调用批量解析接口，弹出纯提示性结果对话框（列出总数、自动确认数、留待人工数、失败数及各自理由），只有一个「关闭」按钮，不提供勾选/确认交互。
  • 关闭弹窗时自动刷新 purchaseReadiness（复用 loadPurchaseReadiness），让"创建采购"按钮的候选数与处理阶段标签立刻反映刚刚自动确认的结果，用户可以直接继续点「创建采购」。
  • 工具栏按钮文案与样式调整：括号计数改为角标；创建 PDD 采集 简化为创建采集。
  • 视需要压缩查询区控件宽度（店铺/订单号/下拉框），使查询控件与操作按钮尽量保持在同一行；提供目标分辨率下的标注截图供用户确认视觉效果。

设计证据

新增按钮与结果确认弹窗，交互模式复用现有批量操作弹窗（purchaseDialog/collectionBatch），不引入新的交互范式。2026-09-01 用户确认：工具栏文案与视觉精简改动范围小、交互不变，用户已认可上方文字方案描述，不要求标注截图，可直接据此实施；单行布局的实际效果在实施后如与预期不符，再另行调整，不作为阻塞实施的前置条件。

验收标准

  • 勾选处于 color_mapping 阶段的 SYB 订单，点击「AI 匹配」，能正确解析各自需要的单个规格并展示结果（自动确认/留待人工/失败/已跳过）。
  • 置信度达到 AutoConfirmMinConfidence 阈值的结果，直接写入对应虾皮商品规格表为 confirmed，无需任何人工点击确认。
  • 置信度未达阈值的结果仍为 pending，不会被本单的入口自动确认，仍需走 #172 人工处理。
  • 关闭结果弹窗后自动刷新，原本"颜色待匹配"且被自动确认的行变为"可创建采购"，「创建采购」按钮候选数正确更新，无需额外操作即可直接点击创建采购。
  • shopeeproduct.SetMapping 函数本身未被修改，其在 #172 及其余调用方的行为（AI 来源强制 pending）保持不变；本单的自动确认逻辑证明为独立写入路径，未复用/修改 SetMapping 的分支判断。
  • 未修改 ConfirmMapping、BatchCreate、previewOneDeterministic 的既有判定逻辑。
  • 「创建 PDD 采集」按钮文案变为「创建采集」，计数以轻量角标呈现；「创建采购」计数同样改为轻量角标。
  • 「已选择 N 条」与按钮角标含义不同的场景下（部分选中行不满足按钮条件）两者数字不同，各自正确。
  • 查询控件与操作按钮（含新增「AI 匹配」）尽量呈现为单行；无法完全单行时如实记录实际效果到工单，不强行承诺，不阻塞验收（用户已用文字方案确认放行，不要求截图比对）。
  • Server 与 Web 单元测试、既有 e2e 测试通过。

必测场景

  • 勾选行包含：已 confirmed（应跳过重复解析）、color_mapping（应解析）、其他阶段（不参与）三种混合情况。
  • AI 解析失败（无候选、AI 未启用、置信度不足）时该行结果明确展示原因，不影响其余行。
  • 同一批结果中，部分达到阈值自动确认、部分未达阈值留 pending，两者互不影响，各自状态正确。
  • 关闭结果弹窗、页面自动刷新后，「创建采购」按钮的候选数、处理阶段标签、purchaseReady(row) 结果与预期一致，被自动确认的订单可以直接点击创建采购成功。
  • 「创建 PDD 采集」「创建采购」新文案与角标在勾选数为 0、部分、全部三种情况下的显示正确。
  • 查询控件+全部按钮实际渲染效果自查一次（不要求提交截图给用户比对，实施者自行确认无明显错位/溢出）。

风险与安全门禁

  • 已放宽的边界仅限本单新增入口：本单允许「AI 匹配」这一个批量入口，在达到置信度阈值时免人工直接写 confirmed——这是本单唯一放开人工确认要求的场景。SetMapping 通用接口及 #172 等其余调用方必须继续保持"AI/exact_match 来源强制 pending"，不得被本单的改动波及。
  • 持久化误判的影响面大于单次采购：一旦某个虾皮商品的映射被自动确认错误，会一直"生效"到有人发现并手动纠正为止，影响该商品此后的所有订单，不是只影响这一次批量操作里的这一单——比 match_worker.go 现有的"只影响单条采购任务快照"的自动匹配机制影响范围更大、更持久。这是用户在明确该差异后仍然要求简化流程所接受的取舍，工单如实记录，不代表该风险不存在。
  • 用户对达到阈值的映射结果没有逐条查看的机会，只能通过结果弹窗的统计和后续在虾皮商品详情页复核；如需要事后审计，应确保结果弹窗和/或日志能回溯"哪些映射是本次自动确认的"。
  • 批量解析可能对多条订单同时发起 AI 调用，需评估耗时与前端超时设置（参考 #172 已经处理过的类似问题：前端调用超时需明显长于服务端 AI 超时上限）。
  • 不涉及权限、安全、并发、数据库结构、订单、支付。

文档影响

无长期文档影响。 未新增持久化数据结构（复用既有 Mapping 字段与既有确认接口），未改变已有业务规则；仅新增一个批量触发入口和对应的前端交互。若实施后发现需要新增独立接口且改变共享契约，届时在实施过程中重新判断并回写本工单。

状态

已确认，可以实施（2026-09-01 创建；同日修订为"达到置信度阈值免人工自动确认"，用户在了解风险后重申并采纳；同日用户明确"不用截图，方案文字描述我认可了"，设计证据门槛以文字方案确认放行，不再要求界面标注截图）。

> Gitea MCP 未向当前会话暴露，按仓库规则回退项目根目录安全配置与 Gitea API 创建本工单；凭据未写入工单、代码或日志。 ## 原始需求摘要 来源：用户于 2026-09-01 提出，在 SYB 商品页「创建采购」按钮左边加一个「AI 匹配」按钮，批量匹配当前勾选的 SYB 货运单商品各自需要的单个规格（不是虾皮商品的全部规格表）与 PDD 商品规格。讨论后确认： - AI 匹配结果按现有 `SetMapping` 规则写成 `pending`（不新增"AI 结果可免人工直接生效"的例外），需要人工确认后才能被「创建采购」识别为可用；本单不实现自动确认，是否放宽为高置信度自动确认是需要用户单独决定的选项，本单不默认采用。 - 为了给新按钮腾出位置，工具栏顺带整理：`创建 PDD 采集（N）`、`创建采购（N）` 的括号计数改为更轻量的角标样式（不是直接删除计数——用户确认计数含义与页面已有的「已选择 N 条」不同，需要保留，只是不再用突出的括号正文形式）；`创建 PDD 采集` 简化为 `创建采集`（去掉 "PDD" 前缀，与相邻的"创建采购"已经能区分含义）。目标是让查询相关控件和这些按钮尽量在同一行，不占两行。 目的：解决 #164 之前讨论中发现的真实缺口——批量「创建采购」内部只做确定性匹配（`previewOneDeterministic`），需要 AI 才能判定的 SYB 订单会被直接跳过标成"颜色待匹配"，此前唯一的解决路径是逐条进虾皮商品详情页用 #172 的 AI 匹配按钮处理，跟批量采购的操作节奏脱节。 ## 基线与已核实事实 代码基线：`6ab2f62`（2026-09-01，含 #186 抽屉内联改动）。核验日期 2026-09-01。 - `purchase/batch.go:233-266`（`BatchCreate`）对每个待创建的 SYB 订单先跑 `previewOneDeterministic`（仅确定性匹配，不含 AI），`!preview.Eligible` 时直接 `continue`，**不会**调用到 `s.Create()`——意味着 `match_worker.go` 里那套"创建任务后自动排队 AI 匹配"的机制，对批量创建路径里需要 AI 才能解决的订单**从未被触发**。 - 前端 `syb-products/index.vue:186`（`purchaseCandidates`）在客户端就已经把 `processStage !== 'purchase_ready'` 的行排除在「创建采购」按钮计数之外，处于 `color_mapping` 阶段的行目前唯一的处理入口是单行「去匹配」链接（`processNextAction === 'open_mapping'`，`runPurchaseNextAction` 里 `openShopeeDetail`），跳到虾皮商品详情页走 #172 的人工/AI 匹配流程。 - `shopeeproduct/service.go:389-391`（`SetMapping`）文档注释明确："An exact-name match or an AI suggestion is always written as pending regardless of what the caller sends; only a manual mapping may start confirmed"——**AI 来源的映射结果无论置信度多高，写入时一律 `pending`，没有例外**。`match_worker.go` 里达到 `AutoConfirmMinConfidence` 阈值即采用的 AI 结果，只写入对应采购任务自己的快照字段（`mapped_color_snapshot` 等），**从未写入或影响过 `shopee_product.specs_json` 里的 `Mapping`**，因此不构成"AI 结果可以免人工直接持久化为 `confirmed`"的先例。本单如果要让批量 AI 匹配的结果直接可用，必须遵守 `SetMapping` 现有规则写成 `pending`，再走既有 `ConfirmMapping` 完成人工确认，不能绕过。 - `purchase/service.go:127-138`（`confirmedMappings`）判定"是否已解决"，只认 `Mapping.Status == confirmed`；`pending` 状态的映射不会让 `previewOneDeterministic`/`confirmedMappings` 判定为已解决，因此仅仅写入 `pending` 还不足以让「创建采购」通过，必须补一步人工确认。 - 工具栏当前一行内容（`syb-products/index.vue:6-15`）已经很拥挤：`已选择 N 条`、店铺 autocomplete、订单号多行输入框、解析状态/处理阶段两个下拉、查询、重置、创建采购（N）、创建 PDD 采集（N），共 8 个控件挤在同一 `el-form :inline="true"` 行内，再加一个「AI 匹配」按钮会更紧张，实际能否不换行取决于目标浏览器宽度，无法仅凭代码静态判断，需要在标注截图/实测中确认。 - 全仓复用组件核实：颜色/尺码规格建议已有的 `aimatching.SuggestBatch`（#172，`server/app/goauto/aimatching/suggest.go`）是"短编号绑定、批量单次调用"的通用批量建议能力，但其设计对象是**一个虾皮商品的全部规格值**；本单需要的是**多个虾皮商品各自一个规格值**，语义不同，不能直接套用同一个函数签名，需要新的服务方法组织输入（每个 SYB 订单贡献一个来源短编号，候选集合是各自关联 PDD 商品的对应维度规格），但可以复用 `aimatching.Resolve`（`server/app/goauto/aimatching/service.go`，确定性优先、AI 兜底，即 `match_worker.go` 已经在用的同一逻辑）按订单逐个调用，不必新增批量 prompt。 ## 判断边界 - **已确认（2026-09-01 修订，用户重申后采纳）**：本单为「AI 匹配」这一个批量入口新增"达到置信度阈值即免人工直接 `confirmed`"的例外，通过独立写入路径实现，不改变 `SetMapping` 通用接口的既有强制 `pending` 规则；未达阈值的结果不享受此例外，仍需人工处理。此为用户在明确了解"当前 `SetMapping` 从未允许 AI 来源直接 `confirmed`"这一事实后做出的决定。 - 已确认：工具栏按钮的计数不能整体删除（含义与"已选择 N 条"不同，删除会让用户误以为"点了就是全选中的都处理"），改为更轻量的视觉呈现（小号/浅色角标），不再用突出的括号正文形式。 - 已确认：`创建 PDD 采集` 简化为 `创建采集`。 - 已确认：目标是查询控件和按钮尽量同一行，但**能否真正不换行取决于实际视口宽度**，本单以"标注截图在目标分辨率下验证"为准，不作为可以脱离实测的绝对承诺。 ## 目标 1. SYB 商品页新增「AI 匹配」按钮，位于「创建采购」左边，对当前勾选中处于 `color_mapping` 阶段的行，批量解析各自需要的单个颜色/尺码规格。 2. 解析结果达到 `AutoConfirmMinConfidence` 阈值时，通过独立写入路径直接落成 `confirmed`（不经过通用 `SetMapping` 的强制 `pending` 规则，`SetMapping` 本身及其现有调用方——包括 #172——不受影响、不修改）；未达阈值时仍按 `SetMapping` 现有语义写成 `pending`，留给人工在虾皮商品详情页用 #172 处理。 3. 结果以纯提示性弹窗展示：处理了多少条、多少条直接匹配成功（已 `confirmed`）、多少条置信度不足留给人工处理（`pending`）、多少条解析失败及原因；一个「关闭」按钮，不需要勾选或点击确认。 4. 达到阈值直接 `confirmed` 的映射，能让 `previewOneDeterministic`/`confirmedMappings` 立即判定为已解决；关闭结果弹窗后自动刷新 `purchaseReadiness`，「创建采购」按钮的候选数与可用性立刻反映最新状态，用户可以直接点「创建采购」，无需额外操作。 5. 工具栏文案与视觉精简：`创建 PDD 采集（N）` → `创建采集` + 轻量角标 N；`创建采购（N）` → `创建采购` + 轻量角标 N；为「AI 匹配」按钮腾出位置，尽量让查询控件与这些按钮保持同一行。 ## 非目标 - 不修改 `SetMapping` 本身的通用接口行为；本单新增的自动确认能力必须走独立的写入路径，不能让 `SetMapping` 对其余调用方（含 #172）也开始允许 AI 来源直接 `confirmed`。 - 不修改 #172 的虾皮商品详情页 AI 匹配逻辑本身，只是复用其确认动作（`ConfirmMapping`）以及匹配引擎（`aimatching.Resolve`）。 - 不修改 `BatchCreate`/`previewOneDeterministic` 的既有判定逻辑，本单让更多订单"提前具备 `confirmed` 映射"，从而自然通过既有检查，不改检查本身。 - 不改变「已选择 N 条」的含义和位置。 - 不强制保证在任意浏览器宽度下都不换行；只以标注截图验证的目标分辨率为准。 - 不涉及创建订单、支付、修改地址；不涉及权限、并发、数据库结构变化（除新增匹配结果的临时展示状态，不新增持久化表）。 ## 前置依赖与并行性 - 依赖 #172 已落地的 `ConfirmMapping`、`aimatching.Resolve`、置信度阈值配置，均已存在，无需等待。 - 与 #164、#165、#178、#179、#184、#185、#186、#187 均无代码重叠，可并行；#186 的抽屉内联改动已落地（`6ab2f62`），本单在其基础上继续，不冲突。 ## 固定实施方案 ### 1. 服务端 - 新增方法（如 `purchase.Service.SuggestSpecMatches` 或放在 `shopeeproduct` 包）：接收 SYB 订单 id 列表，逐个查出各自关联的虾皮商品、目标颜色/尺码、关联 PDD 商品的候选规格值，跳过已经是 `confirmed` 的（无需重复解析），对其余的调用 `aimatching.Resolve`。 - 每个订单的解析结果落到对应虾皮商品的规格表，写入逻辑**不经过通用 `SetMapping`**，而是本单新增的独立写入路径： - `matched.Decision.Confidence >= AutoConfirmMinConfidence`（`aimatching` 设置里已有的同一个阈值，与 #172、`match_worker.go` 共用同一字段）时，直接写入 `Mapping{PDDValue, Source: matched.Source, Status: confirmed, Confidence, Reason}`； - 未达阈值（含确定性匹配失败、AI 未启用、AI 调用失败等）时，仍按 `SetMapping` 既有语义写 `pending`（或不写，留给人工从头处理），不享受自动确认。 - `SetMapping` 函数本身及其"AI/exact_match 来源强制 `pending`"的规则不做任何修改，本单的独立写入路径是新代码，不是放宽 `SetMapping` 的参数或分支。 - 返回每个订单的处理结果：跳过（已 `confirmed`）、自动确认成功（附来源、置信度、理由）、留待人工（置信度不足，附理由）、解析失败（无候选/AI 不可用等，附原因）。 - 不新增批量确认接口——按修订后的方案，本单不需要人工确认这一步。 ### 2. 前端 - `syb-products/index.vue` 工具栏新增「AI 匹配」按钮，禁用条件参考"当前勾选中是否存在 `color_mapping` 阶段的行"。 - 点击后调用批量解析接口，弹出**纯提示性结果对话框**（列出总数、自动确认数、留待人工数、失败数及各自理由），只有一个「关闭」按钮，不提供勾选/确认交互。 - 关闭弹窗时自动刷新 `purchaseReadiness`（复用 `loadPurchaseReadiness`），让"创建采购"按钮的候选数与处理阶段标签立刻反映刚刚自动确认的结果，用户可以直接继续点「创建采购」。 - 工具栏按钮文案与样式调整：括号计数改为角标；`创建 PDD 采集` 简化为`创建采集`。 - 视需要压缩查询区控件宽度（店铺/订单号/下拉框），使查询控件与操作按钮尽量保持在同一行；提供目标分辨率下的标注截图供用户确认视觉效果。 ## 设计证据 新增按钮与结果确认弹窗，交互模式复用现有批量操作弹窗（`purchaseDialog`/`collectionBatch`），不引入新的交互范式。**2026-09-01 用户确认**：工具栏文案与视觉精简改动范围小、交互不变，用户已认可上方文字方案描述，不要求标注截图，可直接据此实施；单行布局的实际效果在实施后如与预期不符，再另行调整，不作为阻塞实施的前置条件。 ## 验收标准 - [ ] 勾选处于 `color_mapping` 阶段的 SYB 订单，点击「AI 匹配」，能正确解析各自需要的单个规格并展示结果（自动确认/留待人工/失败/已跳过）。 - [ ] 置信度达到 `AutoConfirmMinConfidence` 阈值的结果，直接写入对应虾皮商品规格表为 `confirmed`，无需任何人工点击确认。 - [ ] 置信度未达阈值的结果仍为 `pending`，不会被本单的入口自动确认，仍需走 #172 人工处理。 - [ ] 关闭结果弹窗后自动刷新，原本"颜色待匹配"且被自动确认的行变为"可创建采购"，「创建采购」按钮候选数正确更新，无需额外操作即可直接点击创建采购。 - [ ] `shopeeproduct.SetMapping` 函数本身未被修改，其在 #172 及其余调用方的行为（AI 来源强制 `pending`）保持不变；本单的自动确认逻辑证明为独立写入路径，未复用/修改 `SetMapping` 的分支判断。 - [ ] 未修改 `ConfirmMapping`、`BatchCreate`、`previewOneDeterministic` 的既有判定逻辑。 - [ ] 「创建 PDD 采集」按钮文案变为「创建采集」，计数以轻量角标呈现；「创建采购」计数同样改为轻量角标。 - [ ] 「已选择 N 条」与按钮角标含义不同的场景下（部分选中行不满足按钮条件）两者数字不同，各自正确。 - [ ] 查询控件与操作按钮（含新增「AI 匹配」）尽量呈现为单行；无法完全单行时如实记录实际效果到工单，不强行承诺，不阻塞验收（用户已用文字方案确认放行，不要求截图比对）。 - [ ] Server 与 Web 单元测试、既有 e2e 测试通过。 ## 必测场景 - 勾选行包含：已 `confirmed`（应跳过重复解析）、`color_mapping`（应解析）、其他阶段（不参与）三种混合情况。 - AI 解析失败（无候选、AI 未启用、置信度不足）时该行结果明确展示原因，不影响其余行。 - 同一批结果中，部分达到阈值自动确认、部分未达阈值留 `pending`，两者互不影响，各自状态正确。 - 关闭结果弹窗、页面自动刷新后，「创建采购」按钮的候选数、处理阶段标签、`purchaseReady(row)` 结果与预期一致，被自动确认的订单可以直接点击创建采购成功。 - 「创建 PDD 采集」「创建采购」新文案与角标在勾选数为 0、部分、全部三种情况下的显示正确。 - 查询控件+全部按钮实际渲染效果自查一次（不要求提交截图给用户比对，实施者自行确认无明显错位/溢出）。 ## 风险与安全门禁 - **已放宽的边界仅限本单新增入口**：本单允许「AI 匹配」这一个批量入口，在达到置信度阈值时免人工直接写 `confirmed`——这是本单唯一放开人工确认要求的场景。`SetMapping` 通用接口及 #172 等其余调用方必须继续保持"AI/exact_match 来源强制 `pending`"，不得被本单的改动波及。 - **持久化误判的影响面大于单次采购**：一旦某个虾皮商品的映射被自动确认错误，会一直"生效"到有人发现并手动纠正为止，影响该商品此后的所有订单，不是只影响这一次批量操作里的这一单——比 `match_worker.go` 现有的"只影响单条采购任务快照"的自动匹配机制影响范围更大、更持久。这是用户在明确该差异后仍然要求简化流程所接受的取舍，工单如实记录，不代表该风险不存在。 - 用户对达到阈值的映射结果没有逐条查看的机会，只能通过结果弹窗的统计和后续在虾皮商品详情页复核；如需要事后审计，应确保结果弹窗和/或日志能回溯"哪些映射是本次自动确认的"。 - 批量解析可能对多条订单同时发起 AI 调用，需评估耗时与前端超时设置（参考 #172 已经处理过的类似问题：前端调用超时需明显长于服务端 AI 超时上限）。 - 不涉及权限、安全、并发、数据库结构、订单、支付。 ## 文档影响 **无长期文档影响。** 未新增持久化数据结构（复用既有 `Mapping` 字段与既有确认接口），未改变已有业务规则；仅新增一个批量触发入口和对应的前端交互。若实施后发现需要新增独立接口且改变共享契约，届时在实施过程中重新判断并回写本工单。 ## 状态 **已确认，可以实施**（2026-09-01 创建；同日修订为"达到置信度阈值免人工自动确认"，用户在了解风险后重申并采纳；同日用户明确"不用截图，方案文字描述我认可了"，设计证据门槛以文字方案确认放行，不再要求界面标注截图）。
ila commented 2026-09-01 12:21:21 +08:00
Author
Owner
Copy Link
Copy Source

实施完成，待验收

实现

  • 新增 POST /api/admin/v1/purchase-tasks/batch-spec-match（1～100 条，管理员/采购员可用），仅处理当前处于 color_mapping 的 SYB 明细并逐条返回 auto_confirmed / pending / failed / skipped。
  • 复用既有 AI Provider 和 autoConfirmMinConfidence；只有 source=ai_match、置信度存在且达到阈值、候选和理由完整时，才通过独立写入路径原子保存为 confirmed。
  • 低置信度和 Provider 异常不改写现有映射，留给人工处理；这是固定方案允许的“或不写”分支，可避免旧/待定映射被误判为采购就绪。
  • 通用 SetMapping、ConfirmMapping、BatchCreate、previewOneDeterministic 行为未改变。
  • SYB 商品页新增“AI 匹配”批量动作、候选数量徽标及结果弹窗；关闭结果后重新预检采购状态并保留仍可选的勾选项。
  • 按用户确认，#188 不要求截图验收证据。

验证

  • go test ./app/goauto/purchase ./app/goauto/shopeeproduct ./app/goauto/access：通过。
  • go test ./...：通过（因系统盘空间不足，将 Go 临时目录切换到 D:\Temp\goauto-188 后执行）。
  • Linux amd64 服务端构建：通过。
  • 目标 Web ESLint：通过。
  • pnpm run build:prod：通过；仅有既存 lightningcss/大 chunk 警告。
  • Playwright tests/e2e/syb-product-layout.spec.ts：8 passed。
  • python dev_scripts/harness.py check --strict：通过。
  • Wiki sync + sync --check：通过。
  • git diff --check / 提交差异检查：通过。
  • 全量 Web lint 仍被既存的 web/src/views/goauto/purchase-tasks/index.vue 混合缩进问题阻塞（24 errors，41 warnings），该文件不在 #188 范围，本次未修改。

文档

  • Business-Rules-and-Glossary：revision 084dae8190b765758cc77a59732215bd8a9ca6fe。
  • Android-Agent-API-Contract：revision 44f936706dfd36b0281215a239b790bbe50aaf77。

提交与上线

  • 提交：3ef0f72（已推送 main）。
  • 线上 release：/home/goauto/releases/20260901-121758-3ef0f72。
  • 上一 release 保留：/home/goauto/releases/20260901-112853-6ab2f62。
  • 发布包 SHA-256：8b3420d9b04704cd59f0acb61ee4e011ac9c267fe153238a5093d321dfefa9d8。
  • 无数据库迁移。
  • goauto.service：active；Nginx 配置检查通过。
  • 公网首页：HTTP 200。
  • 新接口未登录探测：HTTP 200，应用返回 code=401，说明新路由已加载且鉴权生效。

工单保持打开，等待用户验收。

## 实施完成，待验收 ### 实现 - 新增 `POST /api/admin/v1/purchase-tasks/batch-spec-match`（1～100 条，管理员/采购员可用），仅处理当前处于 `color_mapping` 的 SYB 明细并逐条返回 `auto_confirmed` / `pending` / `failed` / `skipped`。 - 复用既有 AI Provider 和 `autoConfirmMinConfidence`；只有 `source=ai_match`、置信度存在且达到阈值、候选和理由完整时，才通过独立写入路径原子保存为 `confirmed`。 - 低置信度和 Provider 异常不改写现有映射，留给人工处理；这是固定方案允许的“或不写”分支，可避免旧/待定映射被误判为采购就绪。 - 通用 `SetMapping`、`ConfirmMapping`、`BatchCreate`、`previewOneDeterministic` 行为未改变。 - SYB 商品页新增“AI 匹配”批量动作、候选数量徽标及结果弹窗；关闭结果后重新预检采购状态并保留仍可选的勾选项。 - 按用户确认，#188 不要求截图验收证据。 ### 验证 - `go test ./app/goauto/purchase ./app/goauto/shopeeproduct ./app/goauto/access`：通过。 - `go test ./...`：通过（因系统盘空间不足，将 Go 临时目录切换到 `D:\Temp\goauto-188` 后执行）。 - Linux amd64 服务端构建：通过。 - 目标 Web ESLint：通过。 - `pnpm run build:prod`：通过；仅有既存 lightningcss/大 chunk 警告。 - Playwright `tests/e2e/syb-product-layout.spec.ts`：8 passed。 - `python dev_scripts/harness.py check --strict`：通过。 - Wiki `sync` + `sync --check`：通过。 - `git diff --check` / 提交差异检查：通过。 - 全量 Web lint 仍被既存的 `web/src/views/goauto/purchase-tasks/index.vue` 混合缩进问题阻塞（24 errors，41 warnings），该文件不在 #188 范围，本次未修改。 ### 文档 - `Business-Rules-and-Glossary`：revision `084dae8190b765758cc77a59732215bd8a9ca6fe`。 - `Android-Agent-API-Contract`：revision `44f936706dfd36b0281215a239b790bbe50aaf77`。 ### 提交与上线 - 提交：`3ef0f72`（已推送 `main`）。 - 线上 release：`/home/goauto/releases/20260901-121758-3ef0f72`。 - 上一 release 保留：`/home/goauto/releases/20260901-112853-6ab2f62`。 - 发布包 SHA-256：`8b3420d9b04704cd59f0acb61ee4e011ac9c267fe153238a5093d321dfefa9d8`。 - 无数据库迁移。 - `goauto.service`：active；Nginx 配置检查通过。 - 公网首页：HTTP 200。 - 新接口未登录探测：HTTP 200，应用返回 `code=401`，说明新路由已加载且鉴权生效。 工单保持打开，等待用户验收。
ila commented 2026-09-01 14:14:41 +08:00
Author
Owner
Copy Link
Copy Source

需求变更：批量 AI 匹配资格改为显式业务判定（待用户重新确认）

变更来源

用户在 #188 上线后进一步澄清业务含义：批量 AI 匹配的对象是“每条 SYB 货运单商品已经解析出的采购规格”，候选是“该蝦皮商品所关联 PDD 商品的全部当前可选规格”。满足前置条件并匹配成功后，该 SYB 明细应变为“可创建采购”，但不自动创建采购任务、订单或支付。

线上复核发现：当前第一页勾选 17 条时显示“AI 匹配 0”，原因是现实现仅以 processStage === color_mapping 作为候选条件；第一页 20 条实际为 15 条“可创建采购”、2 条“PDD 待采集”、3 条“未关联 PDD”，没有 color_mapping。计数符合原 #188 固定方案，但“候选资格”表达过度依赖处理阶段字符串，不能直接说明两端规格是否真的具备匹配条件。

修订目标

  1. 服务端在批量预检结果中显式返回：
    • aiMatchEligible：当前明细是否可以运行批量 AI 规格匹配；
    • aiMatchDisabledReason：不可运行时的明确原因；
    • 如实现需要，可返回待解决维度，但不新增数据库字段。
  2. 前端“AI 匹配 N”直接统计已勾选且 aiMatchEligible=true 的明细，不再自行使用 processStage === color_mapping 推导资格。
  3. processStage 继续作为页面流程展示；color_mapping 应是服务端资格和当前映射状态计算后的结果，而不是前端候选资格的唯一事实来源。

AI 匹配资格（修订草案）

一条 SYB 明细仅在同时满足以下条件时为 aiMatchEligible=true：

  • SYB 商品存在，且采购规格解析结果可用；对关联 PDD 商品实际存在的规格维度，目标颜色/尺码完整、非空且结构有效；
  • 已关联有效的蝦皮商品；
  • 蝦皮商品已关联未停用的 PDD 商品；
  • PDD 商品采集已完成，并存在当前可选择的规格候选；
  • 当前仍有至少一个所需规格维度没有可复用的有效 confirmed 映射或唯一确定性结果；
  • 当前明细没有进行中、结果待核对或已经成功的采购任务。

不可匹配时至少区分：采购规格未完整解析、解析存疑、未关联蝦皮/PDD、PDD 待采集或采集中、PDD 采集失败、PDD 无可选规格、已有有效映射无需 AI、已有采购任务。

需要重新确认的安全边界

建议口径：parse_status=uncertain（解析存疑）不进入高置信自动确认。 即使目标颜色/尺码字段非空，也先人工修正解析结果，再进入批量 AI 匹配，避免错误的 SYB 来源规格被永久保存为共享的蝦皮→PDD confirmed 映射。

如果用户要求“解析存疑但字段非空也允许 AI”，需要单独明确接受其误确认风险，并决定是否只允许生成 pending、禁止自动 confirmed。

匹配输入、写入与结果

  • 每条明细输入：SYB 当前采购目标颜色/尺码；候选：其关联 PDD 商品的全部当前可选颜色、尺码及可验证的组合约束。
  • 只解析当前尚未解决的维度；不得对已有可靠 confirmed 映射重复调用 AI 或覆盖。
  • 输出的 PDD 规格必须仍存在且可选择；有颜色和尺码时应验证组合可购买，不能只分别命中两个值。
  • 高置信且候选、理由、组合校验均通过：沿用 #188 独立路径写为 confirmed，刷新批量预检后变为“可创建采购”。
  • 低置信、无唯一结果、Provider 异常或组合无效：保留待人工，不覆盖已有映射。
  • 服务端仍须逐条重新校验资格，不能只相信前端提交的候选列表；混合批次逐条返回成功、待人工、失败或跳过原因。

非目标与不变项

  • 不对“已经可创建采购”的明细重新 AI 匹配，不覆盖其有效映射；若怀疑其被误判，应修复采购预检或解析数据，而不是扩大 AI 覆盖范围。
  • 不修改通用 SetMapping 的 AI 强制 pending 语义；高置信自动确认继续限定在 #188 独立入口。
  • 不自动创建采购任务、PDD 订单或付款；匹配成功只获得“可创建采购”资格，仍需用户点击“创建采购”。
  • 不新增数据库表或迁移；如组合约束无法由现有 PDD 归档证明，则必须停止自动确认并回到人工处理，不以猜测补齐。

修订验收与必测场景

  • 预检对每条明细返回准确的 aiMatchEligible 与禁用原因，前端按钮计数与服务端一致。
  • 解析失败/存疑、未关联、PDD 待采集/采集中/失败、PDD 无规格、已有有效映射、已有采购任务均不进入 AI，并显示对应原因。
  • 两端规格具备条件且映射未解决时进入 AI；高置信有效组合变为“可创建采购”，低置信或组合无效保持待人工。
  • 混合勾选时仅处理适用子集，其余逐条跳过且理由明确；关闭结果后重新预检并保留仍可操作的选择。
  • 验证已有 SetMapping、BatchCreate、采购安全边界及订单/支付禁令没有变化。

当前状态

#188 已上线但尚未验收。本变更属于候选资格/API/UI 行为调整，现标记为待用户重新确认；确认前不修改生产代码、不再次发布。确认后继续在 #188 内实施、测试、更新共享 API/Wiki、提交推送，并在单独取得线上发布授权后再部署。

## 需求变更：批量 AI 匹配资格改为显式业务判定（待用户重新确认） ### 变更来源 用户在 #188 上线后进一步澄清业务含义：批量 AI 匹配的对象是“每条 SYB 货运单商品已经解析出的采购规格”，候选是“该蝦皮商品所关联 PDD 商品的全部当前可选规格”。满足前置条件并匹配成功后，该 SYB 明细应变为“可创建采购”，但不自动创建采购任务、订单或支付。 线上复核发现：当前第一页勾选 17 条时显示“AI 匹配 0”，原因是现实现仅以 `processStage === color_mapping` 作为候选条件；第一页 20 条实际为 15 条“可创建采购”、2 条“PDD 待采集”、3 条“未关联 PDD”，没有 `color_mapping`。计数符合原 #188 固定方案，但“候选资格”表达过度依赖处理阶段字符串，不能直接说明两端规格是否真的具备匹配条件。 ### 修订目标 1. 服务端在批量预检结果中显式返回： - `aiMatchEligible`：当前明细是否可以运行批量 AI 规格匹配； - `aiMatchDisabledReason`：不可运行时的明确原因； - 如实现需要，可返回待解决维度，但不新增数据库字段。 2. 前端“AI 匹配 N”直接统计已勾选且 `aiMatchEligible=true` 的明细，不再自行使用 `processStage === color_mapping` 推导资格。 3. `processStage` 继续作为页面流程展示；`color_mapping` 应是服务端资格和当前映射状态计算后的结果，而不是前端候选资格的唯一事实来源。 ### AI 匹配资格（修订草案） 一条 SYB 明细仅在同时满足以下条件时为 `aiMatchEligible=true`： - SYB 商品存在，且采购规格解析结果可用；对关联 PDD 商品实际存在的规格维度，目标颜色/尺码完整、非空且结构有效； - 已关联有效的蝦皮商品； - 蝦皮商品已关联未停用的 PDD 商品； - PDD 商品采集已完成，并存在当前可选择的规格候选； - 当前仍有至少一个所需规格维度没有可复用的有效 `confirmed` 映射或唯一确定性结果； - 当前明细没有进行中、结果待核对或已经成功的采购任务。 不可匹配时至少区分：采购规格未完整解析、解析存疑、未关联蝦皮/PDD、PDD 待采集或采集中、PDD 采集失败、PDD 无可选规格、已有有效映射无需 AI、已有采购任务。 ### 需要重新确认的安全边界 **建议口径：`parse_status=uncertain`（解析存疑）不进入高置信自动确认。** 即使目标颜色/尺码字段非空，也先人工修正解析结果，再进入批量 AI 匹配，避免错误的 SYB 来源规格被永久保存为共享的蝦皮→PDD `confirmed` 映射。 如果用户要求“解析存疑但字段非空也允许 AI”，需要单独明确接受其误确认风险，并决定是否只允许生成 `pending`、禁止自动 `confirmed`。 ### 匹配输入、写入与结果 - 每条明细输入：SYB 当前采购目标颜色/尺码；候选：其关联 PDD 商品的全部当前可选颜色、尺码及可验证的组合约束。 - 只解析当前尚未解决的维度；不得对已有可靠 `confirmed` 映射重复调用 AI 或覆盖。 - 输出的 PDD 规格必须仍存在且可选择；有颜色和尺码时应验证组合可购买，不能只分别命中两个值。 - 高置信且候选、理由、组合校验均通过：沿用 #188 独立路径写为 `confirmed`，刷新批量预检后变为“可创建采购”。 - 低置信、无唯一结果、Provider 异常或组合无效：保留待人工，不覆盖已有映射。 - 服务端仍须逐条重新校验资格，不能只相信前端提交的候选列表；混合批次逐条返回成功、待人工、失败或跳过原因。 ### 非目标与不变项 - 不对“已经可创建采购”的明细重新 AI 匹配，不覆盖其有效映射；若怀疑其被误判，应修复采购预检或解析数据，而不是扩大 AI 覆盖范围。 - 不修改通用 `SetMapping` 的 AI 强制 `pending` 语义；高置信自动确认继续限定在 #188 独立入口。 - 不自动创建采购任务、PDD 订单或付款；匹配成功只获得“可创建采购”资格，仍需用户点击“创建采购”。 - 不新增数据库表或迁移；如组合约束无法由现有 PDD 归档证明，则必须停止自动确认并回到人工处理，不以猜测补齐。 ### 修订验收与必测场景 - 预检对每条明细返回准确的 `aiMatchEligible` 与禁用原因，前端按钮计数与服务端一致。 - 解析失败/存疑、未关联、PDD 待采集/采集中/失败、PDD 无规格、已有有效映射、已有采购任务均不进入 AI，并显示对应原因。 - 两端规格具备条件且映射未解决时进入 AI；高置信有效组合变为“可创建采购”，低置信或组合无效保持待人工。 - 混合勾选时仅处理适用子集，其余逐条跳过且理由明确；关闭结果后重新预检并保留仍可操作的选择。 - 验证已有 `SetMapping`、`BatchCreate`、采购安全边界及订单/支付禁令没有变化。 ### 当前状态 #188 已上线但尚未验收。本变更属于候选资格/API/UI 行为调整，现标记为**待用户重新确认**；确认前不修改生产代码、不再次发布。确认后继续在 #188 内实施、测试、更新共享 API/Wiki、提交推送，并在单独取得线上发布授权后再部署。
ila commented 2026-09-01 14:15:36 +08:00
Author
Owner
Copy Link
Copy Source

修订方案已确认，待实施

  • 确认人：用户
  • 确认时间：2026-09-01 14:15:35 +08:00（Asia/Shanghai）
  • 确认原话：确认 #188 修订方案
  • 确认范围：#188 评论 #issuecomment-6893 中记录的显式 iMatchEligible / iMatchDisabledReason 资格判定、以 SYB 采购规格匹配关联 PDD 当前可选规格、组合有效性校验、混合批次逐条结果及前端计数刷新方案。
  • 安全边界确认：parse_status=uncertain（解析存疑）不进入批量 AI 自动确认，必须先人工修正；高置信自动 confirmed 仍只限 #188 独立入口；不覆盖已有可靠映射，不自动创建采购任务、订单或付款。
  • 当前状态：修订方案已确认，可以继续实施；本次确认不包含线上发布授权，代码完成和验证后仍需单独取得发布确认。
## 修订方案已确认，待实施 - 确认人：用户 - 确认时间：2026-09-01 14:15:35 +08:00（Asia/Shanghai） - 确认原话：确认 #188 修订方案 - 确认范围：#188 评论 #issuecomment-6893 中记录的显式 iMatchEligible / iMatchDisabledReason 资格判定、以 SYB 采购规格匹配关联 PDD 当前可选规格、组合有效性校验、混合批次逐条结果及前端计数刷新方案。 - 安全边界确认：parse_status=uncertain（解析存疑）不进入批量 AI 自动确认，必须先人工修正；高置信自动 confirmed 仍只限 #188 独立入口；不覆盖已有可靠映射，不自动创建采购任务、订单或付款。 - 当前状态：修订方案已确认，可以继续实施；本次确认不包含线上发布授权，代码完成和验证后仍需单独取得发布确认。
ila commented 2026-09-01 14:49:51 +08:00
Author
Owner
Copy Link
Copy Source

实施完成，待验收

已按 2026-09-01 确认的 #188 修订方案完成并推送，提交：5446ebe。

实现

  • batch-preview 新增显式 aiMatchEligible / aiMatchDisabledReason；Admin 候选数和勾选资格只认服务端字段，不再以 processStage=color_mapping 推断。
  • 仅 parse_status=success、蝦皮/PDD 关联完整、PDD 当前规格可用且最近成功/部分成功采集存在完整可售 SKU 组合证据的明细可进入批量 AI 匹配；uncertain 必须先人工修正。
  • 保留有效的部分人工映射；已有完整可靠映射、确定性唯一结果、已有采购任务/订单、缺少组合证据或存在额外规格维度时返回明确跳过原因。
  • AI 高置信度结果除阈值和理由外，还必须属于当前候选并命中同一个完整可售颜色+尺码组合；无效组合转人工且不覆盖旧映射。
  • 修复确定性匹配失败后仍按全颜色价格误报“可创建采购”的预检缺陷。
  • 未创建采购任务、订单或付款；本轮未发布线上。

验证

  • go test ./app/goauto/purchase -count=1：通过。
  • go build：通过。
  • pnpm exec eslint src/views/goauto/syb-products/index.vue：通过。
  • pnpm run build:prod：通过（仅既有 CSS/chunk size 警告）。
  • pnpm exec playwright test tests/e2e/syb-product-layout.spec.ts：8/8 通过。
  • python dev_scripts/harness.py check --strict：通过。
  • git diff --cached --check：通过（提交前）。

已知的非本工单阻断

  • go test ./...：app/goauto/apprelease.TestParseBuiltAgentAPKWhenAvailable 读取到工作区既有 APK 0.9.37（versionCode 50），与测试绑定期望不一致；#188 的 purchase 包已单独全通过。
  • pnpm run lint：被未修改的 web/src/views/goauto/purchase-tasks/index.vue 既有 Tab/空格混排阻断；本工单修改页面单文件 lint 已通过。
  • 全量 sync --check 串行逐页访问 Gitea 很慢，最终仅报告用户原有 docs/12-syb-erp-interface.md 重复镜像头且 revision/正文不一致；未覆盖该无关改动。#188 两页已在线回读并同步：Business-Rules-and-Glossary@b9d13a3576f331091687bca1d6407f9d41901fad、Android-Agent-API-Contract@5afa14ea875e38dc08718a19d4646147a56d829f。

请按修订后的 SYB 商品页 AI 候选数、禁用原因、混合批次结果和可采购状态进行验收；工单保持开启。

## 实施完成，待验收 已按 2026-09-01 确认的 #188 修订方案完成并推送，提交：`5446ebe`。 ### 实现 - `batch-preview` 新增显式 `aiMatchEligible` / `aiMatchDisabledReason`；Admin 候选数和勾选资格只认服务端字段，不再以 `processStage=color_mapping` 推断。 - 仅 `parse_status=success`、蝦皮/PDD 关联完整、PDD 当前规格可用且最近成功/部分成功采集存在完整可售 SKU 组合证据的明细可进入批量 AI 匹配；`uncertain` 必须先人工修正。 - 保留有效的部分人工映射；已有完整可靠映射、确定性唯一结果、已有采购任务/订单、缺少组合证据或存在额外规格维度时返回明确跳过原因。 - AI 高置信度结果除阈值和理由外，还必须属于当前候选并命中同一个完整可售颜色+尺码组合；无效组合转人工且不覆盖旧映射。 - 修复确定性匹配失败后仍按全颜色价格误报“可创建采购”的预检缺陷。 - 未创建采购任务、订单或付款；本轮未发布线上。 ### 验证 - `go test ./app/goauto/purchase -count=1`：通过。 - `go build`：通过。 - `pnpm exec eslint src/views/goauto/syb-products/index.vue`：通过。 - `pnpm run build:prod`：通过（仅既有 CSS/chunk size 警告）。 - `pnpm exec playwright test tests/e2e/syb-product-layout.spec.ts`：8/8 通过。 - `python dev_scripts/harness.py check --strict`：通过。 - `git diff --cached --check`：通过（提交前）。 ### 已知的非本工单阻断 - `go test ./...`：`app/goauto/apprelease.TestParseBuiltAgentAPKWhenAvailable` 读取到工作区既有 APK `0.9.37`（versionCode 50），与测试绑定期望不一致；#188 的 purchase 包已单独全通过。 - `pnpm run lint`：被未修改的 `web/src/views/goauto/purchase-tasks/index.vue` 既有 Tab/空格混排阻断；本工单修改页面单文件 lint 已通过。 - 全量 `sync --check` 串行逐页访问 Gitea 很慢，最终仅报告用户原有 `docs/12-syb-erp-interface.md` 重复镜像头且 revision/正文不一致；未覆盖该无关改动。#188 两页已在线回读并同步：`Business-Rules-and-Glossary@b9d13a3576f331091687bca1d6407f9d41901fad`、`Android-Agent-API-Contract@5afa14ea875e38dc08718a19d4646147a56d829f`。 请按修订后的 SYB 商品页 AI 候选数、禁用原因、混合批次结果和可采购状态进行验收；工单保持开启。
ila commented 2026-09-01 15:18:04 +08:00
Author
Owner
Copy Link
Copy Source

需求再次修订并确认（2026-09-01）

用户确认：AI 匹配的业务含义是，把一条 SYB 货运单商品已解析出的目标颜色、目标尺码，与其关联 PDD 商品的可售规格组合进行匹配。

本次以以下规则替换此前“可在创建采购时临时确定性匹配”的口径：

  • 规格匹配必须先成功并保存为已确认映射，SYB 商品才允许进入“可创建采购”。
  • 没有已保存确认映射的商品显示为“待规格匹配”，即使程序能够推导出唯一精确结果，也不能提前显示为可创建采购。
  • 批量 AI 匹配遇到唯一确定性精确匹配时，不调用外部 AI，直接以 exact_match + confirmed 保存；其余候选再调用 AI。
  • AI 返回结果必须命中当前 PDD 商品完整且可售的 SKU 组合，达到阈值后以 ai_match + confirmed 保存。
  • 创建采购前服务端重新校验已保存确认映射及完整可售 SKU 组合；缺失时拒绝创建，不进入采购任务内的人工匹配步骤。
  • 不新增数据库迁移，不涉及支付或自动下单，不在本工单执行线上发布。

追加验收：

  1. 未保存规格映射的 SYB 商品不再出现在“可创建采购”，而出现在“待规格匹配”。
  2. 唯一精确匹配可由批量 AI 匹配动作直接保存，且无需外部 AI Provider。
  3. 匹配保存后刷新列表，商品才进入“可创建采购”。
  4. 服务端无法被绕过：未保存确认映射时批量创建采购失败并返回明确原因。
## 需求再次修订并确认（2026-09-01） 用户确认：AI 匹配的业务含义是，把一条 SYB 货运单商品已解析出的目标颜色、目标尺码，与其关联 PDD 商品的可售规格组合进行匹配。 本次以以下规则替换此前“可在创建采购时临时确定性匹配”的口径： - 规格匹配必须先成功并保存为已确认映射，SYB 商品才允许进入“可创建采购”。 - 没有已保存确认映射的商品显示为“待规格匹配”，即使程序能够推导出唯一精确结果，也不能提前显示为可创建采购。 - 批量 AI 匹配遇到唯一确定性精确匹配时，不调用外部 AI，直接以 `exact_match + confirmed` 保存；其余候选再调用 AI。 - AI 返回结果必须命中当前 PDD 商品完整且可售的 SKU 组合，达到阈值后以 `ai_match + confirmed` 保存。 - 创建采购前服务端重新校验已保存确认映射及完整可售 SKU 组合；缺失时拒绝创建，不进入采购任务内的人工匹配步骤。 - 不新增数据库迁移，不涉及支付或自动下单，不在本工单执行线上发布。 追加验收： 1. 未保存规格映射的 SYB 商品不再出现在“可创建采购”，而出现在“待规格匹配”。 2. 唯一精确匹配可由批量 AI 匹配动作直接保存，且无需外部 AI Provider。 3. 匹配保存后刷新列表，商品才进入“可创建采购”。 4. 服务端无法被绕过：未保存确认映射时批量创建采购失败并返回明确原因。
ila commented 2026-09-01 15:32:59 +08:00
Author
Owner
Copy Link
Copy Source

实施完成，待验收（2026-09-01）

已按评论 6917 的修订规则完成并推送。

实现结果

  • SYB 列表与处理阶段不再把内存中临时推导出的唯一结果视为“可创建采购”。目标颜色、尺码未保存为确认映射时统一进入“规格待匹配”。
  • batch-preview 仅在已保存确认映射且该颜色+尺码共同命中最近一次成功/部分成功采集的完整可售 SKU 组合时返回 eligible=true。
  • batch-spec-match 遇到唯一确定性结果时不调用外部 AI，直接以 exact_match + confirmed 保存；非确定性结果仍需 AI 高置信度、理由和可售组合校验后才保存。
  • batch 创建入口重新执行上述持久化映射门禁，未保存确认映射时返回 PURCHASE_SPEC_MAPPING_REQUIRED，不会创建后再进入人工规格匹配。
  • 页面阶段文案由“颜色待匹配”调整为“规格待匹配”，并明确提示“先完成并保存规格匹配，商品才可以创建采购”。
  • 保留既有采购重试和通用单条创建契约，不把 #188 的新门禁扩展到历史任务重试。

提交

  • 776db13 fix: require saved spec match before purchase (#188)
  • 已推送 origin/main。

验证

通过：

  • go test ./app/goauto/purchase ./app/goauto/shopeeproduct
  • scripts/verify.ps1 -Component server：go test ./... 与 go build 均通过
  • pnpm exec eslint src/views/goauto/syb-products/index.vue
  • Playwright：syb-product-layout.spec.ts + pdd-related-products.spec.ts，9/9 通过
  • pnpm run build:prod 通过（仅有仓库既有 CSS/分包告警）
  • python dev_scripts/harness.py check --strict 通过
  • 受影响 Wiki 镜像定向 sync + sync --check 通过

全量 Web scripts/verify.ps1 -Component web 停在既有文件 web/src/views/goauto/purchase-tasks/index.vue 的 Tab/空格 ESLint 错误；本次未修改该文件，SYB 页面定向 ESLint 与生产构建均通过。

Wiki

  • Business Rules and Glossary：687439543630832db26d2c73f6ada980e34eea10
  • Android Agent API Contract：b3d7656c10bb3ec93894f69dbe078c5aa3037ef7

未验证/未执行

  • 未执行真实线上数据验收、真机采购或创建订单。
  • 未执行线上发布（本次请求未授权发布）。

工单保持打开，等待用户验收。

## 实施完成，待验收（2026-09-01） 已按评论 6917 的修订规则完成并推送。 ### 实现结果 - SYB 列表与处理阶段不再把内存中临时推导出的唯一结果视为“可创建采购”。目标颜色、尺码未保存为确认映射时统一进入“规格待匹配”。 - `batch-preview` 仅在已保存确认映射且该颜色+尺码共同命中最近一次成功/部分成功采集的完整可售 SKU 组合时返回 `eligible=true`。 - `batch-spec-match` 遇到唯一确定性结果时不调用外部 AI，直接以 `exact_match + confirmed` 保存；非确定性结果仍需 AI 高置信度、理由和可售组合校验后才保存。 - `batch` 创建入口重新执行上述持久化映射门禁，未保存确认映射时返回 `PURCHASE_SPEC_MAPPING_REQUIRED`，不会创建后再进入人工规格匹配。 - 页面阶段文案由“颜色待匹配”调整为“规格待匹配”，并明确提示“先完成并保存规格匹配，商品才可以创建采购”。 - 保留既有采购重试和通用单条创建契约，不把 #188 的新门禁扩展到历史任务重试。 ### 提交 - `776db13 fix: require saved spec match before purchase (#188)` - 已推送 `origin/main`。 ### 验证 通过： - `go test ./app/goauto/purchase ./app/goauto/shopeeproduct` - `scripts/verify.ps1 -Component server`：`go test ./...` 与 `go build` 均通过 - `pnpm exec eslint src/views/goauto/syb-products/index.vue` - Playwright：`syb-product-layout.spec.ts` + `pdd-related-products.spec.ts`，9/9 通过 - `pnpm run build:prod` 通过（仅有仓库既有 CSS/分包告警） - `python dev_scripts/harness.py check --strict` 通过 - 受影响 Wiki 镜像定向 `sync` + `sync --check` 通过 全量 Web `scripts/verify.ps1 -Component web` 停在既有文件 `web/src/views/goauto/purchase-tasks/index.vue` 的 Tab/空格 ESLint 错误；本次未修改该文件，SYB 页面定向 ESLint 与生产构建均通过。 ### Wiki - Business Rules and Glossary：`687439543630832db26d2c73f6ada980e34eea10` - Android Agent API Contract：`b3d7656c10bb3ec93894f69dbe078c5aa3037ef7` ### 未验证/未执行 - 未执行真实线上数据验收、真机采购或创建订单。 - 未执行线上发布（本次请求未授权发布）。 工单保持打开，等待用户验收。
ila commented 2026-09-01 16:01:38 +08:00
Author
Owner
Copy Link
Copy Source

资格判断修订确认（2026-09-01）

根据本地订单 260901TA39HMUY 验证结果，#188 对 SYB 规格可信度的实现遗漏了既有“人工修正与解析成功同等可信”规则。

本次继续在 #188 内修订：

  • parse_status=success 或 manually_confirmed=true 均视为可信的 SYB 目标规格。
  • 人工确认只放宽解析前置判断；PDD 商品仍须已采集并存在完整可售 SKU 组合。
  • 仍须先完成并保存颜色/尺码映射，才允许创建采购；不恢复创建任务后的人工匹配兜底。
  • 唯一确定性结果继续通过批量规格匹配保存为 exact_match + confirmed，再进入“可创建采购”。
  • 未人工确认的 uncertain / failed 仍明确阻断。

回归验收：人工已确认但保留原解析状态为 uncertain 的明细，可以进入规格匹配；映射未保存前不能创建采购，保存后才可创建。

## 资格判断修订确认（2026-09-01） 根据本地订单 `260901TA39HMUY` 验证结果，#188 对 SYB 规格可信度的实现遗漏了既有“人工修正与解析成功同等可信”规则。 本次继续在 #188 内修订： - `parse_status=success` **或** `manually_confirmed=true` 均视为可信的 SYB 目标规格。 - 人工确认只放宽解析前置判断；PDD 商品仍须已采集并存在完整可售 SKU 组合。 - 仍须先完成并保存颜色/尺码映射，才允许创建采购；不恢复创建任务后的人工匹配兜底。 - 唯一确定性结果继续通过批量规格匹配保存为 `exact_match + confirmed`，再进入“可创建采购”。 - 未人工确认的 `uncertain` / `failed` 仍明确阻断。 回归验收：人工已确认但保留原解析状态为 `uncertain` 的明细，可以进入规格匹配；映射未保存前不能创建采购，保存后才可创建。
ila commented 2026-09-01 16:05:08 +08:00
Author
Owner
Copy Link
Copy Source

修订实施完成，待验收（2026-09-01）

已按评论 6920 完成：

  • 新增统一可信规格判断：parse_status=success || manually_confirmed=true。
  • 采购批量预检与批量规格匹配资格共同使用该判断。
  • 未人工确认的 uncertain / failed 仍被阻断。
  • 规格映射保存门禁未放松：人工确认只允许进入匹配，仍须确认映射命中完整可售 SKU 组合后才可创建采购。
  • 新增回归测试，覆盖 uncertain + manuallyConfirmed 从“规格待匹配”到唯一精确匹配保存，再进入“可创建采购”的完整过程。

提交：4a1b4af fix: trust manually confirmed SYB specs (#188)，已推送 origin/main。

验证通过：

  • go test ./app/goauto/purchase
  • scripts/verify.ps1 -Component server（go test ./...、go build）
  • python dev_scripts/harness.py check --strict
  • 受影响 Wiki 镜像定向 sync + sync --check

Wiki revisions：

  • Business Rules and Glossary：3e4f463cfa026a09ba125f2eb376bd42ef41c880
  • Android Agent API Contract：c214791a0b055e5b56c0ad05e73829a1f141dd46

未执行线上发布、真实采购或订单创建。本地已运行的 8010 进程需要重启后才会加载该提交。工单继续保持待验收。

## 修订实施完成，待验收（2026-09-01） 已按评论 6920 完成： - 新增统一可信规格判断：`parse_status=success || manually_confirmed=true`。 - 采购批量预检与批量规格匹配资格共同使用该判断。 - 未人工确认的 `uncertain` / `failed` 仍被阻断。 - 规格映射保存门禁未放松：人工确认只允许进入匹配，仍须确认映射命中完整可售 SKU 组合后才可创建采购。 - 新增回归测试，覆盖 `uncertain + manuallyConfirmed` 从“规格待匹配”到唯一精确匹配保存，再进入“可创建采购”的完整过程。 提交：`4a1b4af fix: trust manually confirmed SYB specs (#188)`，已推送 `origin/main`。 验证通过： - `go test ./app/goauto/purchase` - `scripts/verify.ps1 -Component server`（`go test ./...`、`go build`） - `python dev_scripts/harness.py check --strict` - 受影响 Wiki 镜像定向 `sync` + `sync --check` Wiki revisions： - Business Rules and Glossary：`3e4f463cfa026a09ba125f2eb376bd42ef41c880` - Android Agent API Contract：`c214791a0b055e5b56c0ad05e73829a1f141dd46` 未执行线上发布、真实采购或订单创建。本地已运行的 8010 进程需要重启后才会加载该提交。工单继续保持待验收。
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#188