① ⚡ 一句话总结：想把海外仓、收款公司、电商平台和网红放进同一张表，第一步不是找字段，而是先把「一个点」定清楚——它其实是「签约公司 + 可卖的那项服务 + 具体地址/管辖区」三样东西拼出来的一个联合身份；切错一次，后面填得再漂亮也全是假值。

② 🔍 本期最深发现：真正卡住字段设计的不是「字段太多」，而是没分清「标签」和「货」。抓取时间、来源链接、保鲜期这些是每个字段的标签，如果它们也算进 15 格上限，一个带证据链的字段会一次吃掉 5 格（15 格里只剩 10 格装四类差异，装不下）。国际公交数据标准 GTFS 把这类说明单独放在一个「主键 = 无」的文件里，正是同一个判断——标签不是货。

③ 变现闭环卡片（本期）：钱不从「表」本身来，从这张表替你省掉的三件事来——①选谁（责任主体清楚，出事有人赔）②算清（不同报价单能对齐比较，省掉人工拆单）③什么时候不能碰（黑名单仓/无牌通道提前排除）。正向字段谁都能抄，负向字段（不接什么、出过什么事）+ 保鲜机制才是护城河；对大课题的启示 = OMW 的差异化不在「收录多少家」，在「敢写不敢写的那些列」以及「过期了会不会自己坦白」。

核心知识点（20 条 · 按「先结构后保鲜」排列）

1. 三层粒度 = org / offering / geo：org 是签约与赔付的责任主体，offering 是能单独报价下单的那项服务，geo 是具体地址或监管辖区。三条拆分判据（任一成立就必须拆）：①赔付主体/适用法律/税务口径会不会不同（不同→拆 org）②能不能独立下单、独立报价、独立签约（能→拆 offering）③有没有不同地址/服务半径/辖区（有→拆 geo）。合并只有一个闸门：同一法律主体 + 同一价目表 + 同一辖区，三条同时成立——实务里最常破的是第一条，因为品牌名相同 ≠ 法律主体相同。

   • 人话：查一家连锁店，品牌是 org（谁签合同、谁赔钱）、套餐是 offering（你买的哪一份）、门店是 geo（你去哪家吃）。把品牌当门店，你会以为全国只有一家店。

2. 四类各一个切分实例：海外仓 = 美国 LLC × 前置仓标准件按托盘月租 × 洛杉矶仓；支付 = 香港持牌主体 × 跨境收款美元 × HK 辖区；平台 = 同一运营法人 × 北美站月租 × US/CA/MX 三个站点（一个 offering 三个 geo，不是三个 org）；红人 = 人（或 MCN 法人）= org，账号 = offering，受众地域 = geo（一个人在 3 个平台有号 = 1 org + 3 offering）。

   • 人话：同一家支付集团在新加坡拿一张牌、在香港拿一张牌，是两家公司（两个 org）——因为牌照不能跨主体借用；合并后「牌照类型」这一格只能填一个值，填谁都是错的。

3. 切错一次的三种污染（带量级）：①该拆未拆 → 责任漂移：把两个法人合成一个 org，赔付/法律/税务必错，牌照字段变假值，而且不报错（静默错误）②该并未并 → 计数虚高：把某服务商 12 个仓各打 1 个点，一个服务商就吃掉「约 20 点位」预算的 60%，四类对照表退化成仓列表 ③层级错位 → 可比性崩塌：把平台站点当 org，费率表复制到每个站点 → 同一能力计两次，且费率更新要改 N 行，漏改就留一条过期的假值、还没人知道哪行漏了。

   • 人话：粒度先于字段（承上一夜「分母先于数字」）——切错单元，字段全废，而且废得没有报错。

4. 主键怎么定：org 用 iso6523Code（一串国际通用的组织编码，前 4 位是「编码体系代号」：lei=0199、duns=0060、gln=0088），格式 XXXX:YYYYYY:ZZZ；禁止用品牌名做主键。offering 用「org + 服务类型 + 计价单位」的复合键；geo 用结构化地址（国家+省州+城市+邮编）或坐标，层级用自引用（parent_geo_id）而不是另建三张表。

   • 人话：品牌名会重名、会改名、一个牌子底下好几家公司；国际编码才是身份证号。schema.org 官方也提示：ISO 标识符比税号（vatID/taxID）歧义更少。

5. 字段预算 7 + 8 ≤ 15：核心层 7 个字段四类共用——category（类别路由）、org_ref（主体）、offering_name（供给名）、geo_ref（点位/辖区）、settlement_unit（结算单位）、liability_summary（责任摘要）、status（状态）；类目层每类 ≤8 个，四类不叠加（一个点位只属于一类）。合计 ≤15，正好卡住 OMW「每点位 8-15 字段」的上限。

   • 人话：行李箱 15 公斤。7 件是所有人都要带的内衣（四类共用），剩下 8 公斤按你去哪（哪一类）自己装。

