企业官网建设流程全解析

这次我们来看一个把 AI 用在真实项目里的案例：一个用 Codex 辅助开发的全网 AI 充值比价网站。标题里写“烧了几十亿 token”不是自嘲，在大模型辅助开发的场景下，反复生成、重构、改 bug、调接口累积起来的 token 消耗确实可以到很夸张的量级。重点是这个网站本身免费开放，核心功能是把各家 AI 服务的订阅价格、API token 单价和充值渠道价格拉平，统一换算成用户能看懂的每百万 token 成本，让选套餐和选 API 渠道不再靠感觉。

如果你关心三件事，这篇可以直接收藏：第一，Codex 这种 AI 编程工具在真实项目中到底能做什么、浪费在哪；第二，一个 AI 充值比价网站的功能怎么设计、比价数据怎么处理；第三，这类免费工具自己部署时要注意什么边界。下面按项目定位、数据模型、接口设计、部署启动、功能测试、常见问题排查的顺序展开。

1. 核心能力速览

这里先说明一个技术判断：比价类网站真正的难点不是前端页面，而是价格数据怎么来、怎么保证不过期、怎么归一化到统一口径。很多 AI 服务的计费单位不一样，有的按额度积分算，有的按 token 算，有的按请求次数算，如果不做换算，对比结果就没有参考意义。这个项目能解决的核心问题，就是把“看起来便宜”和“实际便宜”区分开。

2. 比价网站的使用场景与边界

2.1 适合谁用

第一类是个人用户。ChatGPT、Claude、Gemini 这些主流服务的订阅价格经常调整，加上不同地区、不同支付方式的实际到账成本也不一样，普通用户很难记住每个平台的会员价格变化。比价网站可以把各家的月费、年费、功能限制放一起，用户根据预算直接筛选。

第二类是开发者和小型团队。开发者更关心 API 调用成本，也就是每百万输入 token、每百万输出 token 分别多少钱。不同平台的模型命名、上下文长度、缓存价格都不一样，手动算非常容易错。通过比价接口传入模型名称和 token 用量，就能直接在同一个口径下看到各渠道的价格排序。

第三类是研究 token 成本结构的用户。AI 服务的费用不只是“1 个 token 多少钱”，还涉及上下文缓存命中、批量 API 折扣、不同时段的计费策略。比价网站可以辅助做这类成本结构分析。

2.2 使用边界与合规提醒

从项目公开信息看，这个网站定位是信息整理和比价工具，不是代充平台，也不提供账号共享服务。这一点非常重要。AI 充值比价领域常见的风险包括：第三方代充渠道的账号安全、信用卡风控、区域限制、代理商跑路等。比价网站能做的只是把公开价格呈现给用户，不应该介入充值交易流程，也不应该采集用户的 API Key 或登录凭证。

价格数据本身也有时效性。AI 平台调价、新增模型、改变计费单位都是常态，比价结果只能作为参考，最终下单前要以官方定价页为准。涉及人脸、声音、内容生成类服务的比价，还要额外关注授权边界，不能因为某个渠道价格低就推荐用户使用来路不明的服务。

3. Codex 辅助开发的真实实践路径

这次项目的开发流程可以拆成几个阶段，能清楚看到 Codex 在真实工程里的边界。

3.1 用 Codex 做什么

最直接的部分是让 Codex 生成项目骨架。比价网站的基础框架可以分为前端展示页、后端查询接口、数据抓取脚本、数据库表结构四块。对 Codex 来说，这类结构清晰、需求明确的代码生成效率很高。比如让它生成一个 FastAPI 服务、一个 React 表格组件、一个价格归一化工具类，基本只需要描述输入输出，它就能给出可运行版本。

第二类任务是写数据抓取和解析脚本。AI 服务定价页通常有固定的 HTML 结构，Codex 可以快速生成针对特定站点的解析器，包括处理表格、处理 JSON 数据、处理动态加载页面。但这里要注意：目标站点一旦改版，解析脚本就会失效，需要重新让 Codex 分析页面结构并更新选择器。

第三类任务是排查报错。开发过程中最常遇到的就是环境变量没配、依赖版本冲突、接口返回格式变化。把完整报错信息直接贴给 Codex，它会给出排查路径。这一类任务消耗的 token 占比很高，因为需要把上下文反复喂给模型。

