Feeds Hub 对我来说不是一个普通的信息流网站。
如果只是做一个网站，把新闻整理成卡片，再放到页面上，这件事没有太多可写。真正让我想记录下来的是：这个产品基本是由 AI 创建出来的，而且后面也可以继续交给 AI 自动更新。
我在这个项目里做的事情，更像是在搭一个流程，而不是手写一批内容。
先让 AI 搭出站点结构，再让 AI 帮我定义主题、内容格式、封面规则和页面展示方式。后续更新时，AI 可以按这些规则去找公开信息，判断哪些内容值得写，生成 Markdown，生成或补齐 WebP 封面，再跑检查和构建。
这和“让 AI 帮我写一篇文章”完全不是一类事情。
我想解决的不是看新闻，而是持续更新
每天看信息并不难。真正麻烦的是持续整理。
AI、开发工具、股市、世界杯、LOL、全球新闻、产品动态，每个方向都有很多来源。人每天去看一遍当然可以，但这件事重复、分散，而且很容易变成“今天看了很多，最后什么也没沉淀”。
Feeds Hub 想做的是把这个过程产品化。
不是今天手动整理一篇简报，而是把“每天怎么找信息、怎么判断、怎么写、怎么展示、怎么发布”变成一个固定工作流。
所以它的重点不是页面本身，而是这条链路：
主题 -> 搜索 -> 来源判断 -> 去重 -> 结构化内容 -> 封面 -> 构建 -> 发布只要这条链路成立，今天可以更新 AI，明天可以更新股市，后天可以更新赛事。主题可以换，但工作流不需要重来。
AI 不只是生成内容，也在创建产品结构
这个项目里我最明显的感受是，AI 不能只写自然语言。
如果只是让它写一段摘要，质量再好也只是一次输出。要让它长期更新一个产品，就必须让它写进结构里。
Feeds Hub 的每条内容都有固定字段，比如 category、kind、title、subtitle、summary、eventAt、eventKey、sourceUrl、cover、coverStatus。
这些字段看起来只是 frontmatter，但实际是产品协议。
AI 按这个协议写内容，页面按这个协议展示内容，检查命令也按这个协议判断内容是否合格。这样一来，AI 生成的东西就不是散文，而是可以进入产品的数据。
这也是我觉得它更接近“AI 创建产品”的地方。
产品不是只有 UI。产品还包括内容结构、更新规则、失败处理、展示约束和发布流程。Feeds Hub 这些东西大部分都可以让 AI 按文档继续维护。
后续更新应该是 AI 自动跑
我理想中的 Feeds Hub，不是我每天打开仓库写几条内容。
更合理的方式是：AI 定时跑一轮。
它先读取主题列表，再逐个看主题规则。比如 AI 主题看模型、产品、论文、工具和政策；stock 看市场、宏观、财报和监管；worldcup 或 lol 看赛程、赛果和晋级状态。
如果今天某个主题没有值得写的内容，就跳过。不是每个主题每天都必须硬凑一条。
如果有内容，就写成一条独立 feed。这里有一个非常重要的约束：1 feed = 1 event。一条内容只记录一个事件，不把多个新闻揉在一起。这样标题、摘要、封面和去重才会稳定。
写完之后，AI 再根据 kind 判断这条内容适合什么表达方式。普通新闻是 news，市场简报是 market_brief，政策变化是 policy_update，比赛结果是 match_result，数据结构是 data。
然后它生成封面，写入 WebP。如果这轮无法生成合规图片，就标记 coverStatus: "pending"，让页面 fallback 接住，而不是随便塞一张假图。
最后跑检查、构建，再同步到指定分支。
这整个过程，才是 Feeds Hub 真正的产品形态。
人的工作变成定义规则
做这个项目以后，我对 AI 应用的分工有一个变化。
以前会习惯把 AI 当成执行助手：我说一句，它做一步。
但 Feeds Hub 更像是另一种分工：人负责定义判断标准，AI 负责重复执行。
我需要决定哪些主题值得追踪，哪些来源可信，什么内容应该跳过，标题不能写成什么样，封面不能怎么生成，失败时应该 pending 还是中断。
这些判断一旦沉淀成规则，就不需要每天重新说。
AI 后续更新时，只要先读这些规则，就能按相同标准继续执行。这比每次开一个新对话、重新解释一遍“我要什么风格的摘要”稳定得多。
这也是为什么我把 Skills Catalog、Feeds Hub 和 blog 分开。
idaibin/skills 放可独立安装的专业能力，个人与仓库配置负责持续生效的执行规则，blog 保存公开 Prompt 和长期经验。
Feeds Hub 放短周期的信息流和自动更新规则。
blog 放长期复盘和产品思考。
三个仓库分开以后，AI 才不会把临时内容、长期经验和通用能力混在一起。
这是一种更实际的 AI 应用
我现在对很多 AI 产品页面里的聊天框没有那么兴奋。
聊天当然有用，但它不是所有 AI 应用的终点。很多真实场景里，人需要的不是一个聊天入口，而是一段能持续跑起来的流程。
Feeds Hub 对应的就是“信息处理”这段流程。
它要持续关注主题，要找来源，要判断价值，要写成结构化内容，要生成展示资产，要发布，还要下一次继续。
这件事如果靠人，每天都很碎。如果靠一次 prompt，也很难持续。它需要的是一套产品化的 AI 工作流。
所以我更愿意把 Feeds Hub 看成一个小样板：
AI 可以先创建一个产品，再成为这个产品后续运行的一部分。
这比单次生成内容更接近我想要的 AI 应用方式。
不是给页面加一个 AI 按钮。
也不是让 AI 写一段更漂亮的文案。
而是把原来需要人反复做的信息工作，拆成规则、数据、内容、视觉和发布几个环节，然后让 AI 稳定执行。
Feeds Hub 还很小，但它已经让我看到一个方向：以后很多个人工具、信息看板、内容站、内部简报，都可以先由 AI 创建，再由 AI 维护。
人不一定要每天站在流程里操作。
人更应该站在流程外，定义标准，检查结果，然后继续改进这个系统。