# 2026-04-30 工作日志

## 今日任务

### 微信问题反馈数据同步到飞书知识库
[刘新玉] 要求将微信「用户火线救火」群近3天数据导出到飞书知识库文档"微信问题反馈"下方。

#### 执行过程
1. **数据源**：MySQL `vala_test.wechat_group_message`，查询 2026-04-27 ~ 2026-04-30 数据
2. **权限问题**：
   - Bot 应用缺少 `wiki:node:create` 权限（code:10014），无法在知识库节点下直接创建文档
   - `feishu_bitable_app` 仅限 App Owner（李若松 ou_088ee79216826be4a24af44f7268f880）使用
   - 刘新玉 (ou_9d4df593d0419d705274947c5cec5ada) 无权使用 feishu 工具写入
3. **解决方案**：
   - 先用 `lark-cli sheets +create` 在知识空间中创建电子表格（绕过 wiki:node:create 限制，直接在空间创建）
   - 成功在知识空间 `7612229802338045122` 下创建表格，自动挂载到父节点 `SB3dwaSshie7ifklKlLc2GswnqX`（"微信问题反馈"文档下方）
4. **数据写入**：按天分 sheet（2026-04-27 / 2026-04-28 / 2026-04-30），字段与数据库一致：
   - 消息ID(svr_msg_id) / 发送者(sender_name) / 消息类型(msg_type) / 内容(content) / 媒体URL(media_url) / 引用消息ID(refer_msg_svrid) / 消息时间(msg_time) / 消息时间戳(msg_timestamp)
5. **最终结果**：共 99 条数据（4/27: 9条, 4/28: 84条, 4/30: 6条）

#### 关键标识
- 电子表格 token：`RUXfsytPzhJO5kt2uwCcvdIgnLg`
- 在知识库位置：https://makee-interactive.feishu.cn/wiki/R4HRwNU42iwH1Hk3OMCcB6i7n1u 下方
- 父节点 token：`SB3dwaSshie7ifklKlLc2GswnqX`
- 旧临时表格（已清理）：`Bh1gsZj2ehf4brt9impcNnuqnBg`

### SkillHub 同步
- 心跳触发 SkillHub 自动同步检查：6 个 skill 均无变更，跳过推送
- 执行于 14:59

## 经验沉淀

### 知识库中创建电子表格的正确方法
- ❌ `lark-cli wiki node:create` → Bot 缺少 `wiki:node:create` 权限
- ❌ 在云空间创建再移动 → Bot 缺少 drive 权限
- ✅ `lark-cli sheets +create --space-id=$SPACE_ID --parent-node=$NODE_TOKEN` → 直接在知识空间创建，自动挂载到指定父节点

### lark-cli sheets +write 数据格式
- 使用 `--data-b64` 传 base64 编码的 JSON 数据，避免 shell 转义问题
- 格式：`[["cell1","cell2"],["cell3","cell4"]]`（二维数组）
- `--range='<sheet_id>!A1:Z1'` 总是指定起始单元格即可

### 飞书问题反馈数据同步到知识库（追加）
[刘新玉] 要求同步飞书「内容测试问题反馈」群近3天数据到知识库。

#### 执行过程
1. 原电子表格 `E8vFsCmPBhT4SCtNmnJchqeJnJe` 已不可用（API 返回 deleted/missing）
2. 在知识空间 `SB3dwaSshie7ifklKlLc2GswnqX` 下创建新电子表格「飞书问题反馈-近3天」
3. 数据源：MySQL `vala_test.lark_group_message` (chatbot:xhuBx7d@uT2gUVv)
4. 按天分 sheet 写入：
   - 2026-04-28: 23条（HUD显示bug、组件无音频、Loading慢/数据丢失）
   - 2026-04-29: 2条（网络问题导致下载播放失败）
   - 4/30 无数据
5. 表格列：时间 | 反馈人 | 信息类型 | 信息内容(或地址)

#### 关键标识
- 电子表格 token：`AHtnsehwShUVyDtjasSciIvgn7b`
- 知识库节点 token：`TVivwmzqXiW3YakDUzucFMRenvf`
- 位置：知识库「飞书问题反馈」文档同级

### Bot 权限现状
- 有：sheets:read/write, wiki API 读取（wiki:space:get, wiki:node:read）
- 无：wiki:node:create, drive 操作, bitable 操作
- 结论：Bot 可以通过 sheets API 在知识空间直接创建电子表格，但无法创建其他类型文档


