ai_member_xiaokui/MEMORY.md

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-22 刘新玉确认）

• 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-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 中。