# 用 Reddit 帖子建立客户原话文案库

收集客户语言时，保存简短原话，并一同记录发言者的处境、任务、上下文和来源 URL。将每段引文与你的解读及拟用文案分开。保留“能”“不”“每周”等词。先亲自阅读公开帖子。需要保存更多来源记录时，再使用采集工具。公开的经历描述可以为写作提供参考，但不能据此认定对方为产品背书、确认其客户身份，或证明市场需求。

文案库是一组来源记录和写作笔记。客户原话文案库将人们的原话与赋予这些话含义的上下文放在一起。使用 Reddit 时，除非有其他证据，否则应将客户身份记为未知。

完成后的文案库应让其他读者能追溯每条拟用文案的来源，也应清楚显示哪些内容来自你自己的思考。

## 1. 选择一项任务，明确研究范围

收集原话前，先写下你想了解的工作。选择一项任务及其发生情境，而不是笼统了解人们对产品的感受。

在本指南提供的教学主题中，任务是导出报告。适合的研究范围是与报告列有关的工作，包括重复设置。划定这个范围，可以将关于导出速度的表述与关于重新设置布局的表述分开。

记录以下三项：

1. 你想了解的任务。
2. 使这些表述与研究相关的情境。
3. 你不会收录到此文案库中的表述类型。

例如，你可以收录关于准备报告列的段落，不收录无关的账单讨论。这些是建议的研究选择，并不是关于 Reddit 用户讨论内容的研究发现。

