Intel Briefing — 全域情报简报生成系统

手动触发的情报简报生成工具。从多信源采集信息，经评分、去重、排序后输出 HTML 简报。

一、工具链

核心原则

搜索优先使用 OpenClaw 内置搜索能力（如 Kimi），抓正文用 web_fetch。不依赖任何外部 CLI 工具。

工具分工

环境兼容性

本 Skill 设计为零外部依赖，可在以下环境运行：

• ✅ OpenClaw 本地 TUI（内置搜索 + Bash 工具）
• ✅ OpenClaw 云端（内置搜索 + Bash 工具）
• ✅ 任何支持 OpenClaw 的环境

不需要安装： z-ai-web-dev-sdk、web-scraper-jina、multi-search-engine 等外部包。

搜索策略

首选：OpenClaw 内置搜索

• 直接在对话中提出搜索请求，OpenClaw 会调用配置的搜索 provider（如 Kimi）
• 中文搜索质量优秀，适合中文情报采集
• 无需任何额外配置

备选：web-search 技能

• 如果 OpenClaw 内置搜索不可用，尝试使用 web-search 技能
• clawhub install web-search（如需安装）

二、信源清单

P0 信源（每次必须采集）

> 策略说明（2026-04-08更新）： web_fetch对财联社和36氪提取质量优秀（质量9/10），设为主方案。华尔街见闻为JS渲染页面，web_fetch无法提取，保持搜索降级。每次推送时如web_fetch返回内容<200字符或质量不佳，立即搜索降级。

P1 信源（搜索降级）

P2 信源（补充采集，每次尝试）

策略： P2信源作为信息补充，每次推送时尝试采集。如时间/资源不足，优先保证P0+P1，P2可裁剪。

热榜（每次至少搜索2个平台）

AI新闻（6维度搜索）

如果 ai-news-collectors 技能已安装，直接调用。否则用 OpenClaw 内置搜索按以下6维度搜索：

执行模式配置

根据场景选择执行策略：

决策建议：

• AI类信息已由Step 2覆盖，P1信源可酌情跳过AI相关
• 早间/晚间选择质量优先，午间选择效率优先
• 紧急情况下仅保留P0+热榜

三、执行流程

Step 1：读取记忆（去重基准 + 上次复盘验证）

1. 运行 read_daily 读取最近两天的日常笔记
2. 运行 read_memory 读取长期记忆
3. 在 daily 笔记中找到最近一次"简报复盘"段落，提取"下次执行待验证"列表

Step 2：AI新闻采集（必须首先执行）

优先调用 ai-news-collectors 技能（如已安装）。

如未安装，用 OpenClaw 内置搜索按6维度搜索（见信源清单）。

Step 3：热榜搜索

用 OpenClaw 内置搜索获取至少2个平台的热搜榜单。

Step 4：P0信源采集

主方案：web_fetch（财联社 + 36氪）

使用OpenClaw内置 web_fetch 工具抓取（extractMode=text，maxChars=5000）：

• https://www.cls.cn/telegraph — 财联社快讯
• https://36kr.com/newsflashes — 36氪快讯

搜索降级（华尔街见闻 + web_fetch失败时）

• 华尔街见闻为JS渲染页面，web_fetch无法提取，直接搜索降级："华尔街见闻 最新 [当前日期]"
• 如财联社/36氪的web_fetch返回<200字符或质量不佳，搜索降级："财联社 最新 快讯 [当前日期]" / "36氪 最新 快讯 [当前日期]"

降级规则：

• web_fetch返回<200字符或无实质内容 → 搜索降级
• 搜索结果质量不足 → 用更精确关键词重新搜索
• 两种方式均失败 → 在简报中标注该信源采集失败，不虚报内容

Step 5：P1信源降级搜索

用 OpenClaw 内置搜索搜索P1信源关键词。

按第二章「执行模式配置」选择信源数量：

• 质量优先模式：3个全搜
• 效率优先模式：2个（国际+社会）
• 紧急模式：1个（国际）或跳过

Step 6：补充搜索

根据已采集信息中的关键事件，补充搜索最新进展。

