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

3.7 KiB
Raw Blame History

任务说明书 — 批次 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 分支卡片渲染;保留 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 创建任务 宋献