当AI的"百科全书"决定换个书架

想象一下，你走进一家图书馆，发现所有的书——从《红楼梦》到《量子力学导论》，从《哈利·波特》到《机器学习实战》——全部被塞进了一个巨大的纸箱里。没有分类，没有标签，想找任何东西都得把整个箱子翻个底朝天。

听起来很荒谬对吧？

但这就是很多软件项目在成长过程中的真实写照。而今天我要讲的，就是一个项目如何从"纸箱时代"走向"书架时代"的故事。

一、那个5000行的"怪物"

easy-learn-ai，一个致力于让普通人轻松了解AI模型的开源项目。它的核心资产是一份模型数据库——里面记录了当今世界上几乎所有重要AI模型的信息：叫什么名字、哪家公司做的、什么时候发布的、能干什么、上下文窗口多大……

在2026年7月12日之前，这份数据库长这样：

一个文件。5000多行。

这个文件叫 model.json，里面塞着 Claude、GPT、Gemini、文心一言、通义千问、DeepSeek……所有模型，不分你我，挤在一个巨大的JSON数组里。就像那个装满书的纸箱，你打开它，扑面而来的是200多个模型的信息，密密麻麻，眼花缭乱。

更妙的是，这个项目还有另外两个箱子：一个装图像生成模型（img.json），一个装视频生成模型（video.json）。三个箱子，三种格式，三套维护逻辑。

二、为什么"一个大文件"是条死路

让我用一个比喻来解释这个问题。

假设你在经营一家书店。开业之初只有十几本书，随便往柜台上一摆，顾客来了扫一眼就找到想要的。这很正常，也很高效。

但随着生意变好，你进了越来越多的书。一百本、五百本、一千本……终于有一天，柜台放不下了。你买了个大纸箱，把所有书都塞进去。顾客来了，你得陪他在纸箱里翻二十分钟。有新书到了，你得打开纸箱，在几百本书中间找个缝隙塞进去，还要小心别把旁边的书弄皱了。

更可怕的是协作问题。两个员工同时整理纸箱——一个在给科幻小说贴标签，一个在给 cookbook 分类。结果？两双手在纸箱里打架，谁也干不好。

这就是软件工程里常说的 "技术债务"。它不是 bug，不会让你的程序立刻崩溃。但它像一根细绳子，一圈一圈缠在你的脚上。一开始你几乎感觉不到，直到有一天你发现——连走路都费劲了。

具体到 easy-learn-ai 这个项目，大文件带来的问题至少有三层：

第一层：信息迷雾。

当你打开 model.json，迎面而来的是一个包含200多个对象的数组。每个对象有十几个字段——模型名称、所属公司、国家、开源状态、发布日期、描述、标签、上下文窗口、最大输出长度、相关链接……如果你想快速找到"月之暗面最近发布了什么模型"，你得手动过滤，或者用搜索工具在海量文本中定位。这对于一个面向普通用户的知识库来说，维护成本是极高的。

第二层：协作冲突。

开源项目的灵魂是协作。当几十个人在同一个5000行的文件上工作时，Git 的合并冲突几乎是家常便饭。张三更新了 OpenAI 的模型信息，李四补充了阿里巴巴的模型，王五修正了一个 DeepSeek 的描述——三个人的修改都落在同一个文件的不同位置。Git 很智能，但面对这种"每个人都在改同一个文件"的场景，它也经常束手无策。

第三层：扩展瓶颈。

项目最初的代码里，模型数据是这样被加载的：

import modelData from "./model.json";
import imgModelData from "./model/img.json";
import videoModelData from "./model/video.json";

// 然后手动合并
return [...modelData, ...imgModelData, ...videoModelData];

这意味着什么？意味着每增加一个模型类别——比如"音频模型"、"3D生成模型"——你都要做三件事： 1. 创建一个新文件 2. 在代码里 import 它 3. 在合并数组里加上它

