GitHub、RSS、网页和本地入口各有各的问题。来源写清楚了，后面的采集、去重和摘要才不会乱。
日报工具最容易被写成一个会跑的爬虫集合。
今天加一个 GitHub 查询，明天塞几个 RSS，后天又补一个网页列表。刚开始很快，等来源多起来以后，就会变成另一种麻烦：到底哪些页面允许抓、哪些只是临时测试、哪个来源质量差、哪个来源不该提交到公开仓库，全都散在代码和命令里。
我看 daily-open-source-brief 的公开发布目录时，最先注意到的是 config/sources.yml 这类文件其实承担了来源说明的角色。
它应该先回答“我允许系统从哪里拿信息”，再让采集器去工作。
来源配置不是参数表
很多工具会把来源配置当成参数表：URL、limit、enabled，能跑就行。
但日报系统里的来源配置应该把来源范围写清楚。它至少要说明几件事：
- 这是 GitHub 查询、RSS，还是公开网页列表。
- 这个来源叫什么，后续日志和摘要里能不能识别。
- 它默认是否启用。
- 它抓取的页面是否公开、是否允许被自动访问。
- 如果是网页列表，链接范围有没有 allow pattern。
这些字段看起来普通，但能让采集行为说得清。哪天日报里出现一条奇怪内容，我能回到配置文件里看见它从哪个来源进来，而不是去翻一堆临时脚本。
GitHub 查询要写成规则
GitHub 是日报工具里最适合结构化配置的来源。
一个查询别只写“找 AI 项目”这种愿望，要把约束写出来：主题、星标、最近更新时间、是否排除归档项目、是否排除 fork、每次取多少条。
这样日报执行的是一条能回看的搜索规则，不是在漫游 GitHub。
我更喜欢这种方式：查询名称写得短，规则写得硬，滚动时间窗口由程序替换。它不会保证每天都有惊喜，但能保证每天的结果来自同一把尺子。
RSS 适合稳定入口
RSS 和 Atom 的好处是入口清楚。
一个公开 feed 本来就是给订阅准备的，字段也相对稳定。日报工具只需要记录名称、标题、URL、来源类型和启用状态，就能把它纳入同一条流水线。
这里别贪多。RSS 源一多，摘要会很快被同质内容淹没。先少量启用，观察几天，再决定是否扩展，比一次性塞几十个 feed 更稳。
日报不是收集癖，它需要每天能读完。
网页采集必须更窄
公开网页列表比 RSS 更危险一点。
它没有统一格式，页面结构可能改，列表页和详情页的范围也容易含糊。这个时候配置里就应该出现更保守的限制：只抓公开页面，只解析简单列表，只允许匹配特定路径的链接。
allow pattern 是这类来源的安全带。
没有它，网页采集器很容易从“读取公告列表”滑到“跟着页面里的链接到处跑”。对个人日报来说，这没有必要，也不值得。
私有入口别进提交配置
来源配置还有一个明确职责：告诉人什么不该写进去。
私有门户、需要登录的仪表盘、个人邮箱、内部系统、带 token 的 URL，都不该出现在公开提交的配置里。即使脚本能抓，也不代表适合放进这个项目的默认来源。
公开仓库里的配置应该只放通用示例和公开来源。个人化的东西可以留在本地环境或私有覆盖配置里，但不能和开源配置混在一起。
这比“后面再脱敏”可靠。最好的脱敏，是一开始就不让私有入口进入公共文件。
先小规模启用
日报工具的质量不是来源越多越好。
如果一开始就打开 GitHub、RSS、网页、邮件、Lark 和模型摘要，出了问题很难判断是采集质量差、摘要失败，还是投递配置错。
更稳的流程是分层打开：
- 先跑离线 sample，确认渲染和归档没问题。
- 再启用少量公开来源，观察去重和排序。
- 然后打开摘要模型，确认输出风格稳定。
- 最后再打开邮件或 Lark 投递。
这让每一步都有可回退的位置。日报工具是每天运行的小系统，不是一次性 demo。
配置也要能被测试
来源配置写完以后，不能只靠人工看。
至少要有几类检查：
- 配置能被解析。
- 禁用来源不会被采集。
- 网页来源必须有范围限制。
- 私有文件和生成归档不会被提交。
- 采集失败会被记录，而不是让整份日报消失。
这些检查不复杂，但它们能防止配置变成随手乱填的说明文档。尤其是公开项目，配置文件一旦变成别人复制的模板，就更不能把危险默认设置塞进去。
回头看配置这件事
daily-open-source-brief 这种工具做到后面，麻烦通常不在多抓几个页面，而在来源越来越多以后还能看清每一条内容从哪里来。
来源配置先写清楚，采集器才不会变成随手加出来的爬虫集合。
我现在更愿意把日报系统拆成两句话：配置先圈定来源，代码只按这些来源去采集。顺序摆正以后，后面的去重、摘要、归档和投递才比较好查问题。
继续读