AI 信息源怎么接进自动化创作：从抓取、筛选到选题输出

很多人做 AI 内容自动化，第一步就写错了。

他们一开始就想“自动生成文章”，却没有先把前面的信息流搭稳。
结果是：

• 每天抓回来一堆重复链接
• 热点很多，但没有线索排序
• 文章来源混杂，真假难分
• 最后生成的内容像拼接，而不是选题

所以更稳的顺序应该反过来：

先把信息源自动化，再谈文章自动化。

这篇文章就围绕这一点展开。参考的是一个公开脚本，它做的事情很典型：

• 抓 20+ RSS 源
• 抓 Hacker News
• 抓 GitHub Trending
• 调 HuggingFace Papers
• 用关键词过滤
• 对 GitHub README 做二次验证

参考脚本：

• bozhouDev/bozhou-skills: fetch_ai_news.py

先说核心判断：自动化创作的瓶颈通常不在写，而在筛

如果你已经在写 AI 相关公众号，很快会发现：

• 生成初稿不难
• 从海量来源里筛到“值得写”的内容更难

也就是说，自动化链路里真正该优先标准化的，通常不是正文模板，而是前面的信息流。

这条链路至少应该分成 5 层：

1. 抓取
2. 过滤
3. 去重
4. 验证
5. 选题输出

只把第一层做好，最后得到的还是噪音。

第一层：抓取，不要只靠单一接口

参考脚本里做的第一件事很对：
它没有把所有信息都寄托在一个源上，而是按来源类型拆开抓。

比如：

• RSS 负责稳定订阅
• Hacker News 负责社区讨论
• GitHub Trending 负责项目发现
• HuggingFace Papers 负责研究层输入

这意味着自动化创作的“输入层”就已经是多路的。

这个设计有一个直接好处：

• 新闻发布不会和项目动向混在一起
• 研究进展不会被社区热度淹没
• 你后面做排序时，才有机会按来源类型加权

第二层：过滤，不要什么都保留

脚本里有一层很关键的设计：
它先用一组 AI 关键词做过滤。

关键词包括：

• AI、LLM、GPT、Claude、Agent、RAG
• DeepSeek、Gemini、Llama、MCP
• Embedding、Vector DB、LoRA、vLLM、GGUF

这一步说明一个很重要的原则：

自动化信息流的核心不是抓得多，而是先把明显不相关的内容挡在外面。

但过滤也不能只停在关键词。

因为只靠关键词会有两个问题：

• 漏掉一些没有直写关键词但其实很相关的内容
• 收进一些碰巧带词但实际价值很低的内容

所以关键词过滤更适合作为第一层粗筛。

第三层：去重，不然你会误把热度当价值

脚本里处理 Hacker News 时，专门按 HN 讨论链接去重。
这个动作看起来小，实际很关键。

因为如果你不去重，会出现一种假象：

• 同一件事在多个地方出现
• 你误以为它值得写很多次
• 结果选题越来越像热搜搬运

更稳的做法是把去重拆成两层：

1. 链接级去重

同一链接只保留一次。

2. 主题级去重

同一事件、同一模型发布、同一项目更新，只保留一个主入口，再保留几个辅助讨论。

只有这样，后面的选题才不会被重复信号放大。

第四层：验证，不要把“像 AI”当成“真有价值”

这份脚本里最值得学的一点，不是抓了多少源，而是它对 GitHub Trending 做了二次验证：

1. 先看项目名和简介是否命中 AI 关键词
2. 再抓 README
3. 再用 README 文本判断是不是真的相关

这个思路很重要。

因为自动化创作里，很多误判都来自：

• 名字看起来对
• 简介看起来像
• 实际一读内容根本不是重点项目

README 二次验证本质上是在做一件事：

不要只看标题层的像不像，要验证正文层的相关性。

这不只适用于 GitHub。
对文章、博客、Newsletter 也一样适用。

第五层：选题输出，不要直接输出原始条目

很多自动化脚本跑到这里就停了：
抓完、筛完、输出 JSON。

但如果你的目标是公众号创作，这还不够。

因为公众号需要的不是一组原始条目，而是一组可写问题。

更适合写作的输出应该长这样：

• 这条信息属于哪个类别
• 对谁重要
• 为什么今天值得写
• 适合写成快讯、评论、教程还是选型文

也就是说，原始信息要再转一层，变成选题卡片。

一个更适合公众号的自动化输出结构

如果你要把信息源接到选题流，建议输出字段至少包括：

• source
• category
• title
• url
• time
• summary
• why_it_matters
• best_for
• story_angle

其中最关键的不是标题，而是后三个字段：

why_it_matters

这条信息为什么重要。

best_for

适合哪类读者或哪类公众号。

story_angle

这条信息更适合被写成：

• 快讯
• 观点评论
• 工具推荐
• 教程
• 选型分析

这一步做完，自动化链路就不只是“抓新闻”，而开始服务创作。

如果你要接成真正的自动化创作，建议再补三层规则

1. 来源权重

比如：

• 官方博客权重高于二手媒体
• README 二次验证通过的项目高于只看标题命中的项目
• 持续讨论的话题高于一次性热闹

2. 时间窗口

脚本里已经有 --hours 参数。
这类时间窗口非常重要。

因为公众号写作不一定需要“越新越好”，而更需要：

• 在合理时间里保留持续有价值的信息
• 不被旧内容反复刷出来

3. 输出限额

脚本里也有 --limit。
这不是性能优化，而是编辑纪律。

如果每天给自己 100 条来源，最后通常一条也写不好。
更合理的是：

• 原始抓取可以多
• 进入选题卡的候选数量要少

一条更适合当前项目的落地路径

如果把这条思路接到 md2wechat Agent API 的内容场景里，更自然的顺序是：

1. 先抓 AI 信息源
2. 再按来源类型和关键词做粗筛
3. 对项目和文章做二次验证
4. 输出成可写的选题卡
5. 再让 Agent 起草公众号文章
6. 最后再接排版、草稿和发布流程

这个顺序比“先让 AI 写，再去找依据”稳得多。

结论

AI 信息源接进自动化创作，真正关键的不是采集能力，而是编辑能力前移。

更值得自动化的，不只是“抓到内容”，而是把内容变成：

• 可筛选
• 可验证
• 可排序
• 可转成选题

当这条链路跑顺以后，后面的 prompt、成稿、排版和发布才会真正稳定。

如果你要继续补前一层或后一层，可以再看：

• AI 信息源怎么找：适合公众号写作者的 7 类高质量来源
• AI 写公众号怎么去 AI 味：一套可执行的改写清单