Simon
facc04aa65
本提交为 .git 对象库损坏后的重建提交，内容等价于原先三个本地提交 （5e2fd4c2 / 57a53c98 / 5d7e1873）的累积结果，未做任何额外改动。 一、docs 结构整改（整改 #14） 根因：重构时新结构为 untracked 文件，执行 git stash（未带 -u）未纳入， 随后 git reset 拉回 HEAD 旧 tracked 树，导致旧树复活、新旧两棵目录 树并存于 docs/，共 791 文件、双分类体系冲突。 修复动作： - b2 同名异主题文件改名迁移保全 9 个 - C 类 39 个孤立文件按主题正确归类 - A/B1 类 222 个重复文件删除（新结构已有内容副本） - 9 个旧独有空目录删除 - 270 处内部引用按 verified 映射改写 - 整改记录 #14 登记于 04-运维文档/部署运维 结果：docs 791 → 569 文件，顶层仅规范 8 类 + 治理文件，单树恢复。 残留：约 20 处指向从未存在文件的陈旧死链，归入独立文档卫生任务。 二、compose 双目录对齐（消除踩坑 A） - docker-compose.yml：nginx 前端挂载全部由根目录 frontend-*/dist 改为 src/frontend-*/dist（h5 / agent / admin / terminal） - docker-compose.dev.yml：dev 服务 build context 与卷同步改 src/ - 效果：本地 docker compose up 不再把根目录 stale dist 挂回， 与线上一致，分叉隐患消除（已 docker compose config 校验通过） 防复发铁律： - 重构须提交；仓库修复须 git stash -u 或先 commit - 新结构须 git add 并提交，避免再次 untracked 复活 - H5 改动只动 src/frontend-h5/，禁改根目录遗留 frontend-*/
54 lines
2.2 KiB
Markdown
54 lines
2.2 KiB
Markdown
# IT智能服务台 — 技术架构优化建议
|
||
|
||
> **版本**: v1.0
|
||
> **日期**: 2026-07-10
|
||
> **作者**: 宋献
|
||
> **类型**: 技术 - 架构优化
|
||
> **源自**: 方案-全套改造建议与推广-v1.0.md
|
||
|
||
---
|
||
|
||
## 一、后端架构优化
|
||
|
||
| 改造项 | 现状 | 建议 |
|
||
|--------|------|------|
|
||
| **WS断连体验** | 断连后3秒轮询降级，但用户无感知 | 增加"网络重连中"toast提示，重连成功后自动恢复 |
|
||
| **消息缓存策略** | `h5_messages_cache` 7天/100条 | 增加缓存命中率监控，按会话热度动态调整上限 |
|
||
| **头像代理** | `/api/avatar/proxy` 解决COEP/CSP | 增加缓存层，避免每次请求都代理 |
|
||
| **审批意图识别** | Dify API Key已配置 | 增加fallback策略，Dify不可用时降级为关键词匹配 |
|
||
| **历史消息共享** | P1-20 待开发 | 邀请时支持选择共享范围（全部/最近N条/从某条开始） |
|
||
|
||
---
|
||
|
||
## 二、日志与监控优化
|
||
|
||
| 建议 | 理由 |
|
||
|------|------|
|
||
| **日志结构化** | 后端日志增加结构化字段（会话ID/坐席ID/操作类型），便于审计分析 |
|
||
| **性能监控** | 接入前端性能监控（首屏时间、WS连接稳定性），量化体验提升 |
|
||
|
||
---
|
||
|
||
## 三、技术债务与重构
|
||
|
||
| 改造项 | 价值 | 关键动作 |
|
||
|--------|------|---------|
|
||
| **知识库真可用** | 知识建议→训练师审批→入库→AI引用，全闭环 | 1. 取消注释 `knowledge_iteration_router` 2. 挂载API 3. Neo4j图存储写入 4. 审批流打通 |
|
||
| **置信门控** | 低置信度问题自动转人工 | Dify 返回 confidence score → 阈值判断 → 自动转人工 |
|
||
|
||
---
|
||
|
||
## 四、技术层面其他建议
|
||
|
||
| 建议 | 理由 |
|
||
|------|------|
|
||
| **A/B测试框架** | AI回复策略、置信度阈值等可A/B测试，数据驱动调优 |
|
||
| **灰度发布机制** | 前端改造分批灰度，降低全量发布风险 |
|
||
| **性能监控** | 接入前端性能监控（首屏时间、WS连接稳定性），量化体验提升 |
|
||
|
||
---
|
||
|
||
> **关联文档**：
|
||
> - 产品功能层面: `01-产品文档/00-产品规划/全套改造建议-产品功能层面-v1.0.md`
|
||
> - 前端改造建议: `02-技术文档/前端改造/前端改造建议-v1.0.md`
|