3.2 为什么 token 消耗这么高

几十亿 token 的消耗规模并不夸张，主要有几个原因。

第一，大模型辅助开发是多轮迭代过程。每次让 Codex 修改一个文件，它需要重新读取相关代码文件，生成完整补丁，然后做测试。一个项目的代码加上依赖配置、测试用例、部署脚本，上下文很容易达到数十万 token。一次功能迭代往往要跑几十轮，累计消耗就会非常大。

第二，大量 token 消耗在“尝试”上。Codex 生成第一版代码可能很快，但第一版不一定能通过编译或测试。遇到 bug 后，要么人工修改后让 Codex 继续检查，要么把错误日志再贴回去让它修复，这期间的输入输出 token 都会重复计算。

第三，边开发边做数据验证。价格数据抓回来之后，需要验证解析结果是否正确、金额单位是否统一、不同模型名称是否匹配。这些验证逻辑也会让 Codex 反复生成测试脚本，进一步推高消耗。

3.3 Codex 的边界

Codex 并不是万能工具。在这次开发中可以明显感受到，它擅长的是“把需求变成代码”，但不擅长替你做业务判断。价格归一化规则、汇率换算策略、哪些渠道应该展示、哪些渠道有安全隐患，这些业务决策必须由人来确定。Codex 生成的代码也经常出现过度设计，比如为一个简单的查询接口引入复杂的异步任务队列，这时候需要人工干预，告诉它简化实现。

如果把 Codex 当成一个效率放大器，它能帮你在一天内完成原本需要一周的重复性开发工作；如果把它当成完全自动化的开发人员，后续的维护成本可能会高于收益。

4. 价格数据模型与比价算法设计

比价网站的数据层是整个项目的地基。价格数据如果没有统一的数据结构，前端展示和后端计算都会非常混乱。

4.1 价格记录数据模型

一条价格记录至少应该包含这些字段：模型名称、供应商、计费方式、输入价格、输出价格、币种、计费单位、数据来源、更新时间。用 Python 的 dataclass 表示大概是这样：

# price_record.py 数据模型示例，实际字段以项目为准 from dataclasses import dataclass from datetime import datetime @dataclass class PriceRecord: model: str provider: str billing_type: str # subscription / pay_as_you_go / credit input_price: float output_price: float currency: str # USD / CNY unit: int # 计费粒度，通常为 1000000，表示每百万 token source_url: str updated_at: datetime extra: dict = None

设计这个模型时有三个关键点。

第一，币种必须保留。不同渠道标价可能是美元也可能是人民币，比价之前需要统一换算。汇率数据建议用定时任务更新，而不是写死在代码里。

第二，计费单位必须统一。绝大多数 API 服务按每百万 token 计费，但也有一些服务按积分或者服务额度计费。对于按积分计费的服务，需要额外存储积分和 token 的兑换比例，这个比例往往不是固定值，要平台文档明确后才能换算。

第三，模型名称要做映射。不同平台对同一个模型的命名可能不一样，比如同一类对话模型在不同服务商那里可能叫 gpt-4o、gpt-4o-2024-11-20、或者直接简写成 gpt4o。如果字符串完全匹配，就会漏掉大量可比数据，所以需要一个别名映射表。

4.2 比价计算算法

比价的核心逻辑不复杂，重点是归一化。算法流程如下：

1. 从请求中拿到模型名称和输入、输出 token 数量。
2. 在数据库中找到所有匹配该模型的价格记录。
3. 对每条记录做三件事：把价格统一换算成美元或人民币、把单位统一成每百万 token、计算指定 token 用量下的总费用。
4. 按总费用排序返回结果。

这里举一个伪代码示例：

# compare.py 比价计算逻辑示例 def normalize_price(record: PriceRecord, usd_rate: float) -> float: # 统一换算为 CNY，按每百万 token 计算 price = record.input_price if record.currency == "USD": price = price * usd_rate return price def estimate_cost(record: PriceRecord, input_tokens: int, output_tokens: int) -> float: input_cost = record.input_price * input_tokens / record.unit output_cost = record.output_price * output_tokens / record.unit return round(input_cost + output_cost, 4)

