ai-briefing

name: ai-briefing description: > 查询、起草或发布博客“AI 简报”。当用户提到“AI 简报”“每日简报”“AI 雷达”“AI 前沿雷达” “今天 AI 厂商发布了什么”“厂商动态汇总”或要求追踪 OpenAI、Anthropic、Google/DeepMind/Gemini、xAI、Meta AI、Perplexity、Mistral、月之暗面/Kimi、小米 MiMo、DeepSeek、智谱 AI、MiniMax 等厂商近期确定性动态时使用。 本 skill 默认进入查询模式；当用户明确要求生成简报时进入成稿模式；当用户明确要求发布时，执行完整审核和自动发布流程。 argument-hint: "[时间范围，如 今天/本周/2026-05-08] [厂商，如 OpenAI xAI] [关键词，如 GPT-5.5/Gemini API] [选项，如 只生成不发布/英文]"

AI 简报 Skill

功能概述

面向博客的三段式工作流：追踪重点 AI 厂商在指定时间窗口内的确定性动态，核验时间证据与来源可靠性，并根据用户意图执行查询、成稿或发布。

默认跟踪厂商与重点新闻采集对象以 config/focus-companies.json 为准。

当前默认跟踪厂商：OpenAI、Anthropic、Google/DeepMind/Gemini、xAI、Meta AI、Perplexity、Mistral、月之暗面/Kimi、小米 MiMo、DeepSeek、智谱 AI、MiniMax。

当前重点新闻采集对象：OpenAI、Anthropic、Google/DeepMind/Gemini、xAI、Meta AI、Perplexity、Mistral、月之暗面/Kimi、小米 MiMo、DeepSeek、智谱 AI。

默认行为

用户明确说“只生成不发布”“不要提交”“不要 push”时，不能进入发布模式。

意图分流

默认规则

默认进入查询模式。

如果用户表达不足以明确说明要“生成稿件”或“发布”，则不能进入后两段。

模式定义

• 查询模式：只查询、核验并回答，不落盘，不 commit，不 push。
• 成稿模式：生成完整 Markdown 草稿并返回给用户，但本轮不落盘，不 commit，不 push。
• 发布模式：执行查询、成稿、最终审核、仓库门禁，并在全部通过后自动 commit / push。

触发词映射

歧义降级

若用户语义存在歧义，例如：

• 今天 AI 圈发生了什么
• 厂商动态汇总
• 最近 OpenAI / Anthropic 有什么

则一律按查询模式处理。

原则：

• 宁可少发布
• 不要误发布

硬规则

时间证据

时间判断一律先换算为北京时间（Asia/Shanghai），再判断是否属于本期统计窗口；禁止直接按来源页面显示的本地日期归类。

没有明确发布日期或事件时间证据的内容，不能进入正文确定区。所有候选动态都必须先换算到 Asia/Shanghai，再判断是否落在本期统计窗口内。

可接受的时间证据包括：

• 官方博客、公告页、更新日志上的发布日期。
• GitHub Release、Commit、Tag 时间戳。
• Hugging Face 模型或数据集更新时间。
• 权威媒体报道时间；仅在无法找到原始事件时间时使用，并注明“以报道时间计”。

旧事新报不计入当期动态，除非用户明确要求回顾。

来源等级

• [官方]：官方博客、公告、GitHub Release、Hugging Face、官方 changelog。
• [媒体报道]：Reuters、Bloomberg、TechCrunch、The Verge、36kr 等权威媒体。
• [待核验]：无明确日期证据、单一非权威来源、社交媒体传闻。

[待核验] 只能进入内部审核或查询模式中的待核验线索，不得进入正文确定区。

重点厂商覆盖

以下厂商属于重点新闻采集对象，名单以 config/focus-companies.json 中 priorityFocus: true 的条目为准。

默认跟踪厂商不等于重点新闻采集对象。未进入重点名单的厂商（如 MiniMax）仍在默认跟踪范围内，但不要求每期执行重点补检或逐一覆盖检查。

对这些重点厂商，生成每期简报或执行重要查询时必须执行“逐一覆盖检查”，不能因为第一轮通用搜索结果为空、搜索结果靠后或候选较少，就默认该厂商当期无重要更新。

对于模型代际发布、旗舰模型升级、API/SDK/Agent 平台更新、价格变化、上下文窗口变化、推理能力变化、开放范围变化等高价值动态，必须额外做一次 changelog / release notes / 官方发布页补检，避免漏掉类似 GPT-5.5 这类重大发布。

