{"meta":{"title":"优化 AI 使用情况以最大限度地提高效率和降低成本","intro":"了解如何选择正确的模型、构建提示并添加护栏，以便 Copilot 更高效地完成任务，减少使用 AI credits。","product":"GitHub Copilot","breadcrumbs":[{"href":"/zh/copilot","title":"GitHub Copilot"},{"href":"/zh/copilot/tutorials","title":"教程"},{"href":"/zh/copilot/tutorials/optimize-ai-usage","title":"优化 AI 使用情况"}],"documentType":"article"},"body":"# 优化 AI 使用情况以最大限度地提高效率和降低成本\n\n了解如何选择正确的模型、构建提示并添加护栏，以便 Copilot 更高效地完成任务，减少使用 AI credits。\n\n## Introduction\n\n本文概述的策略展示了如何提高Copilot效率，并因此减少AI credits的使用。\n\n## 1.为正确的任务选择正确的模型\n\n通过为任务选择适当的功能级别、适当配置推理以及针对特定工作负荷利用 auto model selection 和更便宜的模型，可以保持质量，同时显著减少令牌消耗。\n\n### 选择正确的模型\n\n模型选择是提高成本效益最快的方法之一，但通常被忽视。 常见的模式是默认为每个任务最有能力的模型，但这通常会增加令牌使用量，而不会改善结果。 在某些执行密集型方案中，过度使用推理模型可能会降低质量，因为模型可能会过度思考任务或引入不必要的更改。\n\n根据所涉及的工作选择模型：\n\n* **推理模型**：最适合需要更深入分析的体系结构决策、复杂调试、系统设计和任务。\n* **中层模型**：最好是计划已经明确，代理需要高效执行。\n* **较轻的模型**：最适合重构、格式设置、文档更新和其他常规、范围良好的更改。\n\n按任务需要尽可能多地使用能力，同时尽可能少用。 匹配任务功能可改善结果，并直接控制大规模成本。\n\n有关按模型和任务类型的细分，请参阅 [使用不同任务比较 AI 模型](/zh/copilot/tutorials/compare-ai-models)。\n\n### 配置模型的推理级别\n\n某些模型还支持可配置的推理级别，用于控制模型在给出响应前进行多少推理。 较高级别可以提升处理复杂问题时的回答质量，但也会消耗更多令牌，因此会占用更多额度。所以，默认情况下应使用常规级别，只在较难的任务中再调高。 对于受支持的模型，Visual Studio Code 和 Copilot CLI 提供可配置推理。\n\n请参阅“[GitHub Copilot中支持的 AI 模型](/zh/copilot/reference/ai-models/supported-models#models-with-extended-capabilities)”。\n\n### 将 Copilot auto model selection 设为默认值\n\nAuto model selection 会根据你的任务意图为你选择合适的模型。\n\n小型路由器会查看你的提示，并将其发送到可以 **最高效地处理它的**模型，从而为复杂的问题保留昂贵的推理模型。 它还避开了那些会迅速耗尽令牌预算的模型。\n\nAuto model selection 还可以 **保护缓存**。 它只会在自然的缓存边界处切换模型：例如在新会话开始时，或在你运行 `/compact` 之后；绝不会在任务进行到一半时切换。 若要详细了解为何如此重要，请参阅 [4。保留缓存](#4-preserve-the-cache)。\n\nAuto model selection 还会绕过性能下降或繁忙的模型，因此你会遇到更少的速率限制和错误。\n\n如果你使用的是付费Copilot计划，则可以在使用、auto model selectionCopilot Chat或Copilot CLI使用GitHub Copilot appCopilot cloud agent模型成本时获得 10% 折扣。\n\n有关该功能及其可用性的信息，请参阅 [关于 Copilotauto model selection](/zh/copilot/concepts/models/auto-model-selection#copilot-chat-in-ides)。\n\n### 使用更便宜的模型用于 subagents\n\n让subagents在更便宜的模型上运行。\nSubagents 会在自己的会话中运行，并且不会继承主代理的对话历史记录。 由于其上下文仅限于单一专注任务，较轻量的模型通常就已足够——而且为其分配这样的模型，也不会像在会话中途切换模型那样影响主代理的缓存。\n\n## 2.在提示中提供明确的指导\n\n提示将为智能体的所有操作设定方向。 当提示较为模糊时，智能体必须推断用户意图，进一步了解更多上下文，并自行作出判断。 这通常会导致反复重试、范围蔓延以及不必要的 token 消耗。\n\n结构良好的提示有三种品质：\n\n* **明确的任务定义。** 而不是“修复此问题”，而是解释问题所在、发生位置以及预期结果的外观。\n* **预先提供的相关上下文。** 如果已经知道哪些文件、服务、日志、错误或输入很重要，请包括这些文件。 这有助于智能体避免不必要的探索。\n* **明确的停止条件。** 明确告知智能体任务完成的判定标准。 如果没有停止点，代理可以通过添加额外的提交、重构不相关的代码或扩展范围来继续超越目标。\n\n这些新增的指导不会明显增加 token 使用量，但可以显著减少代理为得出正确结果所需的运行次数。\n\n有关提示工程最佳做法，请参阅 [GitHub Copilot 对话助手的提示设计](/zh/copilot/concepts/prompting/prompt-engineering)。\n\n## 3. 保持上下文精简\n\nCopilot 会将其可访问的上下文作为输入令牌发送出去，而这些上下文会不断累积：打开的编辑器标签页、附加的文件，以及长对话中的完整往来内容，都算作上下文。\n\n若要使上下文保持控制，请考虑执行以下操作：\n\n### 切换问题时启动新的对话\n\n长对话会将完整的历史记录带入每个新请求中。 当你转而处理不相关的任务时，请开始新的对话。 例如：\n\n* 在 Copilot CLI 中使用 `/new`（或 `/clear`）\n* 在 Copilot Chat中，启动新的聊天会话。\n\n### 压缩你想继续进行的较长Copilot CLI会话\n\n当您需要继续该对话但其规模已变得庞大时，可在 `/compact` 中运行 Copilot CLI 来汇总历史记录并缩小上下文窗口，还可选择对摘要进行聚焦（例如，`/compact focus on the auth module`）。\n\n此外，您可以随时使用 `/context` 检查当前使用情况。\n\n请参阅“[在 GitHub Copilot CLI 中管理上下文](/zh/copilot/concepts/agents/copilot-cli/context-management)”。\n\n### 给 Copilot 提供你的项目地图\n\n维护良好的自定义指令文件（如 `AGENTS.md` 或 `.github/copilot-instructions.md` 文件）为代理提供了存储库的结构概述，因此它们不必读取大量文件即可自行定位。 请参阅“[支持不同类型的自定义说明](/zh/copilot/reference/custom-instructions-support)”。\n\n### 只引入你需要的工具\n\n大型工具集（例如，相当于一台完整 MCP 服务器的工具）会在每次请求中增加上下文。 如果它符合工作流，请仅启用与任务相关的工具集。\n\n请参阅“[为 GitHub MCP 服务器配置工具集](/zh/copilot/how-tos/provide-context/use-mcp-in-your-ide/configure-toolsets)”。\n\n## 4.保留缓存\n\n通过缓存，AI 模型可以存储对话上下文的某些部分，因此无需在每个请求上重新处理它们。 在代理编码中，同一大型上下文（系统提示、文件内容、工具定义）在很多轮次之间重复发送，缓存会产生影响：前一个响应中的缓存部分重复使用而不是重新处理，缓存令牌通常按正常输入价格的 10% 计费。 请参阅“[GitHub Copilot 的模型和定价](/zh/copilot/reference/copilot-billing/models-and-pricing)”。\n\n但是，以下操作使缓存失效，导致重新发送完整上下文并将其作为新的输入令牌计费：\n\n* **在会话中切换模型**。 不同的模型不能重复使用另一个模型的缓存，因此下一个请求从头开始重新生成它。 选择一个模型（或使用 Copilot auto model selection），并在整个会话期间始终使用它。\n* **返回到旧会话**。 缓存在一段时间无活动后会过期（OpenAI 模型为 24 小时，大多数其他模型为 1 小时）。 如果你已经离开了一段时间，请启动新会话或运行 `/compact` （in Copilot CLI），以便重新生成的内容是简短的摘要，而不是完整的历史记录。\n* **在会话中途更改推理**。 在会话期间更改推理工作量级别、上下文大小或一组已启用的工具和 MCP 服务器会使缓存失效。 在开始之前配置这些设置，并为会话保留这些设置不变。\n\n## 5. 设置 AI credit 会话限制\n\nAI credit 会话限制会限制 Copilot 在单个会话中执行的工作量。\n\n在 Copilot CLI 和 Copilot SDK 中，你可以在启动任务前设置会话限制；达到限制时，代理会正常停止、通知你，并让你选择是继续还是调高限制。\n\nAI credit 会话限制在以下情况下最有用：\n\n* 你想要限制 AI credits 单个会话的使用量，以避免意外成本。\n* 你正在优化代理效率，并希望找到仍然产生良好结果的最小值 AI credits 。\n\n会话限制是软限制，可帮助你控制任何单个任务消耗量 AI credits ，但它们不会取代用户级预算或支出限制，从而控制整体每月消耗量。 有关这些控件，请参阅 [基于使用情况的计费预算](/zh/copilot/concepts/billing/budgets-for-usage-based-billing)。\n\n有关如何设置 Copilot CLI会话限制的信息，请参阅 [在 AI credit 中设置 GitHub Copilot CLI 会话限制](/zh/copilot/how-tos/copilot-cli/use-copilot-cli/set-session-limit)。\n\n## 6. 研究，计划，然后实施\n\n高效使用智能体的一大转变是不再依靠单一会话完成全部工作。 当研究、规划和实施一起发生时，上下文会迅速增长，并且不相关的信息会累积。\n\n将工作分解为明确的阶段：\n\n* **研究：** 使用代理浏览代码库、识别相关文件以及了解依赖项。\n* **计划：** 在进行更改之前创建详细的结构化计划或规范。 这就是推理模型最有价值的位置-始终使用强大的推理模型进行计划，然后使用更便宜的模型实现工作。\n  * 在 Copilot CLI 中，使用 `/plan`。\n  * 在 Copilot Chat 中的 Visual Studio Code 中，从智能体下拉菜单中选择“计划”，或在上下文窗口中输入 `plan`。\n* **实现：** 使用重点上下文和适合执行的模型针对计划执行。\n\n在各阶段之间开启新会话，可以避免将不必要的上下文延续到后续阶段，否则这可能会增加令牌使用量，并降低代理的理解清晰度。 每个阶段都应只使用其所需的资源。 有关有效确定会话范围的指导，请参阅 [使用GitHub Copilot处理任务的最佳做法](/zh/copilot/tutorials/cloud-agent/get-the-best-results)。\n\n## 7. 利用经验教训，在每一步都提高效率\n\n### 使用 `/chronicle` 生成洞察\n\n在 Copilot CLI 中，`/chronicle` 可以根据您的会话历史记录提供有价值的洞察。\n\n* 使用 `/chronicle tips` 分析你最近的会话历史记录，并发现更高效地使用 Copilot 的机会。\n* 使用 `/chronicle cost-tips` 了解您的令牌使用模式，并深入了解如何降低成本。\n\n请参阅“[关于 GitHub Copilot CLI 会话数据](/zh/copilot/concepts/agents/copilot-cli/chronicle#the-chronicle-slash-command)”。\n\n### 将洞察写入到 `copilot-instructions.md` 文件中\n\n位于存储库级别的 `copilot-instructions.md` 文件，是写入针对你的存储库的指导信息最直接的方式。 个人和组织级别的说明可以分层，以便实现更广泛的一致性。\n\n当 `/chronicle` 发现某种反复出现的模式——例如某个工具被过度使用，或某条提示反复被误解——就将这一观察直接写入你的 `copilot-instructions.md` 文件中。 这会将一次性的洞察转化为适用于今后每次会话的长期指引，无需你再重复说明。\n\n有关详细信息，请参阅“[为GitHub Copilot添加存储库自定义说明](/zh/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions)”。\n\n### 使 `copilot-instructions.md` 文件保持具体且切合实际\n\n持久指令可提高代理交互的一致性，但其价值完全取决于它们写入方式。 最佳说明是简短的、具体且以实际观察到的代理行为为基础—不是一般最佳做法，这些最佳做法听起来不错，但不适用于系统。\n\n**要包括的内容：**\n\n* 所需的框架、库或设计模式\n* 代理往往会重复犯的已知陷阱\n* 输出预期，如“简洁”或“仅返回代码”\n* 代理必须遵循的团队特定约定\n* 生成、测试和 Lint 命令\n\n**要避免的事项：**\n\n* 长文档，通用文档\n* AI 生成的指南不反映实际系统\n* 一次性首选项或很少使用的详细信息\n* 造成上下文嘈杂的过多指令\n\n随着代码库、体系结构、标准和工作流的发展，请不断更新说明。 由于这些指令包含在代理的上下文中，因此即使是较小的改进也会减少重复的错误，并随着时间的推移降低浪费的令牌使用量。\n\n## 8. 添加确定性防护措施\n\n智能体具备非确定性，无法次次输出正确结果，多阶段工作流中更是如此。 如果缺乏约束机制，小错误就会迅速累积：代理会基于错误的输出继续推进，越来越偏离目标，并使调试成本更高、耗时更长。\n\n确定性控制机制引入了明确的通过/失败信号：\n\n* **单元测试** 验证代理的更改是否生成了预期行为。\n* **Linters** 强制实施结构和一致性，防止格式设置问题、样式偏移和可避免的清理工作。\n* **安全扫描**可以及早发现风险模式，以免后续更难处理。\n\n这些控制机制共同形成了一个紧密的反馈闭环：智能体做出更改后，会由测试、规则或扫描对其进行评估，而智能体会在继续推进之前先作出调整。 这可以防止一连串错误更改，而这正是令牌浪费的主要原因之一。\n\n投入这些防护措施的团队会发现，重试次数更少，任务完成速度更快，而且代理行为更可预测。 即使单个步骤提前使用稍微多一些令牌，它们也会减少令牌消耗总量。\n\n## 后续步骤\n\n监控和管理你的支出，以充分利用你的 AI credits：\n\n* **使用仪表板和预算控件**。 位于 <https://github.com/settings/billing> 下的“AI 使用情况”页面会按各项功能和模型细分用量，让你清楚了解额度实际消耗在何处，并据此进行调整。 请参阅“[监控您的GitHub AI Credits使用情况](/zh/copilot/how-tos/manage-and-track-spending/monitor-ai-usage)”。\n* **升级以增加津贴**。 如果定期接近每月限制，则更高的计划可能比支付额外使用量更经济，因为更高的计划有更多的 AI credit 津贴。 请参阅 [GitHub Copilot计划](/zh/copilot/concepts/billing/individual-plans#github-ai-credits-allowance-by-plan) 和 [查看和更改GitHub Copilot 计划](/zh/copilot/how-tos/manage-your-account/view-and-change-your-copilot-plan)。"}