比价结果还应该包含“每百万 token 输入价”“每百万 token 输出价”“预估总费用”三个指标。只展示总费用不展示单价，用户很难判断这个差价到底来自输入还是输出，对后续成本优化没有帮助。

4.3 数据更新策略

价格数据过期比没有数据更可怕。如果官方已经调价，网站还展示旧价格，会导致用户做出错误决策。比较稳妥的更新方式是：定时抓取官方定价页生成价格快照，抓取结果先进入待确认区，由人或者规则引擎做一次校验，变化超过一定比例时触发告警。这样既不会因为单个页面解析失败导致数据为空，也不会把异常价格直接推给用户。

5. 后端 API 与批量比价

网站对外提供比价接口，是整个项目最有工程价值的部分。接口设计清晰之后，不仅 Web 前端可以调用，开发者也可以直接拿接口做自己的成本计算工具。

5.1 单次比价接口

一个比较实用的接口设计是传入模型名称和 token 预期用量，返回各渠道价格排序。

# main.py 接口示例，具体路径和参数以项目实际配置为准 from fastapi import FastAPI, Query, HTTPException from compare import estimate_cost app = FastAPI() @app.get("/api/compare") def compare( model: str = Query(..., description="模型名称"), input_tokens: int = Query(1000000, description="输入 token 数"), output_tokens: int = Query(1000000, description="输出 token 数"), currency: str = Query("CNY", description="结果币种"), ): if input_tokens <= 0 or output_tokens <= 0: raise HTTPException(status_code=400, detail="token 数据必须大于 0") # 从数据库读取该模型的各渠道价格，并调用归一化算法 results = query_and_compare(model, input_tokens, output_tokens, currency) return {"model": model, "results": results}

返回结果建议使用结构化 JSON，方便调用方解析：

{ "model": "gpt-4o", "currency": "CNY", "input_tokens": 1000000, "output_tokens": 1000000, "results": [ { "provider": "示例渠道 A", "total_cost": 45.00, "input_cost_per_million": 15.00, "output_cost_per_million": 60.00, "source_url": "https://example.com/pricing", "updated_at": "2026-01-01T12:00:00Z" } ] }

这里要强调，真实项目的接口路径和返回字段需要看项目部署后的文档，上面只是通用模板。接口层最需要注意的是参数校验，尤其是 token 数量不能为负数或零，币种必须是支持的范围，模型名称要做归一化处理。

5.2 批量比价任务

除了单次查询，比价网站还支持批量任务。批量任务的适用场景包括：用户一次导入多个模型的 token 用量清单，或者运营人员批量核对多个模型在各渠道的价格变化。

批量任务建议采用“任务提交 + 异步执行 + 结果查询”的模式。调用方提交一个包含多组模型、多组 token 用量的任务，后端返回一个任务 ID，执行完成后提供结果下载地址。这样可以避免单次请求等待时间过长，也方便失败重试。

{ "task_id": "b8f41c2a", "status": "processing", "total_items": 100, "finished_items": 37, "message": "请稍后查询结果" }

批量任务需要额外考虑幂等性。同一个任务如果重复提交，不应该产生重复的抓取或计算请求。建议在任务表中记录 source_hash，对相同参数的任务直接返回已有结果。

5.3 接口限流与缓存

免费开放的接口必须做限流，否则很容易被脚本刷爆。比较简单的方案是给每个 IP 设置每分钟请求数上限，超出后返回 429。价格数据的实时性要求没有新闻类那么高，可以加一层分钟级缓存，避免每次请求都去查数据库或抓取源站。

6. 部署与启动

6.1 环境准备

比价网站使用前后端分离结构，本地部署建议准备以下环境：

• Node.js 18+，用于前端构建和启动开发服务器。
• Python 3.10+，用于后端服务和数据抓取脚本。
• Redis 或等价缓存服务，用于接口限流和缓存。
• PostgreSQL 或 SQLite，用于保存价格记录和批量任务数据。

实际依赖要以项目 README 为准。这里只给出通用检查清单：确认 Python 和 Node 版本、确认能正常访问外网、确认目标数据库端口没有被占用。

6.2 前端构建启动

前端部分一般是标准的 Node 项目。先安装依赖，再做生产构建：

cd ai-price-compare-web npm install npm run build npm run preview -- --host 0.0.0.0 --port 3000

