← 返回文章

如何从 20 万条反馈中形成可验证的需求判断

一套从决策问题、社媒采样、证据整理到产品验证的实操流程

过去一段时间，我先后做了三次大规模用户研究：一次私有算力和本地 AI 设备，一次 AI 眼镜，一次空间显示、3D 与虚拟世界。其中 AI 眼镜那轮收集到 200,732 条原始记录，经过日期、正文完整性、相关性和去重筛选，进入主样本的只有 45,630 条——超过四分之三的材料在入口就被自己的规则拦下了。另一轮保留了 211,088 条“符合初步条件”的反馈，单一平台仍占 90.21%。

研究对象、平台和行业语言差别很大，执行过程却反复撞上同一个问题：数据量迅速增长，能够支持产品决定的证据仍然不足。

这组经历促使我把研究过程重新整理成 SURE：Structured User Research with Evidence。它的核心分析单元是：

用户角色 × 场景与触发 × 任务与结果 × 当前替代方案 × 摩擦与成本 × 后果 × 证据等级

这次更新把方法拆成两种对外版本：

• 这篇文章面向研究者、产品经理和创业者，解释每一步怎样做；
• User Demand Research Agent Skill 面向 Agent，提供固定目录、模板、执行协议和无第三方依赖的审计 CLI。

两者共用同一套证据模型：人类版负责理解和判断，Agent 版负责稳定执行与交接。

下面用一个贯穿案例说明完整流程：

一家公司正在判断，是否值得为现场维修工程师制作 AI 眼镜远程指导原型。

文中的示例记录和数字只用于说明方法，不代表真实行业结论。

先看最终产物

一项完整研究结束时，产品团队需要拿到一组可回查的文件：

repair-guidance-study/
├── study.json                         # 决策问题、假设、证伪条件和质量门槛
├── 01-sources/source-plan.csv         # 来源路线、证据角色、目标和已知偏差
├── 02-data/
│   ├── raw/                           # 原始或授权导入材料
│   ├── views/                         # 配平后的分析视图
│   └── evidence.jsonl                 # 可被结论引用的证据记录
├── 03-codebook/
│   ├── codebook.csv                   # 分类定义和版本
│   └── gold-set.jsonl                 # 人工校准样本
├── 04-findings/demand-judgments.json  # 需求判断、反证和下一项验证
└── 05-audit/                          # 质量检查结果

其中最重要的产物是一条能够被复查的需求判断。例如：

对于需要双手操作设备的现场维修工程师，在复杂拆装步骤中取得准确指导是一项明确任务。目前常用手机、纸质手册或远程语音指导，操作中断与沟通往返会延长维修时间。现有材料已支持问题与替代方案证据；是否接受 AI 眼镜、谁愿意付费、能否持续使用仍待验证。

这段判断写清了已经观察到的内容、证据能走到哪一步、下一步缺什么，没有急着宣布产品机会。

第一步：把研究题目改成一个产品决定

下面这种题目无法指导采样：

研究 AI 眼镜在维修行业的用户需求。

研究范围会不断扩张，任何材料都能被认为有关，最后得到的往往是一份内容丰富、却无法决定下一步的报告。

可执行的研究契约需要写清五项内容：

项目	维修案例中的写法
决策问题	9 月 30 日前决定是否制作现场维修远程指导原型
当前选项	做 AI 眼镜原型；继续优化手机方案；暂停该方向
目标角色	一线维修工程师、远程专家、采购负责人、IT 与安全审核者
最低证据	任务与替代方案、方案接受、付费或部署行为、拒绝与反例
禁止推断	不用便利样本估算市场比例，不把评论条数写成用户人数

每个核心假设还要配一个可观察的证伪条件。

假设：

维修工程师在双手被占用时，需要持续获得可视化指导。

证伪条件：

如果目标任务能够在 30 秒内用手机或语音完成，且概念测试中没有出现对免手持方案的明确接受，则停止当前形态的原型投入。

证伪条件提前写下后，数据才有机会改变决定。否则研究很容易成为对既有想法的补充材料。

第二步：按“材料能证明什么”设计来源

搜索 AI glasses、smart glasses 或 AR glasses，主要会找到产品用户、爱好者、评测者和发布讨论。它们适合研究已有方案的体验，却看不到大量没有使用产品词的任务。

维修工程师可能只会说：

• 拆机时需要反复停下来查手册；
• 远程专家看不到自己正在操作的位置；
• 戴手套时使用手机困难；
• 某些工厂禁止拍摄或外传数据；
• 当前语音加图片的办法已经够用。

因此，来源计划应覆盖五类证据角色。

