别再让 AI 把旧闻当新闻：一套可核验、会去重的 AI 资讯筛选 Prompt

你让 AI 汇总“近 7 天 AI 更新”，几分钟后，它交出一份看起来相当专业的日报：标题完整、摘要流畅，还附了十几个链接。

问题是，逐条点开后才发现：十条信息里有三条发生在几个月前，四条其实是同一次更新的重复转述，还有一条所谓“重大新功能”，根本找不到官方出处。

AI 最危险的不是漏掉一条新闻，而是把三个月前的消息包装成“今天刚刚发布”。

这不是某个模型“不会搜索”，而是普通 Prompt 只提出了“帮我找新闻”，却没有告诉 AI：什么才算新、什么来源可信、遇到冲突如何核验、同一事件怎样合并。

真正可靠的 AI 资讯筛选流程，需要四道规则：

1. 时间窗口

2. 原始来源

3. 交叉验证

4. 事件级去重

少任何一道，最后得到的都可能只是一份“看起来很新”的链接合集。

说明：本文案例与配图均使用脱敏演示数据，用于展示检索和核验方法，不对应真实厂商事件。

AI 找到的“最新消息”，为什么经常不是新的

AI 搜索最容易混淆三个日期：

• 事件发生日期：模型、工具或功能真正发布的时间
• 网页发布日期：媒体、自媒体发布文章的时间
• 搜索发现日期：AI 或搜索引擎抓到这条信息的时间

这三个日期可能完全不同。

例如，一篇媒体文章发布于 2025-03-08，标题写着“某模型重磅上线”，但顺着链接找到官方公告后，发现该模型早在 2024-12-10 就已发布。

文章是新的，事件却是旧的。

如果 Prompt 只要求“搜索最近发布的网页”，AI 很容易把它收进近 7 天日报。“最近搜到”不等于“最近发生”。

先把时间窗口算清楚

假设当前日期为 2025-03-08，近 7 个自然日应明确写成：

当前日期：2025-03-08
有效窗口：2025-03-02 00:00 至 2025-03-08 23:59
时区：Asia/Shanghai

不要只写“最近一周”“近日”或“最近 7 天”。如果不指定时区、起止日期和是否包含当天，不同模型可能给出不同理解。

一条信息只有同时满足以下条件，才应进入正式列表：

• 事件发生或官方首次公开时间位于有效窗口内
• 能定位到可访问的原始来源
• 日期、版本号和核心功能可以核验
• 没有与历史记录或当前列表中的事件重复

不满足条件的内容不能悄悄混进去，而应被降级为旧闻重提、二手消息或无法核验线索。

核心不是“搜索”，而是建立证据链

普通搜索 Prompt 的工作方式像在商场里“听别人说哪家店打折”；核验版 Prompt 则要求 AI 找到商家的正式活动页，确认开始时间、适用商品和活动规则。

后者建立的是一条可以回溯的证据链：

搜索线索
→ 找到媒体或社交平台内容
→ 回溯官方公告
→ 核对日期与版本
→ 检查其他可靠来源
→ 标注核验状态
→ 与历史事件去重

来源可信度优先级

搜索摘要尤其容易误导。它可能截断上下文、拼接旧内容，甚至显示已经修改或失效的页面信息。

因此，搜索结果页只能告诉你“可能发生了什么”，原始页面才能证明“究竟发生了什么”。

日期必须分栏记录

最少应同时记录：

• 事件发生日期
• 官方首次公开日期
• 网页发布日期
• 搜索发现日期

如果媒体今天报道一个三个月前发布的模型，正确处理方式是：

媒体发布日期：2025-03-08
官方首次公开日期：2024-12-10
核验状态：旧闻重提
是否属于近7天：否

而不是模糊地写一句“该模型近日发布”。

核验状态定义

一套可信的筛选系统，价值不在于让 AI 显得无所不知，而在于让它能够主动说：

“我找到了相关说法，但目前不能确认。”

加入事件级去重：五篇文章可能只是一条新闻

标题去重通常没有用。

同一次模型更新，可能被包装成：

• “某公司发布新一代模型”
• “新模型加入长上下文能力”
• “开发者 API 迎来重大升级”
• “我们体验了某公司最新模型”
• “这次更新将如何影响行业”

标题不同，核心事件却相同。

正确做法是为每条信息提取“事件指纹”：

