优化 AI 使用情况以最大限度地提高效率和降低成本

Introduction

本文概述的策略展示了如何提高Copilot效率，并因此减少AI credits的使用。

1.为正确的任务选择正确的模型

通过为任务选择适当的功能级别、适当配置推理以及针对特定工作负荷利用 自动模型选择 和更便宜的模型，可以保持质量，同时显著减少令牌消耗。

选择正确的模型

模型选择是提高成本效益最快的方法之一，但通常被忽视。 常见的模式是默认为每个任务最有能力的模型，但这通常会增加令牌使用量，而不会改善结果。 在某些执行密集型方案中，过度使用推理模型可能会降低质量，因为模型可能会过度思考任务或引入不必要的更改。

根据所涉及的工作选择模型：

• 推理模型：最适合需要更深入分析的体系结构决策、复杂调试、系统设计和任务。
• 中层模型：最好是计划已经明确，代理需要高效执行。
• 较轻的模型：最适合重构、格式设置、文档更新和其他常规、范围良好的更改。

按任务需要尽可能多地使用能力，同时尽可能少用。 匹配任务功能可改善结果，并直接控制大规模成本。

有关按模型和任务类型的细分，请参阅 使用不同任务比较 AI 模型。

配置模型的推理级别

某些模型还支持可配置的推理级别，用于控制模型在给出响应前进行多少推理。 较高级别可以提升处理复杂问题时的回答质量，但也会消耗更多令牌，因此会占用更多额度。所以，默认情况下应使用常规级别，只在较难的任务中再调高。 对于受支持的模型，Visual Studio Code 和 Copilot 命令行界面（CLI） 提供可配置推理。

请参阅“GitHub Copilot中支持的 AI 模型”。

将 Copilot自动选择模型 设为默认值

自动模型选择 会根据你的任务意图为你选择合适的模型。

小型路由器会查看你的提示，并将其发送到可以 最高效地处理它的模型，从而为复杂的问题保留昂贵的推理模型。 它还避开了那些会迅速耗尽令牌预算的模型。

自动模型选择 还可以 保护缓存。 它只会在自然的缓存边界处切换模型：例如在新会话开始时，或在你运行 /compact 之后；绝不会在任务进行到一半时切换。 若要详细了解为何如此重要，请参阅 4。保留缓存。

自动模型选择 还会绕过性能下降或繁忙的模型，因此你会遇到更少的速率限制和错误。

If you are on a paid Copilot plan, you qualify for a 10% discount on model costs while using 自动模型选择 in 副驾驶聊天, Copilot 命令行界面（CLI）, or Copilot云代理.

有关该功能及其可用性的信息，请参阅 关于 Copilot自动模型选择。

使用更便宜的模型用于 子代理

让子代理在更便宜的模型上运行。 子代理 会在自己的会话中运行，并且不会继承主代理的对话历史记录。 由于其上下文仅限于单一专注任务，较轻量的模型通常就已足够——而且为其分配这样的模型，也不会像在会话中途切换模型那样影响主代理的缓存。

2.在提示中提供明确的指导

提示将为智能体的所有操作设定方向。 当提示较为模糊时，智能体必须推断用户意图，进一步了解更多上下文，并自行作出判断。 这通常会导致反复重试、范围蔓延以及不必要的 token 消耗。

结构良好的提示有三种品质：

• 明确的任务定义。 而不是“修复此问题”，而是解释问题所在、发生位置以及预期结果的外观。
• 预先提供的相关上下文。 如果已经知道哪些文件、服务、日志、错误或输入很重要，请包括这些文件。 这有助于智能体避免不必要的探索。
• 明确的停止条件。 明确告知智能体任务完成的判定标准。 如果没有停止点，代理可以通过添加额外的提交、重构不相关的代码或扩展范围来继续超越目标。

这些新增的指导不会明显增加 token 使用量，但可以显著减少代理为得出正确结果所需的运行次数。

