语音房AI审核先测状态与权限边界

AI 在语音房里识别出违规发言，离真正安全地禁言一个人，还隔着权限、麦位变化、请求超时和结果确认。原文的核心主张是：先验证管理协议，再评价模型表现，不能让模型的自信直接变成房间里的处置权。

作者围绕 Tencent RTC 给出了一套 TypeScript 控制层设计。对前端和全栈开发者，更有价值的是它如何拆开「建议」「批准」「执行」和「确认」，以及如何把演示时看不出的错误写成可重复运行的测试。

AI 挂着 moderator 身份，也不该拥有批准权

原文把系统拆成几项独立职责：Tencent RTC 承载实时音频，房间与麦位状态决定谁能发声，语音识别按需生成文本，模型负责分类或建议，人类管理员作出处置决定，应用服务端负责校验和执行。

这里最关键的是两组权限不能混在一起。

第一组是管理权限。参与者的 kind 分为 human 和 ai，role 则是 host、moderator 或 member。即便机器人被标成 moderator，批准函数仍先要求 reviewer.kind === "human"，再检查角色是否为 host 或 moderator。

第二组是音频发布能力。机器人要朗读警告，也必须占有麦位、没有被静音，而且房间仍处于 open。原文用下面的函数表达这一层判断：

export function canPublishAudio(
  state: RoomState,
  participantId: string
): boolean {
  if (state.phase !== "open") return false;

  return Object.values(state.seats).some(
    (seat) =>
      seat.occupantId === participantId &&
      seat.muted === false
  );
}

要看的是 occupantId 和 muted 两个条件：角色名称不能替代当前麦位权限。但这个函数只判断能否发布音频，没有检查警告是否经过人类批准；后者仍要由警告工作流保证。

模型可以提出建议，但批准权和发声条件都必须由应用规则决定。

因此，模型输出某个特殊 token，也不能成为绕过审批或上麦检查的捷径。

为什么禁言建议要绑定麦位版本

实时房间最容易出错的地方，是管理员看到的情况已经过时。

机器人建议禁言某个麦位，管理员读完证据再点击确认时，原发言者可能已经下麦，新用户接着坐了上来。如果执行请求只有麦位编号，就可能处理错人。

作者让建议同时携带 targetId、expectedSeatId、expectedSeatRevision 和 expiresAt。批准时，服务端重新检查房间是否开放、建议是否仍为 pending、是否到期、麦位上的人是否匹配，以及版本有没有变化。

示例里，建议引用的麦位版本是 7。即使该麦位上的人仍是 speaker，只要当前版本变成 8，批准也会报 stale_seat_revision。测试使用 10_000 作为当前时间，建议在 20_000 到期；判断条件为 now >= proposal.expiresAt，到期时刻本身就不能再批准。

revision 是应用维护的版本号，原文明确没有把它冒充成 SDK 字段。不过文字对递增时机有一点差异：代码注释说接受新快照时赋值，适配器说明则要求接受发生变化的快照时递增。实际接入应统一规则，否则没有实质变化的刷新，也可能让建议不断失效。

这类校验必须放在可信服务端。前端隐藏按钮只能减少误操作，不能阻止旧页面、伪造角色或直接请求接口。

接口接受请求，为什么还不能显示成功

另一类问题发生在执行之后。适配器返回 accepted，只能说明请求被接受，不能证明目标已经静音。

作者区分了 pending、applying、awaitingObservation、verified、failed、uncertain 和 dismissed。其中最重要的路径是：

pending → applying → awaitingObservation → verified

先批准，再请求执行，最后等新的麦位快照确认结果。对于禁言，快照需要显示对应用户仍在目标麦位，而且 muted 已变为 true。

超时则返回 unknown，建议进入 uncertain，并记录 action_result_unknown。超时无法告诉应用远端到底有没有执行，因此应先刷新权威状态，再通过 operationId 或持久化层的幂等机制控制重试。

请求被接受和操作已生效，应该是界面上两个不同的状态。

Tencent RTC 的接入被隔离在 VoiceRoomAdapter 后面，通过 readRoomPhase()、readSeats() 和 applyModeration() 与领域逻辑交互。按原文引用的官方实现指南，房间生命周期对接 LiveListStore，麦位快照对接 LiveSeatStore。这些适配器方法是作者定义的应用接口，并非宣称 SDK 存在同名方法。

项目初始化使用近期 Node.js、TypeScript 和 Vitest：

mkdir voice-room-moderation-bench
cd voice-room-moderation-bench
npm init -y
npm install --save-dev typescript vitest @types/node
npm pkg set scripts.test="vitest run"
npx tsc --init
mkdir src

其中 scripts.test 被设为 vitest run，随后用 npm test 执行。编译配置采用 target: ES2022、module: ESNext、moduleResolution: Bundler，开启 strict、noUncheckedIndexedAccess 和 skipLibCheck，只包含 src。

但给出的原文代码并不完整：recordApplyResult 在 accepted 分支中途结束，测试调用的 verifyObservedState 也没有实现。因此，这份输入能说明设计和测试意图，不能直接认定为复制后即可运行的完整项目。

我的判断

我认可作者把评估拆成三个维度：建议质量、协议安全、失败后的恢复清晰度。识别准确率再高，也不能抵消一次错误授权或过期处置。相比只靠提示词要求 AI 谨慎，确定性的服务端校验更容易审查和测试。

但作者没有提供模型准确率、延迟、管理员工作量变化或真实房间对照数据。文中展示的是单元测试用例，也没有附运行结果。它是一套控制协议方案，尚不足以证明 AI 已经减轻管理负担。

边界还有几处需要补齐。人工批准不是万能保障，管理员仍可能误读上下文；保护房主等特殊目标，需要额外的服务端规则，示例没有实现。批准后到远端执行前，麦位仍可能再次变化，适配器如何约束这段并发窗口，原文也没说清。

版本检查较保守，可能因无关变化增加复核次数，但它至少明确拒绝把旧建议转移给新占位者。直接禁言与先提示、加入人工队列之间如何取舍，还要由社区规则决定，不能从这些测试推导出统一答案。

证据也需要单独治理。示例用 transcript-window-42 引用片段，避免每条记录复制完整录音或转写，但引用背后的数据依然需要访问控制、保留期限和用户同意。作者披露了与 Tencent RTC 的内容合作关系；本文更适合用于讨论控制层设计，不能当作产品横向比较。

能拿来做什么

• 给语音房审核台拆开「待审核」「执行中」「等待状态确认」「结果未知」等状态，并展示证据、过期时间和复核入口，让管理员知道下一步能做什么。
• 在 Node 服务端统一校验审核者身份、房间阶段、目标用户、麦位版本和有效期，同时记录建议来源、人工审核者、operationId 与观察结果。
• 用 Vitest 先覆盖离麦、换人、过期、关房和超时场景，再用非生产账号验证真实房间；模型准确率另用有代表性、获得同意的数据评估。
• 保留人工举报和直接管理入口，让语音识别或模型故障时仍能管理房间；取消 AI 警告时，同时处理已排队的合成音频及其麦位权限。