核查 Reddit 产品推荐背后的证据

搜索前先定义证据支持标签

证据等级是一个标签，用于说明某项说法目前有哪些依据。请使用以下四种标签。在表中保留这些名称，方便其他读者使用相同规则。

范围明确的任务有清楚的边界。例如，导入一个文件的范围，就比“某产品能处理所有报表工作”这项说法更小。

给说法添加标签，不要给账号添加标签。一条推荐中，既可能有实用的任务报告，也可能有“该产品最适合所有人”这种缺乏依据的说法。请分行保存。

第四种标签需要特别谨慎地使用。产品官方页面可以支持文档中记载的功能说法，但不能确认 Reddit 作者使用过该功能。你自己的测试可以说明在测试条件下发生了什么，但不能验证作者身份，也不能据此建立普遍适用的产品排名。

不要把这些标签换算成信任分数。更多细节可以让使用报告对某项任务更有用，但不能证明作者更诚实。

设置范围明确的小规模搜索

Reddit 上有一个公开问题：“把 Reddit 作为产品或服务评价的来源，有多可靠？”这个提问为本指南提供了有用的背景。所提供的证据记录了标题，并非对评价可靠性的研究。它也不能说明这个具体问题有多常见。关于评价可靠性的公开提问——于 2026 年 10 月 25 日获取；已核查标题，未记录发布日期。

如果只有几条已知推荐，打开公开来源，手动制表即可。需要更多候选帖子时，再使用采集程序。

Actor 是在托管环境中运行的数据采集程序。Reddit Search Scraper Actor 的文档列出了适合小规模搜索相关帖子的输入字段。Task 是已保存的输入预设。公开的 Reddit Market Research Posts Task 可以作为起点。其页面和准确的 Task ID `c2nOnGXoCJwsOgvdp` 已经过核查，但未验证当前保存的设置。Reddit Market Research Posts Task——于 2026 年 10 月 25 日核查；仅确认页面存在，未验证保存的设置和运行情况。

首次进行小规模采集时，可使用以下建议输入：

{
  "maxResults": 3,
  "query": "recommend reporting software",
  "sort": "relevance",
  "time": "all"
}

将示例 `query` 替换为与你的产品类别和任务有关的词语。首次检查时，将 `maxResults` 保持为 3。这是请求返回的结果上限，不保证会返回三条可用记录。`sort` 请求按相关性排序，并非按推荐的证据质量排序。`time` 请求使用不限时间的搜索选项，但不保证完整覆盖历史内容。

建议输入通过了静态模式检查。模式规定了允许使用的字段和值。静态检查按照这些规定检查输入，不会采集数据。提供的接口规范标明，公开默认构建版本为 2.0.6。本次资料整理未运行 Actor。默认构建版本接口规范——于 2026 年 10 月 25 日核查；仅验证模式，未实际采集数据。

公开帖子和公开 Task 页面属于公开证据。你在自己账号中保存的设置和运行记录是另外的记录。如果运行 Actor，请将这些记录与研究资料一同保存。本指南不含仅账号所有者可访问的运行证据。

按八个步骤建立证据表

1. 写明购买决策问题

说明你需要产品完成什么工作。列出可能改变决策的条件，例如文件类型、任务频率、团队需求或审批要求。

提出一个能通过测试回答的问题。例如，某个工具能否完成你要求的导入，且无需手动修复。“哪个工具最好？”这类宽泛问题无法为判断推荐提供明确标准。

如果需要比较，请说明哪些条件必须相同。与两份互不相关的报告相比，在相同任务和输入下进行比较更清楚。需要定义选择条件时，请参阅产品比较指南。让这张表始终聚焦于每项说法的依据。

2. 采集候选帖子并保留原始记录

保存完整、准确的搜索输入和采集日期。将原始输出与阅读笔记分开保存。不要用自己的结论填补来源中缺失的值。

经过核查的接口规范为这里使用的记录声明了以下字段：

模式允许部分字段的值缺失。`body` 缺失表示正文不可用，不表示这是一条没有亲身体验的陈述。`createdAt` 缺失表示创建日期未知，不能将其视为采集日期。

这些是声明的字段，并非为本指南运行程序后观察到的结果。默认构建版本接口规范——于 2026 年 10 月 25 日核查；仅确认声明字段，未测试实际输出。

3. 阅读问题及相关讨论

将每个采集到的帖子视为需要检查的来源。不要假定记录包含了每条回复，或理解推荐所需的全部上下文。

打开公开来源。阅读这条推荐所回答的问题。检查作者讨论的任务、产品或版本是否与你的购买决策问题相同。

标题可能只是在征求推荐，并不包含任何使用体验报告。回复也可能是在引用另一位作者的话。除来源帖子链接外，如有条件，还应保存该项说法本身的公开链接。

如果无法查看所需上下文，请标记为不可用。不要根据相邻文字或搜索摘要补全该项说法。

4. 区分自述使用和转述建议

找出说明亲自使用的段落。保留足够的原文，以说明作者声称了什么。将作者自己的使用报告与关于他人使用情况的陈述分开。

“试试这个工具”这类推荐没有说明使用情况。“同事在用”则是在报告别人的体验。两者都不能证明作者本人使用过。

仅凭重复措辞无法确定建议的最初来源。如果作者提到更早的来源，请记录该链接。如果来源不明，请保留为未知。不要因措辞相似就推断存在有组织的推广活动。

