docs(feedback): add message 点赞/点踩 feedback PRD

Product PRD (pyramid structure) for adding thumbs up/down feedback to the
four AI Q&A surfaces (workstation daily, linsight task mode, knowledge-space
知源, channel subscription). Feedback persists on the answer row and rolls up
into message_session for single-table, per-surface analytics.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/PRD/2.6 会话点赞点踩反馈 PRD/会话点赞点踩反馈 PRD.md

@@ -0,0 +1,94 @@
+# 会话点赞点踩反馈 PRD（产品视角）
+
+> 面向产品 / 业务的需求说明，大白话、金字塔结构：先结论，再问题，再要做的事、怎么存。
+> 研发验收口径（EARS 句式）另出 `features/v2.6.0/{NNN}-message-feedback/spec.md`，与本文一一对应、不冲突。
+> **本阶段只出文档，不写代码。**
+
+---
+
+## 一、结论先行
+
+**目前只有「应用会话」能对 AI 回答点赞/点踩，另外四个 AI 问答界面（含「深度思考」答案）只能复制/朗读，用户无法表达"这条答案好不好"，我们也拿不到质量反馈。本次给这四个界面统一补上点赞/点踩（点踩可填原因），并让反馈全部落库、能一张表取数分析。改动很小——因为四个界面里三个早就具备存储与接口，只有灵思需要补一列。**
+
+| | 界面 | 现状 | 本次要做的事 | 用户 / 数据侧拿到的结果 |
+|---|---|---|---|---|
+| 1 | 工作台**日常模式** | 只有复制/朗读 | 工具栏加点赞/点踩，点踩填原因 | 能反馈、反馈进库可分析 |
+| 2 | 工作台**任务模式 / 灵思**（深度思考） | 无任何反馈按钮 | 任务完成区加点赞/点踩，点踩填原因 | 同上（唯一需后端补一列的界面） |
+| 3 | **知识空间 AI 问答**（知源） | 只有复制/朗读 | 工具栏加点赞/点踩，点踩填原因 | 同上 |
+| 4 | **频道订阅 AI 问答**（知源） | 只有复制/朗读 | 工具栏加点赞/点踩，点踩填原因 | 同上 |
+
+> 一句话：**不是从零做一套反馈系统，而是把「应用会话」已有的成熟机制铺到另外四个界面；三个界面直接复用，灵思补一列并汇总进同一张分析表。**
+
+---
+
+## 二、为什么要做（问题）
+
+- **用户侧**：这四个界面用得很多（日常问答、深度任务、知识库问答、频道文章问答），但答案好坏用户"没处表达"。应用会话有赞踩、这四个没有，体验割裂。
+- **产品/运营侧**：拿不到"哪些答案被点赞、哪些被点踩、点踩原因是什么"的数据，无法评估各界面/各模型的回答质量，也没法据此调优。
+- **深度思考**：带"已深度思考"的答案恰恰是最该被评价的（推理长、易出错），现在同样无法反馈。
+
+---
+
+## 三、要做哪些事（功能范围）
+
+1. **四个界面统一加点赞、点踩两个按钮**，位置与现有"复制/朗读"并列，风格一致；赞与踩互斥、可再次点击取消。
+2. **点踩弹窗填原因**（沿用应用会话的"填写反馈"弹窗体验），原因文本也落库。
+3. **深度思考按整条答案评价**：赞踩落在整条回答上（思考过程 + 正文一体），不对思考块单独设按钮——与应用会话行为一致。
+4. **反馈全部落库、且方便取数分析**：数据结构合理，能从数据库直接统计各界面/各会话的赞踩情况（见第四节）。
+5. **刷新后保持状态**：已点过的赞/踩，刷新页面后仍高亮显示。
+
+**本次不做（Non-goals）**
+- 审计/后台页面不新增"按赞踩筛选"的界面能力（用户已明确暂不要求，仅保证数据可取）。
+- 不改应用会话现有反馈逻辑（保持不变）。
+- 只读分享页不提供赞踩（匿名访客不交互）。
+
+---
+
+## 四、数据怎么存、怎么取数（数据结构说明）
+
+> 核心诉求是"结构合理 + 好分析"。做法是**逐条明细存在各自答案行、会话级汇总统一进一张表**。
+
+| 界面 | 每条答案的赞踩存哪 | 点踩原因存哪 | 会话级汇总 |
+|---|---|---|---|
+| 日常 / 知源 / 频道 | `chatmessage.liked`（0未评/1赞/2踩，**已有**） | `chatmessage.remark`（**已有**） | `message_session.like/dislike`（**已有**） |
+| 灵思任务 | `linsight_session_version.liked`（**本次新增一列**） | `linsight_session_version.execute_feedback`（**已有**） | `message_session.like/dislike`（本次让灵思也汇总进来） |
+
+**为什么这样"好分析"：**
+- `message_session` 这张表已经按 `flow_type` 区分界面（日常=15 / 灵思=20 / 频道=25 / 知识空间=30）。
+  把灵思也汇总进它之后，**它就成了覆盖全部界面的单一分析表**——按 `flow_type` 分组即可拿到各界面赞踩量。
+- 要看逐条明细，就查各自答案行的 `liked`，都能 join 回 `message_session` 带出界面类型、租户、用户。
+- 既有分析函数可直接复用（`static_msg_liked`、`app_list_group_by_chat_id`、会话反馈过滤）。
+
+**取数示例（说明"方便"）：**
+- 各界面赞踩总量：`SELECT flow_type, SUM(like), SUM(dislike) FROM message_session GROUP BY flow_type;`
+- 逐条被踩明细 + 原因：查 `chatmessage`（liked=2 取 remark）与 `linsight_session_version`（liked=2 取 execute_feedback）。
+
+---
+
+## 五、交互与体验
+
+- **按钮位置**：与"复制/朗读"同一行工具栏，悬停出现；灵思在"任务完成"结果区下方新增一行。
+- **互斥与取消**：点赞后再点赞=取消；赞↔踩互斥切换。
+- **点踩弹窗**：点踩后弹出"填写原因"输入框（复用应用会话的弹窗与文案），提交后记录原因。
+- **状态保持**：刷新/重进会话后，已赞/已踩保持高亮（后端在历史里回传赞踩状态）。
+- **一致性**：四个界面视觉、交互与应用会话统一，用户零学习成本。
+
+---
+
+## 六、范围、分期与风险
+
+- **一次性全上**（不分期）：三个界面复用成熟机制、几乎零后端改动；灵思单独补列。
+- **主要工作量在灵思**：新增 `liked` 列需一条数据库迁移，**须兼容 MySQL 与达梦 DM8 双库**（按仓库既有迁移规范，幂等 + 手工核对 DM8）。
+- **需确认的技术点（研发阶段处理）**：确保三个 chatmessage 界面的"历史接口"回传 `liked`、"实时答案"带上答案 id（否则新答案未刷新时点不了赞、或刷新后不高亮）。
+- **风险低**：不触碰权限/多租户核心；灵思写入按 `session_id` 主键定位，无跨租户风险。
+
+---
+
+## 七、验收要点（对应研发 spec，供后续 EARS 化）
+
+1. 四个界面均可点赞/点踩，赞踩互斥且可取消。
+2. 点踩弹窗可填原因并成功保存（chatmessage→remark，灵思→execute_feedback）。
+3. 刷新后赞踩状态正确回显。
+4. 赞踩写库正确：chatmessage/linsight 各自 `liked` 落值，`message_session` 汇总计数增减正确（含赞→踩切换）。
+5. `SELECT flow_type, SUM(like), SUM(dislike) FROM message_session GROUP BY flow_type` 能看到四个界面（含灵思 flow_type=20）的赞踩汇总。
+6. 只读分享页不出现赞踩按钮；应用会话原有反馈行为不变。