企业官网建设流程全解析

AI 时代的到来，让整个 SaaS 行业站在了一个分岔路口。一边是“所有软件都值得用 AI 重写一遍”的宏大叙事，另一边却是大量 SaaS 公司收入增长停滞、续费率下滑的残酷现实。近期不少科技大佬在访谈中都提到一个反直觉的观点：AI 时代 SaaS 行业即将迎来大洗牌，真正让 SaaS 公司陷入危险的，不是模型能力不够强，而是沿用至今的定价模式正在失效。这篇文章不打算讨论某一家具体公司的股价起伏，而是从技术架构、成本结构、工程实现三个层面，拆解为什么“模型”不是护城河，以及“定价模式”会如何倒逼 SaaS 产品重构。如果你是 SaaS 产品经理、后端开发、架构师，或者正在用 AI 能力做独立产品，这篇文章会给你一个比较完整的框架。

1. 背景与核心概念：AI 时代的 SaaS 为什么需要重新审视

1.1 SaaS 的传统商业模式是什么

SaaS（Software as a Service，软件即服务）经过近二十年的发展，已经形成了一套非常成熟的商业范式。过去企业采购软件的方式是买 License、买服务器、自己运维，SaaS 则把软件部署在云端，企业按订阅周期付费，通常是按年或按月，按账号数量（Seat）收费。这种模式最大的优势在于降低了客户的首次采购成本，同时把软件的升级、运维、安全责任转移给了服务商。

传统 SaaS 的定价模型可以归纳为三种：

这套体系在“软件边际成本趋近于零”的假设下运行了很多年。实现一份软件，服务一万个用户和服务十个用户，服务器成本增加有限，所以按席位收费可以让 SaaS 公司获得极高的毛利率。

1.2 AI 进入 SaaS 后，成本结构被彻底改变

大模型（LLM，Large Language Model）被嵌入 SaaS 后，原来“边际成本趋近于零”的假设不再成立。

传统 SaaS 中，用户多一次点击、多一次查询，公司付出的成本几乎可以忽略。但 AI 功能的每一次调用，都需要消耗 GPU 算力，也就是真实的 Token 成本。用户在一个 AI 聊天框中多输入一句问候、多追问一轮，成本都会立刻增加。如果 SaaS 产品把 AI 问答、AI 写作、AI 总结做成基础功能，用户量增长反而可能带来亏损——这就是“用得越多亏得越多”的倒挂现象。

举一个简化的例子：

传统 SaaS： 用户一个月操作 10,000 次 → 服务器成本约 1 元 → 毛利很高 AI SaaS： 用户一个月调用大模型 10,000 次 每次消耗约 2,000 Token 单月 Token 成本 = 10,000 × 2,000 × 单价 当单价为 0.002 元/千 Token 时，成本 = 40 元

如果这个 AI 功能被包含在 30 元/月的订阅套餐里，用户调用量稍大，产品就进入负毛利状态。

1.3 “模型不是护城河”是什么意思

科技大佬访谈中反复出现一个观点：模型能力本身不会成为 SaaS 公司的长期护城河。原因是多方面的。

第一，基础大模型正在快速趋同。OpenAI、Anthropic、Google、Meta 以及国内多家厂商的模型在通用能力上的差距正在缩小，而且模型可以随时通过 API 切换。第二，开源模型降低了接入门槛。企业可以基于 Llama、Qwen、DeepSeek 等开源权重做微调和私有化部署，模型层面的差异化越来越小。第三，模型能力只是 AI SaaS 的上游供应。真正决定产品价值的，是数据、工作流、行业知识、用户体验和交付效果。

换句话说，模型是一个“成本中心”和“能力基座”，但不是“商业壁垒”。如果一家 SaaS 公司只是把 GPT 的对话框包装后卖 200 元/月，用户很快会发现，不如自己去官网订阅。真正有价值的是：模型能力如何嵌入到用户的业务流中，以及这种嵌入能否用合理的成本结构持续获利。

