企业官网建设流程全解析

1. 一个估值神话背后的真实选择

Anthropic 估值冲上 4 万亿的消息，在圈子里刷屏那几天，我正好在帮一家做跨境电商 SaaS 的朋友做模型成本优化。他们的技术负责人给我看了上个月的账单：Claude 系列模型的 API 调用费用占了整个 AI 预算的六成多，而实际业务里真正需要顶级推理能力的请求，连两成都不到。剩下的那些客服自动回复、商品描述生成、评论情感分类，用便宜模型跑出来的效果，业务方根本看不出差别。

这个场景不是个例。过去半年，我接触过的十几个中小团队里，有做法律文书辅助的，有做教育题库解析的，也有做智能客服的，几乎都在做同一件事：把原本一股脑丢给 Claude 的请求，拆开来重新分配。贵的模型只留给真正需要它的任务，其余的走便宜路线。这不是对 Anthropic 的背叛，而是工程团队在成本压力下最理性的选择。

标题里说的“企业客户已经偷偷换了便宜模型”，这个“偷偷”用得很传神。不是大张旗鼓地宣布迁移，而是在架构层面悄悄加了一层路由，把流量慢慢导走。等 Anthropic 的销售团队发现调用量增长放缓的时候，技术团队早就把成本结构优化完了。这篇文章，我就把这套“模型路由”的实操思路拆开来讲，从为什么要做、怎么选模型、路由层怎么设计，到实际踩过的坑，全部摊开说清楚。不管你是刚接触 API 调用的新手，还是已经在管 AI 预算的负责人，都能从中找到可以直接抄作业的部分。

2. 为什么企业客户开始“用脚投票”

2.1 顶级模型的成本结构到底贵在哪

先算一笔账。Claude 系列里定位最高的模型，输入 token 的价格大约是每百万 token 十五美元，输出是每百万 token 七十五美元。而 DeepSeek 的 V3 系列，输入价格在缓存命中时能低到每百万 token 零点几美元，输出也就几美元的量级。这个差距不是百分之几十，是几十倍。

我拿一个真实的客服场景来算。假设一家中等规模的电商平台，每天有十万条用户咨询需要 AI 处理，平均每条咨询的输入是两百 token，输出是一百五十 token。如果全部走 Claude 顶级模型，一天的输入成本是十万乘以两百除以一百万再乘以十五，等于三百美元；输出成本是十万乘以一百五十除以一百万再乘以七十五，等于一千一百二十五美元。加起来一天一千四百多美元，一个月就是四万多美元。

同样的量走 DeepSeek，输入成本按缓存命中算，十万乘以两百除以一百万再乘以零点零七，等于一点四美元；输出按每百万 token 两美元算，十万乘以一百五十除以一百万再乘以二，等于三美元。一天不到五美元，一个月一百多美元。这个差距，任何一个对成本敏感的团队负责人看了都会心动。

注意：这里说的“便宜模型”不是指质量差，而是在特定任务上性价比极高的模型。DeepSeek 在中文理解、常规问答、文本分类这些任务上，表现已经足够好，和顶级模型的差距在业务可接受范围内。

2.2 企业真正在意的不是模型排名而是单位经济模型

很多技术团队在选型的时候容易陷入一个误区：盯着各种评测榜单，看谁的分数高就用谁。但企业客户，尤其是已经过了概念验证阶段、进入规模化部署的团队，关心的根本不是模型在某个学术榜单上排第几，而是每处理一个业务请求，成本是多少，转化率是多少，用户满意度有没有下降。

我那个做法律文书辅助的朋友给我看过一组数据。他们用 Claude 顶级模型做合同条款风险识别，准确率是百分之九十二；换成 DeepSeek 之后，准确率降到百分之八十七。看起来降了五个百分点，但他们的业务场景里，AI 只是做初筛，最终还是要人工复核。这五个百分点的差距，在人工复核环节被完全抹平了，而成本降了百分之九十以上。对他们来说，这个交换太划算了。

