背景 / 需求
在 Session 会话列表里，群聊中「有人@我」会显示一个醒目的深红色提示（Android #FF5353 + [有人@我] 文案）。但一对一（1v1）聊天没有这个提示 —— 而 1v1 里对方发来的每条消息，本质上都等价于「@我」（点对点直达）。
目标：让 1v1 未读消息在会话列表也享受与群聊「@我」同等的深红色高优先级提示。三端（Web / iOS / Android）均需升级。
需求来源：产品口径已拍板 方案 A —— 只要是 1v1 未读（unread>0），即视同「@我」高优先级，不再细分是否显式 @。
设计原则（务必内化，勿做成"改颜色"的小活）
在人机协同平台里，人极易被大量消息淹没。核心设计思想是帮人识别出真正需要他关注的信息。
深红提示不是群聊专属样式，它是一个注意力分级信号——「有人在等我响应」。1v1 里"对方发消息"本身即等价于 mention，所以应复用同一视觉信号、同一套语义，只是触发条件在 1v1 场景退化为 unread > 0。
现状机制（已核 Android 源码）
三端共用 WuKongIM 的 Reminder 机制驱动@提示：
- 服务端对群聊@下发
WKReminder，type = WKReminderTypeMentionMe (1)。
- 会话项挂
reminderList；UI 层遍历命中 type==MentionMe && done==0 → 渲染深红提示。
- Android 确切位置：
- 渲染逻辑：
wkuikit/.../chat/adapter/ChatConversationAdapter.java#showReminders()（及 showCompactReminders）
- 类型常量：
wkim/.../entity/WKMentionType.java（WKReminderTypeMentionMe = 1）
- 色值：
wkbase/src/main/res/values/color.xml → reminderColor = #FF5353
- 文案：
wkuikit/.../res/values/strings.xml → last_msg_remind = [有人@我]
- 根因：服务端只对群聊@生成该 reminder，1v1 不生成 → 1v1 无深红提示。
实现路线（需拍板 —— L2 架构决策）
路线 1：服务端统一下发（推荐）
1v1 消息也生成等价的高优先级 reminder（或复用 WKReminderTypeMentionMe）。
- ✅ 改一处，三端天然复用现有渲染逻辑，概念完整性最强
- ✅ 判定逻辑单一来源，不会三端各写各的、各飘各的红
- ⚠️ 需评估 1v1 每条消息都生成 reminder 的存储/同步开销；语义上「1v1=永远@你」是否污染 reminder 概念需产品确认
路线 2：各端本地判定
三端各自在会话渲染处加判定：channelType==个人 && unreadCount>0 → 视同 mention 渲染。
- ✅ 不改服务端，零 schema / 存储开销
- ⚠️ 三端各写一遍，必须靠统一判定语义 + 统一色值 token保证一致，否则破坏概念完整性
- ⚠️
unreadCount、channelType 各端会话模型均已具备（Android WKUIConversationMsg.unreadCount），前提成立
倾向路线 2（零后端改动、契合"1v1 判定天然可本地推导"），但需 @李梦林 就跨端一致性 / 是否愿意接受三端各实现拍板。若担心三端飘移，则选路线 1。
三端子任务 Checklist
一致性铁律
- 三端必须共用同一深红色值（
#FF5353）与同一提示形态。禁止各端各调各的红 —— 那会破坏概念完整性。
- 判定语义三端统一：
(群聊 && 有@我reminder) || (1v1 && unread>0)。
克制边界（本 issue 不做）
只做 1v1 未读 → 深红高优先提示。不要顺手加：未读分级多档位、免打扰细则、按联系人配置提示等级。那些是独立需求。
六层影响：仅 L4 过程（会话列表高优先判定分支）直接受影响；L1/L2/L3/L5 不变；L6 可观测可选埋点验证"帮人聚焦"效果。零 schema 改动（路线 2）。
背景 / 需求
在 Session 会话列表里，群聊中「有人@我」会显示一个醒目的深红色提示（Android
#FF5353+[有人@我]文案）。但一对一（1v1）聊天没有这个提示 —— 而 1v1 里对方发来的每条消息，本质上都等价于「@我」（点对点直达）。目标：让 1v1 未读消息在会话列表也享受与群聊「@我」同等的深红色高优先级提示。三端（Web / iOS / Android）均需升级。
需求来源：产品口径已拍板 方案 A —— 只要是 1v1 未读（unread>0），即视同「@我」高优先级，不再细分是否显式 @。
设计原则（务必内化，勿做成"改颜色"的小活）
深红提示不是群聊专属样式，它是一个注意力分级信号——「有人在等我响应」。1v1 里"对方发消息"本身即等价于 mention，所以应复用同一视觉信号、同一套语义，只是触发条件在 1v1 场景退化为
unread > 0。现状机制（已核 Android 源码）
三端共用 WuKongIM 的 Reminder 机制驱动@提示：
WKReminder，type = WKReminderTypeMentionMe (1)。reminderList；UI 层遍历命中type==MentionMe && done==0→ 渲染深红提示。wkuikit/.../chat/adapter/ChatConversationAdapter.java#showReminders()（及showCompactReminders）wkim/.../entity/WKMentionType.java（WKReminderTypeMentionMe = 1）wkbase/src/main/res/values/color.xml→reminderColor = #FF5353wkuikit/.../res/values/strings.xml→last_msg_remind = [有人@我]实现路线（需拍板 —— L2 架构决策）
路线 1：服务端统一下发（推荐）
1v1 消息也生成等价的高优先级 reminder（或复用
WKReminderTypeMentionMe）。路线 2：各端本地判定
三端各自在会话渲染处加判定：
channelType==个人 && unreadCount>0 → 视同 mention 渲染。unreadCount、channelType各端会话模型均已具备（AndroidWKUIConversationMsg.unreadCount），前提成立倾向路线 2（零后端改动、契合"1v1 判定天然可本地推导"），但需 @李梦林 就跨端一致性 / 是否愿意接受三端各实现拍板。若担心三端飘移，则选路线 1。
三端子任务 Checklist
channel_type + unread_count（路线 2 的 fallback，大概率已透传）ChatConversationAdapter#showReminders/showCompactReminders增加"1v1 && unread>0 → mention=true"分支；复用reminderColor+last_msg_remindWKReminderTypeMentionMe的等价渲染路径，加同等 1v1 判定；复用同一深红 tokenisHighPriority(conv) = (群聊 && hasMention) || (个人 && unread>0)，复用同一深红 design token一致性铁律
#FF5353）与同一提示形态。禁止各端各调各的红 —— 那会破坏概念完整性。(群聊 && 有@我reminder) || (1v1 && unread>0)。克制边界（本 issue 不做）
只做 1v1 未读 → 深红高优先提示。不要顺手加：未读分级多档位、免打扰细则、按联系人配置提示等级。那些是独立需求。
六层影响：仅 L4 过程（会话列表高优先判定分支）直接受影响；L1/L2/L3/L5 不变；L6 可观测可选埋点验证"帮人聚焦"效果。零 schema 改动（路线 2）。