# 隐藏 Facebook 负面评论前，如何进行审核

隐藏 Facebook 负面评论之前，先阅读原帖和对话。根据一条明确的公共主页规则核查评论。在人工决策日志中记录证据、拟议操作、审核人和结果。将批评与经核实的违规区分开。对已获批准的操作，使用正常的公共主页账号流程执行。Facebook Comments Scraper 采集公开评论和回复。它不会隐藏、删除、批准或发布这些内容。

如果只需核查少量评论，先进行人工审核。采集工具可帮助你为较大规模的审核保留来源记录。它无法决定一条投诉是否应该保留，也无法决定某条公共主页规则是否适用。

本指南提出一种审核方法。它并未证实隐藏评论能提高销量、维护声誉，或确保评论管理政策安全。本文中的评论管理，是指依据公共主页规则决定如何处理评论。

## 1. 明确决定和规则

有人公开提问：隐藏评论是否值得？对于每项拟议操作，都需要给出理由。仅凭负面语气无法构成理由。所提供的证据包含[一条关于隐藏评论的公开提问，于 2026 年 10 月 25 日核查；它并未衡量更广泛的需求](https://www.reddit.com/r/DigitalMarketing/comments/1bec9tg/hiding_comments_on_facebook_a_good_practice)。

为评论分类之前，先写明审核目的。例如，你可能要核查选定的评论是否违反现有的公共主页规则。将这一目的与判断哪些产品投诉值得调查区分开。

记录规则原文，以及谁有权批准操作。实用的规则必须给审核人提供具体的核查依据。不喜欢某个批评观点，并不能证明该评论违反了规则。

为每条规则记录以下内容：

1. 规则名称或引用编号。
2. 规则全文。
3. 适用该规则所需的证据。
4. 有权批准操作的人员。
5. 证据不明确时的下一步。

如果找不到适用的规则，就记录这一缺口。不要在读完评论后，仅为支持自己想要的结果而制定规则。在负责人核查政策期间，让拟议操作保持待定状态。

还要写明正在审核的具体操作。隐藏、删除、保留，以及将评论转交客服审核，是不同的决定。不要用“已处理”代替你实际所指的操作。

## 2. 选择较小的审核范围

范围是指审核的界限。选择已知的公开帖子链接和审核时段。记录准备核查哪些帖子和日期。最终报告必须清楚保留这些范围限制。

如果评论数量较少，通过正常的公共主页账号流程打开帖子。在原处阅读评论和回复。直接根据这次审核建立决策日志。仅评估几条评论，无需专门导出数据。

需要单独保留来源记录供审核时，可导出公开数据。文档说明，Facebook Comments Scraper 接受 1–100 个受支持的公开内容链接，包括帖子、Reel、视频和照片链接。公共主页、群组、个人主页、快拍和私密链接均不受支持。这些是文档规定的输入限制，并非本指南实际运行后得到的结果。参见[公开 Actor 规范，于 2026 年 10 月 25 日核查；仅核查了静态文档](https://api.apify.com/v2/acts/chronometrica~facebook-comments-scraper/builds/default)。

下面的小规模输入符合所提供的输入规范。输入规范是一组规则，用于规定可接受的输入字段和值。

```json
{
  "collectAllAvailable": false,
  "commentSortMode": "all",
  "includeReplies": true,
  "maxResultsPerPost": 10,
  "startUrls": [
    "https://www.facebook.com/reel/1733966934399341"
  ]
}
```

2. 选择较小的审核范围

将 `startUrls` 中的示例地址替换为你准备审核的受支持公开内容链接。示例地址不能作为你所管理公共主页的证据。此输入已对照文档中的输入规则核查。本指南未实际运行采集。

这些设置的作用如下：

1. `maxResultsPerPost` 将每个所提供 URL 的保存数量上限设为 10 行。每行是一条保存的评论或回复记录。
2. `includeReplies` 请求将回复作为单独计费的数据行采集。回复计入同一个数量上限。该设置并不表示采集 10 条父评论后再额外采集回复。
3. `commentSortMode` 选择文档中的 `all` 排序选项。这个名称并不能证明采集覆盖了全部内容。
4. `collectAllAvailable` 保持为 `false`，因此此输入保留所设的结果数量上限。

此输入没有日期筛选条件。如果添加 `commentsFrom` 或 `commentsUntil`，按照文档说明，系统会跳过没有公开日期的评论。报告审核时段时，应记录这一限制。取消结果数量上限可能增加费用，仍不能保证采集完整。

## 3. 保留来源并阅读对话

保持原始导出数据不变。在单独的表格中建立决策日志。这样，审核人就能将你的判断与原文进行比较。

文档列出的输出字段包括 `commentId`、`commentUrl`、`parentCommentId`、`rootCommentId`、`isReply`、`text`、`publishedAt`、`postDescription` 和 `scrapedAt`。这些是文档中列出的字段，并非已从当前结果中确认的值。某些字段可能无法获取。[Actor 规范，于 2026 年 10 月 25 日核查；未核查实际运行结果](https://api.apify.com/v2/acts/chronometrica~facebook-comments-scraper/builds/default)定义了这些字段及其限制。

使用这些字段定位对话：

1. 将 `commentId` 保留为文本格式。它用于标识评论记录。
2. 如果有 `commentUrl`，用它打开对应的具体评论。
3. 对于回复，检查 `parentCommentId`。它用于标识该回复的父评论。
4. 保留 `rootCommentId`。它用于标识该评论串的顶层评论。评论串是指一条评论及其关联的回复。
5. 阅读原帖及相关的前后回复。
6. 记录核查这些上下文的时间。

一条回复看起来可能是在投诉你的品牌，实际上却是在对另一位用户说话。一句简短回答也可能需要结合父评论才能理解，而导出数据中并未包含那条父评论。不要用假设填补这些缺口。

将发布时间与采集时间分开。`publishedAt` 是可获取的公开发布时间。`scrapedAt` 记录该行数据的采集时间。采集时间不能说明评论何时发布，也不能说明评论管理操作何时发生。

保留缺失值。无法获取日期意味着“日期无法获取”，不意味着“在采集时发布”。无法获取的文本不能视为一条可供分类的空白陈述。缺少心情回应次数，不等于心情回应次数为零。

只引用支持决定所需的文本。从工作报告中移除个人联系方式。必要时，将来源引用保存在单独的位置，仅允许获授权的员工访问。不要将非公开的客服记录或个人联系方式复制到公开报告中。

## 4. 用明确的字段保存决策日志

Actor 不会生成以下审核结论。你需要通过人工核查添加这些结论。为每个已审核的评论 ID 关联一条决策记录，并清楚标明后续核查。

可用以下字段建立一张实用的初始表格：

| 字段 | 保存内容 |
| --- | --- |
| `commentId` | 原始评论标识符，以文本格式保留 |
| `source_reference` | 帖子链接，以及可获取的评论链接 |
| `thread_reference` | 可获取的父评论和根评论标识符 |
| `source_checked_at` | 人工核查来源的时间 |
| `relevant_text` | 审核所需的最少引文，已移除联系方式 |
| `rule_under_review` | 规则原文，或指向该规则的明确引用 |
| `exact_evidence` | 可能符合该规则适用条件的具体文本或来源细节 |
| `context_checked` | 已核查的帖子和对话，以及核查结果 |
| `finding` | 批评、客服问题、经核实的违规，或上下文不明 |
| `uncertainty` | 缺失的证据、相互矛盾的细节，或尚未解答的问题 |
| `proposed_action` | 请求执行的具体操作及其理由 |
| `reviewer` | 负责作出决定的人员 |
| `approval_state` | 待审批、已批准、未批准，或未申请批准 |
| `action_taken` | 实际执行的操作，或尚无完成记录 |
| `action_taken_at` | 已记录的操作时间，或无法获取 |
| `outcome` | 有批准记录和操作记录支持的结果 |

`exact_evidence` 必须足够具体，让另一位审核人能够核查。“不好的评论”没有提供可验证的理由。引用某个具体链接，并说明适用于该链接的规则，才能给审核人提供明确的核查依据。

不要把空白字段当作决定。`approval_state` 为空不代表未批准。`action_taken_at` 为空，也不能说明操作已经发生、只是没有记录时间。标明缺口，并指定人员进行下一步核查。

## 5. 将批评与经核实的违规区分开

选择结论之前，先读懂评论的含义。请区分以下情况：

1. 普通批评：对产品、价格或体验的负面看法。将其与违规区分开。
2. 客服问题：需要客服审核的请求或投诉。不要把客服问题本身当作隐藏评论的证据。
3. 经核实的违规：核查上下文后，具体证据符合该公共主页某条明确规则的违规判定条件。
4. 上下文不明：无法获取所需的原文或对话上下文。让决定保持未决状态。

还要核查评论是对谁说的。仅凭一个向其他用户提出的问题，不能认定品牌需要采取评论管理操作。提出操作建议之前，先记录相关上下文。

重复措辞可以成为另行核查的线索，但不能证明存在滥用行为。如果重复情况与该案例有关，请使用[如何识别重复及疑似垃圾信息的 Facebook 评论，避免错误指控](/zh-Hans/articles/%E5%8F%91%E7%8E%B0%E9%87%8D%E5%A4%8D%E4%B8%94%E7%B1%BB%E4%BC%BC%E5%9E%83%E5%9C%BE%E4%BF%A1%E6%81%AF%E7%9A%84facebook%E8%AF%84%E8%AE%BA/)中的独立证据核查流程。在本日志中，将重复模式的判断与规则适用决定分开记录。

一条投诉也可能包含有用的产品需求。将该需求另行提交产品审核。[如何将 Facebook 功能需求转化为产品优先级](/zh-Hans/articles/facebook%E5%8A%9F%E8%83%BD%E8%AF%B7%E6%B1%82%E8%BD%AC%E5%8C%96%E4%B8%BA%E4%BA%A7%E5%93%81%E4%BC%98%E5%85%88%E7%BA%A7/)中的方法用于作出这类决定。潜在的产品洞察不能决定某条公共主页规则是否适用。

对于每项拟议的评论管理操作，都要将三项内容对应起来：规则、具体证据，以及已核查的上下文。将不明确或影响重大的案例交给指定审核人。此流程不对相关言论作出法律认定。

## 6. 逐项分析六个虚构决定

原创虚构示例：本例中的所有评论、规则、审核人标签和决定均为虚构。此示例用于说明如何使用日志，不代表一次 Actor 运行，也不代表真实的公共主页审核。

这个虚构公共主页设有一条本地规则 R1：“不得在评论中发布指向外部销售页面的链接。”指定审核人可以依据这条规则批准移除评论。这条虚构规则并非 Facebook 全平台的要求，也不是向所有公共主页推荐的政策。

审核人核查了一篇选定公开帖子下的六条评论记录。下方的链接标签是虚构占位文本，不指向真实地址。在实际日志中，应将相关链接的确切证据保存在访问受限的来源记录中。

| 编号 | 虚构评论或来源说明 | 核查结论 | 操作与状态 |
| --- | --- | --- | --- |
| C1 | “就这点功能，价格太贵了。” | 对产品的批评意见 | 保留批评评论 |
| C2 | “我的货为什么还没送到？” | 带有批评的客服问题 | 转交客服审核 |
| C3 | “在这里购买：[虚构销售链接 A]。” | 已根据 R1 和来源上下文核查链接 | 审核人批准移除；尚无完成记录 |
| C4 | “看看这个优惠：[虚构销售链接 B]。” | 已根据 R1 和来源上下文核查第二个链接 | 等待审核人审核 |
| C5 | “你的收到了吗？” | 问题是向评论串中的另一位用户提出的 | 未提出品牌评论管理操作 |
| C6 | 无法获取理解该回复所需的父评论 | 缺少必要上下文 | 未决；核查来源 |

对于 C3，日志记录了 R1、已核查的链接证据、来源核查时间和审核人。其 `approval_state` 为已批准。其 `action_taken` 仍为“尚无完成记录”。获得实际执行操作的证据之前，不要填写操作时间。

对于 C4，规则核查已完成，但仍在等待批准。证据与批准是两回事。存在第二个已核查的链接，并不能证明第二项操作也已获批准。

对于 C6，缺少父评论意味着无法确认上下文，并不是该回复违规的证据。让此案例保持未决状态，并记录由谁重新核查来源。

以下决策类别涵盖全部六行记录：

2 个批评或客服案例 + 2 个已核查的本地规则案例 + 1 个面向其他用户的案例 + 1 个未决案例 = 6 行已审核记录。

只有 1 项移除操作获批。没有任何操作被记录为已完成。这意味着无法根据该记录确定已完成操作的数量；并不能证明记录之外没有发生过操作。

不要报告为“隐藏了两条评论”。获批的操作是移除，而且尚无完成记录。不要报告为“六名有害用户”。这些是六行已审核的评论记录，并非经过核实的人数。此示例也未提供经衡量的销量或声誉收益。

## 7. 核查批准、完成和未能确认的状态

获得批准后，获授权的人员必须通过正常的公共主页流程执行所述操作。采集流程不会执行任何评论管理操作。记录该人员实际做了什么，以及何时执行。

区分以下状态：

1. 已提议：有人请求执行某项操作。
2. 已批准：获授权的审核人同意执行该操作。
3. 已完成：有记录支持该操作已经发生。

后续导出的数据不能代替完成记录。如果某条评论未出现在导出数据中，就记录这一缺失情况。不要声称它已被隐藏。结果数量上限、来源排序或无法获取的来源数据，都可能使评论不被纳入导出数据。所提供的证据无法确定某条具体评论为何缺失。

接受日志之前，检查每项拟议操作是否都有来源引用、明确的规则、具体证据、已核查的上下文和批准状态。确认批评与经核实的违规仍被清楚区分。确认未决案例均有下一步安排和负责的审核人。

报告选定帖子和审核时段内已审核的决定数量，以及未决案例数量。不要将这些数量当作整个公共主页的总数。不要把未审核的记录计入已审核决定的数量。

来源证据支持文档所述的采集功能，以及本文提出的人工方法。它不能证实采集可靠性、旧评论恢复能力，或经衡量的评论管理成效。对于公开导出 Task，仅确认了其页面存在。未读取已保存的设置，也未运行该 Task。

## 从下一个有依据的决定开始

选择一篇已知的公开帖子。写明适用的公共主页规则，并指定审核人。查看原始对话，然后为每条选定的评论填写决策记录。对于缺乏依据的决定，保持未决状态，并指定人员完成缺失的核查。

如果人工审核能满足需求，就使用人工审核。如果需要结构化的公开来源数据行，可使用 [Facebook Comments Scraper](https://apify.com/chronometrica/facebook-comments-scraper)，只提供少量输入，并设置明确的结果数量上限。将采集、批准和已完成的操作分别记录。下一步决定应依据已记录的证据，并遵循公共主页的授权流程。

## 来源和延伸阅读

- [公开提问：隐藏 Facebook 评论是好做法吗？——于 2026 年 10 月 25 日获取；仅一条公开提问记录，未在登录状态下读取，也未估算需求](https://www.reddit.com/r/DigitalMarketing/comments/1bec9tg/hiding_comments_on_facebook_a_good_practice)
- [Facebook Comments Scraper 默认构建版本 2.0.9：输入、输出和 README 证据——于 2026 年 10 月 25 日核查；静态公开规范，未付费运行，也未进行运行验证](https://api.apify.com/v2/acts/chronometrica~facebook-comments-scraper/builds/default)
- [将 Facebook 评论导出为 CSV——于 2026 年 10 月 25 日核查；仅确认公开 Task 存在，未验证已保存的设置，也未运行该 Task](https://apify.com/chronometrica/facebook-comments-scraper/examples/export-facebook-comments-to-csv)