第1890篇：技术创业的AI赌注——用大模型做产品的真实成本与收益

两年前，一个朋友找我说要一起创业，方向是用LLM做一个垂直领域的AI助手。

"这是个风口，我们得快。"他说。

我问他估算过成本吗？他说"模型API又不贵，产品做出来就能卖"。

我没有泼冷水，因为我自己也只是隐约觉得这件事没那么简单，但说不清楚具体哪里。

两年后，他的公司撑过来了，但走了很长一段弯路。我自己也在公司内部做了一个AI产品创业项目，从立项到商业化，经历了很多意想不到的成本和收益。

这篇文章是我对"用大模型做产品"这件事的真实成本与收益的梳理，没有渲染也没有唱衰，就是把账算清楚。

---

成本的真实构成：比你想象的多三倍

很多人在评估AI产品成本时，只算了模型API费用。这是最大的认知误区。

根据我们的实际经验，一个AI产品的成本大致分布是：

模型API费用只占了总成本的约25%。让很多人没想到的是工程开发成本，占了35%，是最大的一块。

模型API费用：比看起来贵得多

我们产品最初的设计是：每次用户提问，调用一次GPT-4o，Token消耗大约1500 input + 800 output。

按GPT-4o的定价（input $5/M tokens，output $15/M tokens）：

• 每次查询：1500/1000000 × 5 + 800/1000000 × 15 = $0.0075 + $0.012 = $0.0195

每次查询接近两分钱，听起来不多。

但我们日活用户2000人，每人平均每天8次查询，每天的API费用是： 2000 × 8 × 0.0195 = $312

一个月下来，API费用是 $312 × 30 = $9,360，接近7万人民币。

然后随着日活增长到5000，每月API费用超过了20万。

更大的隐藏成本是：我们实际的Token消耗比预估高了50%以上。原因是：

成本隐患一：Prompt比想象的长。

我们的系统Prompt（包含角色设定、输出格式要求、安全规则）有大约800个Token。RAG召回的上下文平均有2000个Token。加上对话历史（我们保留了最近5轮），平均input token远不止1500。

实际测量下来，平均input是4200 tokens，是估算的2.8倍。

成本隐患二：失败重试的额外消耗。

模型调用失败（网络超时、内容过滤、格式错误）会触发重试，每次重试都是额外的Token消耗。我们的重试率约8%，这部分成本不小。

成本隐患三：开发和测试阶段的消耗。

开发同学调试Prompt、测试新功能，这些都要消耗Token。我们跑一次评估集需要消耗大约5美元，每周跑几次，一个月下来不少。

// 我们后来做的Token成本追踪
@Aspect
@Component
public class TokenCostTrackingAspect {
    
    @Around("@annotation(TrackTokenCost)")
    public Object trackCost(ProceedingJoinPoint pjp) throws Throwable {
        LlmCallContext context = extractContext(pjp);
        
        long startTime = System.currentTimeMillis();
        LlmResponse response = (LlmResponse) pjp.proceed();
        long duration = System.currentTimeMillis() - startTime;
        
        // 记录每次调用的Token消耗
        TokenUsage usage = response.getUsage();
        double cost = calculateCost(usage, context.getModel());
        
        metrics.record(
            "llm.token.cost",
            cost,
            Tags.of(
                "model", context.getModel(),
                "feature", context.getFeatureKey(),
                "env", currentEnv,
                "user_tier", context.getUserTier()
            )
        );
        
        // 超出成本阈值时告警
        if (cost > 0.1) {  // 单次调用超过0.1美元
            log.warn("High cost LLM call: feature={}, model={}, cost=${}, tokens={}",
                context.getFeatureKey(), context.getModel(), cost, usage.getTotalTokens());
        }
        
        return response;
    }
    
    private double calculateCost(TokenUsage usage, String model) {
        // GPT-4o定价（美元/token）
        Map<String, double[]> pricing = Map.of(
            "gpt-4o", new double[]{5.0/1e6, 15.0/1e6},
            "gpt-4o-mini", new double[]{0.15/1e6, 0.6/1e6},
            "gpt-3.5-turbo", new double[]{0.5/1e6, 1.5/1e6}
        );
        
        double[] prices = pricing.getOrDefault(model, pricing.get("gpt-4o"));
        return usage.getInputTokens() * prices[0] + usage.getOutputTokens() * prices[1];
    }
}

工程开发成本：最被低估的部分

很多人以为用LLM做产品，只需要写一些调用API的代码，技术难度不高。

这个认知在Demo阶段是对的。在生产级产品阶段是错的。

我统计了我们团队在各个工程方向上的投入比例：

工程方向	占工程总投入比例	大多数人预估的比例
LLM调用和Prompt管理	15%	50%
RAG系统（向量化、检索、重排序）	20%	15%
评估体系建设	12%	5%
可靠性和降级机制	15%	5%
数据清洗和知识库建设	18%	10%
监控、可观测性	10%	5%
其他（认证、安全、合规）	10%	10%

"LLM调用和Prompt管理"只占了工程投入的15%。大部分时间花在了RAG系统、数据处理和评估体系上——这些都是"AI功能的支撑工程"，不是AI功能本身。

数据处理成本：一次性但不小

如果你的产品需要私有知识库（大多数B端AI产品都需要），知识库的建设成本是一次性大额投入。

