终端里第三次问到同一个报错后，把答案写进共享运行手册

从第三次出现的终端报错建档

同一个依赖安装错误，周一在自己的终端问一次，周三替同事再问一次，周五换个分支又贴一遍日志。每次答案都差不多，却重新支付了上下文和输出成本。真正值得优化的，不是把提问缩短两行，而是让已经验证过的答案不必重新生成。

我的做法很简单：同一个问题出现第三次，就在仓库的 docs/runbooks 目录建档。先处理安装失败、测试环境差异、鉴权报错这类高频问题，不急着建设知识平台。文件跟代码一起提交，编辑器能搜，终端能查，修改也有历史。

把聊天答案压成可执行的排障条目

直接保存整段聊天记录没有多大用处。聊天里混着猜测、失败尝试和已经过期的环境信息，下一位开发者仍然需要模型重新解释。运行手册应当保留经过验证的最短路径，而不是保存思考过程。

• 每个条目都写明报错特征、适用版本和触发条件，让同事能够判断是否真的遇到了同一问题。
• 每个修复步骤都附上执行位置、预期结果和失败后的分支，避免读者只能继续猜下一步。
• 涉及数据库迁移或者配置覆盖时，必须注明风险、回滚办法以及需要人工确认的操作边界。
• 条目末尾记录验证日期、关联提交和维护人，方便环境变化之后找到需要重新检查的内容。

例如，处理本地服务鉴权失败，先检查变量是否存在，再确认进程是否读到新配置，最后才检查网关。记录变量名和检查办法即可，不要把密钥、客户数据或完整请求头写入仓库。

先用终端检索，再决定是否调用模型

我会先运行 rg -n '鉴权|401' docs/runbooks，找到对应条目后按步骤执行。能直接解决，就不调用模型；不能解决，再把条目、当前差异和脱敏日志一起交给模型。这里省下的不只是 token，还有模型重新猜测项目约定的时间。

在项目的代理说明中也写清楚这个顺序：先检索运行手册，再检查适用条件，只执行获得授权的操作；没有匹配项才继续排查。不要要求代理每次读取全部文档，否则只是把重复聊天换成重复灌入整个知识库。

给重复排障设置模型升级门槛

格式整理、提取报错特征、把已验证步骤改写成条目，可以先交给 Claude Haiku 4.5。遇到跨服务调用链、证据互相矛盾或修复风险较高的情况，再考虑 Claude Sonnet 5.5。这个分工是待验证的策略，不代表某个模型必然更便宜；最终仍要看实际价格、输出长度和重试次数。

我在 Fluxo 使用一个密钥和一个基础地址 https://api.fluxorelay.com，按工具配置接入 Claude Code、Codex、Gemini CLI 或任意 OpenAI SDK。Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等系列可以沿用统一入口，切换时不用顺便重写一套调用逻辑，但仍需检查具体接口的能力差异。

把缓存账单与少调用的收益分开算

Fluxo 没有月费，按实际 token 用量计费，缓存读取和写入也计入账单。因此，缓存命中不等于免费，更不能代替减少无效请求。对于支持缓存的调用，把稳定说明放在前面，把本次日志放在后面，并检查实际用量记录，确认是否真的发生了缓存读取。

我的统计表只保留几个字段：问题类别、请求次数、输入与输出用量、缓存读写用量、最终是否解决。费用按对应模型的实际费率分别计算，不把不同计费项混成一个平均单价。运行手册的维护时间也要记，否则只是把 API 支出转移成了人工支出。

每周合并一次答案，而不是积累聊天

每周看一次重复问题：哪些条目真正减少了调用，哪些因为版本变化已经失效。修复合并时顺手更新手册；涉及生产操作的条目，交给熟悉系统的人审查。判断成效看重复问题的调用次数是否下降，同时确认解决速度和安全性没有变差。

想把这套流程接进现有终端，可以创建一个 Fluxo 账号，先选一个高频问题做小规模记录。若之后邀请同事使用，被邀请者付费时会产生邀请分成；我会把这笔收入单独记账，不用它掩盖实际推理成本。最可靠的节省，仍然是下一次有人遇到相同报错时，打开手册就能继续写代码。