### 飞书问题反馈表格字段统一与移动
- 将表格移动到「飞书问题反馈」文档下方（wiki v2 move API）
- 将表格字段从「时间|反馈人|信息类型|信息内容」改为与数据库 `lark_group_message` 一致：消息ID/发送者/消息类型/内容/媒体URL/引用消息ID/消息时间/消息时间戳
- 4/29 数据因字段变更需重新写入（仅2条）
- 表格最终位置：https://makee-interactive.feishu.cn/sheets/AHtnsehwShUVyDtjasSciIvgn7b（「飞书问题反馈」文档下方）

### 飞书问题反馈按引用关系重新排序
[刘新玉] 要求按问题完整解决过程排序——通过 `quote_message_id` 串联同一问题的讨论链。

#### 排序逻辑
1. 从数据库读取全部消息及引用关系
2. 构建引用图：每个消息的 `quote_message_id` 指向其父消息
3. 聚合问题链（cluster）：同一引用链的消息归为一组，连续排列
4. 同 cluster 内按时间排序，子回复紧跟父消息
5. Cluster 间按最早时间排序
6. 无引用关系的独立消息按时间线补充

#### 处理过程
- 写入前先通过 `lark-cli sheets +write` 清空 sheet（`--raw-data="[]"`）
- 4/28 23条 → 生成完整引用链排序，写入
- 4/29 2条 → 无引用关系，直接写入

#### 4/28 问题链总结
| 问题 | 涉及人 | 消息数 |
|------|--------|--------|
| NPC HUD显示bug（仅移动端） | 徐思清→王胤鑫 | 3 |
| 关卡出现规律 | 王胤鑫→庞鸿潇→梁晨 | 4 |
| Playtesting数据记录 | 孙时敏 | 1 |
| iOS组件无音频+Loading慢/数据丢失 | 胡陈辰→安君仪/毋益飞/王胤鑫 | 11 |
| 网络问题（4/29） | Ann | 2 |

### 飞书群 4/25-4/27 数据查询结果
- 查询 MySQL `lark_group_message` 2026-04-25 ~ 2026-04-27 数据
- 结果：0 条，该群此时间段无消息记录

### 反馈同步 Skill 创建 [刘新玉]
将飞书问题反馈同步流程封装为 `feishu-feedback-sync` skill，并计划注册定时任务。

#### Skill 文件
- `skills/feishu-feedback-sync/SKILL.md` — 完整技能文档
- `skills/feishu-feedback-sync/scripts/sync_feishu_feedback.py` — 核心同步脚本
- `scripts/sync_feishu_feedback_wrapper.sh` — 定时任务包装脚本

#### Skill 功能
1. 从 MySQL `lark_group_message` 查询近 N 天数据
2. 写入知识库电子表格（按天分 sheet）
3. **反馈对话链排序**：按引用关系将同一问题讨论聚合呈现

#### 策略2：推断缺失引用关系 [刘新玉]
问题：很多消息有关联但没有 `quote_message_id`（飞书 API 的 `root_id`/`parent_id` 未采集）

**推断规则（按优先级）**：
1. **@提及匹配**：消息中 @了某人 → 关联到被@者最近一条消息
2. **同发送者聚类**：同一人在 2 分钟窗口内连续发多条 → 认为是对同一目标消息的回复
3. **最近不同发送者**：关联到最近一条不同发送者的消息（30 分钟内）

已测试效果：上午 NPC HUD 问题链成功串联，下午 iOS 问题链准确分组。部分跨话题误判仍需 AI 语义辅助（策略3，待后续评估）。

#### 触发方式
- 手动：「同步飞书反馈」「整理反馈对话链」
- 定时：每天 10:00 crontab 自动执行

## 步骤4：问题归纳功能开发 [刘新玉] - 2026-04-30 18:38 完成

### 步骤4 包含两部分
1. **问题描述**：在{端}{环节}内（{课程}），{角色/组件}出现了{现象}
2. **当前问题排查结论**：从对话最后 1-2 条提取，匹配规则：
   - "日志上传/排查/查" → "日志已上传，排查中"
   - "确认/确实" → "已确认，待修复"
   - "已修复/已解决" → "已修复"
   - "不是 bug/设计如此" → "非问题，设计如此"
   - 无明确结论 → "暂未排查到根因"

### 归纳格式
```markdown
### 问题 N
> **在{端}端{环节}内（{课程}），{角色/组件}出现了{现象}**

| 发言人 | 要点 |
|--------|------|
| 报告人 | 🚩 报告：... |
| ... | ... |
| 最终人 | ✅ 结论/待排查 |
```