必要时，将不同说法拆开。关于使用某个工具的陈述，与关于其当前功能的陈述，可能需要分别核查。

5. 记录任务、结果、使用时长和比较依据

对每份使用报告，记录作者做了什么，以及结果如何。保留“一个文件”“一个项目”或“一个团队”等范围限制。

只有在明确说明时才记录使用时长。完成一次任务不能证明使用了数月。较早的发布日期也不能证明作者从那天起一直在使用。

对于比较，请保存比较依据。作者是否使用过两款产品？比较的是否是同一项任务？偏好是否基于已说明的结果？明确保留尚无答案的问题。

在工作表中使用以下字段：

这些笔记用于整理信息，不会成为 Actor 的输出字段。

6. 将关系披露与猜测分开

关系披露是对某种关系的明确说明。如果存在相关文字，请连同来源一起记录。将其与亲自使用的陈述分开。

如果没有关系披露，请写“未说明”。这不代表不存在任何关系，也不能据此指控作者进行了付费推广。

不要根据语气、账号历史或重复建议推断身份、雇佣关系、客户身份或隐藏的关联。你的任务是评估一项说法的依据。

7. 用当前的一手来源核查重要事实

产品的一手来源是产品提供方发布的材料，例如官方文档。请用它核查对决策有重要影响的事实性说法。

保存具体页面、核查日期、相关条件，以及它支持的内容。将“有文档说明”与“经过测试”分开。文档可以说明产品支持某项任务，但不能证明它处理你的文件时会有怎样的表现。

如果没有找到相关文档，请记录“在已核查的来源中未找到”。不要写成该功能不存在。如果说法仍不明确，请保留为未解决，并选择进一步的核查。

这里没有提供竞品事实，也没有提供已完成的产品测试。本步骤描述的是需要读者完成的工作。

8. 选择下一项要测试的任务

对照最初的购买决策问题阅读表格。找出直接依据最少的重要要求。针对该要求核查文档，或进行小规模测试。

开始前，写明测试条件和你需要达到的结果。测试后保存实际结果。计划中的测试不属于已完成的证据。

不要凭票数或提及次数选出优胜产品。多条推荐可能只是在重复同一项缺乏依据的说法。Reddit 研究计数单位指南解释了为什么需要分别处理记录、账号和来源组。这些数量都不能代替任务证据。

逐步分析一个原创虚构示例

本例全部为原创虚构内容。陈述和产品均为虚构。这不是一次 Actor 运行，不是客户结果，也不是对公司实际情况的观察发现。

虚构买家需要每月导入 CSV。CSV 指逗号分隔值，是一种纯文本表格格式。买家需要了解导入后是否需要手动修复。

以下是三条虚构陈述：

1. 推荐 A：“试试 Tool A。”
2. 推荐 B：“我用 Tool B 做过一次月度 CSV 导入。导入完成了，但我必须手动修复日期列。”
3. 推荐 C：“我用过 Tool A 和 Tool B。Tool A 更好。”

卡片 A 提供了一个候选产品，但没有提供任何明确陈述的导入任务使用体验。

对这个购买决策问题而言，卡片 B 提供的报告最具体。它既记录了任务完成，也记录了一项限制。“一次月度 CSV 导入”描述的是一项任务，不能证明使用了一个月，也不能证明在一年内反复导入。这份报告仍未经验证。

卡片 C 说明使用过两款产品，但没有解释“更好”是基于什么任务。请保留这份使用报告，同时将这一宽泛偏好标记为缺少任务细节支持。

这里计算的是卡片数量：1 张建议卡片 + 1 张详细使用报告卡片 + 1 张缺少细节的使用报告卡片 = 3 张推荐卡片。

说明使用过的卡片有 2 张：B 和 C。这表示两张卡片包含使用声明，并不表示有两位经过验证的客户，也不能证明某款产品的用户更多。

在这个虚构示例中，尚未完成任何另行核查，因此已完成的核查数量为 0。这个零描述的是示例中已完成的工作，不代表任何一款产品未通过测试。使用时长仍是“未说明”，而不是零天。

下一步是在当前官方来源中核查所需的导入行为。如果可以进行测试，买家随后可使用获准使用、且具有所需日期格式的样本。建议的测试应检查是否需要手动修复。这里没有提供该测试的结果。

决策前先检查表格

检查表格是否存在以下问题：

1. 正文缺失：将该记录保留为不可用。无法阅读时，不要将其标记为缺乏依据的建议。
2. 上下文缺失：在能够查看问题或回复的上下文之前，将任务适用性保留为未确定。
3. 亲自使用情况不明确：保留原文。不要将建议提升为亲身体验。
4. 使用时长缺失：写“未说明”。不要根据来源日期推断使用时长。
5. 比较过于宽泛：将偏好与具体任务的证据分开。
6. 产品事实未解决：保存已核查的内容。区分“没有文档说明”与“信息不可用”。
7. 来源重复：保留来源链接，避免让同一项说法看起来像是多次独立确认。
8. 采集不完整：说明输入中的数量上限和实际可用的记录数。不要声称覆盖了全部讨论。

请另一位读者按相同规则检查一小部分记录。请对方指出支持每个标签的原文。记录分歧，并明确规则。比较不同读者的判断是否一致，有助于发现不清楚的规则，但不能验证原始使用报告。

限制结论的范围。说明哪项说法对你的任务有帮助、依据是什么、还有什么未知，以及下一步核查什么。不要把表格变成产品排名，也不要用它评判账号。