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-*/
89 lines
3.7 KiB
Markdown
89 lines
3.7 KiB
Markdown
# 任务说明书 — 批次 3（P1 核心：编排层管线化 + WS 路由清理）
|
||
|
||
> **版本**: v1.0 | **日期**: 2026-07-17
|
||
|
||
---
|
||
|
||
## 📋 基本信息
|
||
|
||
| 项目 | 内容 |
|
||
|------|------|
|
||
| **任务名称** | v4.0 批次 3：P1 核心重构（编排层管线化 + D1 意图合并 + WS 死路由清理） |
|
||
| **任务ID** | #85 |
|
||
| **优先级** | 🟠 P1 |
|
||
| **类型** | 架构重构 |
|
||
| **状态** | 待开始 |
|
||
| **负责人** | 宋献 |
|
||
| **创建日期** | 2026-07-17 |
|
||
| **计划完成日期** | 2026-07-26 |
|
||
| **预估工时** | 4 天 |
|
||
| **风险等级** | 🔴 高（改动主流程，上线后观察 24h） |
|
||
|
||
---
|
||
|
||
## 📥 输入项来源
|
||
|
||
| 来源文档 | 相关章节 |
|
||
|----------|----------|
|
||
| `docs/02-技术文档/重构记录/00-v4.0重构总方案.md` | §三 批次 3、D1 决策 |
|
||
| `docs/02-技术文档/重构记录/01-问题验证清单.md` | B6/B7/F4/F5 |
|
||
|
||
---
|
||
|
||
## 📤 输出成果要求（2 个子项）
|
||
|
||
### P1-3 编排层管线化重构（3d，核心）
|
||
|
||
**问题**：`process_h5_ai_reply()`（h5_ai_task.py:996-1307）主函数 11 对 try/except、最深 4 层缩进、全文 26 对；路由 detect 与主 Dify 串行叠加最坏 45s（B6）
|
||
|
||
**方案**：
|
||
1. **D1 激进合并**（用户已决策）：
|
||
- `ai_service.get_structured_reply()` 扩展解析 `intent_type/business_category/routing_confidence`（同一 Dify 应用同一 key，已验证）
|
||
- 编排层在主调用返回后做路由后处理：`intent_type=='non_it_routing' 且 confidence≥阈值` → 走 `send_contact_card`
|
||
- 删除编排层对 `detect_routing_intent` 的串行调用
|
||
- **风险兜底**：实施前先用 5 条真实消息验证 Dify 稳定输出 intent 字段；不稳定则退回方案 B（detect 与主调用 `asyncio.gather` 并行，仍 30s 总预算收口）
|
||
2. **管线化**：主流程拆为步骤函数，每步返回 `Handled | Continue`：
|
||
`load_conversation → enrich_content → fast_lane → byod_intercept → graph_lookup → ai_inference → post_process`
|
||
步骤级 try/except 收拢到管线执行器一处；**主函数目标 < 100 行、try/except ≤ 3 对**
|
||
3. v3.0/v3.1 两处关键词兜底块（h5_ai_task.py:1205-1241、1252-1272）合并为单一 `keyword_fallback(content)`
|
||
|
||
**验证**：路由消息端到端 < 35s（合并后应 ~主调用耗时）；pytest 编排管线用例；radon cc 复杂度显著下降
|
||
|
||
### P1-5 WS 死路由清理 + 审批卡片渲染点收敛（1d）
|
||
|
||
**问题**：前端 `useH5WebSocket.ts` 3 种死路由（ai_reply_chunk/pending_close_request/quiz_diagnostic_answer）；ApprovalCardModal 3 处渲染点（MessageBubble L19/82/103），L82 已死
|
||
|
||
**方案**：
|
||
1. 删除 3 个死 case 及 store 对应 handler
|
||
2. 删除 MessageBubble L82 text 分支卡片渲染；保留 L19（approval_card，#80 后快捷申请真实使用）与 L103（ai_structured 内嵌）
|
||
|
||
**验证**：grep 无死路由残留；三种审批卡片场景（AI 命中/关键词兜底/快捷申请）均正常渲染
|
||
|
||
---
|
||
|
||
## 🔧 验收标准 + 24h 观察指标
|
||
|
||
- [ ] `process_h5_ai_reply` < 100 行，try/except ≤ 3 对
|
||
- [ ] 路由消息端到端 < 35s
|
||
- [ ] **上线后观察 24h**：AI 回复到达率 ≥99%、平均响应 ≤20s、转人工率不升
|
||
- [ ] 异常时回滚至批次 2 状态
|
||
|
||
---
|
||
|
||
## 📞 依赖与阻塞
|
||
|
||
| 依赖 | 说明 |
|
||
|------|------|
|
||
| 批次 2 完成（#84） | D1 合并依赖统一 Dify 调用点（P1-2） |
|
||
| #80/#82 已上线 | P1-5 渲染点收敛依赖 P0-3/P0-5 已生效 |
|
||
|
||
**文档同步**：架构文档新增「智能回复链路 v4」章节（分层架构图）；填写 `docs/02-技术文档/重构记录/04-批次3-P1核心执行记录.md`。
|
||
|
||
---
|
||
|
||
## 📈 变更记录
|
||
|
||
| 日期 | 变更内容 | 变更人 |
|
||
|------|----------|--------|
|
||
| 2026-07-17 | 创建任务 | 宋献 |
|