# 如何查找讨论 YouTube 视频特定时间点的评论

要查找讨论视频某个时间点的评论，先找出写明该视频时间的评论。播放每个被提及的时间点，并结合上级评论和可获取的回复阅读评论。建立可保存的索引时，每条评论只保存一次。评论每提及一次时间，就单独添加一行关联记录。写明的时间可以帮助你找到场景，但不能证明评论描述的就是该场景。

如果只需核查一次，从公开视频页面开始。阅读评论，播放其中写明的时间点，并检查回复的上下文。如果需要保存一组可供搜索和再次核查的记录，使用下文的采集方法。

一份[读者公开提案，发表于2024年11月20日；报告了一个查找问题](https://www.reddit.com/r/youtube/comments/1gvthqc)描述了这种困难：“在浏览器中查找和浏览评论区的内容可能很费力。”实用的索引必须保留讨论内容，同时让其中的时间引用更容易查找。

本指南介绍如何建立这样的索引。范围仅限于选取的公开评论和回复，不包括直播聊天、YouTube Studio 中的非公开记录，也不代表所有观众的意见。本指南未实际运行评论采集。

## 1. 确定视频时间点和采集限制

选择一个已知的公开视频。记录视频 ID、公开 URL 和时长。ID 是用于识别来源记录的代码。时长是视频的总播放时间。

选取评论前，先写下要研究的时间点。可以指定一个准确时间，也可以指定起止时间。说明搜索范围是否包含结束时间。这样可以避免后续选择改变研究问题。

索引中的匹配结果表示：某条评论包含一个经过核查、且位于该范围内的时间引用。这不表示你已找到关于该场景的所有讨论。有些评论会描述场景，但不写明时间。

接下来，声明采集限制：

| 设置 | 需要记录的内容 |
| --- | --- |
| 视频 | 已知公开视频的 ID 和 URL |
| 时长 | 总秒数及核查时长的来源 |
| 目标时间点 | 准确时间或明确的时间范围 |
| 评论排序 | 热门（Top）、最新（Newest），或两者 |
| 顶层评论上限 | 每个视频请求的顶层评论数量上限 |
| 回复上限 | 每条顶层评论请求的回复数量上限 |
| 采集时间 | 记录的采集时间 |

顶层评论是指不属于回复的评论。上限是允许的最大数量。设定上限并不保证来源会返回这么多条记录。

热门（Top）采用来源的精选排序。最新（Newest）采用来源的时间倒序。两者（Both）使用这两个列表，并在本次运行中按评论 ID 去重。这些选择限定了样本范围。有关如何选择排序方式，请参阅[评论抽样指南](/zh-Hans/articles/%E6%8C%89%E6%9C%80%E7%83%AD%E9%97%A8%E6%88%96%E6%9C%80%E6%96%B0%E9%A1%BA%E5%BA%8F%E6%8A%BD%E5%8F%96%E8%AF%84%E8%AE%BA%E6%A0%B7%E6%9C%AC/)。

## 2. 采集一小组评论及其回复

Actor 是在托管环境中运行的数据采集程序。[YouTube Comments Scraper 接口约定，已于2026年10月25日核查；仅核查文档](https://apify.com/chronometrica/youtube-comments-scraper)说明了如何通过已知视频 URL 或 ID 采集公开评论。文档还说明，可选择采集回复并设定数量上限。

Actor 提供评论记录。你需要自行提取时间引用、核查视频并建立索引。

先从这组小规模输入开始：

```json
{
  "startUrls": ["https://www.youtube.com/watch?v=dQw4w9WgXcQ"],
  "maxCommentsPerVideo": 20,
  "commentSortMode": "newest",
  "includeReplies": true,
  "maxRepliesPerComment": 5
}
```

2. 采集一小组评论及其回复

将整个 `startUrls` 列表替换为你要采集的公开视频。提供的歌曲 URL 只是输入结构示例，不能证明它能为本方法提供有用的评论结果。

这组输入请求按最新（Newest）排序，最多采集20条不重复的顶层评论。同时，请求每条已采集的顶层评论下最多5条回复。回复是额外的记录行，不占用顶层评论上限。这些数字表示请求上限，不表示实际返回的记录数，也不表示人数。

文档规定，输入可包含1至100个视频条目。`maxCommentsPerVideo` 接受1至1,000的整数。启用回复采集时，`maxRepliesPerComment` 接受1至100的整数。

Task 是已保存的输入预设。公开的[评论和回复导出 Task，已于2026年10月25日核查；仅确认页面存在](https://apify.com/chronometrica/youtube-comments-scraper/examples/youtube-comments-and-replies-export)可作为本次采集的起点。使用前，替换其示例视频列表并检查设置。

所提供的输入已通过文档所列输入规则的检查。已找到公开的 Task 页面及其 ID。未核查已保存的输入，也未核查付费运行。这些检查不能证明采集成功，也不能证明回复采集完整。

## 3. 将评论与时间引用分开保存

保留两张表。评论表保存原始讨论记录。关联表保存评论与视频时间之间的联系。关联是指记录下来的两个对象之间的一项联系。

每个稳定的评论 ID 只保留一行评论记录。合并多个视频的数据时，同时使用视频 ID 和评论 ID。不要因为文字相同就合并评论。

来源中存在以下字段时，保存这些字段：

| 字段 | 用途 |
| --- | --- |
| `videoId` | 识别视频 |
| `videoUrl` | 打开来源视频 |
| `commentId` | 识别评论 |
| `parentCommentId` | 将回复关联到其上级评论 |
| `isReply` | 区分回复与顶层评论 |
| `replyDepth` | 保留文档规定的回复层级 |
| `text` | 保留评论原文 |
| `sortMode` | 保留获取该行记录时使用的来源排序方式 |
| `publishedAt` | 有准确发布日期时予以保留 |
| `publishedTimeText` | 保留页面显示的发布时间文字 |
| `updatedAt` | 有准确更新日期时予以保留 |
| `scrapedAt` | 记录采集时间 |
| `status` | 保留该行记录的处理结果 |

[YouTube 评论资源，已于2026年10月25日核查；仅涉及标识与时间概念](https://developers.google.com/youtube/data/reference/rest/v3/comments)区分了评论 ID 和回复的上级评论 ID。其中的发布时间戳记录评论的发布时间，不是视频中的播放位置。Actor 有其自身文档规定的字段。

缺失值应保持缺失。`publishedAt` 为空值，表示无法获取准确日期，不表示零。不要用 `scrapedAt` 替代它，也不要将其转换为视频时间。

即使导出结果中没有上级评论，也要保留上级评论关联。记录这项上下文缺失。不要因为措辞相似，就将回复关联到另一条评论。

## 4. 将每次写明的时间提取为候选引用

时间标记是一小段可能表示视频播放位置的文字，例如37:07和1:02:03。候选引用是尚未确认的可能时间引用。

阅读原文，为每次出现的候选引用建立一行关联记录。保留原始时间标记及其字符位置。位置从零开始计数：第一个字符的位置是0。

记录位置前，不要更改空格或标点。后续读者必须能在保存的文本中找到同一个时间标记。如果使用其他计数规则，需说明规则并始终保持一致。

关联表需要以下字段。这些字段由你为索引创建，并非 Actor 承诺提供的输出字段：

| 保存的字段 | 用途 |
| --- | --- |
| 视频 ID 和评论 ID | 找到来源评论 |
| 原始时间标记 | 保留写明的时间 |
| 时间标记起始位置 | 区分同一条评论中各次出现的时间标记 |
| 换算后的秒数 | 用同一单位比较有效时间 |
| 已知时长 | 检查时间是否在视频时长范围内 |
| 验证结果 | 记录候选引用有效、无效或待复核 |
| 上级评论上下文 | 关联上级评论，或注明上下文缺失 |
| 核查状态 | 记录视频核查确认的内容 |
| 注释 | 简要说明判断依据 |
| 核查时间与核查人 | 记录谁在何时核查了这条关联 |

一条评论可以包含多个时间。同一个时间也可能在一条评论中出现两次。提取时，应分别保留每次出现的时间标记。这两种情况都不会增加评论条数或人数。

回复可以讨论上级评论中的时间，却不自行写明时间。将这类回复保留为上下文。不要为它编造时间标记，也不要将其标为已核查的场景引用。

## 5. 换算前先验证时间标记

计算秒数前，检查完整的时间标记。不要从负数或格式错误的标记中截取一部分，将其变成有效时间。

使用以下规则：

1. 接受“分:秒”或“时:分:秒”格式。
2. 秒数必须小于60。
3. 含小时的格式中，中间的分钟数必须小于60。
4. 拒绝负值和无效的数字组。
5. 将有效时间标记换算为秒数。
6. 将结果与已知视频时长比较。

对于“分:秒”格式，将分钟数乘以60，再加上秒数：

37:07 = 37 × 60 seconds + 7 seconds = 2,227 seconds.

对于“时:分:秒”格式，将小时数乘以3,600，将分钟数乘以60，再加上秒数：

1:02:03 = 1 × 3,600 seconds + 2 × 60 seconds + 3 seconds = 3,723 seconds.

两组数字的格式以分钟数开头，分钟数可以超过59。三组数字的格式以小时数开头，后面的分钟数和秒数都必须小于60。

因此，37:67不能通过验证。不要擅自修正。保留原始时间标记及其未通过验证的原因。

超过已知时长的时间标记必须保留为待复核。不要将它改为最接近的有效时间。如果时长未知，时长检查应保持未查明状态。时间恰好位于视频结尾时，也必须先通过播放核查，才能称为场景引用。

零与缺失不同。时间标记0:00表示视频起点。换算时间字段为空，表示没有可接受的换算结果。

## 6. 观看对应时间点并阅读讨论

即使数字有效，它仍只是候选引用。它可能指的是其他事物。为其分类前，先观看所引用的时间点。

对每个通过检查的候选引用，执行以下步骤：

1. 打开对应视频，跳转到换算后的时间。
2. 观看并听取该时间点前后的内容。
3. 阅读评论原文。
4. 阅读其上级评论和可获取的回复。
5. 用简短笔记记录能够确认的内容。
6. 指定核查状态。

始终统一使用以下状态：

| 状态 | 含义 |
| --- | --- |
| 已核查的场景引用 | 视频和讨论支持该引用与此时间点之间的关联 |
| 无关时间标记 | 经核查，文本中的时间标记指向其他事物，并非该视频的播放位置 |
| 尚未查明 | 无法核查一项必要事实或来源 |
| 范围之外 | 该引用不属于已声明的研究范围 |

将验证结果与这些核查状态分开保存。无效时间标记表示未通过格式检查。尚未查明的引用表示缺少必要事实。已核查但位于目标范围之外的引用可以保留在完整索引中，但不纳入目标结果。

注释应描述关联本身。不要推断观众的意图，也不要推断观众群体持有共同看法。回复上限还可能使你缺少相关上下文。应说明这一限制。

如果需要判断教程是否缺少某项解释，请继续使用[教学缺漏检查方法](/zh-Hans/articles/%E9%80%9A%E8%BF%87youtube%E8%AF%84%E8%AE%BA%E8%AE%A8%E8%AE%BA%E6%9F%A5%E6%89%BE%E6%95%99%E7%A8%8B%E4%B8%8D%E8%B6%B3/)。仅凭场景引用，不能认定课程存在教学缺漏。如果需要查找评论中没有提及的解释，请使用另一套[概念导航方法](/zh-Hans/articles/%E5%9C%A8%E9%95%BF%E7%AF%87%E6%B2%B9%E7%AE%A1%E8%AE%B2%E5%BA%A7%E4%B8%AD%E6%9F%A5%E6%89%BE%E6%A6%82%E5%BF%B5%E8%AE%B2%E8%A7%A3/)。

## 7. 完整演示一个原创虚构示例

本例所有内容均为原创虚构。视频、评论、回复和观看笔记都是为讲解方法而编写的，并非 Actor 输出。本例未实际运行评论采集，也未实际进行播放核查。

虚构视频的时长为40:00：

40 × 60 seconds = 2,400 seconds.

评论 C 的原文如下：

“37:07 explains the setup; 38:10 shows the result.”（中文释义：“37:07 解释了设置；38:10 展示了结果。”）

引号仅用于展示示例，不属于保存的评论原文。中文释义也不属于保存的原文。37:07的第一个字符位于位置0。

### 保留一条评论和两条时间引用

评论表只保存一次 C。回复 R 是 C 下单独的一行记录。在这个虚构示例中，R 的原文是“That comparison helped.”，意思是“这个比较很有帮助。”其中没有时间标记。

| 评论 ID | 上级评论 ID | 文本 |
| --- | --- | --- |
| C | 无；顶层评论 | 37:07 explains the setup; 38:10 shows the result.  中文释义（不属于保存的原文）：37:07 解释了设置；38:10 展示了结果。 |
| R | C | That comparison helped.  中文释义（不属于保存的原文）：这个比较很有帮助。 |

C 中的两个时间标记生成两行关联记录：

| 评论 ID | 时间标记 | 从零计数的起始位置 | 换算后的时间 | 时长检查 |
| --- | --- | --- | --- | --- |
| C | 37:07 | 0 | 2,227秒 | 在2,400秒以内 |
| C | 38:10 | 26 | 2,290秒 | 在2,400秒以内 |

第二个时间标记从位置26开始。位置25是分号后的空格。该位置必须始终对应未改动的英文原文。

第二个时间的计算如下：

38:10 = 38 × 60 seconds + 10 seconds = 2,290 seconds.

两条时间引用相差2,290 − 2,227 = 63秒。这个差值并不构成一个连续的场景区间。评论指出的是两个独立时间点。

### 应用虚构的观看笔记

假设虚构的观看笔记确认，37:07展示设置，38:10展示其结果。两条关联的状态都设为“已核查的场景引用”。R 继续关联到 C，作为回复上下文。不要为 R 编造时间引用。

| 评论 | 时间 | 状态 | 注释 | 回复上下文 |
| --- | --- | --- | --- | --- |
| C | 37:07 | 已核查的场景引用 | 虚构的观看笔记确认此处展示设置 | R 仍关联到 C |
| C | 38:10 | 已核查的场景引用 | 虚构的观看笔记确认此处展示结果 | R 仍关联到 C |

如果目标范围为37:00至37:30，且包含37:30，只有第一条关联进入结果。第二条仍保留在完整索引中。无论查看哪组数据，C 都只算一条评论。

本例有两条评论记录，其中一条是回复。C 提及了两次时间戳。这些记录数不能用来确定人数。

### 将超出时长的时间保留为待复核

现在，另看一个独立的虚构候选引用41:00：

41 × 60 seconds = 2,460 seconds.

2,460 − 2,400 = 60秒，超出了虚构视频的时长。

这个时间标记的格式有效，但未通过时长检查。将其保留为待复核，并记录原因。不要用40:00替换它。这个独立的候选引用不改变上文 C 和 R 的计数。

## 8. 检查导出结果并保留失败状态

导出已核查的导航索引，包含视频 URL、已核查的视频时间、评论 ID、上级评论上下文、简短注释和状态。同时保留原始评论表和候选引用表。

使用索引前，检查每条关联是否都能追溯到一条已保存的评论。对照未改动的文本，再次核查时间标记位置。确认计算和单位无误。确保每个已接受的时间都属于正确的视频。

保留并明确标出以下问题：

| 情况 | 需要采取的处理方式 |
| --- | --- |
| 文本缺失 | 提取保持未查明状态；不要编造文字 |
| 标识缺失 | 记录保持未查明状态；不要编造 ID |
| 时间标记无效 | 保留时间标记及其验证失败记录 |
| 时长未知 | 时长检查保持未查明状态 |
| 无法播放 | 场景核查保持未查明状态 |
| 上级评论或回复缺失 | 记录上下文缺失 |
| 采集失败 | 记录失败；不要将其视为成功采集到空样本 |
| 没有已核查的匹配结果 | 报告本次采集的数据集中没有已核查的匹配结果 |

零计数仅适用于你实际核查过的数据集，不能证明不存在相关评论。分别报告不重复的评论 ID 数量和时间戳提及次数。报告这些计数时，同时保留来源排序方式、数量上限、采集日期和未查明的记录。

## 先建立一条经过核查的记录

选择一个公开视频和一个目标时间点。记录视频时长和采集上限。如果只需手动核查一次，使用公开视频页面。需要保存公开评论和回复记录时，使用 [YouTube Comments Scraper，接口约定已于2026年10月25日核查；未进行运行测试](https://apify.com/chronometrica/youtube-comments-scraper)。

采集前，替换示例视频。然后选取一条评论，完成提取、验证、播放核查和注释。只有时间、来源标识和已核查的上下文相互吻合，才能接受这条索引记录。

确认第一条记录无误后，再扩充索引。保留并明确标出尚未查明的记录。最终得到的是一个经过核查的辅助工具，用于查找所声明样本内的讨论。是否扩大采集范围或评估课程，需要另行决定。

## 来源和延伸阅读

- [YouTube Comments Scraper 公开接口约定——已于2026年10月25日核查；构建版本1.1.6的文档，未进行付费运行或运行测试](https://apify.com/chronometrica/youtube-comments-scraper)
- [YouTube 评论和回复导出 Task——已于2026年10月25日核查；已找到公开页面和预设 ID，未核查已保存的输入或执行情况](https://apify.com/chronometrica/youtube-comments-scraper/examples/youtube-comments-and-replies-export)
- [YouTube Data API 评论资源——已于2026年10月25日核查；仅涉及评论标识、上级评论标识和发布时间概念](https://developers.google.com/youtube/data/reference/rest/v3/comments)
- [关于评论查找的读者公开提案——发表于2024年11月20日，于2026年10月25日查阅；提出了一个读者遇到的问题](https://www.reddit.com/r/youtube/comments/1gvthqc)