有关提示工程最佳做法，请参阅 GitHub Copilot 对话助手的提示设计。

3. 保持上下文精简

Copilot 会将其可访问的上下文作为输入令牌发送出去，而这些上下文会不断累积：打开的编辑器标签页、附加的文件，以及长对话中的完整往来内容，都算作上下文。

若要使上下文保持控制，请考虑执行以下操作：

切换问题时启动新对话

长线程将整个历史记录传送到每个新请求中。 当你转而处理不相关的任务时，请开始新的对话。 例如：

• 在 Copilot 命令行界面（CLI） 中使用 /new（或 /clear）
• 在 副驾驶聊天中，启动新的聊天会话。

压缩你想继续进行的较长Copilot 命令行界面（CLI）会话

如果你需要继续该线程，但内容已经很多，可以在 /compact 中运行 Copilot 命令行界面（CLI） 来总结历史记录并缩小上下文窗口，还可以选择让摘要聚焦于特定内容（例如 /compact focus on the auth module）。

此外，您可以随时使用 /context 检查当前使用情况。

请参阅“在 GitHub Copilot 命令行界面 (CLI) 中管理上下文”。

给 Copilot 提供你的项目地图

维护良好的自定义指令文件（如 AGENTS.md 或 .github/copilot-instructions.md 文件）为代理提供了存储库的结构概述，因此它们不必读取大量文件即可自行定位。 请参阅“支持不同类型的自定义说明”。

只引入你需要的工具

大型工具集（例如，一整套 MCP 服务器工具）会在每次请求时增加上下文负担。 如果它符合工作流，请仅启用与任务相关的工具集。

请参阅“为 GitHub MCP 服务器配置工具集”。

4.保留缓存

通过缓存，AI 模型可以存储对话上下文的某些部分，因此无需在每个请求上重新处理它们。 在代理编码中，同一大型上下文（系统提示、文件内容、工具定义）在很多轮次之间重复发送，缓存会产生影响：前一个响应中的缓存部分重复使用而不是重新处理，缓存令牌通常按正常输入价格的 10% 计费。 请参阅“GitHub Copilot 的模型和定价”。

但是，以下操作使缓存失效，导致重新发送完整上下文并将其作为新的输入令牌计费：

• 在会话中切换模型。 不同的模型不能重复使用另一个模型的缓存，因此下一个请求从头开始重新生成它。 选择一个模型（或使用 Copilot自动选择模型），并在整个会话期间始终使用它。
• 返回到旧会话。 缓存在一段时间无活动后会过期（OpenAI 模型为 24 小时，大多数其他模型为 1 小时）。 如果你已经离开了一段时间，请启动新会话或运行 /compact （in Copilot 命令行界面（CLI）），以便重新生成的内容是简短的摘要，而不是完整的历史记录。
• 在会话中途更改推理。 在会话期间更改推理工作量级别、上下文大小或一组已启用的工具和 MCP 服务器会使缓存失效。 在开始之前配置这些设置，并为会话保留这些设置不变。

5. 研究、计划，然后实施

高效使用智能体的一大转变是不再依靠单一会话完成全部工作。 当研究、规划和实施一起发生时，上下文会迅速增长，并且不相关的信息会累积。

将工作分解为明确的阶段：

• 研究： 使用代理浏览代码库、识别相关文件以及了解依赖项。
• 计划： 在进行更改之前创建详细的结构化计划或规范。 这就是推理模型最有价值的位置-始终使用强大的推理模型进行计划，然后使用更便宜的模型实现工作。
  • 在 Copilot 命令行界面（CLI） 中，使用 /plan。
  • 在 副驾驶聊天 中的 Visual Studio Code 里，从代理下拉列表中选择“计划”，或在上下文窗口中输入 plan。
• 实现： 使用重点上下文和适合执行的模型针对计划执行。

