# SSV Nexus · 讨论模块升级需求文档

> **版本**：v1.0  
> **日期**：2026-04-30  
> **负责人**：西比柚（设计）  
> **状态**：Demo 评审阶段

---

## 一、需求背景

### 1.1 现状问题

当前 Nexus 的评论区沿用乐问/KM 的扁平评论模式：

- 所有评论混排在同一个列表中，不同议题的讨论相互交叉
- 仅靠 @人名 来关联上下文，人多话题多时难以追溯完整对话脉络
- 评论是"终点"——讨论完就散了，没有结论承接和行动转化能力
- 通知较弱——除非被 @ 否则不知道有人跟进了你关心的议题

### 1.2 用户反馈

> "建立能够讨论起来的交互，而不是评论和留言板"  
> "KM 的留言是比较难讨论起来，除非比较激烈的观点吵架"  
> —— brantli(李哲)，2026-04-29

### 1.3 产品规划对齐

Nexus Event #3「一些新的思考，即将到来的新体验」（2026-04-29 发布）明确提出：

> "评论具备局限性，讨论能放大可能性。目前阅读 topic 仅能跟评论回复，但我们更倾向营造讨论氛围，所以评论回复区会等做一些升级改造。"

### 1.4 参考产品

| 产品 | 机制 | 可借鉴点 |
|---|---|---|
| Linear | Issue Thread + 转子任务 | 讨论转 Action Item、Command Palette 快捷操作 |
| Slack | Channel Thread | 独立对话流、不干扰主列表、Thread 级通知 |
| 飞书 | 话题回复 | 底部抽屉展开、独立通知、可转飞书任务 |
| 乐问（内部） | 评论+回复 | 用户已有心智基础，降低学习成本 |

---

## 二、需求概述

本次升级分为两个方面：

| 方面 | 内容 | 性质 | 影响范围 |
|---|---|---|---|
| **方面一** | 文案改名：评论 → 讨论 | 心智重塑，低成本 | 全部 Topic |
| **方面二** | 引入 Thread 机制 + 讨论转子任务 | 结构性功能升级 | 全部 Topic |

---

## 三、方面一：文案改名（评论 → 讨论）

### 3.1 目的

将用户心智从"看完随手留言"转向"围绕议题展开讨论"。名字变了，行为预期跟着变。

### 3.2 改动清单

| 位置 | 旧文案 | 新文案 |
|---|---|---|
| Event 底部入口 | "评论 3" | "讨论 3" |
| 输入框占位 | "写下你的评论" | "发起讨论..." |
| 回复按钮 | "回复" | "回复"（保持不变） |
| 评论区标题 | "评论区" | "讨论区" |
| 通知 - 站内（新评论） | "xx 评论了你的 Event" | "xx 在讨论中发言" |
| 通知 - 站内（新回复） | "xx 回复了你的评论" | "xx 回复了你的讨论" |
| 通知 - 企微 Bot | "有 3 条新评论" | "有 3 条新讨论" |
| AI 总结 | "新评论" | "新讨论" |
| My 页面 | "我评论过的 Topics" | "我参与讨论的 Topics" |
| 红点文案 | "新评论 2" | "新讨论 2" |
| 空态文案 | "暂无评论，来发表第一条吧" | "还没有人发起讨论，来开启第一条" |

### 3.3 不改的部分

- "回复"按钮保持不变（Thread 内的子回复仍叫"回复"）
- Reaction（赞/踩/疑惑）保持不变
- 后端数据模型字段名可暂不改（前端文案层面替换）

---

## 四、方面二：Thread 机制 + 讨论转子任务

### 4.1 信息架构

```
Topic（主题）
  └── Event（事件/更新）
        └── Thread（讨论线）← 本次新增层级
              └── Reply（回复）
```

### 4.2 Thread 核心规则

| 规则 | 说明 |
|---|---|
| 发起 | 在 Event 讨论区发送一条消息 = 自动创建一个 Thread |
| 回复 | 点击某个 Thread 的"回复"按钮，进入该 Thread 内部回复 |
| 隔离 | 不同 Thread 之间互不干扰，每个 Thread 是独立的对话空间 |
| 线性 | Thread 内部的回复为线性排列（非树状），按时间正序 |
| 通知 | Thread 内任何新回复 → 自动通知该 Thread 所有参与者 |
| 层级限制 | Thread 内回复不再支持嵌套（即不存在"回复的回复"），保持结构简洁 |

### 4.3 界面结构

#### 4.3.1 Thread 收起态（列表视图）

