一个 AI 热榜站，为什么要把 JSON 当成产品接口来维护一个 AI 热榜站，为什么要把 JSON 当成产品接口来维护

一个 AI 热榜站，为什么要把 JSON 当成产品接口来维护

很多人做 AI 导航或热榜，第一反应是先把页面做出来：卡片、分类、搜索框、排行榜，看起来像一个信息站就行。

但 AI热榜持续跑了一段时间后，我越来越觉得，真正值得花精力维护的不是某一个页面，而是页面背后的 JSON 数据。因为对于一个 6 小时自动更新的站点来说，页面只是结果，JSON 才是每天反复被读取、排序、过滤和渲染的“产品接口”。

今天想聊一个偏技术的角度：为什么 AI 信息站不能只把数据文件当缓存，而要把它当成长期可演进的结构化资产。

AI 类内容有一个特点：变化快，而且类型很多。

新闻有来源、时间、摘要、热点分；工具有定价、分类、官网、适用场景；模型要关心提供商、能力、上下文、是否支持 API；Agent 又要看工作流类型、开源情况、学习成本和项目活跃度。

如果这些信息都直接写进模板里，短期当然能跑起来，但后面会很难维护。首页想换排序规则，要改模板；模型页想加筛选，要重新整理字段；README 想生成摘要，又要从页面里反推内容。最后每个地方都像一个小孤岛。

更稳的做法，是先把数据层定义清楚：热点是一张表，Agent 是一张表，提供商是一张表，模型和工具也各有自己的字段。Hugo 页面、README 摘要、搜索索引和分类入口都从这些结构化数据里读取。这样页面可以持续改版，但数据语义不容易散掉。

自动化站点最怕什么？不是某次更新失败，而是“看起来成功了，实际质量下降了”。

比如热点列表生成了，但里面混进了太多低价值推广帖；Agent 数量增加了，但描述不完整；提供商数据同步了，但模型字段为空；某些条目标题还是英文，普通中文用户看不懂；某些链接无法访问，页面却正常部署。

这些问题如果只靠人工点页面，很容易漏掉。把 JSON 当成产品接口后，就可以围绕数据做质量门：字段是否完整、分类是否合理、摘要是否为空、外链是否异常、中文标题比例是否达标、站内文章是否有对应的内部路径。

也就是说，质量检查不应该等到页面上线后才开始，而应该在数据进入模板之前就完成。对 AI热榜这种持续更新的项目来说，这比“多抓几个源”更重要。

我比较喜欢的一种分工是：GitHub Actions 只负责把流水线稳定跑起来，Hugo 负责把已经整理好的数据表达出来。

前者关注的是采集、清洗、排序、生成 JSON、提交更新；后者关注的是列表页、详情页、分类页、搜索入口和静态资源。两者中间用数据文件连接，而不是互相混在一起。

这样做有一个好处：新增页面时，不一定要重写采集逻辑；调整数据源时，也不一定影响所有模板。项目会从“一个页面工程”变成“一个数据产品”。

AI 工具每天都在增加，新闻每天都在翻页，模型和提供商也会频繁变化。如果目标只是“收集得更多”，这个项目迟早会变成一个没人敢改的链接仓库。

可持续的关键，是让新增内容有入口、旧内容有校验、页面之间有统一数据源。这样即使更新频率很高，也能保持基本可信：用户打开首页知道今天发生了什么，开发者进模型或 Agent 页面能做初步选型，维护者也能通过数据文件快速判断问题出在哪里。

这也是我觉得 AI热榜比较值得观察的地方。它不是把 AI 新闻、工具、模型、Agent、提供商硬塞到一个页面里，而是在尝试把它们拆成不同数据层，再用静态站点的方式稳定发布出来。

对于想做类似信息产品的人来说，最值得借鉴的可能不是某个页面样式，而是这个思路：先把数据当产品接口维护，再让页面成为它的不同视图。