ai_member_only/ai_member_xiaokui
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
09481e3ff4
ai_member_xiaokui/memory/2026-05-11-1925.md
--git_token 7931b77dfb auto backup 2026-05-12 08:10:01
2026-05-12 08:10:01 +08:00

12 KiB
Raw Blame History

Session: 2026-05-11 19:25:44 GMT+8

  • Session Key: agent:xiaokui:feishu:direct:ou_9d4df593d0419d705274947c5cec5ada
  • Session ID: e5e30039-7ae4-4c7d-acfc-1767daffec51
  • Source: feishu

Conversation Summary

assistant: 测试完整的 --apply-ai 端到端流程： assistant: 全部完成。以下是交付摘要：

AI 归纳已完整接入飞书反馈同步流水线

改了什么

sync_feishu_feedback.py — 新增两种运行模式：

模式 命令 产出
占位符模式 --ai-placeholders 文档写入 [待AI归纳:#N] 占位符 + 保存上下文 JSON
回写模式 --apply-ai <json> 替换占位符为 AI 描述 → 覆盖写入文档

端到端验证通过

今天 2026-05-11 的数据（1 个问题簇、9 条消息）：

阶段 结果
脚本规则引擎 图片 (1/1) 我怎么记着已经出了...（原文拼贴）
AI 归纳 → 回写后 在 132 版本中，L1 级别 U 单元名称显示为数字编号 — U 级别单元名称未命名（季度级别已有名称），新版本发布后用户将全部可见

文档已确认：无重复、无占位符残留、AI 描述正确写入。

伴随修复

  • markdown 转义 Bug：--markdown 内联传递到 subprocess 会导致飞书 rich text 被错误转义，改为 @file 相对路径方式
  • 清理 crontab：移除两个浪费资源的每分钟任务

自动化链路

每日 10:00 crontab → --ai-placeholders（占位符文档）
        ↓
心跳检测到 cluster_context_YYYY-MM-DD.json
        ↓
AI 读取上下文 → 生成描述 JSON
        ↓
--apply-ai → 替换占位符 → 覆盖写入

user: 好的 小葵辛苦了 我还想知道目前“用户反馈问题汇总”下的子文档的排序规则 assistant: 子文档的排序由 create_child_doc() 中的 sort_tag 控制：

当前规则：按日期倒序（最新日期排最前）

sort_tag = 9999999999 - int(dt.timestamp())  # 日期越新 → 时间戳越大 → sort_tag越小 → 排在前面

飞书 Wiki 按 sort_tag 升序排列子节点，所以：

日期 时间戳 sort_tag 位置
2026-05-11 1766966400 8233033599 最小 → 最前
2026-05-10 1766880000 8233119999
... ... ...
2026-01-01 1767196800 8232803199 最大 → 最后

但有两点注意：

  1. 仅创建时生效 — 首次 create_child_doc() 时写入 sort_tag，后续 overwrite 更新内容不修改排序值。如果某文档是早期创建的（sort_tag 逻辑加入之前），它保留原来的默认值。

  2. 排序不一致场景 — 如果某个旧文档需要调整排序位置，需要手动修改其 sort_tag（目前脚本没有做这个）。 user: 理解了，我看现在5月11日的文档排在最下面，按日期倒序逻辑，不是应该排期最上面吗 assistant: 所有文档的 sort_tag 都是空 — 飞书 API 创建节点时 sort_tag 没生效。让我确认并修复： assistant: 根因找到了。

飞书 Wiki 子文档排序由 sort_tag 控制，但 Bot 应用缺少 wiki:node:update 权限，API 不认 sort_tag 字段 — 创建时传了也被静默忽略，更新接口直接 404。

所以实际排序退化为按 node_create_time（文档创建时间）升序排列：

# 文档 创建时间
1 2026-05-08 5月9日 11:17
2 2026-05-07 5月9日 11:17
3 2026-05-06 5月9日 11:17
4 2026-04-28 5月9日 14:05
5 2026-05-11 5月11日 18:18 ← 今天被删掉重建，创建时间最新，所以排最后

要修复的话，需要在飞书开放平台给 Bot 应用（cli_a9311791083adcc1）添加 wiki:node:update 权限，然后我再通过 API 给所有文档设 sort_tag。

这需要技术负责人（李若松或张昆鹏）去操作。要我通知他们吗？ user: 通知 assistant: 已通知李若松和张昆鹏，内容摘要：

  • 问题：Bot 应用缺少 wiki:node:update 权限，无法通过 API 设置 sort_tag，导致子文档按创建时间而非日期排序
  • 需操作：飞书开放平台 → 给小葵应用添加 wiki:node:update 权限
  • 后续：权限开通后告知我，我来批量修正所有子文档排序 user: 好的 那等权限开通后我告诉你 我现在想知道飞书问题反馈整个收集、归纳和分发流程；想要知道的原因是：我现在还要收集微信的问题反馈问题，想评估下要怎么复用 assistant: 整个流程我按三段拆开讲，每段标注了「哪些可以直接复用微信」：

飞书问题反馈完整流程

┌─────────────── 采集层 ───────────────┐
│  飞书群消息 → MySQL lark_group_message │  feishu-group-msg-sync 技能
└──────────────┬────────────────────────┘
               ↓
┌─────────────── 处理层 ───────────────┐
│  步骤1: 查询数据库（按日期范围）        │
│  步骤2: 写入飞书表格（按天分sheet）     │
│  步骤3: 对话链排序（Union-Find聚类）    │
│  步骤4: 问题归纳（规则/AI生成描述）     │
│  步骤5: 优先级排序（P0→P3）            │
│  步骤6: 问题分类（按类型归类）          │
└──────────────┬────────────────────────┘
               ↓
┌─────────────── 分发层 ───────────────┐
│  步骤7: P0 @通知到群                  │
│  步骤8: AI 精炼描述（占位符替换）       │
└──────────────────────────────────────┘

各步骤详解 & 微信复用评估

采集层

飞书 微信（已有）
数据来源 lark_group_message 表 wechat_group_message 表，1089条
采集方式 定时拉群消息 实时每分钟同步
引用关系 quote_message_id + 推断 refer_msg_svrid（较少）

微信已有数据在库，采集层 现成可用。

处理层（核心逻辑在 sync_feishu_feedback.py）

步骤 1-2：查询 + 写表格 — 微信可复用，只改表名和字段映射。

步骤 3：对话链排序 — 这是最重要的复用点，也是最难点：

飞书排序依赖三个推断策略（@提及、同发送者聚类、最近不同发送者），微信消息面临两个额外问题：

  1. 转发消息多 — 微信群大量用「聊天记录」转发，消息内容嵌套在 content 里的 XML/文本中，非原生消息
  2. 无显式引用 — 微信没有飞书那种消息级引用回复能力，只有少数消息有 refer_msg_svrid

→ 排序逻辑需要针对微信场景调优，但整体架构（Union-Find 聚类 + 递归展开）可直接复用。

步骤 4-6：归纳 + 优先级 + 分类 — 全部可直接复用，只改入参数据源。generate_problem_description() 的规则引擎、优先级判定、分类映射都不依赖飞书特有字段。

分发层

步骤 飞书 微信复用
步骤 7 (P0通知) 飞书群 @通知 暂不适用（无微信群 Bot）
步骤 8 (AI归纳) AI 描述 → 知识库文档 同样走知识库

复用建议：两种路径

路径 A：合流（推荐）

微信和飞书数据在「步骤 1 查询」阶段合并，后续处理统一走一套逻辑。最终知识库文档里标注来源渠道。

lark_group_message ─┐
                     ├→ 统一排序 → 归纳 → 分类 → 文档
wechat_group_message─┘
  • 改动量小：query_messages() 加一个 UNION 或双表查
  • 字段对齐：微信没有 quote_message_id，用 refer_msg_svrid 替代；没有 sender_id，用 sender_username 替代

路径 B：分治

两套独立流水线，各自产出文档，在最终展示层合并。

  • 改动量大但隔离性好
  • 可逐步接入，先跑微信、观察效果再合

要我按路径 A 先做一个方案详细设计吗？或者你倾向哪条路？ user: 我更倾向路径B，也就是方案B；原因是：初期我需要分别校验飞书和微信的信息收集、归纳是否准确；若采用方案B，我要怎么做？ assistant: 方案B的核心思路：新建一套独立脚本，复用 80% 的逻辑，只改数据入口和输出目标。

要做的事（按顺序）

第一步：新建微信专属脚本

从飞书脚本复制一份，修改三个入口：

改什么 飞书 微信
源表 lark_group_message wechat_group_message
目标表格 AHtnsehwShUVyDtjasSciIvgn7b 新建一张微信专属表格
知识库输出 「用户反馈问题汇总」父节点 同一父节点下，标题改为 微信-YYYY-MM-DD 问题反馈

第二步：字段映射

飞书字段 微信对应字段 说明
message_id svr_msg_id（优先）或 local_id 消息唯一标识
quote_message_id refer_msg_svrid 引用关系
sender_name sender_name 一致
msg_type msg_type 一致
content content 一致，但微信多了转发嵌套格式需处理
media_url media_url 一致
msg_time msg_time 一致
msg_timestamp msg_timestamp 不一致（飞书是毫秒，微信是秒）

第三步：适配微信特有的消息格式

微信有两个飞书没有的复杂情况，需要新增预处理逻辑：

  1. 转发消息 — content 里是嵌套的 XML/聊天记录文本，需要先提取还原成可读对话
  2. 引用链弱 — 微信没有飞书的消息级引用，refer_msg_svrid 覆盖率远低于飞书的 quote_message_id

第四步：crontab 定时任务

飞书保持现有调度，微信另开一条：

0 10 * * * sync_feishu_feedback_wrapper.sh → 飞书
5 10 * * * sync_wechat_feedback_wrapper.sh --ai-placeholders → 微信

第五步：校验调试

跑几天观察：

  • 对话链排序是否准确（微信引用少，需要看聚类效果）
  • 问题描述归纳是否合理
  • 优先级分类是否正常

总结：需要新建/修改的文件

文件 动作
scripts/sync_wechat_feedback.py 新建（从 feishu 版复制修改）
scripts/sync_wechat_feedback_wrapper.sh 新建（定时任务 wrapper）
新飞书表格 新建（微信专属数据 sheet）
skills/feishu-feedback-sync/SKILL.md 修改（增加微信流程说明）

其他文件（priority_classifier.py、HEARTBEAT.md 等）不需要改。

要我现在开始写 sync_wechat_feedback.py 吗？ user: 先这样吧 我再想想 若有需要告诉你 “所有文档的 sort_tag 都是空 — 飞书 API 创建节点时 sort_tag 没生效”这个问题你看看 现在是不是权限已经开通了 assistant: 结论：权限尚未开通。

测试过程：尝试创建一个带 sort_tag 的节点 → 创建成功但 sort_tag 被静默忽略（返回 NOT_PRESENT），PATCH 接口仍然 404。

这说明飞书开放平台侧还没有给小葵应用添加 wiki:node:update 权限，李若松/张昆鹏那边可能还没处理。要我再次提醒他们吗？