卓安Claw 录音与案件档案证据链 业务方案 v1.0

日期：2026-11-13
状态：业务方案（先定业务逻辑，再补功能）；P0-1 录音上传已落地
关联：卓安Claw-业务流蓝图-v0.1.md、卓安Claw-账号与业务管理落地方案-v1.0.md、卓安Claw-数据对象与状态机-v0.1.md、卓安Claw-谈案录音与AI质检-V1方案草案-v0.1.md

0. 核心原则

录音不是一个孤立的“上传功能”，而是律所业务链上的沟通证据/服务记录：

线索 → 客户 → 案件 → 12 节点办案 → 结案 → 归档 → 复盘/回访

每一个录音都必须回答五个问题：

1. 这是谁说的？（当事人、客户、律师、运营、其他）
2. 属于哪条线索/哪个客户/哪个案件？
3. 发生在哪个业务节点？对应哪次预约/任务/沟通？
4. 它是什么性质：谈案沟通、客户服务、办案沟通，还是证据性录音？
5. 结案后怎么归档、怎么证明没被改过、谁有权限看？

不能只做“上传成功”，必须做到“业务归属清楚、案件过程可调用、结案可归档、证据链可验证”。

1. 业务对象与关系

1.1 主链

Intake（线索/收案）
  ├─ Client（客户，转案时查重复用/新建）
  ├─ Case（案件，转案时创建）
  │    ├─ Appointment（预约/接诊）
  │    ├─ Task（任务/12 节点）
  │    ├─ Document（案件材料/文书）
  │    └─ Archive（归档卷宗）
  └─ CommunicationRecord（沟通录音）

1.2 录音对象的归属

场景	上传时必有	可空	说明
线索阶段电话	intake_id	case_id、client_id	转案后自动补绑案件/客户
客户阶段回访	intake_id 或 client_id	case_id	有案件则选案件
接诊/谈案	intake_id + case_id	—	记录 stage_key=receive/plan
办案沟通	case_id + client_id	intake_id	记录 stage_key=treatment/...
证据性录音	case_id + client_id	—	需单独标记，归档时重点核对

1.3 关联规则

1. 线索转案自动补绑：以 intake_id 为稳定键，把该线索下所有录音补写 case_id/client_id/linked_at，并写 linked_to_case 事件；不复制录音。
2. 上传时已选案件：直接绑定案件；校验当前用户有案件数据范围。
3. 客户有多个案件：上传时必须选案件；不默认猜。
4. 案件无对应线索：允许直接建沟通记录，intake_id 为空，但必须有 case_id。
5. 禁止孤儿录音：除“线索阶段未转案”外，不允许既无 intake_id 又无 case_id 的记录。
6. 参与人角色化：参与人不是一段自由文本，要支持 客户/当事人/律师/运营/其他 角色；V1 可先文本 + 人工确认。

2. 录音性质分类

purpose	用途	归档处理
谈案沟通	首次咨询、邀约、报价、方案沟通	进案件卷宗的“谈案记录”索引，作为过程材料
客户服务	回访、满意度、日常沟通	进“服务记录”索引，可不进核心证据卷
办案沟通	会见、阅卷、开庭准备、进度沟通	进“办案记录”索引，按节点归档
证据性录音	拟作为证据/证明材料使用	必须单独标记、复核、计算哈希，进证据清单

不是所有录音都进“证据卷”。先分类，再决定归档位置和保留期限。

3. 生命周期与状态机

3.1 归属状态

仅线索（lead_only）
  → 已关联案件（linked_to_case）
  → 已归档（archived）

异常：未归属（unlinked，仅允许线索阶段短暂存在）

3.2 处理状态

待上传 → 待转写 → 转写中 → 已转写 → 分析中 → 已分析
                                      ↘ 失败（可重试）

3.3 复核状态

待复核 → 已确认 / 误报 / 已辅导

3.4 归档状态