6. settlement_unit 必须是结构体，不能是一个下拉选项：定义为 {unit, currency, basis} —— 单位、币种、按什么计。因为四类计价语义根本不同（仓按体积·时间、支付按交易额百分比、平台按类目佣金、红人按条/按授权期），压成一个枚举会产生「伪可比」（看着能比，其实不能）。basis 就是后面「禁止换算」规则的锚点。

   • 人话：拿「每立方米仓储费」和「交易额的 2.9%」比大小，等于拿体重比体温——数字都有，单位不对。

7. meta 包装 14 项不计入预算：src（来源等级）、asof（截至日）、ttl（保鲜期）、evidence_url（证据链接）、snapshot_at（快照时间）、content_hash、computed、formula、scenarios、inputs、unit、confidence、verified_by、verified_at。判据：这些是字段的属性（field-level metadata），不是点位的属性（record-level attributes）。标准佐证：GTFS 的 feed_info.txt 官方标注 Primary key = none，作用是描述「the dataset itself, rather than the services that the dataset describes」（数据集自身，而非它描述的服务）。若计入的后果：一个带证据链的字段瞬间吃掉 5 个预算位（src/asof/ttl/evidence_url/snapshot_at），15 位装不下四类差异，唯一出路是砍字段——而砍掉的往往正是决策锚点。

   • 人话：衣服上的吊牌不算行李重量；要是吊牌也过秤，一件大衣的吊牌就占 5 公斤，你什么都带不了。

8. 把预算变成机器能拦的规矩：JSON Schema 里写 required 7 项 + attrs.maxProperties: 8 → 超预算的记录在入库时就被拦下，不再靠人肉 review。另：$schema 必须在根级，且不会传递给 $ref 引用的外部文件——四类拆成四个文件时，每个文件都要自带 $schema。

   • 人话：不是写一张「请大家不要超过 15 个字段」的告示，而是把称重器装进行李口。

9. 四类 attrs 各 8 个（本夜从 91 行候选收敛）：海外仓——服务类型、温层、适用平台辖区、仓储计费口径、费用分项、最低月消费/最低承诺、容量状态、不收货类目（负向字段）；支付——牌照包（辖区/类型/发牌机关/号/状态/登记库更新日）、通道类型、定价模型、费用分项、结算与争议条款、账户国+结算币种（必须成对）、禁入行业、登记库引用；平台——站点（不是品牌）、履约模式、捆包原子性、佣金结构（区间+基数+最低值+分段）、月费/刊登费、入驻与类目准入、税务方案、可见性字段 vs 成交资格字段；红人——账号、受众、内容画像（品类双值）、互动与异常、报价卡、授权包（含 AI 训练权）、披露状态、个人信息边界。

   • 人话：每类只留「会改变决定」的 8 个，描述性的全砍。被砍的不是不重要，是进「待补池」等有真实数据再决定要不要占名额。

10. 几条一填就错的坑（官方页里写着，但极易填反）：①Amazon 佣金基数 = total price，官方明确含运费与礼品包装（用商品标价估会系统性低估）；佣金跨类目 5%-45%，多数类目最低 $0.30（$1 的商品按 8% 算应 $0.08，实际收 $0.30 = 30%）；Professional 月费 $39.99、Individual $0.99/件 ②Walmart 佣金 6%-15%，官方「无月费」——「无月费」≠「$0」（Amazon Individual 的 $0 是「按件计费」的意思，两者禁同填 0）③Amazon 官方明确入驻不需要 LLC 或注册公司，且「公司注册号」≠「EIN 税号」④FBA 的 150cm / 30kg / 围长 3m / 保质期 18 个月上限是新加坡站口径，不带辖区字段就会被当成全球通用 ⑤TikTok Shop 基础佣金费率官方未披露（只有 "No setup fees" 和最高 4% 的 LIVE 折扣）→ 字段填 unknown，禁写 0（把「没找到」写成 0 就是编造）。

    • 人话：「没找到」和「是零」是两件事。资源表里最危险的假值不是错数字，是把空白填成 0。

11. 捆包与去重：原子性是「模式的函数」，不是平台的固有属性：全托管（平台是收款责任人）时「流量+履约+结算」捆成一包 → 记为 1 个资源点（indivisible）；平台代履约但商家仍是卖方（Amazon FBA / Walmart WFS，履约可选、定价归商家、结算归商家）→ partially_separable，履约可独立计数；纯自履约 → separable。但去重的代价是摧毁风险归因（平台流量正常、履约崩了，合并成一行后这个差异在表里消失）→ 本夜裁定：不做硬合并，改用 same_principal（同主体标记）+ bundle_risk_note 备注，让使用者自己决定合不合。

    • 人话：把三张账单合并成一页确实清爽，但「哪一项在漏水」也同时看不见了。所以给标记，不给剪刀。

