如何用 Codex 构建一个 Amazon VOC 打标签系统

我们先看已经跑出来的结果。

特殊说明一下，用户旅程地图的方法论来自于新大佬的文章：亿级品牌化卖家，到底怎么做用户洞察？。这种类似生命周期的表达方式更加直观，可以让我们 get 到具体哪个阶段发生了问题，一目了然。

LLM 审计的作用非常简单，记录所有的 CLI/MCP 调用次数、Token 消耗，让成本清晰可见。

最后，保留完整的评论明细，可以随时阅读，方便快捷。

注意注意！！！上面的报告不是简单把所有评论丢给大模型，然后让模型写一段总结。它们背后有一套更长的流程：评论采集、清洗、taxonomy 自举、闭集打标、质量校验、残差查漏、事实包构建和离线报告渲染。

这篇文章讲的就是这套 VOC 打标系统怎么设计。我们先看一下整体的流程和方法论：

如果图片中很多专业术语看不懂，没关系，文章会逐步展开讲解，接着往下看 😀

一、背景痛点：常规评论分析为什么跑不动

几乎，每个公司，每个上线的产品，我们都会做 VOC 分析。这里评论分析的重点、好处不再赘述，默认大家对评论分析重要性的认知是一致的，如果觉得评论对产品后续的迭代无参考意义，请直接划走，谢谢！

当评论一多，问题就来了。百来条还能人工翻，几千条、上万条以后，人工阅读会变成抽样猜测。更麻烦的是，随着亚马逊政策收紧，前台评论阅读也阻碍重重。即便是通过其他渠道获取到离线评论数据，评论分析不是只看一次，我们需要反复回答这些问题：

• 最近差评主要集中在哪些问题？
• 这个问题是偶发，还是已经成了产品结构缺陷？
• 不同变体、不同尺寸、不同套装是否有不同投诉？
• 好评里的卖点能不能放到 Listing 和广告里？
• 用户到底在什么场景下使用这个产品？
• 这次改版以后，老问题有没有下降？

如果每次都临时看评论，结论很难沉淀。真正需要的是一套稳定的打标签系统：同一类问题每次都被归到同一个标签，标签能聚合、能追踪、能解释，还能随着新问题不断迭代。

真实业务里，常规做法大概有三种。

这里我想重点讲一下飞书多维表格做 VOC 的例子。之所以单独说飞书，是因为多维表格的出现，尤其是 AI 字段 这个创新型产品，曾一度改变了做表格的方式。这种全新的体验前所未有，所以我立马就动手实操了 VOC 分析。如下图：

多维表格玩法可以总结为：

导入评论明细–>新增 AI 字段列–>写标签提示词–>N 个字段列–>全局执行–>产出 Dashboard

这个方法论截至目前依然是众多博主、自媒体在宣传的做法，不过弊端也非常明显。

• 效率
• 成本

真正做过这个案例落地的朋友应该非常有感受。当数量多的时候，首先，免费版飞书多维表格只有 2000 行数据。另外，需要人工新增 N 个 AI 字段列，单独给标签写提示词，打标签的提示词没有上下文关联，经常会出现标签不统一、结果无法有效统计等问题。最关键的是，全局跑一次时它的效率低、成本高是致命的，所以这种方式只能称作是一个玩具，无法胜任生产环境的需求。

二、为什么这些方式不够支撑长期 VOC 资产

这三种方式不是没用。人工适合小样本深读，飞书适合协作展示，商业软件适合快速看大盘。但它们都很难解决同一个问题：如何把评论变成可复用、可追踪、可迭代的数据资产。

归纳下来，常规做法缺的不是一个 dashboard，而是下面这些基础能力：

所以我们不是要否定这些工具，而是要把它们的位置放对。采集工具负责拿数据，表格工具适合协作和临时展示，商业软件适合快速参考。真正要沉淀长期 VOC 能力，就必须自己掌握后面的打标 pipeline：标签体系、LLM 输出标准、质量校验、明细表和报告生成。

三、我们的方法：先把标签体系变成资产

这套系统里，最核心的不是 LLM，而是 taxonomy。

taxonomy 不是一份全行业通用的标签大全，而是一份产品级标签合同。它规定：这个 ASIN 当前允许使用哪些标签，每个标签是什么意思，哪些评论表达应该命中，哪些表达不能混进去。

我们把标签拆成 L1、L2、L3 三层。这里最容易误解，所以要说清楚。

L1 当前固定为 4 类：

• functional_value：**功能价值：**产品解决核心问题的能力与性能。
• experience_value：**体验价值：**使用感受、便捷性、外观、价格价值感。
• assurance_value：**保障价值：**质量、耐用、安全、描述相符、售后服务。
• fulfillment_value：**履约价值：**包装、配送、到货状态。