未归档 → 待归档 → 已归档
异常：已退回（材料/复核不齐）

规则：

• 归档前，录音必须有明确归属；未关联案件且未转案的线索录音不进入案件归档。
• 证据性录音归档前必须“已转写 + 已确认 + 哈希校验通过”。
• 已归档录音不允许覆盖；补正只能追加新版本/新记录，保留原记录。

4. 12 节点与岗位 RACI

节点	录音相关动作	R	A	C/I
预约/建档	上传首次来电/咨询录音；确认客户身份	客服	客服主管	谈案/客户经理
分诊	把线索录音带进分诊包	客服主管	分所管理员	谈案/承办
接诊	上传接诊/面谈录音；确认参与人	谈案/承办	谈案/承办主管	客户经理
检查/诊断	上传会见、阅卷沟通；标记办案沟通	承办	承办主管	谈案/知识库
方案/签约	上传报价/方案沟通；标记谈案沟通	谈案	谈案主管	财务/承办
办案	上传办案沟通；必要时标记证据性录音	承办	承办主管	协办/合伙人
复核/会诊	复核证据性录音与转写	主办律师	合伙人/主任	承办团队
结案	确认录音清单完整	承办	承办主管	客户经理
归档/质控	核对录音索引、哈希、同意记录	承办/档案管理员	管理者/财务	分所管理员
回访	上传回访录音；标记客户服务	客户经理	客户经理主管	承办

关键岗位边界：

• 客服只负责线索阶段录音，不接触办案录音。
• 客户经理不做证据性录音确认。
• 谈案律师可上传谈案录音，但不能把案件证据性录音归入证据卷。
• 承办律师对案件录音的关联、节点、证据性标记负责。
• 档案管理员/管理者负责归档核对，不替承办判断证据内容。
• 财务不接触录音内容，只核对归档财务项。

5. 归档与证据链

5.1 归档卷宗中的录音索引

归档不把音频二进制塞进 document 表；建立录音索引清单，指向原件 blob：

{
  "case_id": "...",
  "recordings": [
    {
      "comm_id": "...",
      "purpose": "办案沟通",
      "stage_key": "treatment",
      "occurred_at": "2026-11-13 10:00",
      "participants": ["客户杨某", "承办律师李某"],
      "original_sha256": "...",
      "original_size": 64044,
      "consent_confirmed": true,
      "transcript_version": "v1",
      "transcript_reviewed": true,
      "analysis_version": "v1",
      "review_status": "已确认",
      "archive_status": "已归档"
    }
  ]
}

归档门禁：

1. 有录音的案件，归档清单必须列出全部录音；无录音的要写“无录音说明”。
2. 证据性录音必须 已转写 + 已确认 + 哈希校验通过。
3. 录音索引必须和案件号、客户、承办律师对应。
4. 归档后录音只读；补正追加新记录/新版本。

5.2 证据链字段

每条录音至少保留：

• original_sha256：原件哈希，归档时重算比对。
• uploaded_by / uploaded_by_user_id：谁上传。
• consent_confirmed / 告知方式：客户同意记录。
• occurred_at：沟通发生时间。
• linked_at / case_id：何时归入哪个案件。
• transcript_version / analysis_version：转写/分析版本。
• review_status / reviewed_by / reviewed_at：人工复核。
• archive_status / archived_at：归档状态。
• zhuoan_comm_event：上传、关联、转写、复核、归档、导出、删除等事件。

证据链事件示例：

uploaded → linked_to_case → transcribed → analyzed → reviewed → archived

每个事件记录 actor、时间、详情；正式版对事件做哈希链，支持“验证完整性”。

5.3 保留与销毁

按数据对象方案：

• 录音属于 C 类敏感数据，默认不出域。
• 保留年限：案卷 5/10/15 年待定；录音跟随案件卷宗保存期限。
• 到期销毁必须审批；销毁记录保留，不物理删除审计。
• 归档后 legal_hold 的录音不得删除。

