Ohhnews

分类导航

$ cd ..
Jetbrains Blog原文

AIDEs框架：JetBrains如何为AI开发工具构建"万物理论"

#aides框架#ai开发工具#委托层级#软件开发生命周期#jetbrains

我们正生活在一个真正有趣的时代。AI 正以几乎每天都有新模型、新工具和新实践出现的速度颠覆软件开发。许多团队的第一反应是花越来越多时间去追逐更新。

在 JetBrains 从事 AI 产品与市场研究近两年后，我们得出了一个不同的结论：变化的速度不是问题，只要你能看到更大的图景。 我们有意识地不去追踪发生的每一件事。相反，我们试图理解所观察到的一切从何而来——以及最终将走向何方。这给了我们一个透视的棱镜，一个区分信号与噪声的过滤器。也正是这一点让我们免于变化疲劳。

这篇文章讲的就是这个棱镜。但在进入框架本身之前，让我们从网络研讨会开始的地方开始：从我们今天在市场上实际看到的东西开始。因为如果不先建立一个对当下的诚实模型，就无法建立有用的未来模型。

我们今天在市场上看到什么

纵观我们的研究，有三件事格外突出。

第一，AI 已经成为开发者生活中的常见部分。 人们了解它，不仅在家里使用，也在公司使用——包括那些传统上对任何新事物采用最慢的大公司。我们不再质疑软件开发中的 AI 是否“成气候”。它已经到来，并且会持续存在。

第二，智能体编码正逐渐成为新常态。 越来越多的开发者使用 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 开发工具的万物理论的方式。我们称之为人工智能开发环境框架（Artificial Intelligent Development Environments Framework），简称 AIDEs Framework。

像任何理论一样，我们从定义和假设开始。定义让我们能够从当前的术语和狭隘思维中抽象出来；假设为问题划定了边界，使系统化推理成为可能。这是任何严谨学科中的标准做法，而令人惊讶的是，它很少被应用于思考开发者工具。

定义

[LOADING...]

人工智能系统（AIS）：任何由人类创造、在帮助用户实现其目标（他们的待完成的任务）时表现出“智能”特征的计算机系统。关键洞见是：人们希望从工具中感受到智能——但这种智能不一定非要来自 LLM。我们的 IDE 一直被认为是“智能的”，但其能力核心建立在确定性启发式规则之上。所以原则是：以智能的用户体验为目标，而不是“到处都有 AI”。

人工智能开发环境（AIDE）：简单来说，就是用于创建软件的人工智能系统。用于创建软件的工具种类繁多，它们被应用于流程的特定阶段和特定的工作委派层级。换句话说：IDE 之外有一个广阔世界，充满我们可能尚未考虑过的机会。

委托人与代理人： 这些术语借自经济学和社会学，用于描述委派关系中两方之间的关系。委托人是其利益或目标得到服务的一方，而代理人是被委托代表委托人行事的一方。但请记住，委托人和代理人都可以是人类或 AIS。这意味着我们可以考虑这样的场景：AI 委托人将工作委派给 AI 代理人，甚至 AI 委托人将工作委派给人类代理人。

软件创造： 我们使用这个术语而不是“软件开发”，因为后者可能暗示软件主要就是编写代码。现实中，软件创造涉及许多不同角色。这些角色可以被理解为委派关系：产品团队可能将实现委派给软件工程师，前端开发者可能将 UI 设计委派给 UX 设计师，等等。

委派的方向取决于你的视角。软件工程师可能将 UX 设计师视为在特定活动中所依赖的人，但从更广泛的产品团队视角来看，两者都可能只是一个更大流程的贡献者。在这个意义上，组织责任是相对于你审视工作的层级和视角而言的。加入 AI 并不会从根本上改变这一结构；它引入了另一种可以参与这些关系的行动者。

假设

我们从四个基本假设开始：

1. 无论未来如何变化，人们仍将拥有创造软件的目标。 我们不相信对软件的需求会减少，也不相信人类会找到一种完全不同的技术来取代它。相反，数字化将继续成为生产力提升和个人演进的主要驱动力，因此对软件的需求实际上会增加。并且至少在中期内，软件开发的基本原则将保持不变。

2. 市场变化的主要驱动力将是软件创造活动逐渐委派给人工智能系统。 说实话——我们都有一点懒，乐于把自认为例行的工作交出去。全部人类历史都支持这一点，从劳动分工到自动化，再到数字化——其核心都是委派。委派在今天的市场上已经存在。在更高层级，人类将工作委派给其他人类（最全面的 IT 解决方案仍然是协作创造的），而在更低层级，我们通过流程自动化将工作委派给人工系统。随着 AIS 进一步发展，它们将成为劳动分工本身不可或缺的行动者——而向 AIS 委派水平的上升将成为衡量其真实能力和影响的终极指标。

