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

评估：SYB 规格剥离 【...】 导致不同规格塌缩成同一采购键 #288

New Issue
Open
opened 2026-09-16 09:56:30 +08:00 by ila · 1 comment
ila commented 2026-09-16 09:56:30 +08:00
Owner
Copy Link
Copy Source

原始需求

  • 来源：2026-09-16 与用户讨论「同一虾皮商品多颜色采购」时发现，用户确认按此建单做方案评估。
  • 本工单只做方案评估，不直接实施：改动触及 #41 定下的解析契约，影响面需用户确认后才能定方案。

缺陷

sybimport.Parse 在拆分 SYB productSpec 时剥离 【...】：

var bracketPattern = regexp.MustCompile(`【[^】]*】`)
func stripBrackets(part string) string {
    return strings.TrimSpace(bracketPattern.ReplaceAllString(part, ""))
}

该规则的前提是「【...】 是备注文本」。线上数据表明这个前提经常不成立：括号里承载的是真正的规格标识。

剥离后不同规格塌缩成同一个 target_color，而 target_color 正是采购查映射的键：

mappedColor, mappedSize, source := confirmedMappings(shopee.SpecsJSON, syb.TargetColor, syb.TargetSize)

同键即同映射，Agent 会为不同的虾皮规格点击同一个 PDD 规格值。

线上规模（2026-09-16 核对）

受影响虾皮商品      61 个
塌缩的键            78 个
被合并的原始规格    190 个      ← 190 个真实规格挤进 78 个键
单键最多合并        6 个
受影响 SYB 明细     407 条
其中所属商品已有映射 36 条
受影响且已关联 PDD  37 个商品

典型样本：

虾皮商品 塌缩键 原始规格
1355 白色 白色【207A】 白色【209A】 白色【211A】 白色【257A】 白色【D113A】 白色【M0086B】
1355 黑色 黑色【204A】 黑色【208A】 黑色【210A】 黑色【D0106A右下 】 黑色【M0059C1】 黑色【M0063C1】
1298 物理防曬 【深灰+淺灰】 【淺灰+粉色】 【黑色+深灰】 【黑色+粉色】
1946 A013#漏胸連體襪2條裝 6 个不同规格

1298 最严重：颜色信息完全在括号内，剥离后整条颜色语义丢失。

括号内容至少有两类必须保留：

  1. 款号色号：白色【207A】、黑色【M0059C1】
  2. 颜色组合：【深灰+淺灰】、【黑色+粉色】

当前损失：尚未造成错误采购

落在塌缩键上的采购任务  3 笔
其中 order_created      0 笔
任务 状态 原始规格 塌缩键 实际购买
134 failed 粉色【短袖】 粉色 未买成
154 failed 粉色【短袖】 粉色 未买成
191 order_result_unknown 白色【短袖】 白色 白色短袖防走光（与原规格相符）

[必须] 之所以没出事，是因为每个塌缩键目前只有一条规格真正下过单，不是设计上有保证。上表 6 个高风险键全部「尚未采购」：一旦同一键下的两条不同规格同时进入采购，必然有一条买错。风险已装好，只是尚未触发。

为什么优先于虾皮规格同步

用户提供了按虾皮商品 id 返回完整颜色尺码的接口，计划用它一次性同步并匹配全部规格。该需求应排在本工单之后：

  1. 接口返回的是虾皮原文（白色 【雙梅花】純棉），而 SYB 经 Parse 剥离后是 白色 純棉，两边键不一致；
  2. 拉取全量规格会把 1355 的 6 个白色一次性全撞进同一个键，显著放大塌缩，甚至可能覆盖掉现有正确映射；
  3. 本工单会改变键的定义，若先做规格同步，之后所有映射要重算一遍。

先做规格同步等于在有缺陷的键体系上盖楼。

待评估的方案方向

方向 A：不再剥离，保留原文

target_color 直接使用虾皮原文。优点：键与虾皮、与用户的新接口天然一致，规格同步不需要任何转换；语义无损。