因为博主的业务以 FBM 为主，所以履约价值也是我非常关心的一个维度。

L2 不是通用行业标签，也不是最终标签。它是某个产品里的问题域，用来把同一对象下的正负反馈组织在一起。

在这套设计中，parent_category 不是摆设。它会沉淀到标签体系和评论打标结果里，也会作为 LLM 理解 taxonomy 的中间层，帮助模型先定位问题域，再选择具体的 L3 label_code。不过主统计口径仍然是 L3，L2 更多承担的是组织标签、辅助打标，以及为报表提供中间层分析视角的作用。

比如便携充电宝里，L2 可能是：

猫爬架里，L2 又会变成另一套产品问题域：

也就是说，L2 可以因产品而异。充电宝的 battery_capacity 和猫爬架的 product_size 没必要强行统一。真正跨产品稳定的是 L1，真正进入主统计的是 L3。L2 有价值，但它不是问题排行和趋势追踪的最小口径。

L3 是最核心的落表标签。它必须足够具体，最好同时包含“评价对象”和“方向”。例如：

label_code: capacity_misrepresentation_negative
label_cn: 容量虚标
value_dimension: assurance_value
parent_category: battery_capacity
sentiment_direction: negative
definition: 用户认为实际容量、续航或可充次数明显低于标称或预期。

这比只写 capacity 有用得多。capacity 只是名词，无法判断是夸容量大，还是骂容量虚标。capacity_misrepresentation_negative 才能直接进入报告、趋势和产品动作。

所以三层的关系可以概括成一句话：

L1 决定业务价值层，L2 决定产品问题域，L3 决定最终统计口径。

在正式打标时，LLM 只能选择 L3 的 label_code。L1 和 L2 要么由这个 label_code 在 taxonomy 里反查得到，要么作为一致性校验字段输出。这样做的目的，是避免模型今天说“尺寸问题”，明天说“规格问题”，后天说“空间不足”，最终把同一个问题拆成三套口径。

四、为什么要先 bootstrap，再做闭集打标

新产品刚接入时，我们不可能一开始就手写完整 taxonomy。完全人工写，慢，而且容易靠经验拍脑袋。

所以第一步是 bootstrap-taxonomy。

它会从评论中抽样，调用 LLM 生成一份产品级 taxonomy.yaml 草稿。这里要注意两个细节。

第一，它不会把所有评论一次性塞给大模型。默认最多抽 120 条。5000 条评论也是抽 120 条，10000 条评论也是抽 120 条。抽样会偏向差评和中评，因为 VOC 里最需要先兜住的是问题。

第二，生成出来的 taxonomy 默认是：

schema_status: draft

draft 不能直接进入正式打标。它只是第一版候选体系。

接着系统会做 holdout 验证。也就是从没有参与 taxonomy 生成的评论里，再抽一批评论，用这份 taxonomy 去打标，看它是否真的覆盖得住。

验证主要看四个指标：

通过验证后，taxonomy 可以进入 auto_validated。没通过，就继续修订，或者停下来人工审核。

这一步是为了处理抽样的天然局限。我们承认 120 条样本不可能覆盖全局，所以必须用未参与生成的评论再做一次压力测试。

五、LLM 具体怎么打标签：提示词、输出和落表

taxonomy 通过后，正式 pipeline 才进入 label_reviews。

全量评论都会被处理，但不是一次性塞进模型。当前默认每批 5 条评论，最多 16 批并发。5000 条评论大约是 1000 个批次，10000 条评论大约是 2000 个批次。

每次请求的 system prompt 由三部分拼起来：

固定打标提示词
+ 批量模式补充规则
+ 当前 taxonomy_labels JSON

这意味着 LLM 看到的不是一句“帮我分析评论”，而是一份受约束的任务书。

固定提示词先定义角色：

你是 Amazon 评论 VOC 打标专家，负责根据给定的三层标签体系（taxonomy）对评论打标签。

然后规定三层标签结构：

value_dimension 是 L1，固定 4 个维度。
parent_category 是 L2，表示维度下的细分领域。
label_code 是 L3，打标时只能从这一层选择。

真正的打标步骤也写死了：

1. 通读评论，拆出每一个独立问题点或卖点。
2. 一个评价对象加一个明确态度，才算一个点。
3. 每个点先判断 L1，再到该维度下选择最匹配的 L3。
4. 用户着墨最多，或对购买决策影响最大的点，作为 primary_label。
5. 其他点进入 aspects，并且主标签对应的点也必须出现在 aspects 里。
6. evidence 必须逐字摘自评论原文，不能翻译、改写、拼接。

批量模式还会追加几条硬规则：

