企业官网建设流程全解析

前两天帮一家制造业客户过2026年的AI预算，采购部门没有像去年那样反复争论“哪家模型更好”，而是直接甩给我三个问题：token单价能不能再压？请求能不能自动路由到便宜模型？搜索入口怎么变成订单入口？这三个问题，恰好指向今年企业AI采购里最明显的三个信号——按token计费、模型路由、搜索交易化。

这篇文章就是围绕这三件事展开的。我尽量站在一个实际参与采购评审的技术负责人角度，把每个信号背后的逻辑、对预算表的影响、以及合同里要怎么写清楚，一次性讲透。适合正在做AI供应商选型、年度预算规划，或者被财务追问“AI到底花多少钱”的同事参考。

1. token计费重构企业AI采购成本模型：从“买座位”到“买用量”

1.1 席位制为什么在AI采购里失效

传统SaaS采购的逻辑是“按人头买席位”，一人一个账号，打包付费，成本跟使用深度关系不大。这套逻辑放到大模型API上基本失灵，因为AI的成本和“用了多少计算量”强相关，而计算量又没法用账号数量衡量。同样一个模型，处理一份三十页的合同，跟回复一句“好的，收到”，消耗的资源可能相差上百倍。按席位收费，要么企业吃亏，要么供应商吃亏，双方都没法精确核算。

所以2025年下半年开始，主流大模型厂商几乎全部转向token计费，企业采购表里也第一次出现了“单token成本”“月均token消耗量”这种字段。这个变化看起来只是计费方式的调整，实际上把采购从“选软件”变成了“算用量”。过去采购关心的是功能列表和账号数，现在关心的是输入输出文本量、缓存命中率、模型调用频次——这些都是token口径下的专业指标。

1.2 理解token这个计费单元：key、query、value

很多同事第一次看到token这个词会懵，因为它在不同场景里含义完全不一样。做过登录系统的会想到JWT、access token，那是身份凭证；而大模型计费里的token，是文本切分的最小单位。一个token大约对应0.75个英文单词，或者半个到一个汉字，具体切法取决于模型的分词器。

这里我建议用大模型工作时的三个角色来理解：key是“我是谁”，也就是系统指令、角色设定、任务目标；query是“我在找什么”，也就是用户输入的问题、上下文材料、历史对话；value是“我能提供什么”，也就是模型生成的回答。三者合在一起，才构成一次完整调用的token消耗。输入侧的key和query会一起计入“输入token”，模型生成的value计入“输出token”，两边单价通常不一样，输出token一般更贵。

搞清楚这个区别，对采购很有实际意义。有些供应商报价单上只写一个笼统的“价格”，等你拿到账单才发现输入和输出分开计价，输入缓存还有单独的折扣档位。我建议在供应商比价阶段，直接要求对方给出输入单价、输出单价、缓存命中单价三张表，否则后续成本核算必然对不上。

1.3 采购部门必须掌握的token成本估算公式

不引入太复杂的模型，单次调用的成本可以写成：

def call_cost(input_tokens, output_tokens, input_price, output_price): # 价格单位：美元/百万token return (input_tokens * input_price + output_tokens * output_price) / 1_000_000 # 示例：输入2000 token，输出500 token print(call_cost(2000, 500, 0.15, 0.60)) # 输出：0.0006美元

单看一次调用，0.0006美元几乎可以忽略。但企业场景要乘以调用量。我见过一个真实案例：某客服系统每天调用8万次，平均每次输入1800 token、输出400 token，按上面的价格算，一个月光这一条链路就是1.44万美元，一年超过17万美元。如果再加上上下文越长、多轮对话越多，输入token会成倍膨胀，账单数字还会更难看。

所以做年度预算时，我建议至少跑一个四段式的估算：单次平均token量、日均调用次数、峰值倍数、缓存命中率。前两项决定基准成本，后两项决定你要预留多少弹性空间。很多企业只算基准值，结果双十一、新品发布这类流量高峰一来，模型费用直接翻两三倍，采购预算当场穿仓。

1.4 token计费催生的新角色和新流程