若重点厂商在当前统计窗口内没有满足条件的确定性动态，也应在内部审核摘要中明确记录“已检查，无符合窗口的确定性更新”。

重点厂商覆盖检查必须形成一份内部清单或内部审核摘要，至少记录：厂商名、是否已检查、本期是否有符合时间窗口的确定性动态、未入稿原因，以及入稿时使用了哪些官方源或权威源确认。

这份覆盖清单仅用于内部审查、审核报告和发布前自检，禁止写入最终简报正文、frontmatter、## 来源 小节或任何面向读者的公开内容中。

查询模式公开边界

查询模式只能基于公开、可核验来源回答；非公开、泄露、NDA、受限访问页面或私下沟通获得的信息一律不得输出给用户，也不得作为待核验线索对外展示。

与最近 5 期去重

• 默认必须对照最近 5 期已发布 AI 简报做去重检查；若已发布历史不足 5 期，则按已有全部历史检查。
• 不得与最近 5 期内任一期重复报道同一新闻事件，除非本期窗口内出现新的、可核验的实质进展。
• 仅仅换一种表述、重写标题、拆分旧事实或重复背景信息，不算新条目。

正文长度

成稿/发布模式下，正文汉字数必须在 900~1300 之间，不统计 ## 来源 章节下的字数；frontmatter 与内部审核摘要也不计入正文长度。

当当天可入稿的确定性新闻较多时，在不添加空话、不重复表述的前提下，正文长度应尽可能接近 1300 字上限，优先补充关键事实、技术细节、发布时间和影响判断。

写作可读性

简报不是论文综述，也不是长新闻稿。读者通常在手机或列表页中快速扫读，因此正文必须优先保证节奏清楚、段落轻、信息密度可控。

成稿/发布模式下遵守以下写法：

• 开篇导语也要短句、短段落。不要用一个长段塞入所有主线，优先写成 2~4 个小段。
• 章节正文必须小段落、多段落。单段目标控制在 80~120 个中文汉字内；超过 120 字时，优先按“事实、解释、影响”拆成多个段落。
• 每个自然段只承载一个意思。不要为了凑字数把两个判断、两个事件或事实与影响塞在同一段。
• 单句尽量不超过 50 个中文汉字；连续使用多个顿号、分号或长破折号时，要改写成短句。
• AI 简报保持 ## 速览、## 重点动态、## 为什么值得关注、## 来源 结构；不要套用投资简报的 ## 近 24 小时确认动态 / ## 未来重点观察 结构。
• ## 重点动态 下优先使用多个 ### 子标题承载提炼判断，而不是用长列表堆叠信息。
• ### 子标题要写成信息提炼，例如“OpenAI 把企业交付单独公司化”，不要只写厂商名或空泛名词。
• 每个 ### 下正文用多个 80~120 字左右的短段描述。先写确认事实，再写关键细节，最后写影响判断；不要把多个事件塞进同一个自然段。
• 列表只适合 ## 速览、## 来源、内部审核摘要或同维度枚举。公开正文主体不要用一串 bullet 替代叙述。
• brief 应压缩成一句清晰摘要，避免列出过多并列事实。

文件格式

正式发布文件生成 .md，不要生成 .mdx。

frontmatter 模板：

---
title: "AI 简报 · YYYY-MM-DD"
date: "YYYY-MM-DD"
brief: "一句话概括当天最重要的 AI 厂商动态。"
published: true
tags:
  - AI
  - OpenAI
---

二次复审

• 成稿模式与发布模式中，在本 skill 完成内部审核摘要后，必须再调用项目级 subagent ai-briefing-reviewer 做第二道阻断式复审。
• 传给 reviewer 的材料至少包含：Markdown 草稿、内部审核摘要、本期时间窗口、重点厂商覆盖清单、剔除项与原因、最终入稿项与对应来源，以及针对最终入稿项的 权威性 / 真实性 / 时效性 自审结论。
• 若 reviewer 判定为“需修改后复审”或“阻断发布”，则本轮只能返回问题与修改要求，不得进入发布门禁、commit 或 push。

执行流程

1. 确定时间窗口

解析用户输入中的时间、厂商、语言和发布选项。未指定时按 Asia/Shanghai 使用“当前执行时刻向前回溯 24 小时”作为统计窗口。

默认可按“固定执行时刻触发”理解，因此一期简报在阅读感受上通常以前一段时间的新动态为主，但实际入稿标准始终是“本次执行时刻向前 24 小时内的确定性动态”，而不是自然日 00:00~24:00。

简报标题中的日期表示发布日，不表示“只统计该自然日 00:00~24:00 的新闻”。

