企业官网建设流程全解析

1. 项目概述：为什么我们需要一个AI模型“比价器”？

作为一名长期在AI应用开发一线的工程师，我几乎每天都在和OpenAI、Anthropic、Google这些大厂的API打交道。从早期的GPT-3.5到现在的Claude 3.5 Sonnet、GPT-4o，模型的选择越来越多，价格体系也越来越复杂。我经常遇到这样的场景：项目初期为了快速验证，随手选了GPT-4，结果月底一看账单，成本远超预期；或者为了省钱选了某个便宜的模型，却发现它在特定任务上表现不佳，导致返工，时间成本反而更高。更头疼的是，各家厂商的定价单位五花八门——有的按每百万输入/输出Token计费，有的按每千次请求计费，还有的提供免费额度但限制速率。手动在十几个浏览器标签页间切换，对比表格，计算月度预估成本，这过程既低效又容易出错。

这就是我发现llmarena.ai这个开源项目时感到眼前一亮的原因。它不是一个简单的模型列表，而是一个真正从开发者痛点出发的“AI模型比价与能力对比工具”。你可以把它想象成AI领域的“天梯图”或“汽车之家配置对比页”，但它更动态、更贴近实际开发需求。项目核心解决了三个关键问题：第一，信息碎片化。它将分散在各家厂商文档、博客和定价页的信息，聚合到一个统一的、实时更新的视图中。第二，成本不可预测性。它内置的定价计算器，允许你基于自己预估的Token用量，快速算出在不同模型上的月度花费，让成本从“黑盒”变得透明。第三，选型决策困难。它提供了并排对比（Versus）功能，让你能直观地看到不同模型在上下文长度、知识截止日期、功能支持（如函数调用、视觉理解）等维度的差异。

这个项目完全开源，技术栈选用了当前前端领域非常主流的Next.js 14 (App Router) + TypeScript + Tailwind CSS，并搭配了shadcn/ui和Radix UI来构建高质量、可访问的组件。数据层则巧妙地依赖了BerriAI的LiteLLM项目作为上游数据源，后者是一个旨在统一各类LLM API调用的开源库，其维护的模型列表和价格信息相对权威和及时。这意味着llmarena.ai本身不需要维护一个庞大的数据库，而是通过API获取最新数据，实现了关注点分离——专注于打造极致的用户体验和对比工具。对于任何想要学习现代全栈开发、理解如何构建数据驱动型工具，或者单纯想为自己的项目找一个高性价比AI模型的开发者来说，这个项目都是一个绝佳的学习范本和实用工具。

2. 核心功能与设计思路拆解

2.1 功能架构：从用户场景出发的设计

llmarena.ai的功能设计非常克制，没有冗余的花哨特性，每一处都直指核心用户需求。我们可以将其核心功能模块分解为以下四个部分，这背后体现的是一种“工具思维”而非“产品思维”。

2.1.1 模型总览与筛选面板这是用户进入网站后的第一印象，也是信息密度最高的区域。设计上，它没有采用常见的仪表盘，而是做了一个清晰的列表视图，每一行代表一个AI模型。关键列包括：模型名称、提供商、输入/输出价格、上下文窗口大小以及一个快捷的“加入对比”按钮。页面顶部通常会有强大的筛选器，允许用户按提供商（如OpenAI, Anthropic）、按模型系列（如GPT-4, Claude）、按特定能力（是否支持函数调用、是否有视觉能力）进行快速过滤。这个设计的精妙之处在于，它模拟了开发者在做技术选型时的思维路径：先确定大方向（选哪家厂商），再缩小范围（选哪个系列的模型），最后关注具体参数和价格。筛选器的即时响应（很可能使用了React的状态管理进行客户端过滤）确保了交互的流畅性。

2.1.2 定价计算器：将抽象成本具体化这是项目的“杀手级”功能。很多定价页面只给出单价，比如“$0.01 / 1K input tokens”，但这个数字对大多数人来说是抽象的。llmarena.ai的计算器允许你输入两组更直观的参数：每月预估的输入Token量和输出Token量。比如，你可以估算你的应用每月大概有500万次用户查询，平均每次查询输入500 Token，输出200 Token。输入这些数字后，计算器会实时为你计算出每个模型对应的月度成本。这个功能的价值在于，它完成了从“单位价格”到“项目总预算”的翻译，让决策从感性走向理性。在实现上，这需要前端对每个模型的价格数据进行实时计算，并可能提供一些预设的用量场景（如“小型创业项目”、“中型企业应用”）作为快速参考。