每条 Thread 在讨论区以卡片形式展示，包含：

| 元素 | 说明 |
|---|---|
| 发起人头像 | 36×36 圆形 |
| 发起人姓名 + 部门 + 时间 | 如：coffeezhong(钟嘉辉) · 技术架构部 · 2小时前 |
| 首条内容预览 | 正文前两行，超出截断 |
| 回复计数 | "💬 4 条回复" |
| 最新回复人 | "最新: maixiao · 30分钟前" |
| 状态标签（如有） | "✅ 已转为待办" 或 "⏳ 等待回复中" |

#### 4.3.2 Thread 展开态（对话流视图）

点击 Thread 卡片后展开：

| 元素 | 说明 |
|---|---|
| 发起消息 | 完整显示首条消息内容 + Reaction |
| 回复列表 | 左侧竖线连接，缩进显示，每条含头像+姓名+时间+正文 |
| 每条消息操作 | hover 显示：👍 / 回复 / ··· 菜单 |
| 底部输入框 | "回复此讨论..." + 附件按钮 + 发送按钮 |

#### 4.3.3 发起新讨论（底部入口）

| 元素 | 说明 |
|---|---|
| 位置 | 讨论区最底部，所有 Thread 卡片之下 |
| 形态 | 虚线边框卡片，含用户头像 + 输入框 + 附件按钮 + 发送按钮 |
| 占位文案 | "发起讨论..." |

### 4.4 讨论转子任务

#### 4.4.1 功能说明

Thread 内的任何一条消息都可以被转化为一条待办（Action Item）。

#### 4.4.2 操作入口

| 入口 | 说明 |
|---|---|
| 消息 `···` 菜单 | hover/点击消息右侧的更多按钮，弹出操作菜单 |
| 菜单选项 | 📌 转为待办 / 🔗 复制链接 / ✏️ 编辑 / 🗑️ 删除 |

#### 4.4.3 转化规则

| 规则 | 说明 |
|---|---|
| 归属 | 转出的待办挂在当前 Event 的待办列表下 |
| 来源标注 | 待办项显示"来自讨论"标签 |
| 指派人 | 默认为消息中被 @ 的人；如无 @，默认为 Thread 发起者；支持手动修改 |
| 双向链接 | 待办可点击跳转回原 Thread 对应消息；Thread 内显示"✅ 已转为待办"标签 |
| 状态同步 | 待办勾选完成 → Thread 内自动显示系统消息"xx 已完成关联待办 · 时间" |
| 权限 | 所有 Thread 参与者和 Event 维护人均可执行"转为待办" |

#### 4.4.4 待办在 My 页面的体现

- My 页面"我的待办"板块新增来源类型："来自讨论"
- AI 总结可识别并提及："你有一条来自讨论的待办待处理"

### 4.5 通知规则

| 触发事件 | 通知对象 | 通知渠道 | 文案示例 |
|---|---|---|---|
| 新 Thread 发起 | Topic 订阅者/维护人 | 站内 Topic动态 Tab + 企微Bot | "xx 在「Topic名」·Event#N 中发起了新讨论" |
| Thread 内新回复 | 该 Thread 所有参与者 | 站内 Topic动态 Tab + 企微Bot | "xx 在你参与的讨论中回复了" |
| Thread 内 @ 某人 | 被 @ 者 | 站内 @我 Tab + 企微Bot（高优） | "xx 在讨论中提到了你：{内容摘要}" |
| 讨论转为待办 | 被指派人 | 站内 @我 Tab + 企微Bot（高优） | "xx 在讨论中指派了一项待办给你" |
| 关联待办完成 | Thread 所有参与者 | 站内 Topic动态 Tab | "你关注的讨论已有待办完成" |

**优先级**：Thread 内的 @ 通知优先级 > 普通 Topic 动态通知，归入一级强相关，在企微 Bot 整点推送中优先展示。

### 4.6 AI 总结适配

| 场景 | 调整 |
|---|---|
| 单 Topic AI 总结 | "新讨论"替代"新评论"；AI 按 Thread 为单位总结讨论结论，而非逐条复述 |
| ALL 页面 AI 简报 | "讨论激增"作为热门 Topic 的信号之一 |
| My 页面 AI 总结 | "你参与的讨论有新进展"/ "有讨论转为待办等你处理" |
| Thread 内容理解 | AI 需理解 Thread 上下文做结论提取，识别"讨论已产出结论"vs"仍在争议中" |

---

## 五、交互流程（全链路）