证据角色	维修案例中可以寻找的材料	主要回答的问题
直接方案反馈	AI 眼镜、远程协作设备、企业部署反馈	方案哪里可用、哪里失败、接受条件是什么
开放场景	维修论坛、工单复盘、培训社区、操作规程讨论	用户在什么时刻完成什么任务
替代与拒绝	手机视频、平板、纸质手册、语音指导、退货与拒绝部署	现有办法是否足够，为什么不换
购买后与支持	部署工单、设备故障、续航、网络、安全与维护记录	使用后能否稳定运行，成本落在哪里
对照样本	对手机或语音方案满意的团队、无需远程专家的任务	哪些场景缺少问题，哪些市场无需进入

来源数量不等于来源多样性。十个科技论坛可能仍然聚集着相似的人；五个平台上的发布评论也可能来自同一批产品爱好者。

研究计划需要为每条路线标明：它承担哪种证据角色、目标记录数、单一路线占比上限、访问状态和已知偏差。

一旦替代与拒绝样本为空，继续增加产品社区评论无法修复缺口。此时应更换搜索入口，或明确写出当前结论缺少反证。

第三步：先试采集，再决定是否扩量

正式采集前，先从每条路线取得一小批材料。试采集的目标是判断路线质量，数量根据平台和材料形态确定。

每条路线至少记录以下结果：

指标	它帮助判断什么
触达记录数	路线的大致规模
正文完整率	能否保留上下文和原话
筛选后有效率	这条路线是否值得继续投入
唯一主题或产品数	是否被一个热门讨论支配
重复率	转帖、搬运和相同回复是否过多
E3–E5 产出	能否找到方案接受、付费和持续使用证据
拒绝与对照产出	能否看到产品不成立的情况
时间集中度	是否受到一次发布、故障或争议影响
访问限制	是否遇到登录、验证码、403、429 或平台限制

假设某条产品发布评论路线取得 500 条记录，却有 70% 来自同一个发布周，且几乎没有退货、部署和长期使用材料。这条路线适合观察发布反应，不适合承担长期需求判断。

当一条路线无法提供它被分配的证据，应重新设计路线。研究者需要保留失败和被阻断的来源，避免后来的人把数据空白理解成“没有问题”。

平台数据怎么接：先审开源代码，再决定能不能抓

这套系统采用一组可以检查、修改和替换的开源连接器。连接器负责把平台数据送进统一格式，研究方法负责采样、判断与审计。

但“GitHub 上有代码”和“这条路线可以用于研究”是两件事。选择一个开源项目，要连续通过四道检查：

检查	需要回答的问题
代码	有没有明确许可证，能否固定到具体 commit，依赖是否可审计
访问	实际使用官方 API、公开数据集，还是模拟登录、内部接口和网页抓取
数据	这项研究能否保存、刷新、删除和使用返回的数据
研究	输出是否保留讨论串、对话、视频、商品变体或项目等关键层级

MIT 许可证只回答第一道问题。它允许怎样使用代码，不会自动授予平台访问权，也不会自动授予评论和用户内容的再利用权。

截至 2026 年 8 月 27 日，我把审查结果整理成下面这张表：

平台	可复用的 GitHub 项目	当前结论	适合做什么
Reddit	PRAW	可用，但需要获准的 Reddit Data API 访问；现有 API 应用须在 2026 年 9 月 30 日前登记，长期将迁移到开发者平台	帖子、评论、讨论串和 subreddit 路线
X	Tweepy	可用，但必须走官方 X API	历史/近期检索、对话、回复、引用和转发
YouTube	Google API Python Client	可用，但受 Data API 配额与数据规则约束	视频检索、频道与视频信息、评论线程和回复
Amazon	AmazonReviews2023	只适合历史研究	截至 2023 年 9 月的评论、ASIN、评分、购买验证和商品信息

另外一些项目代码本身并不差，却不能进入默认采集链路：

• X 的 snscrape 和 twikit使用非官方抓取或内部接口，而 X 当前规则要求官方 API；
• YouTube 的 youtube-comment-downloader 和 youtube-transcript-api都绕开了 Data API，而 YouTube 当前政策禁止直接或间接取得抓取数据；
• 京东的 JD_comment_spider多年未更新，仍依赖旧的直连接口；
• 淘宝的 taobao-review-playwright需要扫码登录、保存登录态并模拟用户操作；
• Kickstarter 的 KSInsights保留了结构化数据，但仓库最新快照停在 2025 年，数据又来自网页爬虫。

这些项目被保留在“已审查、不可启用”的清单中，让下一个 Agent 搜索 GitHub 时能直接看到此前的判断和原因。