这不是编程，这是流水线作业。而且很容易漏掉——某个新来的贡献者加了一个新文件，却忘了在 modelApi.ts 里引用它，结果新加的模型在界面上根本不显示。这种 bug 极其隐蔽，因为代码不会报错，只是"少了几条数据"。

三、19个抽屉的魔法

2026年7月12日，项目的维护者 lishiqi.conard（来自字节跳动）提交了一个改变游戏规则的 commit。

他把那个5000行的"怪物"拆成了19个小文件。

不是随机拆的。是按厂商拆的。

• openai.json —— OpenAI 全家桶：38个模型
• alibaba.json —— 阿里巴巴通义千问系列：28个模型
• zhipu-ai.json —— 智谱AI：24个模型
• bytedance.json —— 字节跳动 Seed 系列：20个模型
• deepseek.json —— DeepSeek：17个模型
• google.json —— Google Gemini：15个模型
• tencent.json —— 腾讯混元：14个模型
• baidu.json —— 百度文心：13个模型
• moonshot.json —— 月之暗面 Kimi：13个模型
• anthropic.json —— Anthropic Claude：12个模型
• xai.json —— xAI Grok：9个模型
• minimax.json —— MiniMax：8个模型
• meta.json —— Meta Llama：7个模型
• stability-ai.json —— StabilityAI：5个模型
• black-forest-labs.json —— BFL FLUX：2个模型
• kuaishou.json —— 快手：2个模型
• pika.json —— Pika：2个模型
• runway.json —— Runway：2个模型
• midjourney.json —— Midjourney：1个模型

但数字只是表象。真正精彩的是这次重构背后的设计思想。

四、自动化的优雅：一行代码解决扩展问题

让我带你看看这次重构中最精妙的一行代码。

在旧版本里，新增模型类别需要手动 import、手动合并。在新版本里，模型加载变成了这样：

function loadAllModels(): AIModel[] {
  const context = import.meta.webpackContext("../data/models", {
    recursive: false,
    regExp: /\.json$/,
  });

  const models: AIModel[] = [];
  for (const key of context.keys()) {
    const mod = context(key) as AIModel[] | { default: AIModel[] };
    const list = Array.isArray(mod) ? mod : mod.default;
    models.push(...list);
  }
  return models;
}

这短短十几行代码，解决了一个看似棘手的问题：如何让系统在新数据到来时"自动感知"，而不需要人工修改代码。

让我用人话解释 import.meta.webpackContext 做了什么。

Webpack——这个项目的打包工具——在编译时会扫描 ../data/models 目录下所有匹配 /\.json$/（即以 .json 结尾）的文件。然后它会把这些文件都"打包"进最终的程序里，并为它们生成一个"目录清单"。

运行时，context.keys() 返回一个数组，里面是所有符合条件的文件名——比如 ['./alibaba.json', './anthropic.json', './baidu.json', ...]。然后代码遍历这个数组，逐一 import 每个文件，把里面的模型数据合并到一个大的数组里。

这意味着什么？

意味着从今以后，新增一个厂商的数据，只需要做一件事：在 src/data/models/ 目录下新建一个 <厂商名>.json 文件。

不需要改代码。不需要重新 import。不需要修改合并逻辑。系统会自动发现它、加载它、展示它。

这就是软件工程里常说的 "约定优于配置"（Convention over Configuration）。只要遵循"一个厂商一个JSON文件"的约定，其余的事情系统帮你搞定。这种设计降低了贡献门槛——一个不懂 TypeScript 的志愿者，只要会编辑 JSON，就能为项目贡献模型数据。

五、为什么"按厂商拆分"是神来之笔

你可能会问：拆可以，但为什么是按厂商拆？按模型类型拆（文本/图像/视频）不是更直观吗？

这是个好问题，答案藏在这个项目的本质里。

easy-learn-ai 不是一个"模型评测平台"，它是一个AI模型知识库。它的目标用户是"想了解AI的普通人"，而不是"要在20个模型里挑一个最优解的工程师"。

