# 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` 控制：

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

```python
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` 权限，李若松/张昆鹏那边可能还没处理。要我再次提醒他们吗？
