【导读】
靠 AI 简单加持的集成开发环境（IDE），真的满足你了吗？本文整理自字节跳动豆包MarsCode团队技术专家天猪在 2024 全球软件研发技术大会中的演讲，从 IDE 设计者和资深程序员的角度出发，深度剖析程序员心中对 IDE 的真正需求，给出 AI 时代下衡量 IDE 优劣的重要标准。
我已经从业很多年了，当时可能还没有前端这个岗位。
高二那年，中国刚兴起互联网，网吧每小时要收 12 块钱。我开始学习编写 HTML + JS + CSS 甚至 Flash，从北邮毕业后，先在小公司待了很多年，接着加入了 UC。随着 UC 被阿里收购，我在阿里游戏负责前端团队，搞前端工程化。几年后，为了去看看国内前端的圣地，就应玉伯邀请，转岗去了蚂蚁的体验技术部，主要深耕在 Node.js 基础设施领域。这么多年里也一直在社区参与开源项目，EggJS 和 CNPM 就是我核心参与的 2 个开源项目，欢迎通过 GitHub（@atian25）跟我交流。
加入字节跳动之后，我一直在继续做基础设施建设。入职后，我发现一件很有趣的事：在字节内部有非常大比例的正式员工在使用自研的云端 IDE（集成开发环境），而在其他大厂更多是外包同学在用。这可能是因为字节有很多 monorepo（单一仓库）模式，大库的本地运行极为耗时，又譬如我们的员工遍布全球各地，需要随时随地可以进行编码，种种因素促使云端 IDE 在字节跳动内部的使用需求持续高涨。
2022 年，ChatGPT 横空出世，引爆整个人工智能行业，AI 的能力以超越人类想象的速度进化。如果用第一性原理来看大语言模型，本质上大语言模型的唯一工作就是预测下一个 token，相比起复杂的自然语言，编程语言是更加简洁、严谨、可预测的。我们已经看到了大语言模型在自然语言预测上令人震惊的效果，因此有理由相信，大语言模型在编程语言预测上也具有非常大的潜力。
在过去的这些年，我所在的部门一直从事开发者工具相关工作，我们的产品服务了字节内部成千上万的工程师，在字节内部有 70% 的工程师在使用豆包代码助手的内部版本来提升他们的开发效率，大语言模型的出现，让我们看到了新的生产力提升开发者效率和体验的可能性，也让我们有机会能够在 AI 时代更好地服务所有开发者，我们非常兴奋能够参与到这一旅程之中。
大概在去年年底时，我与团队开始参与到豆包MarsCode的开发。这个产品目前提供了两种形态：一是许多人熟悉的本地编程助手插件，二是云端的 AI IDE。其中我们的 AI IDE 涉猎到整个链路，包括 IDE UI（用户界面）、IDE Server (服务）、工作区容器、场景化服务等很多能力，而我主要负责工作区和场景化。
豆包MarsCode这个产品和字节跳动的理念其实是一致的：“激发创造，丰富生活”。我们期望用 AI 来激发程序员，包括广大的“泛程序员”群体，让用户使用我们的产品实现过去 10 倍的生产力，成为超级程序员。我们坚信，AI 在编程领域的潜力远未被充分挖掘，当前的 AI 辅助编程仅是冰山一角，未来将朝着结对编程乃至 AI 驱动编程的方向迈进。
我们希望打造一款世界级的产品，拥有世界级的体验，也希望有越来越多认同这个趋势的同道者一起前行，也许是那个愿意『较真』，为 IDE 的颜值能折腾字体和配色一两周的你，也许是那个勇于挑战 K8s 和云服务极限，『抬高技术天花板』的你，期望能加入我们一起探索未来。
AI IDE 演进史
作为一名资深程序员，我每天仍需要写非常多的代码，所以我想从自己的视角观察 IDE 的演化历史，并扪心自问：我们需要怎么样的一款 IDE？
在计算机编程的历史长河中，最初的程序员甚至需要通过打孔机 + 编织机来输入指令，这一过程孕育了编程一词，因为程序真的是“编”出来的。随后，我们进入了文本编辑器时代，Vim、UltraEdit 等轻量级工具与 Eclipse、JetBrains 等 IDE 的重功能分化，形成了编程工具的早期格局。
进入 21 世纪的前十年，纯文本处理的文本编辑器与 IDE 之间的界限开始模糊，代码编辑器时代悄然来临。Sublime 的出现堪称转折点，它不仅解决了处理大型文件时的性能瓶颈，还引入了快捷操作、命令面板等现代 IDE 常见的功能，极大地提升了开发效率。与此同时，Atom 作为 GitHub 当时的孵化产品之一，凭借其强大的插件生态和高度定制化能力迅速走红，尽管性能问题一直为人所诟病。
紧接着，微软推出了 VSCode，这中间有一段传奇的故事：Atom 和 VSCode 在技术上的底层框架 Electron 是由中国开发者赵成（GitHub @zcbenz）开发的。虽是“同根生”，但 VSCode 相比 Atom 采取了不同的策略，它在初期非常克制，专注于性能等用户体验，譬如很多面板当时都是不支持定制的。VSCode 在生态和体验找到平衡点，最终迅速成为最受欢迎的代码编辑器之一，击败了 Atom。
随后，AI 技术开始进入至编程领域。前文已经提到，大模型的本质是对下一字符的预测，而这一能力不仅适用于自然语言的翻译（如今 ChatGPT 已经能解决很多翻译需求了），同样适用于编程语言的解析与生成。对程序员而言，编程语言（如 Java、JavaScript）本质上也是一种语言，AI 能够理解和生成这些语言，为编程带来了新的可能性。
随着 AI 技术的普及，各类 AI 驱动的 IDE 产品如雨后春笋般涌现。GitHub Codespaces 和 Replit 等产品也纷纷开始积极拥抱 AI 辅助编程，前者凭借微软的深厚底蕴赢得了广泛认可，后者则快速转型，成为前端页面预览与分享领域的佼佼者，用户基数庞大。此外，还有 Cursor 这样的代码编辑器以其在 AI 领域的深入探索，吸引了众多技术爱好者的青睐。同样，我们豆包MarsCode应运而生，想一起去探索这项技术的极限。
这引出了下一个问题：我们程序员需要的 IDE 有哪些要素？
从我的视角出发，理想的 IDE 应具备以下核心要素：
1.卓越的开发体验：我用简单的几个字来诠释我眼中的“开发体验”：颜值即正义。在程序员眼中，IDE 的美观度和交互体验其实至关重要，第一印象往往决定了后续的使用意愿。
2.随时随地开发：在当今时代，能否实现随时随地开发成为衡量 IDE 优劣的另一重要标准。是否必须依赖本地电脑进行开发？是否在学习一门新语言时需要重新配置环境？甚至外出时带个配备妙控键盘的 iPad Pro 应急编程一下？这些场景下的开发体验同样重要。因此，理想的 IDE 应具备跨终端与跨场景的兼容性，实现即开即用，随时可投入开发状态。未来，我们期待更加颠覆性的人机交互体验，IDE 的形态是否会迎来根本性的变革，这一点令人充满期待。
3.AI 原生价值：AI 技术的原生集成对于下一代 IDE 至关重要。随着 AI 技术的普及，每位程序员仿佛拥有了一位高潜力的实习生，能够协助完成诸多任务。AI 技术对编程领域的影响主要体现在两个方面：一是提高研发效率，加速编码进程；二是辅助决策，提供高质量的问答服务。当前，我们正处于 AI 辅助编程的阶段，那未来是否会迈入 AI 驱动编程的新时代？对此，我满怀期待，积极参与其中，见证这一进程的推进。
AI 辅助编程
接下来，我们将聚焦于核心话题——AI 辅助编程。
如图 1 所示，这份开发者社区调研结果揭示了程序员对于 AI 的具体需求。实质上，我们归纳出了代码生成、补全、自然语言转代码、初始代码生成、单元测试生成以及代码解释等方面的需求。特别是在接手新库或模块时，理解其内部逻辑变得尤为重要。
图 1 开发者社区调研结果
从开发者的角度审视，我们关注的两大方面是：
第一，提高研发效率。加速编码过程，提升生产力，是 AI 辅助编程的首要目标。当前，代码补全功能已趋于成熟，Copilot 等工具便是快速补全代码片段的优秀实例。自然语言驱动的代码生成同样不可或缺。另外，代码推荐功能虽在社区讨论较少，但已有初步探索。自动修复代码错误的能力更是备受期待。
第二，提供决策辅助。借助 AI 实现高质量的问答，帮助开发者更好地理解项目，是另一大关键议题。这涵盖项目解读与互联网搜索能力的增强，我将在下文逐一展开。
代码生成
代码生成功能为人熟知，通过自然语言界面，无论是在独立窗口还是 IDE 内部，都能便捷生成代码。个人认为，将代码生成功能融入 IDE 更为理想，因为它能提供更多上下文信息，使生成的代码更贴合实际需求。独立窗口虽可行，但用户需额外提供细节，相比之下效率较低。目前，Side Chat[1] 和 Inline Chat[2] 是两种常见实践，不过我认为它们的交互形态还有较大的提升空间，当前还远不是完成态。
[1]: 与 AI 助手的独立聊天窗口，这个窗口通常位于代码编辑器的一侧。
[2]: 在代码行的直接上下文中进行的交互方式。
代码补全的原理
代码补全的核心机制在于预测下一个字符的可能性，这要求模型不仅要理解现有代码的上下文，还要预知后续的逻辑发展。以往，代码补全主要体现为基本的代码提示功能，例如编写代码时出现的下拉菜单供开发者选择。然而，微软公司旗下的 GitHub Copilot 产品带来了颠覆性的改变，将传统的下拉列表转变为代码编辑器内的“幽灵文本”（Ghost Text，指用户在编辑器中输入时出现的内联建议）提示，极大地改善了用户体验。通过简单的几次敲击
实现这一突破的关键在于两点：一是模型需具备强大的性能，确保快速且准确地生成代码建议；二是 Prompt 工程设计的重要性，即如何构建有效的输入提示，使模型能准确捕捉开发者的意图。
在 IDE 中，代码补全的过程相当直观：收集当前光标位置、前后代码片段、文件类型以及关联的其他文件信息。这些数据通过 IDE 的 API 获取，整合成一个完整的 Prompt，明确告知模型当前的代码环境，并请求其进行补全。模型接收到 Prompt 后返回建议，过程中可能涉及预处理与后处理步骤，旨在提升补全质量。
Prompt 工程，即 Prompt 构造技巧，蕴含着丰富的细节。恰当提取和展现上下文信息对性能有着至关重要的影响，过多或不相关的上下文信息反而可能妨碍模型的理解，因此，精确地定位和筛选上下文信息是提高代码补全效果的关键。
代码补全的测评指标
评估代码补全工具的效能时，选择恰当的评测指标至关重要。
尽管“HumanEval”在代码领域享有盛誉，但我们认为它并不适合作为代码补全场景下的理想评估标准，因为该指标与实际应用场景存在较大脱节。为了更贴合实际开发环境，获取真实反映模型性能的数据，我们倾向于采用在线测评的方法，通过 A/B 测试动态调整参数，甚至决定是否更新模型版本，从而获得更为客观和实用的反馈。
“采纳率”这一指标虽被频繁提及，但仅凭采纳率难以全面评判代码补全的质量。如果只看“采纳率 = 采纳次数 / 推荐次数”，容易受多种因素影响，缺乏指导具体优化方向的能力。
为此，我们采用了一项更为全面的评估指标—— CPO（Character per Opportunity，“每次补全机会的平均字符数”），它旨在从多个维度综合考量代码补全工具的性能。CPO 的计算公式如下：
尝试率
尝试率，实际上反映的是 AI 向用户实际提供补全建议的频率。想象一下，当用户在编码时，每进行十次敲击动作，可能只有六次触发了向 AI 请求补全的行为，此时尝试率即为 6/10。通俗地讲，就像在一个相亲会上，面对十位潜在的伴侣，你可能仅对其中六位发出了交友邀请，故尝试率为 6/10。
影响尝试率的因素主要有两个方面。首要因素是前置操作的延迟，即获取上下文（Context）的速度。用户敲击键盘的速度通常较快，AI 系统必须能够跟上这一速度。如果用户敲击一个字符后，AI 的响应时间长达一分钟，这时用户可能已经敲入了下一个字符，导致 AI 返回的补全建议不再适用。因此，迅速且准确地获取上下文是关键，这涉及到模型的运行速度以及能否高效提取并传递准确的上下文信息给 AI。举例来说，如果模型的响应时间从 1 秒缩短至 0.5 秒，用户在等待补全建议的过程中，可能就会更愿意尝试使用 AI 补全功能，从而提高尝试率。
其次，提供多样化的展示方式也是提升尝试率的重要手段。类比于求职者投递简历，除了常规渠道，还可以通过参加行业会议、网络平台等多种途径增加曝光机会。在代码补全场景中，可以考虑将下拉提示与幽灵文本相结合，在编辑器中直接展示补全建议，用户只需轻轻按下 TAB 键即可采纳建议，无需离开当前编辑界面。这种方式不仅提供了更多的展示机会，也简化了采纳补全建议的流程，从而有效提升尝试率，增加了 AI 展示自身补全能力的机会。
反馈率
反馈率，实质上反映了 AI 生成的补全建议在被真实展示给用户的机会中的比例。即便我们向 AI 发送了六次请求，但最终可能只有三次建议被真正展示给了用户，这时反馈率即为 3/6。以日常生活中的比喻来说，你可能向六个人发出了交友邀请，但由于种种原因，如手机信号不佳或对方头像不合眼缘，最终只成功发送给三位，这里的反馈率同样为 3/6。
在 AI 产品领域，有些产品的采纳率异常之高，究其原因，在于它们在生成补全建议的过程中，会调用第三方 API 获取额外信息，从而显著提升建议的准确性和丰富度。然而，如果处理速度过慢，即使生成的建议质量上乘，也可能因“时机”错失，无法及时呈现在用户面前，这正应了那句老话：“酒香也怕巷子深”。
影响反馈率的因素及优化策略主要涵盖以下几点：
- 时效性与模型优化：网络延迟、模型自身的推理速度，以及在保证质量的前提下，选择更小、更快的模型，如通过量化操作或谨慎地限制推荐范围，都是提升反馈率的关键。并非推荐越多越好，因为这往往会降低速度。
- 内容质量与展示决策：在某些情况下，即使建议生成速度快，但工具侧可能会进行后置检查，如果判断建议质量不高，则不会将其展示给用户。例如，对于含有敏感内容或不符合规则的信息，主动选择不展示也是一种策略。
每次采纳平均 token 数 & token 平均字符长度
这两个指标共同构成了评估模型生成建议实际价值的重要维度。每次采纳平均 token 数反映了模型生成建议的“性价比”，即一个 token 能够产生多少字符，进而影响到生成代码的丰富度和实用性。这就好比在日常交流中，你向好友发送一段消息，对方是用长篇大论详细回复，还是仅仅回复“呵呵”二字，两者所带来的实际价值完全不同。
另一方面，token 的平均字符长度则更多地从人类视觉角度出发，因为人们阅读的是字符而非 token。不同的模型可能有不同的字典和 token 划分方式，这意味着在代码补全或 IDE 环境下切换模型时，需要通过这两个指标将不同模型的表现转换到同一尺度上，以确保评估的一致性和可比性。
关于 CPO 与采纳率之间的关系，我认为图 2 生动地表达了两者的区别。CPO 代表的是真实价值，而采纳率则反映了感知价值。采纳率是直观感受的，能够给予用户即时的满足感，而 CPO 则更注重实际产出的效益，并能指导我们如何进一步优化。
图 2 CPO/采纳率
图表中，A、B、C 三点分别对应不同的 CPO 值与采纳率组合。A 点的 CPO 最高，但采纳率最低；B 点的 CPO 稍降，采纳率却明显提升；而 C 点的边际成本不划算，牺牲了 CPO 但采纳率提升有限。在实际应用中，寻找 CPO 与采纳率之间的平衡点至关重要，不应片面追求某一指标，因为真实价值与感知价值都是评价模型性能不可或缺的方面。
代码推荐
代码补全工具往往更擅长于生成全新的代码片段，而非优化已有的代码库。比如，当你在一个对象中添加属性后，是否能智能预测下一步操作，如自动插入 console.log 语句或者修复 Lint 错误？为了实现这一目标，我们通过分析海量的 Git Commits 记录，从中学习用户的编辑行为，将每次属性变更视为 diff 变化，构建出了一套训练模型，以期达到预测编辑动作的目的。
如下动图展示的是豆包MarsCode内部测试的一项功能。例如，当用户添加注释后，仅需连续按下 TAB 键，AI 就能根据上下文智能推断并自动完成后续的代码修改。
预测下一个编辑动作
这表明，AI 有能力预测用户的下一个编辑动作，当用户完成一个操作后，它能精准定位到下一个需要编辑的位置，再次按下 TAB 键，它就会自动进行修正。这一特性同样适用于语言列表的下拉菜单，每当添加一个新属性时，AI 可以智能提示用户可能需要更新的其他部分，只需按几下 TAB 键，即可快速完成代码调整。
我坚信，这种基于预测的编辑辅助功能，将在未来一年内在各种 AI 产品中迅速普及，成为行业标准配置之一。
代码修复
这是目前正在探索的方向之一，核心在于利用 AI 智能体（Agent），结合诸如 LSP、AST 和 Lint 等工具，让 AI 具备静态分析代码的能力，识别潜在的问题。更进一步，AI 是否能够动态运行代码，获取运行时的上下文信息。Swe-bench 是一个评价代码修复能力的平台，近期我们的团队曾在此平台上获得全球第三的成绩，但这一领域的竞争异常激烈，这个分数虽有价值，其实也没那么重要。就像移动互联网时代的安卓手机和 iPhone，它们的硬件元件都大差不多，我们却只在看到安卓手机时会提到跑分，但手机最终的质感却完全不一样，所以最终的用户体验才是决定因素。目前，该领域仍处于起步阶段，预计在未来的一到两年内，代码修复将是极具潜力的研究方向。
辅助决策
前文关于代码推荐的部分已经提到，在项目问答方面，关键在于 AI 能够深入理解项目的上下文信息。鉴于 AI 的数据集可能存在局限，实现实时搜索，获取最新信息，是提升 AI 实用性的重要途径。例如，当需要编写爬虫程序时，能够向 AI 咨询并自动获取所需库的信息，这在前端 Node.js 迅速迭代的环境中尤为重要，因为仅依赖 AI 的学习内容有时难以应对最新的技术发展。
豆包MarsCode 的工程实践
我们已经介绍了程序员对 IDE 的要求以及未来 AI 编程所涉及的几大主要功能，因此下面以豆包MarsCode的具体工程实践为例，谈一谈开发这款产品的过程中诞生的一些想法。
颜值即正义
前文提到，程序员其实非常关心 IDE 的外观，而我们坚信“颜值即正义”的理念，因此深度钻研了豆包MarsCode IDE 的外观设计。我们注重每一个细节，旨在通过提升开发者的实际体验来探索创新的可能。
第一印象至关重要，想打造良好的第一印象，需要始终遵循“亲身体验”的原则，即亲自使用我们开发的产品，确保每个环节都能达到预期的高标准。事实上，我起初对优化 IDE 的交互设计持保留态度，作为一名忠实的 VSCode 用户，我对其丰富的插件生态、自定义主题等功能感到满意，不太愿意轻易改变。
然而，在深入研究后，我逐渐认识到，作为长期使用者，我们可能对某些界面和操作习以为常，以至于忽视了它们可能存在的问题，尤其是对于新手用户而言，这些界面可能并不友好。
为此，我们细致地分析了 VSCode 的各项功能，包括其界面布局与交互流程，发现了许多值得改进的细节。
如下图 3 的“黄金分割线”设计，它是我们无数个晚上讨论和精心打磨用户体验的一个小例子。我们精心调整界面比例，确保每个界面元素都能达到最佳的视觉平衡。此外，我们还深入探讨了如何优化 AI Inline Chat 的交互方式，以及代码 Diff（差异）编辑器的用户体验，这些在现有 IDE 中往往存在不足之处，我们力求在这些方面实现突破。
图 3 “黄金分割线”的界面设计
为了革新设计，我们对传统交互模式进行了大胆改革。以往的 IDE，如 VSCode，界面左侧堆砌了大量功能按钮，显得杂乱无章，这不仅影响美观，也不利于高效操作。因此，我们采用了就近原则，对功能区域进行合理划分，将所有工具集中于右侧，常用操作如 Run（运行）和 Deploy（部署）则置于顶部，以此简化用户操作路径，提升使用效率，使 IDE 的操作逻辑更加直观和人性化。
此外，以 AI Chat 为例，我们在交互设计上经历了多次争执和调整：Inline Chat 真需要在编辑区展示那么一大段的结果么？它和 Side Chat 的边界是什么？Side Chat 里面真的需要用户去选择一大堆文件吗？它只是一种当下大模型还不够强大之下的无奈妥协，我们能不能继续优化和做减法？
设计概念的实现远比想象中复杂，花费了团队大量时间讨论和优化。设计师们会从初学者的角度审视每一处细节，挑战我们作为资深程序员的固有思维，促使我们重新思考界面布局的合理性。这些思想的碰撞，最终推动了设计的不断进化。
我们致力于打造更普惠、易用的开发环境，尤其在启动速度上，我们的 IDE 远超 GitHub Codespaces 和 Google IDX，达到了五秒，与业界最快的 Replit 处于同一水平，尽管两者定位有所不同，Replit 偏轻量化，而我们更注重整体功能的完善。
随时随地开发
接下来，我们聚焦于“开箱即用”的概念，目标是实现随时随地的开发。从架构角度来看，这一目标的实现相对直接——顶层是 IDE 的 UI（用户界面），中间层为 IDE 的 Service（服务）逻辑层，而最底层则是运行代码的工作区，共同构成了一套成熟稳定的架构模式。
实现随时随地开发的核心在于快速启动云端开发环境。这是一项技术挑战，因为云端环境的启动速度直接影响用户体验，必须做到迅速响应。同时，我们致力于确保开发环境跨设备兼容，无论是桌面浏览器、iPad 还是本地计算机，都能无缝接入，提供一致的编程体验。
此外，支持多种编程语言同样至关重要。在 AI 时代，学习一门新语言变得相对容易，但随之而来的环境配置问题却令人烦恼。例如，学习 Python 时，本地环境极易因不当操作而受损，且安装各类依赖库可能带来安全风险。此时，云环境的价值得以彰显，它不仅能够迅速创建安全、隔离的编程环境，还确保了环境的一致性和安全性，避免了本地环境配置的复杂性和潜在隐患。
对于服务器层而言，其运作并非局限于单一工作区。在轻量化场景下，服务器可以采取高密度部署的方式，譬如只需要一个 File 文件服务和LSP（Language Server Protocol，即一个代码编辑器需要的最基础能力 —— 代码提示能力）即可。从 UI 到服务器，再到后端容器，整个系统展现出极高的灵活性和可组合性，能够根据不同的需求自由搭配，形成多样化的形态，为开发者提供更加丰富和个性化的选择（见图 4）。
图 4 组件化的系统
从应用场景的角度看，我们的视野不应局限于传统的 IDE。组件化是关键，这意味着 IDE 的 UI 和服务器层需要模块化，以便于在不同场景下灵活嵌入和定制。IDE 不再仅限于我们常见的形式，它可以融入到各种环境中，例如，当程序员在协作平台上编写代码时，代码编辑框本身是否也可以被视为一种 IDE 的变体？Anthropic 公司发布的 Claude 3.5 Sonnet 大模型中推出了一个名为“Artifact”的功能，它本质上是一款高级版的代码解释器，这是否预示着另一种 IDE 的形态？事实上，我们团队也在着手类似项目的孵化。所以当我首次了解到 Artifact 时，先是惊叹他们的进展比我们更快一步。就在他们公布这一成果的一个月前，我们内部也恰好在讨论类似的形态，只能说 “英雄所见略同”，可惜我们人不多，需要有优先级侧重。
Artifact 的亮点在于，它不仅是所谓的“代码解释器”（Code Interpreter）的升级版，更是将代码执行过程可视化，引入了双向交互机制。传统的代码解释器仅负责代码执行，但用户无法直观观察执行细节。Artifact 的独特之处在于，它额外提供了交互层，使得代码执行和结果展示过程变得生动直观，极大提升了用户体验。
从技术实现角度看，首先面临的挑战是如何选择合适的载体。例如，如何在特定平台如字节豆包上实现这种交互式卡片的支持？是采取定制化方案，直接与豆包合作，还是开放接口，借鉴 Google 的 Gemini 模型与一款 IDE 产品 Replit 之间的集成模式？当前，Gemini 和 Replit 的交互方式还比较“挫”，仅在 Gemini 提问后，通过底部的分享按钮跳转至 Replit，而非无缝集成。我预计 Replit 将在不久的将来会推出类似 Artifact 的强大功能，这将进一步推动行业标准。
所以，最终问题还是在于如何实现与用户的交互。我认为这种交互方式与 Vercel 的 V0 相似，这款产品的解决方案是通过对话生成 UI 界面，并允许用户导出代码。
定制化场景
我们还探索了一些定制化的轻量场景，旨在为用户提供更贴合需求的开发体验。譬如对于 AI 领域常见的 Workflow 搭建场景，往往需要支持嵌入式的代码节点，与传统的 IDE 相比，它只需要一些基础的功能，如代码编辑区、自动补全提示，以及 AI Inline Chat 能力，甚至无需 Side Chat 功能。
对于 AI 而言，代码片段是核心，用户编写完成后，我们应能迅速运行这段代码，这要求 IDE 具备一定的扩展能力，如 Input / Output Schema（输入/输出模式）的构建，以实现整体工作流的无缝集成。此外，考虑到代码测试的需求，我们还探讨了如何在此基础上进一步提升测试效率。
其次，还有一些更复杂一些的云函数场景，譬如 ChatGPT 的 GPTs 插件，会需要更丰富的功能集，包括代码片段的编辑、控制台（Console）面板、包依赖管理以及 API 接口数据管理。对于这个场景来说，Function Call 需要告诉 AI 函数的输入输出字段及其类型，从而有助于 AI 可以正确地调用云函数和处理后续结果。以往，开发者在编写函数后还需手动编写 OpenAPI 的 Schema，过程非常繁琐，而我们就针对这个痛点实现了自动化分析代码并生成 Schema，还支持了自动化生产测试，从而简化开发流程，提升效率。
“开箱即用”的云端开发环境
所谓“开箱即用”的云端开发环境，其实就是指云端 IDE 中的“工作区”。工作区之所以必要，是因为它提供了高度的隔离性和环境一致性，这对于开发人员而言至关重要。尽管 WebContainer 作为一种方案存在，但其局限性明显，仅适用于 Node.js、Python 等可编译为 WebAssembly 的语言，且性能表现欠佳。相比之下，工作区的优越性在于其强大的隔离能力和一致性环境，但这也带来了较高的技术复杂度和实施门槛。
在实现工作区时，K8s（Kubernetes）作为容器调度的主流技术，被普遍采用。然而，K8s 的核心优势在于其能够在短时间内调度大量资源，以应对突发流量，但 IDE 工作区的需求截然不同。IDE 工作区通常是一对一的关系，无需多实例负载均衡，更侧重于快速启动。与微服务架构下的弹性伸缩不同，IDE 的用户体验要求极高，任何延迟都可能导致用户流失。因此，IDE 工作区本质上是一种实时、有状态的服务，而 K8s 则更多应用于无状态、非实时的场景。
为解决这一问题，我们基于 K8s 进行了一系列定制化改造。首先，容器调度成为优化重点，直接采用 K8s 原生功能难以满足高性能需求，因此，针对性的优化措施不可或缺。其次，工作区的休眠机制变得尤为关键，持续运行将导致高昂成本，因此合理的休眠策略必不可少，以在保障快速启动的同时，控制资源消耗。在存储层面，热挂载磁盘而非每次启动时重新挂载，对于缩短启动时间、提升用户体验至关重要。流量调度同样不容忽视，尤其是在轻量化场景下，探索单个容器内多级调度的可行性，仅运行一个 LSP Server 和少量 AI 微服务，实现资源的高效利用，成为优化工作区性能的关键策略之一。
云端成本
在谈及云端测试成本时，我们不得不面对的是高昂的开支。从云成本角度来看，大致可分为两类：间接成本与闲置成本。
间接成本，主要涉及人力成本，这部分难以削减。即便借助某些云服务能够部分抵消，但鉴于我们的场景独特，需要深度参与并与云服务商紧密合作，以优化性能。在我们最近的国内产品发布中，就遇到了不少问题，原因在于不同角色的视角和关注场景不同。为了解决这些问题，我们需深入理解技术细节，与服务商共同协作。
闲置成本，则源于 IDE 场景下难以利用弹性伸缩特性。由于 IDE 使用模式与之不符，我们需自行通过 K8s 进行管理，确保集群的自动扩展，避免资源闲置。这涉及到集群调度的优化，如减少碎片化，尽可能将任务调度在同一台机器上，以释放多余的计算资源。此外，负载均衡与计费策略也是后端工程师熟悉的话题。
集成云服务
在 IDE 领域，我们还面临着另一项挑战：如何更好地集成云服务。例如，前端开发者常遇到的问题是，如何将编写的 Node.js 代码快速部署。为此，我们开发了部署管理功能（目前刚在海外版上线）。这一功能旨在实现从开发到部署的一站式服务，只需点击发布按钮，即可立即使用，对程序员而言，这无疑是一大福音。
又譬如，在 OpenAI 推出 GPTs 时，需要开发一个云函数 + 编写繁琐的 OpenAPI Schema 定义 + 发布部署，我们就思考能否简化这个流程，于是我们提供了云函数的编写、测试、自动生成 Schema、测试、部署等一系列的能力 ，帮助开发者极大的提高了这类垂直场景的效率和幸福感。
MarsCode = ( Cloud + IDE ) ᴬᴵ
面对国内外众多 IDE 的竞争，豆包MarsCode如何脱颖而出？事实上，我认为国外市场确实较为活跃，但国内市场目前仍主要以插件为主，没有将重心放在云端 IDE 或是消费级市场上。
我们采取了双轨策略，一方面推出了豆包MarsCode代码编程助手，这一产品与国内的许多产品类似，主要以插件形式在 JetBrains 或 VSCode 中运行；另一方面，我们推出了豆包MarsCode IDE，一款云端 IDE。
用户对 AI 插件的接受度较高，但资深程序员往往已有成熟的本地开发习惯，单纯提供 IDE 难以满足其所有需求。因此，我们首先通过插件方式切入市场，逐步吸引用户。同时，考虑到程序员在不同场景下的需求，如跨设备开发、出差携带 iPad 等，而且插件其实是非常受限的，很多体验都没法做到最优，譬如 AI Chat 的许多上下文都无法同步。我们相信随着时间推移，用户将自然而然地转向我们的云端 IDE，特别是在初学者和补充场景中。
AI 驱动编程
展望未来，我期待当前 AI 辅助编程的阶段能够迅速演进至 AI 驱动编程的时代。尽管这个转变可能还需数年时间，但我们已经能够看到一些迹象，例如 Devin 和 Copilot Workspace 的出现。以下分享一些我的观察结果，谈谈未来 AI 编程可能的发展形式：
未来的交互方案
我有幸参与过 Copilot Workspace 早期内测，当时感到极为兴奋。通常，我们通过 Side Chat 与 AI 进行对话，发送消息后，AI 会处理信息并提供答案。我在上文曾将 AI 比喻为一名“高潜实习生”，然而体验了 Workspace 之后，我发现 AI 在过去一年内已显著成长，相当于一名合格的新入职员工。以前，分配给 AI 实习生的任务可能在一周后才得到回应，而且结果常常不能令人满意。相比之下，Workspace 提供的交互方式则完全不同：当你向 AI 实习生分配任务时，他在当天下午就能提供一个思维导图，详细说明他对任务的理解、规划的步骤和他的计划，并请求你进行确认。这种方式通过透明的上下文交流和互动，实现了高效的对话和校正，展现了一种更高级的交互形态。
AI 时代的程序员，怎么进行代码验收？
AI 生成了代码之后，还需要人为进行检查。在代码验收方面，我想分享一个有趣的话题：某天，我们发现在某些轻量化的场景中 AI Inline Chat 的反馈率异常之高，跟我们以往的经验数据不太符合。经过深入分析，我们推测这一现象的背后原因可能与用户群体有关。轻量化场景更多是面向那些缺乏开发经验的用户，他们可能对代码编写并不熟悉，只是出于好奇心前来尝试。在这种背景下，用户对待代码生成的态度是“无妨一试”，尤其是对于代码补全和生成的场景，他们更倾向于低成本的尝试。
这一发现反向验证了一个重要的心理现象：用户的心态可能是，既然代码的“生成成本”和“验证成本”如此之低，为何不先生成一段代码，然后通过旁边的测试按钮快速验证其正确性。若结果不尽如人意，用户可以再次尝试生成，直到满意为止。这种心理驱动下，用户更愿意接受代码生成，甚至在遇到问题时主动寻求解决方案，从而推高了这个场景下的反馈率，展示了代码生成与即时验证结合的潜力。
在代码生成的初期，我们尽量减少对代码的干扰，让生成过程更加克制，以降低验证成本。在代码旁，我们提供了 API 测试功能，特别是对于函数的输入/输出参数，AI 能够自动生成，用户可以轻松进行调整，即时查看结果，从而实现代码的有效验证。
这一设计灵感源自对初级开发者行为的观察。我们发现，许多初级开发者并未编写单元测试，而是通过直接在网页上输入输出数据来检验代码。基于这一观察，我们致力于提供简单易用的测试能力，以减轻开发者的负担，降低验证成本。
在豆包MarsCode的发布会上，我们跟 MoonBit 团队负责人张宏波老师也有过沟通，他们面向 AI 的新语言 MoonBit 也在代码验证这块有不少思考和实践。因此，当前各方都在积极探索新的方法，以期实现更加高效、智能的代码测试与验证流程。
我理想中的 IDE
在我看来，IDE 不会受限于特定领域，而是走向大一统。从大语言模型本身的发展就能看出，其一体化的趋势日益明显。我们基于豆包代码大模型的实践，展示了模型在不同领域应用的潜力。我认为，模型的通用性将决定上层应用的灵活性，尤其是在代码补全与生成方面，我们追求模型的全面理解能力，尽管在现阶段，专项能力仍有其价值。
在具体的实践方案中，多智能体协同工作是我认同的理念，它与AI辅助编程至AI驱动编程的演进路径相契合。在编程过程中，设想有多个智能体陪伴左右，分别承担代码重构、单元测试等职责。然而，关键在于是否有必要将功能拆分得如此细化，这取决于产品的形态。底层大模型与上层智能体的人设并不冲突，二者可以共存，共同服务于编程任务。
一个有趣的案例是我们看到有一些 AI 的实验，提供了一个模拟的小镇，让不同的智能体进行狼人杀，展现了多智能体在非编程领域的应用潜力。
当前 IDE 面临的挑战在于其“太 IDE 了”，即过于专注于传统的编码环境，未能充分适应现代开发者的多元化需求。在过去的项目经验中，我参与了前端工程化的研发工作台建设，我们追求的是一站式解决方案，旨在覆盖从代码编写到部署的全过程。豆包MarsCode正是秉持这一理念，力求为开发者提供全方位的支持，譬如我们提供的前后端部署功能就是基于这个理念的一个体现。
然而，现有的 IDE 形态是否已触及天花板？我对此持保留态度。在 AI 领域，我们正处于探索的早期阶段，距离产品形态的成熟还有很长的路要走。我们甚至在讨论中提出了疑问，IDE 的核心编辑区是否必须占据中心位置？是否未来的编程是我们和 AI 的交互，而代码也许只是一个产物，那编辑区是不是可以放到右边区域不占据屏幕的中心呢？这些思考表明，我们对 IDE 的未来形态持开放态度，愿意尝试新的设计思路，以满足不断变化的开发需求。
最后，我认为 AI 与人类的关系不是竞争而是合作。我们的目标是提升开发者的效率，使他们能够成为超级程序员，将更多时间和精力投入到思考和创新上。我们不认同 AI 会导致程序员失业的观点；相反，我们认为 AI 的作用在于协助我们提高工作效率，使我们更加享受编程的过程。我坚信 AI 的发展不应该剥夺编程的乐趣。
作者 | 天猪
编辑 | 《新程序员》王启隆
点击链接，即刻体验豆包MarsCode ：https://sourl.cn/i8aDcN
