并非一切都值得消耗Token：何时用AI，何时用确定性代码

当AI成了昂贵的锤子

在大语言模型（LLM）席卷软件开发的浪潮中，一种颇具争议的趋势正在浮现：似乎每一个功能、每一次数据处理、每一个逻辑判断，都要交给模型去完成。Hacker News 上的讨论文章《Not everything should cost a token》提出了一个值得深思的观点——不是所有任务都需要调用大模型，很多场景下确定性的传统程序才是更优解。

这种趋势的形成有其历史背景。2022年底 ChatGPT 的爆发式普及，让数以百万计的开发者第一次以极低门槛接触到强大的自然语言处理能力。与传统 NLP 工具相比，LLM 不需要标注数据、不需要训练流程，只需一行 API 调用便能完成过去需要数月工程积累才能实现的功能。这种"低摩擦"的技术体验，客观上催生了一种认知偏差：能用 LLM 解决的问题，就优先用 LLM。软件初创团队尤为明显——在快速验证产品假设的压力下，"一切交给模型"成为了默认的最省力路径，技术债与成本隐患则被推迟到增长期才被迫面对。

作者的核心论点可以概括为一句俗语的变体："当你手里只有一把锤子，看什么都像钉子。"如今许多团队手握 LLM 这把"万能锤"，便把本可以用几行代码、正则表达式或状态机解决的问题，也一股脑塞进模型的上下文窗口，付出 Token 成本、延迟成本和不可预测性成本。

Token经济学的隐性代价

每一次调用都是真金白银

将任务交给 LLM 绝非免费。每一次 API 调用都按 Token 计费，输入越长、输出越多，费用越高。对于高频、大批量的任务——比如格式校验、数据清洗、字段提取——如果全部走模型，成本会随调用量线性甚至超线性增长。

Token经济学的底层逻辑值得在此展开说明。Token 是大语言模型处理文本的基本计量单位，由 BPE（字节对编码，Byte Pair Encoding）等分词算法生成——它并非简单地等同于"字"或"词"，而是一种兼顾词频与词形的子词单元。BPE 算法起源于数据压缩领域，其核心思想是通过迭代合并高频字符对来构建词汇表：算法首先将所有文本拆解为单个字符，然后反复找出出现频率最高的相邻字符对并将其合并为新的子词单元，直到词汇表达到预设大小。这一过程使得常见词（如"the""is"）通常被表示为单个 Token，而罕见词则被拆分为多个子词 Token（如"unbelievable"可能被拆为"un""believ""able"三个 Token）。通常，一个 Token 约对应 0.75 个英文单词或约 1.5 个中文汉字，但标点、数字、代码符号等往往会被拆分为多个 Token，导致技术文档、结构化数据等内容的实际 Token 消耗远高于直觉估算。

值得特别指出的是，不同的 Tokenizer（分词器）策略会产生显著不同的 Token 消耗——OpenAI 的 tiktoken、Google 的 SentencePiece、以及 Hugging Face 生态中的各类分词器对同一文本的切分结果可能相差 20%-40%。这背后折射出分词器设计哲学的根本分歧：tiktoken 倾向于对 Unicode 字符进行字节级回退（Byte-Level Fallback），保证词汇表对任意输入的覆盖完备性；SentencePiece 则提供无监督子词分割的统一框架，支持 BPE 和 Unigram 两种算法，更适合多语言场景；而针对代码优化的分词器（如 CodeLlama 所用的分词方案）会对编程语言中的常见符号和关键字给予更精细的处理。这种差异在设计跨模型成本对比、迁移模型供应商时是一个容易被系统性忽略的陷阱，建议在方案设计阶段就将"Tokenizer 差异系数"纳入成本估算模型。

从定价结构看，主流模型如 GPT-4o、Claude 3.5 Sonnet 按输入/输出 Token 分别计费，且输出 Token 通常比输入贵 3-5 倍，这意味着"让模型输出详细结果"的场景成本会被额外放大。价格区间从每百万 Token 数美元到数十美元不等，高端推理模型（如 o1、Claude 3 Opus）的费率可达轻量模型的 10 倍以上。对于企业级应用，一个看似简单的数据处理 Pipeline，若每天处理百万条记录，月度 Token 成本可能轻松突破数万美元。这种"按量计费"的特性决定了：任务频率越高、数据量越大，使用 LLM 的边际成本就越难以忽视。值得注意的是，部分云厂商提供批处理（Batch API）模式，可以用更低价格换取更高延迟，但这只是缓解而非根治高频调用的成本问题。

