每日进化报告 - 2026-07-15

📊 系统健康检查

项目 状态 数据
Cron 配置 ✅ 正常 关键任务均未注释
北京展览爬取 ✅ 执行成功 17 个展览（本地宝 34→去重 17）
飞书文档同步（cron） ❌ 失败 openclaw feishu_doc 不是 CLI 命令
飞书文档同步（手动） ✅ 成功 22 个展览，165 块写入
记忆文件 ✅ 存在 2026-07-15.md
携程数据源 ⚠️ 0 条 连续多日提取 0 条

🔥 今日重大事件

北京展览爬虫覆盖问题（P0，已修复）

时间线：

  1. 07-14：手动整理高质量报告（含中国美术馆文艺复兴展、八大山人展、798吴哥窟、故宫、敦煌等）
  2. 07-15 09:00：cron 自动执行 crawler_v3.py，只有本地宝一个数据源，覆盖了手动报告
  3. 07-15 09:00：飞书同步也失败（openclaw feishu_doc 不是有效 CLI 命令）
  4. 07-15 晚间用户发现并修复

根因：crawler_v3.py 虽然有 4 个数据源函数，但携程提取返回 0 条，实际只有本地宝在运行。且分类逻辑过于粗糙，茶文化、儿童画被分到第一梯队。

修复内容：

  • ✅ 新增 3 个数据源：中国美术馆、重点展览补充、携程修复
  • ✅ 分类逻辑重构：白名单（文艺复兴/八大山人/吴哥→强制第一梯队）+ 黑名单（茶文化/儿童画→强制第三梯队）
  • ✅ 手动同步飞书：22 个展览，第一梯队 10 个全部优质

⚠️ 未解决问题

1. Cron 飞书同步仍然失败（P1）

feishu_sync_fixed.py 调用 openclaw feishu_doc write CLI 命令，但该命令不存在（feishu_doc 是 agent 工具，不是 CLI 子命令）。

影响：每天 cron 爬取后自动同步飞书无法完成，必须依赖手动同步或 agent session 触发。

建议方案：

  • 方案 A：将 cron 同步改为通过 cron job 触发 agent session（isolated）来调用 feishu_doc 工具
  • 方案 B：改用飞书 OpenAPI 直接写入（绕过 openclaw CLI）
  • 方案 C：将同步逻辑内置到 daily_cron.sh，通过 gateway wake 触发 agent 处理

2. 携程数据源持续返回 0 条（P2）

携程页面结构可能已变更，需要更新 CSS 选择器或切换到 API 接口。

📝 工作记录

时间 事件 状态
09:00 cron 爬取 17 个展览 ✅ 执行
09:00 cron 飞书同步 ❌ 失败
23:24 用户发现数据被覆盖 🔴 P0
23:30 新增 3 个数据源 ✅
23:35 重构分类逻辑（白名单/黑名单） ✅
23:42 手动同步飞书（22 展览/165 块） ✅
23:44 git commit ✅ c25d07b

🧠 经验教训

1. 单数据源风险（⭐ 新增）

  • crawler_v3.py 名义上有 4 个数据源，但实际只有本地宝在产出数据
  • 单点故障：任何一个数据源出问题就影响整体质量
  • 教训：必须对每个数据源做独立健康检查，连续 3 天返回 0 条必须告警

2. Cron 自动覆盖手动工作（⭐ 新增）

  • cron 任务设计为"全量覆盖"模式，会覆盖手动整理的内容
  • 教训：当有手动干预时，应设置标记文件避免 cron 覆盖；或 cron 只在内容更丰富时才覆盖

3. CLI vs Agent 工具混淆（⭐ 新增）

  • openclaw feishu_doc 不是有效 CLI 命令，只存在于 agent 上下文中
  • 这个问题已存在多日但日志一直被忽略
  • 教训：cron 脚本中不应依赖 agent-only 的工具

📋 明日计划

  1. P1：修复 cron 飞书同步方案（改用 cron job → isolated agent session 模式）
  2. P2：修复携程数据源（更新选择器或移除）
  3. P2：验证 09:00 cron 爬取的数据质量和飞书同步
  4. P3：为 crawler 添加数据源健康检查告警

📈 趋势数据

指标 今日 昨日 基线
展览数量（cron） 17 20 15-25
展览数量（手动） 22 - -
飞书同步 ❌→✅手动 ✅ ✅
用户交互 1 次 0 次 -

生成时间：2026-07-15 19:25 UTC 维护者：Travel Agent