我们在询问 AI 的用途之前，就先优化了 LLM 成本

我经营一家小型 AI 咨询公司，在做了 8 年软件之后，上个月的一次会议仍然让我耿耿于怀。一位客户带我看了他们的仪表盘，显示经过一次优化冲刺后，他们每月的 LLM 支出下降了近 60%……这里换更便宜的模型，那里加缓存，提示词也被精简到极致。这是很好的工程实践，我也这么说了。然后我问，这个系统现在在哪些事情上变得更便宜了？房间里沉默了一秒钟。没人知道，因为没人追踪这个。说实话，我不评判。我自己也做过完全一样的事。账单让人不舒服，你就会拉动你知道该怎么拉的杠杆，然后感觉自己像个负责任的成年人。某种程度上你确实是。这是真正的工程。只是跳过了那个问题：这个任务到底应不应该交给语言模型。所以我们审计了他们的管道。我们打开的第一个工作流是让 LLM 读取收到的支持邮件以提取订单号，按每千条消息计费。而订单号就在主题行里，每次格式都一样，因为是他们自己的系统放进去的。说实话，这最多是一行代码或一个正则表达式。我们挖得越深，就越发现模型在掩盖上游的某些问题，比如一个本该在几年前就改成下拉框的自由文本字段。那种工作是对一个没人修复的流程征税，而模型只是收税的方式。我认为这背后是这样的：每个人都衡量每 token 的成本，因为仪表盘免费把那个数字递给你；但每次成功结果的成本，你得自己去拼装——从工单和某人失去的下午里——所以它大多数时候根本不会被计算……这很可惜，因为一旦你把它写下来，算术是残酷的。一个便宜的模型在 100 次里错 15 次，如果那 15 次需要人工悄悄修正，它就不便宜了。修正时间躺在另一条预算线上，永远不会靠近 API 账单。与此同时，那个更贵的模型在 100 次里只错 3 次，最终可能成为整体上更便宜的系统，而你还永远不会从 token 仪表盘上得知这一点。在你下一次成本冲刺之前，试试这个：把你最贵的 3 个 AI 工作流拿出来，写下每次成功结果的完整成本，包括人工修正的分钟数。然后对每一个问：是否可以用一条规则、一个表单改动（或者老实说，一个人）以更低的成本获得同样的结果？这个客户本季度最大的节省不是换模型，而是一个下拉框 + 删除那个原本用来清理旧自由文本字段的工作流。我不反对 LLM，我靠它谋生。但我已经开始收集那些“AI 是解决问题最昂贵方式”的故事，所以请告诉我你的故事。我的故事是那个订单号读取器，直到一位朋友提到一家公司用 GPT 来检查表单字段是否为空，而我不相信那是上限。