这也引出了本文的核心：AI 时代 SaaS 的竞争，正在从“谁的模型更强”转向“谁的模式更赚钱”。

2. AI 时代 SaaS 的三种技术形态

要理解定价模式的变化，需要先理解 AI 能力在 SaaS 中的技术落地形态。不同形态对应不同的成本核算方式，也直接影响定价策略。

2.1 形态一：AI 功能作为插件（AI Feature Add-on）

这是最轻量的一种方式。产品主体还是传统 SaaS，在原有订阅套餐之上，额外提供 AI 功能包，用户需要单独购买。

典型例子是 Notion AI、各类文档协作工具的 AI 助手。技术实现上，这些 AI 插件通常包含：

• 调用大模型 API（OpenAI、Claude、国内大模型服务等）
• 上下文拼接（把当前文档、知识库片段拼进 Prompt）
• 结果流式返回（SSE，Server-Sent Events）
• 用量记录（统计每个账号的 Token 消耗量）

这种形态的优点是接入成本低、不影响原有定价体系；缺点是用户感知价值有限，如果按席位再加收 AI 费用，容易让用户觉得“不划算”。

2.2 形态二：AI 原生 SaaS（AI-Native SaaS）

产品从第一天起就以 AI 为核心。用户输入的是一段描述、一张图片、一个数据文件，系统返回的是生成的文案、设计稿、数据分析报告或自动化流程。

这种产品的成本结构几乎完全是 Token 和算力驱动。技术架构上，需要特别注意：

• 模型调用层：支持多模型切换、自动降级
• 消息队列：异步处理长任务，避免 HTTP 请求超时
• 大文件存储：处理用户上传的图片、文档
• 任务状态机：跟踪每个生成任务的状态（排队中、处理中、已完成、失败）

这类产品的定价天然适合按量计费，因为每一次调用都能对应到明确的“产出”和“成本”。

2.3 形态三：AI Agent / Copilot 模式

Copilot 本身不直接产出最终结果，而是辅助用户在现有软件中完成任务。例如，HR SaaS 中的智能薪资计算助手、运维平台中的故障诊断助手。

Agent 模式更复杂，它可能涉及多轮对话、工具调用（Function Calling）、代码执行、外部 API 请求。每一次 Agent 任务可能消耗数万 Token，成本波动范围很大。

这种模式对定价模型带来了新挑战：一个用户可能今天只用 1,000 Token，明天一次复杂任务消耗 50,000 Token，成本差距达到 50 倍。如果按统一的订阅价收费，要么是产品亏本，要么是低用量用户补贴高用量用户，长此以往会出现“高成本用户挤走利润”的逆向选择问题。

3. 定价模式重构：从按席位到按价值

既然 AI 打破了 SaaS 原有的成本结构，定价模式也必须同步调整。当前行业比较有共识的方向主要有三个。

3.1 混合定价：订阅 + 用量

这是目前最主流的过渡方案。用户仍然订阅基础套餐，但 AI 功能采用“免费额度 + 超出按量付费”的模式。

技术上的核心是计量系统（Metering System）。系统需要完成：

• 记录每次模型调用的 Token 数
• 按用户/企业维度聚合
• 将不同模型的 Token 换算为统一计费单位
• 设置阈值触发告警或熔断

3.2 按价值定价：从“按用量”到“按成果”

按量计费看似公平，但它有一个缺陷：把所有成本压力都转移给了用户。用户使用 AI 写一封邮件，如果模型思考了 5,000 Token 才生成 100 字的回复，用户会认为这很不合理。

按价值定价（Value-Based Pricing）则是基于 AI 实际帮助用户完成的任务价值来定价。例如：

• 客服工单 AI：按“成功解决的工单数”收费
• 营销文案 AI：按“生成的可用文案数量”收费
• 智能审阅 AI：按“审阅的合同页数”收费

这个方向需要产品做更深层的效果检测，但用户接受度高，也是访谈中几位大佬认为的长期方向。

