✕

📋 坐席工作台原型 v1.7 变更说明

基线选择：以 v1.3（2447 行全量高保真原型）为骨架，叠加 v1.4~v1.6 的四项演进 + 本次会话条目操作菜单改造，产出 v1.7，作为开发的唯一依据。
为什么不基于 v1.6：v1.4~v1.6 是为论证「B 方案分栏」「全屏流程图」而新画的专题示意原型（961~1088 行），不是 v1.3 的增量演进。其左栏 .conv-item 只有「头像/姓名/时间/摘要/未读数」5 个字段，中栏 .user-info-bar 无任何操作按钮区，保真度落后真实代码两代。直接在 v1.6 上加三点菜单，会得出「条目右侧有大片空槽」的错误结论。

改动组 A — 回填 v1.4~v1.6 的四项演进

• A1 · B 方案分栏：左栏 260px 固定（flex-shrink:0，原 280px 可伸缩）／中栏 flex:1.5／右栏 flex:1，中右恒 6:4，右栏取消 max 上限。
• A2 · 全屏流程图浮层：右栏「排查步骤」新增「⛶ 全屏查看」，可全屏研读完整决策树；关闭后回到右栏原状态（展开/收起态保留）。Esc 可关。
• A3 · AI 智能推荐改纵向堆叠：由横向滚动卡片行（display:flex; overflow-x:auto，一屏仅见 1-3 条需横滑）改为 flex-direction:column 纵向堆叠，每条占满右栏宽度。保留原信息密度：数字快捷键徽标 + 方案标题 + 置信度药丸 + 两行截断正文，点击回填输入框。
• A4 · 工具栏重组 + 图标统一：工具栏整体上移左对齐紧贴输入框左上角。常规组「✂️截图／📷拍照／😊表情／📎文件／👥邀请」，AI 组「💡自动补齐／🎚️语气／🖌️润色／🔄改写」，两组间一条分隔线。AI 按钮纯 emoji 无文字标签，与常规按钮共用同一 .tb-btn 样式（同尺寸/圆角/悬停态/透明度），AI 组不带高亮底色（已移除 .toolbar-right{background:var(--accent-soft)}），仅用原生 title 悬浮提示。

改动组 B — 左栏会话条目回填真实字段（🔴 高风险项 R-2 的收口）

v1.3/v1.6 的条目只有 5 个字段，真实 ConversationItem.vue:11-149 有三行结构。本次逐项对齐：48×48 头像 + 新消息圆点／第一行 📌置顶 📋代办 图标 + 姓名(省略) + 6 类 tag-badge（VIP／招手／需介入／情绪／坐席名／⏳待确认）+ 最多 4 个 16×16 优先级图标／第二行 摘要 + 时间／第三行 5 星紧急度 + 「接手」「退出」link／右侧处理对象缩略头像。

关键：原型如实还原了真实拥挤度。左栏 260px − margin 6×2 − padding 10×2 = 条目内可用仅 228px；头像占 56px、缩略头像占 36px，.conversation-info 只剩约 136px。请评审时按这个真实空间判断落位，而不是一个宽松的假条目。

改动组 C — 三点按钮 + 右键菜单

• 落位（决策 D-5）：三点按钮替换 .conv-target-avatar —— hover 时缩略头像 opacity:0 淡出、三点 opacity:1 淡入，同一栅格位、零布局抖动。命中区 24×24，图标 MoreFilled 14-16px。默认隐藏，:hover / .is-menu-open / :focus-visible 时显示（保证键盘可达）。
  未采用「并列插到缩略头像右侧」：会再吃掉 24px，信息区压到约 108px，第一行的 tag 与优先级图标将严重挤压。
• 双触发器（决策 D-3）：三点按钮为主入口（发现性），右键为快捷方式（效率）。二者共用同一单例菜单与同一菜单项定义，不是两套实现。坐席环境已确认为普通 PC 浏览器，无 VDI/触摸屏顾虑。请在原型上直接右键任一会话条目试一下。
• 菜单定位（D-6）：placement="bottom-end"，宽 140px，视口下缘不足时自动翻转 top-end（滚到列表底部右键即可验证）。
• 🔴 菜单必须单例、挂 ConversationList 层（D-4）：左栏存在双重 overflow 裁剪（.workspace-sidebar{overflow:hidden} + .conversation-list-scroll{overflow-x:hidden}），任何挂在条目内的 position:absolute 菜单横向必被裁掉、列表首尾纵向被裁。合规路径只有两条：position:fixed + 视口坐标，或 Teleport 到 body。
  单例的第二个理由：PRD-011 U-5 虚拟滚动会回收复用条目 DOM，菜单挂条目内会随 reference 销毁而错位/残留。条目只负责 emit('open-menu', {id, x, y})。