开发调试时可以运行npm run dev，默认会启动热更新服务，改完代码浏览器直接刷新。

6.3 后端服务启动

后端部分建议使用虚拟环境隔离依赖：

cd ai-price-compare-server python -m venv .venv source .venv/bin/activate # Windows 下为 .venv\Scripts\activate pip install -r requirements.txt uvicorn main:app --host 0.0.0.0 --port 8000

启动后访问http://127.0.0.1:8000/docs，如果能看到 Swagger 文档，说明后端服务已经跑通。

前后端联调时需要注意接口地址配置。前端开发环境一般通过 vite 或 webpack 的 proxy 把/api转发到http://127.0.0.1:8000，生产环境则通过 Nginx 做反向代理。不要把后端服务直接暴露到公网，除非你明确知道自己在做公网部署。

6.4 Docker 部署模板

如果项目提供了 Dockerfile，可以用 docker-compose 一键拉起前后端和数据库。以下是一个通用模板：

# docker-compose.yml 示例，实际服务名和端口以项目为准 version: "3" services: server: build: ./ai-price-compare-server ports: - "8000:8000" environment: - DATABASE_URL=postgresql://user:pass@db:5432/price - REDIS_URL=redis://redis:6379/0 depends_on: - db - redis web: build: ./ai-price-compare-web ports: - "3000:80" depends_on: - server db: image: postgres:15 environment: - POSTGRES_USER=user - POSTGRES_PASSWORD=pass volumes: - db_data:/var/lib/postgresql/data redis: image: redis:7 volumes: db_data:

部署到生产环境后，第一件事是检查定时抓取任务有没有真正跑起来，第二件事是确认接口限流规则生效。比价网站如果抓取任务挂掉，页面还能正常打开，但价格数据会逐渐过期。

7. 功能测试与效果验证

7.1 比价计算测试

测试的目的是确认同一个模型在不同渠道的价格排序是否正确。手动测试时先构造一组已知的价格数据，比如渠道 A 每百万 token 输入 15 元、输出 60 元，渠道 B 每百万 token 输入 12 元、输出 70 元。输入 token 100 万、输出 token 100 万时，预期结果应该是 A 总费用 75 元、B 总费用 82 元。如果排序结果和手算不一致，优先检查汇率换算和计费单位。

7.2 接口冒烟测试

后端启动后，用 curl 做接口冒烟测试：

curl "http://127.0.0.1:8000/api/compare?model=gpt-4o&input_tokens=1000000&output_tokens=1000000&currency=CNY"

判断成功的标准有三个：返回 HTTP 200、返回 JSON 中包含 results 数组、数组内每个元素包含 provider 和 total_cost 字段。如果返回 500，查看后端日志，大概率是数据库连接失败或模型名称没有匹配到数据。

7.3 批量任务测试

批量任务的测试重点不是速度，而是异常输入的处理。构造一批包含空模型名、负 token 数、超大 token 数的请求，确认后端不会因为单条数据出错而终止整个任务。合理的设计应该是把失败项标记为 failed，成功项正常返回，最终结果里附带错误原因。

7.4 价格抓取稳定性测试

价格抓取脚本需要连续运行几天来观察稳定性。常见问题是：目标站点返回 403、页面结构调整、字段缺失。建议在抓取脚本里加结构化日志，记录每次抓取的状态码、解析数量、耗时。连续运行 24 小时之后，如果日志里出现大量失败记录，就需要检查请求头或解析规则。

8. 资源占用与性能观察

比价网站本身的资源占用并不高。按照常见的小型 Web 服务规模，一个 2 核 CPU、4GB 内存的云服务器足以支撑日常访问，前提是接口加缓存、数据库查询走索引。真正的资源消耗可能来自数据抓取任务和 Codex 开发阶段的 API 费用。

观察资源占用可以从三个维度切入。

第一，抓取任务运行时 CPU 和内存的变化。比价网站的价格抓取通常也是 Python 脚本，如果采用单线程逐页请求，CPU 占用不会高；但如果同时跑多个并发抓取任务，内存占用会上升。建议设置抓取并发上限，避免把数据库连接池打满。

第二，接口响应时间。可以用time curl测量接口耗时，如果每次请求都超过 1 秒，优先检查是否缓存生效。价格数据冷启动时查询数据库慢是正常的，但要确保后续请求能命中缓存。