这就是单位经济模型的思维方式：不追求单点最优，追求整体投入产出比最优。当你的业务量足够大的时候，模型调用成本会从“技术开销”变成“核心成本项”，这时候每一分钱都要花在刀刃上。

2.3 模型路由成为架构标配的必然性

一开始，大家是手动切换的。今天觉得贵了，就把某个服务的模型换掉，改改配置文件，重新部署。但业务一复杂，这种手动方式就撑不住了。一个平台可能有几十个 AI 功能点，每个功能点的请求特征、质量要求、成本敏感度都不一样，靠人工维护根本管不过来。

于是模型路由层就出现了。它的核心思路很简单：在业务代码和模型 API 之间加一层代理，所有请求先经过这层代理，由它根据预设规则决定走哪个模型。规则可以基于任务类型、请求长度、用户等级、时段、甚至实时成本预算来动态调整。

这层代理带来的好处不只是省钱。它还把模型调用这件事从业务代码里解耦出来了。以前换个模型要改十几个服务的代码，现在只需要改路由层的配置。以前做 A/B 测试要部署两套环境，现在路由层按比例分流就行。这种架构上的灵活性，才是企业客户真正看重的。

3. 模型路由层的核心设计思路

3.1 路由决策的五个维度

设计路由层的时候，不能拍脑袋决定哪个请求走哪个模型。我总结下来，决策依据主要有五个维度，每个维度都需要在配置里明确。

第一个维度是任务类型。这是最粗粒度的划分。代码生成、数学推理、复杂逻辑分析这类任务，对模型能力要求高，应该走顶级模型；而文本分类、情感分析、简单问答、格式转换这类任务，便宜模型完全能胜任。我通常会在路由配置里维护一张任务类型到模型池的映射表。

第二个维度是请求复杂度。同样是问答，问“今天天气怎么样”和问“帮我分析这份合同里第三条款的法律风险”，复杂度天差地别。复杂度可以通过输入 token 长度、是否包含多轮对话历史、是否涉及专业领域关键词来估算。我的经验是，输入 token 超过两千的请求，大概率需要更强的模型。

第三个维度是质量要求等级。这个需要业务方来定义。比如客服场景里，VIP 用户的咨询可以走顶级模型，普通用户的走便宜模型；内容审核场景里，疑似违规的内容走顶级模型复核，明确合规的直接放行。

第四个维度是成本预算。路由层可以设置每日或每月的成本上限，当某个模型的消耗接近预算时，自动把后续请求降级到更便宜的模型。这个机制在流量突增的时候特别有用，能防止账单失控。

第五个维度是延迟要求。有些场景对响应速度极其敏感，比如实时翻译、语音助手。这时候不能只看成本，还要看模型的响应延迟。便宜模型有时候因为负载高，延迟反而比顶级模型大，这个要实测。

3.2 规则引擎还是机器学习

路由决策的实现方式有两种：规则引擎和机器学习模型。规则引擎就是写一堆 if-else，根据上面说的五个维度做判断。机器学习则是训练一个分类器，根据历史请求特征和效果反馈，自动决定路由策略。

我建议大多数团队从规则引擎开始。原因很简单：可解释、可调试、可快速迭代。你写了一条规则说“输入超过两千 token 走 Claude”，那所有超过两千 token 的请求都会走 Claude，出了问题一眼就能看出来。机器学习模型虽然理论上更优，但训练数据从哪来、效果怎么评估、出错了怎么排查，这些都是坑。

等规则引擎跑顺了，积累了大量请求日志和效果数据，再考虑用机器学习做动态优化。这时候你有了真实数据，训练出来的模型才靠谱。我见过一些团队一上来就搞智能路由，结果模型训练数据不足，路由决策还不如随机分配，白白浪费了几个月时间。

3.3 降级与熔断机制的设计

路由层还有一个容易被忽视但极其重要的功能：降级和熔断。当某个模型服务出现故障、响应超时或者达到速率限制时，路由层应该能自动把请求转发到备用模型，而不是直接报错给用户。

