1. 从一条推送说起为什么要盯住500个AI模型我平时有个习惯早上泡咖啡的时候会顺手刷一遍模型发布列表。这个习惯大概从两年前开始那时候能叫得上名字的模型也就几十个手动翻一翻还能跟得上。到了今年情况完全变了——几乎每天都有新模型冒出来有开源的、有闭源的有做文本的、有做图像的、有专门跑在端侧的还有一堆微调版本和量化版本。光是记清楚哪个模型叫什么、什么时候发的、参数多大、支持什么模态就已经很费脑子了。真正让我下决心动手做这个网站的是连续两次踩坑。第一次是团队要选一个开源模型做本地推理我凭印象推荐了一个结果同事一查那个模型已经出了三个后续版本我推荐的那个在长文本任务上早就被超越了。第二次更尴尬客户问某个模型支不支持工具调用我拍脑袋说支持结果人家翻出官方文档那个能力是下一个版本才加的。这两件事让我意识到靠人脑记忆和零散收藏夹来跟踪模型动态已经彻底不够用了。所以我做了个网站核心目标就一句话把500个AI模型的动态集中到一个地方自动更新随时可查。它解决的不是什么高深问题就是信息聚合和变化追踪。适合谁看呢我觉得三类人最需要一是做AI应用开发的工程师选型的时候要横向对比二是技术团队的负责人要判断某个方向值不值得投入三是像我这样喜欢折腾本地部署的爱好者想知道哪个模型又出了新量化版本。这个网站不生产模型它只是模型动态的搬运工和整理者。2. 整体设计思路为什么是“聚合自动化”而不是“人工编辑”2.1 核心矛盾信息源太多人工维护必死一开始我想得很简单不就是列个表格吗手动填一填不就行了。结果第一周我就放弃了。模型动态的来源太分散了有的在代码托管平台的发布页有的在模型社区的模型卡有的在官方博客还有的只在技术报告里提一句。更麻烦的是更新频率完全不可预测有的模型半年不动有的模型一周发三个版本。如果靠人工去每个源头检查那这个网站还没上线我就先累死了。所以整体设计的第一原则就是能自动化的绝不手动。网站本身只做三件事——抓取、存储、展示。抓取交给定时任务存储交给结构化数据库展示交给前端页面。我作为维护者只需要在初期配置好数据源和解析规则后面基本不用天天盯着。2.2 方案选型为什么用GitHub Actions而不是自建服务器这里要解释一个关键选择。很多人做这类聚合网站第一反应是租一台服务器跑个定时脚本。我一开始也这么想但算了一笔账就放弃了。一台最便宜的云服务器一年也要几百块还要自己处理系统更新、依赖升级、进程守护、日志清理。对于我这种个人项目来说运维成本太高了。GitHub Actions的好处在于它本身就是为自动化任务设计的。我可以把抓取脚本放在仓库里配置一个定时工作流让它每隔几小时跑一次。跑完的结果直接提交回仓库或者推送到数据库。整个过程不需要我维护任何服务器也不需要担心脚本挂了没人重启。而且Actions的免费额度对于这种轻量级抓取任务来说完全够用一天跑几次一个月下来也用不了多少额度。当然这个方案也有代价。Actions的运行环境是临时的每次跑都是一个干净容器所以不能在里面存状态。我的做法是把所有需要持久化的数据都放到外部存储里脚本本身只负责“读源、解析、写库”这三步。这样即使某次任务失败也不会影响已有数据。2.3 数据模型怎么描述一个“模型动态”在设计数据库表的时候我纠结了很久。一个模型动态到底包含哪些字段最开始我想得很复杂什么训练数据、评测分数、推理成本都想塞进去。后来发现字段越多抓取难度越大因为很多信息在源头就不完整。最后我定了一个最小可用集合字段名说明是否必填model_name模型名称是source来源平台标识是release_date发布日期否version版本号或标签否modality支持模态文本/图像/音频等否parameter_size参数量描述否license许可类型否url原始链接是first_seen首次抓取时间是last_updated最后更新时间是这个表结构的好处是即使某个字段抓不到也不影响整条记录入库。前端展示的时候缺失字段就显示“未知”或者留空不会报错。而且first_seen和last_updated这两个时间戳非常关键它们能让我知道哪些模型是新出现的哪些是最近有更新的。3. 核心细节解析抓取、解析、去重、展示3.1 抓取策略不同来源用不同节奏500个模型不是来自一个地方所以抓取策略也不能一刀切。我把来源分成了三类每类用不同的抓取频率和解析方式。第一类是代码托管平台的发布页。这类来源的特点是结构相对规整有固定的API或者页面结构。对于这类来源我直接用平台的API来拉取发布列表拿到JSON之后解析出模型名称、版本号、发布时间和描述。API的好处是稳定不容易因为页面改版而失效。第二类是模型社区的模型卡页面。这类来源的结构差异很大有的模型卡写得很规范有的就几行字。对于这类来源我用的是HTML解析加启发式规则。比如先找页面里有没有“Model Details”这样的标题有的话就提取下面的键值对没有的话就退而求其次从页面标题和描述里提取模型名称和基本信息。第三类是官方博客和技术报告。这类来源最难抓因为格式完全不固定。我的做法是只抓标题和摘要然后用关键词匹配来判断是不是模型发布相关的文章。如果是就提取标题里的模型名称和发布日期正文内容不抓只保留链接。注意抓取频率不要设得太高。我一开始设了每半小时跑一次结果有些平台会返回频率限制错误。后来改成每三小时跑一次稳定多了。对于更新不频繁的来源甚至可以一天跑一次。3.2 解析难点模型名称的归一化这是整个项目里最头疼的问题。同一个模型在不同来源里的写法可能完全不一样。比如一个模型叫“XYZ-7B”在代码托管平台上可能写成“xyz-7b”在模型社区里可能写成“XYZ 7B”在博客里可能写成“XYZ七B”。如果不做归一化数据库里就会出现一堆重复记录。我的做法是分两步走。第一步是规则归一化把所有名称转成小写去掉空格和特殊符号把中文数字转成阿拉伯数字。第二步是模糊匹配对于归一化之后仍然不完全一样的名称用编辑距离来判断是不是同一个模型。如果编辑距离小于某个阈值就认为是同一个模型的不同写法合并成一条记录。这个阈值我调了好几次。设得太小会把不同模型合并设得太大又会漏掉真正的重复。最后我定的是编辑距离不超过2并且要求两个名称的长度差不超过3。这个参数不是理论最优但在我实际抓取的数据上表现最稳。3.3 去重与更新怎么判断“这条动态是不是新的”去重逻辑其实比想象中复杂。不是简单地把名称一样的去掉就行因为同一个模型会有多个版本。我的判断逻辑是这样的如果model_name和version都相同认为是同一条记录只更新last_updated。如果model_name相同但version不同认为是同一个模型的新版本插入新记录。如果model_name不同但url相同认为是同一来源的重复抓取忽略。如果model_name和url都不同但归一化名称高度相似进入人工审核队列。最后这条“人工审核队列”是我后来加的。因为完全自动化的模糊匹配总会有误判与其让它自动合并出错不如先标记出来我每周花十分钟过一遍。这个设计看起来不够“全自动”但实际用下来它避免了很多脏数据。3.4 前端展示怎么让500条数据不吓人500个模型如果全部平铺在一个列表里用户根本看不过来。所以前端我做了三层过滤和两种视图。第一层过滤是按模态筛选文本、图像、音频、多模态点一下就能缩小范围。第二层是按时间筛选最近一周、最近一月、最近三月。第三层是按来源筛选只看某个平台的动态。两种视图分别是时间线视图和表格视图。时间线视图适合快速浏览最近发生了什么表格视图适合横向对比多个模型的参数。默认打开的是时间线视图因为大部分用户进来就是想看看“最近有什么新东西”。实操心得前端不要做太重的框架。我用的是最基础的HTML加一点原生JavaScript数据通过静态JSON加载。这样页面加载速度非常快而且部署简单直接扔到静态托管服务上就行。4. 实操过程从零搭建的完整步骤4.1 第一步确定数据源清单在写任何代码之前我先花了两天时间整理数据源。具体做法是打开一个空白表格列出我能想到的所有模型发布渠道然后逐个验证是否可抓取。验证的标准有三个页面是否能正常访问、是否有稳定的结构、是否允许自动化访问。最后我筛出了大约20个核心来源覆盖了大部分主流模型。这个数量不是越多越好因为每增加一个来源就多一套解析规则要维护。我的原则是宁可少抓几个小众来源也要保证核心来源的稳定性。4.2 第二步搭建抓取脚本抓取脚本我用的是Python主要考虑是生态成熟处理HTTP请求和HTML解析的库都很完善。脚本的结构很简单就是一个来源一个函数每个函数负责拉取数据并返回统一格式的字典列表。import requests from bs4 import BeautifulSoup def fetch_source_a(): url https://example.com/api/releases resp requests.get(url, timeout30) data resp.json() results [] for item in data: results.append({ model_name: item.get(name), version: item.get(tag_name), release_date: item.get(published_at), url: item.get(html_url), source: source_a }) return results每个函数都加了超时和异常处理因为网络请求失败是常态不能让一个来源的失败影响整个任务。所有函数跑完之后把结果合并成一个列表交给下一步处理。4.3 第三步配置GitHub Actions工作流工作流文件放在仓库的.github/workflows目录下核心配置就是定时触发和运行脚本。name: model-tracker on: schedule: - cron: 0 */3 * * * workflow_dispatch: jobs: fetch: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Set up Python uses: actions/setup-pythonv5 with: python-version: 3.11 - name: Install dependencies run: pip install requests beautifulsoup4 - name: Run fetch script run: python fetch.py - name: Commit and push run: | git config user.name tracker-bot git config user.email botexample.com git add data/ git diff --quiet git diff --staged --quiet || git commit -m update model data git push这个配置里有两个细节值得说。一是workflow_dispatch它允许我手动触发任务调试的时候非常方便。二是提交前的git diff检查如果没有变化就不提交避免产生一堆空提交记录。4.4 第四步数据存储与前端对接抓取结果我存成了JSON文件按日期分目录存放。这样做的好处是版本可控每次更新都能看到差异。前端加载的时候先读一个索引文件找到最新的数据文件然后再加载具体内容。async function loadLatestData() { const indexResp await fetch(/data/index.json); const index await indexResp.json(); const latest index.files[index.files.length - 1]; const dataResp await fetch(/data/${latest}); return await dataResp.json(); }这个方案的好处是简单不需要数据库也不需要后端服务。坏处是数据量大了之后JSON文件会很大。不过500个模型的元数据压缩之后也就几百KB完全在可接受范围内。4.5 第五步部署与域名配置前端页面我托管在一个静态托管服务上绑定了一个自己买的域名。部署流程就是推送代码托管服务自动构建和发布。整个过程不需要手动上传文件也不需要配置服务器。注意静态托管服务通常有缓存更新数据之后可能需要等几分钟才能生效。如果着急看到最新数据可以在URL后面加一个时间戳参数来绕过缓存。5. 常见问题与排查技巧实录5.1 抓取失败怎么快速定位是哪个来源出了问题抓取任务跑失败是家常便饭。我的排查流程是这样的先看日志里哪个来源报了异常然后单独跑那个来源的抓取函数看是网络问题还是解析问题。如果是网络问题通常是超时或者频率限制等一会儿再试就行。如果是解析问题通常是页面结构变了需要更新解析规则。为了提高排查效率我在脚本里给每个来源都加了独立的日志前缀。这样在Actions的日志里搜索来源名称就能快速定位到相关记录。5.2 数据重复为什么会出现同一条记录多次入库前面提到过去重逻辑但实际运行中还是会出现重复。最常见的原因是同一个模型在不同来源里的名称差异太大模糊匹配没识别出来。另一个原因是抓取时间间隔太短同一个来源被连续抓了两次而第二次抓取时页面还没更新导致旧数据被当成新数据插入。解决方法是加一个“抓取窗口”判断如果某条记录的url和上次抓取的一样并且last_updated在24小时以内就跳过不处理。这个简单的规则过滤掉了大部分误报。5.3 页面加载慢500条数据怎么优化一开始我把所有数据一次性加载到前端结果页面打开要好几秒。后来改成了分页加载每次只加载50条滚动到底部再加载下一批。同时把JSON文件做了压缩去掉了不必要的空格和换行。还有一个优化是给数据加了索引。前端加载的时候先加载一个轻量的索引文件里面只有模型名称和ID用户点击某个模型再加载详情。这样首屏加载时间从几秒降到了几百毫秒。5.4 常见问题速查表问题现象可能原因排查方法解决措施任务失败日志显示超时网络不稳定或来源限流单独运行该来源脚本增加超时时间降低抓取频率数据出现重复记录名称归一化不彻底检查归一化后的名称调整模糊匹配阈值前端页面空白JSON文件路径错误检查浏览器控制台修正索引文件路径数据更新延迟静态托管缓存查看响应头缓存时间加时间戳参数或手动刷新缓存某个来源长期无数据页面结构改版手动访问来源页面更新解析规则实操心得不要追求100%的自动化。我每周会花十分钟看一眼人工审核队列处理那些模糊匹配拿不准的记录。这十分钟的投入比调半天算法参数划算得多。6. 这套东西还能怎么扩展网站上线之后陆续有朋友问能不能加一些功能。我挑了几个成本低、价值高的方向在考虑。第一个方向是模型对比。现在只能看单个模型的详情如果能选两个模型并排对比参数和版本历史对选型会很有帮助。技术上不难就是把两个模型的详情数据加载到同一个页面里做差异高亮。第二个方向是变更提醒。现在用户需要主动来网站看如果能订阅某个模型的更新有变化的时候发个通知会更省心。实现方式可以是邮件订阅也可以是生成一个RSS feed让用户自己用阅读器订阅。第三个方向是数据导出。有些用户想把数据导到自己的表格里做进一步分析。这个最简单加一个导出CSV的按钮就行。不过这些扩展我都不着急做。我的原则是先把核心的抓取和展示做稳再考虑锦上添花。毕竟这个网站的价值在于数据准确和更新及时功能再多数据不准也没人用。最后分享一个我在维护过程中体会最深的小技巧给每个数据源写一个健康检查脚本。这个脚本不抓数据只检查来源页面是否能正常访问、返回状态码是否正常。我把它放在抓取任务之前跑如果某个来源健康检查不通过就跳过它的抓取避免因为一个来源的问题导致整个任务失败。这个小小的前置检查让我的任务成功率从大概七成提升到了九成以上。