代价：改变 #41 契约；407 条受影响明细的 target_color 需重算；36 条已有映射需重建；AI 匹配面对更长的字符串（白色【207A】 对 PDD 值）准确率需重新评估。

方向 B：只剥离确认为备注的内容

保留款号、色号、颜色组合，仅剥离纯说明性文本。需要可靠的判别规则，目前没有证据支持能可靠区分，风险是继续错。

方向 C：保留剥离，但检测塌缩并明确失败

不改契约，写入档案时发现两个规格塌缩同键就拒绝并报错。把「静默买错」变成「明确失败」，但不解决根因，且 78 个键会立刻开始报错。

[必须] 三个方向都需要评估对已有 407 条明细与 36 条映射的迁移或重建方案，以及是否需要回溯已完成的采购任务。

非目标

  • 本工单不实施，不改代码。
  • 不处理虾皮规格同步（另行建单，依赖本工单结论）。
  • 不回溯修改已完成的采购任务。

验收

  • 用户确认采用哪个方向。
  • 该方向对已有数据的迁移/重建方案明确。
  • 对 AI 匹配准确率的影响有评估结论。
  • 确认是否需要复核历史采购任务。

风险

改动解析契约会影响 SYB 同步、规格匹配与采购三条链路。在方案确认前不得实施。

文档影响

【...】 的处理规则属于业务规则，方案确定后需更新对应 Wiki 页面中 #41 的描述。