顶层 key 必须是 review_results。
review_results 必须和输入 reviews 数量一致。
返回顺序必须和输入顺序一致。
每个元素都必须使用单条评论的 JSON 结构。
primary_label 不是 insufficient_content 时，aspects 不允许为空。

LLM 的输出标准是严格 JSON。下面是示意结构，里面的 charging_issue、customer_service_issue 等 code 只表示“当前 taxonomy 里已经存在的 L3 标签”，不是跨品类固定标签。

{
  "review_results": [
    {
      "review_label": {
        "review_id": "R1",
        "overall_sentiment": "negative",
        "value_dimension": "functional_value",
        "primary_label": "charging_issue",
        "secondary_labels": ["customer_service_issue"],
        "parent_category": "battery_charging",
        "affected_component": "charging",
        "severity": "high",
        "actionability": "product_or_firmware_improvement",
        "evidence": "then it just stopped charging",
        "confidence": 0.95
      },
      "aspects": [
        {
          "aspect_name": "stops_charging_after_two_weeks",
          "aspect_display_cn": "两周后无法充电",
          "label_code": "charging_issue",
          "sentiment": "negative",
          "sentiment_score": -2,
          "affected_component": "charging",
          "evidence": "then it just stopped charging",
          "severity": "high",
          "confidence": 0.95
        }
      ]
    }
  ]
}

这里有几个字段非常关键。

如果评论证据不足，模型不能硬猜。它必须输出：

{
  "primary_label": "insufficient_content",
  "aspects": []
}

最后结果会落到两张核心表。

review_labels 是评论级主标签，一条评论一行。它保存 review_id、value_dimension、primary_label、secondary_labels、parent_category、severity、actionability、evidence、confidence、needs_review、llm_model 等字段。后续做主问题排行、差评聚合、变体对比、趋势追踪，主要看这张表。

review_aspects 是多观点明细，一条评论可以有多行。它保存 aspect_index、aspect_name、aspect_display_cn、label_code、value_dimension、sentiment、sentiment_score、affected_component、evidence、severity、confidence 等字段。它解决的是“评论里不止一个观点”的问题。

比如一条评论同时说：

安装很简单，但尺寸比想象中小，包装到货时已经破了。

主标签可能只选 size_too_small_negative，因为它对购买决策影响最大。但 review_aspects 会保留三件事：

这就是两张表同时存在的原因：review_labels 保证主统计口径稳定，review_aspects 保证一条评论里的多个业务信号不被压扁。

这里顺带说一下 LLM 接口选择。

如果只是几十条评论，随便选一个顺手的模型接口问题不大。但一旦评论量超过 500 条，就不建议直接用 DeepSeek 这类通用 API 做全量打标。原因不只是单价，而是 VOC 打标不是一次问答：它会拆成很多批次，还会有结构化输出、失败重试、证据校验、上下文补充等开销。数量一上来，总成本和总耗时都会被放大。为什么这么说？因为博主的 DeepSeek 账单就不小心跑欠费过 T-T…

既然是在 Codex 中做这套系统，默认更合理的方式是让 Codex 承担工程调度和离线编排，而不是把所有评论直接塞给执行 agent。直接让 agent 一路读评论、打标签、汇总，很快就会把上下文撑爆，最后既慢又不稳定。

我们实际需要的是一种折中方案：评论原文、中间结果和数据库都留在本地 pipeline 里，agent 只负责调度；真正的大批量模型调用，则通过一个更可控的接口层来承接。至于如何把 Codex 的能力更稳定地接到这条离线流水线里，这里面有一点“黑科技”，本文先卖个关子，后面会单独写一篇展开。我相信聪明的你，肯定已经猜到了 🙂

六、质量校验：把不可靠的结果显形

LLM 输出以后，系统不会直接相信。

当前会做几类校验：

• label_code 必须在 taxonomy 闭集内。
• 闭集外标签会被归入兜底标签，置信度压低。
• evidence 必须能在评论原文里找到。
• LLM 返回的 review_id 必须和输入一致。
• 星级情绪和模型情绪强冲突时，进入复核。
• 长文本却只能打到 insufficient_content，也会进入复核。

这些规则不复杂，但很重要。它们让系统知道哪些结果可信，哪些结果要谨慎。

needs_review=true 不是失败标记。它更像一个信号：这条评论可能暴露了 taxonomy 的边界问题，或者模型判断不够稳。

七、Residual 查漏：让全量评论反过来修正 taxonomy

bootstrap 抽样一定会漏。真正让 taxonomy 越来越准的是 residual 查漏。

全量打标后，系统会把这些评论抽出来：

needs_review = true
primary_label = insufficient_content

这些评论会进入 residual topic modeling。系统会把它们聚成主题，再生成 taxonomy_candidates。

这里的逻辑是：

如果一批评论在当前闭集里找不到好标签，它们就不应该被硬塞进旧标签。应该把它们聚出来，作为候选标签交给人判断。

