企业官网建设流程全解析

1. 这个比价目录到底解决了什么问题

国内大模型这两年的价格战打得比菜市场还热闹。我去年帮公司做技术选型的时候，光是整理各家 API 的计费规则就花掉了整整三天——不是查不到价格，而是查到了也看不懂。DeepSeek 的缓存命中怎么算、通义千问的阶梯计费从哪一档开始跳、智谱的套餐包和按量付费哪个更划算、Kimi 的上下文长度超了之后单价怎么变，这些信息散落在各个官网的定价页、文档角落、甚至更新公告里，格式还都不一样。有的用表格，有的用文字描述，有的把"输入"和"输出"分开列，有的把"缓存"单独拎出来算一档。

更麻烦的是，这些价格规则不是静态的。几乎每个月都有厂商调价、出新套餐、改计费粒度。你上周算好的成本模型，这周可能就失效了。我试过用 Excel 手动维护，结果维护到第三周就放弃了——不是懒，是实在跟不上变化的速度。

所以当我看到有人做了一个"国内大模型 API 和订阅套餐的比价目录，价格规则按官网原样建模"的时候，第一反应是：这东西要是做得靠谱，能省掉技术选型阶段至少一半的扯皮时间。它的核心价值不在于"比价"这个动作本身，而在于把非结构化的价格规则翻译成可计算、可对比、可追溯的结构化模型。这跟普通的"价格汇总表"有本质区别——汇总表只告诉你"多少钱"，而这个目录告诉你"在什么条件下、按什么规则、算出来多少钱"。

这个项目适合谁用？三类人最刚需：一是做技术选型和成本预算的架构师或技术负责人，需要快速估算不同方案的年化成本；二是独立开发者或小团队，预算敏感，需要在免费额度、低价档位和性能之间找平衡；三是做 AI 应用层产品的团队，API 成本直接决定毛利，需要持续监控价格变化并动态调整路由策略。

2. 价格规则建模的核心思路拆解

2.1 为什么不能只做一张价格对比表

很多人第一反应是：不就是把各家价格列出来吗，一张 Excel 就够了。我一开始也这么想，直到我真正动手算了一次某项目的月度成本。假设你有一个应用，日均调用 50 万次，平均输入 800 token，平均输出 400 token，其中 30% 的请求命中缓存。这时候你会发现，不同厂商的计费维度完全不在一个层面上：

• 有的厂商输入和输出统一定价，有的分开定价，输出通常是输入的 2 到 4 倍；
• 缓存命中的折扣力度从 5 折到 1 折不等，有的甚至免费；
• 阶梯计费有的按月累计用量跳档，有的按单次请求量跳档；
• 套餐包有的是"预付费买 token 包"，有的是"包月不限量但限并发"，有的是"包月送一定额度超出另算"。

你把这些规则硬塞进一张表里，结果就是列数爆炸、行数爆炸，而且每加一个厂商就要重新调整表结构。更致命的是，你没法用这张表做自动化计算——每次算成本都要人工判断"这个请求落在哪个档位"。

所以这个比价目录的核心设计决策是：把价格规则抽象成"计费维度 + 计费单元 + 阶梯规则 + 约束条件"的四元组模型。每个厂商的每个模型，都用这四元组来描述，而不是用一张扁平的表。这样做的好处是，计算逻辑和展示逻辑分离——展示层可以渲染成表格，计算层可以用同一套代码跑所有厂商的成本估算。

2.2 计费维度怎么拆才合理

我见过一些比价工具把计费维度拆得很粗，只分"输入"和"输出"两档。这在早期够用，但现在完全不够。国内主流厂商的计费维度至少包括以下几类：

这个目录的做法是：每个维度独立建模，但允许厂商配置"哪些维度合并计费"。比如某厂商把思考过程 token 计入输出 token，那就在配置里标记为合并；另一厂商单独计价，就拆成两个维度。这样既保证了灵活性，又不会让展示层变得过于复杂。

2.3 阶梯规则的建模难点

阶梯计费是比价里最容易踩坑的地方。我举个例子：某厂商的定价是"月累计用量 0-100 万 token 按 0.008 元/千 token，100 万-500 万按 0.006 元/千 token，500 万以上按 0.004 元/千 token"。这看起来简单，但实际计算时有几个关键问题：

第一，阶梯是"全额累进"还是"超额累进"？全额累进是指一旦超过 100 万，所有用量都按 0.006 算；超额累进是指前 100 万仍按 0.008 算，超出部分按 0.006 算。这两种算法的结果差异巨大，而很多厂商的文档里并没有写清楚，需要从计费示例里反推。

