Vibe Coding工具实践：阿里内部遇到的代码质量、成本与调试挑战及解决方案

AI 的发展催生了众多优秀的编程工具，但对于非专业开发者而言，掌握必要的研发知识和工具仍然是门槛，这在某种程度上影响了他们的使用热情。

近年来，我一直在阿里巴巴内部的技术研发设施平台上从事开发者工具相关工作，包括内部的 AI 编程工具以及 Web IDE 等。从 2023 年开始，我的工作重心从内部的 Copilot 逐步转向了如今的 Agent 方向。

当接到关于“Vibe Coding”的分享选题时，我思考了很久。虽然这个概念已经出现数月，但业界对它的理解以及所使用的工具仍存在差异。由于接触了大量内部用户的使用反馈和问题，作为产品提供方，我一直在思考如何解决这些挑战。

接下来，我会先介绍我们内部使用的 Vibe Coding 工具形态，然后分析用户遇到的核心问题，最后分享我们作为建设者的一些思考与实践经验。

Vibe Coding 产品形态

目前的 Vibe Coding 工具大致可以分为四类：

1. Native IDE：例如近年流行的 Cursor、Trae，以及阿里的 QCoder 等，以本地集成开发环境形式存在。
2. IDE 插件：例如内部的 Aone Copilot 等，基于 VSCode 或 JetBrains 等现有开发环境。这仍是内部用户的主流选择，尽管灵活性可能不如 Native IDE。
3. Web Agent：入口在浏览器，整个执行过程在一个异步容器（可能是沙箱）中进行。它有助于解决信任和安全问题，对协作更加友好，天然支持多人同步和分享，且具有跨平台优势。
4. CLI 命令行工具：这是一个有些意外的类别。像 Claude Code 这样的 CLI 工具受欢迎程度超出预期。我们认为，CLI 模式在集成到 CI 或执行垂直异步任务时，具有很高的可用性。

Vibe Coding 在阿里内部的发展现状

我主要参与主导了两个 Vibe Coding 工具的建设。

第一个是基于 IDE 的 Aone Copilot，它已存在多年，拥有大量用户，每周有数千活跃用户。用户主要用它进行新增代码、修复漏洞和代码分析等。在后端场景渗透率较高，而前端用户可能更偏爱 Cursor 或 QCoder 这类 Native IDE。

第二个是 Aone Agent。这是一个从外部容器发起的异步任务工具。用户通过自然语言发起任务，我们在异步容器中启动一个 Agent，由它自行调用搜索、文件读写、Shell 等各种工具。这与 IDE Agent 有本质区别。

虽然用户以后端为主，但我们发现测试、前端、算法、产品、运营、设计甚至运维人员都在使用。用户群体更加多元，提交的任务类型也异常丰富，包括代码分析、修改、单元测试生成、文案方案调研等，更像是一种探索工具。

Vibe Coding，尤其是 Agent 模式发展后，带来了一些显著变化。以 Aone Copilot 为例，自 4 月上线 Agent 模式后，高频用户（蓝色线）的日均代码提交行数显著提升。9 月份数据显示，高频用户日均提交约 560 行代码，而其他用户约为 400 多行。这至少证明 Agent 模式对提效是有效的。

我们还发现，前 10% 的用户提交的代码行数是其他用户的两倍。但效率提升可能远不止于此，因为许多工作还涉及协作和会议。此外，TOP 10 用户的 Token 消耗占了总消耗的 80%。

随着工具发展，由 AI 生成的代码提交占比越来越高。像 JDK 升级、NPM/SDK 包升级这类任务，尤其是 JDK 11+ 的升级场景，内部已几乎全部交由 Vibe Coding 工具完成。数据分析、数据整理、大促期间的截图、压力测试中的重复任务，过去必须由人工完成的工作，现在部分可由 Agent 接手。甚至一些过去因成本过高而无法进行的工作，例如评估一次发布是否会影响其他关联系统，现在也在尝试用 Agent 来解决。

用户在 Vibe Coding 过程中遇到的挑战

从用户视角看，当前的技术和产品仍面临一些亟待解决的问题。用户常因 AI 表现不佳而沮丧，后台日志中充满了“电脑太笨了”这类充满挫败感的反馈。用户频繁删除和修改代码的现象也很普遍。

综合来看，Vibe Coding 工具给用户带来的问题主要体现在以下四大方面。

1. 代码质量问题

我认为代码质量不足主要体现在：

• 一致性不足：在不同场景下，生成代码的质量和风格差异大。在存量代码仓中，AI 常按自己的风格生成，与现有代码风格不一致。
• 边界条件处理不完善：对于复杂业务逻辑的边界情况，处理不够充分。
• 性能优化缺失：生成的代码往往缺乏针对性优化。
• 安全漏洞突出：尤其是 SQL 注入类漏洞。斯坦福大学的研究指出，AI 生成代码中存在注入类漏洞的比例约为 45%。

