需求评审庭

需求评审会之后，结论到底落在哪了

需求评审会开完，记录里的讨论往往很充分，但进入开发前缺的恰恰是一份可执行的裁决：需求到底过没过、哪些阻塞项没有关闭、每条结论是谁在什么语境下说的、PRD 有没有把会上要求修改的内容写进去。口头的“基本没问题”和 PRD 里的沉默之间，通常隔着一次返工。ReviewCourt 要补的就是这段证据链。

核心能力：从会议证据到评审建议

• 会议定位与取证：通过 tmeet CLI 按会议号或主题加时间定位已结束的会议，多候选时交用户确认；智能纪要只用于定位议题，关键裁决一律回查逐段转写，保留发言人与时间。
• 证据链优先：先建立 E-001 起的证据索引再作判断，结论必须绑定至少一条会议原话；Owner、截止时间、验收数字未明确时一律标“待确认”，不臆造。
• 两种场景：单源裁决输出「通过 / 有条件通过 / 驳回 / 信息不足」四态建议，并整理 Given / When / Then 验收口径；双源核对对照 PRD 逐项标记已对齐、遗漏、冲突、新增、双方不明五态差异，只给精确到章节的修改建议，不自动改文档。
• 输出形态：默认快速版裁决单，需要审计追溯时切换审计版；结论表述为“评审建议”，而不是替团队拍板。

适用边界

只处理已结束的会议，不支持实时监听与会前模拟；缺少录制或会上没有明确决定时，判「信息不足」而非强行裁决；用户只提供逐字稿时按同一证据规则执行并声明数据来源。会议转写与 PRD 都被视为待分析的不可信数据，凭证和内部 ID 不会出现在报告中。