Copilot credits 怎么用才不浪费
数据截至 2026-07，价格与限额以各官网为准。
Copilot 的 credits 扣的是 token，不是提问次数，所以”少问几句”几乎省不下什么，真正决定账单的是每次提问带进去多少上下文、用哪个模型接、以及有没有一堆你根本没在看的自动化任务在后台替你花钱。 把注意力从”控制频率”挪到”控制单次成本结构”上，同样的工作量花掉的额度可以差出一大截。
一个流传很广的误解是：额度快用完的时候，工具会自动帮你退到便宜一点的模型继续用，顶多是变笨一点。这条退路并不存在——按官方说明，额度耗尽时没有自动降级到便宜模型的机制，如果没有开放超额，就是直接阻断到下个周期。这意味着省额度这件事只能提前做，不能等出事再补救。
一、先确认你扣的是 credits 还是老的请求次数
2026-06-01 起 Copilot 全部计划转为按用量计费（usage-based billing），用 GitHub AI Credits 替代原先的 premium requests 计数，1 credit = 1 美分。用量按 token 消耗计算（输入、输出、缓存 token 都算），再按各模型的 API 费率折算成 credits。
但有一类人不在这套制度里：年付的 Pro / Pro+ 用户在当前计划到期前仍然走 premium request 制，月付用户则在 2026-06-01 自动迁移完成了。这个区别很重要，因为两套制度下”省”的方法完全相反——请求次数制下你省的是提问次数，token 制下你省的是上下文长度。如果你还在年付老制度上，这篇后半部分的很多动作对你的账单不会有直接影响，可以先看年付和月付到底该选哪个确认自己的处境，再决定要不要改习惯。
判断方法很直接：去 Copilot 的计费面板看计量单位显示的是 credits 还是请求次数，别靠记忆推断。
二、credits 花在哪：拆开看消耗结构
既然扣的是 token，一次交互的成本就由三块拼起来，搞清楚各自的占比才知道该动哪里。
第一块是你打进去的那句话。 这部分通常最小，也是最不值得抠的地方。有人为了省钱把问题写得极简，结果模型答偏了要来回三轮，反而更贵。
第二块是随请求一起送上去的上下文。 打开的文件、选中的代码段、你手动 @ 进来的目录、工具自动检索到的相关片段，都会变成输入 token。这块的体量常常是提问本身的几十倍，也是绝大多数浪费的来源。一个塞了两千行的文件被整个带进上下文，和只带进相关的三十行，扣掉的额度不是一个量级。
第三块是输出。 让它一次生成一个完整模块，和让它改三行，输出 token 差别巨大。而输出通常比输入贵，所以”让它一次写完整个文件再手动删掉八成”是很典型的花钱买废话。
再叠上模型这个乘数：不同模型的费率差异会把上面三块同时放大或缩小。所以同一个动作在不同模型上的成本差距，往往比你优化提问措辞省下来的多得多。关于各模型怎么切、企业策略会不会锁死选项，可以看Copilot 怎么切换 Claude、Gemini 等模型。
三、四类最常见的隐性浪费
下面这四类，共同点是消耗发生在你不注意的时候。
第一类，把整个仓库当上下文用。 遇到问题就习惯性把工作区全丢给它，指望它自己找。这在小项目上感觉很爽，在中大型仓库上就是持续放血。更麻烦的是这种用法答案质量往往还更差，因为无关代码稀释了真正相关的信息。
第二类，长会话不清空。 聊天窗口里的历史消息会作为上下文反复送上去，一个聊了四十轮的会话，第四十一句提问要带的输入 token 可能是第一句的几十倍——哪怕你问的是一个完全不相干的新问题。这是最容易积累、也最容易解决的一类浪费。
第三类，自动化任务在后台跑。 代码评审、后台 agent 这类不需要你按回车就会触发的功能，是账单上最常见的”我没用啊怎么扣了这么多”。这里还有一个容易漏掉的计量：code review 自 2026-06-01 起同时消耗 GitHub Actions 分钟数，也就是说它可能同时在两本账上扣东西。对还在老制度上的年付用户，官方另外说明 2026-06-01 起模型倍率有上调，例如 Copilot code review 的模型倍率为 13，即每次 PR 或 IDE 代码评审扣 13 个 premium request。要不要开、开在哪些仓库上，值得单独算一笔，代码评审这项功能的成本账可以对着看。
第四类，用重模型干轻活。 让最贵的模型去补全一段样板代码、生成一段注释、翻译一个变量名，是很常见的习惯性动作。这类任务的质量差异微乎其微，成本差异却是实打实的。
四、能立刻上手的削减动作
按投入产出排，从最省事的开始。
动作一：会话按任务切分。 一个任务结束就开新会话，别在同一个窗口里从早聊到晚。这条几乎零成本，效果却最直接，因为它砍掉的是会指数增长的那部分。
动作二：手动指定上下文，而不是让它自己搜。 明确 @ 相关的文件或选中相关的代码段再提问。多花五秒钟，省下的是一次全仓检索的输入 token，同时答案还更准。
动作三：按任务难度分配模型。 补全、改名、写注释、格式调整这类，用便宜的模型；跨文件重构、复杂 bug 定位、架构方案讨论这类，再上重模型。把这条变成肌肉记忆，比任何提示词技巧都管用。
动作四：让它做小改动，不要做大生成。 与其说”帮我实现这个功能”，不如拆成几步：“先给个方案不要写代码”、“这一步的实现写出来”。输出 token 是按实际生成量算的，让它少写没用的，比事后删掉省钱。
动作五：关掉不需要的自动化。 把后台评审、自动触发的 agent 任务限制在真正需要的仓库和分支上，而不是全组织默认开启。
动作六：定期看计费面板，而不是等阻断。 每周扫一眼当月消耗和分布，比月底看到账单再复盘有用得多。额度不结转，每个自然月 1 号重置，所以既不要省着不用攒到下月，也不要前十天就烧掉八成。
这六条不需要一起做，先做一和二，通常就能看到明显变化。
五、团队场景：预算怎么设才不误伤
个人是省，团队是分配。按官方说明，管理员用美元预算控制超额，按 $0.01/credit 扣减，也就是 $10 预算对应 1,000 credits。预算可以设在四个层级上：user、cost center、enterprise spending limit、organization。
这里有一个必须知道的陷阱：把某个用户的预算设为 $0 会立即阻断该用户。有人想着”先设成 0 观察一下用量”，结果直接把人挡在门外。要限制就设一个能干活的小额，不要用 0 当观察值。
分配思路上，把预算按角色区分通常比平均分更有效：全天写代码的人和一周用两次的人给同样的额度，前者不够用、后者浪费。团队真的提前烧完了怎么处置，另有一篇应急剧本专门讲。
六、9 月这个时间点要提前看
有一件事值得现在就放进日历：既有 Business / Enterprise 客户在按量计费的头三个月（2026-06-01 至 2026-09-01）享受更高的促销额度，按第三方公开资料的口径是 Business 3,000 credits/用户、Enterprise 7,000，促销结束后回落到标准的 1,900 / 3,900。这些具体数字来自第三方汇总资料，官方计费页未逐字核对，实际以你账号下 GitHub 官方计费页显示的为准。
如果这个口径成立，那么促销期内”够用”的团队，在 9 月之后可能会突然发现不够用了，而且不是缓慢变紧，是换月那一天直接换了一个基数。
现在能做的准备很简单：去 Copilot 计费面板看”预测用量”那个数，把它跟促销结束后的标准额度对一下。差多少，就是你需要在 8 月里省出来的部分，或者需要提前申请的预算。等 9 月账单出来再反应，那时候已经是既成事实了。各档包含额度的横向比较，套餐对比那篇整理得更全。
七、说清楚局限
有几件事这篇给不了确定答案。
一是没有公开的换算表能让你精确预估某次操作扣多少 credits。token 消耗受模型费率、缓存命中情况、上下文实际长度共同影响，只能事后在计费面板看实际值，事前只能做粗略的方向判断。
二是本文引用的各档额度数字来自第三方公开汇总，不是官方逐字口径。做预算决策时请以 GitHub 官方计费页当前显示的数值为准，尤其在促销窗口前后。
三是省额度和干活效率之间存在真实的取舍。上面所有动作都会多花你一点时间：手动指定上下文、切模型、拆任务。如果你的时间比额度贵，有些动作就不该做。这个判断只能你自己下，不存在一个对所有人都成立的最优解。
四是计费规则本身还在变。2026-06-01 才刚做完一次体制性变更，促销窗口 9 月又是一个节点，把任何一套省钱策略当成长期稳定的前提都不稳妥。相关的制度背景可以看计费变更那篇。
小结
Copilot 的 credits 按 token 扣，不按次数扣，所以省的着力点是单次交互的上下文长度和模型档位，不是提问频率。四类隐性浪费里，长会话不清空和整仓当上下文是最普遍的两个，也最好改。额度耗尽不会自动降级，只会阻断，因此所有优化都得提前做。团队设预算时记住 $0 等于立刻断人，别拿它当观察值。促销额度的口径来自第三方资料，9 月前对着计费面板的预测用量核一遍，比事后复盘划算。