提供的公开问题是：“你们实际如何使用 Reddit 做客户研究？”这个问题需要一套实用方法来回答。不过，现有证据只是保存下来的搜索标题和摘要片段。编写本指南时未核查完整页面。这条记录表明，有人提出过一个相关问题，但不能说明本指南所回答的具体问题有多普遍。[公开的客户研究问题——检索于 2026-08-11；发布日期未知；仅有标题和摘要片段](https://www.reddit.com/r/AIAgentsStack/comments/1ozfd89/how_are_you_actually_using_reddit_for_customer)。

限定用途：收集有用的语言素材，供后续文案核验使用。不要把文案库变成总体情绪评分、功能排名，或证明商业构想能带来销售的证据。

## 2. 建立记录，将来源与你的笔记分开

使用电子表格或其他便于检查的表格。为每段选中的文字建立一张上下文卡片。这张卡片是一条记录，保存引文、来源和你的笔记。

一篇帖子可能包含多段有用文字。如果从同一篇帖子制作多张卡片，每张卡片都应保留相同的来源标识。卡片增加不代表来源帖子或人数增加。

保存以下字段。采集结果可以提供其中一些字段，研究笔记则由你自己添加。

| 字段 | 保存内容 |
| --- | --- |
| 卡片标识 | 你为所选段落指定的固定标签 |
| 来源标识 | `postId` 和 `canonicalPostUrl` |
| 搜索记录 | `inputQuery`、请求的 `sort`、请求的 `time` 以及 `maxResults` |
| 社区背景 | 如有，保存 `requestedSubreddit` 和 `matchedSubreddit` |
| 来源文本 | `title` 或 `body` 中的相关文字 |
| 原话 | 你选中的简短段落，保持原文不变 |
| 上下文 | 足以解释这段原话的前后文字 |
| 来源日期 | 分别保存 `createdAt` 和 `observedAt` |
| 可用情况 | `status` 和 `unavailableFields`，明确保留尚未解决的信息缺口 |
| 发言者处境 | 明确提及的角色或条件；未提及的细节标为未知 |
| 发言者任务 | 发言者描述的工作 |
| 触发因素 | 引发任务或困难的事件 |
| 期望结果 | 明确表达的结果，或清楚标明由你作出的解读 |
| 解读 | 你认为这段话表达了什么，以及理由 |
| 文案假设 | 你自行拟定、准备日后核验的文案 |
| 审核备注 | 检查了什么、还有哪些不明确之处，以及检查时间 |

文案假设是你准备测试的拟用表述。它不是来源引文，也不是经过核实的产品声明。

保持来源文本不变。如果缩短一段文字，应在旁边保存支持它的完整段落。这样，审核者就能检查缩短后的引文是否仍保留原意。

将缺失值视为未知。频率缺失不等于“从不”。耗时缺失不等于零分钟。角色信息缺失，不能证明作者没有采购决定权。发布日期缺失，也不能用观察日期代替。

## 3. 先阅读来源，再选择原话

打开每个相关的公开来源，阅读足够的上下文，以理解所选段落。搜索摘要片段可以帮助你找到候选材料，但其中的文字可能不足以建立一张可正式采用的卡片。

按以下顺序操作：

1. 确认 URL 和来源标识与你正在阅读的帖子一致。
2. 阅读标题和相关正文段落。
3. 确认段落中的话是谁说的。
4. 确认这些话描述的任务、条件和时间段。
5. 选择能保留原意的最短段落。
6. 保存上下文和所有尚未解决的问题。

不要把帖子中引用的他人原话归到帖子作者名下。对问题也要谨慎处理。有人询问导出功能是否正常，并不一定是在报告一次导出失败。

保留限定陈述范围的词。“对我们团队来说”限定了发言者描述的适用范围。“每周”说明情况会重复发生。“我能导出”说明，在这段描述中，导出是可行的。删去这些词可能改变含义。

不要将不同帖子中的片段拼成一段引文。如果写作参考了多个段落，应分别保留卡片，并在解读字段中说明它们的联系。

如果上下文无法确定任务或发言者，就将卡片保留为待处理状态。不要根据你设想的目标客户特征补全信息。

## 4. 需要时，使用 Actor 采集公开帖子

Actor 是托管运行的数据采集程序。[Reddit Search Scraper Actor](https://apify.com/chronometrica/reddit-search-scraper) 文档中列出的输入和输出字段适用于公开数据采集这一步。选择原话、阅读上下文和编写文案库仍需由你完成。

提供的小规模采集输入如下：

```json
{"maxResults":3,"query":"export report columns","sort":"relevance","time":"all"}
```

4. 需要时，使用 Actor 采集公开帖子

这是一份建议输入，并非从已保存的预设中复制而来，也不代表已经完成搜索。它通过了静态模式检查。模式定义了允许使用的字段名称、类型和值。静态检查只将输入与这些规则进行比较，不运行采集程序。

使用前：

1. 将 `query` 的值替换为与你所选任务有关的词。
2. 首次小规模检查时，将 `maxResults` 保持为 3。
3. 检查 `sort`。示例请求的值为 `relevance`。
4. 检查 `time`。示例请求的值为 `all`。
5. 在来源记录旁保存所用输入的完整原样内容。

已检查的模式允许 `maxResults` 使用 1 到 10000 之间的整数。`sort` 允许的值为 `relevance`、`hot`、`top`、`new` 和 `comments`。`time` 允许的值为 `all`、`hour`、`day`、`week`、`month` 和 `year`。

将请求上限设为 3，不代表一定会返回三篇可用帖子。指定时间设置，也不代表能完整覆盖该时间范围。编写本指南时没有运行 Actor。这次检查不能证明实时数据可用，也不能证明采集运行正常。[公开默认构建版本 2.0.6——检查于 2026-10-25；仅有模式证据；未实际运行](https://api.apify.com/v2/acts/vwOCid7mnPXd0rMTz/builds/default)。

文档中的输出字段包括上表列出的来源和日期字段。部分值可能缺失。阅读文本时，一并查看 `status` 和 `unavailableFields`。不要用猜测填补缺失的上下文。

[Reddit Post Customer Language Research Task](https://apify.com/chronometrica/reddit-search-scraper/examples/reddit-post-customer-language-research) 提供了另一个起点。Task 是保存下来的 Actor 输入配置。其公开页面和准确的 Task 标识已于 2026-10-25 核查。目前保存的输入和运行表现仍未核实。使用前先检查设置。不要假定其中保存了这里展示的示例输入。

此次采集针对公开帖子。仅所有者可访问的支持记录、账户数据和私信，应通过另一套获得授权的流程处理。不要将这些记录标为 Reddit 输出。公开发表的文字也不代表你已获准将该发言者用于用户推荐或背书。

## 5. 将情境、解读和拟用文案分开

保存来源后，在单独的字段中添加笔记。

情境说明这些话在什么情况下适用。触发因素说明是什么启动了这项工作。期望结果说明发言者想达到什么目标。这些字段各自都可能是未知的。

每周执行一次任务，并不能说明当前困难由什么引起。抱怨重复设置，也不代表提出了某项具体功能需求。不要仅为让表格看起来完整，就填满所有字段。

用简明的语言写出你的解读，并指出支持解读的原话。如果某个结果是你推断出来的，应将它标为解读，而不是发言者的直接陈述。

然后，用自己的话拟定一条文案假设。清楚区分以下三个层次：

1. 来源：对方写了什么。
2. 解读：你认为这段话表达了什么。
3. 文案假设：你打算日后如何表述。

不要修改引文，使其接近你的文案。不要给自己的概括加上引号。

在公开文案中使用某条表述前，先核实产品能否兑现其中的承诺。描述困难的来源段落不能证明某个解决方案有效。即使尚不清楚产品能否支持，拟用文案也可以保留在文案库中。

## 6. 删除工作不需要的个人信息

保留任务和情境。删除无助于解释原话的个人信息。

为了保存一段关于报告列的原话，工作文案库不需要记录公开用户名。使用卡片标识、来源 ID 和 URL 即可追溯。不要添加联系方式，也不要根据无关信息推断其雇主。

如果所选段落中包含个人信息，尽可能选择更短且保持原文的段落。如果这样会删掉关键含义，就将卡片标为限制处理，或从共享副本中移除。不要悄悄修改文字后，仍将其称为原话。

将来源访问与对外展示分开。可追溯的内部卡片，并不自动适合用于广告或公开客户案例。来源备注应明确说明这一区别。

## 7. 操作示例：两张上下文卡片和一条拟用文案

原创虚构示例。本例中的每篇帖子和每张卡片均为虚构。这不是 Actor 的运行结果、客户结果，也不是实际观察到的公司研究发现。这个两张卡片的示例，与建议输入中设为 3 的上限无关。

第一篇虚构帖子写道：

### 7. 操作示例：两张上下文卡片和一条拟用文案

我能导出报告，但每周重新设置列都要花时间。

保存完整句子。“我能导出”很重要，“每周”也很重要。如果将这段话缩成“无法导出”，就会把部分含义反过来。

| 卡片字段 | 虚构卡片 A |
| --- | --- |
| 原话 | 我能导出报告，但每周重新设置列都要花时间。 |
| 来源 | 虚构帖子 A；没有真实的来源 URL |
| 发言者任务 | 导出报告 |
| 情境 | 每周重新设置列 |
| 触发因素 | 未知；这段话没有解释为什么需要重新设置 |
| 所述耗时 | 提到需要花时间；具体时长未知 |
| 解读 | 这段描述说明，虽然可以导出，但仍需重复设置列 |
| 文案假设 | 保存可重复使用的列布局。 |
| 产品支持情况 | 未核实；该假设不是产品能力声明 |

这条文案假设来自写作者的想法。虚构的发言者并未使用这种表述，也未证明存在这样的功能。

现在加入第二篇虚构帖子，内容是称赞导出速度。将它保存为卡片 B，并单独记录其来源和情境。不要用它抵消卡片 A。导出速度和重复设置列涉及工作中的不同环节。

| 核查单位 | 虚构数量 | 含义 |
| --- | --- | --- |
| 上下文卡片 | 1 + 1 = 2 张卡片 | 这个虚构示例中记录的两段经历描述 |
| 来源帖子 | 1 + 1 = 2 篇帖子 | 每张卡片各有一个虚构来源 |
| 拟用文案 | 1 条文案假设 | 写作者根据卡片 A 提出的一个想法 |
| 已核实的客户 | 未知 | 本例没有确认任何客户身份 |
| 付费意愿 | 未知 | 两张卡片都没有提供付费证据 |

两张卡片不等于两名已核实的买家。它们不能证明多数人的情况，也不能确定某种情况在市场中的发生比例。卡片 A 中未知的耗时不等于零。卡片 B 中的称赞也不能让这个时长变得已知。

对于规模更大的文案库，应[先核对计数单位，再报告数量](/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/)。卡片按卡片计数，帖子按帖子计数。多个选中段落可能来自同一个来源。

## 8. 检查每张卡片，处理证据缺失

在写作说明中使用某张卡片的原话前，先审核整张卡片。

1. 将引文追溯到来源段落和 URL。
2. 逐字核对引文与来源。
3. 检查否定词、条件、时间段和单位。
4. 确认这些话是谁说的，以及涉及什么任务。
5. 将推断出的细节标为解读。
6. 将文案假设保存在引文字段之外。
7. 核实产品能否支持每项拟用承诺。
8. 明确保留缺失值和未厘清的上下文。

卡片未通过检查时，采取以下措施。

| 问题 | 下一步措施 |
| --- | --- |
| 只有搜索摘要片段 | 保留为候选材料，直到能检查足够的来源上下文 |
| 正文缺失 | 记录信息缺口；不要编造段落 |
| 发言者或任务不明确 | 将卡片保留为待处理状态，并说明不确定之处 |
| 缩短引文后含义发生变化 | 补回足够的原文，或放弃使用缩短后的引文 |
| 两条记录存在分歧 | 保留两个版本，使用前先检查差异 |
| 来源已无法访问 | 将此前留存的文字与对应的观察记录一起保存；若未留存，则将问题保留为未解决 |
| 拟用文案承诺了一项未经检查的功能 | 将其保留为未核实的假设 |

除非此前已经留存，否则不要声称恢复了旧来源。来源链接失效，可能使你现在能核查的内容变少。应记录这一限制。

卡片缺少足够的上下文，不能证明任务不存在困难。这只是一条你暂时无法解读的记录。同样，小规模采集中没有找到可用原话，也不能证明客户没有有用的话可说。先判断问题出在查询、来源可用情况，还是你的筛选范围。

## 选择下一条要核验的文案

选择一条与来源有明确联系的文案假设。准备一份简短的写作说明，列出原话、上下文、你的解读和拟用文案。说明哪些信息仍然未知。在公开文案中使用之前，先核实产品能否兑现其中的承诺。

然后，提出一项与真实客户核验文案的计划。将这项未来行动与文案库中已有的证据分开。本指南没有进行客户测试。如果你要判断的是相关问题能否支撑一个商业构想，请参阅另一篇[验证 Reddit 问题假设的指南](/zh-Hans/articles/reddit-%E7%97%9B%E7%82%B9%E9%AA%8C%E8%AF%81/)。

如果需要更多公开实例，先用 [Reddit Search Scraper Actor](https://apify.com/chronometrica/reddit-search-scraper) 做一次小规模采集。检查返回的记录后，再扩大采集范围。有用的结果是一份可追溯的语言素材库，其中清楚说明证据的局限，并明确下一条要核验的文案。

## 来源和延伸阅读

- [Reddit 上公开的客户研究问题——检索于 2026-08-11；发布日期未知；仅保存了标题和摘要片段；未核查完整页面](https://www.reddit.com/r/AIAgentsStack/comments/1ozfd89/how_are_you_actually_using_reddit_for_customer)
- [Reddit Search Scraper 公开默认构建版本 2.0.6——检查于 2026-10-25；证据为输入模式和声明的输出字段；没有实际运行、采集产出或覆盖范围的证明](https://api.apify.com/v2/acts/vwOCid7mnPXd0rMTz/builds/default)
- [Reddit Post Customer Language Research Task——检查于 2026-10-25；已确认公开页面和准确的 Task 标识；目前保存的输入和运行表现未核实](https://apify.com/chronometrica/reddit-search-scraper/examples/reddit-post-customer-language-research)