Files
order_site/docs/抖音-码速达/11-接单模板待补清单.md
T
yml2213 10464fea89 refactor(product-match): 抽离接单模板匹配引擎(来源适配器/引擎/价格收口 + 后台按订单项试匹配)
新增 services/product-match:来源适配器(kuaishou-91 合成 91+快手 / pdd / douyin-mashida)+ 平台无关匹配上下文 + 条件打分引擎(并列最高=ambiguous 不猜、逐维诊断)+ 价格数量拼单唯一实现。

- 商店键命名空间化(kuaishou:/pdd:/douyin:),店铺为可选作用域:留空即可按订单信息匹配
- 抖音匹配文本只取内部 SKU,引流标题只进 promoTitle,itemTitle 恒空(修复 0.85 元误命中碎梦浮光珍宝礼盒、拼单未开)
- work-product-match-mappers 改为门面(签名不变),work-order-pricing 改为转发
- 新增后台「按订单项试匹配」接口与面板:走发单同一套链路,返回模板/数量/单价/总额/拼单
- 生产样本回放:91/PDD 6000 条决策 0 差异;抖音 5 条全为修正

设计见 docs/接单模板匹配引擎重构设计.md
2026-10-14 15:58:21 +08:00

6.7 KiB
Raw Blame History

抖音码速达 · 接单模板待补清单(运营动作)

状态:待运营执行(2026-10-14) 数据来源:生产库只读实测(接单模板 662 条 + 抖音单 11 笔) 前置阅读:10-三层分流设计.md(为什么要走接单平台、代码要改什么)


一、先记住三条匹配口径(决定模板怎么填)

  1. 抖音单没有「卖家ID(sellerId)」上下文 → 「适用商品绑定」(work_product_rule_mappings,数据库强制要求填店铺 ID)对抖音完全无效。抖音只能靠模板自身的「商品名 / SKU编码」匹配。
  2. 未命中皮肤映射的抖音商品,SKU编码(item.sku_code) = 内部 SKU(如「套装-牛仔情诗」),而「商品名(item.sku_name)」是引流长标题(如「和平精英皮肤小店入口返场集市新皮肤出售牛仔情诗」)。 → 模板必须按「SKU编码 = 内部SKU」+ 匹配方式「精确」来配,不要依赖商品名包含匹配。
  3. 模板「平台」留空 = 适用所有平台(含抖音);一旦填了 kuaishou,当前代码下抖音命不中(matchesRuleProviderPlatform 只对 PDD 做了跨平台豁免)。在代码放行前,抖音的模板请务必把「平台」留空。

已实测:全库 662 条模板 provider 全部留空、shop_id 全部留空,但 platform 有 354 条锁死 kuaishou、308 条留空。


二、需要运营补的模板(当前生产库抖音 11 笔的结论)

落库 SKU编码 商品(引流标题略) 笔数 现状 运营待办
lucky_coin_x2 幸运币2个 3 皮肤自动发货 ✅ 无需模板(且以后不要给它建模板,否则会重复交付)
suit_romantic_destiny 套装-浪漫天命 2 皮肤自动发货 ✅ 无需模板
套装-牛仔情诗 和平精英…牛仔情诗 2 人工 新建模板(SKU编码=套装-牛仔情诗)
套装-狂战萌兔 和平精英…狂战萌兔 2 人工 新建模板(SKU编码=套装-狂战萌兔)
浪漫天命 和平精英…浪漫天命 1 人工 先确认商品口径:该商品与 套装-浪漫天命 是否为同一款?若是,应修抖音商品 SKU 命名/补映射,而不是建模板
突击兵密钥5个 和平精英指挥官密钥…突击兵密钥… 1 人工 已有模板 id=21「突击兵」(platform=kuaishou,contains);在代码放行跨平台前,可复制一条「平台留空」的模板(SKU编码=突击兵密钥5个,精确)

本清单只覆盖已经产生过订单的抖音商品。抖音在售商品全集需要在放行前拉全(平台侧商品列表接口未接入,建议用后台导一次商品 SKU),按同样口径批量建模板。