比如 bootstrap 样本里没出现“自带线发热”，正式打标时却发现很多评论都在说：

the built-in cable gets hot
cable overheated while charging
integrated cord melted

这些评论可能会被打成 insufficient_content，或者被标记为 needs_review。进入 residual 聚类后，系统就可能生成一个候选：

built_in_cable_overheating_negative

但它不会自动写回 taxonomy。候选只是候选。人工审核后，确认它有业务意义，才会补齐 definition、include/exclude、severity、actionability，再合入 taxonomy.yaml。

这就是闭环：

抽样生成 taxonomy
-> holdout 验证
-> 全量闭集打标
-> needs_review / insufficient_content 暴露盲区
-> residual 聚类生成 taxonomy_candidates
-> 人工审核合入
-> 升级 taxonomy_version
-> 重跑

八、场景画像为什么单独做

VOC 标签回答的是“用户在抱怨什么，或者夸什么”。

但业务还会问另一个问题：谁在什么场景下使用？

比如宠物用品报告里，我们不只关心“尺寸偏小”，还关心是不是多猫家庭、是否用于幼猫、是否放在客厅、用户购买动机是省空间还是耐抓。

这些信息属于 context，不适合和 VOC 标签混在一起。

所以 pipeline 里有一条独立链路：

review_context_inference
context_value_taxonomy
context_value_mapping

context 字段先开放抽取，再做归一化。这样既保留了不同产品的场景差异，又避免报表里出现一堆同义词。

简单说：

• VOC 标签是闭集，保证统计口径稳定。
• 场景画像是开放抽取，再合并成稳定展示值。

九、从方法到 Skill 工程：最终沉淀什么

这套能力最终被封装成 amazon-voc-insight-report Skill。

Skill 本身不是在聊天里逐条分析评论。它更像一套离线流水线的入口约束：什么时候可以跑、输入文件放哪里、taxonomy 怎么验证、LLM 怎么调用、结果怎么落库、报告怎么生成。

工程上可以拆成三层，不需要把目录讲得太碎。

运行时数据不写在 Skill 目录里，而是写到用户目录：

~/Documents/AI-Ecommerce-Runs/amazon-voc/runs/<run_slug>/

一个完整 run 至少会产出这些东西：

• 原始评论文件和清洗后的评论表。
• DuckDB 数据库，里面包含 taxonomy_labels、review_labels、review_aspects、review_context_inference 等表。
• taxonomy.yaml，记录当前产品的标签合同。
• LLM 调用审计，记录 provider、model、stage、status、latency、token 等信息。
• insight_facts.json 和 report_data.json，作为报告生成的数据包。
• 单文件 HTML 报告，方便直接发给业务同事看。

LLM API 这一层也不能只理解成“填一个 key”。真正要稳定跑起来，至少要处理五件事。

第一，Provider 抽象。OpenAI-compatible API、DeepSeek 这类接口都应该能接入，不同 provider 的 base URL、模型名、超时、并发、返回结构要隔离在配置里。

第二，结构化输出。taxonomy、review label、context、候选标签都必须是 JSON。自由文本看起来顺滑，但不能稳定入库，也不能做质量校验。

第三，失败兜底。批量结果数量不一致、JSON 解析失败、review_id 对不上、证据找不到，都要能识别。批量失败后可以降级重试，必要时回退到规则打标。

第四，成本控制。5000 条评论按每批 5 条计算，大约是 1000 次请求。batch size、并发、重试次数、抽样策略和上下文长度，都会影响成本。

第五，审计可追溯。报告里的结论不能只写“模型认为”。它要能追到原始评论、命中的 label_code、证据片段、置信度、模型版本和 taxonomy 版本。

最终沉淀下来的方法论，其实很简单：

用产品级 taxonomy 控制标签一致性，
用 LLM 做语义判断，
用质量校验暴露不可靠结果，
用 residual 闭环持续补齐 taxonomy。

这比“一键总结评论”慢一些，但它能长期复用。Amazon VOC 的难点不在于让模型读懂一句评论，而在于让 10000 条评论在同一套口径下被理解、被统计、被追踪。

十、技术栈与工具选型

最后简单列一下这套方案背后的工具选型。核心目标三个：离线可跑、结果可审计、后续可复用。

如果只是写一个 demo，用表格加提示词也能跑出一些结果。但真正要把它变成可复用的 VOC 系统，就不能只看“模型能不能总结”。更重要的是：数据怎么留、标签怎么控、输出怎么校验、报告怎么复跑、成本怎么兜住。

👉最后，如果对本期介绍的 VOC 打标签系统感兴趣，欢迎在微信公众号评论区留言：【VOC报告】，获取 HTML 报告源码，体验完整的交互报告！