这个机制的设计要点是：备用模型的选择要有优先级顺序。比如主模型是 Claude 顶级，第一备用是 Claude 中级，第二备用是 DeepSeek，第三备用是本地部署的开源模型。当主模型不可用时，按顺序尝试备用，直到有一个成功。

熔断则是另一个方向：当某个模型的错误率超过阈值时，暂时把它从可用池里摘除，过一段时间再试探性放量。这个机制能防止故障模型拖垮整个系统。我在实际项目里把熔断阈值设在错误率百分之二十，持续三十秒就触发，恢复时先放百分之五的流量试探。

提示：降级和熔断的配置一定要做压力测试。我踩过的坑是，备用模型平时流量很小，真到主模型故障时，备用模型瞬间被打满，导致降级也失败。后来我给备用模型也做了容量预留，平时就保持一定比例的流量，确保它随时能承接突发流量。

4. 便宜模型的选型与实测对比

4.1 DeepSeek 在实际业务中的表现

DeepSeek 是这波“便宜模型”浪潮里最受关注的选手。它的 V3 系列在中文任务上的表现，说实话超出了我的预期。我拿它和 Claude 顶级模型做了几组对比测试，场景都是真实业务请求。

第一组是电商客服问答。五百条真实用户咨询，涵盖退换货政策、物流查询、商品参数、优惠券使用等。Claude 顶级模型的回答准确率是百分之九十四，DeepSeek 是百分之八十九。差距主要在复杂退换货规则的推理上，DeepSeek 偶尔会漏掉一些条件分支。但简单查询类问题，两者几乎没差别。

第二组是商品描述生成。三百个商品，每个生成一段两百字左右的描述。人工评估下来，Claude 生成的文案更有文采，DeepSeek 的更直白。但在电商场景里，直白反而转化率更高，因为用户看描述是为了快速获取信息，不是欣赏文学。

第三组是评论情感分类。一千条用户评论，分正面、负面、中性三类。Claude 准确率百分之九十一，DeepSeek 百分之八十八。差距很小，而且错误样本集中在那些反讽、阴阳怪气的评论上，这种连人工标注都容易出错。

4.2 开源模型本地部署的成本账

除了调用 DeepSeek 的 API，还有一种更彻底的做法：本地部署开源模型。像 Qwen、Llama 这些系列，都有可以商用的开源版本。本地部署的好处是数据不出内网，成本固定，不用担心 API 涨价或限流。

但本地部署的成本账要算清楚。我帮一个做医疗问答的团队算过：他们需要处理每天五万条咨询，如果本地部署一个七十亿参数级别的模型，需要至少一张 A100 显卡，按云服务价格算，一个月大概一千五百美元。加上运维人力，一个月总成本两千美元左右。而同样量走 DeepSeek API，一个月大概三百美元。本地部署反而更贵。

本地部署划算的场景是：数据敏感度极高，绝对不能出内网；或者调用量极大，比如每天几百万次请求，这时候 API 成本会超过硬件成本。对于大多数中小企业，调用 API 仍然是更经济的选择。

4.3 多模型组合的性价比最优解

实际业务里，很少有“一个模型打天下”的情况。更常见的做法是组合使用：顶级模型处理复杂任务，便宜模型处理简单任务，本地模型处理敏感任务。

我那个跨境电商朋友最终的方案是这样的：Claude 顶级模型只用于处理 VIP 用户的复杂咨询和纠纷仲裁，大概占总请求量的百分之五；DeepSeek 处理普通用户的常规咨询和商品描述生成，占百分之七十；剩下百分之二十五的请求，比如内部数据查询、日志分析，走本地部署的小模型。

这个组合下来，他们的 AI 成本从每月四万多美元降到了六千美元左右，而业务方反馈的用户满意度几乎没有变化。这个案例说明，模型路由不是简单地“换便宜模型”，而是根据任务特征做精细化匹配。

5. 实操：从零搭建一个模型路由层

5.1 环境准备与技术栈选择

