企业官网建设流程全解析

1. 为什么我要做这个比价目录

国内大模型这两年卷得厉害，几乎每个月都有新模型发布、老模型降价、套餐规则调整。我自己在做几个 AI 应用，需要同时对接好几家厂商的 API，结果每次做成本核算都得重新翻一遍官网，把价格表截图、复制到表格里，再手动算一遍。最头疼的是，各家定价维度完全不一样——有按 token 计费的，有按调用次数计费的，有预付费资源包的，还有订阅制会员的，甚至同一个模型在高峰期和低峰期价格都能差好几倍。

这种混乱状态下，我踩过不少坑。有一次给客户做预算，按某家官网首页写的"输入 0.001 元/千 token"算了一版，结果实际跑下来账单翻了三倍，仔细一看才发现那个价格只适用于特定上下文长度区间，超过之后单价直接跳档。还有一次买了某家的订阅套餐，以为额度是通用的，结果发现不同模型的消耗倍率不一样，贵的模型跑几次就把额度吃光了。

所以我就想，能不能做一个比价目录，把各家大模型 API 和订阅套餐的价格规则按官网原样建模，不做任何简化或近似，让用户能直接对比、直接算账。这个项目的核心不是"便宜"或者"推荐"，而是准确还原规则——官网怎么写，我就怎么建模，包括那些藏在脚注里、折叠面板里、甚至需要点开"查看详情"才能看到的细则。

这个目录适合几类人：一是像我这样需要做成本核算的开发者；二是正在选型、想知道不同厂商价格差异的产品经理；三是做 AI 应用创业、需要控制推理成本的团队。哪怕你只是好奇"DeepSeek 和智谱到底谁便宜"，这个目录也能给你一个基于真实规则的答案，而不是营销话术。

2. 价格规则建模的核心难点

2.1 为什么不能简单做个价格表

很多人第一反应是：不就是把各家价格抄到一个表格里吗？我一开始也这么想，后来发现完全行不通。原因在于，大模型 API 的定价不是一个单一数字，而是一个多维度的规则系统。

举个最典型的例子，某家厂商的输入价格是这样描述的："输入 0.001 元/千 token（0-32K），0.002 元/千 token（32K-128K），0.004 元/千 token（128K 以上）"。这还只是输入，输出价格又是另一套阶梯。如果你只记一个"0.001 元/千 token"，那超过 32K 的请求成本就完全算错了。

再比如订阅套餐，某家写的是"每月 19 元，包含 100 万 token 额度，不同模型消耗倍率不同，其中 A 模型 1 倍、B 模型 2 倍、C 模型 5 倍"。这意味着你实际能用的 token 数取决于你用什么模型，而不是固定的 100 万。如果只记"19 元 100 万 token"，那用 C 模型的时候实际只有 20 万 token 可用。

所以我的建模思路是：把价格规则拆解成结构化的维度，每个维度对应官网上的一个明确说明，不做任何合并或近似。

2.2 我定义的规则维度

经过反复调整，我最终确定了这么几个核心维度：

这个维度表是我踩了很多坑之后才定下来的。一开始我只记了输入输出价格，结果发现订阅制的倍率完全没法体现；后来加了倍率，又发现资源包的有效期也很关键——有些资源包 30 天过期，有些 90 天，有些永久有效，这直接影响你的采购决策。

2.3 按官网原样建模的具体做法

"按官网原样建模"这句话说起来简单，做起来需要很强的自律。因为你在整理的过程中，很容易不自觉地"优化"——比如把两个相似的阶梯合并，或者把某个不常用的限制条件省略掉。但一旦这么做，目录的准确性就打折扣了。

我的做法是：每个价格字段都必须能追溯到官网原文。具体来说，我在数据库里给每个价格记录都加了一个source_note字段，记录这个价格是从官网哪个位置、哪段文字提取的。比如：

{ "model": "某模型", "billing_mode": "按量付费", "input_price": 0.001, "input_unit": "元/千 token", "input_tier": "0-32K", "output_price": 0.002, "output_unit": "元/千 token", "output_tier": "0-32K", "source_note": "官网定价页，输入价格表格第 2 行，折叠面板'阶梯定价'展开后可见" }