• z-index：菜单取 2000 对齐 Element Plus popper 基线。不可沿用 MessageItem.vue 的 1000 —— 会被 EP 的 dropdown/popover/message-box 盖住。

菜单项可见性矩阵（架构核查 §4.4）

菜单项	显示条件	禁用条件	动态文案	后端权限
接单	status==='queued'	—	「接单」	update:all
置顶 / 取消置顶	is_mine || is_collaborator	—	is_pinned → 「取消置顶」	🔴 update:own
代办 / 取消代办	is_mine || is_collaborator	—	is_todo → 「取消代办」	🔴 update:own
转接	status==='serving' && is_mine	无可用坐席 → 禁用 +「暂无可用坐席」	「转接」	update:all
接手	can_grab && !is_mine && status==='serving'	—	「接手」	update:all
退出协作	is_collaborator && status==='serving'	—	「退出协作」	—

🔴 置顶/代办是后端 update:own 权限（conversations.py:374, 467），非本人会话点了会 403。必须靠显示条件在前端拦住，不能靠后端报错兜底。原型中「赵敏」「吴明」两条他人会话的菜单里看不到置顶/代办，「周芳」因我是协作者可以看到 —— 请对比这三条验证。

菜单为空时三点按钮整体不显示（如已结单的历史会话），避免给出一个点开只有「无可用操作」的空菜单。

本轮由产品决策的三项（架构给了倾向，此处为定稿结论与理由）

• Q-3 转接的坐席选择 → 独立 Dialog（采纳架构建议，不做二级菜单）。理由：菜单宽仅 140px，而坐席项需显示「姓名 + (当前负载/上限)」，中文 3 字姓名 + (3/8) 已接近 96px，再叠加滚动条与 hover 态即贴边；坐席超过 8 人还需搜索框，二级菜单承载不下。更关键的是，260px 窄栏内嵌套二级 popper 在视口右下角需同时做水平 + 垂直双向翻转，组合态过于脆弱。Dialog 还带来一个额外收益：中栏保留的「转接」与左栏菜单的「转接」共用同一个 Dialog，两入口 UI 完全一致，不会出现「同一动作两种选人界面」。
• Q-4 「接手」「退出协作」→ 收进菜单，但第三行 link 按钮保留不动（双入口）。理由：第三行 grab-btn/leave-btn 是数据驱动的常显 link，它承担的是「这条会话可以被你接手」的邀约信号，需要在扫视时被看见；而三点按钮默认隐藏、hover 才出现，无法替代这个信号。反过来，右键路径下鼠标不在第三行按钮上，菜单里没有「接手」会造成右键功能残缺。故两者并存。
  ⚠️ 给开发的硬约束：第三行按钮的显示条件是 showGrab && can_grab（showGrab 是 List 层按 section 传的 prop），菜单项若另写一套判据，会出现「条目上没有接手按钮、但右键菜单里有」的不一致。菜单项「接手」必须复用与 grab-btn 完全相同的显示条件表达式，由 useConversationMenuItems 统一出口。
• Q-5 「结单」→ 不进左栏菜单（采纳架构建议）。理由有二：其一，结单需走摘要确认 Dialog（ChatArea.vue:448-502），在左栏触发一个模态流程属路径错位——坐席点完还得回中栏确认摘要；其二，结单与转接、摇人同属「对话过程动作组」，应整组留在中栏，拆开会重演「同类动作入口劈成两处」的问题。

改动组 D — 中栏 UserInfoBar 调整

