不追爆款：用 Claude Code 从用户抱怨里反推产品机会
销量榜告诉你什么东西好卖，抱怨告诉你现在的东西哪里不行——后者才是差异化的入口。做法是把竞品差评、论坛吐槽和自己的退货理由收到一起，按问题类型聚类，再按出现频率、严重程度和改造成本排序，输出一份带证据的需求清单。两个边界要认：写抱怨的人不代表全部买家，而且抱怨得最响的问题，未必是买家愿意多付钱解决的问题。
先讲结论：抱怨比销量榜更适合做差异化
选品最常见的做法是看销量榜：什么卖得好就跟什么。问题是榜单上的信息，所有人都看得到，跟进去只能拼价格。
抱怨不一样。
一个类目的差评里，如果有一半的人在说同一件事——比如「用两个月就松了」「说明书看不懂」「跟宣传的尺寸对不上」——这说明现在在卖的产品集体没解决这个问题。这就是一个还没被占住的位置。
销量榜告诉你什么东西好卖，抱怨告诉你现在的东西哪里不行。做差异化要看的是后者。
这件事人工做很累：要翻几百条评论、跨好几个平台、还要自己归纳。这正好是 Claude Code 擅长的——不是它比你会分析，而是它不嫌烦。
去哪里找抱怨
四个来源，价值和可信度依次不同。
竞品差评
最直接，也最容易拿。一星到三星的评论，尤其是三星——一星里情绪化和物流问题占比高，三星往往是「产品能用，但有个地方不行」，信息密度最高。
你自己的退货理由和售后记录
这类是最可信的，因为背后是真金白银的退货，不是随口一说。但只覆盖你已经在卖的品。
如果你已经在这个类目里，先把自己的退货理由聚类，往往比翻竞品评论更快找到问题。
论坛和社区
Reddit、专业论坛、垂直社群里的讨论，价值在于它们说的是「我想要什么」，而不只是「我买的这个哪里不好」。
这类内容更接近需求本身，但也更松散，噪音多。
社媒评论区和问答
商品页的问答区经常藏着最实用的信息：买家在下单前反复问的问题，通常就是商品页没讲清楚、或者产品确实没做到的地方。
从抱怨到机会，中间要过四道筛
收集只是第一步。一堆抱怨堆在一起没有用，要按四个维度排出优先级。
- 出现频率：多少条评论提到了这个问题，占抽样总量的多少
- 严重程度：是「不好用」还是「不能用」。导致退货的问题权重远高于导致吐槽的问题
- 改造可行性：这个问题是产品设计导致的、材料导致的、还是说明书导致的。说明书能改，模具不一定
- 改造成本：解决它要加多少成本，这个成本能不能在售价里收回来
四个维度都高的，是真正的机会。频率高但改造成本极高的，是这个类目的公共难题，谁都没解决，你也大概率解决不了。
最容易被低估的是「说明书导致的问题」。很多差评的根因不是产品不行，是买家没装对、没用对。这类问题改造成本极低——重做一份图解说明书、在商品页加一段安装视频——但对退货率的影响可能很直接。
完整的 Skill
---
name: complaint-mining
description: 从竞品差评、论坛讨论和自有退货记录里提炼用户抱怨，聚类成需求清单并按机会大小排序。当用户要做产品差异化、找改进方向、分析差评或退货原因时使用。
argument-hint: [类目或产品]
allowed-tools: Read Write WebSearch WebFetch Bash(python3 *)
---
## 任务
围绕 $ARGUMENTS，收集并分析用户抱怨，输出一份带证据的需求清单。
## 数据来源
按可信度从高到低使用：
1. `data/returns/` 下我们自己的退货理由和售后记录
2. 竞品商品页的一到三星评论，优先三星
3. 商品页问答区里被反复问到的问题
4. 论坛和社区里关于这个品类的讨论
每条抱怨都要记录来源和原文片段，不能只留结论。
## 聚类规则
把抱怨归到这几类，一条抱怨可以归多类：
- 耐久性：用一段时间后坏了、松了、褪色
- 功能不达标：能用但达不到宣传效果
- 尺寸与兼容：尺寸不符、装不上、不兼容
- 使用门槛：装不明白、说明书看不懂
- 品质一致性：批次差异、收到的和图不符
- 包装与运输：破损、缺件
- 服务：客服、售后、保修
## 排序
每个问题类别输出四个值：
- 出现频率：提及条数 / 抽样总条数
- 严重程度：高（导致退货或不能用）、中（影响体验）、低（吐槽）
- 改造归因：设计 / 材料 / 生产 / 说明与包装 / 服务
- 改造成本估计：低 / 中 / 高，并说明理由
按「频率 × 严重程度」排序，同时单独标出「改造成本低但频率高」的项，这类优先做。
## 输出
在 `reports/` 目录生成 Markdown 报告：
1. 抽样说明：抓了多少条、来源分布、时间范围
2. 问题清单表：按排序输出，每行带上面四个值
3. 每个前三名的问题，附 3 条原文片段作为证据
4. 低成本改造建议：说明书、商品页、包装层面能立刻做的
5. 产品级改造建议：需要改设计或材料的，注明成本量级
6. 明确写出这次抽样的偏差风险
## 禁止动作
- 不要把「抱怨多」直接写成「有市场」
- 不要编造或改写用户原文
- 抽样量不足 50 条时，明确写「样本不足，结论仅供参考」
- 抓取公开页面时遵守站点规则，不做高频请求
两个必须承认的边界
这套方法有效，但有两处天然的偏差，报告里要明说，否则容易把自己带沟里。
写抱怨的人不代表全部买家
会专门写差评的人，本来就是体验偏负面的那部分。用差评推断整体满意度会严重失真。
正确的用法是：用差评找问题的种类，不用差评估问题的比例。「有 8% 的评论提到松动」不等于「8% 的用户遇到松动」——真实比例可能更低，也可能高得多，因为大部分人遇到问题只是退货，不写评论。
抱怨得最响的，未必是愿意多付钱解决的
这是更隐蔽的一个坑。
买家抱怨某个材质不够高级，不代表他愿意为更好的材质多付 30%。很多抱怨的本质是「这个价位我还想要更多」，而不是「我愿意加钱买更好的」。
所以从抱怨推出改造方向之后，还要过一道价格测试：这个改进值多少钱，加进售价之后你还在原来的价格带里吗？如果一改就跳出主力价格带，那这个「机会」可能是个陷阱。
这一步之后该做什么
抱怨分析的产出不是结论，是假设。
拿到需求清单之后，通常还要做三件事：
- 找供应商问一下，排名前三的问题改造起来分别要加多少成本
- 把改造后的卖点写成一句话，看它能不能在商品页第一屏说清楚
- 如果改造成本高，先只做低成本那一档——说明书、商品页、包装，先看退货率有没有动
先验证便宜的假设，再投入贵的。这个顺序反过来的话，代价会很大。
下一步
选品这条线到这里就完整了：品类调研负责看清市场，抱怨分析负责找到位置。
下一篇进入 Listing，讲同一份产品资料怎么写成一条既能被关键词检索到、又能被 AI 问答读懂的商品页。