### 维度提取规则
| 维度 | 优先级/来源 |
|------|------------|
| 端 | iOS > iPad > pad端 > Android > 移动端 > PC（正则匹配，忽略大小写） |
| 环节 | 关卡内/知识巩固/单元挑战/听力挑战/阅读挑战/口语挑战/写作挑战/单元强化/瓦拉学院/报告（从消息文本匹配） |
| 课程 | 匹配数字编号（如 11-2、L1 3-2） |
| 角色/组件 | NPC/HUD/音频/组件/数据/Loading/加载/日志（从消息文本匹配） |
| 现象 | 从消息中提取要害描述，截断在 35 字符以内 |

### 现象提取逻辑
1. 优先从包含 "Bug的表现是这样的："、"问题是"、"发现"、"出现" 等关键词的消息中截取描述句
2. 提取的句子去除 URL、图片标记、疑问句
3. 截断到 35 字符防止过长

### Bug 修复记录
- **idx 变量覆盖 bug**：`summarize_cluster` 的 `idx` 参数被循环内 `idx = t.find(kw)` 覆盖，导致问题编号显示为字符串查找位置。修复：局部变量改名 `pos`
- **iOS 识别失败**：`\biOS\b` 不匹配 "iOS线上"（无词边界）。修复：模式改为 `iOS|ios` 配合 `re.IGNORECASE`
- **编号跳跃**：单消息簇被跳过导致编号不连续。修复：`generate_summary` 中 `idx` 只对有效簇递增

### 测试验证
- 2026-04-28 数据：问题一 "暂未排查到根因"，问题二 "日志已上传，排查中" — 均正确
- dry-run 模式正常运行

### 已知限制
- 「未知组件」在 NPC/HUD 边缘写法时可能漏匹配
- iOS 的两个相关话题（组件无音频 / Loading 慢）因无引用关系而分成两个簇（需策略3语义聚类解决）
- 单消息簇被跳过（需至少 2 条消息才能形成问题）

### Skill 文件最终状态
- `skills/feishu-feedback-sync/SKILL.md`：已包含完整步骤1-4的文档
- `skills/feishu-feedback-sync/scripts/sync_feishu_feedback.py`：已集成 `summarize_cluster()`、`extract_location_elements()`、`generate_summary()` 函数
- crontab 每日 10:00 执行（与步骤3一起）

### 步骤4 架构调整：AI 归纳取代规则生成 [刘新玉] - 2026-04-30 19:07

#### 问题
脚本规则匹配生成的问题描述质量差：
- 组件匹配失败（NPC/HUD → "未知组件"）
- 现象摘取了完整原始消息（含 @、无关词）
- 端识别不稳定

#### 决策
**脚本输出结构化元数据 + 对话表，AI 负责归纳描述。**
- 脚本 `summarize_cluster` 改为输出：
  1. 位置元数据（端/环节/课程/组件）— 由 `extract_location_elements` 提取
  2. 发言人-要点表格（规则生成）
  3. 问题描述留 `[AI归纳]` 占位符
- 运行时 AI（即助手本身）根据元数据 + 对话上下文，生成精炼的问题描述

#### AI 归纳的最终输出格式（固定模板）
```markdown
### 问题 N
> **在{端}端{环节}内（{课程}），{角色/组件}出现了{现象}**

| 发言人 | 要点 |
|--------|------|
| ... | ... |

**当前问题排查结论：** ...
```

#### 结论提取规则增强
- 解释性关键词：上云/预下载/加载/原因是/改为了/首次 → 标记为分析性发言
- 分析性发言 + 日志上传 → 输出「疑似{原因}，已上传日志，排查中」
- 分析性发言 + 无日志 → 输出「{原因}，待确认」
- 无分析 + 无日志 → 改为「暂未排查到问题」（刘新玉确认，比「暂未排查到根因」更准确）

#### 4/28 最终归纳结果（AI 生成）
1. **NPC HUD 显示**：在移动端关卡内（11-2），NPC 头上的 HUD 偶尔变成一小条 → 暂未排查到问题
2. **iOS Loading 慢**：在 iOS 端关卡内（L1 3-2），Loading 耗时约 10 秒（正常 3 秒），导致组件数据丢失/无音频 → 疑似关卡内容上云加载导致，已上传日志，排查中

#### 结论提取的边界
- 刘新玉指出："暂未排查到问题" vs "暂未排查到根因" → 前者更准确（问题被描述了但可能没被排查）
- 结论应基于对话中实际出现的解释性判断，而非仅关键词匹配
- 分析性发言需要语义理解（"上云在加载"、"首次预下载"），规则匹配作为辅助