GEO-080·第 07 期·技术底座·80 / 132
区域化 feed 与价格：货币、税、运费
feed 里的价格、税、运费写错，AI 会把你从候选集划掉。本文拆开货币、含税口径、运费门槛与到岸价的字段写法，给出单源生成、断言校验、异常告警的四步流程、一份能进 CI 的检查清单，并划清区域化 feed 的适用边界。
本期主线跨市场：多语言、本地化与区域语义
周五下午，客服转来一封邮件：一位德国买家说，他在聊天助手里看到的价格比结账页低，还被告知免运费。运营查了半天，商品页并没有写错，错在 feed——导出的是未税净价，运费字段沿用了美国站的“全场包邮”。买家没有投诉，他只是关掉页面，点开了另一个品牌。
区域化 feed 的单位不是商品，而是“一个商品在一个市场的一份完整报价”：货币、含税口径、运费、到货窗口四项只要有一项说不清，AI 就会换一种说法，或者换一个品牌。
feed 的主键是商品加市场
同一台咖啡机在德国、英国、美国卖，是三份不同的承诺，不是一条记录加一次汇率换算。
检索型 AI 和购物 agent 读的是字段，不是你的商品页排版。它能拿到价格、货币、库存、运费、时效，就能算总价、做比较、走到下单；拿不到，就只剩两种处理：加一句“价格与运费以商家页面为准”，或者从候选名单里划掉。前者把比较权交回买家，后者连解释的机会都没有。
所以第一步是改粒度：feed 的行数从“SKU 数”变成“SKU 数乘以市场数”，一行带一套货币、税制、运费与到货时间，行内自洽，行间不互相引用。让接收方拿全球价按汇率折算，等于把定价权交给不了解你成本结构的外部系统。
反例是把区域化当成翻译。标题和卖点翻得再地道，价格还是美元、运费还写着仅限本土，模型算出的总价就是错的——翻译只是让错误读起来更顺。先定做哪个市场，再谈一行一行怎么填，判断顺序见市场进入的六个变量。
本地化的是交易字段，不是文案
预算通常花在翻译标题，而 AI 拿来比较的是五个数值字段。文案不可比，数字可比；字段错一个，整页文案都救不回来。
| 字段 | 必须写成 | 常见写坏 |
|---|---|---|
| 价格 | 纯数字，不带符号、不带“起” | “€89 起”“低至 89” |
| 货币 | ISO 4217 代码，与该市场一致 | 只给符号 €，或英国站仍写 EUR |
| 税 | 明示含税或未税，与页面同一口径 | 默认对方知道，两个出口各写一种 |
| 运费 | 金额、币种、门槛、目的国 | “结账时计算”“全球包邮” |
| 到货 | 按该市场实际使用的仓与承运商给区间 | 直接搬本国仓的时效 |
五项里，价格、税、运费必须逐市场重算，货币与到货窗口不能从别的市场抄。表格不是给运营看的，是给校验脚本读的：只要某一格允许写“结账时计算”，后面所有自动比对都会失效。
到岸价才是 AI 比较的那个数
买家问“多少钱”，模型答的其实是“到手多少钱”。三个字段决定这个数能不能算出来。
含税口径是第一道坎。欧盟对消费者的标价通常要求含税，美国多数州在结账时另加销售税；同一句“299”在两个市场意味着两个总价。feed 不写清含税与否，模型只能猜，猜错的那次就是买家截图投诉的那次。
运费是第二道坎。“免运费”是承诺而不是状态：满额包邮的门槛、偏远地区附加费、超大件附加费，每个市场都不一样。一行写“全球包邮”，等于在运费更贵的市场许了一个做不到的承诺，而这个承诺会被 AI 原样转述。
第三道坎是关税与清关。DDP 与 DAP（很多卖家仍写作 DDU）的差别，买家在结账前看不见，agent 却要在报价时算进去。算不出精确值，就把“未含关税”“到货另付”写成字段，让模型能正确地打折扣——残缺还能被标注，含糊只能被猜。这也是价格与库存的四个出口里最容易漏的一个：页面、结构化数据、feed、结账四份副本，币种与税制必须同源。
四步：单源生成、断言校验、异常告警
目标不是“把 feed 改对一次”，而是让错误在发布前就失败。
| 步骤 | 做什么 | 谁来做 | 怎么算过 |
|---|---|---|---|
| 1 定矩阵 | 列出市场、货币、税制、发货仓，确定每个市场一行 | 增长与财务 | 每个在售市场都有行，没有空市场 |
| 2 单源生成 | 价格、税、运费由同一主数据算出，导出脚本不做二次加工 | 工程 | 改一次价，feed、页面、结账同步 |
| 3 断言校验 | 把规则写成会失败的检查，接进发布流程 | 工程 | 故意改坏一条，流水线必须报错 |
| 4 告警与复测 | 每日抽样比对，差异进告警；每月用本地语言提问复测 | 增长 | 差异能归因到具体字段 |
断言清单按“缺字段”和“字段矛盾”分两类写，不要合成一个“通过率”：
- 每行有 ISO 货币代码，且与页面、结账一致
- 含税标记非空，且与本地页面口径相同
- 运费与门槛可计算，不出现“结账时计算”
- 到货窗口来自该市场实际使用的仓与承运商
- 价格与库存的更新时间在约定 TTL 内
- 同一 SKU 在不同市场的落地链接不互相串
语法校验只保证文件能被解析，不保证报价是对的。语法错误会让整份文件被拒，语义错误只会让你安静地少掉一批候选——后者更需要告警。复测口径沿用AI 可见度基线：同一批本地语言问题，改动前后各问一次，看模型报的价、运费与时效有没有变。
示例：一台咖啡机，四个市场四行
示例：一个做家用咖啡机的品牌（假设场景），同一款机器在四个市场各占一行。
| 市场 | 标价 | 税 | 运费 | 到货 |
|---|---|---|---|---|
| 德国 | 349 EUR | 含当地增值税 | 满 50 EUR 免，否则 4.95 EUR | 2–4 天，本地仓 |
| 英国 | 309 GBP | 含增值税 | 4.95 GBP，无门槛 | 3–5 天，本地仓 |
| 美国 | 379 USD | 未税，结账按州计 | 满 75 USD 免 | 2–5 天，本地仓 |
| 加拿大 | 519 CAD | 未税，关税另计 | 12 CAD 起 | 5–8 天，跨境 |
四行的差别不在文案，在四个字段。德国行的价格含税、运费有门槛；美国行价格未税、运费门槛更低；加拿大行跨境，关税必须单列。把这四行合成一行交给接收方换算，AI 只能给出一个模糊区间，agent 走到结算就对不上。
单一市场也逃不掉。只做一个市场时最容易漏的是运费门槛与到货窗口，因为团队默认“大家都知道”；而买家在 AI 里问的恰恰是这两件事。单位、支付习惯、退货窗口这些本地表达，另有本地购买语言里的五个陷阱要过一遍。
边界：什么时候不该做区域化 feed
只做一个市场时，先别建多市场矩阵。矩阵的维护成本随市场数上升，收益要等到第二个市场才出现。
纯平台内成交的品类，字段规范由平台定，你的动作是补齐而不是自建。官网 feed 的优先级要往后放，投入先放在平台要求的那套字段上。
按单报价、定制、B2B 批发这类没有固定价的生意，不要硬造一个到岸价。写清“按需报价”与报价有效期，比给一个会被引用的假数字安全。
税与合规口径不由内容或工程团队定。含税展示、关税起征点、折扣披露，都要财务与本地税务顾问确认；本文给的是字段结构，不是税务意见。
价格波动大的品类别追实时。你能承诺价格稳定多久，缓存与更新频率就只能到多久；追不上的实时，不如一个诚实的有效期。
这个月先做一件事：挑一个已经出单的非默认市场，把该市场的 feed 行单独导出，按“价格、货币、税、运费、到货窗口”五列做一次对账。与结账页对不上的 SKU 全部列出来，先修销量前 20 个，并把这次对账写成每月自动跑的一条检查。这条线归在技术底座主题页。