3. AIS 永远不会完全取代人类，人类将保留两项关键工作：任务定义与监督。（文章“AI as Normal Technology”对此主题有深入探讨。）AI 不会“杀死”开发者职业，但会改变这个职业的含义。今天，开发者角色中的高层任务定义与监督通常由架构师完成，这是一个需要多年才能获得的资深级别。未来，我们可能会看到初级架构师的出现——这是一个新类别，它不仅要求重新思考角色，还要求重新思考整个计算机科学教育体系。

4. 随着向 AIS 委派的水平提高，个人对特定开发活动的“沉浸”将减少。 简单来说：如果你不是亲自做这项工作的人，你对它的了解总会少于自己亲手做过。这正是今天人类委托人和人类代理人之间发生的情况。当开发者将附加值较低的活动（如编写代码）委派出去，并专注于附加值更高的活动（如需求制定）时，他们的意识会转向项目的“更高层级”。这并不意味着每个人都会完全转向“氛围编程”（毕竟，当前工具并没有为高层上下文沟通和管理提供解决方案）。未来的开发者应该像开发负责人了解其团队交付的项目那样，了解自己的项目。解决这种“沉浸感丧失”问题，是提升委派水平的前提——这就是为什么上下文抽象和不确定性管理在该框架中如此重要。## 框架的三个维度

我们的框架在三个维度上运作：软件创建过程的阶段、委托层级，以及开发的组织情境。

维度 1：软件创建过程的阶段

第一个维度是对传统软件开发生命周期的重新演绎，关注结果而非流程。我们映射了归入 5 个活动组的 35 项高层活动——从“构思与概念化”到“交付、维护与反馈收集”。任何开发者都会立刻认出这些内容，因此我们在此不再赘述。请探索下面的交互式图示。

构思与概念化
在这一阶段，软件创建者围绕原始问题和潜在解决方案进行构思，探索并形成他们想要创造的愿景和高层概念，识别有价值的机会，并决定是否值得推进。

交付物形式

  • 想法 / 概念 / 愿景
  • 用户故事
  • 产品需求文档（PRD）
  • 低保真概念验证（PoC）或原型

活动

  • 对问题空间进行头脑风暴（机会、痛点、用户画像及其需求、市场趋势与需求、新技术带来的机会 → 我们在哪里看到对新软件解决方案的需求，以及为什么）
  • 对解决方案空间进行头脑风暴（软件类型、设计 / UX / 用户流程、当前技术机会、目标平台 → 我们如何解决原始问题，以及最终解决方案可能是什么样子）
  • 低保真原型制作（侧重面向用户的部分或总体技术探索；包括验证）
  • 记录最终概念与愿景

规划、设计与架构
在这一阶段，软件创建者将最初的想法和概念“操作化”为“工程解决方案”的设计——从系统和软件工程的角度更具体地定义应该做什么。在此阶段之后，开发者（将编写代码的人）应当清楚理解应该做什么、如何做，以及验收标准（“完成的定义”）是什么。

交付物形式

  • 项目计划 / 路线图 / 待办列表
  • 软件需求规格说明书（SRS）
  • 系统架构设计
  • UI / UX 设计
  • 软件组件设计 / 类图 / 数据库模式图
  • 软件设计文档（SDD） / 蓝图
  • 一组更聚焦的概念验证（PoC）或原型，可在最终实现中复用

活动

  • 定义总体解决方案的技术需求与验收标准
  • 选择技术与工具栈
  • 明确系统架构与组成
  • 将实现拆解为具体任务 / 功能；为每个任务 / 功能定义需求与验收标准
  • 设计 UI / UX / 视觉元素
  • 设计系统组件 / 数据层
  • 对技术解决方案进行原型制作

实现
在这一阶段，软件创建者创建代码库及相关制品，以实现设计并通过初步验证。此外，创建和验证该代码库 / 制品所需的任何活动也在此进行（例如设置数据库、与外部服务交互，和 / 或创建自定义工具）。

交付物形式

  • 作为完整解决方案、可运行增量或 MVP 的解决方案代码库

活动

  • 设置开发环境（包括工具设置、VCS、依赖项、运行 / 构建配置 / 脚本）
  • 编写核心业务逻辑（数据实体、数据转换函数、UI 组件的“行为”部分）
  • 编写辅助基础设施代码（API 控制器定义、ORM 映射器、实用 / 辅助函数）
  • 编写样式 / UX 代码
  • 临时代码验证（运行、调试、linting、性能分析）
  • 设置持久化层和外部服务层
  • 开发支持工具
  • 编写文档

测试、验证与质量保证
在这一阶段，所创建的代码库会依据初始需求、验收标准和质量标准进行验证与确认。此阶段结束时意味着软件已通过 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 更有用的工作。