搭建路由层不需要太重的技术栈。我的建议是用 Python 加 FastAPI，因为生态成熟，和各家模型 SDK 的兼容性最好。数据库用 PostgreSQL 存路由规则和调用日志，Redis 做缓存和速率限制。

如果你已经在用 Kubernetes，可以把路由层部署成一个独立的服务，业务代码通过内部域名调用它。如果还没上 K8s，用 Docker Compose 跑起来也完全够用。关键是路由层要无状态，方便水平扩展。

依赖方面，需要安装各家模型的 SDK。Anthropic 有官方的 Python SDK，DeepSeek 兼容 OpenAI 的接口格式，可以直接用 openai 库调用。本地模型如果用 Ollama 部署，也有对应的 Python 客户端。

pip install fastapi uvicorn anthropic openai redis psycopg2-binary

注意：不要把各家 API 的密钥硬编码在代码里。用环境变量或者密钥管理服务。我见过有人把密钥提交到公开仓库，结果被扫到之后一夜之间跑掉几千美元。这种低级错误千万别犯。

5.2 路由规则配置表的设计

路由规则我建议用数据库表来存，而不是写在配置文件里。这样修改规则不需要重启服务，也方便做版本管理和回滚。

表结构大概是这样：规则 ID、规则名称、优先级、匹配条件（JSON 格式）、目标模型、是否启用、创建时间。匹配条件里可以包含任务类型、token 长度范围、用户等级、时段等字段。

{ "task_type": "customer_service", "input_tokens_max": 2000, "user_level": "normal", "time_range": "00:00-23:59" }

路由层收到请求后，按优先级从高到低遍历规则，找到第一条匹配的规则，就用它指定的模型。如果没有任何规则匹配，就走默认模型。这个默认模型我建议设成便宜的那个，防止配置遗漏导致成本失控。

规则的优先级设计有个技巧：把最具体的规则放在最前面，最通用的放在最后。比如“VIP 用户的复杂咨询走 Claude”这条规则，优先级要高于“所有客服咨询走 DeepSeek”。这样能确保特殊场景被正确处理。

5.3 请求转发与结果回传的实现

路由层的核心逻辑就是：接收请求、匹配规则、转发到目标模型、回传结果。听起来简单，但有几个细节要注意。

第一是超时控制。不同模型的响应时间不一样，顶级模型通常更慢。路由层要设置合理的超时时间，并且超时后要触发降级逻辑。我的经验是，顶级模型超时设三十秒，便宜模型设十五秒，本地模型设十秒。

第二是重试策略。网络抖动导致的失败可以重试，但模型返回错误（比如内容被拦截）不应该重试。重试次数建议不超过两次，并且要换一个备用模型重试，而不是死磕同一个。

第三是日志记录。每个请求都要记录：请求 ID、匹配的规则、目标模型、输入输出 token 数、响应时间、是否成功、是否降级。这些日志是后续优化路由规则和成本分析的基础。

async def route_request(request): rule = match_rule(request) model = rule.target_model if rule else DEFAULT_MODEL try: response = await call_model(model, request, timeout=rule.timeout) log_success(request, model, response) return response except TimeoutError: fallback = get_fallback_model(model) response = await call_model(fallback, request) log_fallback(request, model, fallback) return response

5.4 灰度发布与效果监控

路由规则上线不能一刀切。新规则先放百分之五的流量，观察一周，看成本变化和质量指标。如果没问题，再逐步放大到百分之五十、百分之百。

监控指标要覆盖三个层面：成本层面看每个模型的调用量和费用；质量层面看用户反馈、人工抽检准确率、投诉率；性能层面看响应时间、错误率、降级触发次数。

我习惯在 Grafana 上做一个看板，把这些指标都放上去。每天早上扫一眼，有异常能立刻发现。有一次我发现 DeepSeek 的调用量突然涨了十倍，查下来是一个新上线的功能没配路由规则，走了默认模型。如果没有监控，这个月的账单就要爆了。

6. 实际踩过的坑与排查技巧

6.1 模型切换后效果下降的排查思路

