一句定义
普通 Amazon 订单字段约 8-12 列：order-id / sku / quantity / ship-to / price / currency / order-status / 等。处理逻辑：核对、打单、发货。
Amazon Custom 订单在普通字段之外，额外携带 customization-zip 包，里面是 customization-info.json + 客户上传的原始图片/文本文件。这部分独有字段共 12 个核心项，每个都有自己的解析路径和风险点。
本文按 12 个 Custom 独有字段逐个拆：字段名、典型值、处理风险、推荐做法。
适用场景
首次接 Amazon Custom 的卖家：从普通 FBA / FBM 转 Custom，发现 order report 多了好多陌生字段，不知道哪个该解析、哪个该忽略。
对接工厂的运营：要把 12 个 Custom 字段拍平到工厂能直接生产的中文 Excel，需要知道每个字段什么格式。
做订单自动化的工程师：要写解析脚本或对接订单工作台，需要每个字段的数据结构和典型边界 case。
做客服培训的主管：要让客服一眼能看懂客户问的是哪个字段——「我那个 engraving 怎么样了」「我上传的图收到了吗」分别对应不同字段。
输入输出示例
Amazon Custom 订单的 12 个独有字段，逐个对照表：
| # | 字段名 | 典型值示例 | 处理风险 |
|---|---|---|---|
| 1 | customization-text | Mom 2026 / Sarah / Happy Birthday | 拼写不可擅改；emoji 与特殊字符易丢 |
| 2 | engraving-text | Forever Yours / J & K 6.18.2026 | 大小写敏感；日期格式多样需保留原文 |
| 3 | color-customization | Gold / 金色 / #FFD700 | 名称与 hex 混填；需要同义词归一 |
| 4 | font-selection | Anton / Bree Serif / Pacifico | 字体名拼写多种变体；工厂需要精确字体文件 |
| 5 | font-size | 12pt / 14 / Medium | 单位混填（pt / px / 描述词）；需要标准化 |
| 6 | image-upload | 8f0001-2a4b-...jpg（UUID 命名） | 文件名无业务含义；必须按订单号重命名归档 |
| 7 | preview-image | preview_xxx.png（系统生成） | 用于客户和工厂二次确认；不能丢 |
| 8 | surface-area | surfaces[0].areas[1] / Back / Inside | 位置标签英文与具体面要映射到工厂模板的中文位置 |
| 9 | gift-message | Happy Birthday Mom! / 节日快乐 | 多语言；含 emoji 概率高；可能含敏感信息 |
| 10 | gift-wrap | true / false / gift-box / standard | 布尔与文本混填；触发包装工序切换 |
| 11 | option-selection | Size: 18 inch, Material: Sterling Silver | 多个 key:value 对挤在一个字段；需拆分 |
| 12 | customization-version | v1 / v2（客户改单后版本号） | 改单订单要识别最新版本，旧版本素材作废 |
完整原始输入示例（一条项链 Custom 订单的 customization-info.json 节选）：
```
{
"version": 2,
"surfaces": [
{ "areas": [
{ "areaType": "TextPrinting", "label": "Back",
"text": "Mom 2026", "fontFamily": "Anton",
"fontSize": 14, "colorHex": "#000000" },
{ "areaType": "ImageUpload",
"imageUrl": "https://.../8f0001-...jpg" }
] }
],
"options": [
{ "name": "Size", "value": "18 inch" },
{ "name": "GiftWrap", "value": "true" }
]
}
```
对应输出（工厂可执行的中文字段表）：
- 背面文字 = Mom 2026 / 字体 = Anton / 字号 = 14pt / 字色 = 黑色 (#000000)
- 客户上传图 = order_102-7345891_back.jpg
- 链长 = 18 inch (约 45cm)
- 包装 = 礼盒
- 版本 = v2（已确认为最新）
- 审核状态 = 通过 / 原文 = 完整保留
常见误区
误区一：把 customization-text 当成单一字符串处理。它实际上是嵌套 JSON 的浅化版本——只看字符串会丢掉位置标签、字体、字号、颜色四个维度。
误区二：忽略 customization-version。客户下单后改单，Amazon 会推第二条订单，customization-version 从 v1 升到 v2——按旧版本生产 = 整单报废。
误区三：image-upload 用 UUID 文件名直接发工厂。工厂收到 8f0001-2a4b-...jpg 不知道是哪条订单的哪个位置，常错图、漏图。必须按 order_号_位置.jpg 重命名。
误区四：gift-message 当成可忽略字段。礼物留言印错 = 客户最敏感的客诉，比刻字错更难解释（「我送给我妈，你给印成 Dad」）。
误区五：option-selection 用「整段字符串」存进 ERP。「Size: 18 inch, Material: Sterling Silver, GiftWrap: true」整段存为 remark，工厂要自己拆——拆错就报废。
Koru 如何处理
12 个字段全部单独拆解 + 单独审核。每个字段都有独立解析器、独立同义词清单、独立审核策略——不是把整段 customization-info.json 当字符串塞进一个 remark 列。
素材按订单号自动重命名。从 Amazon 抓 image-upload 时按 order_号_surface_area.jpg 重命名归档，工厂 Excel 里的图片列直接是有意义的文件名。
customization-version 追踪。同一个 order-id 进入多个版本时，Koru 自动以最新版本为准、旧版本素材进「作废库」可查不可用，避免按旧版生产。
字段对照表完全可配。surface-area 的「Back / Inside / Front / Left / Right」映射到你工厂的「背面 / 内侧 / 正面 / 左侧 / 右侧」由你团队自己改。
行动建议
1. 把 12 个字段贴在墙上：让运营、客服、生产对接人一起对一遍——哪些字段你们当前根本没在用？哪些字段经常出错？
2. 给每个字段标审核等级：P0 必审（customization-text / engraving-text / gift-message / image-upload）/ P1 失配审（color / font / size / surface-area）/ P2 自动通过（gift-wrap / option-selection 标准值）。
3. 跑 20 条真实订单对照：把过去一周的 20 条 Custom 订单按 12 字段拆解一遍，统计每个字段的「出错次数 / 漏识别次数」——这就是接下来 30 天优化的优先级清单。
4. 建立 customization-version 守门规则：同一 order-id 任何后续版本进入时，旧版本的素材文件必须进「待作废」队列由运营确认——这一条能拦住「按旧图生产」类的整单报废。