这样做的好处是，当官网价格调整时，我能快速定位到需要更新的字段，而不是重新翻一遍整个页面。另外，当用户质疑某个价格时，我也能直接给出出处，而不是含糊地说"我记得是这样"。

提示：如果你也想做类似的比价工具，强烈建议保留 source_note。我一开始没加，后来官网改版，我完全不知道哪些价格需要重新核对，只能全部重来一遍。

3. 各家厂商价格规则拆解实录

3.1 按量付费的阶梯陷阱

按量付费是最常见的模式，但阶梯规则是最容易算错的地方。我拿几个典型厂商举例说明。

某厂商的定价页面上，输入价格写的是"0.001 元/千 token"，看起来很简单。但如果你点开旁边的"查看详情"，会发现实际规则是：

• 0-32K 上下文：0.001 元/千 token
• 32K-128K 上下文：0.002 元/千 token
• 128K 以上：0.004 元/千 token

这里的"上下文"指的是单次请求的输入 token 数。也就是说，如果你一次请求发了 40K token，那这 40K 全部按 0.002 元/千 token 计费，而不是前 32K 按 0.001、后 8K 按 0.002。这个细节很多开发者会搞错，我一开始也以为是分段累进，后来仔细看官网说明才发现是整单跳档。

输出价格也是类似的阶梯，但阶梯边界可能和输入不一样。有些厂商输入和输出的阶梯边界一致，有些则不同。比如某家输入是 32K 跳档，输出是 16K 跳档。这种不对称的规则，如果不仔细看，很容易算错。

我在建模时，对每个阶梯都单独记录，并且明确标注是"整单跳档"还是"分段累进"。这个区分对成本核算影响很大。

3.2 订阅套餐的倍率迷宫

订阅套餐是另一个重灾区。表面上看，各家都是"每月 X 元，包含 Y 额度"，但实际规则差异巨大。

某家的订阅套餐是这样的：每月 19 元，包含 100 万 token 额度。但不同模型有不同的消耗倍率：

这意味着，如果你主要用高级模型，19 元实际只能跑 20 万 token，而不是 100 万。如果只看"19 元 100 万 token"这个宣传语，实际成本可能比按量付费还贵。

另一家的订阅套餐更复杂：每月 39 元，包含 200 万 token 额度，但额度分"通用额度"和"高级额度"两种。通用额度可以用于所有模型，高级额度只能用于特定模型。而且通用额度和高级额度的有效期还不一样，通用额度当月有效，高级额度可以累积三个月。

这种规则如果不拆解清楚，用户根本没法对比。我在目录里把每个订阅套餐都拆成"基础额度 + 倍率规则 + 有效期 + 适用范围"四个部分，让用户能一眼看出实际成本。

3.3 资源包的隐藏限制

资源包是预付费模式，通常比按量付费便宜，但限制也更多。我整理时发现几个常见的隐藏限制：

• 有效期：有些资源包 30 天过期，有些 90 天，有些永久有效。30 天过期的资源包，如果你用不完，剩余额度就浪费了。
• 适用范围：有些资源包只能用于特定模型，有些可以用于所有模型。
• 并发限制：有些资源包会限制并发数，比如最多 10 并发，超过就需要排队。
• 退款规则：有些资源包不支持退款，有些支持按比例退款。

这些限制在官网通常不会放在显眼位置，而是藏在"购买须知"或"服务条款"里。我在建模时，会专门花时间把这些细则找出来，记录到restrictions字段里。

注意：资源包的"便宜"是有条件的。如果你用量不稳定，或者主要用高级模型，资源包可能反而不划算。我在目录里加了一个简单的计算器，输入你的预估用量和模型分布，就能算出哪种模式最省钱。

4. 比价目录的技术实现

4.1 数据结构设计

整个目录的核心是一个结构化的价格数据库。我用的是 JSON 格式，因为灵活、易读、方便版本管理。每条记录的结构大致如下：