在各阶段之间开启新会话，可以避免将不必要的上下文延续到后续阶段，否则这可能会增加令牌使用量，并降低代理的理解清晰度。 每个阶段都应只使用其所需的资源。 有关有效确定会话范围的指导，请参阅 使用GitHub Copilot处理任务的最佳做法。

6. 利用所获经验，在每一步都提高效率

使用 /chronicle 生成洞察

在 Copilot 命令行界面（CLI） 中，/chronicle 可以根据您的会话历史记录提供有价值的洞察。

• 使用 /chronicle tips 分析你最近的会话历史记录，并发现更高效地使用 Copilot 的机会。
• 使用 /chronicle cost-tips 了解您的令牌使用模式，并深入了解如何降低成本。

请参阅“关于 GitHub Copilot 命令行界面 (CLI) 会话数据”。

将洞察写入到 copilot-instructions.md 文件中

位于存储库级别的 copilot-instructions.md 文件，是写入针对你的存储库的指导信息最直接的方式。 个人和组织级别的说明可以分层，以便实现更广泛的一致性。

当 /chronicle 发现某种反复出现的模式——例如某个工具被过度使用，或某条提示反复被误解——就将这一观察直接写入你的 copilot-instructions.md 文件中。 这会将一次性的洞察转化为适用于今后每次会话的长期指引，无需你再重复说明。

有关详细信息，请参阅“为GitHub Copilot添加存储库自定义说明”。

使 copilot-instructions.md 文件保持具体且切合实际

持久指令可提高代理交互的一致性，但其价值完全取决于它们写入方式。 最佳说明是简短的、具体且以实际观察到的代理行为为基础—不是一般最佳做法，这些最佳做法听起来不错，但不适用于系统。

要包括的内容：

• 所需的框架、库或设计模式
• 代理往往会重复犯的已知陷阱
• 输出预期，如“简洁”或“仅返回代码”
• 代理必须遵循的团队特定约定
• 生成、测试和 Lint 命令

要避免的事项：

• 长文档，通用文档
• AI 生成的指南不反映实际系统
• 一次性首选项或很少使用的详细信息
• 造成上下文嘈杂的过多指令

随着代码库、体系结构、标准和工作流的发展，请不断更新说明。 由于这些指令包含在代理的上下文中，因此即使是较小的改进也会减少重复的错误，并随着时间的推移降低浪费的令牌使用量。

7. 添加确定性护栏

智能体具备非确定性，无法次次输出正确结果，多阶段工作流中更是如此。 如果缺乏约束机制，小错误就会迅速累积：代理会基于错误的输出继续推进，越来越偏离目标，并使调试成本更高、耗时更长。

确定性控制机制引入了明确的通过/失败信号：

• 单元测试 验证代理的更改是否生成了预期行为。
• Linters 强制实施结构和一致性，防止格式设置问题、样式偏移和可避免的清理工作。
• 安全扫描可以及早发现风险模式，以免后续更难处理。

这些控制机制共同形成了一个紧密的反馈闭环：智能体做出更改后，会由测试、规则或扫描对其进行评估，而智能体会在继续推进之前先作出调整。 这可以防止一连串错误更改，而这正是令牌浪费的主要原因之一。

投入这些防护措施的团队会发现，重试次数更少，任务完成速度更快，而且代理行为更可预测。 即使单个步骤提前使用稍微多一些令牌，它们也会减少令牌消耗总量。

后续步骤

监控和管理你的支出，以充分利用你的 AI credits：

• 使用仪表板和预算控件。 位于 https://github.com/settings/billing 下的“AI 使用情况”页面会按各项功能和模型细分用量，让你清楚了解额度实际消耗在何处，并据此进行调整。 请参阅“监控您的GitHub AI Credits使用情况”。
• 升级以增加津贴。 如果定期接近每月限制，则更高的计划可能比支付额外使用量更经济，因为更高的计划有更多的 AI credit 津贴。 请参阅 关于个人版 GitHub Copilot 计划和权益 和 查看和更改GitHub Copilot 计划。