109 lines
2.1 KiB
Markdown
109 lines
2.1 KiB
Markdown
# Audit 模块需求分析
|
|
|
|
## 1. 模块定位
|
|
|
|
`apps.audit` 在最新版产品形态中对应：
|
|
|
|
> 处理历史与审计留痕中心
|
|
|
|
它不仅保存对话历史，还要保存资料包、节点执行、风险结论和飞书通知的完整链路。
|
|
|
|
## 2. 模块目标
|
|
|
|
1. 记录每次 Agent 审核任务。
|
|
2. 记录资料包与会话绑定关系。
|
|
3. 记录节点执行结果与最终风险状态。
|
|
4. 记录飞书通知触发、接收人和回执。
|
|
5. 支持处理历史页按批次回看任务。
|
|
|
|
## 3. 审计对象
|
|
|
|
V1 至少需要覆盖：
|
|
|
|
1. 资料包导入任务
|
|
2. 目录汇总任务
|
|
3. 完整性检查任务
|
|
4. 字段抽取任务
|
|
5. 一致性核查任务
|
|
6. 风险预警任务
|
|
7. 飞书通知任务
|
|
|
|
## 4. 关键字段
|
|
|
|
### 4.1 基础字段
|
|
|
|
1. `audit_id`
|
|
2. `batch_id`
|
|
3. `conversation_id`
|
|
4. `product_name`
|
|
5. `task_type`
|
|
6. `status`
|
|
7. `created_at`
|
|
|
|
### 4.2 节点结果字段
|
|
|
|
1. `node_name`
|
|
2. `node_status`
|
|
3. `node_summary`
|
|
4. `source_report_ids`
|
|
|
|
### 4.3 飞书留痕字段
|
|
|
|
1. `trigger_source`
|
|
2. `notify_reason`
|
|
3. `owner_role`
|
|
4. `feishu_user_id`
|
|
5. `feishu_open_id`
|
|
6. `feishu_name`
|
|
7. `feishu_message_id`
|
|
8. `message_status`
|
|
9. `error_message`
|
|
|
|
## 5. 处理历史页要求
|
|
|
|
处理历史页应展示：
|
|
|
|
1. 批次号
|
|
2. 产品名称
|
|
3. 任务名称
|
|
4. 时间
|
|
5. 风险状态
|
|
6. 资料规模
|
|
7. 最终结果
|
|
8. 节点链路
|
|
|
|
## 6. 飞书协同留痕要求
|
|
|
|
在 V1 中，飞书通知有两个固定触发时机：
|
|
|
|
1. 审核任务执行完成
|
|
2. 审核任务执行异常
|
|
|
|
两类通知都必须在审计中保留：
|
|
|
|
1. 谁被 `@`
|
|
2. 为什么被 `@`
|
|
3. 发送是否成功
|
|
4. 是否有 Web 详情页回链
|
|
|
|
## 7. 与角色信息的关系
|
|
|
|
审计模块必须能记录责任人实体中的飞书字段，至少包括：
|
|
|
|
1. `owner_role`
|
|
2. `owner_name`
|
|
3. `department`
|
|
4. `chapter_scope`
|
|
5. `risk_scope`
|
|
6. `feishu_user_id`
|
|
7. `feishu_open_id`
|
|
8. `feishu_name`
|
|
9. `notify_enabled`
|
|
|
|
## 8. 验收标准
|
|
|
|
1. 处理历史页能回看历史审核任务。
|
|
2. 能从历史中看出资料包、产品名称和对话的对应关系。
|
|
3. 飞书通知的完成态和异常态都能留痕。
|
|
4. 审计详情足以解释“为什么通知了这个处理人”。
|