第三，Codex 开发阶段的资源占用。Codex CLI 是终端应用，本身对显存没有要求，主要占用的是终端进程和本地服务资源。它不像本地大模型那样烧显卡，核心成本是 API 调用费用和 token 用量。所以“烧几十亿 token”主要是 API 成本概念，不是显存占用概念。

性能调优的优先级建议是：先做接口缓存，再做数据库索引，最后才考虑加机器。比价场景的数据量通常不会大到需要分布式计算，过度设计反而会增加运维成本。

9. 常见问题与排查方法

这里特别说一下 Codex 相关的两个典型问题，因为最近搜索热度很高。第一个是unable to locate the codex cli binary，核心原因就是环境变量 PATH 没有指向 Codex 安装目录，重新安装或手动配置 PATH 就能解决，不用重装系统。第二个是登录时token exchange failed，这类提示大多是官方登录服务返回了异常状态，也可能和当前网络环境的官方支持范围有关，稳妥的做法是以官方支持状态和文档为准，避免使用非官方通道。

10. 最佳实践与合规建议

10.1 工程化实践

第一次部署比价网站，不要急着把所有模型价格都抓一遍。先挑 5 个主流模型，手工确认价格数据的准确性，再逐步扩大抓取范围。这样即使解析规则写错，影响面也有限。

价格数据要分目录管理。模型列表、价格快照、抓取日志、数据库备份分开存放，方便定位问题。建议把所有价格记录的来源 URL 存到数据库，遇到数据异常时能快速回溯。

批量任务必须加日志和失败重试。一个批次里如果有 10% 的任务失败，不能直接整批重跑。正确做法是记录失败项，单独重试失败的数据，并且给重试设置最大次数，防止死循环消耗资源。

10.2 免费服务的合规边界

官网自己就是免费服务，更要重视边界。

第一，只展示公开价格信息。不要诱导用户通过非官方渠道充值，不做代充黄牛，不提供账号共享服务。一旦涉及资金交易，责任和风险会成倍增加。

第二，不采集用户的 API Key。比价网站只需要用户输入模型名称和 token 数量，完全不需要知道用户的 Key。任何主动收集密钥的行为都应该被阻止。

第三，数据来源要标注清楚。比价结果必须附上价格来源链接和更新时间，让用户知道这个价格来自哪里、什么时候更新的。来源不明的价格数据不但没有参考价值，还可能误导用户。

第四，涉及图像、语音、视频生成类服务的比价时，要提醒用户注意版权和肖像授权。低价渠道如果存在模型来源不明、生成内容版权不清的问题，即使价格再低也不值得推荐。

10.3 token 成本核算建议

很多用户对 token 和 credit 的换算感到困惑。不同平台的积分体系完全不同，有些平台 1 credit 等于 1000 token，有些平台则按请求次数或模型等级计费，不存在一个固定的换算比例。比价网站能做的是把这些差异明确展示出来，而不是强行给出一个可能出错的换算结果。如果你是开发者，直接看 API 文档中的价格页最靠谱；如果你是普通用户，可以让比价工具辅助判断，但最终决策还是以官方信息为准。

11. 总结

这个项目最值得肯定的地方，是它把 AI 辅助开发的效率真正落地成了一个对用户免费的工具。Codex 的 token 消耗虽然大，但省下的是反复编写重复代码、处理报错、调试脚本的时间。如果你也想尝试类似的开发方式，先记住一点：AI 生成代码越爽，人工验证责任越重，代码可以让它写，业务规则必须自己定。

拿到这个项目后，最先验证的是比价算法的准确性，拿一个小模型、一套手工计算的数据去对比接口返回结果，确认无误后再看完整功能。最容易踩的坑基本集中在三个地方：Codex CLI 安装和登录配置、价格抓取脚本失效、汇率换算错误。这三个问题解决了，整个项目就能稳定跑起来。

后续可以扩展的方向也不少，比如增加价格变动提醒、支持更多模型别名映射、开放历史价格趋势接口。比价类工具的价值会随着数据积累越来越大，价格更新越及时，对用户的参考意义就越强。这篇就到这里，建议收藏备用，下次选 AI 套餐或者做 token 预算的时候可以直接拿来比对。