从小红书评论区挖需求：我准备用 opencode 写一个 Chrome 插件

最近我在做一个小实验：

能不能从小红书评论区里，提取出用户真实的需求和痛点？

这个想法听起来有点简单，但越想越有意思。

因为很多产品需求，其实不是从会议室里想出来的，而是藏在用户的吐槽里、疑问里、抱怨里、求助里。

比如评论区里经常会出现这种话：

text 复制代码

这个太麻烦了，有没有简单一点的方法？
有没有适合新手的？
有没有便宜一点的替代方案？
我也遇到这个问题，最后是怎么解决的？
看完还是不知道怎么选。
这个功能很好，但我真正想要的是......

这些评论看起来只是普通互动，但如果放在产品视角里看，它们很可能就是：

text 复制代码

用户痛点
潜在需求
产品机会
内容选题
知识星球选题

所以我准备做一个 Chrome 插件，用来采集某个小红书帖子下面已经展示出来的评论，并导出成 JSON 文件。后续再把这些评论交给 AI 分析，提炼出用户痛点和产品需求。

这个系列文章，就是记录我如何用 opencode 从零开始开发这个插件。

一、为什么盯上小红书评论区？

很多人做产品调研，第一反应是问卷、访谈、行业报告。

这些方法当然有价值，但它们都有一个问题：

用户在正式调研场景里，往往说得比较"正确"，但不一定说得真实。

而评论区不一样。

评论区里，用户通常是被某个具体内容刺激之后，顺手表达自己的真实反应。

这种反应往往很口语化，但也非常有价值。

比如一个帖子讲"职场效率工具"，评论区可能会有人说：

text 复制代码

领导天天发语音，听完后面的，前面的都忘了。

这句话如果只当评论看，就是一句吐槽。

但如果从产品角度看，它背后至少有几个需求：

text 复制代码

语音转文字
语音内容总结
待办事项提取
截止时间识别
自动生成回复话术

这不就是一个"领导语音纪要助手"的雏形吗？

所以，我真正想做的不是"抓评论"本身，而是：

从评论中提取用户真实痛点，再把痛点转化成产品需求。

二、评论为什么能反映用户痛点？

我理解，一个有价值的评论，通常不只是表达情绪，而是暴露了一个没有被满足的需求。

比如下面几类评论就很值得关注。

1. 抱怨型评论

text 复制代码

这个流程太麻烦了。
我每次都卡在这一步。
为什么没有一个简单点的工具？

这类评论背后往往是：

text 复制代码

流程复杂
操作成本高
用户需要更简单的解决方案

2. 求助型评论

text 复制代码

有没有人知道怎么解决？
新手应该怎么选？
预算有限怎么办？

这类评论背后往往是：

text 复制代码

用户不知道怎么决策
用户缺少知识
用户需要推荐或指导

3. 对比型评论

text 复制代码

这个和另一个有什么区别？
A 好还是 B 好？
有没有平替？

这类评论背后往往是：

text 复制代码

选择困难
信息不透明
需要对比工具或测评内容

4. 场景补充型评论

text 复制代码

我是宝妈，有没有适合带娃用的？
我是小公司老板，这个适合我们吗？
我是新手，能不能不要那么复杂？

这类评论背后往往是：

text 复制代码

细分人群需求
场景化需求
垂直产品机会

所以评论区的价值在于：

它不是直接告诉你"我要什么产品"，但它会暴露用户正在为什么事情烦恼。

而产品机会，往往就藏在这些烦恼里。

三、我要做的插件是什么？

我准备做的第一版插件很简单，暂时不做复杂功能。

它的目标是：

打开一个小红书帖子后，点击 Chrome 插件按钮，自动采集当前页面评论区中已经加载出来的评论，并导出为 JSON 文件。

第一版不追求完美，不追求全自动，不追求抓取全部历史数据。

第一版只解决一个核心问题：

把当前页面里能正常看到、正常滚动加载出来的评论，整理成结构化数据。

四、为什么选择 Chrome 插件？

因为这个场景非常适合浏览器插件。

如果做成普通爬虫，会遇到很多问题：

text 复制代码

登录问题
接口变化
验证码
风控
反爬
cookie
请求签名
合规边界

而 Chrome 插件的思路不一样。

它不是去破解接口，也不是绕过平台机制，而是：

用户自己正常打开页面，插件只读取当前浏览器里已经展示出来的页面内容。

也就是说，第一版插件只做这件事：

