198 lines
14 KiB
Markdown
198 lines
14 KiB
Markdown
# 三角色对公业务工作台开发任务 v1.1
|
||
|
||
更新日期：2026-09-14
|
||
状态：开发基线（客户经理、评审员、配置管理员需求已确认）
|
||
|
||
## 1. 首要原则
|
||
|
||
1. 简洁、好用、可用是第一要务。业务用户只处理业务问题，不学习 SQL、提示词或 Agent 技术。
|
||
2. 所有预审、评审、计算和报告生成统一由 mini-openclaw 调度已发布的 Skills、规则、经验和模板，不建立旁路计算链。
|
||
3. 页面明显位置始终显示当前身份和当前项目；越权操作由后端拒绝，不能只靠前端隐藏。
|
||
4. 每次运行冻结项目数据和组件版本。历史预审、评审和报告不可覆盖，并可从项目内点击查看。
|
||
5. 重要数字、风险和建议均可追溯到数据卡、证据、Skill、规则、经验、模板和运行编号。
|
||
6. 时间事件自动记录，不要求工作人员手工打卡；统计区分处理、排队、外部等待和系统执行。
|
||
|
||
## 2. 统一架构
|
||
|
||
```text
|
||
页面按钮 / 对话指令
|
||
↓
|
||
统一业务命令与项目权限
|
||
↓
|
||
mini-openclaw 运行（run_id）
|
||
↓
|
||
数据卡 + Skills + 规则 + 经验 + 报告模板
|
||
↓
|
||
问题、补件、方案、报告、经验和时间事件
|
||
```
|
||
|
||
系统使用一个组件目录和两套角色业务方案：
|
||
|
||
- `corporate.pre-review`：客户经理提交正式评审前的风险筛查。
|
||
- `corporate.independent-review`：评审员独立复核及评审报告生成。
|
||
|
||
公共事实、确定性计算和正式规则保持同源；角色方案的深度、动作权限和输出不同。
|
||
|
||
## 3. 客户经理工作台
|
||
|
||
主线：选择项目 → 补充证据 → AI 预审 → 回应风险/现场核实 → 再次预审 → AI 预审报告 → 提交主审。
|
||
|
||
首版页面只保留：
|
||
|
||
- 我的项目：待补材料、待回应风险、最近预审、明确的下一步。
|
||
- 项目办理：材料与问题、AI 预审记录、报告、时间轴。
|
||
- 提交准备卡：材料、时效、必做检查、风险处理和报告状态，不使用来源不明的综合分。
|
||
- 现场尽调清单：由未闭环风险生成，支持说明和附件回填证据链。
|
||
|
||
客户经理使用系统默认方案，可选已发布专项 Skill，并可输入仅作用于本项目的自然语言检查要求；不能配置数据源、SQL、模型或发布公司规则。
|
||
|
||
## 4. 评审员工作台
|
||
|
||
主线：接收项目 → 独立复核 → 质疑补件 → 方案测算 → 评审报告 → 上会摘要 → 经验候选。
|
||
|
||
首版页面只保留：
|
||
|
||
- 我的待审：收件时间、排队时间、当前阶段、补件等待和下一步。
|
||
- 独立评审：查看送审包，但新建独立 `review_run_id`，不覆盖客户经理预审。
|
||
- 风险分歧：同意、证据覆盖、误报、遗漏、计算修正、现场核实、方案调整。
|
||
- 评审报告：统一核心要素，行业/部门模板可配置；一键生成上会摘要。
|
||
- 经验沉淀：系统预填经验候选，评审员只做确认、修改或放弃。
|
||
|
||
个人意见不自动成为公司经验；经验经评测、审核和发布后才能反哺客户经理预审，反复验证后才能升级为正式规则。
|
||
|
||
## 5. 配置管理员
|
||
|
||
管理端只保留三个入口：
|
||
|
||
1. 模型与运行：模型 URL、服务端 Key 引用、本地/私有云模型、连接测试和运行状态。
|
||
2. 数据与权限：统一数据连接、数据卡、字段口径、角色模板、人员和项目授权。
|
||
3. 业务组件：Skills、规则、经验、业务方案和报告模板的草稿、评测、审核、发布及回退。
|
||
|
||
数据连接按数据域统一配置，不为每个人复制连接；人员配置的是角色、项目和数据权限。管理员能配置权限，不代表自动获得全部项目内容。
|
||
|
||
## 6. 对话式业务入口
|
||
|
||
原 mini-openclaw 对话框调整为受身份和项目约束的便捷业务入口。页面操作和对话操作必须调用同一业务服务。
|
||
|
||
首版支持：
|
||
|
||
- 查询项目缺件、风险、最近预审和下一步。
|
||
- 上传材料到当前项目并进入项目材料版本及证据链。
|
||
- 发起 AI 预审或评审员独立复核。
|
||
- 生成相应角色的报告草稿。
|
||
- 打开项目、预审记录、报告和时间轴。
|
||
|
||
提交正式评审、定稿、发布组件、修改权限、删除资料和外发文件必须二次确认。
|
||
|
||
## 7. 报告模板
|
||
|
||
模板是展示协议，不是业务事实来源。首版包含：
|
||
|
||
- AI 预审报告（业务提交前）
|
||
- 独立评审报告
|
||
- 上会摘要
|
||
|
||
统一核心章节不可删除；允许按行业或部门增加章节。报告冻结模板版本，正文的重要事实与风险可点击查看执行依据。客户经理预审报告不作审批结论；评审员报告保留独立专业判断和责任边界。
|
||
|
||
## 8. 时间追踪与看板
|
||
|
||
客户经理阶段：资料收集、AI 预审、补件等待、报告整理、提交准备。
|
||
评审员阶段：收件排队、材料初核、独立审查、补件等待、复核、报告编制、内部审核、上会准备。
|
||
|
||
看板提供：
|
||
|
||
- 单项目高端时间轴和阶段占比。
|
||
- 业务端准备周期与评审周期两个口径。
|
||
- 中位数、P75、各阶段分布、补件轮次和报告修改轮次。
|
||
- 按角色、行业、月份筛选；个人只看授权项目，负责人看汇总。
|
||
|
||
不把外部等待算作人员实际处理时间，不做缺乏业务解释的个人排名。
|
||
|
||
## 9. SQLite 演示数据
|
||
|
||
使用 `backend/xingbang_data/project_assistant.sqlite3` 作为本地运行库，由版本化 fixture 自动初始化。新增规范化时间事件表，用于真实记录阶段开始、结束、角色、来源运行和耗时。
|
||
|
||
另提供 `backend/xingbang_data/xingbang_business_demo.sqlite3` 作为脱敏多表业务源，包含客户、项目、融资方案、多期财务、租赁物、保险、增信、征信、涉诉、还款来源和材料索引。数据卡通过只读参数化 SQL 读取指定字段并映射为标准字段，配置说明见《对公多表业务库与数据卡说明》。
|
||
|
||
演示最小数据集包含：
|
||
|
||
- DEMO-A：资料完整、可快速形成预审报告。
|
||
- DEMO-B：现金流缺失、负债口径冲突、设备重复及覆盖不足，可演示补件和重跑。
|
||
- DEMO-C：回款依赖，可演示评审经验发布后反哺预审。
|
||
|
||
数据库必须由 SQL schema 和固定 fixture 可重复生成；运行数据目录不进入 Git。
|
||
|
||
## 10. 首版验收流程
|
||
|
||
1. 切换客户经理身份，页面明显显示身份。
|
||
2. 打开 DEMO-B，查看提交准备卡和时间轴。
|
||
3. 上传补件并确认来源，发起 mini-openclaw AI 预审。
|
||
4. 点击任一历史预审查看冻结卡片、证据和执行轨迹。
|
||
5. 生成 AI 预审报告并提交评审。
|
||
6. 切换评审员身份，看到待审项目和评审耗时。
|
||
7. 发起独立评审，处理分歧，生成评审报告和上会摘要。
|
||
8. 将一条评审修正保存为经验候选并发布演示经验。
|
||
9. 对 DEMO-C 运行预审，确认已发布经验增加了核实动作。
|
||
10. 切换配置管理员，查看模型、数据权限和组件治理；管理员默认不自动打开项目内容。
|
||
11. 在对话入口查询项目、上传材料或发起检查，项目页面出现对应真实记录。
|
||
12. 运行 `python scripts/verify.py`，全部通过后方可构建和部署。
|
||
|
||
## 11. 业务易用性缺陷修复清单
|
||
|
||
共同验收原则：一眼看懂、一步到达、能选不写、技术信息后置；任何单条异常数据不得造成整页崩溃。
|
||
|
||
| 编号 | 问题 | 修复目标 |
|
||
| --- | --- | --- |
|
||
| BUG-001 | 缺少 mini-openclaw 原生入口 | 业务助手内增加项目上下文绑定的原生对话选项卡 |
|
||
| BUG-002 | 问题数量无法直达 | 概览卡点击直达未处理问题，并显示问题、影响和解决动作 |
|
||
| BUG-003 | 检查结果直接显示 JSON | 默认改为中文业务结论卡，技术明细折叠 |
|
||
| BUG-004 | 历史记录是技术日志 | 分类汇总、中文关键事件时间轴、对象可点击 |
|
||
| BUG-005 | 评审员卡片没有提交与等待时间 | 提交后进入公共待评审池；与客户经理提交事件使用同一时间源，按等待时长排序，评审员领取后停止排队计时并留痕 |
|
||
| BUG-006 | 评审员缺少全链路决策视图 | 数据来源、AI判断、客户经理说明、评审选择与报告串联 |
|
||
| BUG-007 | 时间轨迹渲染对象导致崩溃 | 详情安全格式化并提供异常数据降级显示 |
|
||
| BUG-008 | 时效页角色筛选与身份切换混淆 | 复用首页身份组件；管理员另设统计范围筛选 |
|
||
| BUG-009 | 项目评审池缺少独立入口和客户经理视图 | 新增统一“项目评审池”页面；评审员领取项目，客户经理查看自己的送审项目、撤回并重新推送 |
|
||
| BUG-010 | “方案比较”没有明确使用价值 | 从客户经理和评审员界面移除该功能，减少无效入口 |
|
||
| BUG-011 | 评审员页面只突出 AI 问题，容易把“AI 未报错”误解为“无需人工评审” | 改为覆盖全部必审事项的节点式三链评审，逐项形成评审员结论 |
|
||
| BUG-012 | 提交成功后仍停留在报告页，用户无法确认项目是否进入评审池 | 提交成功后直接进入项目评审池，高亮刚提交项目并明确显示提交时间和等待状态 |
|
||
| BUG-013 | 业务助手的人类消息多次调整后仍在中间显示，且缺少人类图标 | 用户消息占满独立消息行并强制靠右，右侧显示“本人”头像；发布后必须以云端实际资源验收，不能用本地结果代替 |
|
||
|
||
### BUG-009 项目评审池交互约定
|
||
|
||
- 顶部导航新增“项目评审池”，不再把评审池仅作为项目工作台的隐含首页。
|
||
- 评审员视图：显示待领取和本人已领取项目；按等待时长排序；卡片显示客户经理提交时间、等待时长、当前状态和“领取/继续办理”。
|
||
- 客户经理视图：只显示本人提交的项目；卡片显示提交版本、提交时间、等待时长、领取状态和评审进度。
|
||
- 客户经理可撤回尚未形成最终评审结论的当前有效送审版本；撤回必须二次确认，并同步终止该版本的排队或评审计时、通知当前评审员并写入操作留痕。
|
||
- 撤回后可重新推送。重新推送只替换评审池中的“当前有效版本”，不得删除或覆盖历史报告、输入快照、Skills/规则版本、评审动作和撤回记录。
|
||
- 同一项目在评审池中最多只有一个当前有效送审版本，避免重复领取和多人同时办理。
|
||
|
||
### BUG-010 方案比较移除约定
|
||
|
||
- 客户经理和评审员工作台删除一级“方案比较”页签及其操作界面。
|
||
- 不新增替代入口，避免用低频演示能力增加业务人员理解负担。
|
||
- 已形成的历史情景对象和兼容接口暂不删除，仅作为旧数据的只读追溯能力保留，不在新业务主线中展示。
|
||
|
||
### BUG-011 全链路节点式评审约定
|
||
|
||
- 评审员页面必须展示全部必审事项，AI 未发现异常不等于人工已完成评审，不能自动跳过或自动确认。
|
||
- 按主体信息、财务与现金流、租赁物、增信措施、征信与涉诉、交易结构等业务主题组织节点，避免按技术 Skill 名称组织页面。
|
||
- 每个业务节点固定为三条并行信息链：
|
||
1. 数据链：关键数据、材料来源、定位、口径一致性和缺失状态，来源可点击查看。
|
||
2. AI 判断链：AI 结论、理由、命中的 Skill/规则和证据；正常、待关注、异常分别显示明确文字、图标和颜色。
|
||
3. 评审决策链：评审员选择“认可 / 要求补件 / 不采纳 AI 判断”，并选择常用意见或补充简短说明。
|
||
- AI 认为有问题的节点使用醒目的红色；材料缺失或口径冲突使用橙色；检查正常使用绿色；尚未人工评审使用灰色。状态不能只依赖颜色表达。
|
||
- 默认优先展开红色、橙色和未评审节点；绿色检查项保持折叠，由评审员按业务章节一次确认，避免逐条点击增加负担。
|
||
- 页面顶部显示“已评审节点数 / 必审节点总数、异常数、待补件数”，点击数字可定位到对应节点。
|
||
- 所有必审章节形成明确人工结论后，才允许执行“批准并生成评审报告”；异常项须逐项闭环，正常项允许章节批量确认。仍有未评审章节、待补件或待现场核查事项时，按钮禁用并直接提示缺少哪些确认。
|
||
- 评审报告按相同业务节点汇总数据来源、AI 判断、评审员结论和意见，保证页面与最终报告一一对应。
|
||
- 每次评审判断由服务端自动绑定运行、冻结快照、证据编号、材料定位和 Skill/规则版本；不能由前端自行填写或删改追溯关系。
|
||
|
||
### BUG-013 业务助手消息对齐与发布验收约定
|
||
|
||
- 根因一：旧布局只给消息卡片设置最大宽度，用户气泡在该卡片内部仍从左开始，视觉上停在会话区中间。
|
||
- 根因二：前两次修复仅在本地完成，用户实际查看的是阿里云 `3200` 页面；验收环境判断错误，导致“代码已改”与“客户看到已改”不一致。
|
||
- 用户消息必须占据一整行，再由行内容强制右对齐；气泡宽度最多占会话区 75%，窄屏最多占 88%。
|
||
- 用户气泡右侧显示带“本人”语义的人类头像；助手消息继续靠左显示机器人图标，双方身份无需阅读文字即可区分。
|
||
- 回归测试必须同时检查整行右对齐规则、人类头像组件和移动端最大宽度。
|
||
- 涉及客户正在查看的云端缺陷时，完成标准包括：代码验证通过、提交并推送、云端容器健康、云端返回的新 CSS/JS 包含修复标识、实际访问页面完成刷新。
|