大语言模型使用成本问题凸显并非所有提示都是相同的。通过将简单的提示路由到更便宜的模型能在令牌成本上节省一大笔钱。图片来源Shutterstock Gen AI作为资深的 Delphi 开发者对当年和 Visual Basic 开发者之间的“语言战争”记忆犹新。Delphi 早期代号是“VBK”即“VB 杀手”这引起 VB 社区不满他们会到 Delphi 论坛挑起争端而 Delphi 开发者也会反击引发激烈口水战。那些日子令人怀念。如今讨论更上层次——哪种模型更适合用于编码虽现在争论没当年 VB 和 Delphi 之争激烈但大家各有看法。企业在为团队选择模型前会对不同模型进行评估大多数团队已选定常用的一系列模型。有时与 Claude 或 Codex 聊天体验欠佳。不久后像 GStack 和 Superpowers 这样的脚手架工具开始为与大语言模型LLM交互提供基础支持即在提示到达模型本身之前对其进行基本处理。这些工具有助于建立有用的上下文就像在“原始提示”之上增加一层。上下文工程是在聊天界面之上添加的第一层也是最常见的一层。选定模型和工具后大家追求令牌使用最大化。但账单寄来时管理者不高兴了。随着成本飙升领导层担心钱没花在刀刃上。模型路由下一层解决方案就像汇编语言和手动调整寄存器被编译器和结构化语言取代进而发展出框架和库最近又出现大语言模型和提示工程一样开发者和管理者开始意识到有更好方法管理大语言模型使用成本。但自然地刚弄清楚事情运作方式新的一层就会出现让辛苦积累的知识过时。显然仅能用英语编写代码不足以阻止下一次抽象出现。所以又一层抽象出现了。世事皆如此。因此模型路由成为让每一分令牌成本都发挥最大价值的最新方法。其理念是并非所有提示都需要同等处理能力。向 Claude 提出的问题并非都需要前沿模型深度思考。模型路由器可以分析提示内容决定哪个模型最适合回答该提示并将查询导向该模型。也许简单请求更适合用旧模型处理也许代码审查用专门为此设计的模型效果更好。模型路由可以提高令牌使用效率。如今使用 Claude Code 时必须为整个会话选择一个模型若想用顶级模型无论最终做什么都得为此付费。而模型路由器可以让灵活选择模型从而控制成本。像 Coinbase 这样的公司在令牌使用量增加的同时AI 支出却减少了一半。从令牌最大化到令牌匹配大语言模型不断发展功能越来越强大也越来越专业化。将提示路由到既适合任务又具有成本效益的模型是提高令牌使用效果的关键。目前团队是手动进行这项工作的但未来人工智能本身将成为做出此类决策的最佳方式。例如Claude Code Router 可以根据每个提示所需的工作类型将其路由到多个流行模型中的任意一个而且它是开源的。接下来出现的将是提示预处理。可以努力编写好的提示但人工智能本身可以对提问进行优化。提示工程中最好的技巧之一就是告诉大语言模型“提出我没问但应该问的问题”。不难想象未来写出一个提示人工智能会帮助澄清、完善它然后将其路由到最合适、最具成本效益的模型来获取答案。将不再需要选择特定的大语言模型提供商而是可以专注于明确表达自己的需求。所以别再为特定模型手工编写提示了让即将出现的模型路由器和提示预处理器为完成这些繁琐的工作吧。人工智能、开发工具、生成式 AI、软件开发该何去何从呢