在实际中，我们观察到两类典型问题：

1. 安全漏洞：如 SQL 注入、XSS 攻击、密钥硬编码。
2. 逻辑与边界错误：如空指针异常、数组越界。

我们还发现 AI 在代码生成中存在“自洽”问题。曾考虑让 AI 同时生成代码和单元测试来保证质量，但很快发现这行不通。因为 AI 会在逻辑上自洽，可能生成一个有逻辑缺陷的函数和一个恰好能通过（但未覆盖缺陷）的测试，造成“测试通过率100%但逻辑错误”的假象。因此，我们建议用户至少对代码或测试中的一项进行人工 Review。

2. 调试与维护困难

用户使用 Vibe Coding 工具后，调试时间增加了 30%-50%。这是因为 Vibe Coding 倾向于生成黑盒代码逻辑，用户通常只确认最终的代码差异（DIFF），而不会逐行检查生成过程和代码本身。这种“黑魔法”一旦出问题，用户往往无从下手，导致技术债务累积。

另一个问题是上下文理解的局限。对于存量业务逻辑，代码为何这样写、能否删除等问题，对 Agent 而言都是难题。Vibe Coding 工具缺乏全局思维，生成的代码模块化不足、耦合度高。目前有一些方案试图解决，如建设 Repo Wiki 或 Deep Wiki。

缺乏可追溯性也限制了工具使用。Vibe Coding 一次性生成大量代码，很难定位是新需求导致错误，还是最初生成就有问题。如何引入版本管理概念以便回滚，是一个挑战。目前有些方法，比如每次修改并通过测试后提交一个 Commit，或使用 Cursor 的回滚功能，但整体上可追溯性仍不足。

此外，当前 Vibe Coding 工具还无法像人类一样熟练使用调试工具（如设置断点）。它们通常通过大量打印日志（console.log）来定位问题，需要用户复制报错信息粘贴给工具分析。这种模式效率低下，人工介入多。

3. 用户体验问题

除了编码问题，工具本身也存在诸多不足：

• 稳定性和成功率低：执行时间长（30秒-5分钟），且并非每次都能成功。失败原因多样（模型错误、工具调用出错、IDE不稳定）。不稳定的结果让许多用户在时间紧迫时不愿使用。
• 交互界面设计缺陷：许多工具频繁改版，导致用户找不到原有功能，或不断加入新功能让用户困惑。例如 Devin 的多次改版。
• 沟通交互障碍：AI 理解能力不足，需要用户反复确认意图，增加沟通成本。长链路任务执行能力不足，无法维持长期上下文对话（受 Token 上限限制）。
• 工作流程中断：IDE、CLI、Web Agent 等各种工具擅长领域不同，但无法让用户在统一流程中解决问题。频繁切换工具导致上下文丢失，效率降低。

4. 成本与效率问题

Vibe Coding 的成本高企，使得大多数参与方都不满意。

• Token 消耗激增：一次代码补全约 4000 tokens，而一次 Vibe Coding 任务可能达到 6,000,000 tokens，增长 1500 倍。
• 成本与效果的恶性循环：成本上升迫使产品方压缩成本，进而降低 Vibe 效果；效果下降又导致用户不断重试，反而进一步推高成本。
• 加速技术债务：Vibe Coding 引入的技术债务反过来对 Agent 提出更高要求，消耗更多 Tokens。
• 缺乏规模效应：大模型应用没有边际效应，用户规模越大，成本不一定越低。

Vibe Coding 产品自身遇到的挑战

随着 Agent 和模型能力演进，产品功能也在变化，这给产品设计带来了挑战。

在产品设计层面，无论是 IDE Agent 还是 Web Agent，都处于摸索阶段。

• 界面区分度不够：Chat、Deep Research、Agent 等产品往往都是一个对话框，用户难以区分功能差异。
• 对用户缺乏引导：面对对话框，用户常不知该输入什么。不同工具有明确适用场景，但用户往往一刀切，导致实际效果不佳、学习成本高、使用频次低。像 Devin 这类工具的留存率就很低。
• 无法一站式实现功能闭环：用户面临的不只是编码，还有发布、部署、调试等问题。当前工具无法在一个产品中解决不同难度问题，导致用户需要频繁切换工具。

安全性问题也值得高度关注。例如 Cursor 曾出现删除用户本地代码的情况，Anthropic 的 Claude Code 被劫持用于探测漏洞。在内网，我们尚不能完全信任 Vibe Coding 工具。供应链攻击和开源代码风险加剧了这一问题。Vibe Coding 工具对代码和电脑有控制能力，能自由探索，可能发现并利用系统漏洞。因此必须在安全环境中使用，并严格管理权限。

Agent 建设过程中的一些经验

在参与 Agent 建设的过程中，我们积累了一些经验教训。

1. 摒弃 All In One 架构