更关键的是，这类任务往往有明确的规则和确定的答案。判断一个字符串是否是合法邮箱、把日期从一种格式转成另一种、根据固定规则路由请求——这些问题的解在几十年前就已经被计算机科学完美解决，且执行成本近乎为零。

延迟与不确定性：两大工程痛点

除了金钱成本，LLM 还带来了两个工程上的挑战：

• 延迟：一次模型推理动辄数百毫秒甚至数秒，而确定性代码的执行时间通常在微秒级。
• 不确定性：即便设置了较低的 temperature，LLM 的输出仍可能出现幻觉、格式偏差或偶发错误。对于需要 100% 可靠的关键路径，这种不确定性难以接受。

确定性程序与概率模型的本质差异根植于计算理论的不同分支。确定性程序（Deterministic Program）是图灵机模型的直接体现——相同输入必然经过相同的计算路径，产生相同的输出，行为完全可预测、可测试、可调试。正则表达式引擎、有限状态机（FSM）、SQL 查询优化器都属于此类，它们的正确性可以通过数学归纳法形式化证明。

LLM 则完全不同：它本质上是一个基于 Transformer 架构的概率分布估计器，输出实际上是对"下一个 Token"的概率采样。理解这一点需要稍微深入 Transformer 的推理机制：在每一步生成中，模型通过多头自注意力（Multi-Head Self-Attention）机制计算出整个上下文的权重分布，经过前馈神经网络变换后，在词汇表上输出一个 Logits 向量，再经 Softmax 归一化为概率分布。temperature 参数本质上是对这个 Logits 向量进行缩放——temperature 越低，概率分布越尖锐，高概率 Token 被选中的可能性越大；temperature 为 0 时退化为贪婪解码（Greedy Decoding），每步选取概率最高的 Token。然而即便如此，也仅能保证在单次模型版本内的确定性——模型权重的更新、底层 CUDA 内核的版本差异、甚至硬件浮点运算的精度差异（如 FP16 与 BF16 的舍入误差积累）都可能引入输出漂移（Output Drift）。

更复杂的是，LLM 供应商通常不对模型版本变更提前通知，这意味着今天通过测试的 Prompt，三个月后可能因模型静默更新而产生截然不同的输出。这种不透明性在工程上催生了一类新兴实践——LLM 回归测试（LLM Regression Testing）：团队维护一套"黄金标准"输入输出对（Golden Dataset），在每次模型升级或 Prompt 变更后自动运行，检测输出分布的显著偏移。部分团队还引入语义相似度指标（如 BERTScore、BLEURT）替代精确字符串匹配，以更鲁棒地捕捉功能性回归而非表面形式变化。在金融风控、医疗诊断、法律合规等对结果一致性有强约束的场景中，这种不可预测性不仅构成工程风险，还可能触发监管合规层面的实质性问题——部分行业的审计要求需要系统能够完整复现历史决策的计算过程，而概率模型天然难以满足这一要求。

确定性程序则恰恰相反：给定相同的输入，永远得到相同的输出，可测试、可验证、可调试。

何时用AI，何时用代码

适合LLM的场景

大模型的真正优势在于处理模糊性、非结构化和开放性问题：

• 自然语言理解与生成（摘要、翻译、对话）
• 从杂乱文本中抽取语义信息
• 需要"常识"或上下文推理的任务
• 规则难以穷举、边界模糊的判断

在这些领域，编写传统规则代码要么不可能，要么成本极高，LLM 的泛化能力带来了质的飞跃。以情感分析为例：传统方法需要人工维护一个包含数万条词条的情感词典，且对新词、网络用语、反讽表达束手无策；而 LLM 凭借在海量语料上习得的语言模式，能以接近人类水平理解细微的情感色彩变化。这种"涌现能力"（Emergent Capability）正是 LLM 区别于所有传统 NLP 工具的核心价值所在。

