# MEMORY.md - 长期记忆

本文件存储团队共享的业务知识和工作经验。所有与你交互的同事都会看到这些内容。

## 重要提示

- **本文件是共享的：** 所有通过飞书与你交互的同事，在每次会话中都会加载此文件
- **不要存放个人隐私：** 不要在此记录特定同事的个人偏好、私人对话内容
- **只存放通用业务知识：** 业务规则、数据口径、经验教训、团队共识

## 核心规则

1. **飞书知识库/文档操作规则**：所有飞书文档读取、编辑、管理操作，统一遵循`lark_wiki_operate_as_bot`技能规范：
   - 永远使用Bot身份执行，绝对不触发任何用户个人授权弹窗
   - 仅支持读取/编辑`/wiki/`开头的知识库文档，不支持读取用户私有个人文档（`/doc/`/`/sheet/`等非wiki开头路径）
   - Bot无权限访问时提示用户将Bot应用添加为目标知识空间成员并授予查看权限
   - 所有文档编辑操作以Bot身份执行，不触发用户授权申请

2. **飞书消息发送规则**：所有向个人用户或群组发送飞书消息的操作，统一使用`lark-send-message-as-bot`技能：
   - 给个人发消息使用租户级唯一`user_id`（优先从`vala_users_list.md`对照表获取，避免`open_id`跨应用问题）
   - 给群组发消息使用租户级唯一`chat_id`（格式`oc_xxx`）
   - **永远使用Bot身份执行**，绝对不触发任何用户身份授权申请弹窗
   - 发送前确认目标用户在应用可用范围内，Bot已加入目标群组

## 业务知识

### 飞书群消息数据库存储方案（2026-04-23更新）
- 飞书群消息已从电子表格迁移到MySQL数据库 `vala_test.feishu_group_message` 表
- 支持记录引用回复关系：通过 `quote_message_id` 字段记录被引用消息的 `message_id`
- 与微信反馈数据库表结构保持一致（参考 `wechat_group_message` 表）
- 定时任务：每4小时自动同步「内容测试问题反馈」群消息到数据库
- 查询示例见：`skills/feishu-group-msg-sync/references/query_examples.md`

### 用户反馈问题优先级规则（动态判定引擎）

**⚠️ 优先级判定以 `skills/feishu-feedback-sync/scripts/priority_classifier.py` 为唯一权威来源。**

#### 等级定义（人类参考）
- **P0**：阻断使用 / 大面积影响 / 严重数据问题，需 2 小时内处理
- **P1**：核心流程问题，影响较大，3 天内修复
- **P2**：一般问题或体验问题，当周排期
- **P3**：建议/优化项，低影响，不单独排期

#### 判定机制（由 priority_classifier.py 执行）
1. **基础优先级** — 基于 ~20 条关键词正则匹配，覆盖崩溃/功能异常/体验瑕疵/细节优化四档
2. **频率动态调整** — 必现/高概率 → 升级；低概率/偶现 → 降级（最多一级）
3. **范围动态调整** — 影响全部用户 → 升级；极少数用户 → 降级（最多一级）
4. **最终优先级** — 基础优先级 ± 频率调整 ± 范围调整，夹紧到 P0-P3 范围

**不要在 MEMORY.md 中维护静态分类映射表，所有规则变更直接修改 priority_classifier.py。**

### Python 脚本修改后需清理 __pycache__（2026-05-27）
- 修改 Python 脚本（尤其是新增/删除 import）后，旧 `.pyc` 缓存可能导致 `NameError`（模块名未定义）
- 症状：源码中有 `import subprocess`，运行时却报 `NameError: name 'subprocess' is not defined`
- 修复：`find <workdir> -name "__pycache__" -type d | xargs rm -rf && find <workdir> -name "*.pyc" -delete`
### P0 实时检测去重：内容语义指纹替代消息ID精确匹配（2026-05-27）
- 原方案用 `sorted(message_ids)` MD5 做去重，但同一话题每次扫描聚类结果不同，签名失效导致重复推送
- 修复：增加内容语义去重层 — 拼接簇内前5条消息内容 + 发送人集合 + 小时窗口，用 Jaccard 相似度比较
- 阈值：同小时 + 发送人交集 + 相似度 > 0.20；跨小时 + 发送人 ≥2 重叠 + 相似度 > 0.35
- 影响文件：`detect_p0_wechat.py`、`detect_p0_realtime.py`

