我每天关注的内容很分散：AI、开源、Rust、产品、市场和全球新闻，各自有不同的来源和更新节奏。把网页打开并不难，难的是判断哪条信息值得留下。

Feeds Hub 不负责“让 AI 自动写新闻”。它把候选信息从发现到发布的处理链写进仓库，让每条内容都能回到来源、判断和验证结果。

项目地址：idaibin/feeds-hub

一条信息怎样进入仓库

一次自动更新至少要回答这些问题：

如果这些判断没有固定下来，更新越频繁，仓库里积累的噪声越多。在我现在的流程里，AI 可以把零散材料整理成完整段落；如果没有来源和输出约束，它也会把任务要求、搜索过程和空泛总结一起写进正文。

这套判断落在五个连续步骤里：

discover
-> verify
-> write Markdown
-> validate
-> squash/push

discover 负责寻找候选主题。X、Reddit、社区讨论和聚合页面可以提供线索，但不能自动成为事实来源。

verify 回到原始公告、项目仓库、官方文档或可靠报道，确认时间、主体和变化内容。找不到足够证据的主题直接跳过。

write Markdown 只写读者需要的信息：发生了什么、为什么值得关注、来源在哪里。任务指令、执行汇报和“本轮未发现内容”不应该出现在 Feed 正文里。

validate 检查 frontmatter、链接、格式和站点构建。当前自动更新的主体仍然是 Markdown；封面不属于这条主链路，状态保持待处理。

最后再整理提交历史并推送。这个步骤看起来普通，但它保证每次更新都能追踪、回退和审查。

规则和内容放在哪里

idaibin/skills = 可独立安装的通用能力
feeds-hub = 主题规则、来源规则、信息流内容和站点实现
blog = 公开 Prompt、长期复盘和开发经验

我不把具体 Feed 放进 Skills Catalog，也不把个人或仓库规则复制进每个 Prompt。通用能力集中在 idaibin/skills，公开 Prompt 和长期经验留在 blog，具体信息流内容保留在产生它的项目里。

AI 能处理哪一段

AI 适合搜索、归并、压缩、检查格式，也可以按照固定结构写 Markdown。至于一条信息是否可信、是否重复、是否值得长期保留，仍然需要规则和证据约束。没有这层约束，自动化只会把同一类噪声更稳定地写入仓库。

页面只是结果。这个项目真正留下的是一条可追踪的编辑链：规则为什么改变，内容依据什么写入，出现问题后从哪里往回查。