- 新增 web2/ 前端:任务卡看板、风险雷达、决策日志、我的团队、快捷指令 - ChatPanel 增强:风险卡置顶、案卡接入、起诉状向导、语音输入 - 事项看板:点击查看详情弹窗、断点续接(恢复历史对话+matterId) - 保密模式恢复:密码验证后重建内存 session,保留多轮上下文 - 多轮对话:ask/ask-stream/ask-analyze 注入 session 历史,AI 有上下文 - 追问优化:紧扣用户问题,不再偏离主题(社保问社保,工伤问工伤) - 对话区可滚动,输入区固定可见 - 状态机放宽:允许从任意非终态转到 pending_expert - session 存活检查端点,后端重启后自动重建 session - DB migration:风险推送表、案卡表 Generated with [Devin](https://devin.ai) Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
102 lines
3.6 KiB
Markdown
102 lines
3.6 KiB
Markdown
# ADR-002 UIUX 范式转变:从"对话工具"到"经营智囊"
|
||
|
||
- **状态**:待确认
|
||
- **日期**:2026-08-30
|
||
- **决策者**:产品负责人 + 技术负责人
|
||
- **关联**:PRD v2.0、CHG-20260830-001
|
||
|
||
## 背景
|
||
|
||
BossAi v1.0 上线后,用户调研发现中小企业老板的核心痛点未被满足:
|
||
|
||
1. **对话流程过长**:提问→追问→确认→分析,老板 30 秒内拿不到要点
|
||
2. **无事项管理**:同时处理多件事时,无法可视化追踪进度
|
||
3. **AI 被动响应**:老板不问,AI 不说,缺少主动提醒
|
||
4. **专家关系断裂**:咨询过的专家无沉淀,每次重新找
|
||
5. **决策无复盘**:做完就忘,无法反哺 AI
|
||
|
||
根本原因:v1.0 是"AI 对话产品",老板要的是"我的经营智囊"。
|
||
|
||
## 选项
|
||
|
||
### 选项 A:保持对话优先,局部优化
|
||
|
||
- 优化 ChatPanel 追问体验、风险卡展示
|
||
- 保留当前按场景分页的导航
|
||
- **优点**:改动小,风险低
|
||
- **缺点**:不解决根本痛点,老板仍觉得"不像我的智囊"
|
||
|
||
### 选项 B:任务卡片优先,对话为手段(推荐)
|
||
|
||
- 新增"老板台"(今日要事)+ "事项看板"(案卡)
|
||
- 对话成为案卡的推进手段,不是目的
|
||
- AI 主动推送风险,专家沉淀为"我的团队"
|
||
- 移动端重构为底部 Tab + FAB
|
||
- **优点**:直击痛点,产品定位清晰
|
||
- **缺点**:重构量大,需分阶段交付
|
||
|
||
### 选项 C:完全重写
|
||
|
||
- 抛弃现有代码,重新设计
|
||
- **优点**:无历史包袱
|
||
- **缺点**:浪费已验证的 ChatPanel/要素化立案/事实确认等核心能力
|
||
|
||
## 决策
|
||
|
||
选择 **选项 B**:任务卡片优先,分三阶段交付。
|
||
|
||
核心原则:
|
||
1. **保留并优化 ChatPanel**,不推翻已验证的对话能力
|
||
2. **新增案卡层**,包裹现有对话,提供事项管理视角
|
||
3. **导航重组**,从"按场景分页"转向"按事项聚合"
|
||
4. **移动端重构**,底部 Tab 替代 Sidebar 抽屉
|
||
|
||
## 后果
|
||
|
||
### 收益
|
||
|
||
- 产品定位从"工具"升级为"智囊",差异化竞争力提升
|
||
- 老板可同时管理多件事,降低流失率
|
||
- AI 主动推送增加打开频次
|
||
- 专家关系沉淀提升续费意愿
|
||
|
||
### 成本
|
||
|
||
- 三阶段共约 6 周(每阶段 2 周)
|
||
- 后端新增 3 张表(matters/risk_alerts/expert_relations)
|
||
- 前端导航重构,移动端底部 Tab 为较大改动
|
||
- 需新增 10 个 API 端点
|
||
|
||
### 风险
|
||
|
||
- 范式转变用户不适应 → 阶段一保留独立入口,案卡为增量
|
||
- 移动端底部 Tab 重构 → 与 Sidebar 共享 NavConfig,降低重复
|
||
|
||
## 实施策略:新目录并行开发
|
||
|
||
**决策**:在 `web2/` 新目录开发 2.0 前端,保留 `web/` 原样不动。
|
||
|
||
| 维度 | 说明 |
|
||
|---|---|
|
||
| 原目录 `web/` | 保留为 v1.0,继续可用,不做任何改动 |
|
||
| 新目录 `web2/` | 2.0 全新实现,独立 package.json、独立端口 |
|
||
| 后端 `api.py` | 共享同一后端,新增端点向后兼容,不破坏 v1.0 调用 |
|
||
| 数据库 | 共享同一数据库,新增表通过 migration 脚本添加 |
|
||
| 切换 | 2.0 验证通过后,可切换 Nginx/反代指向 web2/dist,或直接替换 web/ |
|
||
|
||
**端口分配**:
|
||
- `web/` (v1.0):5173(保留)
|
||
- `web2/` (v2.0):5174
|
||
|
||
**优点**:
|
||
- v1.0 用户零影响,可随时回退
|
||
- 2.0 可大胆重构,无历史包袱
|
||
- 同一后端,API 契约清晰
|
||
|
||
## 回滚思路
|
||
|
||
- 阶段一可独立回滚:老板台/案卡为新增页面,不影响现有 ChatPanel
|
||
- 阶段二快捷指令为新增组件,不替换现有话题选择
|
||
- 阶段三风险雷达为后端新增任务,可关闭不影响主流程
|
||
- 若整体回滚,删除 web2/ 目录和新增表即可,web/ 和现有功能不受影响
|