## 原始需求 - 来源：2026-09-16 与用户讨论「同一虾皮商品多颜色采购」时发现，用户确认按此建单做方案评估。 - 本工单**只做方案评估，不直接实施**：改动触及 #41 定下的解析契约，影响面需用户确认后才能定方案。 ## 缺陷 `sybimport.Parse` 在拆分 SYB `productSpec` 时剥离 `【...】`： ```go var bracketPattern = regexp.MustCompile(`【[^】]*】`) func stripBrackets(part string) string { return strings.TrimSpace(bracketPattern.ReplaceAllString(part, "")) } ``` 该规则的前提是「`【...】` 是备注文本」。线上数据表明这个前提**经常不成立**：括号里承载的是真正的规格标识。 剥离后不同规格塌缩成同一个 `target_color`，而 `target_color` 正是采购查映射的键： ```go mappedColor, mappedSize, source := confirmedMappings(shopee.SpecsJSON, syb.TargetColor, syb.TargetSize) ``` 同键即同映射，Agent 会为不同的虾皮规格点击**同一个** PDD 规格值。 ## 线上规模（2026-09-16 核对） ``` 受影响虾皮商品 61 个 塌缩的键 78 个 被合并的原始规格 190 个 ← 190 个真实规格挤进 78 个键 单键最多合并 6 个 受影响 SYB 明细 407 条 其中所属商品已有映射 36 条 受影响且已关联 PDD 37 个商品 ``` 典型样本： | 虾皮商品 | 塌缩键 | 原始规格 | |---|---|---| | 1355 | `白色` | `白色【207A】` `白色【209A】` `白色【211A】` `白色【257A】` `白色【D113A】` `白色【M0086B】` | | 1355 | `黑色` | `黑色【204A】` `黑色【208A】` `黑色【210A】` `黑色【D0106A右下 】` `黑色【M0059C1】` `黑色【M0063C1】` | | 1298 | `物理防曬` | `【深灰+淺灰】` `【淺灰+粉色】` `【黑色+深灰】` `【黑色+粉色】` | | 1946 | `A013#漏胸連體襪2條裝` | 6 个不同规格 | 1298 最严重：颜色信息**完全在括号内**，剥离后整条颜色语义丢失。 括号内容至少有两类必须保留： 1. **款号色号**：`白色【207A】`、`黑色【M0059C1】` 2. **颜色组合**：`【深灰+淺灰】`、`【黑色+粉色】` ## 当前损失：尚未造成错误采购 ``` 落在塌缩键上的采购任务 3 笔 其中 order_created 0 笔 ``` | 任务 | 状态 | 原始规格 | 塌缩键 | 实际购买 | |---|---|---|---|---| | 134 | failed | `粉色【短袖】` | `粉色` | 未买成 | | 154 | failed | `粉色【短袖】` | `粉色` | 未买成 | | 191 | order_result_unknown | `白色【短袖】` | `白色` | `白色短袖防走光`（与原规格相符） | `[必须]` 之所以没出事，是因为**每个塌缩键目前只有一条规格真正下过单**，不是设计上有保证。上表 6 个高风险键全部「尚未采购」：一旦同一键下的两条不同规格同时进入采购，必然有一条买错。风险已装好，只是尚未触发。 ## 为什么优先于虾皮规格同步 用户提供了按虾皮商品 id 返回完整颜色尺码的接口，计划用它一次性同步并匹配全部规格。该需求应排在本工单之后： 1. 接口返回的是**虾皮原文**（`白色 【雙梅花】純棉`），而 SYB 经 `Parse` 剥离后是 `白色 純棉`，两边键不一致； 2. 拉取全量规格会把 1355 的 6 个白色**一次性全撞进同一个键**，显著放大塌缩，甚至可能覆盖掉现有正确映射； 3. 本工单会改变键的定义，若先做规格同步，之后所有映射要重算一遍。 先做规格同步等于在有缺陷的键体系上盖楼。 ## 待评估的方案方向 **方向 A：不再剥离，保留原文** `target_color` 直接使用虾皮原文。优点：键与虾皮、与用户的新接口天然一致，规格同步不需要任何转换；语义无损。 代价：改变 #41 契约；407 条受影响明细的 `target_color` 需重算；36 条已有映射需重建；AI 匹配面对更长的字符串（`白色【207A】` 对 PDD 值）准确率需重新评估。 **方向 B：只剥离确认为备注的内容** 保留款号、色号、颜色组合，仅剥离纯说明性文本。需要可靠的判别规则，目前没有证据支持能可靠区分，风险是继续错。 **方向 C：保留剥离，但检测塌缩并明确失败** 不改契约，写入档案时发现两个规格塌缩同键就拒绝并报错。把「静默买错」变成「明确失败」，但不解决根因，且 78 个键会立刻开始报错。 `[必须]` 三个方向都需要评估对**已有 407 条明细与 36 条映射**的迁移或重建方案，以及是否需要回溯已完成的采购任务。 ## 非目标 - 本工单不实施，不改代码。 - 不处理虾皮规格同步（另行建单，依赖本工单结论）。 - 不回溯修改已完成的采购任务。 ## 验收 - [ ] 用户确认采用哪个方向。 - [ ] 该方向对已有数据的迁移/重建方案明确。 - [ ] 对 AI 匹配准确率的影响有评估结论。 - [ ] 确认是否需要复核历史采购任务。 ## 风险 改动解析契约会影响 SYB 同步、规格匹配与采购三条链路。在方案确认前不得实施。 ## 文档影响 `【...】` 的处理规则属于业务规则，方案确定后需更新对应 Wiki 页面中 #41 的描述。
ila commented 2026-09-16 10:09:26 +08:00
Author
Owner
Copy Link
Copy Source

评估结论（2026-09-16）

用户初选方向 A（不再剥离、保留原文）。进一步量化后改为延后实施，先做 #289 检测、再做 #290 同步。

量化后发现 A 的范围远超预期

含【】的明细      11220 条（不是塌缩的那 407 条）
涉及虾皮商品      3733 个（不是 61 个）
其中人工修正过    8 条      ← #41 规定不得被规则重跑覆盖
已有映射的商品    104 个    ← 键变化后映射全部失效，需重建
相关采购任务      184 笔

颜色与尺码的括号性质完全不同

              含括号明细    塌缩键    塌缩率
颜色            2062         78       3.8%
尺码            6106         24       0.4%

尺码括号绝大多数是真备注（S【建議40公斤以內】、M【建議40-50公斤】），剥离正确；颜色括号出问题的概率高 10 倍（款号 白色【207A】、色号 黑色【M0059C1】、颜色组合 【深灰+淺灰】）。