第二，阶梯的累计周期是什么？是按自然月、按账单周期、还是按合同周期？有的厂商按月重置，有的按季度，有的按年。这个信息直接影响成本估算的时间粒度。

第三，阶梯是否跨模型共享？有的厂商所有模型共享一个月度累计额度，有的每个模型独立累计。这决定了你多模型混用时的实际单价。

这个目录的建模方式是：每个阶梯规则显式标注"累进类型"和"累计周期"，并在计算引擎里实现两种累进算法。我实测下来，超额累进是更常见的做法，但全额累进在某些厂商的套餐包里也会出现，所以两种都得支持。

3. 核心细节解析与实操要点

3.1 数据采集：怎么从官网"原样"提取规则

"按官网原样建模"这句话说起来简单，做起来极其繁琐。我自己的经验是，一个厂商的定价页通常包含以下信息源，而且它们之间可能互相矛盾：

• 定价页的主表格：通常是最新的标准价格，但可能不包含套餐包和优惠活动；
• 文档里的计费说明：有时比定价页更详细，包含阶梯规则和计费示例；
• 控制台的计费预览：最准确，但需要登录且不一定对所有用户开放；
• 更新公告：调价时发布，但旧公告可能没有及时归档。

这个目录的采集策略是：以定价页为主，以文档计费说明为辅，以计费示例为校验。具体操作时，我建议按以下步骤走：

1. 先截取定价页的完整表格，包括所有脚注和小字说明。很多关键约束（比如"缓存命中仅限特定模型"）都藏在脚注里。
2. 在文档里搜索"计费"、"价格"、"阶梯"、"缓存"等关键词，找到计费说明章节。
3. 如果文档里有计费示例，用示例数据反推规则，验证是否与定价页一致。
4. 把提取到的规则填入四元组模型，标注数据来源和采集日期。

注意：厂商调价频繁，建议每次采集都记录时间戳，并在展示层标注"价格最后更新于 X 年 X 月 X 日"。我踩过的坑是，有一次用了一个月前的数据做预算，结果厂商已经调价了，预算偏差超过 20%。

3.2 套餐包的建模：比按量付费复杂三倍

订阅套餐的建模难度远高于按量付费。按量付费的核心是"单价 × 用量"，套餐包则涉及"预付费金额、包含额度、超出单价、有效期、并发限制、模型范围"等多个参数。我整理了一下，国内常见的套餐包至少有以下几种形态：

这个目录的做法是：把套餐包也抽象成"计费规则 + 约束条件"的组合，而不是单独建一套模型。比如"包月套餐"可以表示为"固定费用 + 包含额度 + 超出部分按某单价计费"，这跟按量付费的阶梯规则在计算逻辑上是同构的，只是多了一个"固定费用"项。

3.3 计算引擎：怎么保证算出来的价格可信

比价目录最核心的功能是成本估算，而成本估算的可信度取决于计算引擎的准确性。这个目录的计算引擎设计有几个关键点：

第一，输入参数标准化。用户输入的用量数据（输入 token 数、输出 token 数、缓存命中率等）需要统一单位，避免"千 token"和"百万 token"混用导致的错误。我建议统一用"token"作为基础单位，展示时再换算。

第二，计算过程可追溯。每次估算都要输出中间结果，比如"输入费用 = 输入 token 数 × 输入单价 = X 元"、"缓存折扣 = 缓存命中 token 数 × 输入单价 × 折扣率 = Y 元"。这样用户能看懂钱花在哪了，也方便排查异常。

第三，边界条件显式处理。比如用量为 0 时、缓存命中率为 100% 时、超出套餐额度时，这些边界情况要有明确的处理逻辑，不能靠默认值蒙混过关。

我实测下来，一个可靠的估算引擎至少需要以下输入参数：

# 成本估算输入参数示例 estimate_params = { "input_tokens": 800, # 单次请求平均输入 token "output_tokens": 400, # 单次请求平均输出 token "cache_hit_rate": 0.3, # 缓存命中率 "daily_requests": 500000, # 日均请求数 "monthly_days": 30, # 月计费天数 "model_name": "deepseek-chat", # 模型名称 "provider": "deepseek" # 厂商 }

计算引擎根据这些参数，结合厂商的价格规则，输出月度成本估算和费用明细。这个过程中，阶梯规则的累进计算是最容易出错的地方，建议单独写单元测试覆盖。

4. 实操过程与核心环节实现

4.1 从零搭建比价目录的完整流程