2. 查询模式

适用于查询近期动态，不生成博客成品。

流程：

1. 优先使用 tavily skill 搜索。若 tavily 不可用，访问 references/source-map.md 中的官方源和权威媒体源。
2. 对重点新闻采集对象逐一执行定向检索。对于 OpenAI、Anthropic、Google/DeepMind/Gemini 等具备官方 changelog / release notes 的厂商，优先检查 changelog / release notes，再看博客与媒体报道。
3. 对候选做轻量核验：
   • 是否有明确时间证据
   • 是否落在窗口内
   • 是否是确定性动态
   • 是否只是旧闻重复
4. 按以下三类输出给用户：
   • 已确认动态：有明确时间证据且满足来源等级要求
   • 待核验线索：时间证据不足、仍需补检或只有单一媒体线索
   • 未发现符合窗口的确定性更新：当没有任何确认项时必须直接说明

约束：

• 查询模式不落盘
• 查询模式不生成正式简报结构
• 查询模式不进入 git / 发布链路
• 查询模式默认不得输出内部覆盖清单、内部审核摘要或内部检查明细
• 如果重点厂商覆盖未完成、关键源抓取失败或补检未完成，必须显式说明“查询不完整，不能作为成稿依据”

搜索关键词示例：

• {厂商名} news {日期}
• {厂商名} announcement {日期}
• {厂商名} changelog {日期}
• {厂商名} release notes {日期}
• 中文厂商增加 {厂商名} 发布 {日期}

3. 成稿模式

适用于生成完整简报草稿，但本轮不落盘。

流程：

1. 执行查询模式的候选发现与轻量核验。
   2. 对每条候选动态执行正式入稿审核：
   • 是否在时间窗口内。简报只包含“本次执行时刻向前 24 小时”内的新闻内容，不能按来源页显示的自然日直接判断。
   • 是否与最近 5 期已发布简报重复报道同一事件；若只是重复前情、没有新的可核验进展，不得作为当天新闻条目入稿。不足 5 期时，按已有全部已发布简报检查。
   • 若属于同一事件的后续，只有在本期窗口内出现新的、可核验的官方更新、版本变更、功能上线、价格调整、开放范围变化等实质进展时，才允许作为当天新条目继续报道。
   • 是否与 AI/模型/API/Agent/开发者平台相关。
   • 是否有明确来源 URL。
   • 是否有明确时间证据。
   • 来源类型是否正确标注为 [官方] 或 [媒体报道]。
   • 证据是否具备足够的 权威性 / 真实性 / 时效性：优先原始官方源，必要时再用权威媒体交叉确认；无法回溯原始源、时间不清或明显滞后的内容不得入稿。
2. 生成完整 Markdown 草稿，并只在对话中返回。
   • 正文结构使用：开篇短导语、## 速览、## 重点动态、## 为什么值得关注、## 来源。
   • 主体章节下用多个 ### 子标题拆分事件和判断，每个子标题下使用短段落叙述。
   • 不要在 ## 重点动态 中用长列表承载主要内容；## 为什么值得关注 可以用短段落或少量短子标题展开影响判断。
3. 生成内部审核摘要。
4. 调用项目级 subagent ai-briefing-reviewer 对草稿和内部审核摘要做阻断式复审。
5. 若复审通过，输出草稿内容与审核结果；若未通过，输出问题与修改要求。

输出格式必须分成两段：

• 第一段：可直接发布的 Markdown 草稿
• 第二段：明确标注为“内部审核摘要”的非发布内容，并在末尾追加“subagent 复审结论”小节

禁止把内部审核摘要放进 frontmatter、正文、## 来源 小节，或与草稿正文放在同一个 Markdown 代码块中。

阻断条件：

• 时间证据不足
• 重点厂商覆盖检查未完成
• 重大候选仍未确认
• 与最近 5 期重复报道但没有新进展
• 内容质量不足以形成合格简报
• 只有 [待核验] 线索，没有可入稿的确定性动态
• ai-briefing-reviewer 复审未通过

本轮最小实现原则：

• 成稿模式一律不落盘
• 不写入 content/ai-briefings/
• 不 commit
• 不 push

4. 发布模式

适用于明确要求自动发布简报的场景。

发布模式 = 成稿模式 + 最终审核 + 仓库门禁 + 自动发布。

4.1 生成正式简报

仅在发布模式中，且成稿内容通过最终审核后，才允许写入：

• content/ai-briefings/YYYY/MM/YYYY-MM-DD-ai-briefing.md

