details[].id 是否全局唯一仍未验证——现有 HAR 只抓到一张货运单的两条明细（145306175 / 145306176），样本不足。唯一键当前保守取「货运单号 + 来源明细ID」组合，即使 ID 仅单内唯一也安全。若需改为全局唯一键，需抓取多张货运单的 detail/listByStock 响应验证 ID 是否跨单连续且不重复。
Wiki Product-Requirements-Overview 与 Delivery-Issues 已更新为「Stage A 原型 2026-08-19 已通过，Stage B 待实施」；镜像已导出并通过一致性检查。prototypes/README.md 标记四份原型均可作为实现依据。提交 80434ec。
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
基本信息
依赖与并行
子项目影响
原始需求
SYBERP货运单包含1个或多个虾皮商品明细；同一虾皮商品可有多条不同颜色、尺码记录，每条数量为1到N。每条来源商品具有唯一ID，并包含虾皮订单号、商品ID、店铺、目标颜色、尺码、数量和原始数据。
做什么
details[].productId）、店铺、标题（details[].productTitle，不可用订单级productName）、目标颜色与目标尺码（均从details[].productSpec自由文本解析）、数量（productQty）与成交单价（productPrice）。amtOrder在/am/stock/list为 61200、在/am/stock/detail/listByStock为 612.0（相差 100 倍），而同一对象的escrowAmount两边一致，不可共用同一套金额转换。code+details[].id」；实测sku与variationSku均为空字符串，不可作为唯一键或规格标识。details[].productThumb拼接https://www.shunyunbaoerp.com/api/p/file?id=<productThumb>，与 #40 已实测规则一致。purchaseStatus/purchaseCode/purchaseLink/pruchaseId，来源侧拼写如此）仅保留在原始 JSON，不进结构化字段。不做什么
Stage A：QuantUX 原型（当前唯一实施范围）
说明：#32 原型只覆盖采购流程视角的SYB采购明细列表与详情，不替代本工单的独立 SYB 数据域管理页原型。
使用 QuantUX MCP 创建 SYB 货运单商品管理端原型，至少覆盖：
syb_products表本身不保存任何采购字段。原型审核门禁
6a83d7b4191a826306a7eebd）Stage B：代码实现
仅在原型明确验收后开始，交付内容见上文「做什么」。
Stage B 代码验收标准
风险和回退
外部字段可能变化；解析器需要兼容缺失字段并保留原始JSON。外部接口凭据和生产数据不得写入仓库、日志或工单。
Stage A 原型已完成，待用户审核
原型
6a83d7b4191a826306a7eebdprototypes/quantux-syb-import-6a83d7b4191a826306a7eebd.html（无外链请求，参考图以 data URI 内嵌）页面清单与 Stage A 覆盖点对应
覆盖点 6（同一货运单内同一虾皮商品的多组颜色尺码为独立明细）在列表第 1、3、4 行体现并有图例说明；覆盖点 7（不出现采购任务、订单、物流字段）在列表、详情、结果、关联四页写明边界。
基于
demo/shunyunbaoerp_stock_list.har实测数据的设计依据导入链路已确认为两步：
POST /am/stock/list，用queries: [{colName:"created", dvalue:"2026-08-06,2026-08-09", op:0, type:3}]按创建日期区间分页拉货运单；POST /am/stock/detail/listByStock?hist=0，body{"ids":[75104587]}批量取明细行。原型的导入弹窗即按此设计（日期区间 + 店铺 + 预检），不是臆造的交互。
实测发现的三个必须写进解析规则的坑
productSpec是颜色尺码合并的自由文本，且含括号备注："白色,L【建議50-60公斤】""黑色+白色【純棉兩件裝】 簡約親膚,L【建議52.5-60公斤】"规则定为「按最后一个逗号切分 → 剥离【】备注 → 与虾皮商品规格值比对」，三步在详情页逐步展示。比对不上时标记存疑而非自动新增规格值。空字符串或无分隔符（如
"均碼"）标记失败/存疑，绝不猜测。amtOrder在两个接口单位不一致：/am/stock/list返回61200，/am/stock/detail/listByStock返回612.0，相差 100 倍；而同一对象的escrowAmount两边都是505，不存在这个倍率。解析器必须按接口分别定义单位，不能共用一套金额转换。sku与variationSku实测均为空字符串，不能作为明细唯一键或规格标识；来源明细唯一键用details[].id（如 145306175），配合货运单code组成「货运单号 + 来源明细ID」。其他实测确认
details[].productId（如 50209124255）；标题productTitle；数量productQty；单价productPrice。productThumb是 ID，需拼https://www.shunyunbaoerp.com/api/p/file?id=<productThumb>，与 #40 已实测的图片地址规则一致。productName只取了其中一条明细的名称（订单有 2 条明细却只显示「純棉上衣」），不可作为明细商品名使用，必须用details[].productTitle。purchaseStatus/purchaseCode/purchaseLink/pruchaseId（来源侧拼写如此）仅保留在原始 JSON，不进结构化字段、不驱动本系统采购动作。receiver/receiverTel/receiverAddr来源侧已脱敏为****，本系统不保存明文。待确认的假设（原型按此表达，审核时请确认或推翻）
验证：
quantux_verify_export→verdict=PASS，widgetCount 140、wiredCount 9、navigation=true、runtimeErrors=0、无不支持控件；几何检查 0 越界。未验证部分：无浏览器环境，未做人工视觉走查；观感以用户审核为准。
相关提交：
7f6bee3docs(#41): add stage A syb import prototype门禁：明确回复「原型通过」前不修改数据库迁移、Go 服务端、Vue 页面和共享 API。
四项假设的确认结果与假设 4 的修正
用户回复：1、2、3 赞同；4 提出质疑——「虾皮数据不齐全不影响采购吧」。该质疑成立，原假设措辞过宽，已修正。
假设 1 / 2 / 3 —— 确认采纳
假设 4 —— 修正
原表述：「存疑明细在人工确认前不参与采购域读取」。这个说法有两处错误：
错误一：把「数据不齐全」和「不能采购」划了等号。 实际只有三项缺失会阻断采购：
details[].productId）—— 缺失则无法关联档案；productQty）—— 缺失则不知道采购数量。标题、参考图、售价、店铺缺失不影响采购。「存疑」同样不等于不可采购：人工修正颜色后映射即可命中，该明细照常可采购。
错误二：把判断权放在了 SYB 域。 与本工单已确认的原则冲突——「SYB 负责忠实保存和解析外部需求，不负责采购执行」。
修正后的规则：SYB 域不设置「可否采购」开关，只如实标记解析状态与结构化字段。采购域（#33 / #34 / #35）在创建采购任务时自行校验上述三要素，缺失则拒绝创建并在采购侧给出原因。
采购发起入口的归属（已在既有工单中确定，本次确认一致）
#35正文：「前置工单：#33 共享契约、#41 提供 SYB 明细入口」「从已有 SYB 商品详情进入采购任务创建确认，不重新实现 SYB 列表和详情」。#33正文：「purchase_tasks.syb_product_id允许演练阶段为空；正式采购必须引用 SYB 明细」。#32已验收原型：「采购任务统一从 SYB 商品列表多选后批量创建」。三处一致，结论：采购在 SYB 明细列表/详情发起，但创建能力属于采购域。理由是采购由订单驱动而非商品驱动——「买几件、什么颜色尺码」只存在于 SYB 明细行上，虾皮商品档案里没有这些信息，从档案发起凑不齐参数。
对 #41 的约束：本工单不实现任何采购入口，只预留位置，由 #35 注入。代码归属保持清晰，采购代码不进入 SYB 模块。
原型对应修改
验证：
quantux_verify_export→verdict=PASS，widgetCount 142、navigation=true、runtimeErrors=0；几何检查 0 越界。门禁不变：明确回复「原型通过」前不修改数据库迁移、Go 服务端、Vue 页面和共享 API。
原型第 2 版：按 #46 决策变更修订，待首次验收
趁本工单尚未验收，先移除已被 #46 动摇的表述，避免带过时内容走验收。
修订过程中厘清的一个关键点
AI 匹配的路径是 SYB 原始颜色尺码 → PDD 实际规格，绕过了
shopee_products的映射表。这意味着「存疑」的影响比原先设想的小得多：存疑的成因是「拆出的颜色与虾皮档案中的规格值对不上」，但 AI 匹配根本不读虾皮档案的规格值，而是直接拿 SYB 的原始文本去匹配 PDD 当前实际规格。因此：
这条区分此前是模糊的，现已在原型四处写明。
修订的文案
新增内容
解析错误清单页新增「与采购的关系」说明卡，明确区分两类：
该页高度 940 → 800（重排后内容更紧凑），返回按钮下移。
规模与验证
quantux_verify_export→verdict=PASS，wiredCount 9、navigation=true、runtimeErrors=0、无不支持控件3d72af9docs(#41): revise prototype for AI matching per #46待验收
四项假设已在 此前评论 中确认（1、2、3 采纳，4 已按用户质疑修正）。本次修订后原型内容与 #46 一致，请审核并明确回复「原型通过」。
线上：http://124.222.27.183:8082/#/apps/6a83d7b4191a826306a7eebd.html
原型第 3 版：列表列调整与多行勾选
四项修改（均已实现）
details[].id，属内部标识，采购员不需要。改为只在明细详情页保留，并标注用途「仅用于幂等导入与 SYB 回填定位，不在列表展示」。列表图例同步说明。新列序：勾选 / 参考图 / 货运单号 / 虾皮商品ID / 商品标题 / 店铺 / 目标颜色尺码 / 数量 / 售价 / 虾皮关联 / 解析状态。
关于「勾选后发起采购任务」
是的，且这是既定设计，本次修改与之一致：
#32（已验收）原型：「采购任务统一从 SYB 商品列表多选后批量创建」「逐条校验和批量创建结果」；#35正文：「前置工单 #41 提供 SYB 明细入口」「从已有 SYB 商品详情进入采购任务创建确认」。一条明细 = 一个独立采购任务。依据
#32已确认规则「一个采购任务只采购一个明确规格；数量 1 到 N 均放在同一个 PDD 订单，不自动拆单」——勾选 N 条即批量创建 N 个彼此独立的任务与 PDD 订单，不合并。不合并也是地址后缀_cg{task.id}机制成立的前提：合并会使后缀无法一一对应订单。该规则已写入列表图例。实现层面需要注意的三点
① 勾选禁用需要采购状态，但
syb_products不存采购字段。#32规则：「已成功采购的syb_product默认不能再次创建采购任务」，需二次确认才能「允许重新采购一次」。要正确禁用勾选，列表必须知道采购状态。而#41明确「不创建 purchase_tasks，不保存 PDD 订单号、快递单号、支付、有效订单或回填状态」。二者不冲突：表不存 ≠ 页面不显示。采购状态由采购域（
#35）经关联查询提供，syb_products表本身不新增任何采购字段。#41阶段该列不存在，#35实施时注入。已在图例中写明，避免实施时两边打架。② 本工单阶段勾选不能是死控件。
若勾选只为采购准备，
#41单独交付时它将无任何用途。因此列表新增「批量重新解析」——这是#41自身的批量能力（按选中项对原始 JSON 重跑解析规则）。采购入口位置以说明文字预留，标注由#35注入。③ 解析失败行禁用勾选。
失败行取不到目标颜色尺码，AI 无从匹配，创建采购任务必然失败。原型中该行勾选框呈禁用态。存疑行可勾选——按 #46，存疑不阻断采购。
全选行为沿用
#32原型规则：表头全选只勾选当前页。规模与验证
quantux_verify_export→verdict=PASS，wiredCount 15、navigation=true、runtimeErrors=0、无不支持控件5e2d460遗留待验证
details[].id是否全局唯一仍未验证——现有 HAR 只抓到一张货运单的两条明细（145306175 / 145306176），样本不足。唯一键当前保守取「货运单号 + 来源明细ID」组合，即使 ID 仅单内唯一也安全。若需改为全局唯一键，需抓取多张货运单的detail/listByStock响应验证 ID 是否跨单连续且不重复。线上：http://124.222.27.183:8082/#/apps/6a83d7b4191a826306a7eebd.html
搜索框改为支持多行批量查询
采用直接把原输入框改为多行文本域的方案，取代此前提议的「批量」按钮 + 弹窗。原方案是为了不占版面，但自适应高度能同时解决版面与交互层级两个问题，多一次点击没有必要。
交互定义
sys_config。第四、五点是批量查询最容易遗漏的部分：粘 50 个单号只出 47 条时，用户必须能知道缺的是哪 3 个，否则无法判断是没导入还是打错了。同时明确筛选器与批量搜索取交集且继续生效，避免「明明粘了 50 个怎么只出来 3 条」的困惑。
两个页面搜索内容不同
syb_products，会破坏 #40 已确认的「商品域独立于采购任务和 SYB 数据」该限制已写入 #40 列表页说明文字，避免实施时被误加。
规模与验证
verdict=PASSverdict=PASSTextArea属导出器完整支持类型25b160c两份原型仍待验收。
T39 SYB 货运单商品导入与 Shopee 信息提取to T39 SYB 货运单商品导入与 虾皮 信息提取T39 SYB 货运单商品导入与 虾皮 信息提取to T39 SYB 货运单商品导入与虾皮信息提取术语统一：货运宝 → SYB
用户确认将展示术语统一为「SYB」。本工单标题与正文已同步，#32 已关闭工单保持归档原样不动。
修改范围
T39 SYB 货运单商品导入与 Shopee 信息提取→T39 SYB 货运单商品导入与虾皮信息提取货运宝6 处 →SYB；Shopee10 处 →虾皮Delivery-IssuesT39 行同步未受影响（已校验）
货运单8 处完整保留 —— 与系统名 SYB 是两个概念：SYB 是外部 ERP 系统，货运单是其中的一张单据（code，如 260728TB95MJTQ）shopee_products/shopee_item_id等程序标识符保持不变顺带解决的既有歧义：同一系统此前在文档中有「货运宝」「顺云宝」「SYB」三种叫法，而实测域名为 shunyunbaoerp.com，SYB 正是 ShunYunBao 的缩写。Wiki 术语表已拆为两条，明确「管理端界面一律用 SYB，不再使用货运宝/顺云宝等别名」，并单列「货运单」条目区分二者。
原型侧同步完成（提交
953ce55）：两份原型共 21 处文案、14 处控件名、2 个屏幕名及应用名已改；导航栏「货运宝商品」→「SYB商品」，页面标题「货运宝商品明细」→「SYB商品列表」。货运宝残留 0，货运单17 处保留完好，两份原型verdict=PASS。按钮重命名与「清空搜索 / 重置」冲突消解
1. 批量按钮重命名（#41）
批量重新解析 (2)→重新解析 (2)批量创建采购任务 (2)→创建采购 (2)计数已在标签内，「批量」二字冗余；缩短后第一排更紧凑。
2. 「清空搜索」与「重置」确实冲突，已消解
冲突性质：
重置清空全部查询条件（搜索框 + 所有筛选器），清空搜索只清搜索框——后者是前者的子集。两个按钮一个包含另一个，用户需停下判断该点哪个。位置问题更明显：
清空搜索此前被放在命中统计条最右端（x=1290），距搜索框极远。清除搜索的控件不挨着搜索框，交互上本身就不成立。改法：
两份原型同步处理（#40 的搜索框同样内置 ✕）。
验证
verdict=PASS、越界 0verdict=PASS、越界 0231a604Stage A 原型验收通过
用户 2026-08-19 明确回复「验收通过 SYB 商品和虾皮商品两个模块原型」。两个工单的 Stage A 门禁均已解除，Stage B 代码实施可以开始。
工单保持 open：本次通过的是 Stage A 原型门禁，非整单验收。Stage B（迁移、服务端、Admin 页面、测试与文档）尚未开始。
已确认的原型
6a83b708191a826306a7eeb1verdict=PASS，越界 06a83d7b4191a826306a7eebdverdict=PASS，越界 0离线导出均为零外链单文件，位于
prototypes/。本次验收覆盖的关键设计
shopee_*/syb_*。人工/精确匹配/AI 建议，均需人工确认；一键确认仅对精确匹配生效，AI 建议须逐条确认；附「名称相同不代表实物尺寸相同」警示。shopee_item_id唯一约束需与软删除并存。遗留项（Stage B 实施时处理，不阻塞本次验收）
details[].id全局唯一性未验证：现有 HAR 仅含一张货运单的两条明细，样本不足。唯一键当前保守取「货运单号 + 来源明细ID」组合，安全但索引偏宽。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 阶段进度
三工单边界核对结果（#35 / #41 / #44）
用户 2026-08-19 要求核对 #35、#41、#44 的边界。核对发现四个问题，均已修复。
职责划分（收敛后）
问题一：#41 原型的归属标注错误（已修复）
#41 Stage A 原型第 9、10 屏及列表页的采购入口说明，此前标注「本页由 #35 实现」。经核对 #44 正文——「SYB 商品列表左侧勾选后批量创建」「表头全选只选择当前页」「不可创建行禁用并显示原因」「每条分别创建一个任务，禁止合并」「批量结果逐条显示」——与该原型逐条对应，归属应为 #44。
已更正 3 处标注，导出文件中「由 #35 实现」残留 0 处，
verdict=PASS。提交1cd32a4。问题二：#35 与 #44 都声称拥有创建确认页（已收敛）
_cg{task.id}提示」按能力而非入口切分：创建是一个完整能力，拆到两个工单会导致确认页被实现两遍或互相等待。创建能力整体归 #44，#35 收敛为管理已有任务。两张工单正文均已更新并注明移交关系。
问题三：#44 状态过期（已更新）
原写「阶段：待实施；受 #32 原型审核门禁阻塞」。实际 #32 已于 2026-08-18 验收，#40、#41 原型已于 2026-08-19 验收，三个前置门禁全部解除，#44 现为可实施状态。
问题四：本单阶段二第 7 项记错对象（已修正）
「#35 原型缺口」应拆为两部分：创建流程已由 #41 原型覆盖且归属 #44，无需另建原型；任务详情展示
spec_source、AI 匹配快照与两趟 attempt 历史的部分才归 #35，实施前需评估。正文第 7 项已改写。??? 2026-08-20 ???????????:Task-41-SYB-product-import;Wiki revision:a627417c412e44fbc6b0816f15395e131760522f??????