6. 案件办理中怎么调用

6.1 线索/客户详情

• 时间线显示每次沟通：类型、时间、参与人、上传人、状态、关联案件。
• 点开录音：播放器 + 转写 + AI 发现 + 下一步建议。
• 转案时提示“该线索有 N 条录音，将随案归档”。

6.2 案件详情

• 「沟通录音」卡：按节点/时间列出；标记谈案、办案、证据性。
• 上传时默认当前案件、当前客户/线索、当前节点。
• 节点清单可关联录音；例如“会见当事人”节点展示对应会见录音。

6.3 归档页

• 显示录音索引清单、哈希状态、复核状态、同意记录。
• 缺少录音说明或证据性录音未复核时，归档门禁提示。

6.4 复盘/回访

• 复盘页可引用录音时间点作为证据；引用必须带 comm_id + start/end。
• 回访录音归入“客户服务”，不默认进证据卷。
• 知识回流只提取结构化经验，不复制录音全文。

7. 权限与数据边界

• 录音查看：本人/本部门/本分所/全所/案件团队，按现有五维权限。
• 上传：客服（线索）、客户经理（客户）、谈案/承办（案件）、管理者。
• 证据性录音：承办律师标记，合伙人/管理者复核。
• 归档查看：档案管理员/管理者/承办团队；跨所默认不可见。
• 导出/下载/删除：单独授权 + 审计；C 类不出私有云。
• 外部模型：只送脱敏转写文本，不送音频；C 类文本不送。

8. 当前代码与目标差距

已实现（P0-1）：

• zhuoan_comm_record / zhuoan_comm_transcript / zhuoan_comm_analysis。
• 人工上传、SHA-256 原件、同意确认、线索/客户关联。
• 案件详情「沟通录音」卡；上传时可选择案件。
• 线索转案后按 intake_id 自动补绑案件/客户。
• zhuoan_comm_event 记录上传/关联事件。
• 非管理者 V1 只看自己上传的录音。

未实现：

• 归档卷宗中的录音索引与归档门禁。
• purpose/stage_key 在 UI 的完整维护（上传已有用途，节点待补）。
• 参与人角色化、客户身份确认。
• 转写/分析/复核/证据链哈希。
• 主管团队视图、档案管理员视图。
• 录音删除/保留期/导出权限。
• 归档后只读与补正流程。

9. 落地顺序

P0（先闭环）

1. 转案自动关联（已做）。
2. 案件详情录音卡（已做）。
3. 录音用途 + 节点 + 参与人角色。
4. 归档页录音索引清单（先展示，不阻塞归档）。

P1（可办案调用）

1. 转写 worker + 播放器 + 分段。
2. 节点清单关联录音。
3. 主管质检队列。
4. 复盘引用录音时间点。

P2（证据链）

1. 证据性录音标记 + 复核。
2. 归档门禁 + 哈希校验 + 事件哈希链。
3. 保留期/销毁审批/legal hold。
4. 导出与审计报表。

10. 验收用例

1. 客服上传一条线索电话录音 → 线索时间线可见 → 转案后自动出现在案件「沟通录音」卡，case_id 正确。
2. 承办在案件内上传会见录音 → 选择节点 treatment → 节点清单/归档清单可见。
3. 证据性录音未复核 → 归档门禁提示，不能标记“已归档”。
4. 归档后修改录音 → 拒绝；补正生成新记录，原记录保留。
5. 客服看不到办案录音；谈案看不到其他团队案件录音；管理者按范围可见。
6. 删除/导出录音 → 有审计，C 类不出私有云。
7. 复盘引用录音 → 能回到原句/时间点；无出处不展示。

11. 一句话总结

录音要沿着“线索—客户—案件—节点—归档—复盘”这条业务链走；上传只是入口，归属、用途、节点、权限、归档、证据链才是产品。