Afield用买家描述问题的方式搜索
你的产品分类，不一定是买家会使用的词。一个正为现场照片与项目记录对不上而烦恼的人，可能从未搜索过“修复管理软件”。先描述他正在完成什么工作、卡在哪一步。
告诉 Afield 目标人群、问题和需要查看的公开社区，要求附上原帖链接、日期、讨论摘要与相关理由。也说明排除什么，例如供应商广告、其他岗位的教程和重复转载。
先读原帖，再判断它是不是信号
搜索摘要只是入口。作者可能在谈过去的问题、回复别人的提问，或推荐一个已经在用的解决方案。能够访问原帖时，应结合上下文阅读，并把作者原话与研究者的概括分开。
| 研究记录 | 需要保留的信息 |
|---|---|
| 原始背景 | 链接、日期、正在讨论的工作 |
| 具体问题 | 作者描述的困难；需要引用时核对短引文 |
| 人群匹配 | 岗位或公司类型的依据；没有说明就标为未知 |
| 下一步问题 | 开始写作或联系之前，还需要了解什么 |
一条讨论可以改变内容任务
假设某帖讨论整理现场照片耗时，这可能支持一篇照片命名和交接教程，但不能证明发帖人正在购买软件。更适合的访谈问题是：“拍照完成后，到准备报告之前，还要经过哪些步骤？”
这是研究判断示例，不代表系统已经找到某个真实帖子。实际工作中应把原始链接留在内容 brief 中，让写作者能够核对，而不是把多次转述当成证据。
给竞品研究一个公开页面能回答的问题
提供竞品网址，询问页面面向谁、怎样介绍上手过程、价格按什么单位计算、功能声明有什么依据。比较多家公司时，尽量采用同一组问题。
当前页面只能支持当前可见的信息。要说竞品“最近涨价”或“改变了定位”，需要旧版本或带日期的公告。缺少这些材料时，就描述当前价格与定位，不要编造变化趋势。
一次弱结果，怎样继续变成有用的调研
假设你的产品做语音安全，目标客户是 MSP 服务商。直接搜索“声音克隆检测”，返回的却是安全厂商文章和 AI 语音代理接入讨论。它们可能与技术有关，却没有回答 MSP 是否遇到了你关心的客户问题。先保留原任务，判断这一轮为什么搜偏。
下一轮改用买家的工作语言：服务台接到电话要求重置权限，技术人员验证来电者身份，管理员判断哪些请求需要再次确认。先改变关键词，保留 MSP 这个人群；如果同时扩大到其他行业，就把那些结果单独说明，不要让报告悄悄变成泛泛的诈骗研究。
调查 MSP 服务台如何验证电话里提出的敏感操作请求。区分亲历的工作描述和厂商建议。保留能打开的原讨论链接与上下文，说明具体提到了哪一步、还有什么不清楚。相邻讨论可以用来设计访谈问题，不要直接当作采购需求。
读到“我们会回拨客户”时，还要看这句话是谁说的：是在描述自己的流程，给别人提建议，还是回应一个无关问题？如果只是建议，报告应该写“有人提出回拨”，不能变成“该团队已经采用回拨验证”。这一点会直接影响后续文章究竟是在解释现有做法，还是推荐一个待验证的方法。
交付物应该包含查过的来源、相关工作描述、缺口和下一步问题。即使精确匹配仍然很少，也可以完成一份有针对性的访谈提纲：“最近一次电话里提出敏感请求时，你们如何确认身份？验证失败之后怎么处理？”这比直接交付一个 0 更有用，也没有把搜索不到偷换成市场不存在需求。
后续任务由发现来决定。流程缺口适合写操作指南，责任归属不清适合访谈，泛行业新闻只能补背景。不要把新闻文章改一个标签，就当成正在寻找产品的客户名单。
第一轮结果少，先检查搜索方式
先看查询词和来源是否能读取，再判断市场需求。每次扩大一个变量：换买家的日常说法、增加社区或调整日期范围。把相邻主题与准确匹配分开，避免扩大搜索后悄悄降低标准。
研究可以交付有出处的主题，也可以帮助收窄访谈问题、说明哪些来源暂时读不到。不能为了让报告看起来成功，就增加不存在的匹配。