最近我给自己搭了一套自动化流程：每天追踪 AI / CS 方向的新论文和 GitHub Trending 热门项目，然后自动筛选、整理、生成中文摘要，最后沉淀成日报。
这套系统的目标很简单：
不再靠手动刷 arXiv 、GitHub Trending 、Twitter/X 和各种群消息来追前沿，而是让 AI Agent 每天帮我完成第一轮信息筛选。
我用的是 OpenClaw ，主要让它承担三件事：
- 定时抓取 arXiv 最新论文和 GitHub 热门项目；
- 按主题、质量和工程价值做过滤；
- 自动生成中文摘要、深度解读和每日归档。
这篇文章简单分享一下系统是怎么搭的，以及目前踩到的一些坑。
1. 为什么要做这套东西？
如果你关注 AI 工程化，信息源会非常碎：
- arXiv 每天都有大量新论文；
- GitHub Trending 每天都有新项目冒出来；
- Hugging Face 、OpenAI 、Anthropic 、Google 、Meta 、微软等团队会不定期发布模型、框架或技术报告；
- 很多有价值的项目不是一开始就爆火，而是在小范围技术圈里先出现。
手动追踪的问题是：
- 很容易漏掉重要论文；
- GitHub Trending 噪声很大，很多项目只是短期热闹；
- 标题和 README 经常看起来很强，但实际工程价值一般；
- 每天都刷一遍非常耗时间。
所以我想做一个自动化系统，先让 Agent 帮我做“第一轮粗筛”，把候选论文和项目整理出来，再对其中高价值内容做中文精读。
2. 整体架构
目前流程大概是这样：
定时任务 / Cron
↓
数据源抓取
├── arXiv API
├── GitHub Trending / GitHub API
└── 其他公开信息源
↓
候选池入库
↓
规则过滤 + 去重
↓
Agent 精读 / 摘要生成
↓
Markdown / JSON / SQLite 归档
↓
公众号草稿 / GitHub 日报 / 后续分发
核心不是“抓取”，抓取其实不难。真正麻烦的是：
- 怎么过滤垃圾信息；
- 怎么避免每天重复写同一个方向；
- 怎么判断一个项目是不是真的值得看；
- 怎么让生成内容尽量可验证，而不是 AI 胡编。
3. 论文部分：从 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 ，例如：
每篇论文进入候选池后，会先做基础解析：
- 标题
- 作者
- 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 写论文解读很容易“看标题发挥”。所以每篇文章都需要保留来源、证据和不确定点。
4. 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
我希望最后生成的不是“这个项目很厉害，大家快去看”的营销文，而是能回答几个问题：
- 它解决了什么问题？
- 它和已有方案相比有什么不同？
- 它的架构或实现有什么可复用点？
- 它现在成熟吗？适不适合生产使用？
- 如果我要试用，第一步应该看哪里？
5. 为什么用 OpenClaw ？
我需要的不是单次 ChatGPT 问答，而是一个能长期运行的个人自动化 Agent 。
OpenClaw 对我比较有用的点：
- 可以读写本地工作区文件；
- 可以跑脚本、定时任务；
- 可以维护长期记忆和每日日志；
- 可以把流程拆给多个子 Agent ；
- 可以把产物写成 Markdown / JSON / SQLite ；
- 可以接入公众号草稿、Discord 、QQ 等通知渠道。
换句话说，它更像一个“能干活的个人自动化工作台”，而不是只会聊天的模型。
当然，最重要的是：所有自动生成内容都要有检查门禁。比如：
- 没有来源链接不能进正式稿；
- 没读 primary source 不能写深度解读；
- 不能出现“待补充”“TODO”“正式发布前请检查”这类占位词；
- 标题不能为了吸引点击而歪曲论文或项目本意；
- GitHub 项目不能把 README 里的宣传语直接当事实。
6. 目前的每日输出
现在我的目标是每天产出两类内容：
- 论文精读：偏研究方法、技术路线、评测和启发；
- GitHub 项目精读：偏架构、代码、工程价值和可落地性。
每日内容会先进入本地归档，再进入公众号草稿箱，最后人工检查后发布。
我也准备把其中一部分公开成 GitHub 仓库，作为每日 AI 论文和 GitHub Trending 的中文索引：
- 每日论文列表；
- 每日热门项目列表；
- 中文简介；
- 原始链接；
- 主题标签；
- 后续可能补充脚本。
完整版的深度解读会继续放在公众号里。
7. 踩过的一些坑
7.1 不要只追热点
GitHub Trending 很容易让人被短期 Star 牵着走。后来我加了“工程价值”和“主题相关性”的过滤，否则日报会变成项目搬运。
7.2 AI 很容易把摘要写成鸡汤
如果 prompt 不约束，论文解读很容易变成：
本文提出了一种创新方法，显著提升了性能，具有重要意义。
这种话基本没信息量。
所以我现在要求每篇都必须回答：
- 方法具体是什么；
- 输入输出是什么；
- 对比基线是什么；
- 适用边界是什么；
- 工程上能学到什么。
7.3 需要保留证据文件
自动化写作最怕“看起来很完整，但来源不可查”。
所以每个 slot 都会保留来源文件，例如：
- arXiv 链接；
- PDF 链接；
- GitHub repo 链接；
- README 摘要；
- 关键文件路径；
- 生成时的判断理由。
这样后面出了问题可以回溯。
7.4 公众号不是终点，归档和分发更重要
如果内容只存在公众号里，后续搜索和复用都不方便。
所以我会同时保留：
- Markdown 版本；
- JSON 元数据；
- SQLite 主账本；
- GitHub 公开索引；
- 后续可能加网页展示。
8. 后续计划
接下来我想继续做几件事：
- 开源每日论文和 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