主体＋产品/模型＋动作＋版本＋发生日期

例如：

示例公司＋示例模型＋发布＋V2＋2025-03-06

只要多个页面指向同一个事件指纹，就应合并为一个条目：

• 官方公告作为主来源
• GitHub Release 或技术文档作为技术证据
• 媒体报道作为补充解读
• 自媒体转载不再单独占一个位置

这一规则也应该延伸到内容生产。

一份可以直接复制的完整 Prompt

下面这份 Prompt 可以用于 ChatGPT、Claude、Gemini 等支持检索的模型，也可以接入 API 工作流。

你的任务是筛选过去7个自然日内首次公开发布的AI模型、AI工具和重要版本更新，并建立可回溯的证据链。

【变量】
当前日期：{{CURRENT_DATE}}
时区：Asia/Shanghai
时间窗口：{{START_DATE}} 00:00 至 {{END_DATE}} 23:59
关注范围：{{TOPICS}}
历史记录：{{HISTORY_ITEMS}}

【来源优先级】
1. 官方公告、官方博客、产品更新日志
2. GitHub Release、模型卡、技术文档、开发者文档
3. 当事人、项目负责人或官方团队公开账号
4. 权威媒体及可靠数据库
5. 自媒体、聚合站和搜索摘要

【执行规则】
1. “最新”以事件实际发生日期或官方首次公开日期为准，
不以网页发布日期、搜索发现日期为准。
2. 先计算并写出准确的时间窗口，再开始筛选。
3. 优先寻找官方博客、更新日志、GitHub Release、
模型卡或开发者文档。
4. 媒体、自媒体和社交平台只能作为线索，
必须继续追溯原始来源。
5. 如果新文章报道的是时间窗口之外的旧事件，
标记为“旧闻重提”，不得放入正式更新列表。
6. 找不到原始来源时，标记为“二手消息”或“无法核验”，
不得写成已确认事实。
7. 按事件去重，不按文章标题去重。
使用“主体＋产品/模型＋动作＋版本＋发生日期”
判断是否属于同一事件。
8. 同一发布被多个来源报道时，只保留一个事件条目。
官方公告作为主来源，其他链接作为补充证据。
9. 如果事件已经存在于历史记录中，合并更新，
不要生成新的重复条目。
10. 不得把搜索摘要当作证据。
11. 不得根据媒体标题自行补全功能、版本号或发布日期。
12. 不得使用“近日、日前、最新”等模糊表达代替具体日期。
13. 不得编造发布日期、版本号、功能、测试成绩或官方结论。
14. 如果多个来源存在冲突，请写明冲突点，不要自行选择
一个更像真的说法。

【核验状态】
已核验：有可访问的原始来源，日期与关键信息一致
二手消息：只有媒体或账号转述，尚未找到原始出处
无法核验：链接失效、来源不可访问或关键信息无法确认
旧闻重提：报道日期较新，但事件日期超出时间窗口
重复事件：与列表或历史记录中的事件指向同一次更新

【输出字段】
事件名称
主体/厂商
类型：新模型/新工具/版本更新
事件发生日期
官方首次公开日期
搜索发现日期
来源类型
官方来源链接
补充来源链接
核验状态
是否属于近7天
事件指纹
去重说明
100字内摘要

先输出“已核验且属于近7天”的正式列表。

最后单独列出：
A. 旧闻重提
B. 二手消息
C. 无法核验
D. 已合并的重复事件

如果正式列表为空，请明确输出“本时间窗口内未发现可核验事件”，
不要用旧闻或二手消息填充数量。

最后一条非常重要：宁可输出空列表，也不要为了显得丰富而拿旧闻凑数。

用三个边界案例测试它

以下均为脱敏演示数据，域名和事件名称不代表真实项目。

案例一：旧模型被新文章重新报道

检索过程：

2025-03-08：发现 newsroom.example 的新文章
→ 文章称“示例模型X重磅发布”
→ 继续搜索官方博客
→ official.example 显示首次公告日期为 2024-12-10
→ 超出 2025-03-02 至 2025-03-08 的有效窗口

普通 Prompt 的结论：

示例模型 X 于近期发布。

核验版 Prompt 的结论：

旧闻重提：媒体文章发布于 2025-03-08，但官方事件日期为 2024-12-10，不进入近 7 天正式列表。