3.3 成本穿透与毛利保护

不管采用哪种定价模式，SaaS 公司都必须清楚每一个 AI 功能的真实毛利。这里需要建立一套“成本核算机制”：

单客户月度 AI 成本 = Σ(每次调用的 Token 数 × Token 单价) 单客户月度 AI 收入 = 订阅分摊收入 + AI 按量收入 单功能毛利率 = (AI 收入 - AI 成本) / AI 收入

对于毛利率为负的功能，要么调整定价，要么做模型降级（切换到更便宜的模型），要么限制单用户用量。

4. 技术落地：为 AI SaaS 构建一套计量计费体系

上面讨论的定价模式，最终都要落到工程实现。本节用 Java + Spring Boot 为例，演示如何构建一套最小可用的 AI 用量计量与计费系统。示例会覆盖用量记录、额度扣减、超限熔断和成本估算四个核心环节。

4.1 项目结构设计

我们先建立项目的基本目录结构：

ai-saas-billing ├── pom.xml ├── src/main/java/com/example/billing │ ├── BillingApplication.java │ ├── controller │ │ └── UsageController.java │ ├── service │ │ ├── TokenUsageService.java │ │ ├── QuotaService.java │ │ └── CostEstimateService.java │ ├── entity │ │ └── UsageRecord.java │ ├── repository │ │ └── UsageRecordRepository.java │ └── interceptor │ └── UsageLimitInterceptor.java └── src/main/resources └── application.yml

4.2 数据表设计

计量系统最关键的是 UsageRecord 表。它记录了每次模型调用的明细，包括客户 ID、用户 ID、功能模块、模型名称、输入 Token 数、输出 Token 数、总 Token 数、时间戳等。

CREATE TABLE usage_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, customer_id VARCHAR(64) NOT NULL, user_id VARCHAR(64) NOT NULL, module_code VARCHAR(32) NOT NULL, model_name VARCHAR(64) NOT NULL, prompt_tokens INT NOT NULL, completion_tokens INT NOT NULL, total_tokens INT NOT NULL, estimated_cost DECIMAL(10, 6) NOT NULL, created_at DATETIME NOT NULL, INDEX idx_created_at (created_at), INDEX idx_customer_module (customer_id, module_code) );

这里需要注意索引设计。计量系统最常见的查询是按客户和时间范围聚合，因此customer_id + created_at联合索引非常重要。如果数据量巨大，可以考虑按月分表，或者把明细数据写入 ClickHouse 之类的列式存储，MySQL 中只保留聚合结果。

4.3 用量记录的核心代码

定义 UsageRecord 实体：

// 文件路径：src/main/java/com/example/billing/entity/UsageRecord.java package com.example.billing.entity; import java.math.BigDecimal; import java.time.LocalDateTime; public class UsageRecord { private Long id; private String customerId; private String userId; private String moduleCode; private String modelName; private Integer promptTokens; private Integer completionTokens; private Integer totalTokens; private BigDecimal estimatedCost; private LocalDateTime createdAt; // 省略 getter/setter，实际项目中可用 Lombok @Data 简化 }

继续写 Token 用量服务。这里有一个关键实践：不要在业务代码里到处计算成本，而是统一在一个服务里完成“用量换算为成本”的逻辑。这样后面切换模型、调整价格时只需要改一处。