• 删除「📥 接单」「📌 置顶」「📋 代办」3 个按钮。接单本就发生在打开会话之前，左栏是其自然场所，且原按钮在 status!=='queued' 时恒为 disabled 的「已接单」，长期占位却不可点，删除是净收益；置顶/代办属列表组织行为，其效果只在左栏可见，操作与反馈同处一栏更内聚。
• 保留「🔄 转接」，与既有的「🤝 摇人」「✅ 结单」并列。三者构成语义一致的对话过程动作组：转接=把这件事交出去／摇人=把人拉进来／结单=做完了，都在坐席读完描述、注意力与鼠标都在中栏的那一刻触发。若把转接赶到左栏，交互步数从 3 步涨到 6 步，且「在会滚动、会因置顶与紧急度动态重排的三分区列表里定位当前会话」本身就有成本。⚠️ 后人请勿误以为「转接」是漏删——这是明确保留项（决策 D-2）。

C-6 · 中栏 A/B 对比图 — 请视觉对比后定夺

你已选「删 3 留转接」（A 方案 = 当前 v1.7 已落地）。但「把 4 个全收进中栏自己的『⋯』菜单」是另一个候选思路——它把顶栏视觉元素从 6 件压到 3 件，缺点是接单/置顶/代办需多一步点开⋯。下图并列两份中栏 UserInfoBar 布局。

对比要点：A 方案（左，已落）—— 接单/置顶/代办走左栏是它们的"自然场所"，中栏保持"对话过程动作"语义一致组（转接/摇人/结单 = 交出去/拉进来/做完了）；B 方案（右，备选）—— 把 4 个全收回中栏顶栏则失去了"左栏即列表组织"的语义清晰度，且接单需要走到顶栏，不如 A 自然。请视觉确认 A 方案符合你的预期，或基于此图提出 B 方案的进一步变体。

一处必须澄清的既有误解

「接单/置顶/代办/转接 4 个按钮丢失了」——丢失发生在原型侧，不是代码侧；起始版本是 v1.4，不是 v1.5。
逐版本关键词计数：v1.0~v1.3 四个按钮均存在（v1.0 原文见 :1559-1567）；v1.4.archive 起计数全部归零。而真实运行代码中，四个操作从未丢失、且全部是真闭环（UI → handler → store → api → 后端端点，四个端点均带权限装饰器）。请勿据「原型里没有」推断「功能没做」。

与 PRD-011 的前向兼容

PRD-011 Phase 2 要做「统一 ListItem（含 kind 判别式）+ 条目组件支持会话态与任务态」。本次菜单若硬编码进 ConversationItem.vue，Phase 2 必然重写。因此建议的抽象边界是：抽菜单壳、不抽业务动作 —— WorkItemActionMenu.vue（纯 UI 壳，零业务逻辑，不认识 conversation/approval/ticket）+ useConversationMenuItems.ts（承载全部可见性规则，可单测，Phase 2 原样复用）。
⚠️ 三类 kind 的反馈模型根本不同：会话操作是服务端真闭环（点完即生效）；审批是降级跳转（点完只是跳走，状态由企微回调异步回写）；工单当前读链路即断。菜单项定义须携带 execMode: 'direct'|'redirect'|'disabled'，由容器按 mode 分派反馈策略。若共用一套「点击 → toast 成功」的反馈模型，就会重演 PRD-011 §3.1 定性为 P0 的那个错误（绿色成功提示 + 外部系统实际未变更）。

验收提醒

禁止以 toast 成功作为验收依据（PRD-011 §3.1 既有教训）。会话侧四个操作的验收标准是：操作后后端状态真实变更且列表刷新后条目呈现对应变化（如置顶后条目上浮、代办后出现 📋 图标）。另需专门验证：非本人会话的菜单中不出现置顶/代办项（403 前端拦截），以及后端返回 403 时前端给出明确文案而非静默（现状 stores/conversation.ts:539-541 仅 console.error，用户无任何感知，属既有缺陷，建议一并修）。

评审操作提示

• 左栏任一条目 hover → 右侧缩略头像淡出、三点按钮淡入（同位替换，观察是否有布局抖动）。
• 点击三点按钮，或在条目上直接右键 → 弹出同一菜单。滚到列表底部再右键，验证向上翻转。
• 对比「张伟(queued)」「陈芳(serving本人)」「李娜(已置顶已代办)」「赵敏(他人)」「周芳(我是协作者)」五条的菜单差异。
• 「刘洋」一条设为无可用坐席，其菜单中「转接」为禁用态并提示「暂无可用坐席」。
• 顶栏「会话状态」开关：模拟会话进行中/已结束，验证右栏复盘三模块显隐。右上角可切换深/浅色主题。