最近我给自己搭了一套自动化流程：每天追踪 AI / CS 方向的新论文和 GitHub Trending 热门项目，然后自动筛选、整理、生成中文摘要，最后沉淀成日报。 这套系统的目标很简单：
不再靠手动刷 arXiv 、GitHub Trending 、Twitter/X 和各种群消息来追前沿，而是让 AI Agent 每天帮我完成第一轮信息筛选。
我用的是 OpenClaw ，主要让它承担三件事：
定时抓取 arXiv 最新论文和 GitHub 热门项目； 按主题、质量和工程价值做过滤； 自动生成中文摘要、深度解读和每日归档。
这篇文章简单分享一下系统是怎么搭的，以及目前踩到的一些坑。
- 为什么要做这套东西？ 如果你关注 AI 工程化，信息源会非常碎：
arXiv 每天都有大量新论文； GitHub Trending 每天都有新项目冒出来； Hugging Face 、OpenAI 、Anthropic 、Google 、Meta 、微软等团队会不定期发布模型、框架或技术报告； 很多有价值的项目不是一开始就爆火，而是在小范围技术圈里先出现。
手动追踪的问题是：
很容易漏掉重要论文； GitHub Trending 噪声很大，很多项目只是短期热闹； 标题和 README 经常看起来很强，但实际工程价值一般； 每天都刷一遍非常耗时间。
所以我想做一个自动化系统，先让 Agent 帮我做“第一轮粗筛”，把候选论文和项目整理出来，再对其中高价值内容做中文精读。
- 整体架构 目前流程大概是这样： 定时任务 / Cron ↓ 数据源抓取 ├── arXiv API ├── GitHub Trending / GitHub API └── 其他公开信息源 ↓ 候选池入库 ↓ 规则过滤 + 去重 ↓ Agent 精读 / 摘要生成 ↓ Markdown / JSON / SQLite 归档 ↓ 公众号草稿 / GitHub 日报 / 后续分发
核心不是“抓取”，抓取其实不难。真正麻烦的是：
怎么过滤垃圾信息； 怎么避免每天重复写同一个方向； 怎么判断一个项目是不是真的值得看； 怎么让生成内容尽量可验证，而不是 AI 胡编。
- 论文部分：从 arXiv 候选到中文精读 论文侧主要关注这些方向：
RAG / Retrieval-Augmented Generation Search / Information Retrieval Agent / Tool Use / Function Calling Long Context Evaluation / Benchmark LLM Application Engineering Knowledge Base / Re-ranking / Query Understanding
数据源主要是 arXiv API ，例如：
cs.AI cs.CL cs.IR cs.LG cs.CV 中和多模态检索、文档理解相关的部分
每篇论文进入候选池后，会先做基础解析：
标题 作者 arXiv ID 摘要 分类 发布时间 PDF 链接 关键词
然后做几层过滤：
主题相关性：是否和 AI 工程化、RAG 、搜索、Agent 等方向有关； 新鲜度：优先最近 1 个月，越新越优先； 机构/作者可信度：顶级实验室、大厂、知名高校会加权，但不绝对迷信； 工程价值：有没有方法、框架、评测或实践启发； 重复度：是否和之前已经写过的主题过于接近。
通过过滤后，Agent 会读取论文摘要、PDF 或 HTML 版本，生成结构化产物： paper_slot/ deep_read_article.md deep_read_meta.json sources.md evidence-notes.md seo-title.json
我比较看重 sources.md 和 evidence-notes.md，因为 AI 写论文解读很容易“看标题发挥”。所以每篇文章都需要保留来源、证据和不确定点。
- GitHub 部分：不只看 Star ，更看工程价值 GitHub Trending 的噪声非常大。 有些项目一天几千 Star ，但可能只是：
一个简单 UI 壳子； 复刻已有项目； README 写得很夸张； Demo 很漂亮，但代码不可复用； Star 暴涨，但最近维护质量一般。
所以我没有只按 Star 排序，而是做了几个维度：
Star 总数； 最近增长速度； 最近 commit 活跃度； README 是否清晰； 是否有真实代码结构； 是否有 license ； 是否有 release / examples / docs ； 是否和 RAG 、Agent 、搜索、LLM 应用工程相关； 是否解决真实工程痛点。
一个项目进入精读流程前，至少要检查： repo_slot/ repo-evidence.json readme.md key-files.md sources.md deep_read_article.md seo-title.json
我希望最后生成的不是“这个项目很厉害，大家快去看”的营销文，而是能回答几个问题：
它解决了什么问题？ 它和已有方案相比有什么不同？ 它的架构或实现有什么可复用点？ 它现在成熟吗？适不适合生产使用？ 如果我要试用，第一步应该看哪里？
- 为什么用 OpenClaw ？ 我需要的不是单次 ChatGPT 问答，而是一个能长期运行的个人自动化 Agent 。 OpenClaw 对我比较有用的点：
可以读写本地工作区文件； 可以跑脚本、定时任务； 可以维护长期记忆和每日日志； 可以把流程拆给多个子 Agent ； 可以把产物写成 Markdown / JSON / SQLite ； 可以接入公众号草稿、Discord 、QQ 等通知渠道。
换句话说，它更像一个“能干活的个人自动化工作台”，而不是只会聊天的模型。 当然，最重要的是：所有自动生成内容都要有检查门禁。比如：
没有来源链接不能进正式稿； 没读 primary source 不能写深度解读； 不能出现“待补充”“TODO”“正式发布前请检查”这类占位词； 标题不能为了吸引点击而歪曲论文或项目本意； GitHub 项目不能把 README 里的宣传语直接当事实。
- 目前的每日输出 现在我的目标是每天产出两类内容：
论文精读：偏研究方法、技术路线、评测和启发； GitHub 项目精读：偏架构、代码、工程价值和可落地性。
每日内容会先进入本地归档，再进入公众号草稿箱，最后人工检查后发布。 我也准备把其中一部分公开成 GitHub 仓库，作为每日 AI 论文和 GitHub Trending 的中文索引：
每日论文列表； 每日热门项目列表； 中文简介； 原始链接； 主题标签； 后续可能补充脚本。
完整版的深度解读会继续放在公众号里。
- 踩过的一些坑 7.1 不要只追热点 GitHub Trending 很容易让人被短期 Star 牵着走。后来我加了“工程价值”和“主题相关性”的过滤，否则日报会变成项目搬运。 7.2 AI 很容易把摘要写成鸡汤 如果 prompt 不约束，论文解读很容易变成：
本文提出了一种创新方法，显著提升了性能，具有重要意义。
这种话基本没信息量。 所以我现在要求每篇都必须回答：
方法具体是什么； 输入输出是什么； 对比基线是什么； 适用边界是什么； 工程上能学到什么。
7.3 需要保留证据文件 自动化写作最怕“看起来很完整，但来源不可查”。 所以每个 slot 都会保留来源文件，例如：
arXiv 链接； PDF 链接； GitHub repo 链接； README 摘要； 关键文件路径； 生成时的判断理由。
这样后面出了问题可以回溯。 7.4 公众号不是终点，归档和分发更重要 如果内容只存在公众号里，后续搜索和复用都不方便。 所以我会同时保留：
Markdown 版本； JSON 元数据； SQLite 主账本； GitHub 公开索引； 后续可能加网页展示。
- 后续计划 接下来我想继续做几件事：
开源每日论文和 GitHub Trending 中文索引仓库； 加入更细的主题分类，比如 RAG 、Agent 、Search 、Evaluation ； 对高价值论文做系列化追踪； 对 GitHub 项目增加“可运行性”和“维护质量”评分； 把日报沉淀成一个可搜索的 AI 工程知识库。
如果你也在做类似的论文追踪、GitHub Trending 筛选、AI 技术日报，欢迎交流。 我会把完整的中文精读和每日筛选结果放在公众号「 AltenAI 观察」。 最后放一句软广：如果你关心 RAG 、搜索、Agent 、API 接入和大模型工程化落地，可以关注一下「 AltenAI 观察」。我会持续把每天筛出来的论文和项目做成中文摘要和工程解读。 也把文章放在了 github： https://github.com/AltenLi/daily-paper-github-trends