按token计费之后，AI采购不再是CTO一个人拍板的事。财务要盯用量异常，法务要审计费条款，工程要优化token消耗，采购要谈单价和折扣。我甚至在一些头部互联网公司里看到“模型成本工程师”这个岗位，专门负责压缩上下文、配置缓存、设计降级策略。

对预算有限的中小企业来说，不必设专职岗位，但流程上必须有人对以下三件事负责：一是每日用量监控，二是每月成本归因，三是季度供应商价格复审。这三件事做扎实，token计费不但不是负担，反而能让你对每一分AI预算的去向都心里有数。

2. 模型路由：采购决策从“选一款模型”变成“配一条路由策略”

2.1 单一模型绑定不再是默认选项

以前企业采购AI，常见做法是选一款综合能力最好的模型，所有业务场景都用它。这个做法简单，但浪费极其严重。简单信息抽取、意图识别、分类打标这类任务，用旗舰模型和用轻量模型的效果差距很小，价格却能差5到10倍。反过来，复杂的代码生成、多步推理、长文档分析，小模型又确实扛不住。

模型路由解决的就是这个问题：在请求入口加一层智能分发，根据任务难度、质量要求、成本预算，把每个请求送到最合适的模型上。从采购视角看，这相当于把“买一款模型”拆成了“买一个模型组合”，再把“组合路径”本身也变成一个采购对象。

2.2 路由决策的三个核心维度

做路由不是简单“贵的给复杂任务，便宜的给简单任务”，至少要同时看三个维度：

其中质量门槛最容易被忽略。我见过一个团队为了省钱，把所有客服问题都路由到小模型，结果复杂投诉处理不好，客户满意度下降，最后退单损失远超省下的模型费。我的经验是：先对业务场景做一次分类，标出哪些任务“失败不可接受”，哪些任务“失败可容忍”，再决定路由策略，而不是一上来就谈价格。

2.3 一个典型路由策略的配置示例

路由规则的实现从简单到复杂都有。最简单的是关键词和规则匹配，适合场景边界清晰的企业；进阶做法是用embedding把用户请求向量化，和预设任务模板做相似度匹配；更复杂的会用一个小模型实时预测“哪个大模型能最好地完成这个请求”。

下面是一个很简化的Python伪代码，演示按任务类型路由的基本逻辑：

def route_request(task_type, input_text): if task_type == "entity_extraction": # 命名实体识别：用轻量模型，成本优先 return call_model("light-model", input_text) elif task_type == "complex_reasoning": # 复杂推理：用旗舰模型，质量优先 return call_model("frontier-model", input_text, max_tokens=2048) elif task_type == "customer_service": # 客服应答：先用规则判断是否需要人工介入 if is_high_risk(input_text): return call_model("frontier-model", input_text) return call_model("mid-tier-model", input_text) else: # 默认走平衡型模型 return call_model("mid-tier-model", input_text)

路由层的效果在实测中通常很可观。公开案例里，切换路由策略后模型API成本普遍能降30%到50%，同时质量几乎不下降。但我要提醒一点：路由策略上线前一定要做回归测试，至少准备200条覆盖各场景的测试样本，对比路由前后的输出质量。否则你只知道账单降了，不知道质量是不是也降了。

2.4 路由层本身正在变成采购对象

既然路由能省钱，企业自然面对两个选择：自建路由网关，或者直接采购路由服务。自建的好处是可控性强、数据不出内网，坏处是要养团队、踩坑；采购现成路由服务（比如各类模型网关和统一API平台）的好处是上线快、自带成本统计和模型切换能力，坏处是又多了一层供应商依赖。

我倾向于分阶段：初期用路由服务快速跑通，同时积累自己的调用日志和评估集；跑半年左右，如果企业模型调用量足够大、场景足够复杂，再评估自建。采购合约上要注意一个细节：路由服务本身的费用通常按“代理调用量”额外计费，这部分不能漏算进整体AI预算。

3. 搜索交易化：AI搜索从“信息出口”变成“交易入口”

3.1 传统搜索与交易化搜索的本质差异

传统搜索引擎的核心商业模式是广告：用户搜索关键词，页面展示自然结果加广告位，广告主按点击付费，交易发生在搜索页面之外。这个模式下，搜索是“信息出口”——用户带着问题来，得到答案或链接就走了，搜索平台赚的是流量差价。

