morning-report

name	morning-report
description	为 text-matrix 生成四类中文早报:AI 新闻早报、经济财经早报、AI 副业午报、Web3 早报。触发词:"做早报""写早报""morning report""AI 新闻早报""财经早报""副业午报""副业早报""Web3 早报""加密货币早报"。强制 24h 时间窗、Browser 逐条核链、V2EX 验真、Web3 事件级去重、Hugo 快讯 frontmatter 输出。
metadata	{"version":"2.3.0","tags":["morning-report","news","hugo","verification","workflow","web3-dedup"]}

Morning Report Skill

⚠️ 2026-06-19 重要变更：Web3 早报事件级去重（师父拍板 C 方案）

新增 Step 2.5 - 事件级去重（仅 Web3 早报任务触发）：

• Web3 早报历史曾发生 3 条"持续更新型"URL 跨 3-14 天复用问题（2026-06-19 早报 6-05 fg-nexus、6-14 bitmine、6-16 strategy 三条 URL 被 cron 反复抓取）
• 根因：CoinTelegraph 大量"持续更新"型文章（同一 URL 内容持续被作者更新）+ cron prompt 缺"已用 URL 黑名单"约束
• 修复：所有 web3 早报任务在动笔前必须先跑 scripts/morning-news-web3-dedup.sh 去重，命中严重复用（跨 ≥ 3 天）的 URL 直接丢弃
• 详见 references/web3-event-dedup.md + 下方 Step 2.5 强制流程

Morning Report Skill

核心原则

与通用聚合器的区别:每条新闻必须通过 Browser 逐条打开原文页核验,禁止直接使用列表页、摘要页或猜测 URL。

⚠️ frontmatter date 硬性规则（2026-06-03 故障后新增）

绝对禁止：把「计划发布时刻」（如 08:00 / 08:30 / 09:00）作为 date 填入 frontmatter。

原因：Hugo 生产构建按 date 过滤页面，date 晚于构建时间的页面会被判为「未来页面」并整篇排除，不会出现在 public/ 输出中。如果实际写入磁盘是 08:27、但 date 填 08:30，Hugo 提前构建会在 08:27 扫到该文件并排除。

正确做法：

• date = 「实际写入磁盘时刻」 - 5 分钟（如实际生成 10:00 → date 填 09:55）
• 公式：TZ=Asia/Shanghai date -v-5M "+%Y-%m-%dT%H:%M:%S+08:00"
• 验证：生成后用 git log -1 --format=%cd 确认 commit 实际时间，frontmatter date < commit 时间 才算合规

故障示例（2026-06-03 08:27:53 UTC+8）：content/posts/news/financial-morning-news-2026-06-03.md 的 date: 2026-06-03T08:30:00+08:00（计划时刻）晚于 Hugo 构建时间 08:27:53，整篇被排除；该问题已由主 AI 介入补做，date 改为 09:50 修复。

任务路由

收到请求后先确认范围,再按需加载对应文件:

输入信号	任务	必须加载	禁止加载
"检查早报""修复早报""纠正早报"	审核并修复已有早报	template.md;逐份加载对应来源文件	不要把已有正文当作事实来源
"AI 新闻""AI 早报""模型新闻"	仅 AI 新闻早报	template.md + ai-news-sources.md	其余来源文件
"财经早报""经济早报""市场早报"	仅经济财经早报	template.md + finance-sources.md	其余来源文件
"副业午报""副业早报""招聘早报""赚钱机会"	仅 AI 副业午报	template.md + side-hustle-sources.md	其余来源文件
"Web3""加密货币""币圈""BTC""ETH"	仅 Web3 早报	template.md + web3-sources.md + web3-event-dedup.md	其余来源文件
"做早报""写早报""morning report"	全部 4 份	template.md;逐份加载对应来源文件	不要一次全量预加载

未指定日期 → 使用今天;指定日期 → 仍只采集该日期回溯 24h 内容。

如果用户提供的是已有早报文件,执行逻辑改为:先把现稿当作候选清单而不是事实来源,逐条反查原文;无法核验的条目必须删除或替换,不能只在原稿上润色。

执行流程

每份早报独立执行以下步骤：

