终端频繁断线时，把 AI 调用费用花在有效改动上

终端频繁断线时，把 AI 调用费用花在有效改动上

我最不喜欢的开发现场，是测试已经跑完，终端里的 AI 回复却停在半句话。光标还在闪，不知道该等还是重发。手快连按几次，网络恢复后又收到几份差不多的答案：时间没省，账单反而多了。

弱网下省钱，重点不是寻找一个神奇的超时值，而是减少重复计算，让每次请求都能留下可继续使用的结果。我的习惯是先把任务拆小，再决定哪些内容值得发出去。

发请求前，先在本地把问题缩到一个补丁

遇到失败测试，我先检查差异、运行单个测试、截取相关错误栈，而不是把整个仓库和全部日志交给模型。日志里重复的警告、构建进度和依赖清单，通常只会增加上传时间与输入令牌。

• 每次请求只处理一个明确问题，并写清允许修改的文件和验收条件。
• 发送错误日志前先保留关键调用链，同时删除密钥、令牌和个人信息。
• 要求先返回最小补丁和验证命令，不要默认生成整份文件或长篇背景介绍。

例如修复配置解析错误，我会附上解析函数、失败输入和断言，要求“只改这个函数，不新增依赖”。边界越明确，断线后的恢复范围也越小。

用一个入口整理终端配置，不把切换变成重复劳动

我把不同项目的连接配置集中管理。Fluxo 用一个密钥和一个基础地址 https://api.fluxorelay.com 接入多家模型，覆盖 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等系列，也能配合 Claude Code、Codex、Gemini CLI 和 OpenAI SDK 使用。不同工具的配置字段与接口要求仍需分别核对，不能只改地址就假定全部兼容。

统一入口方便排查配置问题，但不能修复本地 Wi-Fi 或运营商丢包。密钥放在环境变量或本地密钥管理工具里，不写进仓库；网络异常时，也先检查连通性，再怀疑模型。

给重试设预算，别让一次超时变成三次账单

客户端超时，不等于服务端没有接收请求，也不等于生成已经停止。因此，我不会把所有错误都交给无限重试。尤其是已经收到部分输出的请求，直接重发可能重复消耗令牌。

• 检查 SDK 和外层脚本各自的重试配置，避免两层机制叠加放大请求次数。
• 只对适合重试的临时故障设置有限次数，并采用带随机抖动的退避等待。
• 遇到限流时优先遵循服务端返回的等待提示，不用并发请求强行撞过去。
• 认证失败和参数错误应先修正配置，不要通过自动重试重复提交相同请求。

我的交互脚本通常最多自动重试一到两次，并记录时间、状态码与可用的请求标识。需要人工接手时，至少能知道发生过什么。除非接口明确支持，否则不要假设相同请求会自动去重。

流式输出先落盘，断线后只补缺失部分

流式响应能更早看到内容，但不保证总耗时或费用更低。我会把已收到的文本持续保存到本地，同时标记任务是否完整结束。连接断开后，先读保存结果，再决定补问，而不是直接重新生成全文。

如果只收到半个补丁，就不要立即应用。先检查格式与上下文，必要时附上已有片段，请模型仅补齐缺失部分。涉及文件修改或命令执行时，还要先检查工作区，避免重试把同一操作执行两遍。

缓存和模型选择，都按实际账单验证

Fluxo 没有月费，按实际令牌用量计费，其中包括缓存读取与写入。缓存不是免费输入：是否支持、怎样命中以及具体价格，都要按所用模型和接口确认。对于支持缓存的调用，可以保持稳定说明与公共上下文不变，把本轮差异放在后面，再查看用量记录是否真的命中。

简单的日志归类可以先试 Claude Haiku 4.5；跨模块分析再评估 Claude Sonnet 5.5。这里不是固定的能力或价格排名，而是给任务设置不同预算。拿自己的测试集比较一次成功率、总令牌和重试次数，比只看单次报价可靠。

把等待时间换成本地验证，而不是继续排队

网络变差时，我会暂停新的远程任务，转去跑测试、整理复现步骤或审查已有差异。当天收工前再核对调用记录，找出哪些费用来自重复上下文、过长输出或失败重试，下次只改最明显的一项。

如果你想把这套流程放进现有终端，可以创建一个 Fluxo 账号，先用一个小任务记录耗时和用量。邀请他人后，对方付费时你可获得推荐分成，但做预算时不要把它当作确定的费用抵扣。配置遇到问题，可以登录后在联系页面留言。

弱网下真正省钱的工作流，是请求足够小、结果能保存、失败可定位。这样下一次连接恢复时，你继续推进代码，而不是重新购买刚才已经做过的工作。