搜索交易化则完全不同：搜索结果本身直接关联商品、服务或订单，用户可以在搜索结果里完成加购、下单、预约、支付。最典型的是电商平台的站内搜索，用户搜“手机”，结果页直接展示商品卡片和下单按钮。AI搜索出现后，这个逻辑被进一步放大：对话式搜索可以直接给出购买建议、生成比价表、一键跳到结算页，搜索从“帮你找”变成“帮你买”。

3.2 AI搜索交易化在企业采购里的三种形态

对企业采购来说，搜索交易化不是一个抽象概念，而是已经能落地的几类业务：

第一种是内部知识搜索转工单。员工用AI搜索内部制度和流程，搜到结果后可以直接发起审批、提交采购申请，搜索系统变成业务系统的前端入口。

第二种是B2B采购搜索。比如一个采购员搜索“30kw空压机供应商”，AI不只返回网页列表，还能直接整理供应商报价、资质和交期，生成询价单发给备选厂商。这个场景里，搜索的终点是采购行为本身。

第三种是面向消费者的购物助手。AI助手在回答“哪个品牌的保温杯适合通勤用”时，直接推荐具体商品并附购买链接，平台按成交订单抽取佣金。这和传统广告的区别在于：每一次推荐都有明确的交易结果可以追踪，结算逻辑从“点击付费”变成“成交付费”。

3.3 交易化的变现模型：从广告点击到成交分成

这对采购和商务谈判影响很大。传统搜索广告的计价单位是CPC（按点击付费）或CPM（按展示付费），而交易化搜索的计价单位变成了CPS（按成交付费）或按订单金额抽成。计价逻辑的变化意味着，搜索服务商愿意承担一部分“推荐无效”的风险，因为只有真正促成交易才能拿到分成。

对企业来说，这既有机遇也有陷阱。机遇是，你可以把一部分费用从固定成本变成可变成本，和结果强绑定；陷阱是，成交归因很容易扯皮——用户看了AI推荐，但三天后从别的渠道下单，这个成交算谁的？所以采购搜索交易化服务时，合同里必须写清楚归因口径、归因窗口期、数据回传方式。没有这些条款，后续对账会非常痛苦。

3.4 搜索交易化的合规评审必须前置

搜索交易化最容易被忽视的是合规和数据风险。自然结果和广告推荐的边界一旦模糊，用户容易产生误导；AI推荐的商品如果存在虚假宣传，责任方到底是搜索服务商还是商家？另外，用户的搜索行为和购买行为一旦被聚合，就涉及隐私边界和数据留存问题。

我的建议是：这类项目在技术选型之前，先让法务和合规介入，对三条线做评估——广告标识义务、数据归属权、审计权。拿不到审计权，或者不允许企业对推荐结果做抽查，再便宜也别签。这个原则在我经历的几个项目里反复被验证，跳过合规步骤的项目，后期几乎没有不返工的。

4. 三个信号叠加：2026年企业AI采购清单与合同要点

4.1 采购品类扩容：从模型API到路由与交易链路

把三个信号放在一起看，2026年企业AI采购清单会和2024年、2025年明显不一样。过去的年度采购清单主要是“模型API”“算力资源”“标注数据”这类相对基础的东西；2026年至少要增加五个品类：模型路由网关、token用量治理平台、AI搜索交易服务、模型评估测试服务、成本监控与审计工具。

这背后是一个很重要的变化：企业不再把AI当单一产品来买，而是当成一条“调用链路”来配。从用户提问，到模型路由，到token计量，再到搜索结果转化为交易，每一环都有独立的采购和供应商。采购部门的职责也随之扩展——不是选一个最好的模型，而是配置一套最高效的调用链路。

4.2 从成本治理到合同条款：按token计费时代的谈法

既然计费单元变成token，合同条款也要跟着升级。我总结了几条容易被忽略的谈判要点：