社媒平台：连接器相同，样本结构不同

三个社媒平台仍然共用一条研究流程：

确定证据角色
→ 选择通过审查的开源连接器
→ 固定代码版本和访问依据
→ 建立平台检索路线
→ 小批量试采集
→ 保存采集 manifest 与平台层级
→ 整理成 SURE 证据记录
→ 检查集中度
→ 用独立来源验证

每次采集都要生成一份 manifest，记录连接器、固定 commit、许可证、访问依据、数据权利、检索式、请求/触达/写入数量、配额、警告和停止原因。API 密钥、Cookie 和账号信息不能写进 manifest。

Reddit：把社区和讨论串当成样本结构

使用 PRAW 不代表可以无限取数。研究仍需先确认 API 用途、速率、保留和删除规则。每条路线至少记录：

subreddit × 检索主题 × 原始检索式 × 排序 × 时间范围 × 帖子/评论 × 历史/监听

2026 年 8 月，Reddit 公布了公共 Data API 的调整计划：已有的 API 应用必须在 2026 年 9 月 30 日前完成登记，新的自助申请入口已经关闭、改为审批制，长期方向是迁移到开发者平台。对研究系统的含义是：已经持有获批访问的研究可以继续用 PRAW，但没有获批凭据的研究要把 Reddit 记为访问缺口，而不是换成抓取工具。

同一个问题应分别观察 relevance、new、top 等视图。热门排序适合发现重要讨论，时间排序更接近近期基线。十个 subreddit 仍属于同一个来源家族，同一讨论串里的五十条评论也不是五十次独立确认。

X：把转发和事件扩散从需求中拆开

Tweepy 负责调用官方接口，研究文件还要保留：

检索主题 × Boolean 检索式 × recent/full-archive × 起止时间 × 语言 × 原帖/回复/引用/转发

原帖、回复和带新文字的引用可能包含新的证据；单纯转发主要说明传播，只能作为 E0 注意力信号。一次发布会在一天内产生大量转发，不能据此得出需求突然扩大。X 研究要同时检查唯一对话数、转发占比和单日记录占比。

YouTube：先抽视频，再抽评论

YouTube 研究先决定哪些频道和视频进入样本，再决定每个视频读取哪些评论。频道可以分成产品评测、任务与职业、替代与批评、部署与支持、主流对照五组；每个视频设置评论上限，避免一条爆款视频决定全部结论。

官方 commentThreads.list支持按时间或相关性读取评论线程，两种排序要分开记录；线程返回结果也不一定包含全部回复。评论还要标记它在评价产品、任务、创作者、视频制作，还是另一条评论。Great video 通常只能说明内容受到认可。

电商与众筹：目前的空白也要写进结论

Amazon Reviews 2023 可以用来开发历史评论解析、商品变体采样和代码本，但不能回答当前商品、当前价格或当前竞争变化。每条结论都应明确写“历史材料截至 2023 年 9 月”，并用访谈、用户提供的当前记录或现场观察验证它是否仍然成立。

对于 Amazon 实时评论、京东、淘宝/天猫和 Kickstarter，目前没有找到可以作为默认能力的第三方开源连接器。遇到这种情况，研究系统应该：

1. 保留原本想研究的品类、商品或项目路线；
2. 记录审查过的仓库和失败在哪一道检查；
3. 把这条路线标为 blocked；
4. 改用访谈、参与者主动提供的购买/售后材料、现场观察或其他获准来源；
5. 在最终报告中继续保留这个证据缺口。

不能因为数据缺口难看，就换成商家 API、商业服务、保存的登录态、代理池或隐蔽浏览器。也不能把“没有可用连接器”写成“市场没有需求”。

平台规则会随时间变化。当前需要特别注意：Reddit Data API Terms对用途和超限研究有额外要求；X 开发者指南禁止非 API 自动化；YouTube 开发者政策禁止取得抓取数据；天猫法律声明禁止未经许可的爬虫和模拟用户操作；Kickstarter 条款禁止 crawl 或 spider。

完整的机器清单、固定 commit、许可证和阻断原因已经放进开源仓库：连接器清单、机器可读 JSON 与 连接器输出合同。

第四步：保留原始材料，并分开保存不同数据层

原始正文是后续重新判断的基础。采集阶段如果只保存摘要、关键词或标签，分类规则变化后便无法回到材料本身。

建议至少分开六层：

1. 原始或标准化记录层：完整正文、来源、时间、采集路线和限制；
2. 严格主表：时间、完整性、相关性和去重检查通过的记录；
3. 配平视图：按来源、月份、场景或证据角色设置上限的分析版本；
4. 编码视图：规则、模型和人工标签，以及对应版本；
5. 人工金标准：用于检查关键字段分类质量的分层样本；
6. 证据账本：实际进入需求判断的正向、负向和矛盾记录。