{ "provider": "厂商名称", "model": "模型名称", "billing_mode": "按量付费 | 订阅制 | 资源包", "currency": "CNY", "input": { "price": 0.001, "unit": "元/千 token", "tiers": [ {"range": "0-32K", "price": 0.001}, {"range": "32K-128K", "price": 0.002}, {"range": "128K+", "price": 0.004} ], "tier_type": "整单跳档" }, "output": { "price": 0.002, "unit": "元/千 token", "tiers": [ {"range": "0-16K", "price": 0.002}, {"range": "16K+", "price": 0.004} ], "tier_type": "整单跳档" }, "subscription": { "monthly_fee": 19, "included_tokens": 1000000, "model_multipliers": { "轻量模型": 1, "标准模型": 2, "高级模型": 5 }, "validity": "当月有效" }, "free_tier": { "available": true, "description": "新用户赠送 100 万 token，有效期 30 天" }, "restrictions": { "max_context": 128000, "max_concurrency": 10, "qps": 5 }, "source_note": "官网定价页，2025-01 更新", "last_updated": "2025-01-15" }

这个结构的好处是，既能表达简单的按量付费，也能表达复杂的订阅制。tiers数组支持任意数量的阶梯，tier_type区分整单跳档和分段累进，model_multipliers处理订阅制的倍率问题。

4.2 价格计算逻辑

有了数据结构，下一步是实现价格计算。这部分逻辑不复杂，但细节很多。我以按量付费为例说明：

def calculate_cost(model_config, input_tokens, output_tokens): # 计算输入成本 input_cost = 0 if model_config['input']['tier_type'] == '整单跳档': # 找到输入 token 数落在哪个阶梯 for tier in model_config['input']['tiers']: if input_tokens <= tier['max']: input_cost = input_tokens / 1000 * tier['price'] break elif model_config['input']['tier_type'] == '分段累进': # 分段累进：每个阶梯单独计算 remaining = input_tokens prev_max = 0 for tier in model_config['input']['tiers']: tier_tokens = min(remaining, tier['max'] - prev_max) if tier_tokens <= 0: break input_cost += tier_tokens / 1000 * tier['price'] remaining -= tier_tokens prev_max = tier['max'] # 输出成本同理 output_cost = 0 # ... 类似逻辑 return input_cost + output_cost

这段代码的关键是区分"整单跳档"和"分段累进"。我一开始只实现了整单跳档，后来发现有些厂商是分段累进，不得不重构。所以如果你也要做类似工具，建议一开始就把这两种模式都考虑进去。

订阅制的计算更复杂一些，需要先根据模型倍率折算实际消耗的额度，再判断是否超出套餐额度，超出部分按什么价格计费。这部分我单独写了一个模块，逻辑是：

1. 根据模型倍率，计算实际消耗额度 = token 数 × 倍率
2. 如果实际消耗额度 ≤ 套餐额度，成本 = 月费
3. 如果超出，超出部分按按量付费价格计算，加上月费

这个逻辑看起来简单，但实际实现时要注意：有些套餐超出后直接停止服务，有些会自动转为按量付费，有些需要手动购买额外额度。这些差异我都记录在overage_policy字段里。

4.3 数据更新与版本管理

价格数据是会变的。我遇到过好几次官网悄悄调价，没有任何公告。所以数据更新是个持续的工作。

我的做法是：

• 每周固定时间检查各家官网定价页，对比是否有变化
• 每次更新都记录版本号，保留历史版本
• 在目录页面上显示"最后更新时间"，让用户知道数据的新旧程度

版本管理我用的是 Git，每次更新提交一个 commit，commit message 写清楚改了哪些厂商、哪些模型、哪些字段。这样如果发现某个价格有问题，可以快速回滚或追溯。

提示：不要依赖官网的"价格调整公告"。我统计过，至少有一半的调价是没有公告的，只能靠定期检查发现。

5. 常见问题与排查技巧

5.1 价格对不上怎么办