如果你也想自己搭一个类似的比价目录，我把自己走过的流程整理一下，供参考。整个项目可以拆成五个阶段：数据采集、规则建模、计算引擎、展示层、维护机制。

第一阶段：数据采集。先确定要覆盖的厂商和模型范围。我的建议是不要贪多，先覆盖 5 到 8 家主流厂商的核心模型，把规则跑通再扩展。采集时用统一的模板记录信息，包括厂商名称、模型名称、计费维度、单价、阶梯规则、套餐信息、数据来源、采集日期。这个模板可以用 YAML 或 JSON 存储，方便后续程序读取。

第二阶段：规则建模。把采集到的数据翻译成四元组模型。这一步的关键是定义好 schema，确保不同厂商的规则能用同一套结构描述。我用的 schema 大致如下：

# 价格规则 schema 示例 provider: deepseek model: deepseek-chat billing_dimensions: - name: input unit: per_1k_tokens price: 0.001 - name: output unit: per_1k_tokens price: 0.002 - name: cache_hit_input unit: per_1k_tokens price: 0.0001 condition: "cache_hit == true" tiers: - min_tokens: 0 max_tokens: 1000000 multiplier: 1.0 - min_tokens: 1000000 max_tokens: 5000000 multiplier: 0.75 - min_tokens: 5000000 max_tokens: null multiplier: 0.5 tier_type: progressive # progressive 超额累进 / flat 全额累进 billing_cycle: monthly source: "https://example.com/pricing" collected_at: "2025-01-15"

第三阶段：计算引擎。用 Python 或 TypeScript 实现计算逻辑。核心函数包括：单次请求成本计算、月度成本估算、套餐包对比、阶梯累进计算。我建议把计算逻辑写成纯函数，输入参数和价格规则，输出费用明细，方便测试和复用。

第四阶段：展示层。展示层可以是一个静态网页、一个 CLI 工具、或者一个 API 服务。我倾向于先做 CLI，因为开发快、调试方便，等规则稳定了再做网页。展示时重点突出"同等用量下的成本对比"和"不同用量下的最优选择"，而不是简单罗列单价。

第五阶段：维护机制。这是最容易被忽视但最重要的环节。价格会变，规则会变，模型会下架。我建议建立一个简单的维护流程：每月固定时间检查各厂商定价页，发现变化就更新数据，并在展示层标注变更记录。如果可能的话，用脚本自动抓取定价页并对比差异，能省不少人工。

4.2 一个完整的成本估算实例

光说流程可能还是抽象，我拿一个具体场景走一遍。假设你有一个客服机器人应用，日均请求 30 万次，平均输入 600 token，平均输出 300 token，缓存命中率 25%，想对比 DeepSeek、通义千问和智谱三家的月度成本。

第一步，整理三家的价格规则。这里我简化一下，只列核心维度：

第二步，计算月度 token 用量。日均请求 30 万次，月按 30 天算，总请求数 900 万次。输入 token 总量 = 900 万 × 600 = 54 亿 token。输出 token 总量 = 900 万 × 300 = 27 亿 token。缓存命中输入 token = 54 亿 × 25% = 13.5 亿 token，未命中输入 token = 40.5 亿 token。

第三步，按各家规则计算费用。以 DeepSeek 为例，假设月累计用量落在第二档（100 万到 500 万 token 区间，这里用量远超，实际会落到最高档），超额累进计算：

• 未命中输入费用：40.5 亿 token = 405 万千 token，按阶梯累进计算；
• 缓存命中输入费用：13.5 亿 token = 135 万千 token，按 1 折计算；
• 输出费用：27 亿 token = 270 万千 token，按输出单价计算。

具体计算过程略复杂，但计算引擎会自动处理。最终结果会输出一个费用明细表，让你清楚看到每一部分的成本占比。

提示：实际估算时，阶梯规则的累进计算建议用代码实现，手工算容易出错。我试过手工算一次，结果因为把"全额累进"和"超额累进"搞混了，偏差超过 30%。

4.3 套餐包对比的实现要点

套餐包对比比按量付费对比更复杂，因为涉及"预付费"和"用量不确定性"。这个目录的做法是：用"盈亏平衡点"来对比套餐包和按量付费。具体来说，对于每个套餐包，计算"在什么用量下，套餐包比按量付费更划算"，以及"在什么用量下，套餐包会浪费钱"。

