
直接回复回应的是你那条特定评论。更深层回复回应的是该评论下的另一条回复。阅读对话时,两者都可能有用,但它们属于不同的结果。
本指南介绍如何制作经过核验的直接回复表。采集工具提供公开记录。你需要核对帖子、确认自己的评论,并判断哪些记录应纳入表格。
1. 确认 Spotlight 和你自己的评论
读者的问题很具体:如何找到别人对自己在 Snapchat Spotlight 上所留评论的回复?提供的这条公开读者提问,检索于 2026 年 8 月 11 日;仅有一条提问直接提出了这个问题。它无法说明有多少用户遇到了同样的问题。
如果你能打开已知的 Spotlight 并找到自己的评论,就先从那里开始。阅读相关的公开交流内容。当你想理解一条回复,或决定是否回应时,人工核对很有用。如果只是阅读已经能找到的交流内容,就不需要导出文件。
要得到经过核验的导出结果,请在采集前确认以下前提条件:
- 保存公开 Spotlight 的 URL,也就是它的网址。
- 保存你那条评论的准确 ID。
- 保留能证明该评论属于指定 Spotlight 的证据。
- 保留能证明该评论属于你的账号的证据。
如果已有经过核验的记录,请使用该记录。本指南没有确立从通知中获取未知评论 ID 的方法,也不提供针对文档未说明的 Snapchat 界面的操作步骤。
措辞相似不足以确认哪条评论是你的评论。仅凭显示名称也不够。如果保存的证据无法确认评论身份,请停止查找该目标。增加记录行数无法解决目标身份未确认的问题。
公开评论记录与仅账号所有者可见的记录也不同。文档说明,该工具采集对外公开可见的评论和回复。其规范不提供私信或通知。不要将公开导出文件视为账号私密活动的副本。公开 Actor 规范,核对于 2026 年 10 月 25 日;仅限文档列出的字段。
2. 如有需要,设置一次小规模公开数据采集
Actor 是托管运行的数据采集程序。Chronometrica Snapchat Comments Scraper 接受已知的公开 Spotlight URL。其 `includeReplies` 设置用于请求采集公开回复,每条回复作为单独的付费记录行。该设置默认为 `false`,因此使用本方法时要将其设为 `true`。公开输入规范,核对于 2026 年 10 月 25 日;未进行运行测试。
使用以下提供的输入格式:
{
"includeReplies": true,
"startUrls": [
"https://www.snapchat.com/@mrbeast/spotlight/W7_EDlXWTBiXAEEniNoMPwAAYbHZzZmtrYm1jAZhMOQmTAZhMOQfqAAAAAQ"
]
}将示例地址替换为你已知的公开 Spotlight URL。示例展示了有效的输入格式。它并未指明你的帖子,也不能证明你的评论出现在其中。本指南没有实际执行采集。
先从一条帖子开始。经过核对的公开输入结构规范没有用于限制每条帖子记录行数的输入项。结构规范定义可接受的字段及其类型。行数上限用于限制一条帖子的最大记录数。不要添加结构规范未列出的输入字段。
准备运行前,先查看可用的费用控制选项。将实际使用的完整输入与所有导出记录一起保存。这样可以保留你请求的内容,但不表示你已获得所有可用回复。
Task 是已保存的输入预设。公开的 Snapchat Spotlight 评论与回复 Task,核对于 2026 年 10 月 25 日;仅确认页面存在确实存在。尚未通过已登录账号核对其保存的设置,也未运行该 Task。使用前请核对输入。
3. 保存核对每条回复所需的字段
一行就是导出文件中的一条记录。分类前,先保存原始记录行。保留足够的信息,以便将每行关联到请求采集的帖子及其准确的父评论。
父评论是某条回复所回应的那条特定评论。深度表示评论在对话中的层级。深度能提供上下文,但决定回复是否直接回应目标评论的是父评论 ID。
当前输出规范列出了以下字段。规范列有这些字段,并不能证明某次实际采集会提供完整的上下文。公开输出规范,核对于 2026 年 10 月 25 日;仅限文档列出的输出。
| 字段 | 需要保留和核对的内容 |
|---|---|
| `inputUrl` | 提交给采集程序的网址。 |
| `postUrl` | 返回的公开帖子网址。 |
| `snapId` | 返回的 Spotlight ID。核对它是否对应指定帖子。 |
| `commentId` | 用于标识每条不同评论的评论 ID。 |
| `parentCommentId` | 用于判断是否为直接回复的准确父评论 ID。 |
| `depth` | 记录的对话层级。保留它作为上下文信息。 |
| `text` | 供人工阅读的评论正文。 |
| `authorId` | 作者 ID(如有)。缺失时保留缺失状态。 |
| `publishedAt` | 评论发布时间(如有)。 |
| `observedAt` | 观测到该记录的时间。 |
| `status` | 返回的记录状态。保留原值。 |
| `statusReason` | 返回的状态说明(如有)。 |
| `replyCount` | 回复数量。该字段不提供回复记录本身。 |
| `postCommentCount` | 帖子的评论数量(如有)。该字段不能证明导出结果完整。 |
发布时间和观测时间回答的是不同的问题。前者说明评论何时发布,后者说明何时看到该记录。不要用观测时间替代缺失的发布时间。
区分缺失值和零。父评论 ID 缺失,表示父评论关系尚未确定,不表示该评论没有父评论。数量缺失表示数量未知。记录中的零则是一个数值。
你可以自行添加目标 ID、判定、原因和来源引用等列。请将这些列标注为你的核验字段。它们不是 Actor 原生的输出字段。来源引用应能定位到原始导出记录行,并保留其公开帖子链接。不要编造评论的直接访问 URL。
4. 为已知评论 ID 建立统一索引
索引是一张查找表。在本任务中,它将每个已知的 `commentId` 关联到已保存的记录。将重复观测另存于观测日志。一次观测,是指一条记录在导入文件中出现一次。
按以下步骤操作:
- 核对返回的帖子身份是否与指定的 Spotlight 相符。
- 在索引中,每个不同的评论 ID 只记录一次。
- 在观测日志中保留每次导入的观测。
- 将重复观测关联到已有的索引条目。
- 保留已保存并经过核验的目标评论及其身份证据。
- 如果记录所需的身份或父评论关系仍未得到证实,请暂缓判定该记录。
不要将重复观测计为额外回复。如果同一条回复在文件中出现两次,它仍只对应一个唯一评论 ID。
后续导出文件可能只覆盖公开对话的一部分,因此可能不含你的目标评论。这种缺失不能推翻此前保存的身份确认结果。请保留早先经过核验的记录及其证据。关键是目标评论的身份是否仍然得到确认。
如需了解如何分别保存请求采集的帖子、去重后的记录行和导入的观测记录,可参阅 TikTok 评论数据集指南。其中的产品设置适用于 TikTok。不要将这些设置复制到此处的 Snapchat 输入中。
5. 根据准确的父评论身份纳入回复
对每条候选记录使用相同的判定规则。先核对 Spotlight,再核对父评论 ID。最后,确认纳入结果的评论 ID 在结果中只出现一次。
| 核验记录中的证据 | 你的核验判定 |
|---|---|
| 已确认属于指定 Spotlight,且父评论 ID 等于你已核验的评论 ID | 作为直接回复纳入结果。 |
| 父评论 ID 等于一条已纳入结果的回复的 ID | 保留为深层上下文。 |
| 父评论 ID 指向另一条分支 | 与目标评论的回复分开保留。 |
| 父评论信息缺失或尚未得到证实 | 保留为待确认。 |
| Spotlight 身份不符 | 从本次目标查找中排除。 |
| 你的目标评论身份尚未确认 | 暂停整个目标查找。 |
这些是读者自行作出的核验判定,不是文档为 Actor 的 `status` 字段定义的值。
不要只筛选深度为一的记录。你自己的评论可能已经是一条嵌套回复。在这种情况下,对你的直接回复可能位于更深的层级。准确的父评论关系仍能正确识别这类回复。
不要根据行顺序、相似措辞或相邻的显示名称推断父评论。电子表格可能将无关记录排在一起。相邻位置不能证明存在对话关联。
Facebook 未获回复问题指南说明了当问题位于评论串中时,准确的评论关系为何重要。该指南核验品牌是否作答的流程用于另一项任务。在这里,你只需判断哪些已观测记录直接回复了你经过核验的评论。
结构关系相符也不能确定内容含义。在决定如何回应前,请阅读正文和相关公开上下文。本方法识别的是记录之间的关系,不会自动解读或发布回复。
6. 逐步分析一个原创虚构示例
原创虚构示例。本例使用虚构 ID,不含实际采集的 Snapchat 数据或私密账号数据。它用于说明你的核验表,并非经过验证的实际运行输出。
假设已知的 Spotlight 为 S1。你已确认的评论为 T2。它的父评论是 ROOT,深度为一。ROOT 是本例中虚构的评论 ID。
下方所有记录行都属于 S1。在这个虚构练习中,已核对它们的帖子身份。
| 评论 ID | 父评论 ID | 深度 | 核验判定 | 原因 |
|---|---|---|---|---|
| T2 | ROOT | 1 | 已核验的目标 | 保存的证据确认这是你的评论。 |
| R1 | T2 | 2 | 直接回复 | 它的父评论是目标 T2。 |
| R2 | T2 | 2 | 直接回复 | 它的父评论是目标 T2。 |
| D1 | R1 | 3 | 深层上下文 | 它回复的是 R1。 |
| O1 | ROOT | 1 | 其他分支 | 它与 T2 具有相同的父评论,但并未回复 T2。 |
| M1 | 缺失 | 缺失 | 待确认 | 它的父评论关系尚未得到证实。 |
M1 的深度缺失,描述的是本虚构示例中一条不完整的核验记录。这并不表示当前输出结构规范允许深度为空值。该规范将 `depth` 定义为整数。
R1 和 R2 通过核验,因为它们的父评论是 T2。深度为二不妨碍它们成为直接回复。D1 位于 R1 下方,因此提供更深层的上下文。O1 属于另一条分支。
只筛选深度为一的记录,会漏掉这两条直接回复,还会纳入并未回应 T2 的 O1。因此,应由父评论身份决定是否纳入结果。
现在假设导入文件中多出一份 R1 的副本。请同时列出以下两个总数:
7 次导入观测 − 1 次重复观测 = 6 个唯一评论 ID。
对这六个唯一 ID 进行分类:
1 条目标评论 + 2 条直接回复 + 1 条更深层回复 + 1 行其他分支记录 + 1 行待确认记录 = 6 个唯一评论 ID。
直接回复结果包含两个唯一评论 ID:R1 和 R2。这不是两个人的计数。本练习并未确认它们是否来自不同作者。
交付 R1 和 R2 时,附上它们的来源记录行引用和已知 Spotlight 的引用。将 D1 保留为深层上下文。单独保留 O1。将 M1 保留为待确认。如果无法确认 T2 的身份,请暂停整个查找。
7. 核对结果并说明其局限
确认表格可用前,请完成以下核对:
- 确认目标 ID 仍与保存的身份证据相符。
- 确认每条纳入结果的回复都属于指定 Spotlight。
- 确认每条纳入结果的回复的 `parentCommentId` 都等于目标 ID。
- 确认每个纳入结果的 `commentId` 在结果中只出现一次。
- 确认每条纳入结果的回复都有来源记录行引用。
- 再次导入同一份已保存的导出文件,确认没有新增评论身份。
- 分别保留深层上下文、其他分支和待确认记录行。
重复导入用于检查你对同一文件的处理方式。这是建议执行的验证步骤,本指南并未实际执行该测试。它不能说明重新进行一次实际采集会返回相同记录。
如果没有任何去重后的回复通过核验,请报告“在这份已核验文件中,纳入结果的直接回复为零”。不要报告“没有人回复”。内容公开可见,并不保证能取得完整的回复集合。
如果必要的父评论值缺失,请将该行保留为待确认。如果目标本身尚未确认,请报告查找结果待确认。这些状态与观测到的数量为零不同。
交付说明应列明已知 Spotlight、经过核验的目标 ID、观测时间、导入的观测次数,以及纳入结果的去重后直接回复数量。同时说明待确认记录和公开可见范围的限制。回复数量字段不能替代这份经过核验的实际回复记录清单。
来源和延伸阅读
作者 Chronometrica · 更新日期
返回顶部 ↑