我们有一个客户，他们的知识库来自历史客服工单（200万条）和产品文档（5000份PDF）。这些数据的处理过程包括：

• 格式转换和清洗（约3周工程师时间）
• Embedding向量化（200万条×平均500 tokens，按OpenAI embedding价格约$200，但需要做批处理工程）
• 质量校验和人工抽查（约1周工程师+业务专家时间）
• 持续的增量更新机制（长期维护成本）

这个数据处理过程消耗的人力成本，远超过了Embedding的API费用。

---

收益的真实图谱：不只是省了多少人力

谈AI产品的收益，很多人习惯算"省了多少人"。这个角度既不准确，也不讨好。

更准确的收益框架是：AI让哪些原本做不到的事成为可能，让哪些原本昂贵的事变便宜。

收益一：服务规模的扩张（而不只是成本下降）

我们有一个产品，是帮企业做合同初审的AI工具。

在用AI之前，企业只有3个法务人员，每周能审20份合同，积压严重。

用了AI之后，AI每天能处理200份合同的初审，法务人员只需要复核AI标注了高风险的30%，实际工作量反而下降了。

这里的收益不是"省了2个法务"，而是"审合同的吞吐量提升了10倍"。对企业来说，这意味着可以做更多的业务，而不是裁更多的人。

收益 = 在同等成本下，服务规模扩大了多少。

收益二：质量的提升（某些场景）

AI在某些任务上的质量，确实高于平均水平的人工。

我们做了一个对比评估：用AI审查合同找出的问题数，vs. 3个法务人员分别审查之后取平均，AI的召回率（找出了多少真实问题）比人工高约18个百分点。

不是所有场景都这样。在创意类任务、高度个性化的任务、需要深度领域知识的任务上，AI的质量通常不如高水平的专业人士。

在大量的、中等复杂度的、有明确标准的任务上，AI的质量稳定性往往优于人工（不会有坏心情、不会疲劳、不会粗心）。

收益三：响应速度（有时候比质量更重要）

这条很容易被忽视。

合同审查的例子：法务人员审一份合同需要2-4小时，AI需要45秒。对于一些时间敏感的商业场景（比如投标前需要紧急审查合同），这45秒 vs. 4小时的差距，价值远超过成本。

响应速度是一个经常被低估的收益维度。

---

真实的投资回报期：比预期长，但比预期稳

我们内部做AI产品的项目，从立项到实现正向现金流，大概花了18个月。

这18个月里，大致的资金投入分布是这样的：

• 前6个月：探索期，主要是工程投入，无收入。月均烧钱约40万（人力+API+基础设施）。
• 7-12个月：MVP上线，开始有付费用户，但收入远不够覆盖成本。月均净亏损约20万。
• 13-18个月：产品迭代，用户增长，规模效应开始显现。月均亏损收窄到5万以内。
• 第19个月：首次月度盈亏平衡。

18个月的总投入大约是560万人民币。

这个投入在我们的预算内，但比最初预估的"12个月内回本"慢了半年。

慢在哪里？主要是两个地方：

第一：客户教育成本高于预期。

我们的第一批企业客户，大概有60%在签合同前都要问"AI审查结果有法律效力吗"。这个问题的回答（没有，需要法务人员最终确认）每次都会让客户犹豫。我们花了大量时间在"改变客户认知"上，这是前期没有预估到的销售成本。

第二：产品打磨比预期花了更多时间。

AI产品有一个特殊性：用户对"偶尔出错"的容忍度远低于对传统软件的容忍度。传统软件错了是bug，AI出错是"AI不可信"。这种认知上的不对称，让我们不得不把产品打磨到更高的稳定性才敢推给大客户。

---

我的判断：什么情况下值得押注

做了这么长时间，我觉得用大模型做产品，有三类场景相对更值得押注：

场景一：处理量大、人力成本高、质量要求中等的重复性工作。

合同初审、客服问答、代码注释生成、会议纪要、数据报告撰写——这类工作的特点是量大、有明确标准、专业人士处理成本高。AI在这里有最稳定的ROI。

场景二：知识密集型的信息检索和整合。

企业知识库问答、技术支持、医疗咨询辅助——用户需要从大量文档中找到准确信息。AI在检索速度和覆盖面上有压倒性优势，而且用户对"不够完美的回答"有一定接受度（他们知道这是辅助工具）。

场景三：有差异化数据的垂直领域。

如果你能拿到某个垂直领域其他人拿不到的数据（行业专有数据、用户行为数据、历史决策数据），用这些数据做fine-tuning或RAG，能构建出通用模型很难复制的护城河。这比"我也在调用GPT-4"要有竞争力得多。

---

一个忠告：算清楚再下注

最后说一句可能不受欢迎的话。

现在有很多人进场做AI产品，有些人是因为真的看清楚了市场机会，有些人是因为"不上AI会落后"的焦虑驱动的。

焦虑驱动的决策，往往会在第一次遇到真实困难时失去后劲。当发现"做一个AI产品原来不只是调调API"，当API账单比预期高两倍，当用户说"这功能有点鸡肋"——这时候如果没有清醒的预判和足够的现金流支撑，很容易半途而废。

把账算清楚再下注，不是保守，是负责任。

清醒地进场，比冲动地进场，成功率要高很多。