如果当天文件已存在，先停止并说明冲突；除非用户明确要求覆盖当天简报。

4.2 发布前最终审核

在 commit/push 前执行一轮阻断式审核，重点检查：

• 信息准确性：正文每个关键事实都有来源支撑，没有误读或夸大。
• 证据质量：每个最终入稿项都已单独检查 权威性 / 真实性 / 时效性，且三项均过关。
• 专业性：模型名、版本号、厂商名、API 名称、技术术语准确。
• 来源完整性：正文每个确定事件都能在“来源”小节找到对应来源。
• 来源可靠性：来源为官方或权威媒体；社交媒体、二手转述、无日期来源不得进入正文。
• 时间窗口：所有事件时间都已统一折算到 Asia/Shanghai，并且严格落在“本次执行时刻向前 24 小时”的统计窗口内，不存在旧事新报。
• 去重检查：当前简报不得与最近 5 期已发布简报重复报道同一新闻事件；若正文引用前情，必须明确服务于当天新进展，且旧事实不能单独作为当天新闻条目出现。不足 5 期时，按已有全部已发布简报检查。
• 重点厂商覆盖：OpenAI、Anthropic、Google/DeepMind/Gemini、xAI、Meta AI、Perplexity、Mistral、月之暗面/Kimi、小米 MiMo、DeepSeek、智谱 AI 已逐一完成搜索与补检，没有漏掉重大模型/API/平台发布。
• 字数：正文汉字数（不含 ## 来源 章节）为 900~1300。
• 可读性：开篇和主体正文没有大段落；章节正文单段目标为 80~120 个中文汉字；主体章节使用有信息量的 ### 子标题拆分，而不是依赖长列表。
• frontmatter：published: true，文件扩展名为 .md。
• subagent 复审：项目级 ai-briefing-reviewer 已基于草稿与内部审核摘要完成第二道审核，并明确给出“可进入发布门禁”结论。

任一检查失败：停止发布，不得 commit 或 push。修复问题再次执行审核。最多执行 3 轮审核，超过 3 轮仍未通过，停止发布并输出失败原因。

4.3 内部审核摘要

每次成稿/发布前必须形成内部审核摘要，至少包含：

• 本期时间窗口
• 重点厂商覆盖清单
• 候选条目数
• 剔除项与剔除原因
• 最终入稿项
• 每项确认源
• 每项最终入稿内容的 权威性 / 真实性 / 时效性 自审结论
• 是否存在高风险未确认项
• ai-briefing-reviewer 的复审结论

本轮内部审核摘要默认只允许存在于：

• 对话输出
• 临时过程数据

本轮明确禁止：

• 落盘为默认审核文件
• stage 到 git
• commit / push

4.4 发布前仓库安全检查

最终审核与 ai-briefing-reviewer 复审均通过后，执行本地发布门禁：

1. just validate-content
2. just build-site-ai-data
3. 确认 site/public/ai-data/briefings/index.json 已包含当天简报。

任一命令失败或索引未更新：停止发布，不得 commit 或 push。

随后执行 git 安全检查：

1. git status --short --branch
2. 确认当前分支是部署分支（默认 main，除非用户明确指定）
3. 确认分支有 upstream，且没有 behind/diverged
4. 确认没有无关 staged changes
5. 只 stage 当天简报与必要生成产物

禁止使用 --no-verify。禁止 force push。若必须 force push，只能在用户明确要求时使用 --force-with-lease。

4.5 自动发布

默认执行：

just validate-content
just build-site-ai-data
git add content/ai-briefings/YYYY/MM/YYYY-MM-DD-ai-briefing.md site/public/ai-data/briefings/index.json
git commit -m "add ai briefing for YYYY-MM-DD"
git push

git push 后不要立刻手动 purge Cloudflare 缓存，避免 GitHub Pages 还未部署完成时又把旧 HTML 回填进 CDN。默认由 .github/workflows/site-ci.yml 在 Pages 部署成功后执行定向 purge；只有用户明确要求手动补刷时，才执行 just purge-ai-briefing-cache YYYY-MM-DD。

输出给用户

查询模式完成后

• 查询摘要
• 已确认动态
• 待核验线索（如有）
• 必要来源链接

成稿模式完成后

• 草稿正文
• 内部审核摘要（含 ai-briefing-reviewer 复审结论）
• 未入稿原因（如有）

发布模式完成后

• 简报文件路径
• 审核结果摘要
• commit hash
• push 结果

如果审核或 git 安全检查失败，输出失败原因和需要人工处理的文件。