1. 识别（输入：用户请求 → 输出：早报类型 + 目标日期） 确认早报类型；加载相应 references 文件。
2. 采集（输入：来源站点 → 输出：候选 URL + 发布时间列表） 逐条记录文章 URL；禁止用栏目页更新时间替代文章发布时间。 2.5. 🆕 Web3 事件级去重（仅 Web3 任务触发，强约束）
   • 触发条件：早报类型 = Web3
   • 强制流程：
     1. 采集到候选 URL 列表后、动笔前，必须先跑仓库根目录下的 scripts/morning-news-web3-dedup.sh：

        cd ~/.openclaw/workspace/github/text-matrix
        bash scripts/morning-news-web3-dedup.sh --threshold 3 --window 14 <url1> <url2> ...
        # 或从候选文件读：
        cat /tmp/web3-candidates.txt | bash scripts/morning-news-web3-dedup.sh
        

     2. 脚本返回 exit 0（无严重复用）→ 正常进入 Step 3。
     3. 脚本返回 exit 1（有严重复用）→ stdout 会列出"严重复用"的 URL + 命中历史，必须把这些 URL 从本轮写文章清单中剔除，只对脚本标记的"✅ 新事件"列表动笔。
     4. 严重复用 URL（跨 ≥ 3 天）一律丢弃，不允许"复用 + 改写时间副词"。
   • 3 重判定（任一命中即视为"已用"）：
     • A 重 - state file：~/.openclaw/workspace/state/web3-event-fingerprint.json（本地，不入 GitHub）
     • B 重 - 文件系统：扫 content/posts/news/web3-morning-news-*.md 全部历史早报（自动排除"今天"避免自我命中）
     • C 重 - 持续更新型标记：state 中 is_continuously_updated=true 的 URL + 跨 ≥ 3 天 → 🔴 强制丢弃
   • 历史教训（2026-06-19 复盘）：6-19 web3 早报 11 条 URL 中 3 条严重复用（fg-nexus 14 天、bitmine 5 天、strategy 3 天），均为 CoinTelegraph "持续更新"型文章，AI 用新时间副词包装旧事件制造"新事件"假象。根因：cron prompt 只有"24h 时间窗口"无"已用 URL 黑名单"。本 Step + 脚本彻底封死此类问题。
3. 核验（输入：候选列表 → 输出：通过验证的条目） 逐条打开原文页，确认发布时间在 24h 内、正文主题与标题吻合；V2EX 条目必须打开帖子页验证标题、正文和发布者。
4. 筛选（输入：核验结果 → 输出：精简条目列表） 删除超时、无稳定原文页、标题-正文不符、信息密度不足的条目；同主题重复稿保留最完整的一条。
5. 撰写（输入：精简条目 → 输出：结构化草稿） 按 template.md 骨架分组；每条写 2-3 句实质性摘要，只能来自实际浏览到的信息。
6. 自检（输入：草稿 → 输出：通过/回滚决定） 执行下方自检清单；任一失败返回步骤 3。
7. 链接最终核验（输入：草稿 → 强制步骤，不能跳过） 生成 Markdown 文件后、git push 前，使用 Playwright 逐个打开正文中的 [原文](url) 链接，验证：页面能正常访问、页面标题与摘要描述匹配；发现无效链接立即修复或删除该条新闻；禁止凭记忆/猜测写链接。
8. 输出（输入：通过自检的草稿 → 输出：content/posts/news/ 下的 Markdown 文件） 执行 git push 后立即验证远程仓库是否更新成功；若 push 失败（rejected/fetch first），必须 git pull --rebase 后再 push。

输出要求

• 输出目录固定为 content/posts/news/。
• 输出文件名固定为 slug.md,不要自定义其他命名。
• 文末"数据来源"只列正文实际引用过的来源,且应与正文出现顺序尽量一致。
• 若正文含价格表、链接核查清单或原文链接汇总,均只保留真实采集结果,不能保留模板占位值。

完成汇报格式

完成生成后,向用户汇报时至少包含以下信息:

• 已生成的早报类型与对应文件名。
• 每份早报的实际来源数量;若低于理想覆盖,明确说明原因。
• 是否存在被丢弃的候选条目,以及丢弃原因(如超出 24h、无稳定原文页、正文不匹配)。
• 若用户要求草稿,明确说明未执行发布动作。