12. 负向字段 = 护城河，也是最大的法律雷区：三组——exclusions（主体自己说不接什么）、red_flags（风险信号）、exit_terms（退出条款）。规则一句话：只存可核事实 + 来源 + 时间，禁存评价（✅「官网条款 §7 载明不承运锂电池」+ 快照；❌「这家很坑」）。三档：可存（主体自行公开的经营性事实，依 PIPL 第 13 条「已合法公开」；且法人信息不受个人信息规则约束，但仍受名誉权约束）/ 需授权（红人联系方式、粉丝画像、报价合同；PIPL 第 17 条须告知保存期限、第 27 条「个人明确拒绝的除外」、第 38 条跨境三路径；GDPR 第 14 条须一个月内告知来源与删除权）/ 禁存（敏感个人信息、推断性负面结论「疑似刷量」、「匿名爆料」、已删除主体的残留）。两条宽松假设被证伪：GDPR「合法利益」是平衡测试、不是当然许可；「不成比例的努力」豁免不适用于 20 点位规模（这么小的量，逐个通知完全做得到）。入库守卫：red_flag 必须四项齐全（来源链接 + 快照哈希 + 复核人 + 复核时间）才允许写入——这把民法典的「合理核实义务」变成了代码。

    • 人话：正向字段是「这家能做什么」（谁都能抄），负向字段是「这家不能做什么、出过什么事」（要证据、要担责）。证据链不全的坏话，一个字都不能写——写了就是你自己侵权。另：民法典 1024/1025/1026 三条本夜未取到官方原文页（返回 302/404），只作定性依据，不逐字引用。

13. 保鲜：TTL 四档 + 三态，档位 = f(错误代价, 变化速度)：T1 自动刷新 ≤30 天（价格/费率/汇率/佣金率/库存与容量状态；信号源 = 官方费率页的 ETag/Last-Modified 响应头 + 正文 diff；schema.org 的 priceValidUntil 就是标准内置的有效期字段）；T2 区间 + 过期标记 90-180 天（服务范围/时效/覆盖区域/分项费结构；信号源 = 官网服务页、站点选择器页、sitemap lastmod、页面 dcterms:modified；标准范式 = GTFS 的 feed_start_date/feed_end_date 可信窗口 + 窗口外标 non-authoritative「非权威」）；T3 人工复核 365 天（责任结构/赔付条款/牌照类型；信号源 = 牌照库公开检索页、监管公告与处罚页、官方条款版本页；季度复核并记录复核人）；T4 事件驱动下线，无固定 TTL（主体注销/牌照吊销/破产/被制裁；信号源 = 注册处状态变更、执法公告、制裁名单）——一句话记法：T4 优先于 TTL，资质失效不等日历。三态：stale（值可能旧，但主体与事实没被推翻 → 可见 + 标 asof 与「过期」徽标）/ hidden（条目有效但暂不参与推荐排序，策略问题）/ delisted（事实被推翻或资格失效，从主视图移除但保留墓碑记录）。

    • 人话：牛奶（价格）三天一换，罐头（服务范围）三个月，合同（责任结构）一年看一次但一定要看；而「这家是不是已经倒闭了」（资质）不看保质期，听到消息当天就下架。判断「该藏还是该下架」只问一句：「这条如果是真的，我们愿不愿意展示它？」 愿意但暂不展示 = 藏（策略）；不愿/不能展示 = 下架（事实）。

14. 最关键的一条：资质必须「下线」，价格只需「标过期」。资质是布尔事实（有牌/无牌），没有「大概有牌」的中间态——stale（可能旧）表达不了「当前无牌」，错标一个无牌机构为持牌是直接的合规与资金风险，宁可误下线，不可误保留。价格没有「资格真伪」问题，且历史价格对趋势有价值 → 只标 stale + 保留 asof。边界：价格字段的来源页整体失效（404/域名过期）→ 升级为 delisted，因为已无法回溯来源。墓碑必带四字段：status: delisted + delisted_at + delist_reason + evidence_url。

    • 人话：资质是开关（没有「大概有牌」），价格是温度计（旧了还能看趋势）——所以一个必须拔掉，一个只需贴个日期。下架也不能悄悄删，要留一张「某日下架、因为什么」的条子。

