1 问题概述

最近几个月，GitHub Copilot 对部分模型开始限量：10 美金的套餐常常在月底前就耗尽了，被迫退回到“无限用但效率低”的模型。用量上其实差距不大——就是最后三五天总差那么一点儿，就很烦人。我也愿意为多出来的部分按量计费，但找不到在哪里设置。于是只好想一些节流的办法。

### 2 原因分析

使用大量Agent无疑是主要原因，不过仍有一些节省空间。

  • VSCode 插件/Session 常进入“死循环”式请求：模型在某个方向反复尝试和输出，导致 token 的浪费。
  • 生成了过多的测试、示例和说明文件，同时还扩展了一些用不上的功能。
  • 目前的 VSCode 1.105 版本在交互方面已经有很大提升，比如它边改我边确认，在思考过程中还可以叫停。但仍有人与模型协作时不够协调的问题。常见的问题包括：我没有把大目标拆分成小目标，没有及时清理上下文等等。

3 实操建议（可直接复用）

  • 先搭框架：人工先写好项目/函数骨架，再让模型填充实现细节（可使用 Ask 方式讨论确定框架）。
  • 小步提交：大目标拆成若干小目标，一次别改太多文件或太多逻辑。
  • 频繁“商量”再执行：多用 ask（询问）确定方案后再用 agent（执行）。
  • 看到死循环立刻打断：及时停止当前会话，必要时新建聊天窗口；有一些简单的调试（在提示是否允许运行时），人工来调。
  • 区分改动范围：简单的小改自己手动，改小功能在代码中用 prompt 方式，改单一文件用 edit，牵一发动全身的大改交给 agent。简单的修改自己测试。
  • 模型选择：除了选择不限量模型，使用 Claude Haiku 替代 Claude Sonnet，也可省2/3，我觉得效果差不太多，尤其是难度小的修改，而且 Haiku 运行速度明显快。
  • 定期整理与拆分代码：避免超长文件，减少每次改动需要复查的范围。一开始就要把关做好，尽量不保留任何冗余代码，尤其是在做大型项目时，不能抱有“差不多就得了”的心态——否则后期维护会非常麻烦。
  • 清理临时产物：文档、demo、测试片段用完就删，别留“企业级废话库”。
  • 写入限制性提示：如在 .github/prompts 或代码注释里写明确要求（它乱加，你还得花时间删），例如：“只按要求实现，不扩展额外功能；每次只返回实现本次功能所需的最小代码块，尽量简化测试和说明，节约 token。”
  • 角色定位：把 50%+ 的工作留给自己——管结构、审查、测试，约束模型行为。模型是助理不是替身。

4 结语

从工具提供者的角度来说，很多时候杀鸡不用牛刀，凡事都用最好的模型其实是一种算力浪费。当然，系统可以通过判断问题的难度来选择合适的模型，只不过现在还没有实现。

对于程序员来说，编程工具是助力器，而不是自动驾驶。把握好方向和边界，节省下来的 token 就是节省下来的时间以及避免折腾的心情。