模型切换后效果下降是最常见的问题。排查的时候不要一上来就怀疑模型能力，先检查这几个地方。

第一，检查 prompt 是否适配。不同模型对 prompt 的敏感度不一样。Claude 对系统提示词的理解比较强，DeepSeek 可能更需要把指令放在用户消息里。我遇到过切换模型后效果大跌，最后发现是系统提示词里的格式要求 DeepSeek 没遵守，调整 prompt 结构后就恢复了。

第二，检查输出格式解析。有些模型喜欢在输出前后加解释性文字，如果你的代码直接按 JSON 解析就会失败。这时候要么在 prompt 里强调只输出 JSON，要么在解析前做一层清洗。

第三，检查 token 限制。便宜模型的上下文窗口可能比顶级模型小。如果请求里带了很长的历史对话，切换后可能被截断，导致效果下降。这个要在路由规则里加一个 token 长度上限，超过的请求不走便宜模型。

6.2 API 调用中的常见错误与解决

调用各家 API 的时候，错误类型五花八门。我整理了一个速查表，覆盖了大部分常见问题。

提示：遇到连接类错误，先确认是不是本地网络问题。我见过有人折腾半天 API 配置，最后发现是公司网络策略限制了外部访问。这种问题排查顺序应该是：本地网络、DNS、API 端点、密钥、请求格式。

6.3 成本失控的预防与应急处理

成本失控通常发生在两个时间点：新功能上线和流量突增。预防措施是在路由层设置硬性预算上限，当日消耗达到预算的百分之八十时发告警，达到百分之百时自动降级所有请求到最便宜的模型。

应急处理的话，如果发现账单异常，第一时间做三件事：查调用日志，看是哪个服务、哪个模型、什么请求类型导致的；如果是 bug 导致的重复调用，立刻修 bug 并加限流；如果是正常业务增长，评估是否需要调整预算或优化路由规则。

我自己的习惯是每周做一次成本复盘，看各个模型的调用量趋势和单位成本变化。有一次发现某个模型的平均 token 数在缓慢上升，查下来是业务方在 prompt 里加了很多示例，导致输入变长。这种渐进式的成本增长最容易被忽视，定期复盘才能发现。

6.4 多模型输出一致性的处理技巧

当同一个功能在不同请求中可能走不同模型时，输出一致性就成了问题。用户今天问和明天问，得到的回答风格可能不一样，体验会很割裂。

解决思路有两个。一是统一 prompt 模板，把格式要求、语气要求写死在模板里，不同模型都用同一套模板。二是在路由层做输出后处理，比如统一去掉模型特有的前缀、统一 JSON 格式、统一数字格式。

如果业务对一致性要求极高，那就不要做动态路由，而是按功能模块固定模型。比如客服模块永远走 DeepSeek，合同分析模块永远走 Claude。这样虽然牺牲了一些成本优化的空间，但换来的是稳定的用户体验。

7. 模型路由之后的下一步

路由层跑顺之后，我建议把注意力放到两个方向。一个是 prompt 的精细化运营。同一个模型，prompt 优化好了，效果能提升一大截，甚至能让便宜模型在某些任务上追平顶级模型。我见过一个团队通过优化 prompt，把 DeepSeek 在合同条款识别上的准确率从百分之八十七提到了百分之九十一，直接省掉了走 Claude 的那部分流量。

另一个方向是建立自己的效果评估体系。不要依赖模型厂商的评测数据，要基于自己的业务数据做评估。每次切换模型或调整路由规则，都跑一遍评估集，用数据说话。这个评估集不需要很大，几百条覆盖核心场景的样本就够，但一定要持续维护和更新。

最后分享一个小技巧：在路由层加一个“影子模式”。新模型上线时，先不真正切换流量，而是把请求同时发给新旧两个模型，对比输出差异，但只返回旧模型的结果给用户。这样能在不影响用户体验的前提下，积累新模型的真实表现数据。等数据够了，再正式切换。这个做法我在多个项目里用过，能大幅降低切换风险。