• 计费口径必须写明：输入token、输出token、缓存token分别怎么计价，四舍五入规则是什么，token统计以哪一方为准。
• 单价保护期：约定供应商调价需提前多久通知，是否锁定一段时间内的单价。
• 用量明细与审计权：要求供应商提供可下载的调用日志和用量明细，企业有权定期核对。
• 模型下线与替换条款：如果某个模型版本下线，供应商要提供同等规格的替代模型，并保障迁移期。
• 故障切换机制：路由服务如果出现故障，是否有备用通道，SLA怎么赔偿。

这些条款不是法务单方面能拟好的，需要采购把实际业务场景翻译给法务。比如“模型下线”看起来是技术问题，但如果你有一个跑了一年的客服机器人依赖某个模型，突然被下线，用户侧体验就会立刻出问题，所以合同里必须有明确的过渡方案。

4.3 部门协作：采购、财务、法务、工程四方对接机制

三个信号叠加之后，AI采购必然会把采购、财务、法务、工程四方拉到一个桌上。工程负责提需求和做技术验证，采购负责谈价格和供应商管理，财务负责用量预算和成本归因，法务负责合同和合规。任何一个环节缺位，都会出问题。

我最常看到的失败模式是：工程把技术方案定了，采购只负责走流程，结果合同里没写计费口径，账单出来对不上；或者法务只按通用模板改条款，没考虑token计费和搜索交易化的特殊性，出了问题又没有追溯依据。所以建议企业在采购流程里设置一个“四方评审会”，在比价之前就把需求、预算、风险、条款四个维度过一遍，宁可前期多花一周，也不要后期返工一个月。

5. 给正在做2026年AI采购规划的三点落地建议

5.1 先跑30天用量盘点，再谈一切采购

不管供应商给的价格多诱人，没有准确的用量基线，一切都是空谈。我建议至少预留一个月时间，把企业现有的AI调用全部接入一个统一的请求网关，记录模型、任务类型、输入输出token、时延和成本。一个月后，你会得到三个数字：日均token消耗、月均API费用、场景分布比例。这三个数字是你和供应商谈判的底牌，也是预算审批的依据。

这一步看起来简单，实际执行时最大的阻力是工程资源。调用日志要统一格式、要脱敏、要按业务线打标签，如果现有系统比较散，工作量并不小。但这件事值得在采购季之前做掉，因为它直接影响后续所有决策的精度。

5.2 用小流量路由试点验证成本与质量

如果条件允许，别一上来就全量上线模型路由。先选一条调用量中等、质量反馈清晰的业务线，比如客服工单分类或者工单摘要，把请求按5%到10%的流量切到路由策略上，和原来的单一模型跑两周对比。对比指标就三个：成本下降比例、质量评估得分、异常率。

试点期间要注意收集失败样本。路由模型出错的模式和单一模型不一定相同，有些错是“小模型能力不足”，有些错是“路由规则本身分类错误”。前者调整模型选择就行，后者要改路由策略。两到三周试下来，你对路由的真实收益会有很扎实的判断，这个判断比供应商给你的任何宣传数据都可靠。

5.3 把搜索交易化的合规评估放在POC之前

搜索交易化项目最容易犯的错，是先用POC验证效果、再让合规介入，结果发现推荐流程里的数据使用方式需要大改，POC白做。正确顺序应该是：先让法务和合规把边界划清楚，再启动技术验证。评估内容包括搜索结果里商业推荐是否需要显著标识、数据是否允许回流给供应商、平台是否有义务保存并供审核的推荐日志。

我也理解合规评估在早期会拖慢节奏，看起来“什么都没做就开始走流程”。但经历过一次返工之后，你就会认同这个顺序。搜索交易化涉及用户信任，一旦出问题，损失的不只是合规罚款，还有用户对整个搜索入口的信任。

最后分享一点我个人的体会。这三个信号表面上是三个独立趋势，背后其实是同一件事：AI的成本第一次被精确到了“一次请求、一个token、一次转化”的颗粒度。当成本可度量，采购就可以从“赌一个模型”变成“精细配置一条链路”。如果你所在的企业还在用去年那种“选个最强模型然后祈祷账单别爆”的思路做2026年预算，我建议你把token用量盘点和模型路由试点排上日程。实际跑下来你会发现，成本降下来只是一个结果，更值钱的是对AI投入的掌控感，这是从“凭感觉花钱”到“按数据花钱”的关键一步。