2.1.3 并排对比（Versus）功能当你通过筛选或搜索找到几个候选模型后，如何做出最终决定？并排对比功能就像一张详细的“参数对照表”。你可以选择2-4个模型，系统会生成一个对比视图，将关键属性如最大上下文长度、训练数据截止日期、是否支持JSON模式、是否支持视觉输入、每分钟请求限制等并排列出。这个视图极大地减少了用户在多个标签页或文档间来回切换的认知负荷。从技术实现看，这需要前端动态生成一个对比表格，数据来源于统一的模型数据对象。这里的一个细节优化可能是高亮显示某个模型在特定维度上的优势（比如用绿色背景标出最长的上下文窗口或最低的价格），帮助用户快速捕捉差异点。

2.1.4 数据实时性与来源一个对比工具如果数据过时，就失去了所有价值。llmarena.ai聪明地选择了LiteLLM作为单一数据源。LiteLLM本身就是一个需要持续维护以支持其统一API接口的项目，因此它的模型列表和价格信息更新相对频繁。llmarena.ai通过定期（可能是通过GitHub Actions定时任务或直接调用API）从LiteLLM仓库获取数据，从而保证了自身数据的鲜活性。这种架构意味着项目维护者不需要成为所有AI模型的专家，只需确保数据拉取管道畅通即可。这是一种非常高效的“站在巨人肩膀上”的策略。

2.2 技术栈选型背后的逻辑

作者选择的技术栈堪称现代React应用的最佳实践组合，每一项选择都有其明确的意图。

• Next.js 14 (App Router)：这是项目的基石。Next.js提供了开箱即用的服务端渲染、静态生成、API路由等能力。对于llmarena.ai这样一个内容相对静态（模型数据定期更新）、但需要极快首屏加载速度的工具网站来说，使用getStaticProps或新的App Router中的服务端组件来在构建时生成页面，可以带来近乎瞬时的加载体验。同时，当需要实现更动态的交互（如计算器实时计算）时，它又能无缝切换到客户端渲染。Vercel Analytics的集成也因部署在Vercel上而变得异常简单。
• TypeScript：在处理像AI模型数据这样结构复杂、字段众多的对象时，TypeScript的静态类型检查是必不可少的“安全网”。它能确保在数据源结构发生变化时，前端代码的适配过程更容易被捕获，避免运行时错误，极大提升了项目的可维护性。
• Tailwind CSS：对于需要快速迭代、定制大量独特UI组件的项目，Tailwind这种实用优先的CSS框架能显著提升开发效率。llmarena.ai的界面干净、响应式，用Tailwind来实现各种布局、颜色和响应式断点调整非常高效。
• Radix UI + shadcn/ui：这是构建高质量可访问性组件的“黄金搭档”。Radix UI提供了完全无样式、可访问性完善的组件原语（如对话框、下拉菜单、切换开关），而shadcn/ui则是在此基础上，提供了一套用Tailwind CSS编写的、开箱即用且美观的组件实现。选择它们意味着开发者不需要从零开始构建复杂的交互组件，同时能保证组件具备良好的键盘导航、屏幕阅读器支持等可访问性特性，这对任何面向公众的工具都至关重要。
• 数据流管理：考虑到项目状态并不极度复杂（主要是筛选状态、对比模型列表、计算器输入值），很可能没有引入Redux或Zustand这样的状态管理库，而是使用了React的Context API或甚至只是通过Props drilling和组件本地状态来管理，这保持了项目的轻量。

注意：技术栈的“时髦”有时是一把双刃剑。Next.js App Router的理念与之前的Pages Router有较大不同，学习曲线较陡。对于初学者，如果只是想借鉴核心功能，可以先用更熟悉的Pages Router或甚至Create-React-App来实现核心逻辑，避免在框架复杂性上卡壳。

3. 核心实现细节与实操要点

3.1 数据层的设计与同步策略

llmarena.ai的核心是数据。其数据流设计可以概括为：上游数据源 -> 数据获取与处理层 -> 前端状态与展示。

3.1.1 从LiteLLM获取原始数据LiteLLM的模型数据通常以一个结构化的文件存在，比如一个model_prices_and_context_window.json的JSON文件。这个文件包含了数百个模型的详细信息。在llmarena.ai中，会有一个数据获取脚本（例如scripts/fetch-models.js）。这个脚本的核心任务很简单：