案例二：多个账号转发，但没有官方公告

检索过程：

发现多个中文账号转发“示例模型性能提升3倍”
→ 搜索产品官网，未找到相关公告
→ 检查开发者文档和模型卡，未发现对应说明
→ 检查GitHub仓库，未发现匹配的Release
→ 转发内容均指向另一篇二手文章

普通 Prompt 可能直接复述“性能提升 3 倍”。

核验版 Prompt 则会标记：

核验状态：二手消息
官方来源：未找到
关键信息：无法确认
处理结果：不进入正式列表

特别是“提升 3 倍”这类定量结论，如果没有测试条件、指标定义和原始报告，更不能直接采用。

案例三：多个页面报道同一版本

检索过程：

发现官方博客发布版本更新
→ GitHub Release记录相同版本号与日期
→ 三家媒体随后报道
→ 中文账号继续转载媒体内容
→ 事件指纹一致

普通 Prompt 可能输出五条“新闻”。

核验版 Prompt 只保留一条：

主来源：官方博客
技术证据：GitHub Release
补充来源：媒体报道
核验状态：已核验
去重说明：5个页面均指向同一次版本发布，已合并

两种 Prompt 的差别，不是一个找到了五条、另一个只找到一条，而是后者知道：五个链接不等于五个事件。

从一次查询升级为每日情报工作流

手动使用时，可以直接把 Prompt 复制到支持网页检索的模型中。但要让它每天自动运行，还需要三部分协同：

定时触发
→ 网页搜索、RSS、GitHub等数据源
→ 模型执行核验与去重
→ 输出Markdown或JSON
→ 写入飞书、Notion、邮件或数据库

Prompt 本身不能凭空获得实时信息。模型必须实际接入网页搜索、RSS、GitHub API 或其他可访问数据源，否则再严谨的规则也只是“无米之炊”。

自动化代码可以从一个极简框架开始：

from datetime import date, timedelta

current_date = date.today()
start_date = current_date - timedelta(days=6)

history_items = load_history_items()

result = call_model(
prompt=render_prompt(
current_date=current_date,
start_date=start_date,
end_date=current_date,
history_items=history_items
)
)

save_to_database(result)
send_daily_digest(result["verified_items"])

这里最容易被忽略的变量是 history_items。

没有历史记录，系统只能对“今天抓到的链接”去重；有了历史记录，它才能判断某条新闻昨天是否已经收录、某个模型是否只是再次被媒体提起。

建议历史库至少保存：

• 事件指纹
• 主体与产品名称
• 版本号
• 官方首次公开日期
• 官方来源 URL
• 首次收录时间
• 最近更新时间
• 对应历史文章链接

如果只是偶尔查一次，可以手动运行 Prompt；如果希望每天定时执行，并把结果发送到飞书、Notion 或自己的数据库，就需要通过 API 接入工作流。

可以前往 api.884819.xyz 查看当前可用模型与接口文档，再根据检索能力、上下文长度和成本选择合适模型。平台使用用户名和密码即可注册，不需要邮箱验证；内置 AI 对话功能，注册后可以直接使用。国产模型如 Deepseek、千问等完全免费，没有月租或订阅，其他模型按量付费。

• 复制 Prompt，接入每日 AI 情报工作流
• 查看可用模型与 API 接入方式：api.884819.xyz
• 先手动测试，再把核验流程自动化

最后：真正有价值的不是“更多”，而是“可信”

一套稳定的 AI 情报系统，至少由三部分组成：

• Prompt 负责判断规则
• 检索源负责提供事实
• 历史数据库负责跨天去重

三者缺一不可。

从今天开始，你可以先做一个最小测试：选取过去一周保存的十条 AI 新闻，要求模型分别给出事件日期、官方来源和核验状态。凡是无法找到原始出处的内容，先移出正式日报，不要急着下结论。

这套 Prompt 解决了“哪些消息值得进入日报”，但还没有彻底解决另一个更棘手的问题：同一个模型更新被几十家媒体换标题转发时，AI 如何稳定判断它们都来自同一条官方公告？

下一篇，我们会拆解一套更细的“事件指纹”去重方法，用主体、版本、动作、日期和来源关系，把几十条链接压缩成真正值得看的三五个事件。

#AI教程 #Prompt技巧 #AI资讯 #人工智能 #信息核验 #自动化工作流 #8848AI