AI News Radar：把新闻去重、锐评和 Agent 读报装进一个 GitHub 仓库
该项目围绕「LearnPrompt/ai-news-radar」构建，面向真实业务场景提供可复用的开源实践方案，支持稳定落地与可扩展的项目实践。
秒懂
- 它是什么？
- AI News Radar 是一个用 GitHub Actions 驱动的 AI 新闻聚合管线，把信源判断、抓取、去重、LLM 点评和静态站点发布串成一条流水线。它适合想自己掌控信息源的人，但对 LLM 的依赖和架构复杂度需要先看清楚。
- 适合谁用？
- 想自己掌控 AI 新闻信息源、愿意 fork 仓库并维护 OPML 和 personas 的开发者适合采用 AI News Radar，普通读者直接用在线站即可，不必碰代码。不适合想要开箱即用、不想接触 GitHub Actions 和 JSON 数据文件的人。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的痛点：信源太多，重复太多，判断太累
AI 新闻分散在官方博客、X、聚合站和各类 RSS 里，同一个事件往往被多家转来转去。项目 README 描述的场景很具体：打开几十个页面，肉眼过滤重复内容，再猜哪条值得深挖。AI News Radar 的目标就是把这套人工流程自动化。它面向两类人：普通读者直接看网页版，按栏目 tab 和精选/全量开关浏览；开发者和 Agent 用户则 fork 仓库，把信源换成自己的 OPML，改 personas 文件，数据长在自己的 GitHub Pages 上。项目自称永远不是又一个新闻网页，核心逻辑是内置的伯乐 Skill，先判断哪些信源值得长期追踪，再接入抓取。
管线怎么跑：从信源分类到静态 JSON 的七步流程
README 里的 flowchart 给出了完整数据流。第一步是信源清单，伯乐 Skill 判断每个来源的类型，分成官方 RSS、私人 OPML、公开 GitHub feed、静态页面和 AgentMail 邮箱五类，高风险来源直接跳过。接着进入抓取与结构化，然后去重归一化，再做 AI 相关性评分与标签，之后是故事合并与多源证据聚合，最后生成源健康状态和 AI 占比。每次更新产出一组静态 JSON 文件，页面只读这些文件，不需要后端服务。GitHub Pages 是 canonical 源，Vercel 站只是同一份数据的另一个门面。这个设计有个明显优点：上线后核心流程不消耗模型额度，因为 LLM 只在需要点评或改写标题时才被调用。
v0.9 的界面收敛：单层信息架构与双视图
v0.9 把 v0.8 的三视图合并成一层，具体是栏目 tab（全部/模型/产品/开发者/行业/论文/社区/自媒体）加上精选/全量开关，再加一条时间轴。精选模式读故事合并后的高价值池，全量模式读 score >= 0.3 的广义 AI 原始池。双视图是指两套 UI 皮肤：根目录 index.html 默认手机版，右上角视角开关可切到 /classic/ 经典桌面版，也支持 ?view=mobile 或 ?view=classic 参数直接指定。两套皮肤读同一份 data/ 目录，选择记在浏览器本地。当前热点榜不设固定条数，只要满足多信源热度阈值就上榜。这个设计比三视图更直接，但 README 也提到旧版三视图截图存档在 /legacy/，保留至 2026 年 8 月中旬，说明界面演进还在进行中。
三口味 persona 与真实推荐理由
v0.8 引入的三口味 persona 是项目最有辨识度的功能。实用派只关心对开发者今天有什么用，毒舌评论员拆穿营销话术，较真党只认论文和 benchmark 实证。每个口味就是 personas/ 目录下一个 markdown 文件，包含 frontmatter 和 system prompt，想换口味就改一个文件，想造新口味按 personas/README.md 的格式写一个。每日精选 20 条按默认口味打分点评，TOP3 再由三个口味分别评。v0.9 把推荐理由真实化了：对通过 AI 相关性筛选的条目抓取全文，交给 DeepSeek 写一句为什么值得读，需要 DEEPSEEK_API_KEY；没有真实理由时前端直接隐藏这个区块，不用模板句撑场面。这个设计很诚实，但依赖外部 API，没配 Key 时页面会少一块信息。
部署与 fork：五步拥有自己的雷达
普通用户不用部署，直接打开在线站即可。想自己办报，README 给了五步：fork 仓库，开 Actions，这一步是关键，因为所有数据更新靠 GitHub Actions 定时触发。之后把信源换成自己的 OPML，改 personas 口味，数据就发在自己的 GitHub Pages 上。高级来源可以通过 GitHub Secrets 或本地环境变量接入，避免把 token、cookies 和私有 OPML 写进仓库。本地多分支开发可以用页面 ?data= 参数切换前端读取的 data/ 目录，不用改代码。还有一个零 API 的用法：npx skills add LearnPrompt/ai-news-radar -s ai-radar -g 安装 Agent Skill，装完对 Agent 说一句今天 AI 圈有什么就能拿简报，不需要 API Key 和服务器。
限制与失败模式：LLM 依赖、聚合源风险和维护成本
项目对 LLM 的依赖是双刃剑。不配 DEEPSEEK_API_KEY 也能跑全流程，自动降级成规则分，但标题增强和真实推荐理由会失效，页面会保留原标题，不显示推荐理由区块。另一个风险在聚合源：v0.9 取消了 zeli 整榜白名单放行，改成和其他聚合源一样过 AI 相关性打分，说明聚合源内容质量参差，需要额外过滤。双语标题翻译有校验，拒答文案会被识别并回退到原文标题，但这类校验只覆盖已知退化模式，新问题可能出现。维护成本不低，源健康状态依赖持续抓取，信源清单需要定期检查，README 也建议新信息源先单独运行一周再决定是否录入。对只想看新闻的人，fork 和配置 Actions 是多余的负担。
替代方案与差异：从手动 RSS 到全自动管线的光谱
最常见的替代方案是自己维护一个 RSS 阅读器加手动筛选，比如用 FreshRSS 或 Miniflux 订阅几十个源，靠人眼去重。差异在于 AI News Radar 把去重和相关性判断自动化了，还加了故事合并和多源证据聚合，这是普通阅读器做不到的。另一个替代是直接用 LLM 写一个抓取脚本，定时调 API 总结新闻，但那样每次运行都要消耗模型额度，而 AI News Radar 的核心流程不消耗额度，只有点评才调 LLM。更轻量的选择是直接用 GitHub 的 RSS 生成服务，比如 rsshub，但那只能解决抓取，不解决去重和判断。AI News Radar 的定位是完整管线，不是单一工具。
许可证与升级成本：MIT 下的自由与责任
项目使用 MIT 许可证，可以自由 fork、修改和商用，但 README 没有提供贡献指南或代码规范，升级成本主要来自架构变动。v0.9 把三视图合并成单层，旧界面存档到 /legacy/ 且保留至 2026 年 8 月中旬，这意味着如果你依赖旧视图，需要在那之前迁移。数据文件结构也在演进，v0.8 起 daily-brief.json 包含 persona 打分字段，v0.9 新增 latest-24h-all.json 和 merge-log.json，fork 后如果上游更新，你的数据文件可能不兼容。项目没有发布 Python 包，安装方式只有 fork 或 npx skills add，所以升级只能靠 git pull 或重新 fork，没有版本管理工具辅助。对长期维护者来说，这不是零成本的事情。
编辑结论
想自己掌控 AI 新闻信息源、愿意 fork 仓库并维护 OPML 和 personas 的开发者适合采用 AI News Radar，普通读者直接用在线站即可，不必碰代码。不适合想要开箱即用、不想接触 GitHub Actions 和 JSON 数据文件的人。采用前先验证三件事：fork 后 Actions 能否正常触发，DEEPSEEK_API_KEY 是否准备（不配也能跑，但标题增强和真实推荐理由会失效），以及你是否有精力维护信源清单，因为源健康状态依赖持续抓取，没有一劳永逸的配置。
社区笔记