【小庄的AI踩坑笔记05】这个不用 AI

锤子定律推行之后，团队少走了很多弯路。但小庄发现，还有一类问题——锤子定律管不了。不是"用锤子还是用规则"的选择。而是——这个活，AI 根本不该接。

场景

产品经理找上门。说要做一个"智能报价"功能。需求很简单：用户输入产品型号和数量，系统给出一个报价。小庄第一反应是——这不就是个查表 + 计算的事？产品经理说："但老板要 AI 化。"小庄问："你说的个性化，是不是就是：大客户打九折，新客户不打折？"产品经理想了想："差不多。"小庄说："那这就是一个 if-else。"产品经理："但 if-else 不够智能。"小庄没有争辩。他回去做了一组对比实验。

对比实验

同一个报价任务，三种实现方案：

方案 A：纯 LLM。

prompt："你是一个报价助手，根据以下产品信息和定价规则给出报价。"配上产品价目表和折扣规则。模型选了一个中等规模的推理模型，temperature 设为 0.1。测试样本：1000 条真实历史报价请求。

结果：准确率 96.3%。3.7% 的请求算错了——忘了应用折扣、数量乘错、货币单位错误。P50 延迟 800ms，P99 延迟 2.3s。成本：每次约 2000 token，日均 5000 次 = 每天约 80 元。

方案 B：规则引擎 + 数据库查询。

一张产品定价表（PostgreSQL）+ 23 条折扣规则（if-else）。结果：准确率 100%。P50 延迟 0.3ms，P99 延迟 1.2ms。成本 0。每条报价都能追溯到具体的定价记录 ID 和折扣规则编号，审计时可导出完整决策链路。

方案 C：LLM 生成文案 + 规则计算报价。

报价用规则引擎算，但用 LLM 给每个报价生成一段个性化推荐理由。结果：报价准确率 100%，总体 P50 延迟 600ms，每天成本约 20 元。用户满意度比方案 A 高了 15%。

产品总监看完之后说："用方案 C。报价必须准，但文案可以个性化。"小庄做了一个关键发现：方案 C 的思路才是正确的。不是"LLM vs 规则"的二选一，而是"LLM 做什么 + 规则做什么"的组合设计。

LLM 擅长：开放生成、语义理解、意图识别、多轮对话、创意写作
规则擅长：精确计算、格式校验、权限控制、状态机、路由分发
两者结合：LLM 提取参数 + 规则校验 + LLM 生成回答 + 规则过滤敏感词

五条不可用

这件事之后，小庄列了一个"AI 不可用清单"。满足以下任意一条，就不要用 AI：

不可用1：需要 100% 正确率。

计算、校验、格式验证。LLM 是一个概率模型，输出是"最可能的"不是"正确的"。技术原因：LLM 的 tokenizer 把数字拆成 token 片段，模型做的不是算术运算，是 token 预测。遇到训练数据里没有的数字组合，它就会猜。

不可用 2：延迟要求 < 100ms。

实时排序、广告竞价、风控拦截。一个 70B 参数的模型，即使用 FP8 quantization + 4 张 H100 + PagedAttention + KV Cache 优化，TTFT 也要 50-100ms，完整输出 500ms 以上。这是物理限制。对比：规则引擎 0.1ms，XGBoost 0.5ms。差了 1000 倍。

不可用3：需要可解释的决策过程。

合同审核、合规检查、审计、医疗诊断建议。LLM 的解释是生成的，不是推导的。学术上叫"rationale hallucination"（理由幻觉）：模型不管答案对错，都能编一个听起来合理的理由。审计要求的是"因为 A 且 B，所以 C"的逻辑链条。

不可用4：有成熟的确定性算法。

排序（PageRank）、搜索（BM25）、推荐（协同过滤）、分类（朴素贝叶斯 / SVM / XGBoost）。这些领域有几十年研究积累。LLM 可能提升 2-3% 的准确率，但成本增加 1000 倍，延迟增加 1000 倍。除非那 2-3% 值 1000 倍的成本，否则不值得。

