优化知识整理合并逻辑体验，支持学习用户推荐/沉淀习惯

[xgx1124982311-sys]

背景

当前合并逻辑不够好，知识整理体验需要整体优化。建议支持自进化：学习用户的推荐或沉淀逻辑，自适应调整合并策略。

工作范围

• 梳理当前知识整理 / room 合并的完整交互流程与痛点。
• 输出迭代规划。
• 评估支持学习用户习惯：根据用户的推荐/沉淀行为自适应调整合并策略。

验收标准

• 输出知识整理迭代规划文档并完成评审。
• 明确合并逻辑的改进方案（含手动合并能力，见 room 合并逻辑问题：会直接加入已有 room 且无法手动合并 #155）。
• 给出用户习惯学习方案的可行性结论。

迭代信息

• 优先级：P2
• 模块：context-rooms、knowledge

[github-actions]

该 issue 更像迭代规划需求，不能据此确认存在某个具体缺陷。仓库中已经具备一套 Room 重复检测与手动确认合并能力，但“学习用户习惯”尚未形成通用策略闭环。

可能受影响的代码

• 候选生成与评分核心：duplicate-service.ts
  • 综合标题、向量、资料和实体重叠度。
  • 使用固定全局阈值决定 high、medium、pending。
  • 可调用 LLM 判断两个 Room 是否为同一实体。
• 用户反馈保存：duplicate-service.ts
  • “保持分开”会保存为 distinct，但仅在同一 evidenceRevision 下保留；证据变化后重新开放。
  • 目前没有证据表明这些反馈会调整其他候选或用户级阈值。
• 合并预览与执行：duplicate-service.ts
  • 已检查影响数量、冲突、遗漏项和过期预览。
  • 合并使用幂等键并保留来源 Room tombstone。
• 桌面交互：RoomDuplicateCenter.tsx
  • 已支持选择主 Room、查看影响、确认合并、重试、取消及“保持分开”。
  • 入口只能处理系统生成的候选，尚未看到任意选择两个 Room 发起合并的界面。
• API 契约：index.ts 和 context-room-gateway-bridge.ts。

正确性与安全风险

• 错误合并具有较高数据风险：合并进入提交阶段后不可逆，可能错误迁移文档、记忆、实体、关系和 Agent run。
• 当前数组冲突按稳定 ID 折叠，其他字段以主 Room 数据优先；需要用真实案例确认是否会静默丢失来源 Room 的摘要或状态信息。
• distinct 是单候选反馈，不等于用户习惯学习。直接把少量反馈用于全局阈值，容易造成过拟合和推荐漂移。
• 学习信号可能包含敏感的知识组织偏好。若跨用户、跨工作区聚合，需要明确隔离、保留期限、删除和退出机制。
• LLM 判定接收资料中的证据文本。现有实现仅将其作为判定输入；引入自进化时仍需防止不可信资料污染长期规则。
• “手动合并”目前似乎局限于推荐候选，可能尚未满足 issue 所引用的 room 合并逻辑问题：会直接加入已有 room 且无法手动合并 #155。

缺少的信息

• 至少 2 至 3 个“当前合并逻辑不够好”的真实 Room 对及期望结果。
• 问题发生在候选漏报、误报、主 Room 推荐、影响预览、执行结果，还是操作入口。
• “推荐/沉淀行为”具体包括哪些正负反馈，以及学习范围是设备、工作区还是账号。
• 对误合并率、候选召回率、反馈生效时间和撤销能力的验收指标。
• “类似 hermes”指向的具体机制或参考资料。

最小有用下一步

先为负责人产出一张现状流程表，并用三个匿名真实案例走通：

候选生成 → 用户保持分开/选择主 Room → 影响预览 → 合并执行 → 合并后核对