text 复制代码

读取当前页面 DOM
滚动加载更多评论
提取评论文本
去重
导出 JSON

这条路线更适合 MVP。

它的优点是：

text 复制代码

实现简单
风险相对低
调试方便
适合个人工具
适合后续接 AI 分析

当然，它也有缺点：

text 复制代码

页面结构变化后需要调整选择器
懒加载评论需要边滚动边采集
如果平台改版，插件可能失效
无法保证抓取全部评论

但对第一版来说，这些都可以接受。

我现在最关心的是：

先把"评论 → JSON → AI 分析"这个闭环跑通。

五、为什么用 opencode 开发？

这次我不准备完全手写代码，而是打算用 opencode 辅助开发。

原因很简单：

我想验证 AI 编程工具在真实小项目里的效率。

现在很多人聊 AI 编程工具，容易停留在两个极端：

一种是神化：

text 复制代码

AI 可以替代程序员。
以后不用写代码了。
一句话生成完整产品。

另一种是否定：

text 复制代码

AI 写的代码不能用。
还是得程序员自己写。
AI 只能写 demo。

我觉得这两种说法都不准确。

更真实的情况是：

AI 编程工具能显著提高开发速度，但前提是你要知道自己要什么，也要能判断它写得对不对。

所以这次我想用一个真实项目来观察：

text 复制代码

opencode 能不能理解需求？
能不能拆分 Chrome 插件项目？
能不能生成可运行代码？
遇到懒加载滚动时会不会犯错？
我该如何给它提示词？
哪些地方必须人工判断？

这比单纯写一篇"opencode 使用教程"更有价值。

六、第一版 MVP 功能清单

第一版插件，我准备只做最小功能。

1. 插件弹窗

点击浏览器插件图标后，出现一个简单弹窗。

弹窗里有几个按钮：

text 复制代码

开始采集评论
导出 JSON
清空数据

同时显示：

text 复制代码

当前页面 URL
已采集评论数量
采集状态
最近几条评论预览

2. 读取当前页面评论

插件会通过 content script 读取页面 DOM。

评论数据先设计成这样的 JSON 结构：

json 复制代码

{
  "id": "自动生成的唯一ID",
  "post_url": "当前帖子URL",
  "nickname": "评论用户昵称，如果无法识别则为空",
  "content": "评论正文",
  "time": "评论时间，如果无法识别则为空",
  "like_count": "点赞数，如果无法识别则为空",
  "level": "top 或 reply",
  "parent_id": "如果是二级回复，记录父评论ID；否则为空",
  "raw_text": "该评论节点的原始文本",
  "captured_at": "采集时间"
}

第一版不要求每个字段都百分百准确。

最重要的是：

text 复制代码

content
raw_text
post_url
captured_at

这几个字段必须能保留下来。

因为后续 AI 分析用户痛点，最重要的是评论原文。

3. 支持懒加载滚动

小红书评论不是一次性全部展示出来的。

它一般是：

text 复制代码

先展示一部分评论
滚动后继续加载更多
部分回复需要点击展开
页面结构可能动态变化

所以插件不能只在最后读一次 DOM。

正确思路应该是：

text 复制代码

滚动一次
↓
读取当前已展示评论
↓
保存到本地数组
↓
去重
↓
继续滚动
↓
继续采集

也就是说：

懒加载页面的数据采集，核心不是"最后读取全部 DOM"，而是"一边滚动，一边采集，一边去重"。

这个会是本系列的重点技术问题。

4. 去重

采集评论时，一定会遇到重复。

去重可以先用：

text 复制代码

昵称 + 评论内容 + 时间

如果昵称和时间识别不到，就先用：

text 复制代码

评论文本 hash

第一版先不追求极致准确，只要避免明显重复即可。

5. 导出 JSON 文件

最后点击"导出 JSON"，插件下载一个文件：

text 复制代码

xhs-comments-YYYYMMDD-HHmmss.json

文件内容是一个 JSON 数组：

json 复制代码

[
  {
    "id": "...",
    "post_url": "...",
    "nickname": "...",
    "content": "...",
    "time": "...",
    "like_count": "...",
    "level": "top",
    "parent_id": "",
    "raw_text": "...",
    "captured_at": "..."
  }
]

这个 JSON 后续可以直接丢给 AI 做分析。

七、这个插件不做什么？

这个边界必须提前说清楚。

第一版不做：

text 复制代码