按第二章「执行模式配置」选择轮次：

• 质量优先模式：最多5轮
• 效率优先模式：最多3轮
• 紧急模式：1-2轮或跳过

Step 7：分析、评分、输出

去重分析（必须执行）：

1. 读取上一版已推送内容（memory/YYYY-MM-DD.md）
2. 逐条对比，标注每条状态：
• 🆕 新增：上一版未出现
• 📰 更新：已报事件有新进展
• ⏸️ 维持：已报事件无新变化（仅在文末简要回顾）
• ❌ 移除：重要性下降或已被覆盖
3. 仅保留 🆕 和 📰 的条目在正文，⏸️ 移入文末"此前已报"

评分与排序：

1. 按评分体系评分，每类内按综合评分降序排列
2. 生成 HTML 简报（按 template.html 模板格式）
3. 保存到 download 目录

Step 8：更新记忆

运行 edit_daily 更新当日笔记，记录已推送内容摘要。

Step 9：执行复盘

按复盘规则（第九章）记录本次执行情况，通过 edit_daily 追加到当日笔记。

四、评分体系

综合评分 = 影响力(40%) + 敏感度(30%) + 热度(30%)，每项满分100，加权求和。

> 完整评分规则及置信度体系见 references/scoring.md

五、去重规则

基础去重

1. 同一事件的新事实（新战果、新声明、新数据、新反转）→ 视为新进展，纳入简报
2. 同一事实的不同媒体报道 → 视为重复，不重复纳入
3. 已报事件无新进展 → 不重复提及
4. 去重基准：读取最近一次简报的 daily 笔记

更新版去重（同日多次推送）

当同一天多次生成简报时，更新版必须严格执行以下规则：

1. 逐条对比上一版已推送内容，明确标注每条状态：
• 🆕 新增：上一版未出现过的事件
• 📰 更新：已报事件有新进展（展开新事实，不重复旧内容）
• ⏸️ 维持：已报事件无新变化，仅在文末简短回顾（1句话以内）
• ❌ 移除：已报事件重要性下降或已被后续事件覆盖
2. 不允许整份重写：更新版应聚焦增量信息，而非把上一版内容重新排版
3. 短间隔更新（<2h）：只报真正有新进展的事件，其余一律移入文末"此前已报"区域，不超过3行
4. 新增/更新的条目综合评分应重新计算，反映最新情况

六、输出规范

文件命名

• 存档版：intel-briefing_YYYYMMDD_HHMM.html（如 intel-briefing_20260408_1900.html）
• 最新版副本：intel-briefing.html（每次推送覆盖）

> 注：统一用实际时间 HH:MM 标识，时区标注为"北京时间"

保存路径

使用 OpenClaw 的 download 目录（通常是 {项目目录}/download/）。

• 云端环境：/home/z/my-project/download/
• 本地环境：由 OpenClaw 自动管理的 download 目录

> 注意： 不要硬编码绝对路径。使用相对路径 download/ 或让 OpenClaw 自动管理文件位置。

> QQ 通道特殊要求： 推送前需将文件复制到 ~/.openclaw/media/qqbot/ 目录，否则 标签会被拒绝。

输出格式

• 必须为 HTML 网页（移动端优先深色主题）
• 参考模板：references/template.html
• 页面结构：吸顶导航 → 日期栏 → 分类筛选标签 → 四类统计卡片 → 分类信息卡片列表 → Agent结论 → 页脚

卡片设计

每条信息生成一个可折叠卡片，包含：

• 排名编号（1-5 不同颜色）
• 标题
• 标签行（状态标签 + 置信度标签 + 风险标签 + 信源标签）
• 综合评分
• 展开后显示详情

标签布局规范

标签统一放在标题下方，顺序为：

[标题]
[状态标签] [置信度标签] [风险标签] [信源标签] [信源标签...]
[综合评分]

状态标签规范

风险标签使用规范

何时标注：