链接验真示例

✅ 正确:打开 https://techcrunch.com/2026/04/07/openai-raises/ 后,确认标题、正文与发布时间均匹配,原文字段写 [原文](https://techcrunch.com/2026/04/07/openai-raises/)。

❌ 错误:直接使用 https://techcrunch.com/ai/(列表页),或未打开原文就根据标题猜测摘要内容。

摘要校准示例

✅ 正确:摘要写"公司发布新模型,并同步公布 API 定价和企业接入计划;正文还提到该模型已在客服场景上线",信息来自正文已见内容。

❌ 错误:摘要写"这标志着 AI 行业进入新纪元,未来市场空间巨大",只有空泛判断,没有正文可验证信息。

硬约束

时间窗口

• 只保留过去 24h 内发布的内容;无法确认发布时间的条目直接丢弃。

内容质量

• 摘要必须是信息提炼,不是改写标题,也不是泛泛而谈。
• 优先保留高信息密度条目:融资、财报、产品发布、模型更新、监管政策、市场数据、招聘需求、真实变现案例。

来源覆盖

早报类型	最低要求
AI 新闻早报	≥ 3 个来源,含 ≥ 2 中文 + ≥ 1 海外
经济财经早报	≥ 2 核心财经来源;行情必须写出关键数字
AI 副业午报	≥ 3 个来源,含 ≥ 1 社区 + ≥ 1 内容来源
Web3 早报	CoinMarketCap + CoinDesk;Browser 采集真实价格,禁止模型幻觉数据

Hugo frontmatter

title: "中文标题(含日期)"
date: YYYY-MM-DDTHH:MM:SS+08:00
slug: <固定规则,见下表>
description: "50-100 字纯文本摘要"
draft: false
categories: ["行业快讯"]
tags: ["名词1", "名词2"]   # 2-5 个精准名词
hiddenFromHomePage: true

固定 slug(禁止修改命名模式):

早报	slug 格式
AI 新闻早报	ai-morning-news-YYYY-MM-DD
经济财经早报	financial-morning-news-YYYY-MM-DD
AI 副业午报	ai-side-hustle-noon-news-YYYY-MM-DD
Web3 早报	web3-morning-news-YYYY-MM-DD

禁止项

• 编造新闻、摘要、发布者、链接、发布时间。
• 把栏目页、聚合页、快讯流入口当作原文链接。
• 禁止凭记忆/猜测写链接,必须实际访问验证后才能写入正文。
• 因来源不足硬凑低质量内容。
• 输出裸 URL 或"见原文"等无链接文本。
• 修改 slug 命名规则。
• 跳过 V2EX 帖子验真。
• 未逐个验证链接有效性就 push 到 GitHub。

输出前自检

检查项	要求
时间窗口	所有条目发布时间在过去 24h 内
链接验真	每条都打开过原文页,标题与正文匹配
原文字段格式	全部使用 [原文](url)
frontmatter 完整性	含 draft: false 和 hiddenFromHomePage: true
slug 格式	符合固定命名模式
标签质量	2-5 个具体名词,非空泛词
来源汇总一致性	文末汇总与正文实际引用一致
占位文本清除	所有示例 URL、用户名已替换为真实值

生成后自检回执

完成单份早报后,必须在内部形成一份简短回执;若是回复用户,可按需显式汇报:

字段	要求
文件名	必须等于 slug.md
时间窗结果	写明 通过 / 失败
已保留条目数	统计正文实际保留条目
已丢弃条目数	统计被移除候选数
丢弃原因	只能写:超出 24h / 无稳定原文页 / 标题正文不符 / 信息密度不足 / 链接失效
来源数	统计正文实际引用来源数量
结构检查	frontmatter、[原文](url)、标签数、文末来源汇总是否全部通过

若任一项失败,回到"核验"或"筛选"步骤重做,禁止带着失败项输出成品。

异常处理

情况	处理
当天高质量条目不足	保持少而准;汇报时说明来源不足
原站无稳定文章页	丢弃,换来源
列表页与正文冲突	以正文页为准;无法消解则丢弃
用户只要草稿	同样校验标准生成 Markdown,不执行发布