三、新建模板的建议字段

以「套装-牛仔情诗」为例(其余同理):

字段 建议值 说明
模板名称 抖音-套装-牛仔情诗 便于和快手商品区分
所属分类 按游戏/玩法归类(可空) 只影响报表归类
计价方式 固定金额 与现有模板一致
接单金额 由运营按成本定 全库现有模板集中在 ¥55~¥398 区间,仅供参考
验收模式 标准验收 与快手模板保持一致
来源(provider) 留空 留空即通配
平台(platform) 留空 填 kuaishou 会导致抖音命不中(放行代码前)
SKU编码(sku_code) 套装-牛仔情诗(抖音内部SKU,原样复制) 唯一可靠的匹配键
商品名(product_name) 同 SKU编码(或留空) 不要填引流长标题
匹配方式(match_type) 精确(exact) 避免短名 contains 误命中
启用模板 开 —
自动建单 开 不开则只匹配、不建单
启用拼单 关(除非业务需要) 与现有模板一致
任务时限 / 超时策略 按现有同类模板 —
资料字段(requirement) 需单独确认 现有模板是快手/PDD 口径(如 gameId:游戏编号),抖音商品要交什么素材需产品确认

四、后台操作路径

接单平台 → 接单模板 → 「+ 新建模板」

  1. 填「模板名称 / 所属分类 / 接单金额」;
  2. 「来源」留空、「平台」留空;
  3. 「SKU编码」填抖音内部 SKU(可在「订单详情 → 商品」或 order_items.sku_code 里取);
  4. 「匹配方式」选精确;
  5. 「启用模板」「自动建单」打开;
  6. 保存后在匹配诊断页查看是否命中(该页会显示 rule_not_matched 等未命中原因)。

⚠️ 「适用商品绑定」那一栏对抖音不要填(填了也没用,抖音无 sellerId)。


五、验证(只读 SQL,放行后逐条核对)

-- 1) 某个内部 SKU 会被哪些模板命中(把 :sku 换掉)
SELECT id, platform, product_name, match_type, auto_create
FROM work_product_rules
WHERE enabled AND (
  (match_type = 'exact' AND :sku = product_name) OR
  (match_type <> 'exact' AND (:sku = product_name OR :sku LIKE '%' || product_name || '%' OR product_name LIKE '%' || :sku || '%'))
);

-- 2) 抖音单是否已经建出工单
SELECT w.work_order_no, w.status, w.product_name, o.platform_order_id
FROM work_orders w JOIN orders o ON o.id = w.order_id
WHERE o.provider = 'douyin_mashida'
ORDER BY w.id DESC LIMIT 20;

-- 3) 抖音单匹配结论(应逐步由 unmatched 变为 matched)
SELECT l.match_status, count(*)
FROM work_product_match_logs l JOIN orders o ON o.id = l.order_id
WHERE o.provider = 'douyin_mashida'
GROUP BY 1;

-- 4) 防重复交付自查:同订单项既有 affiliate_dash 任务又有工单(结果应为 0)
SELECT count(*)
FROM work_orders w
JOIN fulfillment_tasks ft ON ft.order_id = w.order_id AND ft.executor_key = 'affiliate_dash'
JOIN orders o ON o.id = w.order_id
WHERE o.provider = 'douyin_mashida';

匹配诊断页(接单平台 → 匹配诊断)比 SQL 更直观,可直接看单笔订单项的未命中原因。


六、红线

  1. 已自动发货的商品不要建模板(如 幸运币2个、套装-浪漫天命、lucky_coin_x2 系列)——否则同一单会既派打手又自动发货。
  2. 模板「平台」在代码放行前必须留空。
  3. 匹配键用 SKU编码(内部SKU)+ 精确,不要用引流长标题做 contains。
  4. 抖音「浪漫天命 / 套装-浪漫天命」这类同一商品两种写法,先统一命名口径,再决定是补映射还是建模板。
  5. 存量 11 笔(尤其 6 笔人工单)建议人工处理不回溯,新规则只对新单生效。