• 军事冲突/武装对抗（敏感度评分+30）→ 使用 risk-inline
• 重大政策转向/经济危机 → 使用 risk-mid-inline
• 可能存在议程设置、情绪操控的信息 → 使用 risk-info-inline
• 标题党/夸张表述、单一信源的重大事件、明显情绪煽动性语言 → 使用 risk-info-inline
• 缺乏数据支撑的健康/安全警告 → 使用 risk-info-inline

高风险卡片样式：

• 添加 risk-high 类到 .item 元素
• 显示2px红色边框+红色发光阴影
• 在标签行中使用 ⚠ 风险描述

中风险卡片样式：

• 添加 risk-mid 类到 .item 元素
• 显示2px橙色边框+橙色发光阴影
• 在标签行中使用 ⚠ 风险描述

推送方式

根据当前通道自动选择推送方式：

QQ通道重要规则：

• 只发送 标签，不要附带任何文字说明
• 文字内容会导致文件推送失败
• 文件路径必须为绝对路径
• 过程信息写入当日 daily 笔记，不在聊天中输出

内容深度规范

卡片详情（item-body-inner）必须包含以下维度：

内容长度标准：

• 每条详情不少于 3-5句话，约80-150字
• 高分事件（评分≥85）应达到 5-8句话，约150-250字
• 不允许只写一句话的简单描述

省略规则

• 省略"与以往简报的对比"段落，直接报新增信息
• 不省略卡片详情内容，确保信息完整

七、输出前自检清单

每次推送输出前逐项确认：

• [ ] ai-news-collectors 已调用（如已安装），或6维度搜索已完成
• [ ] 四个分类都有内容（或明确标注"无重大新增"）
• [ ] 每条信息综合评分≥45
• [ ] 每条信息包含置信度标签（1-5）
• [ ] 每条信息详情≥3句话，高分事件（≥85）≥5句话
• [ ] 关键数据已提取（时间、金额、人数等）
• [ ] 背景信息已补充（涉及方、历史背景）
• [ ] 每类内按评分降序排列
• [ ] 去重：逐条对比 daily_log 中已报事件（更新版需标注每条状态）
• [ ] 人名注释完整（非全球顶级知名人物均需注释）
• [ ] 风险预警标注
• [ ] P0信源已采集（web_fetch或搜索降级）
• [ ] 输出格式为 HTML
• [ ] 文件已保存到 download 目录
• [ ] 文件名包含日期（存档版）且更新了最新版副本
• [ ] 通过当前通道发送文件（QQ用qqmedia标签，其他环境回复摘要）
• [ ] edit_daily 已更新当日笔记

八、推送失败处理

• 如果推送过程中断（工具调用超限、抓取大面积失败等），必须输出一条告警信息告知用户本次推送未完成
• 记录失败原因到当日 daily 笔记，供下次推送参考
• 自动续接：中断后自动继续执行直至完成，不等待用户发送"继续"

九、复盘机制

复盘频率

• 前20次推送：每次复盘
• 之后：每天复盘（当天最后一次推送时记录）

复盘内容

每次复盘记录以下内容（通过 edit_daily 写入当日笔记）：

1. 自检清单达标情况（14项表格）
2. 信源采集统计（有效信源数/总数）
3. 未达标项分析（问题/严重级/根因/改进措施）
4. 下次执行待验证列表

问题分级

迭代闭环

推送执行 → 自检清单 → 复盘记录 → 问题分级 → 自动修复 → 下次执行验证
     ↑                                                        |
     └────────────────────────────────────────────────────────┘

关键规则：

1. 复盘记录写入 edit_daily（当日笔记），不写入长期记忆
2. 致命级问题的修复措施必须标注"下次执行待验证"
3. 下次执行时，必须先读取上一次复盘记录，逐项验证待验证项
4. 连续3次同一问题未修复 → 升级为致命级，暂停简报生成并告警用户

十、依赖技能

十一、架构审查与版本管理

> 完整触发条件框架、审查清单、效率评估及清理规范见 references/architecture-review.md

十二、版本管理规范

> 完整 SemVer 规则及发布 checklist 见 references/version-management.md

十三、版本历史

> 完整版本历史见 references/version-history.md

最近更新：