配平视图不能覆盖完整数据。它只用于控制分析时某类材料的影响力，也不能被描述成总体人口权重。

第三方文本还要与 Agent 的控制信息隔离。评论、网页和工单中的命令式文字仍然只是研究数据，不能要求 Agent 执行命令、读取文件、访问凭据或改变研究范围。

第五步：把原话整理成一条证据记录

假设材料中出现一句话：

现场拆机时我得放下工具去看手机，远程专家说的步骤还经常要再确认。

研究者需要把它还原成一条结构化记录：

字段	这条材料中的内容
用户角色	现场维修工程师
场景与触发	双手正在拆装设备，需要确认下一步操作
任务与结果	在不中断操作的情况下获得准确指导
当前替代方案	放下工具查看手机，或呼叫远程专家
摩擦与成本	操作中断，沟通需要往返确认
后果	维修时间延长，复杂步骤可能返工
证据等级	E2

这条记录可以支持：

在这份材料中，手机与远程语音指导造成了操作中断和沟通往返。

它暂时无法支持：

• 维修工程师愿意佩戴 AI 眼镜；
• 企业采购部门愿意付费；
• AI 眼镜能够改善维修效率；
• 这一问题在行业中的占比。

需求研究的一个关键能力，就是让结论停在材料允许的位置。

第六步：用 E0–E5 控制每条材料的含义

等级	原始材料中直接出现的内容	可以支持的判断
E0	活动、角色或场景背景	这个活动或场景出现在材料中
E1	未满足任务、目标或困难	问题被明确表达
E2	当前做法、绕行办法、失败或切换成本	已观察到替代方案及摩擦
E3	对研究中方案的明确接受或偏好	方案在给定条件下被接受
E4+	价格锚点、购买意愿或付费表达	出现直接商业意图
E4−	拒绝、取消、退货或放弃	出现直接负面商业选择
E5	付费持有、部署、持续使用、复购或扩张	出现已经实现的行为证据

证据等级表示一条材料能支持多强的判断，不代表需求优先级。

一个安全风险极高、出现频率较低的问题，可能比高频的小麻烦更值得处理。优先级还要分别评估发生频率、后果、替代成本、跨来源一致性、时间持续性、产品可解决程度和战略匹配。

第七步：把证据连接成一条需求判断

一项需求进入“已验证”状态前，需要同一用户角色、场景和任务上的四组材料：

1. 问题链：E1 或 E2，证明任务和当前做法的摩擦；
2. 方案链：E3，证明研究中的解决方式获得明确接受；
3. 商业或行为链：E4+ 或 E5，证明付费、部署或持续使用；
4. 反证：E4−、满意替代方案、问题不成立的场景或矛盾材料。

回到维修案例，当前只有前面那条 E2 记录时，需求判断应写成：

状态：needs-validation

已经观察到：
- 目标任务和触发场景
- 手机与远程语音的操作中断
- 维修时间延长和返工风险

仍缺少：
- 工程师对免手持方案的 E3 接受证据
- 采购、部署或持续使用的 E4+/E5 证据
- 安全、隐私、舒适度和现有方案满意者的反证

下一项低成本验证：
- 用可点击原型和佩戴模型完成 8—12 次场景化概念测试
- 预先记录接受条件、拒绝原因和继续使用意愿
- 若多数目标任务仍需拿起手机，且出现明确 E3 接受，再进入短期现场试用

这里的 8—12 次 是示例规模，用于快速发现接受条件和明显拒绝原因。

第八步：机器扩大阅读范围，人负责校准关键判断

几十万条材料需要规则或模型参与去重、候选场景发现、初步分类和复核排序。自动结果不能直接成为事实。

关键字段应建立人工金标准。抽样时覆盖：

• 不同来源家族；
• 不同月份和事件窗口；
• 五类证据角色；
• 正向、负向与中立材料；
• 高置信和低置信记录；
• 高频标签与稀有但后果严重的标签。

决策相关字段可以让两位标注者独立判断一部分记录。Cohen’s kappa 或 Krippendorff’s alpha 低于预设门槛时，先检查定义、边界和示例。更大的模型无法自动修复含糊的分类规则。

每条自动编码结果还应保留模型、提示词或规则版本、代码本版本、置信度和人工复核状态。来源结构发生明显变化后，需要重新校准。

第九步：在形成结论前完成一次质量审计

一份研究报告至少要公开以下信息：

