演讲嘉宾｜向邦宇
编辑｜Kitty
策划｜QCon 全球软件开发大会
AI 发展过程中诞生了许多优秀的 Coding 产品，但非专业开发者需要掌握一些简单的研发知识才能完成研发任务，而这些工具和研发知识的匮乏，都在不同程度上影响非专业开发者的热情。
本文整理自阿里巴巴高级技术专家向邦宇在 2025 QCon 全球软件开发大会（上海站）的分享 “Vibe Coding 在代码生成与协作中的实践与思考”。主要探讨如何构建下一代 Vibe Coding 工具，从阿里当前的挑战出发，提出以用户为中心、强化工具质量、深化场景适配、支持协作与包容不确定性的核心设计原则与实践。
内容亮点
Vibe Coding 工具在建设过程中遇到的问题，以及解决的办法
构建 Vibe Coding 工具所趟过的产品方面的坑
构建 Vibe Coding 工具时的技术创新与落地实践
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
多年来，我一直在阿里巴巴内部的技术研发设施平台上从事研发者工具的工作，其中包括内部的 AI 编程工具以及 Web IDE 工具等。从 2023 年开始，我参与了相关工作的转型，从之前的内部 Copilot 逐步转向如今的 Agent 方向。
当我拿到这次演讲选题时，我在思考 Vibe Coding 这一主题。虽然 Vibe Coding 已经出现几个月了，但它似乎还不是一个非常确定性的概念，因为大家对它的理解以及所使用的相关工具都存在差异。而我由于接触了大量内部用户对这些工具的使用情况，包括他们在使用过程中遇到的问题，以及作为产品提供方，面对众多用户在使用工具时所遇到的问题，我需要思考如何解决这些问题。
首先，我会简单介绍一下我们内部在哪些行业以及具体使用了哪些 Vibe Coding 工具。接着，我会讲述用户在使用 Web 编程工具过程中遇到的一些问题。然后，作为 Vibe Coding 工具的两位核心主导者之一，我会分享我是如何思考这些问题的。最后，我在之前的许多分享中已经介绍过我们如何使用国产模型以及在适配国产模型过程中遇到的问题。
Vibe Coding 产品形态
目前，Vibe Coding 工具大致可以分为四类。首先是 Native IDE，例如近年来较为流行的 Cursor、Trae，以及我们阿里巴巴的 QCoder 等，它们都以本地集成开发环境的形式存在。第二类是 IDE 插件，比如我们内部的 Aone Copilot 等工具，这些插件大多是基于现有的开发环境，如 VSCode 或 JetBrains 的插件形式存在。目前来看，内部用户使用这类插件仍是一种比较主流的习惯，尽管其灵活性可能不如 Native IDE 那么高。第三类是 Web Agent，它的入口在浏览器上，整个执行过程在一个异步容器中进行，可能是沙箱环境。它可以解决信任问题以及云端执行中的安全问题，并且对于协作更加友好，能够在 Web Agent 中实现多人同步协作和分享。这类主要是跨平台工具，具有广泛的适用性。最后一类是 CLI 命令行工具，这其实是一个比较意外的类别。我们之前并没有预料到像 Claude Code 这样的 CLI 工具会如此受欢迎。最初，我们认为这种工具不会受到主流研发人员的欢迎，但后来发现大家其实非常接受这种模式。现在我们认为，CLI 模式在被集成的方式中，比如 CI 或一些异步容器中执行垂直任务时，具有更高的可用性。这就是我对 Vibe Coding 工具大致分类的介绍。
Vibe Coding 在阿里内部的发展现状
接下来，我主要介绍一下我主导的两个 Vibe Coding 工具的使用情况。首先是基于 IDE 的 Vibe Coding 工具。我们内部有一个名为 Aone Copilot 的工具，它已经存在多年，拥有众多用户，每周大约有数千的活跃用户。目前，用户在使用 IDE 的 Vibe Agent 工具时，主要场景包括新增代码、修复漏洞以及代码分析等。在后端场景中，这种工具的渗透率相对较高，而在前端场景中，大家可能更倾向于使用 Native IDE，如 Cursor 或 QCoder。
另一个我主导的项目是 Aone Agent。这是一个以外部容器发起的异步任务工具。它强调用户可以通过自然语言发起任务，我们在异步容器中启动一个 Agent，这个 Agent 会自行调用各种工具，无论是搜索工具、文件读取工具还是 Shell 工具。这种在容器内执行的异步 Agent 与前面提到的 IDE Agent 有本质区别。虽然用户主要是后端人员，但我们发现测试人员、前端人员、算法工程师、产品经理、运营人员、设计师以及运维人员等都在使用这种工具。它的用户群体更加多元，提交的任务类型也更加丰富多样，包括代码分析、代码修改、单元测试、代码生成以及文案方案调研等，用户通过这种工具进行各种探索。
在 Vibe Coding，尤其是 Agent 模式发展之后，我们看到了一些显著的变化。以 Aone Copilot 的 Agent 模式为例，从 4 月份开始，我们观察到用户提交代码行数的变化。蓝色的线表示高频用户，即那些经常使用该工具的用户。我们发现，在 Agent 模式下，这些高频用户的代码提交行数有了显著提升。虽然整体趋势都在上升，但高频用户的提升更为明显。从定量角度来看，9 月份高频用户每天提交的代码行数约为 560 行，而其他用户只有 400 多行。这至少证明了 Agent 模式在提高效率方面是有效的。
我们还发现，不同用户对这些工具的使用方式有所不同。前 10% 的用户提交的代码行数是其他用户的两倍。但我认为，Agent 对人的效率提升可能不止两倍，因为大量的工作可能涉及协作或会议等。我们还发现，TOP 10 用户的 Token 消耗占总消耗的 80%。在 Vibe Coding 工具的使用下，由 AI 生成的代码提交占比越来越高。随着 Vibe Coding 工具的发展，像 JDK 升级、NPM 包升级或 SDK 升级等任务已经可以由 AI 完成，尤其是 JDK 11 及以上版本的升级场景，我们内部几乎全部交由 Vibe Coding 工具来完成。此外，数据分析和数据整理工作也部分交给了 Agent。过去，一些必须由人工完成的任务，如大促过程中的截图或压力测试中的重复任务，现在都可以由 Agent 完成。还有一些在研发过程中成本过高而无法进行的事情，比如一次发布是否会引发其他相关系统的故障，现在也在探索使用 Agent 来解决。过去，由于无法审查每一行代码对其他系统的影响，这类问题很难处理，但如今 Agent 可以承担这项任务。
用户在 Vibe Coding 过程中遇到的挑战
在审视当前技术发展现状时，从用户的角度来看，技术和产品都面临着一些亟待解决的问题。首先，用户常常因为 AI 的表现不尽如人意而感到沮丧。从后台日志中，我们可以看到大量用户抱怨“电脑太笨了”等类似的不满情绪，这些反馈充满了挫败感。同时，用户频繁地删除和修改代码的现象也屡见不鲜。无论是公司内部还是在社区中，都存在许多用户因 Agent 能力不足而陷入困境的情况。此前，甚至有用户在 GitHub 上分享关于 AI 的“八荣八耻”提示词，其中不乏诸如“以不修改原始代码为荣”等观点。
综合来看，Vibe Coding 工具给用户带来的问题主要体现在以下几个方面。首先是代码质量问题，生成的代码往往缺乏质量把控。其次是调试和维护困难，这给用户带来了额外的负担。第三是用户体验不佳，目前的 AI 编程工具尚未达到让用户满意的程度。最后是成本与效率问题，这些问题也在一定程度上影响了工具的使用效果。
我认为代码质量不足主要体现在几个方面。首先是代码一致性不足。在不同场景下，生成代码的质量和风格存在较大差异。例如，在存量代码仓库中编写代码时，AI 往往会按照自己的风格生成代码，这与现有代码风格不一致。其次，边界条件的处理不够完善。对于复杂业务逻辑的边界情况，AI 生成的代码往往处理得不够充分。此外，生成的代码还存在性能缺失的问题。最后，安全漏洞问题尤为突出，尤其是 SQL 注入类漏洞。斯坦福大学的一项研究指出，AI 生成的代码中存在注入类漏洞的比例约为 45%。
在实际应用中，我们发现了一些典型案例。首先是安全漏洞，包括 SQL 注入和 XSS 攻击。其次是在边界逻辑处理方面，逻辑错误和边界条件处理不当的情况较为常见，例如空指针异常和数组越界等问题，这些都是我们在用户使用过程中观察到的现象。
我们发现 AI 在代码生成过程中存在自洽问题。过去，我们曾考虑让 AI 生成代码的同时，也生成对应的单元测试，以此来解决代码质量问题。然而，我们很快发现，如果让 AI 同时负责代码逻辑和单元测试的生成，它无法保证质量，因为 AI 会在逻辑上进行自洽。例如，下图展示的一段数组去重函数及其对应的测试代码，虽然测试通过率达到了 100%，但其逻辑实际上是存在问题的。这说明，如果完全依赖 AI 来完成代码和测试，很容易出现自我拟合的情况。因此，我们建议用户在使用 AI 生成代码时，至少有一项由人工进行 Review 或主导，以确保质量
在用户使用 Vibe Coding 工具的过程中，我们还发现调试时间增加了 30% 到 50%。这是因为 Vibe Coding 更倾向于生成黑盒代码逻辑，尽管最终会让人确认代码的差异（DIFF）后才能提交，但生成过程和代码本身通常不会被逐条仔细检查。因此，我们将其视为一种黑盒操作，AI 生成代码就像一种“黑魔法”，一旦出现问题，用户可能不知道从何处入手，技术债务也会不断累积。
另一个问题是上下文理解的局限性。对于存量任务，其业务逻辑往往是经过多年积累形成的，一些代码为何如此编写，是否可以删除等问题，对于 Agent 来说都是难题。我们认为，Vibe Coding 工具缺乏全局思维，生成的代码模块化程度不足，代码耦合度较高。为了解决这一问题，目前有一些方案，例如 Repo Wiki 或 Deep Wiki 等。
此外，Vibe Coding 缺乏可追溯性，这限制了工具的使用。由于 Vibe Coding 一次性生成大量代码，我们很难确定是新的需求导致代码出错，还是最初生成时就存在错误。因此，如何引入版本管理的概念，以便在代码出错后能够回滚到正确状态，是一个亟待解决的问题。目前有一些方法，例如在每次修改并通过测试后提交一个 Commit，以便后续能够从该 Commit 回滚。也有一些工具，如 Cursor 或其他回滚工具，但总体而言，Vibe Coding 在可追溯性方面仍有不足。用户在生成大量代码或经过多次迭代后，往往无法进行有效的版本管理，只能选择回滚或重新开始。
目前 Vibe Coding 工具还无法像人类开发者那样熟练运用常见的调试工具。在过去传统的编程模式中，开发者们常常会大量使用调试工具，例如在代码中设置断点，或者在浏览器中进行调试。然而，对于 Vibe Coding 工具来说，要利用这些调试工具来定位问题的堆栈信息，几乎是不可能完成的任务。那么，Vibe Coding 工具是如何应对这种情况的呢？它们通常会通过大量打印日志（如 console log）来解决问题。它们要求用户在执行代码后，将控制台中的报错信息或打印内容复制并粘贴给工具，以便进一步分析。这种模式不仅需要人工介入，而且效率低下。因此，我认为大型模型的调试手段相对单一，传统的调试方法很难被这些模型有效利用。
从用户使用 Vibe Coding 工具的角度来看，除了编码层面的问题外，工具本身也存在诸多不足。首先，稳定性和成功率是最大的问题之一。Vibe Coding 工具的执行时间往往较长，用户可能需要等待 30 秒到 5 分钟才能得到结果，而且并非每次都能成功。失败的原因可能是模型返回错误、工具调用出错，或者 IDE 本身不稳定等。一些用户在初次使用后，发现结果不稳定，尤其是在时间紧迫、任务繁重的情况下，他们就不再愿意使用这类工具。
其次，交互界面设计也存在一些问题。这并非缺陷，而是因为许多 Vibe Coding 工具频繁改版，导致用户难以找到以前的功能，或者工具中不断增加新功能，使得用户感到困惑。以 Devin 为例，它在改版过程中，曾经引入了剧本、MCP 市场和知识库等功能，但后来又取消了。这种频繁的改版让用户难以适应。
第三，沟通和交互存在障碍，主要表现为 AI 的理解能力不足。用户需要反复确认意图，尤其是在不同场景下，这种确认虽然有意义，但也增加了沟通成本。例如，在最近流行的 Spark Coding 中，用户先提出需求，生成设计稿，再让 Agent 执行。对于复杂的任务，这种模式可能是必要的，但对于其他任务，可能需要 Agent 自由探索。此外，长链路任务的执行能力也存在不足，无法维持长期的上下文对话。由于 Agent 大模型的 Token 有上限，当上下文过长时，其记忆和召回能力就会下降。
最后，工程工作流程的中断也是一个问题。目前有大量 Vibe Coding 工具，包括 IDE、CLI 和 Web Agent 等，每种工具都有其擅长的领域，但它们无法让用户在一个统一的流程或上下文中解决问题。例如，用户在 IDE 中完成一项任务后，如果切换到 CLI，就需要重新向新的 Agent 介绍需求。这种频繁切换不仅增加了用户的负担，也降低了工作效率。
Vibe Coding 产品自身遇到的挑战
随着 Agent 和模型能力的不断提升，产品功能也在不断演进。从最初的单代码补全场景，单个任务 4000 个 Token，到后来的 Chat 模式，单个任务 1000 个 Token，输出约为 4000 个 Token。再到 IDE 或 CLI 模式，Token 消耗量达到十万级别。如今，Web Agent 模式具备独立容器，能够广泛使用各种工具，实现多种任务类型的 Agent 模式，Token 消耗量更是达到百万级别。像 Cursor、Trae 等 Native IDE 工具正在探索 Sub-Agent 或 Multi-Agent 架构，单个任务的 Token 消耗量甚至可能达到上亿级别。这种演进模式虽然为用户提供了更强大的功能，但也给产品设计带来了挑战。一方面，我们需要让用户满意，另一方面，成本控制必须与用户规模相匹配。
在产品设计方面，Vibe Coding 工具，无论是 IDE Agent 还是 Web Agent，都处于摸索阶段。尽管模型能力的提升推动了产品功能的不断变化，但产品界面的区分度却不够。例如，Chat、Deep Research、Agent 等产品都采用对话框形式，用户难以区分不同产品的功能差异。此外，用户缺乏引导，面对 Vibe Coding 的对话框，用户往往不知道该输入什么内容。不同工具适用于不同场景，但用户常常一刀切地认为某个产品应该满足他们的需求，然而在实际使用中，他们发现产品无法达到预期目标。这不仅增加了用户的学习成本，也降低了产品的使用频次。我们观察到，像 Devin 这样的 Web Agent 工具，留存率非常低，这反映出用户在使用过程中遇到的诸多问题。另一个问题是缺乏一站式的功能闭环。用户面临的不仅仅是代码编写问题，还包括发布、部署、调试等多方面的问题。目前的 Vibe Coding 工具无法在一个产品中同时解决不同难度问题。比如，初学者可能需要更多指导和简化功能，而复杂问题则需要更强大的工具支持。这种功能上的割裂导致用户在使用过程中需要频繁切换工具，增加了使用成本和学习难度。
Vibe Coding 工具的安全性问题值得我们高度关注。可能大家有所耳闻，例如 Cursor 曾出现过删除用户本地代码的情况，虽然这类事件相对较少，但今年已经发生了好几次。另一个案例是 Anthropic 的 Claude Code 被劫持，攻击者利用 Vibe Coding 工具在用户网络中探测漏洞，并编写代码将敏感信息暴露出来。
在内网环境中，我们可能还无法完全信任 Vibe Coding 工具。当前，供应链攻击和开源代码的发展带来了新的挑战。许多人会在开源社区中潜入木马，一旦我们稍不留意，拉取的 SDK 或代码可能本身就存在漏洞。Vibe Coding 工具由于对代码或当前电脑具有一定的控制能力，能够进行自由探索，可能会发现系统中的漏洞并加以利用。因此，我们在使用 Vibe Coding 工具时，必须谨慎对待其安全性问题，确保在安全的环境中使用，并对工具的权限进行严格管理。
Agent 建设过程中的一些经验
在参与 Agent 建设的过程中，我积累了一些经验，这些经验对我们后续的工作有着重要的启示。
最初，我们采用了一种 All In One 架构，这种架构在建设 Vibe Agent 时带来了诸多问题。当时，Vibe Agent 的核心是一个输入框，围绕这个输入框的是 MCP 工具、知识库（Knowledge）以及各种剧本（Playbook）。这些外围工具构成了一个完整的场景图，涵盖了数据处理、后端开发、前端开发、代码审查、风险管理等多个方面。在这种架构下，所有工具和知识都需要放入上下文中，导致上下文内容异常庞大，成本难以压缩。例如，当时我们使用 Claude 模型执行一个任务，成本高达几百元，这显然是不可持续的。
此外，这种 All In One 架构还导致任务成功率较低。当所有工具和知识集中在一起时，上下文过长，消耗大量 Token，不仅增加了成本，还降低了任务执行的效率。更重要的是，这种架构难以针对不同场景进行优化。例如，当我们对比其他类似产品时，我们的 Vibe Agent 在前端场景上的表现却不尽如人意。这说明，我们的架构缺乏灵活性，无法根据不同场景进行针对性的调整和优化。
在后续的 Agent 建设过程中，我们采取了一系列措施来优化工具的性能和用户体验。首先，我们对知识和数据进行了调整，特别是在代码数据建设方面，通过构建 Repo Wiki 和 Embedding 数据库，提升了对整体代码库的搜索理解和搜索能力。此外，我们还将研发行为数据纳入考量，包括构建 CI、CR、发布监控等行为。由于我们依托的是集团内部的发布平台和代码平台，因此能够将代码数据与需求数据相结合，形成一个综合的数据体系。
我们意识到，传统的文档知识库难以直接被 Agent 使用，原因在于这些知识库可能存在信息过时、前后矛盾、图文混杂以及错误信息等问题。这些问题如果直接传递给 Agent，可能会导致误导。因此，我们没有采用传统的 RAG 技术，而是通过建立一个中间层来处理面向 Agent 的数据协议，从而解决文档知识库的引入问题。
在 Agent 的建设过程中，我们还发现很多知识并不在文档或代码中，而是存在于开发者的头脑中。因此，我们思考如何设计一个产品，帮助用户将这些知识沉淀下来。这并非通过自动生成实现，而是需要用户主动参与编写。
在上下文记忆方面，我们进行了大量处理工作，包括写入、提取、压缩和隔离等操作。我们的 Agent 工具旨在满足大多数用户的需求。为此，我们在容器中集成了大量工具，涵盖任务管理、基本交互、文件操作（读写、编辑、管理）、命令行执行监控等功能。由于 Agent 可以执行命令行，对于一些耗时较长的命令，我们需要监听其执行结果，并在超时后进行中断处理。
我们还加入了浏览器自动化工具，例如使用 Playwright 等工具进行网页操作，帮助用户完成登录等交互任务。同时，我们还集成了多媒体开发工具，支持用户将代码部署到特定环境进行调试。在协作方面，我们设计了团队协作功能，用户可以将任务分享给他人，基于任务继续协作。我们还加入了高级功能，如并行执行优化和网络搜索等
在面对模板和成本过高的问题时，我们采取了一系列措施来优化和解决。最初，我们发现单个任务的 Token 消耗量接近 400 万到 1000 万，这是一个极为严重的问题。为了降低 Token 成本，我们进行了一些操作和设计调整。
积极适配和拥抱国产开源模型
在探讨为何要解决成本问题时，我相信从事相关工作的人都能理解其重要性。实际上，解决成本问题的另一个重要方向是积极拥抱国产开源模型。然而，国产开源模型并非针对我们的具体场景进行训练，因此仍存在诸多问题。
使用国外的 SOTA 闭源模型也存在诸多风险。首先，这类模型非常昂贵，尤其是处理复杂问题时，需要在长链路任务中运行，成本极高。其次，隐私问题不容忽视，闭源模型可能存在合规风险。第三，我们还发现了被限流和性能下降的问题，即使是同一模型、同一供应商，在不同时间的表现也可能不同，有时会出现格式错误或陷入死循环等问题。最后，国外模型在面向 C 端用户时，可能还存在备案等额外问题。
相比之下，国产模型在短链任务中表现良好，但在长链任务中仍存在一些问题。例如，死循环问题较为常见，因为 Agent 有多种选择和入口，可能在执行过程中陷入某种循环，无法跳出。另一个问题是格式遵循能力不足，例如 XML 标签格式不准确，前后无法匹配，导致无法正确解析，容易失败。此外，还存在指令遵循问题，在处理大量 Token 的上下文时，模型可能忘记某些指令，尤其是在未被充分训练的情况下。最后，我们还发现全局智能方面存在缺陷，模型容易陷入“走一步看一步”的情况，导致 Token 消耗大，步骤时间长。
为了应对这些问题，我们采取了一系列措施。首先，针对稳定性问题，我们设计了主备模型切换和重试机制。其次，为了解决速度慢或 Infra 稳定性问题，当模型输出被截断时，我们引入了流式输出和续写设计。此外，我们还进行了健康检查和死循环检测，在 Agent 中针对重复执行指令或相同错误点的无限循环问题进行了优化。当检测到明显错误逻辑时，我们能够及时干预。同时，我们还进行了格式检查和修复，针对模型生成的 XML 标签格式错误，通过堆栈或自动补齐方式解决格式缺失问题。
目前，我们已经将所有国外模型替换为国产模型。在运行过程中，我们会实时检测任务是否进入死循环，一旦发现，会采取干预措施，例如截断后续任务执行，或对任务进行总结和压缩，使其能够继续执行。这些措施都是我们在上下文管理方面的探索和实践。
在思考如何提升产品用户体验和降低使用成本时，我发现了一个核心问题：普通用户甚至小白用户在使用我们的产品时，往往不清楚产品能做什么。即便他们知道自己需要什么，也难以准确地提出需求，不知道如何在产品中选择合适的工具或知识。这导致产品的任务成功率很低，同时 Token 消耗量却很大。
为了解决这些问题，我考虑是否可以将一些已经成功完成的垂直任务进行抽象和模板化。例如，如果某个任务经过多次探索后成功完成且用户非常满意，我们能否将其经验抽象出来，形成一套标准化的模板？通过这种方式，我们可以针对不同的垂直场景不断积累模板，从而提高任务的成功率，降低 Token 消耗。当用户面对对话框时，模板也能提供一定的引导性，帮助他们更好地使用产品。
在模板设计方面，这些模板可以被理解为工具组合和知识组合的集合。有了模板后，用户在使用对话框时可以先选择一个模板，这大大提高了任务的完成率。目前，大约有 50% 的用户任务都使用了模板，任务完成率提高到了 95% 以上。通过固化 Prompt、工具和知识，形成模板后，用户在下次生成或执行任务时可以先选择模板，再进行具体操作。
Manus 1.5 提出了一个新概念：Agent 也是一种工具。这意味着我们可以将 Agent 视为一个工具，例如一个专门用于深度调研的工具，它可以独立完成网页搜索和内容总结。这样，主 Agent 只需要调用这个工具即可，从而将部分任务抽象化，形成一个工具。从最初的“函数即工具”，到“LLM 即工具”，再到现在的“Agent 即工具”，我们将所有任务都视为子任务，通过工具化的方式进行处理。
以上内容是我关于产品和用户体验方面的分享。实际上，我们的工作不仅局限于内部，也已经向外部用户开放使用。未来，我们还将进一步把内部的技术成果开放给社区，以促进更广泛的交流与合作。
演讲嘉宾介绍
向邦宇，阿里巴巴代码平台负责人，在代码管理、代码结构化数据处理、代码搜索、代码评审以及编辑器技术等领域拥有丰富的专业知识和实践经验。在阿里，负责了包括 CloudIDE、代码搜索、CodeReview 等多个关键产品的开发与管理，成功引领了代码智能平台的建设与发展。他主导实现的阿里内部多个 AI Coding 工具，包括 Aone Copilot 和 Aone Agent 等，在阿里内部被广泛使用。他还主导开发了 AI Development 产品“搭叩”。
会议推荐
2026，AI 正在以更工程化的方式深度融入软件生产，Agentic AI 的探索也将从局部试点迈向体系化工程建设！
QCon 北京 2026 已正式启动，本届大会以“Agentic AI 时代的软件工程重塑”为核心主线，推动技术探索从「AI For What」真正落地到可持续的「Value From AI」。从前沿技术雷达、架构设计与数据底座、效能与成本、产品与交互、可信落地、研发组织进化六大维度，系统性展开深度探索。QCon 北京 2026，邀你一起，站在拐点之上。
热门跟贴