// 文件路径：src/main/java/com/example/billing/service/TokenUsageService.java package com.example.billing.service; import com.example.billing.entity.UsageRecord; import org.springframework.stereotype.Service; import java.math.BigDecimal; import java.time.LocalDateTime; @Service public class TokenUsageService { /** * 记录一次模型调用的用量 * 价格表简化处理：实际项目中应从配置中心或数据库读取 */ public UsageRecord recordUsage(String customerId, String userId, String moduleCode, String modelName, int promptTokens, int completionTokens) { int totalTokens = promptTokens + completionTokens; // 这里以某个模型的价格为例：输入 0.002 元/千Token，输出 0.006 元/千Token BigDecimal promptPricePerThousand = new BigDecimal("0.002"); BigDecimal completionPricePerThousand = new BigDecimal("0.006"); BigDecimal promptCost = BigDecimal.valueOf(promptTokens) .divide(BigDecimal.valueOf(1000)) .multiply(promptPricePerThousand); BigDecimal completionCost = BigDecimal.valueOf(completionTokens) .divide(BigDecimal.valueOf(1000)) .multiply(completionPricePerThousand); BigDecimal estimatedCost = promptCost.add(completionCost); UsageRecord record = new UsageRecord(); record.setCustomerId(customerId); record.setUserId(userId); record.setModuleCode(moduleCode); record.setModelName(modelName); record.setPromptTokens(promptTokens); record.setCompletionTokens(completionTokens); record.setTotalTokens(totalTokens); record.setEstimatedCost(estimatedCost); record.setCreatedAt(LocalDateTime.now()); // 实际项目中：repository.save(record); return record; } }

这段代码展示了一个非常核心的原则：Token 成本必须在调用时估算并落库。否则业务高峰过去后，你很难把“用户行为”和“成本”准确对应起来。

4.4 配额控制与超限熔断

按量计费的场景下，如果没有配额控制，客户可能在不知情的情况下产生高额费用，最终造成客诉或者坏账。因此系统必须提供实时配额检查。

// 文件路径：src/main/java/com/example/billing/service/QuotaService.java package com.example.billing.service; import org.springframework.stereotype.Service; import java.math.BigDecimal; import java.time.LocalDate; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; @Service public class QuotaService { /** * 简化实现：用本地缓存保存客户当月已用金额 * 生产环境建议使用 Redis，支持更复杂的聚合统计 */ private final Map<String, BigDecimal> monthlyUsage = new ConcurrentHashMap<>(); public boolean checkQuota(String customerId, BigDecimal estimatedCost) { String key = customerId + ":" + LocalDate.now().getMonthValue(); BigDecimal used = monthlyUsage.getOrDefault(key, BigDecimal.ZERO); BigDecimal limit = new BigDecimal("1000"); // 客户月度限额，实际从配置读取 return used.add(estimatedCost).compareTo(limit) <= 0; } public void addUsage(String customerId, BigDecimal cost) { String key = customerId + ":" + LocalDate.now().getMonthValue(); monthlyUsage.merge(key, cost, BigDecimal::add); } }

配额检查的逻辑可以放在拦截器、AOP 切面或模型调用 SDK 中。如果项目使用 Spring Boot，推荐用拦截器统一处理：

// 文件路径：src/main/java/com/example/billing/interceptor/UsageLimitInterceptor.java package com.example.billing.interceptor; import com.example.billing.service.TokenUsageService; import jakarta.servlet.http.HttpServletRequest; import jakarta.servlet.http.HttpServletResponse; import org.springframework.web.servlet.HandlerInterceptor; public class UsageLimitInterceptor implements HandlerInterceptor { private final TokenUsageService tokenUsageService; public UsageLimitInterceptor(TokenUsageService tokenUsageService) { this.tokenUsageService = tokenUsageService; } @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String customerId = request.getHeader("X-Customer-Id"); String moduleCode = request.getHeader("X-Module-Code"); if (customerId == null || moduleCode == null) { response.setStatus(HttpServletResponse.SC_BAD_REQUEST); response.getWriter().write("Missing customerId or moduleCode"); return false; } // 实际项目中，这里要预估本次请求可能消耗的成本 // 然后在模型调用结束后再精确记录用量 return true; } }

注意，真正精细的熔断不能只靠 HTTP 拦截器。因为模型调用是异步的，请求进来后可能排队几秒甚至几十秒才真正执行。更合理的做法是：在任务进入队列前做预检查，任务完成后精确扣减；同时用定时任务扫描异常账号（例如短时间消耗超过限额 50% 的用户）。

4.5 成本预估与模型路由