这是最常见的问题。用户拿着目录里的价格去官网核对，发现不一致。原因通常有几种：

我自己的经验是，价格对不上时，先别急着改数据，而是去官网把相关页面完整看一遍，包括折叠面板、脚注、FAQ。很多时候问题就藏在这些地方。

5.2 阶梯边界怎么处理

阶梯边界是最容易出错的地方。比如"0-32K"这个区间，32K 到底算哪一档？是算 0-32K 这一档，还是算 32K-128K 这一档？

我的处理方式是：严格按照官网的表述。如果官网写"0-32K"和"32K-128K"，那 32K 就归入 0-32K 这一档（因为 0-32K 包含 32K）。如果官网写"0-32K"和"32K 以上"，那 32K 就归入 32K 以上这一档。

这个细节看起来很小，但在大批量调用时，影响可能不小。我在目录里对每个阶梯都明确标注了边界归属，避免歧义。

5.3 免费额度怎么算

免费额度是另一个容易混淆的地方。有些厂商的免费额度是"每月赠送"，有些是"新用户一次性赠送"，有些是"每日赠送"。而且免费额度通常有有效期，过期作废。

我在目录里把免费额度单独列出来，标注清楚：

• 赠送方式：每月 / 一次性 / 每日
• 额度数量：多少 token 或多少次调用
• 有效期：多少天
• 适用范围：哪些模型可用

这样用户就能清楚知道，免费额度到底能省多少钱，以及什么时候会用完。

5.4 并发和 QPS 限制

并发和 QPS 限制虽然不直接影响价格，但会影响实际使用体验。有些厂商的低价套餐会限制并发数，比如最多 5 并发，超过就需要排队。如果你的应用需要高并发，那这个限制可能比价格更重要。

我在目录里把并发和 QPS 限制也记录进去，让用户能综合评估。毕竟，便宜但用不了，等于不便宜。

6. 我踩过的坑和实操心得

做这个目录的过程中，我踩了不少坑，这里分享几个最有代表性的。

第一个坑是过度简化。一开始我觉得阶梯定价太复杂，就只记了最低档的价格，想着"反正大部分请求都在最低档"。结果有用户反馈说，他的请求经常超过 32K，实际成本比目录里显示的高很多。后来我不得不把所有阶梯都补上，工作量翻了好几倍。所以我的建议是：一开始就按完整规则建模，不要想着先简化再补充。

第二个坑是忽略有效期。我一开始只记了资源包的价格和额度，没记有效期。后来发现有些资源包 30 天过期，用户买完用不完就浪费了。这个信息对采购决策很重要，我后来专门加了一个validity字段。

第三个坑是模型名称不一致。不同厂商对同一个模型的命名可能不一样，比如有的叫"某模型-128K"，有的叫"某模型-long"，有的叫"某模型-2025-01"。我在目录里统一用模型 ID 作为主键，同时记录各厂商的别名，避免混淆。

第四个坑是官网改版。有一次某厂商官网改版，定价页的 URL 变了，我的爬虫直接失效。后来我改成手动检查 + 半自动更新，虽然效率低一点，但更可靠。毕竟价格数据准确性是第一位的，效率可以牺牲。

提示：如果你也想做类似工具，建议不要完全依赖爬虫。官网结构随时可能变，手动检查虽然慢，但能发现很多爬虫发现不了的细节，比如折叠面板里的隐藏规则。

最后分享一个实用技巧：我在目录里加了一个"成本模拟器"，用户可以输入预估的月调用量、输入输出比例、模型分布，然后自动算出不同厂商、不同计费模式下的月成本。这个功能比单纯的价格表更实用，因为很多人其实不知道自己一个月会用多少 token，模拟器能帮他们建立直观感受。

这个目录我还在持续维护，每次官网调价都会更新。虽然工作量不小，但看到用户反馈说"帮我省了不少钱"或者"终于搞清楚哪家便宜了"，就觉得值得。如果你也在做类似的事情，欢迎交流，尤其是如果你发现了什么隐藏的价格规则，那正是我最感兴趣的部分。