Files
wecom_it_smart_desk/docs/07-项目管理/任务说明书/任务说明书-85-批次3-P1核心重构.md
T
Simon 44e77dcb0e chore(docs): docs/ 目录全面重新编号 + 重组
**重构前**(旧编号 02-11):
- docs/02-产品需求/      → 00 产品规划/PRD
- docs/03-技术架构/      → 01-05 子目录散落
- docs/04-原型设计/      → 01-02 产品设计(HTML 原型)
- docs/05-原型设计/      → screens/
- docs/06-测试素材/      → 02-E2E / 03-功能 / 04-版本测试
- docs/07-项目管理/      → 任务说明书/日报/计划
- docs/08-安全审计/      → 审计报告
- docs/09-堡垒运维/      → toolbox / deploy
- docs/10-项目管理/      → 任务说明书(重复)
- docs/11-历史归档/      → deploy-nas-archived

**重构后**(新编号 00-07,语义化):
- docs/00-产品开发流程与文档管理规范.md
- docs/00-版本迭代总览.md
- docs/01-产品文档/      (PRD/原型/认证/会话/AI 服务/坐席/集成)
- docs/02-技术文档/      (技术方案/架构图/重构记录/前端改造/实现配置)
- docs/03-测试文档/      (E2E/功能用例/版本报告/缺陷单)
- docs/04-运维文档/      (部署运维/运维指南)
- docs/05-运营文档/      (品牌推广/用户手册)
- docs/06-安全审计/      (审计报告)
- docs/07-项目管理/      (任务说明书/日报/计划/看板)

**净收益**:
- 目录编号与产品文档管理规范对齐(按文档阶段 01-07 编号)
- 消除 02-产品需求 与 10-项目管理 的编号重叠
- 子目录按文档类型分组(如 01-产品文档/00-产品规划、01-产品文档/01-认证与登录)
- 把运维/安全/项目管理从 0X 散落改为 04/06/07

合计 494 文件 + 78495 行 / - 14076 行
2026-08-03 18:46:55 +08:00

89 lines
3.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 任务说明书 — 批次 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 串行叠加最坏 45sB6
**方案**
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 分支卡片渲染;保留 L19approval_card#80 后快捷申请真实使用)与 L103ai_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 | 创建任务 | 宋献 |