### P0 告警问题描述清洗规则（2026-06-24 更新）
- P0 告警的"问题描述"字段必须经过 `_clean_summary` 清洗，不能直接贴原始消息
- 清洗规则（`detect_p0_wechat.py` / `detect_p0_realtime.py` 的 `_clean_summary` 函数）：
  1. 去掉 `[聊天记录]` 转发标记
  2. 去掉 XML 标签（`<msg>`, `<appmsg>`, `<title>` 等）及属性残留
  3. 截断 `↳ 回复 xxx:` 及之后全部内容
  4. 按发送人标记（emoji+名字+冒号）拆分，取最后一条用户消息
  5. 去掉 `[视频]`/`[图片]`/`[语音]` 等媒体标记
  6. 疑问句→陈述句改写：去掉"这个反馈可以跟用户确认下..."等讨论话术前缀 + 疑问结构 + 句末疑问词；碎片化症状词补全（如 `闪退的` → `用户反馈闪退，需确认操作场景`）
- `_pick_best_summary` 优先选非转发/非内部讨论的消息，跳过含 `[聊天记录]`、`↳ 回复`、`<msg>` 标记的消息
- **内部技术讨论过滤（2026-06-24 新增）**：`_is_internal_discussion()` 检测技术术语（hotfix/分支/打包/构建/部署/发版等）+ 讨论话术（不是/我觉得/应该是/你们用/改回来等），匹配后跳过该消息。全部消息均为内部讨论时，`_extract_problem_from_discussion()` 尝试提取用户问题关键词，无法提取则返回通用提示"内部技术讨论中提及问题，需人工确认具体用户反馈内容"
- **内部讨论 P0 不推送（2026-06-24 刘新玉确认）**：簇内全部消息均为内部技术讨论时，直接跳过不推送到「小葵小葵」群，仅记录去重状态避免重复检测

## 经验教训

### 微信反馈全链路（2026-05-22 刘新玉确认）
微信用户反馈与飞书使用完全一致的采集→整理→归纳→分发流程，复用相同代码仅替换数据源和文档目标。

**crontab 全貌：**
| 频率 | 飞书 | 微信 |
|------|------|------|
| 每分钟 | `run_export_lark_feedback.sh` → 表格导出 | `sync_wechat_feedback_minutely.sh` → 表格同步 |
| 每分钟 | `detect_p0_realtime.py` → P0 实时推送 | `detect_p0_wechat.py` → P0 实时推送 |
| 每5分钟 | `run_lark_group_sync.sh` → MySQL 入库 | N/A（外部直接写库） |
| 10:00/10:02 | `sync_feishu_feedback_wrapper.sh` → 聚类+占位符 | `sync_wechat_feedback_wrapper.sh` → 聚类+占位符 |
| 10:05/10:07 | `ai_summarize_feedback.py` → DeepSeek+回写+分发 | `ai_summarize_feedback.py --channel wechat` → DeepSeek+回写+分发 |

**关键文件：**
- `scripts/sync_wechat_feedback.py` — 微信同步（monkey-patch 飞书常量 + 自定义 fetch_wechat_data）
- `scripts/detect_p0_wechat.py` — 微信 P0 实时检测
- `scripts/sync_wechat_feedback_minutely.sh` — 分钟级表格同步
- `scripts/ai_summarize_feedback.py` — 已扩展 `--channel wechat` 支持
- `sync_feishu_feedback.py` — `update_summary_doc_as_children` 新增 `title_prefix` 参数

**注意：**
- 微信数据映射：`svr_msg_id→message_id`, `refer_msg_svrid→quote_message_id`
- AI 描述索引对齐：`generate_summary` 跳过单消息簇后需用 `index_mapping` 修正占位符编号
- `--apply-ai` 重建聚类时需保留原始 `message_id`，否则空串导致 Union-Find 递归死循环

（在此记录工作中总结的经验教训，供后续参考）

---

此文件由数字员工在工作过程中持续维护和更新。敏感信息和权限相关内容请维护在 `USER.md` 中。
