集成开发环境（IDE）：企业AI战略中被忽视的关键变量
开发人员所使用的 AI 工具，其效能取决于它们在运行前掌握了多少信息。当这些工具通过合适的集成开发环境（IDE）运行时，IDE 可以为它们提供先发优势——即提供一幅代码库的全景图，否则工具就必须自行拼凑这些信息。
这意味着，团队的 IDE 选择应当与你针对网关数据和大型语言模型（LLM）决策所制定的政策一样，被列入 AI 议程。
AI 网关的局限性
AI 网关现已成为重要的管理基础设施组件。据 Gartner 预测，到 2028 年，70% 构建多模态应用的软件工程团队都将部署 AI 网关。
网关为你提供了两类 AI 管理手段：
- 流水线内控制（In-pipeline controls）： 包括模型路由、速率限制和成本分配。流水线内控制能让你对 AI 支出有稳健的可见性和护栏，但它们仅适用于已经生成的请求。
- 流水线前策略（Pre-pipeline policies）： 包括批准的模型列表、提示词指南和培训计划。理论上，这些策略可以引导开发人员的行为。然而，2024 年 Stack Overflow 的一项调查发现，73% 的开发人员甚至不确定公司是否制定了 AI 政策。
尽管如此，如何将 AI 使用情况与工程成果挂钩的问题依然悬而未决。GitHub 在 2026 年 2 月推出其组织级 Copilot 仪表板时表示：“我们正在朝着这个答案努力。”
网关是实现这一目标不可或缺的一部分，但它们无法在请求生成之前，为 AI 工具所利用的信息提供架构层面的控制。无论你的员工是否遵循提示词指南，或者你对网关统计数据的监控有多严密，AI 工具能够访问的信息质量始终是决定性因素。
熟悉的工具，被忽视的 AI 杠杆
在缩小 AI 使用与 AI 成果之间差距的衡量标准方面，最有效的框架之一是《DORA 2025 AI 辅助软件开发现状报告》。报告确定了领导者应优先考虑的七项能力：
- 两项组织能力： 关注 AI 终端用户和清晰、已传达的 AI 政策。这正是 AI 网关的用武之地。
- 两项流程能力： 强大的版本控制实践和小批量工作。
- 三项技术能力： 健康的数据生态系统、可被 AI 访问的内部数据以及高质量的内部平台。
在数据能力领域，DORA 明确指出驱动绩效的核心是“上下文（Context）”，即模型在生成输出之前接收到的信息。更好的上下文意味着更大的收益。DORA 没有深入探讨的是，在创建阶段是什么决定了上下文的质量。这取决于创建者是谁（或什么）以及创建的方式。
致 AI：关于上下文
虽然网关目前可能还无法显示是谁或什么在创建上下文，但通常有三种基本情况：
- 开发人员直接操作： 开发人员通过浏览器或聊天界面直接与 AI 交互。上下文就是粘贴进去的任何内容。
- 智能体直接操作： 自主智能体直接在代码库上运行。上下文就是智能体所选择的内容。
- IDE 中介： AI 助手或编码智能体通过开发环境运行。上下文包括 IDE 提供的代码库结构化知识——对于助手是自动提供的，对于智能体则是通过配置提供的。
这三种情况都有相应的政策杠杆，包括你资助哪些模型、允许哪些智能体，以及如何跟踪成本和用量。
但“IDE 中介”的情况还引入了一个关于 AI 工具运行环境的决策，而不仅仅是工具本身的决策。考虑到目前大部分代码都是在 IDE 内置工具中生成的（在 Uber，这一比例为 65%--72%），这一决策至关重要。
上下文，集结！
上下文组装是选择发送给 AI 模型内容的过程。所使用的方法会对输出质量产生可衡量的影响：
- 一项 2026 年的研究发现，一种基于追踪代码在文件间如何连接的方法，比基于匹配相似代码的方法，在 Java 语言中产生了多 213% 的测试覆盖率，在 Go 语言中则多出 174%。
- 一项 2024 年的研究对比了另一种相似代码匹配方法与基于静态分析提取代码依赖和类型信息的方法。结果显示，基于提取的方法生成的代码补全准确率提高了 62%。
对于在开发环境中运行的 AI 工具，环境决定了它们的上下文组装方法所能利用的结构化知识。
重构 IDE 的决策
选择哪个 IDE 传统上是开发人员的个人决定。你所拥有的最佳衡量指标无非是许可成本和开发人员满意度评分。AI 网关正在改变这一现状。
考虑一下你可能已经在监控的网关数据，例如模型调用量、上下文负载大小或 Token 使用量。团队 IDE 提供给 AI 工具的信息，会影响所有这些指标。
目前尚无成熟的 AI 管理框架将 IDE 的角色正式纳入该范畴。衡量基础设施仍在发展中。GitHub 的 Copilot 仪表板可以告诉你 Copilot 流量的来源，但目前还没有多工具网关能为所有 AI 编码工具提供现成的等效功能。在此期间，你可以采取以下两项措施以保持领先：
了解现有资产
无论你是否已经部署了网关，首先要了解你的开发人员正在使用哪些 IDE 以及原因。如果你已有网关，请更进一步：询问你的工程师，按交互类型（IDE 中介、智能体直接操作或开发人员直接操作）对模型调用进行分类需要做些什么。虽然工作量因配置而异，但原始数据很可能已经存在。建立基准线将为你后续衡量工具的成熟度提供参考。
评估未来需求
有些 IDE 让 AI 工具自行摸索代码库。当前的编码智能体默认就是这样做的。
另一些 IDE 则向运行其中的 AI 工具提供整个代码库的结构化模型。智能体客户端协议（ACP）允许外部智能体在 JetBrains IDE 中运行。连接后，它们可以通过模型上下文协议（MCP）调用 IDE 端的工具。
随着智能体编码工作变得更加复杂和自主，IDE 所能提供的这种结构化优势将愈发重要。虽然相关机制尚属新兴事物，证据基础尚薄，但 Sourcegraph 发布的一项基准测试早期结果显示，使用 MCP 工具的智能体在大型多存储库代码库中，完成任务的速度快了 38%，定位相关文件的频率高了 70%。
你的开发人员知道他们的 IDE 提供了什么，以及他们的智能体是如何配置的。你则需要决定，对于 AI 辅助开发的未来方向而言，这些是否足够。
面向未来的 IDE
当团队的 IDE 选择被纳入 AI 议程时，JetBrains 为你提供了可调整的架构变量。
JetBrains IDE 维护着整个代码库的持续结构化表示，这简化了 AI 上下文的构建。所有这些信息都会自动传达给 AI Assistant——这是 IDE 的原生接口，通过你自己的密钥或 JetBrains AI 支持几乎任何 LLM。
对于超过 25 种 ACP 兼容的编码智能体，JetBrains IDE 提供的工具可以直接暴露相同的表示。大多数智能体需要被指向这些工具；一旦连接，根据至少一个工程团队的反馈，上下文构建循环可以被显著缩短。
行业动态仍在演变，你的实际收益当然会有所不同，但你手中已经掌握了可以调控的杠杆。
了解 JetBrains 如何在 AI 辅助开发中支持更可靠的上下文构建。