15. 改状态不要原地改，要「加一条例外」：GTFS 的 calendar_dates.txt 是成熟范式——主键 (service_id, date)，exception_type 里 1 = 新增服务、2 = 取消服务，官方明确它modifies（修改）主表的默认值。同构到资源表：status 是默认态，另设 status_override + override_reason + override_at。直接 UPDATE 会抹掉审计轨迹，「为什么这个点位被下线」就永远查不回来了。

    • 人话：像排班表——正常班表不动，某人请假单独记一条；直接把班表改了，就再也说不清那天为什么没人。

16. 派生值取「木桶短板」：computed 字段的四条边界——C1 禁覆盖原值；C2 必带公式 formula + 假设 scenarios + 输入 inputs；C3 不得作为默认排序依据（防伪精确）；C4 ttl(computed) = min(ttl(input_i))。例：「单件到岸成本」= 采购价（180 天）+ 头程费（90 天）+ 汇率（30 天）→ 整体 30 天。

    • 人话：一份沙拉的新鲜度取决于最早坏的那个食材，不是最后放进冰箱的那个。忘了这条，会算出一个「看着新鲜、其实用的是三年前汇率」的成本。

17. 六类禁止换算（computed 也救不了）：支付百分比费率 ↔ 仓储 $/m³/天；红人报价 ↔ 互动率；覆盖区域 ↔ 仓数量；月费 ↔ 年费（有阶梯折扣/最低承诺期时）；类目佣金 ↔ 综合费率（缺官方类目权重就禁加权）；跨辖区牌照类型（MSO ≠ MPI ≠ EMI，牌照不能折算成等级）。

    • 人话：比价的前提是「三同」——同口径（单位定义一致）、同情景（含不含首末程/退货/最低消费一致）、同时间（asof 在同一窗口，建议窗口 ≤ TTL 的一半）。违反三同，只能并排展示，不能说「A 比 B 便宜」。

18. 中文站的自动保鲜要降级两步走：中文 B2B 站普遍不提供 ETag/Last-Modified 这类响应头，页面 diff 噪声大（广告位、计数器、时间戳）→ ①改「定时抓取 + 只比对结构化字段值」而不是全文 diff ②所有自动检测到的变更一律进人工确认队列，不直接覆盖生产值；确认前该字段保持 stale 并保留旧值。

    • 人话：外国网站会主动告诉你「我改过」（响应头/sitemap），中文站往往不说——所以不能信它自报，只能自己按字段比对，而且改了先问人。

19. 保鲜期不是工程偏好，是法定义务：GDPR 第 5(1)(e) 存储限制原则原文「kept in a form which permits identification of data subjects for no longer than is necessary」（保存时间不超过处理目的所必需）+ PIPL 第 17 条处理前须告知保存期限 → 含个人信息的字段（红人联系方式、粉丝画像）到期必须真正执行删除，不是只标 stale。「标过期但留着」在个人信息场景是违规，不是懒。

    • 人话：给别人定的「用到什么时候」，到点就要真删；留着不删还把标签撕了，是最容易被抓的一种错。

20. 顺手记下的一组支付事实（都在官方页上）：美国 MSB 是联邦登记不是牌照（180 天内登记、每 24 个月续期；公开库只披露「分支机构数 + 代理人数」，代理人名单属不公开申报）→ 字段只能设 agent_count 不能设「代理人名单」；四个监管库实测三个是客户端渲染或异步加载（FinCEN 检索页静态正文 2,339 字节、EBA EUCLID 685 字节单页应用外壳、香港 MSO 结果区只返回 1 个表格行）→ 「可直接采集」只对部分字段成立，采集前先测渲染方式；滚存保证金「5-15%、30-180 天」来自厂商博文（无监管一手源），属逐商户合同条款。Stripe 拒付罚金收到 $15/笔、回应 $15/笔（胜诉退还），美国结算 T+2、英国与欧元区 T+3，且官方明确T 从交易时间起算（部分处理商从资金到账银行起算）——「T+2」不带起算点等于没说。

    • 人话：支付这一格最容易骗人的不是费率，是结算周期从哪一刻开始算——同一天成交，能差出好几天到账。

名词表（本期新增词 · 只列不在《常用词表》里的）

本期正文专有名词 66 个（脚本去重统计，为下限值；含重复出现只计一次），其中新增 23 个（下表），其余 43 个常见词见《常用词表》→ https://willgoblog.com/wiki/cheatsheet/glossary

自测入口

6 道题（3 选择 + 2 简答 + 1 实战，100 分制，通过线 80）见 raw/self-test.md；晨报已附题面，读完本速查即可作答。

🔗 重点来源

信源数统计：9 个可读来源（#1-#9），其中 Tier 1 一手来源 3 个（#1、#2、#3），满足验收线（≥8 URL / ≥2 一手源）。#10、#11 为不可读，不计入信源数，仅作「无公开一手源」的举证。