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

1. 明确决定和规则

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

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

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

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

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

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

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

2. 选择较小的审核范围

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

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

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

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

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

将 `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 日核查；未核查实际运行结果定义了这些字段及其限制。

使用这些字段定位对话：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

重复措辞可以成为另行核查的线索，但不能证明存在滥用行为。如果重复情况与该案例有关，请使用如何识别重复及疑似垃圾信息的 Facebook 评论，避免错误指控中的独立证据核查流程。在本日志中，将重复模式的判断与规则适用决定分开记录。

一条投诉也可能包含有用的产品需求。将该需求另行提交产品审核。如何将 Facebook 功能需求转化为产品优先级中的方法用于作出这类决定。潜在的产品洞察不能决定某条公共主页规则是否适用。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

区分以下状态：

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

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

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

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

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