同一个 AI 功能，不一定每次都要用最强、最贵的模型。一个实用的工程策略是“模型路由”（Model Routing）：简单任务走小模型，复杂任务走大模型，从而在用户体验和成本之间做平衡。

// 文件路径：src/main/java/com/example/billing/service/CostEstimateService.java package com.example.billing.service; import org.springframework.stereotype.Service; @Service public class CostEstimateService { /** * 根据输入长度和任务难度选择模型 * promptLength: 输入内容的字符数 * taskComplexity: LOW/MEDIUM/HIGH */ public String selectModel(int promptLength, String taskComplexity) { if (taskComplexity.equals("HIGH") || promptLength > 5000) { return "premium-model"; } if (taskComplexity.equals("MEDIUM")) { return "standard-model"; } return "light-model"; } /** * 预估成本：在调用前基于输入长度做粗估 */ public double estimateCost(String modelName, int promptTokens) { double pricePer1000 = switch (modelName) { case "premium-model" -> 0.06; case "standard-model" -> 0.02; case "light-model" -> 0.005; default -> 0.01; }; // 假设输出长度约为输入的 0.8 倍，这里只做粗估 int completionTokens = (int) (promptTokens * 0.8); return (promptTokens + completionTokens) / 1000.0 * pricePer1000; } }

模型路由在技术上有几个细节需要留意：

• 模型能力差异要严格记录：同一功能的 A/B 效果对比要留存日志。
• 模型路由规则要支持动态配置，不能写死在代码里。推荐把路由规则放到配置中心，运营可以随时调整。
• 用户感知不能有太大差异。如果用便宜模型生成的结果质量明显下降，会直接影响口碑。

5. 实战：AI 文档助手“按次 + 按量”双计费示例

为了把上面的设计串起来，这里用一个完整的示例场景：某 SaaS 平台提供“AI 文档助手”功能，用户可以在线撰写文案、翻译、总结。产品的定价策略是：

• 基础订阅：99 元/月，包含 100 次 AI 调用
• 超出部分：按 0.05 元/次 + Token 用量计算

接下来用代码展示核心流程。

5.1 编写 AI 文档助手服务

// 文件路径：src/main/java/com/example/billing/controller/UsageController.java package com.example.billing.controller; import com.example.billing.service.TokenUsageService; import org.springframework.web.bind.annotation.*; import java.math.BigDecimal; import java.util.HashMap; import java.util.Map; @RestController @RequestMapping("/api/ai") public class UsageController { private final TokenUsageService tokenUsageService; public UsageController(TokenUsageService tokenUsageService) { this.tokenUsageService = tokenUsageService; } @PostMapping("/document/generate") public Map<String, Object> generateDocument(@RequestBody GenerateRequest request) { // 1. 调用模型生成内容（此处省略实际调用代码） // 假设模型返回了如下用量信息 int promptTokens = request.getPrompt().length() / 2; int completionTokens = request.getMaxTokens(); // 2. 记录用量 var usage = tokenUsageService.recordUsage( request.getCustomerId(), request.getUserId(), "document_ai", "standard-model", promptTokens, completionTokens ); // 3. 返回结果和用量信息 Map<String, Object> result = new HashMap<>(); result.put("content", "这是 AI 生成的内容示例"); result.put("usage", usage); return result; } public static class GenerateRequest { private String customerId; private String userId; private String prompt; private int maxTokens; // 省略 getter/setter } }

这个 controller 展示了核心链路：调用模型 → 拿到用量 → 记录用量 → 返回结果。

5.2 编写订阅额度扣减逻辑

实际业务中，“基础包次数 + 超额按量”的逻辑比直接记录 Token 复杂一些。这里拆成两步：