第二——这是更深层的要点——我们所描述的一切都不是代理的属性，而是委托方与代理之间 关系 的属性。 委托层级是委托方基于其对代理的个人感知所做的决定。开发者可能会把代码编写以 L3 委托给 Junie，让它端到端执行任务，但在更关键的情况下，他们会切换到 L2，把 Junie“拴上绳子”，交给它窄得多的任务。即使代理有能力达到 L3，也会有一些场景中委托方选择少委托一些。委托层级不是 Junie 的属性——它是两者之间“代理契约”的属性，而委托方是设定条款的人。

即使 AI 在技术上能够完成工作，决定放手多少控制权的仍然是人。

维度 3：开发的组织情境

第三个维度描述开发所处的组织情境。我们区分三种情境：

  • 个人——由个人或以小型非正式团体进行的开发（爱好、教育、开源、一人初创公司、自由职业）。工具要求宽松且由偏好驱动，粘性低，预算有限——即使付费体验更优，也偏好免费选项。代码库规模和复杂度有限，对最终软件的要求（质量、安全、可靠性、流程标准）可能相当低。
  • 中小企业（SME）——在中小公司、初创公司以及大型企业内部高度自治团队（“内部初创团队”）中进行的开发。生产级商业应用、现代技术、由专业人士组成的团队自行做出大多数决策，技术领导层仅进行轻度协调。速度和敏捷性是关键目标，技术、流程和工具都为最大化这些目标而让步。工具价格很少成为问题——薪资和基础设施主导成本结构。
  • 企业——在大型商业公司内进行的开发。超大型项目（包括大型 monorepo）、遗留代码、正式且严格的质量与流程标准，以及对技术和工具的硬性要求。通常还有特殊的合规与安全需求（零数据保留、私有云、本地部署），以及对企业客户体验的期望（集中式用户管理与计费、专属支持、自定义集成）。技术和采购决策集中化，非常关注最小化交易成本。

这些情境定义了不同类型的约束和不同复杂度的组织动态——这些随后会反映在开发决策的复杂度中，并最终反映在代码库本身。我们加入这个维度，主要是为了永远不忘掉这一方面——而且我们已经看到某些事物特别在大型组织的规模上变得相关。

把它们放在一起：地图

现在，还记得我们之前的“时间线”图吗？通过框架的视角，显而易见，贯穿其中的那条线本质上就是委托层级维度。但由于模型比单条线更丰富，我们还可以追踪 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...]

我们最终可能会得到类似 Agentic Software Production Platforms（代理式软件生产平台） 的东西——垂直整合的软件生产系统，其中 AI 作为输入的“智能资源”运作，围绕工作管理的主要层次——意图管理、执行和治理——来组织，而不是围绕 DevOps 循环，由人类开发者管理生产系统本身。## 如何为未来做好准备

令人兴奋，或许也有一点令人不安。那么，你个人可以做些什么来做好准备？

首先，一个重要说明：我并不是声称自己确切知道我们正走向哪种未来（或确切何时会抵达那里）。我们的框架只是描述：在驱动软件开发演进的关键力量之下，根本上有哪些可能。这是任何模型诚实的边界。但理解这些力量，确实能让你在应对实际展开的无论何种未来时，拥有决定性的优势。

所以，这里有一个实用方法——JetBrains 使用的也是同一套方法：

审视我们的核心假设。 AI 真的会扩大委派开发工作的机会吗？它能充当一种“智能资源”吗？最终是否可能出现由人类开发者和 AI 同事组成的“混合”团队？还是说，正在发生的完全是另一回事？

建立你的模型——然后坚定采用它。 建立你自己的现实模型（或借用我们的 AIDEs 框架），接受它，并在其概念边界之内开始提问：作为一名开发者，我的职责会变成什么样？哪些技能会变得更加重要？如果未来关乎“委派管理”，某些管理技能会成为必备吗？而如果我们仍留在纯粹的工程领域：每个人都会成为软件架构师吗，并分化出高级、中级，甚至初级架构师这样的角色？这些技能中，哪些我已经具备？哪些需要我培养？我准备好改变了吗？

观察并验证。 观察世界，并让你的模型和假设接受现实的检验。变化不会一夜之间发生——它是一个持续的过程，总会存在摩擦和惯性。一个你从未验证过的模型，不过是一种观点。

如果你是工程负责人，你的目标会难得多：你需要重新思考开发流程本身应如何构建，以及 AI 作为一种“智能资源”应如何嵌入那些智能已经作为人类能力存在的流程之中。这值得单独展开讨论——而我们 JetBrains 已经有了自己的愿景。敬请关注。

观看完整网络研讨会录像： AIDEs 框架——网络研讨会。