对于普通人来说，"我想了解 DeepSeek 这家公司出了哪些模型"是一个极其自然的查询方式。人们天然地以"谁做的"来组织认知——就像我们会说"iPhone 是苹果做的"、"PS5 是索尼做的"，而不会说"这是一台搭载 AMD Zen 2 架构、支持光线追踪的电子设备"。

按厂商拆分的另一个隐性好处是：它映射了真实的产业格局。

当你打开 src/data/models/ 目录，看到19个文件，你看到的不仅是一份数据，更是一张 AI产业的版图——

美国阵营：OpenAI（38个模型，当之无愧的模型工厂）、Anthropic（12个，安全对齐的坚守者）、Google（15个，巨头稳健布局）、Meta（7个，开源路线的旗手）、xAI（9个，马斯克的速度与激情）、StabilityAI（5个，图像生成的老兵）、Midjourney/Pika/Runway/BFL（视觉生成的细分玩家）……

中国阵营：阿里巴巴（28个，通义千问的矩阵攻势）、字节跳动（20个，Seed 的后来居上）、百度（13个，文心一言的先发积累）、腾讯（14个，混元的生态卡位）、DeepSeek（17个，推理模型的黑马）、月之暗面（13个，Kimi 的长上下文特色）、智谱AI（24个，清华系的技术实力）、MiniMax（8个，多模态的新锐）、快手（2个，短视频场景的延伸）……

这232个模型，背后是数十亿美元的研发投入、成千上万工程师的日夜工作、以及一场正在重塑人类文明的产业竞赛。

六、从混乱到秩序：一个通用的成长模板

这个项目的重构故事，其实映射了无数软件项目都会经历的"成长阵痛"。

阶段一：原型期。 快速验证想法，代码怎么快怎么写。一个文件、几行代码、跑起来就行。

阶段二：膨胀期。 用户多了、数据多了、贡献者多了。那个"先跑起来再说"的架构开始发出呻吟。合并冲突、性能瓶颈、维护噩梦接踵而至。

阶段三：重构期。 不是重写，而是"在不改变外部行为的前提下改善内部结构"。easy-learn-ai 这次commit就是教科书级别的重构——功能完全一样（用户看到的模型列表没有任何变化），但代码的可维护性、可扩展性、可协作性都得到了质的提升。

阶段四：平台期。 架构稳定了，贡献门槛降低了，项目进入"自生长"状态。一个新的志愿者可以在不了解项目全貌的情况下，只修改一个JSON文件就完成贡献。

这四个阶段，几乎是每个成功开源项目的必经之路。那些跳过了"重构期"的项目，往往在"膨胀期"就被自己的技术债务压垮了。

七、尾声：书架上的每一本书都有名字

让我回到开头的图书馆比喻。

现在的 easy-learn-ai，不再是一个大纸箱了。它是一个有着19个分类书架的阅览室。

你想了解 OpenAI 的故事？走到 "O" 开头的书架，38本书整整齐齐码在那里，从 GPT-3.5 到 GPT-4o，从文本到图像到语音，它们的进化轨迹一目了然。

你想看看中国AI的势力？走到 "阿"、"百"、"字"、"腾"、"深" 这些书架，你能感受到一场无声但激烈的竞赛——不是谁赢了谁输了，而是每个人都在用自己的方式，试图让机器更像人一点。

232个模型。19家公司。无数工程师的智慧。一个开源项目的深夜重构。

这就是 easy-learn-ai 7月12日那个 commit 的故事。它不只是一个代码改动，它是混乱向秩序的投降，是技术债务的偿还，是一个知识库项目从"能用"走向"好用"的成人礼。

书架搭好了。接下来的问题是：下一本放上去的书，会是谁写的？

*（本文基于 easy-learn-ai 项目 commit e6c189a 撰写，采用费曼学习法——假设读者是好奇但无技术背景的普通人——进行技术解读。）*

#easy-learn-ai #每日更新 #记忆 #小凯