来源：2026-09-15 部署 #275～#280 前的线上核对。用户要求「按 1→2→3 走，然后部署」，其中 1 即本工单。
sybimport.Parse 把空格分隔的「颜色 尺码」整条当成颜色，尺码为空，且状态判为 success。
sybimport.Parse
success
线上实测（be03972，2026-09-14 已部署）：
be03972
"黑色 XL" -> status=success color="黑色 XL" size="" note="仅识别到颜色" "紅色 M" -> status=success color="紅色 M" size="" note="仅识别到颜色"
解析器自己在 note 里写了「仅识别到颜色」，却给了 success。
note
success 的行永远不会进 AI 解析队列——ai_parse_batch.go 的候选查询是：
ai_parse_batch.go
Where("parse_status IN ?", []string{models.SYBParseStatusUncertain, models.SYBParseStatusFailed})
因此这批数据不会被任何机制纠正，带着错误的颜色和空尺码直接进入采购规格匹配。
2026-09-15 线上统计：
SELECT COUNT(*) FROM syb_product WHERE parse_status='success' AND target_size=''; -> 152
152 条中并非全部误判（部分商品本来就是单维度），具体构成待另行核查。
b83f20c（#274 accept descriptive color specs）删除了 ambiguousPattern 这道闸：
b83f20c
ambiguousPattern
-var ambiguousPattern = regexp.MustCompile(`[+＋\s]`) - if only != "" && !ambiguousPattern.MatchString(only) { - if ambiguousPattern.MatchString(colorPart) { - return ParseResult{... Status: uncertain, Note: "颜色部分含备注文本或多个分隔符，拆分结果可能不准确"} - }
#274 的意图是让描述性颜色（黑色+白色 簡約親膚）被接受而不是被拒绝，这个意图是对的；副作用是 黑色 XL 也一并放行。parse.go 的文档注释仍停留在「no comma -> uncertain」的旧描述，未随 #274 更新。
黑色+白色 簡約親膚
黑色 XL
parse.go
不恢复被删的旧闸（那会退回 #274 之前、重新拒绝描述性颜色）。改为把空格当作与逗号同等的分隔符，复用逗号分支已有的规则：恰好一个空格分隔 token 带明确尺码特征时才拆分。这不构成猜测，与既有契约一致。
新增 splitOnWhitespace：
splitOnWhitespace
explicitSizePattern
接入 Parse 的两处单维度返回点（无逗号分支、逗号存在但一侧为空分支），并修正过期的文档注释。
Parse
黑色
XL
XL 黑色
均碼
S M L
黑色,XL
后端解析逻辑，无界面变化，不强制 UI 原型。
紅色 M
go build ./... 与 go test ./app/goauto/sybimport/...。
go build ./...
go test ./app/goauto/sybimport/...
[必须] 该包存在 12 个先于本工单的失败用例，来自 #272/#274 改变契约后未更新的旧断言，已另行建单记录。本工单前后失败集合必须完全一致，不得新增。
[必须]
解析规则属于业务规则。parse.go 的文档注释随本次改动更新；若 Wiki 业务规则页面记录了旧的 uncertain 描述，需一并更新。
1d01186
be03972..1d01186
main
/home/goauto/releases/20260915-1d01186
65e404c4721d592a
systemctl is-active goauto.service
active
127.0.0.1:8010
collection_task
shopee_product
外部入口验证：
GET /
GET /api/admin/v1/collection-tasks
{"code":401,"msg":"cookie token is empty"}
POST /api/admin/v1/collection-tasks/image-search/batch
{"code":401,...}
最后两行是关键对照：图搜接口返回 401 而非 404，证明新路由已注册。
回退方式：把 current 软链切回 20260914-be03972-r2 后重启。两条迁移均为加列与放宽约束，不阻碍回退到旧二进制。
current
20260914-be03972-r2
提交：93a175d。改动 server/app/goauto/sybimport/parse.go 51 行，新增 parse_whitespace_split_test.go 80 行。
93a175d
server/app/goauto/sybimport/parse.go
parse_whitespace_split_test.go
新增 splitOnWhitespace：token 数 < 2 不拆；多于一个 token 命中 explicitSizePattern 不拆（对齐逗号分支「两侧均像尺码则无法安全识别颜色」）；恰好一个命中时该 token 为尺码、其余合并为颜色。接入 Parse 的两处单维度返回点，并修正停留在旧 uncertain 描述的文档注释。
紅色
M
黑色 XL 加厚
黑色 加厚
go build ./... 通过；新增 5 个测试全部通过（含 #274 描述性颜色不被退回的回归）。
[必须] 该包的 12 个失败用例先于本工单存在（#285）。本次提交前后失败集合逐条 diff 完全一致，数量 12 → 12，未新增。
线上 parse_status='success' AND target_size='' 共 152 条（2026-09-15 统计）。其中并非全部误判——部分商品本来就是单维度。修复只影响之后新解析的数据，存量不会自动修正。是否执行 #282 的批量重解析脚本需单独确认，建议先核查这 152 条的实际构成。
parse_status='success' AND target_size=''
已上线，保持待验收。
No dependencies set.
The note is not visible to the blocked user.
原始需求
来源：2026-09-15 部署 #275～#280 前的线上核对。用户要求「按 1→2→3 走，然后部署」，其中 1 即本工单。
缺陷
sybimport.Parse把空格分隔的「颜色 尺码」整条当成颜色，尺码为空，且状态判为success。线上实测（
be03972，2026-09-14 已部署）：解析器自己在
note里写了「仅识别到颜色」，却给了success。影响
success的行永远不会进 AI 解析队列——ai_parse_batch.go的候选查询是：因此这批数据不会被任何机制纠正，带着错误的颜色和空尺码直接进入采购规格匹配。
2026-09-15 线上统计：
152 条中并非全部误判（部分商品本来就是单维度），具体构成待另行核查。
根因
b83f20c（#274 accept descriptive color specs）删除了ambiguousPattern这道闸：#274 的意图是让描述性颜色（
黑色+白色 簡約親膚）被接受而不是被拒绝，这个意图是对的；副作用是黑色 XL也一并放行。parse.go的文档注释仍停留在「no comma -> uncertain」的旧描述，未随 #274 更新。方案
不恢复被删的旧闸（那会退回 #274 之前、重新拒绝描述性颜色）。改为把空格当作与逗号同等的分隔符，复用逗号分支已有的规则：恰好一个空格分隔 token 带明确尺码特征时才拆分。这不构成猜测，与既有契约一致。
新增
splitOnWhitespace：explicitSizePattern-> 不拆（对齐逗号分支「两侧均像尺码则无法安全识别颜色」）接入
Parse的两处单维度返回点（无逗号分支、逗号存在但一侧为空分支），并修正过期的文档注释。行为对照
黑色 XL黑色 XLsize=``黑色size=XLXL 黑色XL 黑色size=``黑色size=XL黑色+白色 簡約親膚均碼均碼黑色黑色S M LS M L黑色,XL黑色size=XL设计证据
后端解析逻辑，无界面变化，不强制 UI 原型。
验收
黑色 XL/紅色 M/XL 黑色解析出颜色与尺码两个维度。黑色+白色 簡約親膚行为与 #274 一致，未被退回拒绝。均碼、黑色、黑色,XL行为不变。S M L）不拆分。验证
go build ./...与go test ./app/goauto/sybimport/...。[必须]该包存在 12 个先于本工单的失败用例，来自 #272/#274 改变契约后未更新的旧断言，已另行建单记录。本工单前后失败集合必须完全一致，不得新增。风险
S M L这类多尺码 token 按最保守处理（不拆）。实际数据中该形态的占比与是否应进 AI 兜底尚无证据，如后续有数据可再调整。文档影响
解析规则属于业务规则。
parse.go的文档注释随本次改动更新；若 Wiki 业务规则页面记录了旧的 uncertain 描述，需一并更新。上线信息（共用）
1d01186，已推送be03972..1d01186到main。/home/goauto/releases/20260915-1d01186，二进制 SHA-256 前缀65e404c4721d592a（本地与服务器一致）。systemctl is-active goauto.service=active，监听127.0.0.1:8010。collection_task222 行、shopee_product26901 行，逐一相符。外部入口验证：
GET /GET /api/admin/v1/collection-tasks{"code":401,"msg":"cookie token is empty"}POST /api/admin/v1/collection-tasks/image-search/batch{"code":401,...}最后两行是关键对照：图搜接口返回 401 而非 404，证明新路由已注册。
回退方式：把
current软链切回20260914-be03972-r2后重启。两条迁移均为加列与放宽约束，不阻碍回退到旧二进制。实施
提交：
93a175d。改动server/app/goauto/sybimport/parse.go51 行，新增parse_whitespace_split_test.go80 行。新增
splitOnWhitespace：token 数 < 2 不拆；多于一个 token 命中explicitSizePattern不拆（对齐逗号分支「两侧均像尺码则无法安全识别颜色」）；恰好一个命中时该 token 为尺码、其余合并为颜色。接入Parse的两处单维度返回点，并修正停留在旧 uncertain 描述的文档注释。行为核对（实测）
黑色 XL黑色 XLsize=``黑色size=XL紅色 M紅色 Msize=``紅色size=MXL 黑色XL 黑色size=``黑色size=XL黑色 XL 加厚黑色 加厚size=XL黑色+白色 簡約親膚均碼/黑色/黑色,XLS M LS M L验证
go build ./...通过；新增 5 个测试全部通过（含 #274 描述性颜色不被退回的回归）。[必须]该包的 12 个失败用例先于本工单存在（#285）。本次提交前后失败集合逐条 diff 完全一致，数量 12 → 12，未新增。存量数据未处理
线上
parse_status='success' AND target_size=''共 152 条（2026-09-15 统计）。其中并非全部误判——部分商品本来就是单维度。修复只影响之后新解析的数据，存量不会自动修正。是否执行 #282 的批量重解析脚本需单独确认，建议先核查这 152 条的实际构成。状态
已上线，保持待验收。