用 Codex 从用户抱怨里反推产品机会，别只追爆款

先讲结论：抱怨比销量榜更适合做差异化

选品最常见的做法是看销量榜：什么卖得好就跟什么。问题是榜单上的信息所有人都看得到，跟进去只能拼价格。

抱怨不一样。

一个类目的差评里，如果有一半的人在说同一件事——比如「用两个月就松了」「说明书看不懂」「跟宣传的尺寸对不上」——这说明现在在卖的产品集体没解决这个问题。这就是一个还没被占住的位置。

**销量榜告诉你什么东西好卖，抱怨告诉你现在的东西哪里不行。**做差异化要看的是后者。

这件事人工做很累：要翻几百条评论、跨好几个来源、还要自己归纳。而这正好是 Codex 擅长的——不是它比你会分析，是它不嫌烦。

去哪里找抱怨

四个来源，可信度依次不同。

竞品差评

最直接，也最容易拿。一星到三星的评论，尤其是三星——一星里情绪化和物流问题占比高，三星往往是「产品能用，但有个地方不行」，信息密度最高。

你自己的退货理由和售后记录

最可信，因为背后是真金白银的退货，不是随口一说。但只覆盖你已经在卖的品。

如果你已经在这个类目里，先把自己的退货理由聚类，往往比翻竞品评论更快找到问题。而且这类数据在本地，不需要联网，用只读沙箱就能跑。

论坛和社区

价值在于它们说的是「我想要什么」，而不只是「我买的这个哪里不好」。更接近需求本身，但也更松散，噪音多。

商品页的问答区

经常藏着最实用的信息：买家在下单前反复问的问题，通常就是商品页没讲清楚、或者产品确实没做到的地方。

从抱怨到机会，要过四道筛

收集只是第一步。一堆抱怨堆在一起没用，要按四个维度排优先级。

出现频率：多少条评论提到了这个问题，占抽样总量的多少
严重程度：是「不好用」还是「不能用」。导致退货的问题权重远高于导致吐槽的问题
改造归因：问题出在产品设计、材料、生产，还是说明书。说明书能改，模具不一定
改造成本：解决它要加多少成本，这个成本能不能在售价里收回来

四个维度都高的，是真正的机会。频率高但改造成本极高的，是这个类目的公共难题，谁都没解决，你大概率也解决不了。

**最容易被低估的是「说明书导致的问题」。**很多差评的根因不是产品不行，是买家没装对、没用对。这类问题改造成本极低——重做一份图解说明书、在商品页加一段安装视频——但对退货率的影响可能很直接。

权限怎么配

按数据来源分，这个活可能落在两档里。

只分析自有退货数据：数据在本地，用 read-only 就够。这是最安全也最该先做的一档。

要抓竞品评论和论坛：需要联网，在专用的调研目录里做，规则和上一篇一样——目录里只放调研数据，抓取守站点规则。

建议的顺序是先做第一档。自己的退货理由是最可信的数据，而且不需要任何网络权限。很多团队跳过它直接去抓竞品，其实手边就有更准的东西。

用子代理拆开

这是子代理最典型的场景。

几百条评论如果全进主线程，上下文很快被原文填满，而你真正要的只是聚类结果。

做法：按来源或按批次派子代理，每个子代理读一批、归类、只返回问题类型、条数和几条证据片段，原文留在各自分支里。主线程拿到的是干净的统计，再做跨来源的汇总。

子代理的指令里要写死这一条：

只返回问题类型、提及条数和最多 3 条原文片段作为证据。
不要把原始评论全部带回。

不写这句的话，它很可能把读到的都带回来，那和不拆没区别。

另外子代理这一档配 read-only 就够——它只需要读，写报告是主线程的事。

规则文件怎么写

把分类维度和排序规则写进 AGENTS.md，这样每次跑出来的口径一致：

## 抱怨聚类

把抱怨归到这几类，一条可以归多类：

- 耐久性：用一段时间后坏了、松了、褪色
- 功能不达标：能用但达不到宣传效果
- 尺寸与兼容：尺寸不符、装不上、不兼容
- 使用门槛：装不明白、说明书看不懂
- 品质一致性：批次差异、收到的和图不符
- 包装与运输：破损、缺件
- 服务：客服、售后、保修

## 排序

每类输出四个值：

- 出现频率：提及条数 ÷ 抽样总条数
- 严重程度：高（导致退货或不能用）／中（影响体验）／低（吐槽）
- 改造归因：设计／材料／生产／说明与包装／服务
- 改造成本估计：低／中／高，并说明理由

按「频率 × 严重程度」排序，同时单独标出「改造成本低但频率高」的项，这类优先做。

## 禁止

- 不要把「抱怨多」直接写成「有市场」
- 不要编造或改写用户原文
- 抽样量不足 50 条时，明确写「样本不足，结论仅供参考」

两个必须承认的边界

这套方法有效，但有两处天然偏差，报告里要明说，否则容易把自己带沟里。

写抱怨的人不代表全部买家

会专门写差评的人，本来就是体验偏负面的那部分。用差评推断整体满意度会严重失真。

正确用法是：用差评找问题的种类，不用差评估问题的比例。

「有 8% 的评论提到松动」不等于「8% 的用户遇到松动」——真实比例可能更低，也可能高得多，因为大部分人遇到问题只是退货，不写评论。

抱怨得最响的，未必是愿意多付钱解决的

这是更隐蔽的一个坑。

买家抱怨某个材质不够高级，不代表他愿意为更好的材质多付 30%。很多抱怨的本质是「这个价位我还想要更多」，而不是「我愿意加钱买更好的」。

所以从抱怨推出改造方向之后，还要过一道价格测试：这个改进值多少钱，加进售价之后你还在原来的价格带里吗？如果一改就跳出主力价格带，那这个「机会」可能是个陷阱。

这一步之后该做什么

抱怨分析的产出是假设，不是结论。

拿到需求清单之后，通常还要做三件事：

找供应商问一下，排名前三的问题改造起来分别要加多少成本
把改造后的卖点写成一句话，看它能不能在商品页第一屏说清楚
如果改造成本高，先只做低成本那一档——说明书、商品页、包装，先看退货率有没有动

先验证便宜的假设，再投入贵的。

一个容易被忽略的用法

除了选品，这套方法还有一个立刻能用的场景：改自己的商品页。

把你自己产品的差评和退货理由跑一遍，会发现相当一部分问题不是产品的问题，是商品页没说清楚——尺寸没标全、兼容范围没写、使用条件没提。

这类问题改起来最便宜：改文案就行，不用动产品。而且效果直接反映在退货率上。

所以如果你还在犹豫从哪开始，从这个开始——数据在本地、只读权限、改动成本最低、效果可衡量。

下一步

找到差异点之后，下一篇讲怎么把它写进 Listing：产品资料包该怎么整理，以及怎么一次生成多个站点的版本而不是简单翻译。