// 订阅额度示例：先从客户的剩余次数中扣减，不足部分转为按量计费 public BillingResult deductQuotaOrCharge(String customerId, String userId, int costUnits) { // 查询客户当月剩余次数 int remaining = getRemainingCredits(customerId, userId); int coveredBySubscription = Math.min(remaining, costUnits); int overage = costUnits - coveredBySubscription; // 扣减订阅额度 deductCredits(customerId, userId, coveredBySubscription); // 超出的部分按量计费，生成订单 BigDecimal charge = BigDecimal.valueOf(overage).multiply(new BigDecimal("0.05")); // 记录账单明细 saveOverageCharge(customerId, userId, overage, charge); return new BillingResult(coveredBySubscription, overage, charge); }

这里的一个工程要点是：扣减订阅额度和记录超额账单必须保证原子性。如果先扣了额度，但生成账单失败，用户就白白损失了次数。建议把这两个操作放在同一个数据库事务中，或者通过带有幂等键的消息队列异步处理。

5.3 运行效果与验证

启动 Spring Boot 应用后，用 curl 模拟一次请求：

curl -X POST http://localhost:8080/api/ai/document/generate \ -H "Content-Type: application/json" \ -d '{ "customerId": "CUST-001", "userId": "USER-001", "prompt": "请帮我撰写一封客户感谢信", "maxTokens": 500 }'

预期返回中会包含 usage 字段，记录本次调用消耗的 Token 数和预估成本。通过控制台日志或数据库查询，可以看到 usage_record 表新增一条记录。

{ "content": "这是 AI 生成的内容示例", "usage": { "customerId": "CUST-001", "userId": "USER-001", "moduleCode": "document_ai", "modelName": "standard-model", "promptTokens": 11, "completionTokens": 500, "totalTokens": 511, "estimatedCost": 0.003022 } }

到这里，一套最小的“AI 用量计量 + 计费 + 配额控制”系统就落地了。它虽然简单，却包含了 AI SaaS 定价模式转型所需的核心技术骨架。

6. AI SaaS 落地中的常见问题与排查思路

转型过程中，技术团队会遇到不少实际问题。下面整理高频问题及排查方案，供大家在设计和排错时参考。

针对上面表格中的第一项，多说一句。“预扣费 + 多退少补”是 AI SaaS 中比较稳妥的方式。具体做法是：

1. 任务进入队列前，先按预估成本冻结用户账户中的可用余额或次数。
2. 模型调用完成后，用实际 Token 用量更新冻结金额。
3. 如果实际成本低于预估成本，释放差额；如果高于预估，继续扣减。

这类似于电商中的“预授权”，能有效避免用户超额使用后拒绝支付的问题。

7. AI 时代的 SaaS 架构演进趋势

定价模式的变化只是表层现象，更深层的是 SaaS 技术架构正在从“应用为中心”转向“模型为中心”。这里补充三个值得关注的技术演进方向。

7.1 从单体应用走向模型网关（Model Gateway）

SaaS 接入多个大模型后，需要一个统一入口来管理所有模型调用。模型网关通常承担这些职责：

• 统一鉴权：管理不同云厂商的 API Key
• 模型路由：按成本、延迟、效果选择模型
• 限流熔断：保护上游模型 API 不被击穿
• 日志与计量：统一记录 Token 消耗

这种模式与 API Gateway 非常类似，业界目前也有不少开源方案。它的核心价值在于：上层业务不用关心底层接的是哪个模型，让“切换模型”变成一件低成本的事，正好呼应了“模型不是护城河”的判断。

7.2 从按请求处理走向任务队列化

传统 SaaS 接口追求“请求-响应”毫秒级返回。但很多 AI 任务无法做到这一点。比如让 AI 根据 100 页合同生成摘要，耗时可能超过 60 秒。这个场景必须使用异步任务架构：

• 用户提交任务后，前端轮询或通过 WebSocket 接收状态
• 任务进入消息队列，由独立 Worker 消费
• 任务状态存入 Redis 或数据库
• 完成后再回调通知用户

这种架构带来一个好消息：异步化之后，任务成本更容易计量。因为每次任务都有明确的开始、结束时间，可以准确关联模型调用的 Token。

7.3 从单一订阅走向精细化财务运营

