AIDEs框架：我们如何为AI开发工具构建“万物理论”
我们正生活在一个真正有趣的时代。AI 正以几乎每天都有新模型、新工具、新实践涌现的速度颠覆着软件开发。许多团队的本能第一反应，是把越来越多的时间花在追逐更新上。
在 JetBrains 做了将近两年的 AI 产品与市场研究之后，我们得出了一个不同的结论：变化的速度并不是问题，只要你能看清更大的图景。 我们有意不去追踪发生的每一件事，而是努力理解我们所观察到的一切从何而来——以及它们最终要走向哪里。这给了我们一个透视的棱镜、一个区分信号与噪声的过滤器，也正是它让我们免于变化疲劳。
这篇文章讲的就是那面棱镜。但在进入框架本身之前，让我们从这场网络研讨会开始的地方说起：我们今天在市场上实际看到的东西。因为如果不先建立对当下的诚实模型，就无法建立起对未来的有用模型。
我们今天在市场上看到的现象
通览我们的研究，有三件事尤为突出。
首先，AI 已经是开发者生活中的常见部分。 人们不仅在家里使用它，也在公司里使用它——包括那些传统上对任何新事物采纳最慢的大公司。我们已不再质疑软件开发中的 AI「是否算得上是个事」。它已经到来，并且会留下来。
其次，智能体式编程（agentic coding）正逐渐成为新常态。 越来越多的开发者在使用 AI 编程智能体，它们不止于自动化的代码编辑——而是真正把编码委托给智能体。这从根本上改变了开发循环：从编辑器里的「编写 → 验证 → 修复」，变为智能体对话中的「规划 → 执行 → 审查」。这一趋势最大的推动力来自 Anthropic 的 Claude Code。据我们估算，它拥有约 850 万编程专业用户，年收入约 70 亿美元，并被普遍认为是所有类别中最好的 AI 编程工具。它的发布也开启了与 IDE 无关的 CLI 编程智能体的竞赛——如今 OpenAI、Google 以及一大批小众玩家都推出了类似产品。
第三，AI 智能体开始向云端迁移。 像 Devin 这样的工具已经存在一段时间，但直到现在，这一趋势才开始真正具有意义。随着模型能力更强、智能体更强大、开发者也更清楚 AI 能做什么、不能做什么，他们正在更自觉地决定把工作委托给云端智能体——这类智能体在设计上就更加自主。它们仍有严重的局限，但已经能处理简单的、低投入的「垃圾任务」，比如修复 CI 流程中发现的 lint 错误。
然而，这里存在一个悖论：尽管人人都在用 AI，我们却不能说 AI 已被用在了所有地方。 现实中，AI 主要用于两项开发活动：头脑风暴和编码。但开发并不只是编码。软件开发生命周期中的许多环节仍基本未被触及，这为后续的采纳留下了巨大的空间。AI 的使用在稳步增长，但并不均衡。
在谈论未来之前，先退一步
每个人都想得到答案的问题是：下一个大事件是什么？ 但在跳到那里之前，让我们先退一小步，回看过去。我们必须先建立对现实的恰当模型，然后再透过它去看未来。
到目前为止，AI 在软件开发中的演进历程是怎样的？
- 它始于简单的整行代码补全——AI 的作用范围仅限单行之内。
- 生成式 AI 带来了多行代码补全，即补全整块代码的能力。
- 更好的模型以及对对话式流程的关注，使得把整个对话引入 IDE 变得合理，AI 助手由此诞生。
- 像 Cursor 和 Windsurf 这样的 AI 代码编辑器，把 AI 能力带到了整个开发过程，将多个环节整合进同一个上下文与流程。
- 随后出现了智能体，我们把完整的端到端任务交给它们，并配有截然不同的 UI 范式——智能体开发环境。
- 而现在，这些智能体正在迁往云端，开始自主完成开发工作。
[LOADING...]
这读起来不太像一份功能清单，更像是一条轨迹。我们可以穿过这些点画出一条线，然后问自己：这条线究竟意味着什么？为什么 AI 在开发者工具中的这些形态会以这样的特定顺序出现？如果我们把这条线延伸到未来，它又会指向哪里？
AI 开发工具的「万有理论」
2025 年初，我们被要求汇总洞察以评估自身的 AI 战略。在做这件事的过程中，我们受到启发，想要创建一套「万有理论」：它不仅能解释该领域的现状，还能解释什么是根本上的可能性。就这样，我们最终形成了自己对 AI 开发工具的万有理论。我们称之为人工智能开发环境框架，即 AIDEs 框架。
和任何理论一样，我们从定义和假设开始。定义让我们得以摆脱当下的术语和狭隘思维，进行抽象；假设则为问题划定边界，使系统性的推理成为可能。这是任何严谨学科的通行做法，而令人惊讶的是，人们却很少把它用在思考开发者工具上。
定义
[LOADING...]
人工智能系统（Artificial Intelligent System，AIS）：任何由人类创造、在帮助用户达成其目标（即其待办任务，Jobs-To-Be-Done）时表现出「智能」特征的计算机系统。关键洞察是：人们希望从工具中感受到智能——但这种智能不一定非要来自 LLM。我们的 IDE 一直被认为是「智能」的，但它们能力的核心建立在确定性的启发式规则之上。因此原则是：以智能的用户体验为目标，而不是「到处都塞 AI」。
人工智能开发环境（Artificial Intelligent Development Environment，AIDE）：简单说，就是用于创建软件的 AIS。用于创建软件的工具集合极为庞大，它们作用于流程中的特定阶段，也对应着不同的工作委托层级。换句话说：IDE 之外还有一个广阔世界，充满着我们可能尚未考虑过的机会。
委托人与代理人（Principal and Agent）：这两个术语借自经济学与社会学，用来描述委托关系中两方的关系。委托人是其利益或目标得到服务的一方，代理人则是被托付、代表委托人行事的一方。但请记住，委托人和代理人都可以是人类，也可以是 AIS。这意味着我们可以考虑这样的场景：AI 委托人把工作委托给 AI 代理人，甚至 AI 委托人把工作委托给人类代理人。
软件创造（Software Creation）：我们用这个词而不是「软件开发」，因为后者可能让人以为软件主要就是写代码。现实中，软件创造涉及许多不同角色。这些角色可以被理解为委托关系：产品团队可能把实现委托给软件工程师，前端开发者可能把 UI 设计委托给 UX 设计师，等等。
委托的方向取决于你的视角。软件工程师可能把 UX 设计师看作自己在某项活动上要依赖的人；但从更广泛的产品团队视角看，二者或许都只是更大流程中的贡献者。在这个意义上，组织责任是相对于你审视工作的层级和视角而言的。加入 AI 并不会从根本上改变这一结构，它只是引入了一类新的行动者，可以参与这些关系。
假设
我们从四条基础假设出发：
1. 无论未来如何变化，人们仍会以创造软件为目标。 我们不相信对软件的需求会减少，也不相信人类会找到一种完全不同的技术来取代它。相反，数字化仍将是生产率提升与个人进化的主要驱动力，因此对软件的需求实际上还会增长。而且至少在中期内，软件开发的基本原则将保持不变。
2. 市场上变化的主要驱动力，将是软件创造活动逐步被委托给人工智能系统。 说实话——我们都有点懒，乐于把自认为例行的事务交出去。整个人类历史都支持这一点：从劳动分工到自动化，再到数字化——其核心都是委托。委托在今天市场上已经存在。在较高层级，人类把工作委托给其他人类（最全面的 IT 解决方案仍是协作创造的）；在较低层级，我们通过流程自动化把工作委托给人工系统。随着 AIS 的进一步发展，它们将成为分工本身中的关键行动者——而向 AIS 委托的程度不断提升，将成为衡量其真实能力与影响的终极指标。
3. AIS 永远不会完全取代人类，人类将保留两项关键工作：任务定义与监督。（文章《AI as Normal Technology》对这个问题有深入探讨。）AI 不会「杀死」开发者这一职业，但会改变这一职业的含义。今天，开发者角色中的高层任务定义与监督通常由架构师承担，这是需要多年积累才能达到的高级职级。未来，我们可能会看到初级架构师的出现——这是一个新类别，它不仅要求我们重新思考角色，还要求重新思考整个计算机科学教育体系。
4. 随着向 AIS 委托的程度提高，个人对具体开发活动的「沉浸」会减少。 简单说：如果活不是你干的，你对它的了解总会少于亲自动手。这正是今天人类委托人与人类代理人之间发生的情况。当开发者把附加值较低的活动（如代码编写）委托出去，并专注于附加值更高的活动（如需求表述）时，他们的意识会转向项目的「更高层级」。这并不意味着人人都会彻底转向「氛围编程」（毕竟，当前工具还没有为高层上下文的沟通与管理提供解决方案）。未来的开发者应当像开发负责人了解其团队交付的项目那样了解自己的项目。解决这种「沉浸感丧失」的问题，是提升委托层级的前提——这也是为什么上下文的抽象与不确定性的管理在本框架中如此重要。## 框架的三个维度
我们的框架在三个维度上运作：软件创建过程的阶段、委托的层级，以及开发的组织语境。
维度 1：软件创建过程的阶段
第一个维度是对传统软件开发生命周期的重新演绎，关注结果而非流程。我们将 35 项高层活动归入 5 个活动组——从“构思与概念化”到“交付、维护与反馈收集”。任何开发者都能立刻认出这些活动，因此我们在此不再赘述。请探索下面的交互式图表。
构思与概念化
在此阶段，软件创建者围绕最初的问题和潜在解决方案展开构思，探索并形成他们想要创造的愿景和高层概念，识别有价值的机会，并决定是否值得追求。
交付物形式
- 想法/概念/愿景
- 用户故事
- 产品需求文档（PRD）
- 低保真概念验证（PoC）或原型
活动
- 头脑风暴问题空间（机会、痛点、用户画像及其需求、市场趋势与要求、新技术带来的机会 ⇒ 我们在哪里看到对新软件解决方案的需求，以及为什么）
- 头脑风暴解决方案空间（软件类型、设计/UX/用户流程、当前技术机会、目标平台 ⇒ 我们如何解决最初的问题，以及最终解决方案可能是什么样子）
- 低保真原型制作（聚焦面向用户的部分或一般技术探索；包括验证）
- 记录最终概念和愿景
规划、设计与架构
在此阶段，软件创建者将初步想法和概念“操作化”，转化为“工程解决方案”的设计——从系统和软件工程的角度更具体地定义应该做什么。在此阶段之后，开发者（将编写代码的人）应当充分理解应该做什么、如何做，以及验收标准是什么（“完成的定义”）。
交付物形式
- 项目计划/路线图/待办列表
- 软件需求规格说明（SRS）
- 系统架构设计
- UI/UX 设计
- 软件组件设计/类图/数据库模式图
- 软件设计文档（SDD）/蓝图
- 一组更聚焦的概念验证（PoC）或原型，可在最终实现中复用
活动
- 定义总体解决方案的技术要求和验收标准
- 选择技术和工具栈
- 明确系统架构与组成
- 将实现拆解为具体任务/功能；为每个任务/功能定义要求和验收标准
- 设计 UI/UX/视觉元素
- 设计系统组件/数据层
- 制作技术解决方案原型
实现
在此阶段，软件创建者创建实现设计并通过初步验证的代码库及相关产物。此外，创建和验证该代码库/产物所需的任何活动也在此进行（例如设置数据库、使用外部服务，和/或创建自定义工具）。
交付物形式
- 作为完整解决方案、可工作增量或 MVP 的解决方案代码库
活动
- 设置开发环境（包括工具设置、VCS、依赖项、运行/构建配置/脚本）
- 编写核心业务逻辑（数据实体、数据转换函数、UI 组件的“行为”部分）
- 编写辅助基础设施代码（API 控制器定义、ORM 映射器、实用/辅助函数）
- 编写样式/UX 代码
- 临时代码验证（运行、调试、lint、性能分析）
- 设置持久化和外部服务层
- 开发支持工具
- 编写文档
测试、验证与质量保证
在此阶段，所创建的代码库会依据初始需求、验收标准和质量标准进行验证与确认。此阶段结束时意味着软件已通过 QA——所有关键缺陷均已修复，利益相关者确信产品正确且稳定。
交付物形式
- 对代码库按预期工作的总体信心
- 测试总结报告/已验证的测试用例
- 通过代码审查
活动
- 制定测试计划和策略；设计测试用例
- 设置测试环境
- 编写并运行自动化测试（单元、集成、端到端、回归）
- 进行手动测试
- 进行性能/负载测试
- 进行安全测试
- 进行可用性测试
- 进行代码审查
交付、维护与反馈收集
在此阶段，所创建的代码库通过部署（Web 生产环境）或分发（应用商店、文件存储、包仓库）交付给最终用户。此外，此阶段还涵盖软件解决方案的“运营”状态，包括维护（确保软件仍可供最终用户使用）和反馈收集（用于未来改进）。
交付物形式
- Web 生产环境中的应用代码
- 分发渠道中的应用可执行文件分发
- 分发渠道中作为包/源代码的解决方案代码库
- 收集到的应用和性能日志、使用指标、用户数据/反馈
活动
- 规划部署和/或发布方式
- 编写生产构建配置/脚本（例如 Maven、Gradle、yarn/npm、Docker）
- 编写生产部署配置/脚本（例如 Compose、Ansible、Terraform）
- 设置生产托管环境/分发渠道
- 创建部署/发布 CI/CD 流水线
- 管理云基础设施（手动、通过 API、通过 IaC）
- 监控生产环境中的软件，包括设置监控基础设施（CLI 日志、异常、使用/性能指标）
- 收集并分析用户行为和反馈数据，包括设置分析/反馈基础设施
关于我们的方法：该分类法旨在覆盖软件团队中任何角色参与的所有类型的开发（不仅仅是开发者），但也不至于细到让我们失去同质的活动组。各阶段看起来像线性工作流，但现实中开发者在阶段之间以及同一阶段内的活动之间来回跳转。这些活动也可以作为制定高层开发者待完成工作（Jobs-To-Be-Done）的基础。
维度 2：委托层级
这是更新颖的维度。在这里，我们定义委托方与代理之间的角色分配，以及 10 项委托属性——自主性、规划层级、主动性等。角色与属性值的不同组合定义了 五个委托层级：
L1——工具。 委托非常有限、范围明确的操作。代码补全是典型例子：你让 AI 完成你已经写下的内容。
L2——助手。 委托定义明确的一系列操作——一个边界非常具体的“任务”。一个例子可能是为特定函数生成单元测试。简单、定义明确、上下文最少——但它是一项包含一系列步骤的任务，而不只是一个操作。这就像有第三只手：它在干活，但仍然是你的手。
L3——通用执行者。 在这里，关注点开始从过程转向交付物。L3 代理可以执行任何任务，但需要委托方提供专家输入，而委托方在更复杂的问题上充当“顾问”。当前的代理式编码大致处于这个位置：我们认为 Claude Code 和 Codex 之类的代理很擅长写代码和低层解决方案工程，但我们仍不信任它们决定到底该构建什么——那需要对业务领域有更深入的知识。因此，我们完全委托执行，但保留任务设定和审查。
L4——受监督执行者。 在这里，我们超出个体空间，进入组织视角，因为代理现在负责整个开发职能，比如管理全栈 Web 应用的后端实现。它之所以是“受监督的”，是因为委托方的角色缩小为批准关键决策；其他一切由代理自行决定。这也是我们找不到现实例子的地方，或许除了 Lovable 或 Replit 等 vibe-coding 平台的一些使用模式。
L5——能力中心。 想象你是一家初创公司的 CEO，身边有一支工程团队。你定义公司想要实现什么、将如何实现、关键指标是什么，以及你是否表现良好。你的工程团队的存在是为了执行你的战略，让愿景成为现实。你不在乎他们用什么技术栈、应用有什么 API 结构，或者它托管在 Azure VM 上还是 GCP 托管 Kubernetes 上的 Docker 容器里——你把这些决策委托给团队。那种委托就是 L5。
属性视图 委托层级视图
选择属性
为什么“AI 有多聪明？”不是一个维度
你可能注意到这里明显少了点什么：没有任何关于 AI 原始能力或它能有多“聪明”的内容。这种省略是刻意的，原因有两个。
第一，基准测试表现不会自动转化为现实世界中的委托。 AI 模型可以在标准化测试中取得非凡结果，却仍然难以赢得人们足够的信任，以自主执行哪怕相对简单的任务。因此，我们可能看到某个 AI 模型拥有顶尖的基准测试结果，但经济影响却出奇地小。反过来，一个有效编排一组能力较弱代理的确定性系统，可能比单个超级智能的 AGI 产生更有用的工作。
第二——这也是更深层的要点——我们所描述的一切都不是代理的属性，而是委托方与代理之间关系的属性。 委托层级是委托方基于其对代理的个人感知所做出的决定。开发者可能把编写代码委托给 Junie 到 L3，让它端到端执行任务，但对于更关键的情况，他们会切换到 L2，把 Junie“拴上绳子”，喂给它窄得多的任务。即使代理有能力达到 L3，也会有一些场景中委托方选择少委托一些。委托层级不是 Junie 的属性——它是两者之间“代理契约”的属性，而委托方是设定条款的人。
即使 AI 技术上能够完成工作，决定放开多少控制权的仍然是人。
维度 3：开发的组织语境
第三个维度描述开发所处的组织语境。我们区分三种语境：
- 个人——以独自或小型非正式团体形式进行的开发（爱好、教育、开源、单人创业、自由职业）。工具要求宽松且由偏好驱动，黏性低，预算有限——即使付费体验更好，也更偏好免费选项。代码库规模和复杂度有限，对最终软件的要求（质量、安全、可靠性、流程标准）可能相当低。
- 中小企业——在中小公司、初创公司以及大型企业内高度自主的团队（“内部创业团队”）中进行的开发。生产级商业应用、现代技术、由专业人士组成的团队自行做出大多数决策，技术领导层只做轻度协调。速度和敏捷是核心目标，技术、流程和工具都围绕最大化这些目标而调整。工具价格很少是问题——薪资和基础设施主导成本结构。
- 企业——在大型商业公司中进行的开发。超大型项目（包括大型 monorepo）、遗留代码、正式且严格的质量和流程标准，以及对技术和工具的硬性要求。通常还有特殊的合规与安全需求（零数据保留、私有云、本地部署），以及对企业级客户体验（CX）的期望（集中式用户管理和计费、专属支持、自定义集成）。技术和采购决策集中化，强烈关注最小化交易成本。
这些语境定义了不同的约束类型和不同的组织动态复杂度——这些后来会反映在开发决策的复杂度中，并最终反映在代码库本身中。我们加入这个维度，主要是为了永远不忘这一方面——而且我们已经看到某些事情特别在大型组织规模上变得相关。
把它们放在一起：地图
现在，还记得我们之前的“时间线”图吗？通过框架的视角，很明显贯穿其中的那条线，其核心就是委托层级维度。但由于模型比一条线更丰富，我们还可以追踪 AI 在 SDLC 活动中的渗透如何增长，以及它在不同组织语境中如何不同。
在我们关于 AI 使用的定期调查中，有一个专门部分正是做这件事，这让我们能够构建所谓的 AIDEs 地图。
ChatGPT、Claude Code
未使用（0）
工具（1）
助手（2）
通用执行者（3）
受监督执行者（4）
能力中心（5）
问题头脑风暴
解决方案头脑风暴
低保真原型制作
概念记录
需求定义
技术栈选择
系统架构
任务制定
UI/UX 设计
系统设计
解决方案原型制作
设置开发环境
编写业务逻辑
编写基础设施代码
编写样式/UX
代码验证
持久化/外部层
编写工具
编写文档
规划测试/测试用例
设置测试环境
编写/运行自动化测试
手动测试
性能测试
安全测试
可用性测试
代码审查
规划部署
编写构建脚本
编写部署配置
设置生产环境
创建 CI/CD 流水线
管理云
监控
用户数据分析
未使用（0）
工具（1）
助手（2）
通用执行者（3）
受监督执行者（4）
能力中心（5）
在这样一张地图上，我们可以同时看到 ChatGPT 和 Claude Code 在哪里被使用、处于什么委托层级、在哪里没有被使用，以及它们彼此如何比较。而且由于我们定期收集这类数据，我们可以追踪其随时间的变化。
该框架预测了什么
那么，我们有了一个整体模型。我们已经描绘了我们曾经在哪里、现在在哪里。现在终于可以向前看了。
我们的数据显示，我们正处于地图的中间，即 L3“通用执行者” 层级，云代理才刚刚开始触及 L4。我们仍然看到整个 SDLC 中存在空白，因此还有充足的增长空间，而下一个演化阶段只需看着地图就很容易想象。但该框架描述的是根本力量，是现实的正式模型——这意味着我们可以走得更远，开始想象其“最终阶段”的更遥远未来。
问问自己：**L5“能力中心”**的世界状态是什么样子？在那里，我们可以把开发委托给一个智能系统，不只是作为一组任务，而是作为一种能力。在那里，创建软件的过程是什么样子？它仍然存在于 DevOps 运营循环中，还是会浮现出一种新的流程？回想我们关于任务规范和监督的假设：人类开发者到底会做什么？创建软件的体验本身会是什么感觉？
我们可以永远思考这些问题。以下是我们认为的主要方向。
第一：抽象化的兴起。 开发者会少想代码本身，多想真正的解决方案工程——架构、组成、数据和用户流，以及业务影响。这与低级编程中发生的事非常相似：今天我们很少思考代码如何在硬件上运行；我们通过语言和框架中内嵌的抽象来操作。代码总体上也会发生同样的事。焦点从“如何构建”转向“构建什么以及为什么”。好消息是，这对开发者来说并不新鲜。它只是会成为工作的核心。
第二：AI 在软件开发生命周期所有部分的垂直整合。 今天，AI 主要存在于我们的 IDE 或聊天应用中，这限制了它的上下文跨度。未来的系统将把 AI 端到端地整合到整个 SDLC 中。但这不简单地意味着“AI 成为大型开发平台的一部分”——我们正走向某个更有趣的方向。
第三（也可能是最迷人的）：人们将不再把 AI 当作工具，而是开始把它当作一种“智能资源”。
考虑任何生产过程，比如制作家具。我们从原材料开始，把它们转化为最终产品。木板变成桌子。软件创建也是一个生产过程，最终产品是一套软件。但那么，原材料是什么？
它是智能。很长一段时间里，我们人类是它唯一的来源。在组织中，智能是一种与拥有它的人不可分割的能力。现在，LLM 正在引入第二种智能来源——一种可以像任何原材料一样被当作可变资源来对待的来源。
继续用我们的“家具工厂”类比：当组织理解 AI 不只是锤子，而是木材本身时，我们可能会经历开发方式的根本转变。
[LOADING...]
我们最终可能会得到类似 代理式软件生产平台 的东西——垂直整合的软件生产系统，其中 AI 作为输入性的“智能资源”运作，围绕工作管理的主要层次——意图管理、执行和治理——来组织，而不是围绕 DevOps 循环，并由人类开发者管理生产系统本身。## 如何为未来做准备
令人兴奋，或许也让人有点不安。那么，你个人能做些什么来准备？
首先，有一个重要前提：我并不是在声称自己确切知道我们将走向何种未来（或我们究竟何时会抵达那里）。我们的框架只是描述了，在推动软件开发演进的关键力量作用下，什么在根本上可能。这是任何模型诚实的边界。但理解这些力量确实能让你在应对任何实际展开的未来时，拥有决定性优势。
所以，这里有一套实用方法——也是 JetBrains 所采用的方法：
审视我们的核心假设。 AI 真的扩大了委派开发工作的机会吗？它能作为一种“智能资源”吗？最终是否可能出现由人类开发者和 AI 同事组成的“混合”团队？还是说，实际上正在发生的是完全不同的事情？
建立你的模型——然后坚定采用它。 建立你自己的现实模型（或借用我们的 AIDEs Framework），接受它，并开始在其概念边界之内提出问题：作为一名开发者，我的职责会变成什么样？哪些技能会变得更重要？如果未来关乎“委派管理”，某些管理技能会成为必备吗？而如果我们仍处在纯工程领域：是否每个人都会成为软件架构师，出现高级、中级，甚至初级架构师这样的角色？这些技能中，哪些我已经具备？哪些还需要培养？我准备好改变了吗？
观察并验证。 观察世界，并用它来检验你的模型和假设。改变不会一夜之间发生——它是一个持续的过程，而且总会有摩擦和惯性。一个你从未验证过的模型，只不过是一种观点。
而如果你是工程领导者，你的目标会困难得多：你需要重新思考开发流程本身如何组织，以及如何将作为“智能资源”的 AI 嵌入到那些智能已经作为人类能力而存在的流程中。这值得单独专门讨论——而我们 JetBrains 已经有自己的愿景。敬请期待。
观看完整网络研讨会录像： AIDEs Framework——网络研讨会。