涌现能力指的是在模型参数量突破某一临界规模后，系统自发表现出训练数据和优化目标中并未明确要求的复杂能力——如少样本学习（Few-Shot Learning）、思维链推理（Chain-of-Thought Reasoning）、跨语言迁移等。这一现象由 DeepMind 和 Google 的研究团队在 2022 年的论文《Emergent Abilities of Large Language Models》中系统记录，研究发现某些能力呈现出非线性的"相变"特征：在参数量低于阈值时几乎为零，超过阈值后性能急剧跃升。

然而，这一图景并非没有争议。2023 年斯坦福大学的后续研究对"涌现"的不连续性提出了根本性质疑——研究者发现，当采用粒度更细的评估指标（而非粗粒度的离散准确率）时，能力提升实际上是平滑渐进的，"相变"在一定程度上是评估指标选择的人工产物，而非模型能力的真实突变。这场学术争论揭示了一个更深层的方法论问题：我们如何度量智能，直接影响我们对智能"何时出现"的判断。对于工程师而言，这意味着在引用"涌现能力"作为选型依据时，需要针对具体任务进行基准测试，而不能将学术论文中的泛化结论直接套用到生产环境——一个在 BIG-Bench 评测上展示出涌现能力的模型，在你的特定业务场景中可能表现平平。正是这种对能力边界的批判性认识，使得"何时用 LLM"的判断从直觉走向了工程化决策。

适合确定性代码的场景

对于规则清晰、结果可预期的任务，传统方案几乎总是更好的选择：

• 数据格式转换与校验
• 数学计算与统计
• 基于固定条件的路由与分支
• 结构化数据的解析与查询

一个理性的工程实践是：用确定性代码处理确定性问题，把 LLM 的算力留给真正需要智能的环节。 很多成熟的 AI 应用架构（如 Agent 工作流）也印证了这一点——让模型负责"决策"，把"执行"交给可靠的工具函数。

混合架构：更成熟的AI工程方向

这场讨论背后指向了一个更成熟的 AI 工程范式：混合系统（Hybrid Systems）。在这种架构中，LLM 不再是唯一的计算引擎，而是整个系统的"大脑"或"编排者"——它决定何时调用哪个确定性工具，而不是亲自完成所有低层次工作。

这样的设计既保留了大模型在处理复杂、模糊任务时的灵活性，又通过确定性组件保证了系统的可靠性、可预测性和成本效率。当下流行的 Tool Calling、Function Calling 以及各类 Agent 框架，本质上都是这一理念的工程化体现。

混合架构的技术实现涉及多个层次的工程设计，理解其原理有助于更好地做出架构决策。Tool Calling（工具调用）是当前主流 LLM API 的核心能力：开发者预先向模型注册一组函数的名称、参数签名与功能描述，模型在推理过程中若判断需要外部信息或执行特定操作，便会在输出中声明一个结构化的"调用意图"（通常为 JSON 格式），由宿主程序负责实际执行并将结果注入对话上下文，模型随后基于工具返回值继续推理。这一机制使得"语言理解"与"代码执行"得以在架构层面解耦。

LangChain、LlamaIndex、AutoGen、CrewAI 等 Agent 框架将这一机制系统化，构建出可复用的"LLM 决策 + 工具执行"分层组件体系。在学术层面，这种范式对应 2022 年 Google 提出的 ReAct（Reasoning + Acting）框架——模型交替进行思维链推理（Chain-of-Thought Reasoning）和工具调用动作（Acting），形成一个迭代式的感知-推理-行动循环。ReAct 的核心洞见在于：将语言理解与逻辑推理留在模型层，而计算、数据库查询、格式校验、代码执行等确定性操作则委托给可靠、高效的代码层。

从系统工程角度看，这种解耦还带来了一个重要的可维护性优势：确定性工具层可以独立进行单元测试和集成测试，其行为可以用传统软件工程的所有质量保证手段来验证；而 LLM 层的变更（如切换模型供应商、升级模型版本）只需重新评估决策路由逻辑，无需担心底层工具的正确性。这种"关注点分离"（Separation of Concerns）原则在 AI 工程中的应用，正是混合架构相较于端到端纯模型方案在工程可维护性上的核心优势。实测数据显示，这种混合架构相比"纯 LLM"方案，不仅能将 Token 消耗降低 40%-70%，还使整个系统的行为更易于端到端审计和单步调试——因为每一次工具调用的输入输出都是可记录、可重放的确定性事件。

