终端里读陌生代码：用六种提示模式省下解释成本

先锁定一个问题，别让模型讲完整个仓库

接手陌生服务时，我最容易浪费的钱，不是模型单价，而是一句“解释这个项目”。它通常换来目录复述、框架常识，以及下一轮重新提问。现在我先在编辑器里标出困惑，再用终端找入口：搜索函数名、查看调用点，只提交能回答当前问题的片段。

我的预算单位也从“一次请求多少钱”改成“解决一个疑问多少钱”。便宜但反复跑偏的解释，未必比一次有证据的回答省钱。下面六种提示模式，适合直接放进日常代码阅读流程。

模式一：给解释设定边界和停止条件

提示：“我需要理解订单取消为何返回冲突。只分析下面的处理函数和直接依赖，不介绍框架。先用三句话概括输入、状态变化和返回值，再列出与冲突有关的分支。缺少证据时指出需要哪个文件，不要猜测。”

提交前保留文件路径和行号，删除密钥、客户数据及无关日志。行号让回答可以核对；明确“不介绍框架”，则能减少我已经知道的背景内容。不要为了省输入删掉错误处理，它往往正是行为差异的来源。

模式二：要求沿一个真实输入走读

提示：“假设订单处于已支付状态，用户连续提交两次取消请求。沿当前代码逐步追踪，每步写出条件、状态读写和返回结果。区分代码能够证明的行为与需要运行验证的行为，总共不超过八步。”

比起逐行翻译，这种问法更容易暴露事务边界、幂等判断和提前返回。如果涉及并发，继续限定：“只分析两个请求交错执行的情况，指出锁或原子操作的证据。”不要让模型把顺序执行的推演当成并发保证。

模式三：让模型申请最小补充上下文

提示：“如果现有片段不足以解释冲突，请最多提出三个补充请求。每个请求必须包含符号名、需要它的原因，以及它能排除哪一种解释。暂时不要给最终结论。”

我会先检查它要的内容，再补相关定义，而不是直接开放整个仓库。排查状态判断时，枚举定义和查询条件可能足够；整份依赖锁文件通常没有帮助。这一步用很短的问答，避免下一轮塞入大量无关文本。

模式四：把解释压成可以验证的断言

提示：“根据现有证据，写出三个可验证断言，每条注明文件与行号，并给一个最小测试场景。把事实、推断和未知项分开；没有看到实现的函数，不得假定它的副作用。”

接着我会运行已有测试，或者补一个最小用例。解释听起来流畅，不代表它成立。测试失败后，只回传失败信息和相关代码差异，让模型修正具体断言，而不是重新生成整篇讲解。

模式五：按问题难度升级，不按焦虑升级

普通控制流可以先试 DeepSeek V4 Flash；遇到跨文件状态约束，再让 Claude Sonnet 5.5 复核尚未解决的争议。这里不是保证哪一个更准确，而是先用少量代表性问题记录正确率、耗时和实际费用，再决定默认配置。

Fluxo 用一把密钥和一个基础地址 https://api.fluxorelay.com 接入多个模型系列，切换时不用重写接入代码。它可配合 Claude Code、Codex、Gemini CLI 以及任何 OpenAI SDK 使用；不过，各工具的地址配置方式和模型功能支持仍要分别检查。

模式六：固定上下文，追问只发送增量

提示：“沿用已经确认的函数职责，只解释这次差异如何改变取消条件。不要重复之前的摘要；若旧结论失效，指出失效原因。”稳定的项目约定放在前面，变化的代码和问题放在后面；工具支持会话复用时，也别反复粘贴相同文件。

Fluxo 没有月费，按真实令牌计费，缓存读取和写入也计入账单。因此，缓存命中不等于免费，更不能只凭输入变短就认定省钱。我会记录输入、输出、缓存读写和最终费用，比较同一问题的完整解决成本。

如果你想把这套流程放进自己的终端，可以创建一个 Fluxo 账户，从一个小问题开始记录。邀请他人后，对方付费可带来推荐分成；我会把它与调用成本分开记账，避免收益掩盖低效请求。真正稳定的节省，还是来自范围清楚、证据可查、到点停止的解释。