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

要区分自述的亲身体验和转述的推荐，请检查每项说法有什么依据。查找明确的使用陈述、具体任务、结果、说明的使用时长和清楚的比较。将这些细节与来源一同保存。如果建议没有说明亲自使用过，它对你的任务而言仍是缺乏依据的建议。即使个人使用报告很详细，也仍需另行核查。这些标签描述的是证据，不用于判断作者是否诚实或是否收取报酬。

先亲自阅读公开讨论。与统计提及次数相比，这更有助于回答核心问题。采集程序可以帮助你查找帖子，但不能仅凭一个产品名称就确认作者有亲身体验。

最终应整理出一张推荐证据表。每行记录一项说法、它的依据、局限和下一项核查。用这张表选择需要针对自身需求测试的内容。

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

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

| 证据支持标签 | 适用条件 | 仍未解决的问题 |
| --- | --- | --- |
| 未说明亲自使用的建议 | 作者推荐某个产品，但未说明自己使用过 | 是否亲自使用、执行了什么任务、结果如何 |
| 自述使用过，但任务细节不足 | 作者说明自己使用过，但对相关任务或结果提供的细节太少 | 这份使用报告是否适用于你的需求 |
| 自述使用过，且任务范围和结果明确 | 作者说明了使用情况、具体任务和实际结果 | 能否得到独立确认，以及是否适合你自己的任务 |
| 已另行核查的证据 | 你记录了另一来源或已完成的测试，用于支持某项具体的事实性说法 | 该次核查范围以外的所有事项 |

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 按八个步骤建立证据表

### 1. 写明购买决策问题

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

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

如果需要比较，请说明哪些条件必须相同。与两份互不相关的报告相比，在相同任务和输入下进行比较更清楚。需要定义选择条件时，请参阅[产品比较指南](/zh-Hans/articles/%E7%A0%94%E7%A9%B6reddit%E7%94%A8%E6%88%B7%E6%9B%B4%E6%8D%A2%E4%BA%A7%E5%93%81%E7%9A%84%E5%8E%9F%E5%9B%A0/)。让这张表始终聚焦于每项说法的依据。

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

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

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

| 准确字段名 | 使用本方法时应保留的内容 |
| --- | --- |
| `inputQuery` | 与该记录关联的搜索查询 |
| `requestedSubreddit` | 请求搜索的社区值，如有 |
| `matchedSubreddit` | 匹配到的社区值，如有 |
| `postId` | 来源帖子的标识符 |
| `canonicalPostUrl` | 帖子的标准公开地址 |
| `title` | 帖子标题 |
| `body` | 帖子正文，如有 |
| `createdAt` | 创建时间值，如有 |
| `observedAt` | 观察时间值 |
| `status` | 该记录返回的状态 |
| `unavailableFields` | 返回的不可用字段列表 |

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

这些是声明的字段，并非为本指南运行程序后观察到的结果。[默认构建版本接口规范——于 2026 年 10 月 25 日核查；仅确认声明字段，未测试实际输出](https://api.apify.com/v2/acts/vwOCid7mnPXd0rMTz/builds/default)。

### 3. 阅读问题及相关讨论

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| 表格字段 | 应保存的内容 |
| --- | --- |
| 说法编号 | 你为某一项说法设置的编号 |
| 来源链接和帖子 ID | 公开来源及其标识符 |
| 来源日期 | 发布日期，如已知 |
| 观察日期 | 你查看或采集该来源的日期 |
| 相关问题 | 这条推荐回应的需求 |
| 证据原文 | 支持所用标签的原文 |
| 产品和具体说法 | 该项说法涉及的内容 |
| 亲自使用的陈述 | 说明使用过、未说明使用过，或不明确 |
| 任务和条件 | 所描述的工作及其范围限制 |
| 自述结果 | 作者所说的实际结果 |
| 使用时长 | 说明的使用时长，或“未说明” |
| 比较依据 | 比较的产品和条件，或“未说明” |
| 关系披露 | 明确说明关系的文字，或“未说明” |
| 证据支持标签 | 已定义的证据标签之一 |
| 另行核查 | 如已完成，记录来源、日期、发现和范围 |
| 待解决问题和下一步行动 | 你仍需解决的问题 |

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

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

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

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

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

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

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

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

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

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

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

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

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

不要凭票数或提及次数选出优胜产品。多条推荐可能只是在重复同一项缺乏依据的说法。[Reddit 研究计数单位指南](/zh-Hans/articles/%E6%A3%80%E6%9F%A5%E5%8D%95%E4%B8%AAreddit%E5%B8%96%E6%98%AF%E5%90%A6%E4%B8%BB%E5%AF%BC%E7%A0%94%E7%A9%B6%E7%BB%93%E6%9E%9C/)解释了为什么需要分别处理记录、账号和来源组。这些数量都不能代替任务证据。

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

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

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

以下是三条虚构陈述：

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

| 卡片 | 自述使用情况 | 任务和结果 | 使用时长 | 比较依据 | 证据支持标签 |
| --- | --- | --- | --- | --- | --- |
| A | 未说明 | 未说明 | 未说明 | 未说明 | 未说明亲自使用的建议 |
| B | 明确说明 | 完成了一次月度 CSV 导入；日期列需要手动修复 | 未说明 | 未说明产品比较 | 自述使用过，且任务范围和结果明确 |
| C | 说明使用过两款产品 | 未说明任务和结果 | 未说明 | 列出了两款产品；缺少比较条件 | 自述使用过，但任务细节不足 |

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

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

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

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

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

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

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

## 决策前先检查表格

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

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

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

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

## 从一条推荐确定下一项有用的核查

先选一条与你的购买决策问题有关的重要推荐。保存它的来源和上下文。为其中的说法添加证据支持标签。记录任务、结果、使用时长、比较依据和未解决的事实问题。

如果需要更多候选帖子，请使用建议的小规模输入运行 [Reddit Search Scraper Actor](https://apify.com/chronometrica/reddit-search-scraper)。扩大采集范围前，先检查返回的记录。文档中列出的字段可用于采集数据和追踪来源。你仍需阅读推荐内容并核查其中的说法。

根据缺少的任务证据选择下一步行动。最终应得到一个明确的购买决策问题，以及一项你能完成的核查。

## 来源和延伸阅读

- [关于 Reddit 评价可靠性的公开提问——于 2026 年 10 月 25 日获取；已核查标题，发布日期未知，并非可靠性研究](https://www.reddit.com/r/AskReddit/comments/1kyd9dz/how_reliable_is_reddit_as_a_source_for/)
- [Reddit Search Scraper 默认构建版本 2.0.6——于 2026 年 10 月 25 日核查；提供输入和输出模式证据，无实际运行记录，也无覆盖范围证明](https://api.apify.com/v2/acts/vwOCid7mnPXd0rMTz/builds/default)
- [Reddit Market Research Posts Task——于 2026 年 10 月 25 日核查；已确认准确的 Task ID 和页面存在，未验证保存的设置和运行情况](https://apify.com/chronometrica/reddit-search-scraper/examples/reddit-market-research-posts)