「两种写代码的方式，一个掌控它们的地方。」这是JetBrains对2026年的定义。当整个行业都在争论「AI会不会取代程序员」时，这家老牌工具商选择了一条中间路线——既不押注纯AI生成，也不固守传统编码。
两种工作流，没有优劣之分
JetBrains把现在的开发者分成两类。
一类坚持经典路径：逐行敲代码，手动重构，一步步调试，意图在每一行中累积。另一类拥抱新方式：与AI协作，有时用自动补全，有时把整块任务丢给智能体（agent）去草拟。
这家公司明确表示，「我们不认为一种比另一种更好。」
这个判断本身就有信息量。2024-2025年，AI编程工具的市场叙事高度两极化——要么鼓吹「自然语言取代代码」，要么嘲讽「AI只会写bug」。JetBrains的立场是工具商的立场：用户怎么选，IDE就怎么适配。
具体落地为两条原则：
如果你想自己写代码，IDE的核心体验不能被AI干扰。代码编辑、导航、重构这些基本功，优先级高于任何智能功能。
如果你想用AI生成或委托任务，IDE要让这个过程「自然且强大」——从交互设计到功能深度都要到位。
一个底线不变：最终对交付代码负责的是人。而阅读、理解、掌控代码的最佳场所，仍然是IDE。
「AI在IDE里」到底是什么
JetBrains拒绝给出一个「官方工作流」。理由是市场变化太快，开发者群体又太多样，统一方案行不通。
他们定义的「AI in JetBrains IDEs」是按需出现的增强价值，具体落在四个场景：
AI Chat工具窗口，纯对话式交互；IDE内置终端，开发者本来就在用命令行工具的地方；以及为智能体系统设计的可选模式——你可以启动一个agent，让它运行数小时。
核心逻辑是：同一个IDE，多种AI赋能的工作方式。用户选，团队定，真实开发需求约束。
这里有个值得注意的产品哲学。JetBrains没有把AI当作一个独立功能模块，而是作为「在需要时出现」的能力层。这与某些竞品把AI聊天窗口做成固定入口的做法形成对比——后者某种程度上是在培养用户习惯，前者则是跟随用户既有习惯。
反锁定的技术赌注
JetBrains对模型供应商的态度非常清醒：「今天最好的模型、提供商或智能体，不会永远最好——也许下个月就不是了。」
基于这个判断，他们在架构上刻意避免单点依赖。AI聊天体验支持多种接入方式：
JetBrains AI托管方案（需订阅）；自带API密钥（BYOK）；支持OAuth登录的提供商账户（前提是提供商支持）；以及通过ACP协议接入的外部编码智能体。
这里有个诚实的脚注：OAuth并非总能实现。如果智能体提供商不提供OAuth，或提供的版本IDE无法调用，JetBrains「不能凭空发明」。
这种坦诚在厂商声明中不多见。大多数公司会模糊处理技术限制，把「不支持」包装成「即将推出」。
ACP协议：「自带智能体」
Agent Client Protocol（智能体客户端协议）是JetBrains开放策略的技术载体。它允许通过标准接口连接外部编码智能体，IDE无需为每个智能体做定制化集成。
这个设计的商业意图很明显：降低用户切换成本，同时把JetBrains定位为「智能体的宿主环境」而非「智能体的生产商」。在AI能力快速迭代的阶段，这是一种防御性架构——不押注赢家，而是让自己成为任何赢家都可以跑的平台。
对开发者而言，这意味着今天用Claude Code，明天试Gemini CLI，后天换开源方案，都不需要换IDE。对JetBrains而言，这意味着避免被某个爆款智能体绑架，也避免因为押错技术路线而被淘汰。
正方：为什么这种中立策略合理
支持JetBrains路线的人有几个核心论据。
第一，技术不确定性太高。2023年的GPT-4还是绝对标杆，2024年Claude 3.5 Sonnet在编码场景反超，2025年初DeepSeek以成本优势搅动市场。在这种波动中，锁定任何单一供应商都是高风险决策。JetBrains的「多接入选项」本质上是把技术风险转移给用户——你赌你的，我提供场地。
第二，开发者群体高度分化。有人用AI写80%的代码，有人坚决不用，有人只在特定场景求助。统一产品策略必然得罪至少一部分人。JetBrains的选择是最大化覆盖：想要纯手动？体验不降级。想要全AI？能力跟得上。
第三，IDE的核心价值在于「代码所有权」。无论代码怎么产生，最终需要人阅读、审查、维护。JetBrains强调IDE作为「代码归属地」的角色，实际上是在强化自己的不可替代性——AI工具可以换，但代码库的管理中枢不易迁移。
反方：中立是否等于平庸
批评者也有充分理由。
第一，「不站队」可能意味着「没有主场优势」。Cursor和Windsurf选择深度绑定特定模型能力，在AI原生交互上迭代更快。JetBrains的开放架构虽然灵活，但每个接入点的体验深度可能受限。当竞争对手能提供「端到端优化」时，JetBrains的「通用适配」是否显得松散？
第二，资源分散风险。支持四种接入方式（托管、BYOK、OAuth、ACP）意味着四套维护成本、四套文档、四套故障排查路径。对于一家以产品精细度著称的公司，这种广度是否以牺牲打磨深度为代价？
第三，时机问题。2025年的AI编程工具市场正在快速收敛——不是技术收敛，而是用户习惯收敛。早期尝鲜者已经形成偏好，晚期大众即将入场。JetBrains的「让用户选」策略，在窗口期可能有效，但如果市场迅速走向寡头格局，中立姿态反而会让它错过定义标准的机会。
我的判断：这是一场关于「基础设施定位」的赌局
JetBrains的路线选择，本质上是把自己定位为AI编程时代的「基础设施」而非「应用」。
这个定位有其历史合理性。IntelliJ IDEA、PyCharm、WebStorm这些产品在过去二十年建立了深厚的开发者信任，代码索引、重构引擎、调试能力构成了难以复制的护城河。在AI浪潮中，这些资产不会自动贬值——恰恰相反，它们是AI生成代码的「最终质检环节」。
但定位基础设施也有代价。应用层可以快速增长、快速变现、快速讲故事；基础设施的增长曲线更平缓，需要更长时间验证价值。JetBrains的2026方向声明，读起来像一份长期主义宣言，而非短期竞争武器。
关键变量在于ACP协议的生态发展。如果足够多的第三方智能体选择支持ACP，JetBrains确实可以成为「智能体的通用宿主」，届时它的中立性会从「缺乏特色」转化为「平台优势」。但如果主流智能体更倾向于自建客户端或绑定特定IDE，ACP可能沦为边缘功能。
另一个观察点是JetBrains AI订阅的竞争力。BYOK和OAuth选项虽然开放，但也会分流付费用户。公司需要在「开放性」和「商业化」之间找到平衡点——目前看来，他们押注的是长期用户粘性而非短期订阅收入。
对25-40岁的科技从业者来说，这件事的启示在于：工具选择正在从「功能对比」转向「哲学对齐」。你更信任一个帮你做决定的供应商，还是一个让你自己做决定的平台？这个问题没有标准答案，但JetBrains已经明确了自己的立场。
如果你正在评估明年的开发工具栈，不妨把这篇声明加入阅读清单——不是为了看功能列表，而是为了理解一个老牌厂商如何在剧变期定义自己的角色。然后，决定你是否认同这种定义。
热门跟贴