试一个模型，看它惊艳的那一下就行。把它变成每天要跑一万次的活儿，判断标准完全换了一套：不是谁更聪明，是谁更稳、更便宜、更不容易哪天用不了。我踩过三个坑，都是尝鲜时完全看不到的。
第一个坑是可用性。试用时你打开网页就能聊，真放到流程里才发现它比你想的脆。我们那阵子有个任务每分钟调一次，某天开始大量超时，查了半天是服务端在限流。后来我给自己定了规矩：任何要长期跑的调用必须有重试加降级，主模型失败就切备用，绝不能让它卡住整个流程。 ChatGPT 和 Claude 的能力都很稳，但再好的服务也不是百分百，留一条路是工程问题不是信任问题。
第二个坑是价格。同一个模型，试用和个人订阅的价格跟走 API 的量级价差很大。我们一开始按订阅算成本，后来量上来改成按调用计费，账单翻倍。算清楚单价是输入还是输出更贵很关键，长输出的任务贵得离谱，我后来给输出加了上限，成本立刻下去三成。 Gemini 在长上下文那一档性价比不错，适合材料特别长的活， Grok 在要实时性的场景有优势。别只比月费，要按你的单次调用量折算。
第三个坑是断供。这话不好听，但长期用海外模型就得接受一件事：政策一动，你的流程可能随时要改。我试过某天一个接口突然不给调用，我们的批量任务全停了半天。从那以后任何长期依赖都配一个国内备胎，接口层做好适配，切换只是改个配置。 OpenRouter 这类统一入口在这里能省事，它把多家接在一处，不至于一家变了你从零写。
稳定性还有一层是版本。模型升级后行为可能悄悄变，同样的提示词输出风格不一样了。我们吃过一次，输出突然变啰嗦，下游解析全乱。后来我把版本号锁死，升级先拿一小批真实样本跑一遍，确认没退化才放全量。这条规矩现在写进了发布流程。
再往细说，提示词也要跟着版本走。不同版本对同一段指令的理解有差别，我把常用指令存成库，每次换版本就拿老版本复核一遍，看有没有被改坏。这不是洁癖，是省事后排查的时间。
延迟也是长期指标。试用时你感觉不到，批量堆上去才知道。我们有个任务要串行调七次，单次慢两秒，整体就慢了十几秒，用户体验一下就差了。后来我把它拆成并行三路再合并，同样的模型，时间砍到三分之一。
缓存能省不少。同样的材料每次都问一遍是浪费，我们把稳定不变的那部分先问一次存下来，只有变化的部分才重新调。这一改动了接口结构，但每个月省下的钱够开好几个账号。
输出格式要自己兜底。指望模型每次都返回规整的 JSON，迟早会有一版给你多返回一个字段。我们解析端做了容错，坏格式走重试加修复提示，第二轮基本都能出来。把容错做在代码里，别做在提示词里，提示词救不了坏数据。
合同和合规这块得有人拍板。真要把海外模型放进对外交付的东西里，先确认数据能不能带出去、要不要标注。这不是技术问题，拖到出事再补成本很高。我们最后是内部用不限，对外交付的用国内模型，边界划清楚。
真要长期跑，我建议从第一天就做三件事：锁版本、留备份、记日志。锁版本防止行为突变，留备份防止某天取不回来，记日志让你出问题知道是哪一环。这三件都不难，难在开工就想起来。
还有个便宜的保险是双写。重要输出让主模型和备各跑一遍，结果一致就采信，不一致再人工看。双写的额外成本不到两成，但能挡住绝大多数静默错误，比事后排查便宜太多。
退路不是悲观，是成本很低。多接一家接口、多存一份输出、多写一层适配，加起来不到两天。等真要用的时候，这不到两天能救你一整天。
你那个流程每天大概调多少次、怕不怕哪天用不了？告诉我量级，我帮你算算该走订阅还是按量，备用该配哪一个。