言需有据

把腾讯会议中的客户原声变成可复核的需求证据账本，再生成候选需求。核心原则是：先取证，后归纳；保留反例，不替客户说话。

触发边界

使用本 Skill：

• 分析客户访谈、用户研究、VOC、需求调研或产品发现会议。
• 找出某项需求来自哪些会议、哪些角色和哪些原声。
• 跨会议归纳痛点、期望结果、替代方案、阻碍、异议和反例。
• 把新访谈增量合并到既有需求证据账本。

不要使用本 Skill：

• 普通会议纪要、实时发言提醒或实时情绪检测。
• 泛化联系人搜索、人物画像、绩效评价或成交概率预测。
• 用户没有提供会议范围，也没有允许选择腾讯会议记录时。
• 只有二手总结、无法取得转写或原文，却要求输出确定性需求结论时。

按需读取

不要一次性读取全部 reference。先判断当前步骤，再读取对应文件。

工作模式

1. 单场速览：用户给出一个会议口令，输出主题证据、反例和遗漏问题。
2. 多场归纳：用户给出时间范围或会议清单，输出跨会议需求地图。
3. 增量更新：用户提供既有 ledger，再把新会议合并并说明变化。

无法判断模式时，只问一个问题：要分析哪场会议或哪个时间范围？

执行流程

1. 认证闸门

   • 确认 tmeet 可用；缺失时先征得用户同意，再安装 @tencentcloud/tmeet@latest。
   • 执行 tmeet auth status。未授权时引导 OAuth，不读取或展示 token。

2. 确认范围

   • 使用会议口令、项目代号或带时区的日期范围查找已结束会议。
   • 候选不唯一时，展示会议主题、会议口令和时间，让用户选择。
   • 在用户确认前，不批量读取不相关会议。

3. 获取证据

   • 读取录制列表、智能纪要、转写段落；需要角色覆盖时再读取参会人报告。
   • 内部 ID 只在命令参数间传递，不写入聊天、日志或最终文件。
   • 权限不足时按两阶段权限申请流程处理，提交前必须确认。

4. 规范化转写

   • 每场会议的原始 JSON 单独保存到临时目录。
   • 运行 scripts/normalize_transcript.py，生成脱敏段落、稳定 paragraph ID 和角色别名。
   • 没有可用段落时停止该会议的需求归纳，记录结构化缺口。

5. 提取证据候选

   • 按 evidence-schema.md 识别 job、pain、desired_outcome、workaround、objection、constraint、counterexample、commitment。
   • 每条候选必须引用真实 paragraph ID，并保留原声短摘录。
   • 不得把智能纪要中的转述当作原声；它只能用于导航或补充上下文。

6. 生成账本

   • 运行 scripts/build_evidence_ledger.py 去重、生成 evidence ID、统计会议和角色覆盖、识别冲突并计算可解释等级。
   • 有旧账本时传入 --previous，输出新增、增强、减弱和冲突变化。

7. 生成交付物

   • 运行 scripts/render_report.py 生成单文件 HTML。
   • 同时保留 ledger JSON，供复核和后续增量更新。
   • 报告必须包含需求地图、原声证据、冲突、覆盖度、候选需求和后续验证问题。

8. 质量门

   • 运行 scripts/validate_output.py --ledger ... --html ...。
   • 校验失败时修复证据或降级结论，不能绕过校验。
   • 最终回复只给出产物路径、会议覆盖数、证据数、冲突数和数据缺口，不展开隐私内容。

证据规则

• 结论没有 paragraph ID：不进入账本。
• 高置信不是模型主观分；必须满足跨会议、跨角色和无关键反例的规则。
• 同一段原声只计一次，不因重复措辞增加权重。
• 支持与反对证据并列呈现，不通过润色消除冲突。
• 只有一场会议或一个角色时，最多给“弱”或“中”证据。
• 缺少时间字段时标注“段落证据”，不伪造时间戳。

用户可见表达

使用“证据强 / 证据中 / 证据弱 / 存在冲突”，避免“AI 置信度 87%”。候选需求必须写成待验证的问题陈述，不得冒充已经批准的 PRD。