1. 从指定的LiteLLM GitHub仓库URL或API端点获取最新的JSON数据。
2. 对数据进行清洗和转换，使其适配前端组件需要的数据结构。例如，原始数据中的价格可能是字符串“0.0015”（表示每千Token），前端可能需要将其转换为数字0.0015，并同时计算好每百万Token的价格（1.5）以便展示。
3. 将处理好的数据写入项目中的一个JSON文件（如lib/data/models.json）或直接更新数据库。

3.1.2 实现自动化的数据更新为了让网站数据保持最新，必须实现自动化更新。最经典的方案是使用GitHub Actions。

# .github/workflows/update-models.yml name: Update Model Data on: schedule: - cron: '0 0 * * *' # 每天UTC时间0点运行一次 workflow_dispatch: # 允许手动触发 jobs: update: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '18' - name: Install dependencies run: npm ci - name: Fetch latest model data run: node scripts/fetch-models.js - name: Commit and push if changed run: | git config user.name 'github-actions' git config user.email '41898282+github-actions[bot]@users.noreply.github.com' git add lib/data/models.json git diff --quiet && git diff --staged --quiet || (git commit -m "chore: update model data from LiteLLM" && git push)

这个工作流每天自动运行一次，执行数据获取脚本。如果数据有变化，它会自动提交并推送到仓库。项目部署在Vercel上，Vercel会监测到仓库更新并自动触发一次新的部署，这样用户访问到的就是最新的数据。这是一种低成本、高可靠性的数据同步方案。

3.1.3 前端数据消费在前端，处理好的models.json数据会被导入。在Next.js中，这可以在服务端组件中直接导入，或者在客户端通过fetch获取一个公开的API端点。然后，这些数据会被注入到React的Context中，或者作为Props传递给各个页面组件，供筛选、列表展示和计算器使用。

3.2 定价计算器的实现逻辑

计算器是前端交互逻辑的核心，其实现需要兼顾准确性和用户体验。

3.2.1 计算模型计算逻辑本身并不复杂，但需要仔细处理单位。假设我们有以下输入：

• 每月输入Token量：inputTokensPerMonth
• 每月输出Token量：outputTokensPerMonth
• 模型单价：输入inputPricePerMillion(美元/百万Token)，输出outputPricePerMillion(美元/百万Token)

那么月度成本计算公式为：monthlyCost = (inputTokensPerMonth / 1,000,000) * inputPricePerMillion + (outputTokensPerMonth / 1,000,000) * outputPricePerMillion

在UI上，用户输入框的单位可能是“百万Token”或直接是“Token”，前端需要做好转换。一个友好的设计是提供两个输入框：“平均每次请求输入Token数”、“平均每次请求输出Token数”和“每月预计请求数”，由前端自动计算总Token量，这更符合用户的思考方式。

3.2.2 实时响应与性能优化当用户在输入框中键入数字时，需要实时为列表中数十个甚至上百个模型计算成本并更新显示。这里必须考虑性能。一个简单的实现是为每个模型绑定一个useEffect或使用useMemo来监听输入值的变化并计算成本。但如果模型数量很多，频繁的重新计算可能导致界面卡顿。

更优的方案是：

1. 防抖处理：对用户的输入事件进行防抖，比如延迟300毫秒后再触发计算，避免每次按键都进行全量计算。
2. 虚拟列表：如果模型列表非常长，可以考虑使用虚拟滚动技术（如react-window或tanstack-virtual），只渲染可视区域内的模型行，这样需要计算成本的模型数量就大大减少了。
3. Web Worker：将繁重的计算任务丢给Web Worker，避免阻塞主线程，保持UI的流畅响应。不过对于简单的乘法计算，这可能有点杀鸡用牛刀。

3.2.3 展示优化计算出的成本需要友好地展示。对于很小的成本（如0.00015美元），直接显示意义不大。通常的做法是：

• 如果成本低于0.01美元，显示为“<$0.01”。
• 对于其他数字，格式化为两位小数，如“$12.34”。
• 可以提供一个“年度成本”的切换选项，让用户从更宏观的视角评估。
• 用颜色进行视觉编码：例如，成本最低的3个模型用绿色高亮，成本最高的用浅灰色，让优劣一目了然。

3.3 并排对比（Versus）功能的实现

这个功能的关键在于状态的动态管理和表格的灵活生成。