• 原始记录数、严格主表记录数和配平视图记录数；
• 来源家族、平台、月份、事件窗口和唯一讨论的分布；
• 五类证据角色的覆盖情况；
• E0–E5 与拒绝证据的分布；
• 重复、正文缺失、日期不精确和无法追溯来源的比例；
• 人工金标准的关键字段表现；
• 被阻断或失败的来源路线；
• 当前材料明确不能支持的判断。

质量门槛应写进研究契约。下面是一组演示配置：

试研究最低有效记录：30
必须覆盖：五类证据角色
单一来源家族占比上限：65%
标准化文本重复率上限：2%
validated 判断：必须包含反证记录

真实项目的门槛，应根据决策风险、材料形态、来源可得性和时间窗口重新设定。

第十步：根据风险选择小样本或大样本路径

这套方法不要求每次都抓取几十万条数据。

小样本路径

适合已有明确用户、材料量较少或产品决定临近的项目：

1. 完成研究契约；
2. 从五类证据角色各找一批材料；
3. 人工编码 30—100 条高相关记录；
4. 形成 3—5 条需求判断；
5. 直接进入访谈、观察、概念或价格测试。

大样本路径

适合跨行业场景发现、长期用户反馈、复杂品类或大量工单：

1. 对每条来源路线做试采集；
2. 保存原始层、严格主表和配平视图；
3. 用规则与模型做开放发现和初步编码；
4. 用人工金标准校准关键字段；
5. 审计来源集中、时间事件、重复和证据角色；
6. 将高优先级判断送入更便宜的直接验证。

两条路径的判断门槛相同。大样本增加了覆盖范围，也增加了偏差审计、数据治理和复现成本。

数据抓到什么时候可以停

研究应在开题时写下停止条件。可以考虑同时满足：

• 严格主表通过质量检查；
• 关键证据角色和目标市场没有无法解释的空白；
• 单一来源或事件窗口没有超过预设上限；
• 新增材料带来的新场景连续下降；
• 关键字段经过人工校准；
• 下一项产品决定已经能够在声明的置信度下作出；
• 继续采集的成本高于一次访谈、概念测试或现场试用带来的信息价值。

如果二十万条材料里没有拒绝者、满意替代方案、付费者和持续使用者，研究仍有关键缺口。继续增加同类评论只会让原有偏差更稳定。

今天就可以开始的 90 分钟版本

第一次使用这套方法，可以只完成 Design 阶段：

1. 用 20 分钟写清决定、选项、负责人、时间和禁止推断；
2. 用 20 分钟写三条核心假设，以及每条假设的证伪条件；
3. 用 30 分钟为五类证据角色各列两条来源路线；
4. 用 10 分钟设置试研究的重复、集中度和覆盖门槛；
5. 用 10 分钟评审：这份计划能否主动找到拒绝、放弃和满意替代方案。

完成后再决定是否需要爬取大量数据。很多研究在这 90 分钟里就能发现，原计划只能接触产品爱好者，或根本没有准备商业与行为证据。

交给 Agent 执行

公开的 User Demand Research 仓库包含：

• 可安装的 $user-demand-research Skill；
• 研究契约、来源计划、代码本和需求判断模板；
• sure.py init 研究目录初始化命令；
• --platform reddit|x|youtube|amazon|jd|taobao|kickstarter 平台路线初始化参数和专用审计；
• 一份机器可读的 GitHub 开源连接器清单，包含固定 commit、许可证、可用状态与阻断原因；
• Design、Evidence 和 Full 三个阶段检查；
• 一套完整合成案例和自动测试。

Agent 版本采用 Skill + CLI。Skill 负责研究判断、安全边界和失败处理；CLI 负责目录、连接器选择、字段、重复、来源集中和证据链等确定性检查。连接企业工单、数据库或获得授权的平台 API 时，可以再增加 MCP 适配器，研究数据合同无需改变。

安装后，可以直接要求 Agent：

使用 $user-demand-research，为“维修工程师是否需要免手持远程指导”建立研究目录。
先完成 Design 阶段，写明假设、证伪条件、五类证据来源和质量门槛；
通过 design check 后再给出试采集计划。

这套方法最后要解决什么

大规模反馈的价值，在于让低频、分散和高后果的问题有机会出现，也让研究者能够观察不同来源与时间中的稳定模式。研究质量取决于更具体的事情：问题是否对应一个真实决定，材料是否承担了不同证据角色，拒绝和满意替代方案是否进入判断。当这些条件写进文件、门槛和交接协议后，研究才容易被复查、继续和推翻。

数据量可以很大，也可以很小；每一条需求判断都应当说清自己从哪里来，还缺什么。