样本虾皮商品 2065（51102181348）的接口返回印证：14 个颜色全部无括号（圓領 彩藍色 / V領 白色），7 个尺码全部带括号且全是体重建议，剥离后 S/M/L/XL/2XL/3XL/4XL 互不冲突。

[必须] 因此纯 A 会让 6106 条本来剥得正确的尺码带上纯噪音去做 AI 匹配，为修 78 个颜色键而污染 6106 条尺码的匹配输入。若将来实施，应收窄为 A″：仅颜色保留原文，尺码继续剥离，范围由 11220 条降至 2062 条。

为什么延后

  1. 至今 0 次错误采购，风险已装好但未触发；
  2. 重建 104 个商品的映射意味着这些规格一次性全部由 AI 重新决定并自动确认——#200 已取消 SYB 批量入口的置信度门槛，没有兜底；
  3. #289 的塌缩检测能以几十分之一的成本达到同样的防护效果（把静默买错变成明确失败）；
  4. #289 上线后的检出频率才是判断 A″ 值不值得做的可靠依据，比现在凭 78 这个静态数字拍板要好。

后续

  • #289 塌缩检测（先做）
  • #290 虾皮完整规格同步（依赖 #289）
  • 本工单保持开启，待 #289 积累真实检出数据后重新评估 A″

「已匹配的 PDD 商品与虾皮原始规格是否一致」的三方对照（用户 2026-09-16 提出）留待 A″ 评估时进行：它回答的是现有 104 个映射有多少是错的，只影响 A″ 的迁移方案，不影响 #289 与 #290。

## 评估结论（2026-09-16） 用户初选方向 A（不再剥离、保留原文）。进一步量化后**改为延后实施**，先做 #289 检测、再做 #290 同步。 ### 量化后发现 A 的范围远超预期 ``` 含【】的明细 11220 条（不是塌缩的那 407 条） 涉及虾皮商品 3733 个（不是 61 个） 其中人工修正过 8 条 ← #41 规定不得被规则重跑覆盖 已有映射的商品 104 个 ← 键变化后映射全部失效，需重建 相关采购任务 184 笔 ``` ### 颜色与尺码的括号性质完全不同 ``` 含括号明细 塌缩键 塌缩率 颜色 2062 78 3.8% 尺码 6106 24 0.4% ``` 尺码括号绝大多数是真备注（`S【建議40公斤以內】`、`M【建議40-50公斤】`），剥离正确；颜色括号出问题的概率高 10 倍（款号 `白色【207A】`、色号 `黑色【M0059C1】`、颜色组合 `【深灰+淺灰】`）。 样本虾皮商品 2065（`51102181348`）的接口返回印证：14 个颜色全部无括号（`圓領 彩藍色` / `V領 白色`），7 个尺码全部带括号且全是体重建议，剥离后 `S/M/L/XL/2XL/3XL/4XL` 互不冲突。 `[必须]` 因此纯 A 会让 6106 条本来剥得正确的尺码带上纯噪音去做 AI 匹配，为修 78 个颜色键而污染 6106 条尺码的匹配输入。若将来实施，应收窄为 **A″：仅颜色保留原文，尺码继续剥离**，范围由 11220 条降至 2062 条。 ### 为什么延后 1. 至今 **0 次错误采购**，风险已装好但未触发； 2. 重建 104 个商品的映射意味着这些规格**一次性全部由 AI 重新决定并自动确认**——#200 已取消 SYB 批量入口的置信度门槛，没有兜底； 3. #289 的塌缩检测能以几十分之一的成本达到同样的防护效果（把静默买错变成明确失败）； 4. #289 上线后的**检出频率**才是判断 A″ 值不值得做的可靠依据，比现在凭 78 这个静态数字拍板要好。 ### 后续 - #289 塌缩检测（先做） - #290 虾皮完整规格同步（依赖 #289） - 本工单保持开启，待 #289 积累真实检出数据后重新评估 A″ 「已匹配的 PDD 商品与虾皮原始规格是否一致」的三方对照（用户 2026-09-16 提出）留待 A″ 评估时进行：它回答的是现有 104 个映射有多少是错的，只影响 A″ 的迁移方案，不影响 #289 与 #290。
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#288