Files

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

5.2 KiB

Raw Blame History

任务说明书

版本: v1.0 | 日期: 2026-07-24

📋 基本信息

项目	内容
任务名称	H5选项交互消息重复处理
任务ID	#125
优先级	🔴P0
类型	Bug修复
状态	已完成
负责人	Simon / 助理
创建日期	2026-07-24
计划完成日期	2026-07-24

📥 输入项来源

产品需求

来源文档	相关章节	说明
`01-产品文档/03-AI服务/PRD-REQ-AI-004-AI回复来源标识-v1.0.md`	§1	AI对话交互流程

技术方案（参考）

来源文档	相关章节	说明
`02-技术文档/实现配置/AI对话链路全栈改造实施计划-v1.0.md`	§3.6 / §4.5	选项回传链路（option_select）、WS消息处理

⚠️ 本次修复是对现有选项回传链路的Bug修复，根因是前端消息处理逻辑问题，不涉及技术方案变更。

需了解的现有代码（历史现状）

模块/文件	说明	需了解的内容
`frontend-h5/src/stores/conversation.ts`	H5消息状态管理	sendOptionSelect函数、消息去重机制

📤 输出成果要求

交付物清单

#	交付物	类型	说明
1	`frontend-h5/src/stores/conversation.ts`	代码	修复选项选择消息重复逻辑
2	`docs/04-运维文档/部署运维/00-标准故障排查手册.md`	文档	新增CASE-20260724-01

🎯 问题描述

现象

员工端H5点击AI提供的选项后，出现两条相同的员工消息（如"检查同步设置"）。

时间特征

一条立即出现
另一条约3秒后出现（轮询间隔）

坐席端表现

坐席端只看到一条消息（说明后端只存储了一条，问题在前端显示）。

🔍 根因分析

直接原因

前端点击选项时：本地立即添加消息（message_id = option_select_${timestamp})
后端收到后：存储到数据库（message_id = UUID，与前端不同）+ 广播给前端
前端收到后端广播的消息时，因为 message_id 不同，去重检查失效，导致重复添加

根本原因

前端本地添加的消息与后端存储的消息 message_id 不同
去重机制基于 message_id 无法识别这种场景

🛠 修复方案

核心思路

前端不再本地立即添加消息，只发 WS 给后端，等后端存储后通过轮询/广播回来再添加，确保消息来源唯一。

修改内容

修改 frontend-h5/src/stores/conversation.ts 中的 sendOptionSelect 函数
移除本地立即添加消息的代码
依赖后端回传后添加消息

✅ 验证结果

H5点击选项后只显示一条消息，问题已修复。

📎 关联文档

docs/04-运维文档/部署运维/00-标准故障排查手册.md - CASE-20260724-01
.workbuddy/memory/MEMORY.md - 前端消息处理规范

💡 设计改进建议（补充到产品设计文档）

问题反思

本次Bug的表层是技术问题（前后端ID不一致），但深层是产品设计文档中没有定义「用户点击选项后的界面反馈是什么」。

应该补充到产品/设计文档的内容

文档	需补充内容	目的
PRD 需求文档	明确「用户交互反馈」规范	定义「选中即禁用」还是「显示待确认消息」
UI/UX 设计稿	补充「选项卡选中态」设计	选中后的视觉表现（变灰/高亮/加载中）
技术设计文档	补充「消息添加时机」原则	前端不应在收到后端确认前添加消息

具体需要确认的产品问题（以「用户点击AI选项」为例）

问题	选项A	选项B	选项C
点击后界面立即显示什么？	显示"发送中..."状态	显示该选项内容作为消息	按钮变灰+显示处理中
何时显示正式消息？	等后端返回后	等后端返回后	等后端返回后
如果后端失败？	显示错误提示	消息变红/撤回	按钮恢复+提示错误

规范改进建议（适用于所有类似交互）

阶段	规范要求
需求阶段	PRD 必须包含「用户交互反馈」章节，明确定义每个操作的即时界面表现
设计阶段	UI 设计稿必须包含「状态变化」标注（正常/禁用/加载/错误）
技术设计阶段	技术方案必须写明「前端消息添加时机」——是本地先添加还是等后端确认
验收阶段	用例测试必须覆盖「网络异常/超时」场景，验证界面反馈是否符合预期

5.2 KiB Raw Blame History Unescape Escape