未来 AI SaaS 公司内部一定会新增一个角色：模型成本运营。技术侧需要为这个角色提供工具化能力，而不是每次都改代码。例如：

• 每个功能模块的实时成本看板
• 每个客户的毛利分析
• 模型价格变动时的成本影响模拟
• 异常客户的自动告警

这些能力本质上属于 FinOps（云成本优化）在 AI 领域的延伸，值得提前布局。

8. 最佳实践：AI SaaS 定价与架构的工程建议

最后从工程和商业两个角度，汇总一些可执行的建议。

8.1 产品与技术设计建议

• 功能模块必须打点清晰。每个 AI 功能要有独立的 moduleCode，不要在代码里混用。否则后面对账、成本分析会非常痛苦。
• 成本统计尽量实时。模型调用完成后立即计算 Token 成本，不要等 T+1 的离线任务。账单延迟越久，用户异议越难处理。
• 缓存和复用要谨慎。如果一个 AI 功能有较高的重复调用率（例如相同的合同模板重复生成），可以设计结果缓存，既节省成本又提升响应速度。

// 示例：基于文本 Hash 的结果缓存 public String generateWithCache(String prompt) { String cacheKey = "ai:result:" + DigestUtils.md5DigestAsHex(prompt.getBytes()); String cached = redisTemplate.opsForValue().get(cacheKey); if (cached != null) { return cached; } String result = callModel(prompt); redisTemplate.opsForValue().set(cacheKey, result, Duration.ofHours(24)); return result; }

• 模型降级路径必须存在。当高价模型不可用或超时时，能自动切换到备用模型，保证用户体验不中断。

8.2 定价与商业化建议

• 逐步取消“无限量”套餐。AI 场景下，无限量套餐要么赔本，要么被迫限制服务质量。比较稳妥的做法是设置“高额度”而不是“无限额度”。
• 将 Token 成本可视化给用户。让用户每月看到自己的 AI 调用次数和消耗情况，能有效培养合理使用习惯，减少客诉。
• 预留“成本安全垫”。定价时建议将模型成本的 1.5 倍到 2 倍作为基准，用来覆盖模型价格波动、重试成本和低效调用。
• 使用开源模型兜底。对于成本敏感的长尾场景，优先采用开源模型自部署，而不是全部走高价 API。尤其是文档总结、信息抽取这类对“智力”要求不高的任务，开源模型通常够用。

8.3 安全与合规建议

• 用户输入数据不得直接用于训练第三方模型。SaaS 客户的数据往往包含商业机密，技术侧要在 API 层做好数据脱敏和调用协议限制。
• 日志中不要记录完整的 Prompt 和模型输出。必要时只保留 Hash 值或截断后的摘要。
• 涉及计费和配额的系统变更，必须在测试环境充分验证后再上线，并保留操作审计日志。

9. 总结

AI 时代的 SaaS 大洗牌，本质上是商业模式的洗牌。模型能力的差距会随着技术迭代不断缩小，但定价模式决定了 SaaS 公司能否在成本压力下持续提供高质量服务。传统“按席位、按功能、无限量”的定价方式，在 Token 成本面前变得越来越不现实，取而代之的是“订阅 + 用量”、“按结果付费”、“模型路由 + 成本透明”等更精细化的体系。

从技术实现角度看，构建一套稳健的计量计费系统，并不是一个后期补丁式的需求，而应该在 AI 功能立项初期就纳入架构设计。用量记录、配额控制、成本预估、模型路由、异步任务处理，这些组件共同构成了 AI SaaS 的成本底盘。谁能更快把底盘打牢，谁就能在洗牌中占得先机。

对于工程师和产品经理来说，接下来的重点不是继续纠结“哪个模型最强”，而是想清楚：你的产品为客户创造了什么可量化的价值，以及你能否用可持续的毛利去交付这个价值。如果你喜欢这篇文章，可以收藏备用，也欢迎在评论区聊聊你对 AI SaaS 定价模式的看法。