最初我们采用了 All In One 架构，带来了很多问题。核心是一个输入框，外围环绕着 MCP 工具、知识库、各种剧本，涵盖数据处理、前后端开发、代码审查、风险管理等。这导致：

1. 所有工具和知识都要放入上下文。
2. 上下文特别长，无法压缩成本（曾有一个 Claude 任务成本高达几百元）。
3. 任务成功率低，消耗大量 Tokens。
4. 很难针对不同场景进行调优（例如，我们的 Agent 在前端场景表现就不佳）。

2. 建设可靠的知识质量体系

知识和数据是 Agent 的养分。我们调整了策略：

• 代码数据：建设 DeepWiki, RepoWiki, Embedding 数据库，提升 Agent 对整体代码库的理解和搜索能力。
• 研发行为数据：将构建、CI、CR、发布、监控等行为数据有机结合，提升模型的全局理解能力，帮助解决简单重复任务。
• 文档知识库：传统 RAG 技术只能解决少部分问题。我们通过建立中间层来处理面向 Agent 的数据协议，解决文档中的信息过时、图文混杂、错误信息过滤等难题。
• 隐性知识：许多知识藏在开发者大脑里。我们思考如何设计产品，帮助用户主动将这些知识沉淀下来，而非自动生成。

3. 上下文记忆与工具集成

Agent 任务的成败很大程度上取决于上下文管理的成败。我们对上下文的写入、提取、压缩和隔离做了大量处理。

为了让 Agent 满足大多数用户需求，我们在容器中集成了大量工具，共分为10类：

1. 基础工具 (6个) - 任务管理和基本交互
2. 文件操作 (8个) - 读写编辑和管理文件
3. 终端控制 (5个) - 命令行执行和监控
4. 浏览器自动化 (11个) - 网页浏览和交互（如 Playwright）
5. 手机云 (12个) - 虚拟设备控制和测试
6. 多媒体 (5个) - 图像和音频处理
7. 开发工具 (7个) - 代码开发和部署
8. 协作工具 (5个) - 团队协作和集成（如任务分享）
9. 高级功能 (1个) - 并行执行优化
10. 网络搜索 (2个) - 信息和资源获取

4. 成本控制与模板化

面对初期单个任务近 400 万到 1000 万 Token 的惊人消耗，我们不得不进行成本控制。通过任务模板和预设任务是降低成本、提高成功率的有效手段。

积极适配和拥抱国产开源模型

解决成本问题的另一个重要方向是拥抱国产开源模型。使用国外 SOTA 闭源模型存在昂贵、隐私合规风险、限流、性能波动和备案等问题。

然而，国产模型在长链路任务中仍存在一些问题：

• 死循环问题：Agent 容易陷入反复执行某条指令的循环。
• 格式遵循能力不足：如 XML/JSON 标签格式不准确，导致解析失败。
• 指令遵循问题：在超长上下文中，可能遗忘某些指令，尤其是在未充分训练的场景（如发布、运维）。
• 全局智能缺陷：容易“走一步看一步”，导致结果随机性大且消耗大量 Tokens。

为应对这些问题，我们做了以下努力：

• 主备模型切换和重试：主模型失败后自动切换到备用模型。
• 流式响应处理和续写：当模型输出被截断时自动续写。
• 健康检查与死循环检测：针对重复执行、逻辑错误导致的无限循环进行检测和干预。
• 格式检查与修复：实时检测并自动补全 XML 等标签。

提升体验与降低成本的创新实践

1. 模板化能力

普通用户常不清楚产品能做什么，也不知道如何准确提需求，导致任务成功率低且 Token 消耗大。我们考虑将已成功完成的垂直任务抽象为模板。模板是一套工具和知识的集合，它使得成功经验可复用，能提高成功率、降低 Token 消耗，并为用户提供使用引导。

在内部，约 50% 的任务使用了模板，使用后任务成功率提升到 95% 以上。通过固化 Prompt、工具和知识形成模板，用户可以先选择模板再执行具体操作。

2. “Agent as Tool” 架构创新

我们采纳了 “Agent as Tool” 的理念。这意味着可以将一个专门用于深度调研的 Agent 视为一个工具，主 Agent 只需调用它即可。这样可以将部分任务抽象化，形成专业分工。

从“函数即工具”、“LLM 即工具”到“Agent 即工具”，我们将复杂任务分解为子任务，通过工具化的方式协同处理，有效管理了上下文长度和任务复杂度。

以上是关于产品和用户体验方面的分享。实际上，我们的工作成果已逐步开放给外部用户使用。未来，我们也会持续将内部的技术实践与思考贡献给更广阔的 开发者社区，特别是在 人工智能 和 开源实战 领域，与业界同行一起探索 Vibe Coding 的未来。我们也整理了相关经验，形成了可供参考的 技术文档，希望能为同行提供一些借鉴。