每个案例记录四项评分、LLM 结论、用户选择和实际迁移差异。随后再决定首个迭代是补“任意两 Room 手动合并”入口，还是建立只读反馈日志。现阶段不宜直接实现自动调参；仓库已有的候选状态和合并操作记录可先作为评估数据源。

[github-actions]

初步判断

这不是一个具备明确复现路径的缺陷报告，而是跨 context-rooms 与 knowledge 的产品规划需求。仓库中已经存在较完整的 Room 合并流程，因此第一步不应直接重写合并算法，而应先明确“当前合并逻辑不够好”具体指候选召回、排序、交互还是合并结果。

可能受影响的代码

• Room 重复候选评分与状态持久化：duplicate-service.ts
  • 使用标题、语义质心、资料重叠和实体重叠加权评分。
  • 支持 LLM 同一性判断。
  • 用户选择 distinct / related 后仅保存当前候选状态；现有证据未显示这些反馈会调整全局阈值或排序模型。
• Room 合并预览及执行：duplicate-service.ts
  • 已覆盖影响统计、冲突提示、预览过期校验、幂等键、异步执行、重试和有限取消。
• 桌面端交互：RoomDuplicateCenter.tsx
  • 当前入口主要面向系统生成的重复候选。
  • 用户可以选择保留哪个 Room、确认合并或标记“保持独立”。
  • 未看到从任意两个 Room 主动发起合并的通用入口，这可能是 issue 所引用 room 合并逻辑问题：会直接加入已有 room 且无法手动合并 #155 的“手动合并能力”缺口。
• 实体解析与自动归并：router.ts
  • 使用固定 Dice 阈值和 LLM 判断，与 Room 级合并是不同层次的机制。
• 既有设计文档：entity-room-plan.md、room-wiki-plan.md
  • 文档仍将实体治理、拆分以及部分手动合并能力列为后续工作，与 issue 范围有重叠。

正确性与安全风险

• 错误合并可能迁移文档、记忆、实体、关系和会话归属，并污染后续知识检索；界面也明确将其视为不可逆操作。
• 自适应策略若直接从少量用户操作更新阈值，可能形成反馈回路：一次误合并或误点“保持独立”会持续影响后续推荐。
• “保持独立”目前会在证据修订不变时保留，但证据变化后候选会重新开放。这是否符合“学习用户习惯”尚未定义。
• 学习数据可能暴露用户的项目关系、主题偏好和知识结构，需要明确本地/服务端存储、保留期限、删除及跨用户隔离规则。
• 文档内容和实体依据会进入 LLM 同一性判断；需要防止不可信资料通过提示注入操纵合并结论。现有代码不足以证明这一链路已完整防护。
• API 路由本身未体现资源级授权检查，但仅凭该文件不能断言存在越权漏洞，还需结合服务端统一鉴权机制判断。

缺失信息

Issue 尚未给出：

• 一个实际失败案例及期望结果；
• “合并逻辑不好”是误报、漏报、排序差、操作繁琐，还是合并后数据不正确；
• 涉及 Room 合并、实体合并、wiki 内容合并中的哪一层；
• 推荐/沉淀行为的具体事件定义，以及负反馈、撤销、跨设备同步规则；
• 自适应是单用户、工作区还是全局模型；
• 可接受的误合并率、召回率、延迟和 LLM 成本；
• room 合并逻辑问题：会直接加入已有 room 且无法手动合并 #155 的具体契约及与现有重复候选中心的差异；
• 合并后的撤销或拆分要求。

最小有用下一步

先补充一个包含 3 至 5 个真实案例的流程基线文档：记录候选输入、四项评分、LLM 结论、用户选择、目标 Room 和期望结果。基于这些案例再确认 #155 是否只需增加“任意两个 Room → 现有预览/执行管线”的入口。

“习惯学习”第一阶段建议只记录结构化反馈并离线评估，不立即动态修改生产阈值。这样可以先验证反馈量是否足够、哪些特征有效，以及个性化是否真的优于当前固定评分。