不破解小红书接口
不绕过登录
不绕过验证码
不绕过风控
不批量抓取多个帖子
不采集用户隐私信息
不做自动化账号操作

它只做：

采集当前用户正常打开页面后，浏览器里已经展示出来的评论内容。

这个边界很重要。

因为我做这个插件的目的不是做爬虫工具，而是做一个个人辅助分析工具。

八、后续真正有价值的是 AI 分析

插件只是第一步。

真正有价值的是后面的分析。

完整流程应该是：

text 复制代码

打开小红书帖子
↓
采集评论
↓
导出 JSON
↓
AI 清洗评论
↓
识别痛点评论
↓
聚类高频需求
↓
输出产品机会
↓
生成内容选题

最终我希望输出一份类似这样的报告：

markdown 复制代码

# 小红书评论痛点分析报告

## 一、评论概况

- 评论数量：
- 有效评论数量：
- 痛点评论数量：
- 高频讨论方向：

## 二、高频痛点

| 痛点 | 出现次数 | 痛点强度 | 代表评论 |
|---|---:|---:|---|

## 三、潜在需求

| 用户痛点 | 对应需求 | 产品机会 |
|---|---|---|

## 四、用户原话

列出最有代表性的评论原文。

## 五、可转化的内容选题

1. 选题一
2. 选题二
3. 选题三

这才是我真正想要的东西。

不是为了抓评论而抓评论，而是为了：

从评论区里找到用户真正关心的问题。

九、为什么这个项目适合做成系列文章？

因为它同时包含了几个很典型的技术和产品问题：

text 复制代码

Chrome 插件开发
Manifest V3
popup 和 content script 通信
DOM 数据提取
懒加载滚动采集
数据去重
JSON 导出
AI 分析评论
opencode 实战开发流程

每一个点都可以单独展开成一篇文章。

更重要的是，这不是一个纯 demo。

它有真实应用场景：

text 复制代码

产品经理可以用它找用户需求
自媒体人可以用它找选题
知识星球运营者可以用它找付费主题
创业者可以用它做需求调研
AI 编程学习者可以用它练项目

所以这个系列不会只写技术，也会写：

text 复制代码

需求怎么拆
提示词怎么写
AI 生成的代码哪里能用
哪里必须人工判断
如何从工具走向产品

十、这个系列准备怎么写？

我准备把这个项目拆成 12 篇文章。

text 复制代码

1. 从小红书评论区挖需求：我准备用 opencode 写一个 Chrome 插件
2. 不要直接让 opencode 写代码：我先让它帮我拆 Chrome 插件需求
3. Chrome 插件开发第一步：Manifest V3、popup、content script 是什么？
4. 用 opencode 生成 Chrome 插件骨架：从空目录到可加载扩展
5. Chrome 插件 popup 和 content script 通信：让按钮控制页面采集
6. Chrome 插件如何读取页面 DOM：从评论节点中提取文本
7. 小红书评论是懒加载的：Chrome 插件如何边滚动边采集？
8. 小红书评论采集插件的 scroll 函数，我踩了哪些坑？
9. 采集到的小红书评论太乱？去重、清洗和字段整理这样做
10. Chrome 插件如何导出 JSON 文件：Blob、downloads API 实战
11. 抓到小红书评论之后，如何用 AI 提炼用户痛点？
12. 用 opencode 开发 Chrome 插件的完整复盘：AI 写代码，真正难的不是代码

第一篇先讲背景和需求。

下一篇开始，我会把这个模糊想法整理成一份 opencode 能理解的开发需求，然后看看它会给出什么方案。

十一、写在最后

这次我想验证的，不只是 Chrome 插件怎么写。

我真正想验证的是：

一个普通想法，能不能借助 AI 编程工具，快速变成一个可运行的小产品？

过去写一个工具，需要自己从零查资料、搭结构、写代码、调试。

现在有了 opencode 这样的 AI 编程工具，开发方式变了。

但有一点没有变：

AI 可以帮你写代码，但不能替你判断需求是否真实。

所以这个系列的核心，不是"AI 多厉害"，也不是"opencode 多神奇"。

而是：

如何把一个真实问题，拆成清晰需求，再借助 AI 编程工具一步步实现。

这才是我觉得 AI 编程真正有价值的地方。

下一篇，我会先不写代码，而是让 opencode 帮我做第一件事：

把"小红书评论采集插件"这个想法，拆成一份真正可执行的 Chrome 插件开发方案。