以"红点消失逻辑讨论"为例：

```
Step 1: 发起讨论
钟嘉辉在 Event 讨论区输入问题 → 点击发送 → 讨论区新增 Thread 卡片

Step 2: 触发通知
系统向 Topic 订阅者/维护人推送通知 → 企微 Bot 聚合推送

Step 3: 多人参与
王昕、李丹阳、李培轮点击通知进入 → 展开 Thread → 在 Thread 内回复
每次新回复 → Thread 参与者自动收到通知

Step 4: 产出结论 + @ 指派
肖迈总结讨论 → @ 钟嘉辉 → 被 @ 者收到高优通知（@我 Tab + 企微 Bot）

Step 5: 转为待办
肖迈点击该消息 ··· 菜单 → 转为待办 → 指派钟嘉辉
Thread 卡片出现 "✅ 已转为待办" 标签
Event 待办列表新增一条

Step 6: 待办完成 → 状态同步
钟嘉辉完成待办 → 勾选已完成
Thread 底部显示系统消息 → 参与者收到通知
```

---

## 六、边界与异常

| 场景 | 处理方式 |
|---|---|
| Event 归档后 | Thread 保留可读，不允许新回复，不允许转待办 |
| Event 删除后 | Thread 随 Event 一起进入回收站 |
| Thread 发起者删除了自己的首条消息 | 整个 Thread 删除（需二次确认） |
| Thread 内某条回复被删除 | 仅删除该条，其余保留，显示"该消息已被删除" |
| 被 @ 者不在 Topic 可见范围内 | 沿用现有权限申请逻辑（通知→申请→审批→结果通知） |
| 单个 Event 下 Thread 数量过多 | 超过 10 条时默认收起较早的 Thread，显示"展开更多讨论" |
| 讨论转待办后，原 Thread 被删 | 待办保留，来源链接显示"原讨论已删除" |
| 同一条消息重复转待办 | 拦截，提示"该消息已关联待办" |

---

## 七、兼容性与迁移

| 事项 | 方案 |
|---|---|
| 历史评论数据 | 现有评论自动视为独立 Thread（每条评论 = 一个 Thread 的首条消息），其下已有的回复自动归入该 Thread |
| 数据模型 | 新增 Thread ID 字段，评论表增加 thread_id 外键 |
| 前端切换 | 一次性切换，无新旧版并行 |

---

## 八、验收标准

- [ ] 所有"评论"文案已替换为"讨论"
- [ ] 可在 Event 下发起新 Thread
- [ ] Thread 卡片支持收起/展开切换
- [ ] Thread 内支持多人线性回复
- [ ] Thread 内新回复自动通知所有参与者
- [ ] Thread 内 @ 触发高优通知
- [ ] Thread 内消息可通过 ··· 菜单转为待办
- [ ] 转出的待办与原 Thread 双向链接
- [ ] 待办完成后 Thread 内显示状态同步消息
- [ ] 归档 Event 的 Thread 冻结写操作
- [ ] 历史评论数据平滑迁移为 Thread 结构
- [ ] AI 总结正确识别并总结 Thread 内容

---

## 九、设计交付物

| 交付物 | 状态 | 路径 |
|---|---|---|
| Thread 交互演示 HTML | ✅ 已完成 | `thread-demo.html` |
| 通知中心 Demo | ✅ 已完成 | `notification-demo.html` |
| 通知触达配置 Demo | ✅ 已完成 | `reach-demo.html` |
| 高保真设计稿（Figma） | 待启动 | — |
| 动效规范（展开/收起/转待办） | 待启动 | — |
| 移动端适配方案 | 待启动 | 配合一期移动端需求 |

---

## 十、待确认决策点

| # | 决策点 | 选项 | 建议 |
|---|---|---|---|
| 1 | Thread 内回复是否支持附件 | A: 支持 / B: 仅纯文本 | 建议 A（与现有评论附件能力一致） |
| 2 | 转待办时是否必须指派人 | A: 必须 / B: 可留空 | 建议 A（确保有人认领） |
| 3 | Thread 是否支持"标记为已解决" | A: 支持 / B: 不支持 | 建议 A（配合待办闭环） |
| 4 | 空 Thread（0回复）是否折叠 | A: 永远展示 / B: 超过10条时折叠旧Thread | 建议 B |
| 5 | 历史数据迁移时机 | A: 上线时一次性迁移 / B: 渐进式（用户访问时迁移） | 建议 A（避免体验不一致） |

---

*文档结束*