举个例子：某厂商的包月套餐是 500 元/月，含 1000 万 token，超出部分按 0.002 元/千 token 计费。按量付费是 0.003 元/千 token。那么盈亏平衡点是：500 / 0.003 = 16.67 万千 token，也就是约 1.67 亿 token。如果你的月用量低于 1.67 亿 token，按量付费更划算；高于这个值，套餐包更划算。但还要考虑套餐包含的 1000 万 token 是否能用完——如果用不完，实际单价会更高。

这个目录会在展示层直接给出"推荐方案"和"盈亏平衡点"，而不是让用户自己算。我实测下来，这个功能对预算敏感的小团队特别有用。

5. 常见问题与排查技巧实录

5.1 价格规则理解偏差的典型场景

做比价目录最大的坑不是技术实现，而是对价格规则的理解偏差。我整理了几个自己踩过的坑，以及排查方法：

我遇到最坑的一次是某厂商的"缓存命中"定义——它要求请求的 prefix 完全一致才算命中，而不是语义相似就算。这个细节在定价页里只提了一句，藏在脚注里。结果我按 50% 命中率估算，实际只有 10%，成本偏差巨大。所以采集数据时一定要把脚注和小字说明看全，这是血泪教训。

5.2 数据更新与版本管理

价格数据会变，这是比价目录最大的维护挑战。我的做法是：每次更新都保留历史版本，并在展示层提供"价格变更记录"。这样用户能看到某个厂商什么时候调过价、调了多少，而不是只看到当前价格。

具体实现上，可以用 Git 管理数据文件，每次更新提交一个 commit，commit message 写清楚变更内容。展示层读取当前版本和历史版本，渲染变更记录。这个做法简单有效，我用了半年多，没出过问题。

注意：不要覆盖旧数据，一定要保留历史版本。我有一次偷懒直接覆盖了，结果用户问"上个月的价格是多少"时答不上来，很尴尬。

5.3 计算引擎的测试策略

计算引擎的准确性是比价目录的生命线。我建议用以下策略保证准确性：

第一，单元测试覆盖所有计费维度。每个维度单独测试，确保单价计算正确。第二，集成测试覆盖典型场景。用真实账单数据反推，验证估算结果与账单一致。第三，边界测试覆盖极端情况。用量为 0、用量极大、缓存命中率 100%、套餐额度刚好用完等边界情况都要测试。

我自己的做法是，每接入一个新厂商，先用它的计费示例跑一遍，确认结果一致后再上线。这个步骤不能省，我试过跳过，结果上线后发现某厂商的阶梯规则理解错了，不得不紧急修复。

5.4 展示层的用户体验要点

比价目录的展示层不需要花哨，但有几个要点必须做到：

• 同等用量对比：不要只列单价，要按用户的实际用量估算总成本，这样才有可比性；
• 费用明细可展开：用户能点开看每一部分的费用构成，而不是只看到一个总数；
• 数据来源可追溯：每个价格都标注来源链接和采集日期，方便用户核实；
• 变更记录可查看：价格调过几次、每次调多少，一目了然；
• 推荐方案要谨慎：不要轻易说"某厂商最便宜"，因为不同用量下最优选择不同，应该给出"在你的用量下，推荐 X 方案"。

我见过一些比价工具直接给一个"性价比排名"，这其实误导性很强。因为性价比取决于用量、模型能力、稳定性、生态等多个因素，单纯按价格排名没有意义。这个目录的做法是只做成本估算，不做综合排名，把选择权交给用户。

6. 这个目录后续可以怎么扩展

做了一段时间之后，我发现这个比价目录的价值远不止"比价"。它其实是一个大模型成本知识库，可以往几个方向扩展。

第一个方向是成本优化建议。基于用户的用量特征，给出具体的优化建议，比如"你的缓存命中率只有 10%，如果提升到 30%，月度成本可以降低 X 元"、"你的输出 token 占比过高，建议优化 prompt 减少输出长度"。这些建议比单纯的价格对比更有价值。

第二个方向是动态路由策略。根据实时价格和用户用量，自动推荐或切换最优模型。比如简单任务用便宜模型，复杂任务用贵模型，缓存命中率高的请求走支持缓存的厂商。这个方向技术难度较高，但价值也最大。

第三个方向是价格预警。当某厂商调价时，自动通知用户，并估算对用户成本的影响。这个功能对长期使用某厂商的用户特别有用。

我自己在实际操作中的体会是，比价目录的核心竞争力不在于覆盖多少厂商，而在于价格规则的准确性和更新速度。覆盖 20 家但规则经常出错，不如覆盖 8 家但规则准确、更新及时。这个项目如果能把"按官网原样建模"这件事做到极致，就已经很有价值了。