值得一提的是，混合架构的设计并非没有自身的工程复杂度。工具注册数量的膨胀会引发"工具选择幻觉"（Tool Selection Hallucination）问题——当可用工具超过一定数量（经验上约 20-30 个），模型在工具选择准确率上会出现明显下降；工具调用链的深度增加也会累积错误传播风险，单个工具的失败可能级联影响整个推理链路。因此，成熟的混合架构工程实践还需要引入工具调用的超时熔断、结果校验、回退策略等防御性设计，而不能将"委托给工具"视为一劳永逸的解决方案。此外，多步工具调用链中每一步的延迟累加效应同样不可忽视：若一个 Agent 任务需要顺序调用 5 个工具，每次 LLM 推理耗时 1-2 秒，总端到端延迟可能超过 10 秒，这在实时交互场景中往往是不可接受的。工程师需要在任务分解的粒度、并行工具调用的可能性以及用户体验的延迟预算之间做出精细的权衡。

给开发者的三条务实建议

尽管原文在 Hacker News 上讨论热度不高，但它触及了 AI 应用开发中一个被普遍忽视的问题：过度依赖 LLM。在"言必称大模型"的氛围下，冷静评估每个任务是否真的需要智能，反而成了一种稀缺的工程素养。

这种稀缺性有其结构性原因。一方面，LLM API 的极低使用门槛压缩了工程师深入思考"是否应该用"的动力；另一方面，在以"AI 原生"为卖点的产品叙事中，技术选型本身承载了超出工程范畴的商业信号功能——有时候，使用 LLM 的价值不在于它解决了什么问题，而在于它传递了"我们是一家 AI 公司"的市场信息。识别并抵制这种认知偏差，是高级工程师区别于初级工程师的重要能力维度之一。

这种现象在技术社会学中被称为"技术信号效应"（Technology Signaling Effect）——技术选型不仅是工程决策，也是向投资人、客户和市场传递能力定位的叙事工具。历史上类似的现象曾多次出现：2010年代初的"大数据"浪潮中，许多只需 Excel 就能处理的数据分析任务被强行迁移到 Hadoop 集群；区块链热潮期间，大量并不需要去中心化信任机制的系统被套上"链上"架构。每一轮技术热潮都会催生这种"技术过度使用"的模式。

更深层的机制在于，技术选型决策往往不是由直接承担工程成本的人做出的——产品经理、投资人或市场团队推动了"AI 化"叙事，而工程团队则要承担由此带来的额外复杂度和运营成本。这种决策权与成本承担的错位，是技术信号效应得以持续的根本原因。从组织行为学的角度看，打破这一错位需要两个结构性条件：其一是将 LLM API 的费用直接归因到发起调用的业务线（而非由基础设施团队统一承担），让决策者感受到真实的成本反馈；其二是在技术评审（Tech Review）流程中引入"替代方案论证"环节，要求提案者说明为何传统方案不适用。这两个机制合力，才能在组织层面建立起对技术过度使用的系统性抵抗力。识别当前正处于哪个技术浪潮的哪个阶段，正是技术领导者的核心判断力之一。

以下三条建议值得每位开发者收藏：

1. 先问自己：这个问题有确定答案吗？ 如果有，优先考虑传统代码。
2. 量化 Token 成本。 在高频场景下，哪怕单次调用便宜，累积起来也可能是一笔可观开支。建议在系统设计阶段就建立成本模型，以日/月调用量乘以平均 Token 消耗测算峰值费用，并为每个 LLM 调用点设置成本上限预警。
3. 把 LLM 当作最后手段，而非第一选择。 让它专注于那些只有它才能做好的事情。具体而言，可以在代码审查（Code Review）流程中增加一项检查：对每个新增的 LLM 调用，要求开发者说明"为什么这个任务不能用确定性代码实现"——这个简单的问题往往能过滤掉大量不必要的模型调用。

归根结底，工程的本质是用合适的工具解决合适的问题。LLM 是一项强大的技术，但强大不等于万能。识别出哪些任务"不值得消耗 Token"，恰恰是构建高效、经济、可靠 AI 系统的第一步。

核心要点