不可用5：成本敏感的高频任务。

日均 > 10000 次的任务。算一笔账：日均 10000 次 x 2000 token x 0.01 元/千 token = 每天 200 元 = 每年 7.2 万。规则成本是零，小模型（DistilBERT）每年约 1800 元。差距 7 万块。

替代方案矩阵

小庄给每个"不可用"场景配了一个替代方案：

精确计算 → 规则引擎 + 数据库查询 + 单元测试实时决策(< 100ms)
传统 ML（XGBoost / 逻辑回归）可解释决策
规则引擎 + 决策树 + 审计日志成熟算法场景
已有算法（BM25 / PageRank / 协同过滤）高频低成本
缓存 + 规则 + 小模型（DistilBERT / TinyLlama）

关键不是"不用 AI"，而是"把 AI 留给值得的场景"。

决策框架

小庄把这个清单整合成了一个"AI 适用性评估表"。每个新功能立项时填写：

Q1：需要 100% 准确率吗？ 是 → 不用 LLMQ2：延迟预算 < 100ms 吗？ 是 → 不用 LLMQ3：决策过程需要可解释吗？ 是 → 不用 LLMQ4：有成熟的传统算法吗？是 → 先用传统算法，评估 LLM 边际收益Q5：日均调用量 > 10000 吗？是 → 先考虑规则或小模型

五个问题都回答"否"的，才进入 LLM 方案评估流程。推行之后，团队立项速度变慢了——因为需要先想清楚"这个活适不适合 AI"。但上线后的问题率降低了 60%。

成本账

小庄做了一次完整的成本审计。每月 AI 总成本 12 万元：7.2 万花在"不可用清单"上的 9 个功能，用规则替代后成本为零。3.6 万花在"可用但可以用小模型替代"的 6 个功能，换成 7B 小模型可以降到 1.2 万。只有 1.2 万花在"必须用大模型"的 2 个功能（文案生成、代码补全），这些确实值。

12 万 → 1.2 万。90% 的 AI 成本是花在不需要 AI 的地方。这个数据后来成了小庄推动"AI 瘦身"最有力的论据。

真正的智能

小庄后来在团队分享会上说了一句话：

"真正的智能不是’什么都能用 AI‘。真正的智能是知道什么时候不用 AI。"

他举了一个例子。好的厨师不会因为手里有一把新刀，就把所有食材都用那把刀处理。切菜用刀，打蛋用打蛋器，磨胡椒用研磨器。工具多不代表每个活都要用最贵的那个。

AI 是当前最贵的工具。贵在三方面：

金钱成本：每次调用都有 token 费用，积少成多。
时间成本：延迟是毫秒到秒级，比传统方案慢 1000 倍。
信任成本：输出不可预测，需要额外的校验和兜底。

然后，小庄设定了使用AI架构的三条原则。

AI 架构三原则

原则一：确定性优先。

系统中任何可以用确定性方法解决的环节，都应该用确定性方法。LLM 只应该出现在没有确定性方法的地方。这条原则的本质和工程领域的"最小惊讶原则"一致：用户和开发者都应该能预测系统的行为。

原则二：分层隔离。

LLM 层和规则层应该分层隔离。LLM 的输出不能直接进入下游业务逻辑，必须经过规则层的校验。分层的目的是控制故障面：LLM 出错时，规则层能兜住；规则层出错时，不影响 LLM 的生成能力。

原则三：成本透明。

每个 AI 功能的 token 消耗和成本必须可观测、可告警。设月度成本上限，超过上限自动降级到规则或小模型方案。防止"AI 成本漂移"——随着调用量增长，AI 成本悄无声息地膨胀。

所以它应该被用在最值得的地方——那些规则写不出来、计算算不出来、传统算法做不好的地方。生成文案、开放式问答、复杂推理、多轮对话、创意写作。这些是 AI 的舒适区。报价、计算、排序、分类、格式转换、合规检查。这些不是。

会做加法的人不厉害，知道什么时候不需要做加法的人才厉害。