3.3.1 状态管理需要维护一个“对比列表”状态（例如comparedModels: Array<ModelId>）。每个模型行上的“加入对比”按钮点击时，会触发一个动作，将该模型的唯一ID添加到这个列表中，同时要确保列表内不重复，且可能限制最大数量（如4个）。这个状态最好放在React Context或全局状态管理中，以便在模型列表页和专门的对比页面都能访问到。

3.3.2 对比表格的生成当用户进入对比页面或展开对比面板时，前端需要根据comparedModels数组，从完整模型数据中筛选出对应的模型对象。然后，需要定义一个comparisonFields数组，明确要对比哪些属性，例如：

const comparisonFields = [ { key: 'provider', label: '提供商' }, { key: 'inputPrice', label: '输入价格 ($/1M tokens)', format: (value) => `$${value}` }, { key: 'contextWindow', label: '上下文窗口', format: (value) => value.toLocaleString() }, { key: 'supportsFunctionCalling', label: '函数调用' }, // ... 更多字段 ];

然后，通过两层循环来渲染表格：外层遍历comparisonFields生成行，内层遍历comparedModels生成列。对于布尔值或枚举值，可以用图标（✅/❌）或标签来展示，比纯文本更直观。

3.3.3 用户体验细节

• 拖拽排序：允许用户拖动对比表中的模型列来调整顺序，方便重点比较。
• 高亮差异：通过算法比较同一行中所有模型的值，将最优值（如价格最低、上下文最长）用粗体或背景色高亮。
• 一键移除：在每个对比模型的标题栏提供一个“×”按钮，方便用户快速移除不需要的模型。
• 分享链接：将对比的模型ID序列化到URL的查询参数中（如?compare=gpt-4o,claude-3-5-sonnet），这样用户可以将当前的对比视图直接分享给同事，这是一个非常实用的协作功能。

4. 本地开发环境搭建与代码走读

4.1 从零开始运行项目

假设你是一个想要学习或贡献代码的开发者，以下是快速上手的步骤，我会补充一些原README中未提及的细节。

4.1.1 环境准备与克隆首先确保你的开发机满足前提条件：Node.js版本需要在18以上（建议使用LTS版本），并安装了npm或yarn。然后克隆仓库并安装依赖：

git clone https://github.com/Ahmet-Dedeler/ai-llm-comparison.git cd ai-llm-comparison npm install # 或使用 yarn install

这里有个小坑：如果网络环境导致npm install缓慢或失败，可以尝试切换npm源（npm config set registry https://registry.npmmirror.com）或使用yarn，它通常有更好的缓存机制。

4.1.2 首次运行与数据准备运行npm run dev启动开发服务器。此时，你可能会发现模型列表是空的或加载失败。这是因为项目依赖的模型数据可能没有被包含在仓库中，或者需要手动运行脚本获取。你需要检查项目结构，通常会发现一个scripts/目录或lib/data/目录。

1. 查看package.json中的脚本命令，是否有类似npm run fetch-data或npm run build:data的命令。
2. 如果没有，直接运行数据获取脚本：node scripts/fetch-models.js。
3. 脚本执行成功后，会在lib/data/下生成或更新models.json文件。
4. 此时刷新开发服务器页面（http://localhost:3000），应该就能看到完整的模型数据了。

4.1.3 理解项目结构一个典型的Next.js 14 (App Router)项目结构如下，了解它有助于你快速定位代码：

ai-llm-comparison/ ├── app/ # Next.js 14 App Router 核心目录 │ ├── layout.tsx # 根布局，定义全局HTML和样式 │ ├── page.tsx # 首页路由组件 │ ├── versus/ # 对比页面路由 │ │ └── page.tsx │ ├── api/ # API路由（如果存在） │ │ └── ... │ └── globals.css # 全局样式 ├── components/ # 可复用的React组件 │ ├── ui/ # 基础UI组件（可能来自shadcn/ui） │ ├── ModelTable.tsx # 模型表格组件 │ ├── PricingCalculator.tsx │ └── ... ├── lib/ # 工具函数和配置 │ ├── data/ │ │ └── models.json # 模型数据文件 │ ├── utils.ts # 通用工具函数 │ └── constants.ts # 常量定义 ├── scripts/ # 构建脚本和数据获取脚本 │ └── fetch-models.js ├── public/ # 静态资源 ├── tailwind.config.ts # Tailwind CSS配置 ├── tsconfig.json # TypeScript配置 └── package.json

4.2 核心组件代码解析

让我们深入几个关键组件，看看它们是如何工作的。

4.2.1 ModelTable组件这是渲染模型列表的核心。它接收过滤后的模型数组作为props。其内部逻辑大致是：

1. 使用useState或从Context获取筛选状态（如选中的提供商、排序方式）。
2. 根据筛选状态对传入的模型数组进行过滤和排序。
3. 使用Array.map()遍历处理后的数组，为每个模型数据渲染一行（<tr>）。
4. 每一行包含模型名称、提供商徽标、价格、上下文窗口等单元格。
5. 价格单元格可能需要一个PriceDisplay子组件，该组件会根据当前计算器的输入值（从Context获取）实时计算并显示月度成本。
6. 每一行还有一个复选框或按钮，用于将模型加入/移出对比列表，点击时会调用从Context传来的addToComparison或removeFromComparison函数。

4.2.2 PricingCalculator组件这是一个受控表单组件。

// 简化示例 const PricingCalculator = () => { const [inputTokens, setInputTokens] = useState(1000000); // 默认100万 const [outputTokens, setOutputTokens] = useState(500000); // 默认50万 const { setCalculatorInputs } = useCalculatorContext(); // 假设有一个Context const handleInputChange = (e: React.ChangeEvent<HTMLInputElement>) => { const value = Math.max(0, parseInt(e.target.value) || 0); // 确保非负整数 setInputTokens(value); // 使用防抖函数更新全局状态 debouncedUpdateGlobalState(value, outputTokens); }; // ... outputTokens类似 return ( <div className="p-4 border rounded-lg"> <h3>定价计算器</h3> <div className="flex space-x-4"> <div> <label>每月输入Token (百万)</label> <input type="number" value={inputTokens / 1_000_000} onChange={(e) => setInputTokens(parseFloat(e.target.value) * 1_000_000)} /> </div> <div> <label>每月输出Token (百万)</label> <input type="number" value={outputTokens / 1_000_000} onChange={(e) => setOutputTokens(parseFloat(e.target.value) * 1_000_000)} /> </div> </div> <p className="text-sm text-gray-600">调整滑块，查看下方模型月度成本变化。</p> </div> ); };

这个组件的关键在于，它的状态变化需要立即（或防抖后）通知到全局状态（Context），从而驱动ModelTable中每个模型行的成本重新计算。

4.2.3 数据流与状态管理对于这样一个中等复杂度的应用，状态管理方案的选择直接影响代码的清晰度。项目很可能采用了React Context API来管理全局状态。通常会定义几个Context：

• ModelDataContext: 提供原始的模型列表数据。
• FilterContext: 管理用户选择的筛选条件（提供商、能力等）。
• ComparisonContext: 管理当前加入对比的模型ID列表。
• CalculatorContext: 管理计算器的输入值（月度Token用量）。

这样，ModelTable、PricingCalculator、ComparisonView等组件都可以通过useContext钩子订阅和更新相关的状态，实现数据的单向流动和跨组件通信。如果逻辑更复杂，未来可能会引入像Zustand或Jotai这样更轻量级的状态库。

5. 常见问题、排查技巧与扩展思路

5.1 开发与部署中的常见问题

在实际运行和修改这类项目时，你可能会遇到以下典型问题：

5.1.1 数据获取失败或为空

• 症状：页面加载后模型列表为空，控制台可能有网络错误。
• 排查：
  1. 首先检查scripts/fetch-models.js脚本是否成功运行并生成了lib/data/models.json文件。可以手动运行node scripts/fetch-models.js看终端输出。
  2. 检查脚本中请求的LiteLLM数据源URL是否有效。有时上游仓库的文件路径可能会发生变化。
  3. 检查脚本是否有处理网络请求失败的情况（如使用try-catch，设置请求超时）。
  4. 查看生成的JSON文件格式是否正确，能否在JSON验证器中通过。
• 解决：更新脚本中的源URL，增加错误处理和重试逻辑，确保本地有可用的数据备份。

5.1.2 构建或开发服务器启动错误

• 症状：npm run dev或npm run build时报TypeScript类型错误或模块找不到错误。
• 排查：
  1. Type error: Property 'xxx' does not exist on type...：这通常是models.json的数据结构与TypeScript类型定义（可能在lib/types.ts中）不匹配。需要检查数据获取脚本转换后的字段名是否与类型定义一致。
  2. Module not found: Can't resolve '@/components/...'：这是路径别名问题。检查tsconfig.json中的paths配置，确保@/*正确指向了项目根目录。
  3. 依赖安装不全：尝试删除node_modules和package-lock.json，然后重新运行npm install。
• 解决：根据错误信息调整类型定义、修正导入路径或清理依赖重装。

5.1.3 性能问题：列表滚动或计算卡顿

• 症状：当模型数量很多（>200）时，滚动页面或快速调整计算器滑块时感到明显卡顿。
• 排查：
  1. 使用React DevTools的Profiler工具，录制一个交互动作（如输入数字），查看哪些组件渲染耗时最长、渲染次数过多。
  2. 检查ModelTable组件是否在每次计算器输入变化时，所有行都进行了重新渲染。可能缺少了React.memo对行组件进行记忆化。
  3. 检查计算成本的函数是否被包裹在useMemo中，其依赖项是否设置正确。
• 解决：
  • 对ModelRow组件使用React.memo。
  • 确保计算成本的函数使用useMemo：const monthlyCost = useMemo(() => calculateCost(model, inputTokens, outputTokens), [model, inputTokens, outputTokens]);
  • 考虑实现虚拟滚动。

5.2 功能扩展与个性化改造思路

llmarena.ai提供了一个出色的基础，你可以基于它进行二次开发，打造更适合自己或团队使用的工具。

5.2.1 集成性能基准数据单纯对比价格和参数还不够，模型的实际性能（速度、准确性）至关重要。你可以扩展数据模型，为每个模型添加指向权威基准测试（如MMLU、HellaSwag、HumanEval）的分数。数据可以从Papers with Code、Open LLM Leaderboard等渠道爬取或手动录入。在UI上，可以增加一个“性能”标签页，用雷达图或条形图可视化不同模型在多个基准上的表现。

5.2.2 添加个性化“收藏夹”与备注对于经常需要评估模型的团队，可以增加用户系统（甚至简单的本地存储）。允许用户将常用的模型加入收藏夹，并为每个模型添加私有备注，比如“在代码生成任务上表现优异，但价格偏高”、“适合处理长文档摘要”。这样就能积累团队内部的经验知识库。

5.2.3 开发浏览器插件将核心的比价功能打包成一个浏览器插件。当开发者浏览OpenAI、Anthropic等官方定价页面时，插件可以浮动显示一个对比窗口，直接展示该模型与其他竞品的价格和关键参数对比，实现“随时随地比价”。

5.2.4 构建成本监控与预警API基于计算器逻辑，可以开发一个简单的后端服务（例如使用Supabase Functions或Vercel Serverless Function）。用户提交自己的API使用量日志（或连接其云账户），服务定期计算其在各个模型上的花费，并在成本超出预算时发送邮件或Slack通知。这相当于一个轻量级的AI成本监控工具。

5.2.5 实现“模型推荐引擎”根据用户输入的使用场景描述（如“我需要一个模型来处理客户支持聊天，要求响应快、成本低、能理解上下文”），利用简单的规则引擎或嵌入向量相似度搜索，从模型数据库中推荐最匹配的2-3个选项，并给出推荐理由。这能将工具从被动查询升级为主动建议。

5.3 部署与生产环境考量

如果你想部署自己的版本，需要注意：

1. 数据更新自动化：确保GitHub Actions工作流或类似的CI/CD流程配置正确，能自动更新数据并触发部署。
2. 性能优化：对生产环境构建（npm run build）生成的静态页面，可以利用Vercel、Netlify等平台的全球CDN进行分发，确保全球访问速度。对于图片等静态资源，进行压缩和优化。
3. 分析集成：项目已集成了Vercel Analytics和PostHog，你可以查看实际的用户访问量、最常对比的模型等数据，用以指导后续的功能优化。
4. 自定义域名与品牌：在Vercel等项目设置中，可以轻松绑定自己的域名，并修改网站标题、Logo等，打造属于自己的AI模型对比平台。

这个项目最让我欣赏的一点是，它用并不复杂的技术，解决了一个真实、高频的开发者痛点。整个代码结构清晰，技术栈选型合理，既是实用的工具，也是学习现代React全栈开发的优秀案例。无论是直接使用，还是借鉴其思路和代码来构建自己的内部工具，它都能带来巨大的价值。在实际使用中，我最大的体会是：在AI模型选型上，没有“最好”的模型，只有“最适合”当前场景和预算的模型。而llmarena.ai这样的工具，正是帮助我们做出这个理性决策的得力助手。