Claude 封锁中国，腾讯带着国产 AI 编程工具 CodeBuddy 来了

采访嘉宾 | 汪晟杰，腾讯云开发者 AI 产品负责人

编辑 | Tina

AI 编程工具的竞争已经进入深水区：不仅各家产品在补全速度、上下文感知、智能体协作上不断拉锯，在背后的模型层面，博弈同样激烈，甚至出现了全球范围的“准入门槛”和“封锁线”。这意味着工具之争早已不是单纯的产品对比，而是与模型生态、合规和市场战略深度绑定。

然而，在这样的背景下，国产代码模型也在加速发力。今年 8 月，DeepSeek V3.1 在国际开发者社区引发热议：它在 aider 编程基准测试中取得 71.6% 的成绩，成为新的非推理类 SOTA，不仅比 Claude Opus 4 高出 1 个百分点，还便宜 68 倍。更重要的是，这一版本在编程表现、Agent 能力、推理效率和长文本处理等方面全面升级，为国产工具落地提供了坚实基础。

顺势而来的是国产编程工具的演进。8 月 21 日，CodeBuddy IDE 率先完成 DeepSeek V3.1 的接入并开启公测，让开发者第一时间体验最新国产模型在真实场景中的能力。仅仅不到三周，团队便根据反馈完成优化。

9 月 9 日，CodeBuddy 带来了两大更新：

首先是增加新的产品形态 CLl，也有独立的名字“CodeBuddy Code”。这是国内乃至全球少数同时支持 IDE 插件、独立 IDE、CLI 三种形态的 AI 编程工具，开发者可以自由切换，按需选择最适合的工作流。

全新上线的 CodeBuddy Code 是终端原生的 AI CLI，通过 npm install -g @tencent-ai/codebuddy-code 即可安装。它让习惯命令行的开发者在熟悉的环境中获得 AI 辅助，无需切换工具，并能与现有脚本和工具链配合使用。CodeBuddy Code 内置文件编辑、命令运行和提交创建等功能，也支持通过 MCP 扩展或自定义开发工具。

（CodeBuddy Code 的操作界面）

整体而言，CodeBuddy Code 具备自然语言开发、智能代码库分析与集成、内置完整工具链、多场景任务自动化、灵活扩展 AI 团队能力（即将上线）等五大核心产品能力。

其次是 IDE 新能力与生态融合，并宣布 CodeBuddy IDE 开启公测，面向所有用户开放使用，无需邀请码。国内版支持 DeepSeek，所有功能均可无限制使用；国际版支持 GPT 与 Gemini 等主流模型，可同时在 IDE 和 CLI 消耗 Pro 模型额度（测试期间赠送部分 Pro 模型体验额度）。

本次公测的 IDE 版本在两方面提升显著：其一，针对 AI 编程领域普遍存在的痛点（如后端质量不稳定、上下文不足）进行整体优化，结合新的 Agent 设计，进一步提高生成质量与稳定性；其二，与腾讯生态的融合更深入，尤其是 CloudBase、EdgeOne Pages 等能力，开发者可以直接用 CodeBuddy 从零构建小应用，并一键部署到腾讯云开发环境中，打通了完整的“代码、部署、上线”闭环。

这也意味着，国产模型的突破正在与国产工具、云平台、应用生态联动起来，形成一条贯通的“模型—工具—生态”链路。

在这样的背景下，InfoQ 采访了 CodeBuddy 团队，深入探讨他们在产品定位、技术决策以及未来发展上的思考。

AI 编程工具的中国路径

InfoQ：从最初发布到现在，CodeBuddy 中间其实发了不少功能，那么回顾起来你们在定位或功能上有哪些关键转折？

汪晟杰：在腾讯内部的调研中，我们发现开发者多达 30% 的时间被消耗在重复性和手动任务上，在编码方面这些任务包括：CRUD 的业务代码编写、格式化和代码规范检查、提高单元测试及其覆盖、API 文档过于老旧需要维护、调试和错误修复，等等。我们一直希望突破仅仅是“代码生成”，而是打造一个能理解项目上下文、执行复杂任务的智能助手，让开发者真正从繁琐工作中解放出来。

事实上，在 2018 年之前没有 AI 的时候就开始探索了，不过更多的是依赖于 IDE 自身，通过很多规则来判定交付，或者可能会推送一些可能相似的函数或者调用，帮助用户提效，但整体还是通过纯手工编码。

我们也从产品的用户画像和用户的痛点出发，做了很多调查，发现大家需求可能集中在针对新的业务，希望能快速了解工程规范和优化工程，希望 AI 能帮我写、帮我读、帮我分析、运行，去解决当前工程的问题；在专业的评审环节，帮我快速辨别或者发现问题；以及对于专业的行动，快速帮我搜索。

于是我们就在几年开始落地，立项做一款工具，希望加速并且提高软件的开发质量，并且能使用不同研发的阶段下，所以我们先在原有工作环境里面进行优化，做一个在主流的 IDE 中可以快速安装的插件，帮大家完成上面的任务，就是最早的 CodeBuddy 代码助手。

到 2022 年的时候，AI 云慢慢爆发起来之后，我们通过让 AI 可以写代码，提升编码的速度，于是我们做了代码补全的能力：触发特定情况的时候可以自动推荐、确认、补全，帮你完成代码编程。到 2023 年、2024 年的时候，智能体 Agent 进到大家的视野里，我们在更多产品形态里面可以用到它，比如通过简单对话能够帮我完成一个项目工程的理解、知识库的检索、更好地能懂我当前上下文，通过一些智能修改、内联对话的方式，快速用自然语言生成大部分完整的代码。

到 2024 年、2025 年，在插件形态的 CodeBuddy，我们推出了一个叫 Craft 软件开发智能体，希望能做到的逻辑是我们能不能站在用户角度，懂我、懂工程，生成用户需求要多文件项目，并通过 AI 进行反思、修正，并且运行，有点像后来说的 Vibe Coding（氛围编程）。这时候我们已经在以 Agent，也就是软件开发智能体的形态，完成一种智能体的开发协同，结合了这个模式很好的开启了和企业、个人的互联。

2025 年 Q2 季度，我们发布了 CodeBuddy IDE 国际版，在产设研和规约编码上，基于海外模型，做出了一定的成效，比如有一些用户基于 CodeBuddy IDE，开发出了一个管理后端。另外在插件版本上我们也做了重构，接入国内模型和混元模型，专注在已有的 IDE 下的 AI 编码工具，提升了研发效率，在小程序 IDE 的合作上，深度融合小程序的效果，集成开发了小程序 IDE 版本的 CodeBuddy 的智能编码能力。

而在近期发布的 CLI，其实已经在腾讯内部“吃过狗粮”了。在很多场景下，CLI 版能够更灵活地嵌入到研发流水线里，支持批量代码生成、自动化任务执行以及跨项目重构。相比 IDE 插件，CLI 更适合有标准化流程的团队和需要快速迭代的工程环境，同时也为高级用户提供了更多自定义和脚本化操作的可能。

回顾整个产品演进，我们经历了几个关键转折：

• 从单一 IDE 插件到多平台兼容——最初只聚焦在 IDE 内的辅助编码，随着用户需求的多样化，我们逐步扩展到小程序 IDE 和独立 CLI，实现不同场景下的高效支持。

• 模型整合与优化策略——从最初单一海外模型，到接入国内模型和 Hunyuan 模型，使产品在不同项目、不同语言环境下都能保持较高的智能化水平。

• 从工具型到 CLI 提效的流程型能力——不仅是单次编码辅助，更开始覆盖任务管理、自动化执行和工程上下文感知，逐渐向团队级 AI 研发助手转型。

• 整体来看，每一次迭代都不是单纯增加功能，而是针对不同研发场景进行能力重塑，让 CodeBuddy 既能满足个人开发者，也能服务企业级团队。

InfoQ：你们为什么选择这种产品形态（IDE 插件 / 独立应用 / CLI）？ 如何决定哪些功能应该内建在 CLI 里，哪些应该留给 IDE 工具去做？

汪晟杰：产品形态本身的选择也取决于技术本身的发展，我们最早也是从代码补全的插件开始，随着 AI 技术的成熟，对软件工程的改变越发深入。开发者的需求从“代码补全”转向“全栈应用开发”与“流程自动化”，AI 编码产品的形态也从最早的 IDE AI 插件，到 AI IDE 和 AI CLI 等多种形态并存。

IDE 插件、独立 IDE 和 CLI 面向不同用户和场景：

• IDE 插件针对日常开发者，提供实时代码补全、跨文件分析和重构等功能，嵌入现有工作流；

• 独立 IDE 面向大型团队和复杂工程，支持工程上下文理解，和任务拆分，规约编程，面向产设研一体的开发平台；

• CLI 面向自动化和批处理场景，用于批量 API 替换、全仓索引和 CI/CD 集成。

功能分配遵循原则：交互性强、依赖上下文的任务放 IDE；批量、自动化任务、异步完成工程任务的，放 CLI；依赖于本地主流 IDE 的开发者，对已有 IDE 产生粘性的用户，可以采用插件形态。整体目标是针对不同场景提供最优开发效率和 AI 协作体验。

InfoQ：在代码补全场景，你们有没有采用什么特殊优化？除去“补全层面”，在复杂 refactor 和大规模代码迁移场景下，CodeBuddy 在这一层能做到什么？有真实 benchmark 吗？

汪晟杰：在代码补全方面，我们除了常规的上下文感知补全外，还在模型侧和工程侧做了多维度优化，比如我们支持 NES（Next Edit Suggestion）和补全缓存，能够快速提供更精准、可靠的补全建议。

在复杂重构和大规模代码迁移场景下，CodeBuddy CLI 的优势更加明显。我们内置的“全仓记忆 ”机制，可以让智能体快速记住之前的总结、工程描述等。工程上下文压缩和自定义策略（Rules）是基建能力。

在真实 benchmark 上，我们并没有做精准的评测，而是更多的以宏观的方式去看效果，看提效。相比传统研发，新时代的 AI 辅助编码，可以大大降低了编码阶段的时间，也成为了开发者很强的粘性工具。

InfoQ：很多开发者会把国产 AI 编程工具和 Cursor、Claude Code、Copilot 作比较。在你看来，CodeBuddy 的独特技术壁垒是什么？它在哪些方面不是简单的平移或替代，而是真正提供了新的价值？或有没有你们认为只有在中国市场才能跑通的独特场景？

汪晟杰：CodeBuddy 不只是一个 AI 代码补全工具，而是一个面向企业级复杂项目的工程智能体平台，结合全仓感知、任务级自定义 Agents 和本地化场景优化，提供了在海外工具难以复制的价值。在国内，很多企业有严格的数据安全、代码隐私和云端合规要求。CodeBuddy 可以本地化部署、支持私有模型接入，同时兼顾国内主流 IDE 和国产代码托管平台生态。这些场景在海外工具中很难原生实现，是在中国市场才能真正跑通的独特价值。

比如，CodeBuddy 按照客户体量和安全要求差异，分为个人版和企业 SaaS 版、企业 VPC 专享版和私有化订阅版等多种版本，形成了清晰的商业模式。同时，我们建设了大模型新范式的研效生态体系。在具体客户合作案例中，企业客户依托我们的伙伴生态，利用 CodeBuddy 成功完成旧系统的改造、流水线智能化升级和企业内部泛开发者大规模推广落地。

总结来看，CodeBuddy 不只是“替代 Copilot 或 Claude Code”，而是在工程级智能体、全局上下文感知、自然语言闭环执行以及本地化合规等层面形成了技术壁垒和差异化价值。它解决的是开发效率和工程协作的深层痛点，而不仅仅是代码补全。

InfoQ：现在 AI 编程工具百花齐放，多少有点像当年的“前端框架大战”。过去没人会一周用 Angular，下一周又改成 React，再换成 Vue；但今天很多团队在 Cursor、Claude Code、CodeBuddy 之间频繁切换。另一方面，各工具之间的差异也在缩小。那么在你看来，是否已经出现了判断标准，来帮助团队选择最合适的工具？

汪晟杰：每一位开发者可能都会有自己的“体验感受”，这本身是个性化的，跟他所处理的场景和任务也有很大关系。也许他内心是有“标准”但还没提炼出来，我认为这个标准也许对我们做产品而言更加重要，因为我们需要有更普适、更明确的标尺去指导我们优化用户体验。整体而言，我们观察下来认为：

• 场景适配优先于品牌偏好。 不同工具在“代码补全”、“大规模重构”、“跨文件迁移”甚至“工程级 Agent 协作”上能力差异仍然存在。团队不再单纯追求新奇或明星工具，而是根据项目特点来选择。例如：小型前端项目可能更关注快速补全和内联建议 → CodeBuddy 或轻量级 IDE 插件足够。大型后端或跨仓库重构项目则需要上下文感知、全仓记忆和 Sub Agent 协作能力 → CodeBuddy IDE 或 CodeBuddy CLI 相结合更适合。

• 工程上下文管理能力成为核心指标。 过去选择工具主要看语言模型能力，但现在团队越来越关注工具是否能完整理解工程上下文，是否是一个上下文感知能力强的工具，能够减少切换成本和潜在错误，这一点比单次补全的准确率更重要。

• 可扩展性和定制能力。 随着团队规模增长，工具是否允许自定义 Agent、指令、插件或任务链路，会直接影响长期效率。简单的“开箱即用”体验固然重要，但可扩展性和自动化能力决定了工具是否能在团队内部形成核心竞争力。

InfoQ：如果要把 CodeBuddy 来个定位，你们倾向于放在“能力最强”的这一端，还是“更快更便宜但能力较弱”的那一端？ 如何在速度和代码可维护性之间平衡？

汪晟杰：我们的核心用户群是产设研群体，所以，CodeBuddy 不是追求“最快”，而是追求“工程质量”，在此基础上尽可能做到快。我们认为未来 AI 编程工具的竞争，不会只看生成速度，而是看谁能在百万行级的真实项目里，让开发者少踩坑、少返工、持续维护。

InfoQ：目前 CodeBuddy 的用户规模大概是多少？技术用户和非技术用户的比例如何？企业客户占比又有多少？

汪晟杰：目前我们拥有百万级用户，有 1/4 左右是非技术用户，企业客户占了 40%。

技术决策的核心：上下文、规则与协作

InfoQ：有开发者反馈国产模型在性能上大约能发挥 Claude Code 七成多的水平，但在长上下文和稳定性上仍有差距。你们在选用混元 + DeepSeek 双模型时，实际测试的性能差异体现在哪里？在什么场景下国产模型已经足够好，在哪些环节还存在明显短板？

汪晟杰：针对混元 +DeepSeek 双模型场景，在小程序上我们有做一些优化，结合小程序的知识库强化，在小程序上 default+DeepSeek 下，可以做到比较好的还原度，同时在工程层面上让小程序编码更智能快捷。

当然在其他方面，比如上下文支持、稳定性、代码生成的稳健程度上，还是和 Claude 模型有一定差距。但我们觉得 AI Coding 赛道会随着模型越来越强，弥补上去，我们先做好产品体验，内部我们戏称，“枪准备好了，就等待更好的子弹”。

InfoQ：Cursor 因调整价格而陷入热议，并且通过优化上下文传递来降低推理费用，但这类方法始终有限，那么 CodeBuddy 对外的时候需不需要考虑商业模式？并且在成本控制上有没有新的思路？

汪晟杰：我们不会走 Cursor 那种“单一大模型 + 涨价”的路。CodeBuddy 从设计之初就考虑了商业可持续性，采用分层商业模式：个人用户用低成本模型保证体验，团队和付费用户在需要时可以调用高性能模型，而企业用户可以有选择性的选择企业私有化的开源模型，做到成本和价值解耦。

在成本控制上，我们有两方面创新：

• 智能模型路由：按场景选择最合适的模型，避免无效算力浪费；

• 上下文优化：对于非必要的上下文做好精细化裁剪，并在合适时机做压缩和总结。

InfoQ：很多开发者抱怨某些国产 AI 编程工具几乎都是按 token 计费，结果一旦用 high 了，分分钟就是上亿 token 的花销。CodeBuddy 在计费模式上会不会有新的探索？比如订阅制、企业级套餐，或者更透明的 token 消耗反馈和预算上限管控？

汪晟杰：我们意识到纯按 token 计费模式会带来成本不可控的问题，尤其是在高强度使用下可能瞬间产生巨大开销。因此，CodeBuddy 正在探索订阅制和企业套餐，提供固定额度（credit）和团队管理能力，同时内置实时消耗反馈和预算上限管控，让开发者和企业可以清晰掌握成本。我们还在尝试智能模式切换，根据任务复杂度选择合适模型，以降低不必要的 token 消耗，实现可预测、可管理的使用体验。

InfoQ：关于上下文，长会话里，多次压缩后最初的意图可能被淡化，模型也会遗忘部分指令，虽然我们很期待模型有更大的“有效上下文”。在 CodeBuddy 的设计中，你们是更依赖上下文压缩算法这类的技术解法，还是尝试用外部存储（如 KV store / 向量检索）产品解法？是否还有其他内部需求或‘黑科技’值得分享？

汪晟杰：CodeBuddy 采用 压缩 + 外部存储的混合策略。通过即时上下文压缩，使得：

a.  对话或编辑历史在本地 / 临时内存中做轻量压缩，保证模型可以快速处理当前任务。

b.  类似“流式摘要”，保留核心任务意图和最新代码片段。

InfoQ：现在开发圈里很热的是“后台代理”和“看板式多代理系统”，像 Cline 可以在 CLI 开多个代理，或在 GitHub Action 或云进程里跑，以及还有像 roo code 的 Boomerang 任务模式。腾讯的 CodeBuddy Craft 会不会也尝试类似的探索？在你们看来，是一个能力不断扩展的单体代理更可控，还是并行协作的多代理在大规模场景里更具优势？

汪晟杰：CodeBuddy CLI 正是在做这类事情的探索。结合 CDE（Cloud Development Environment）可以很好的异步执行，拉起环境，启动 CLI，生成到执行程序，合并到主线，过程中有冲突则解决，有运行失败则反思修正。我们在 Cloud Studio 产品上已经落地了类似的能力，给教师端提供作业批改的 Background Agent，当学生提交作业的时候就会主动触发进行作业批改，完成后将结论推送给教师。

单体代理和多代理协作要解决的问题场景不一样，都是要深度探索，不断迭代的领域，要让单体代理解决好垂直场景问题，同时又要让多个智能体之间有良好的协作节目。

InfoQ：很多人对 AI 代码助手的担心是：它会不会一直“死磕”，走错路还在不断尝试？在 CodeBuddy 里，你们如何设计“自动探索”与“人工介入”的边界？哪些场景你们敢放手让代理全自动执行，哪些必须要有 human-in-the-loop？人工介入的 checkpoint 是怎么设置的？

汪晟杰：自动探索 vs 人工介入的原则：

• 自动探索：适合结构清晰、规则明确、风险可控的任务，比如：批量重构固定风格的代码（rename、move file、format），执行标准化脚本操作（依赖安装、代码 lint），小范围单元测试或自动修复可预测错误。

• 人工介入：涉及高风险、不可逆或者结果多样化的场景，比如：核心业务逻辑改动（finance、auth、payment），架构级迁移或重构，多模块交叉依赖的复杂变更。

在 CodeBuddy 中，checkpoint 是人为设置的“检查点”，确保自动行为不失控。常见做法：

1. 任务级 checkpoint

每个子任务执行前，弹出摘要给人类确认

例如：“我计划在文件 X 修改 10 行函数 Y，你确认吗？”

2. 结果校验 checkpoint

自动执行后先生成 diff/ 日志，让用户 approve 才提交

可结合单元测试、lint 或静态分析，自动判定是否安全

InfoQ：有人认为“规则和记忆本质上是一样的，本质就是提供上下文”。但在 CodeBuddy 里，你们区分了 rules、plan mode 和 Spec-driven。你们怎么看待这三者的边界和各自的作用？

汪晟杰：这个问题非常有意思，也触及了 AI 编程助手设计里一个核心哲学：“上下文”到底如何被管理和利用”。我可以从 CodeBuddy 的设计思路梳理一下 rules、plan mode 和 spec-driven 之间的边界和作用：

• Rules（规则）的本质：硬性约束或操作规范，确保安全与一致性。

• Plan Mode（计划模式）的 本质：多步策略执行，指导 AI 按步骤完成复杂任务。

• Spec-driven（规格驱动）的 本质：以功能或产品规格为导向，生成符合需求的代码。

InfoQ：很多 AI 编程工具在强调 YOLO 模式 和 SOLO 模式。你们怎么看待这两种模式？在 CodeBuddy 的设计里，会如何取舍或融合？

汪晟杰：YOLO 模式追求快速实验，效率高但风险大；SOLO 模式强调自由探索，灵活性强但协作成本高。CodeBuddy 通过规则引导、上下文感知和审查，将两者融合，让开发者在自由与规范间自如切换。

在 CodeBuddy 的理念中，YOLO 模式和 SOLO 模式并不是对立的，而是互补的两种工作心态。YOLO 模式激励开发者大胆尝试、快速迭代，避免陷入过度设计；而 SOLO 模式则帮助开发者在独立思考和全局把控中找到个人创造力的发挥空间。

CodeBuddy 通过语义理解、通过人机交互，比如询问下一步建议、是否要继续的确认框等交互，使开发者可以在团队规范下“放心 YOLO”，也能在需要深度思考时“高效 SOLO”。当用户处于快速原型阶段，可以告诉系统，请帮我全部完成，那么 CodeBuddy 会拆解任务，甚至还会测试验证、错误修正建议，降低试错成本；而在独立探索时，CodeBuddy 会强化对上下文的捕捉和个人偏好的学习，让开发者保持专注，改动少量文件，甚至是文件的光标后的预测推荐。这样，既能保持创造势能，又能减少因为随意性而带来的技术债。

InfoQ：规则太多容易把团队管死，规则太少又容易失控。你们认为大型团队在制定规则集时，真正的“临界点”在哪里？CodeBuddy 又是如何帮助团队在这种张力下找到平衡的？

汪晟杰：临界点其实不是固定的数字，而是团队能在自由度与可控性之间实现最优张力的点：核心规则保留关键约束：如代码风格、测试覆盖率、提交规范等。

可调整的自由区间：允许团队成员在非核心部分自主选择工具、方法、实现方式。

所以，CodeBuddy 的规则层可配置化，团队可以在 CodeBuddy 内设置必遵守的规则（例如代码风格、模块依赖限制、测试覆盖率阈值）。

InfoQ：关于 MCP：在 CodeBuddy 里，面向 MCP/ 工具的“最小可信工具集”是什么？你们如何在开放性与产品安全性、一致性之间做平衡？

汪晟杰：核心思想是：每个工具必须可审计、可验证、可组合，但不能无限制扩展。MCP 内的每个工具都有明确的输入输出规格，避免生成代码或操作出现意外行为。

本质上，MCP 就是“最小、可信、可组合”的工具集合，能够支撑 CodeBuddy 的核心功能，同时降低复杂性和潜在风险。

Vibe 是过渡，Spec 才是未来

InfoQ：你们提到 AI 会打破专业壁垒，模糊 PM、设计师、开发者的边界，团队结构因此发生调整。那么在 CodeBuddy + Supabase + Vibe Coding 的实践里，目前有非技术人员使用的真实例子吗？

汪晟杰：非技术人员可以直接触达代码或数据层，无需完全掌握编程。CodeBuddy + Vibe Coding 让自然语言和可视化交互成为主入口。

团队结构变化：PM/ 设计师 / 运营可以承担“原型构建 + 数据操作 + 部分前端逻辑”的角色。开发者更多专注于架构、性能优化和安全控制。

真实落地：目前在一些初创团队和内部业务线试点中，PM 和设计师确实在没有手写代码的情况下完成了 MVP 和内部工具原型。

补充一下，我们的实践不仅仅有 Supabase，我们还有 CloudBase，也就是腾讯云开发，他们在跟小程序的结合上也有很深的积淀。同时，目前我们也在跟腾讯生态做更好的融合，你点开 CodeBuddy IDE 的 integration 界面，会发现我们现在不仅仅有 Supabase、云开发 CloudBase，还有腾讯云 EdgeOne Pages，针对小程序这块我们也会逐步优化，同时未来我们也集成越来越多的内外部能力。

InfoQ：有观点认为 Vibe coding 并不适合企业场景，对个人开发者也存在限制，比如技术栈固定、目前模型生成出来的 PR 无法保证没有 Bug。你们认为 Vibe coding 到底是面向什么样的用户群体？它的边界和定位在哪里？

汪晟杰：我想，Vibe Coding 大致的定位可能是：“一种辅助开发的创作型工具，优化开发体验和迭代速度，而非替代专业工程师。”

它的边界是：

• 适合原型开发、个人 / 小团队快速迭代、熟悉技术栈。

• 不适合关键生产系统、全栈大团队核心代码、对 Bug 零容忍的场景。

使用策略：

• 企业可以用 Vibe coding 生成草稿、建议或 PR 草案，再由人工严格审查。

• 个人开发者可用它 加速实验和小型项目，同时保留人工掌控权。

这涉及到 Vibe Coding 的定义，但我们要注意 Vibe Coding 不等于 AI Coding 的全部。AI 能力本身对现代软件工程会带来广泛且深入的变革，我认为这个是毋庸置疑的。因此，假设 Vibe Coding 真的不适合企业，但不代表 AI Coding 对企业和个人没有意义。这个词本身就是就是技术发展过程中冒出来描述某种状态、某种场景的代称，本身技术、产品都是流动的。

所以我们更关注“Spec Coding”。其实这个我们在 7 月 22 日的发布上有分享，我分享一下当时那张 PPT。

企业应用和生产力提升

InfoQ：你们怎么衡量 CodeBuddy 的生产力提升？ 你们有没有通过外部客户或内部实验，量化 CodeBuddy 的生产力提升？是缩短开发周期、减少 bug，还是帮助新人快速上手？能分享一个典型数据点吗？

汪晟杰：CodeBuddy 的生产力提升在这几个地方都有，确实主要体现在：开发周期缩短（效率提升）、低级 bug 减少（质量提升）、新人快速上手（学习曲线优化）。

我们可以分享一些数据，从量化上看，平均效率提升 30–40%，Bug 数量下降约 20–30%，新人上手速度提升约 40%，这也是我们在内部实验和部分客户案例中看到的典型数据。

InfoQ：对于企业，工程副总裁 /CTO 他们关心的不只是个体开发者，而是整个代码库、工程决策。比如一个团队有 100 个开发者，每个人都可能在用这些工具。那么该怎么治理？代码审查怎么改？变更管理怎么改？

汪晟杰：从个体到团队，简单的说，关注点可能会有所不同，主要是从三个层面而言：

• 研发效能层面，从单个开发者效率，到团队治理效率，会更注重规则化、分级审查、自动化监控等。

• 代码审查层面，从“逐行检查” ，到同时关注 “架构和策略一致性”。

• 变更管理层面，从“人工把控” ，到注重 “自动化 + 风险可视化 + 分级合并”。

InfoQ：面向团队与企业。有没有一些企业级的 AI 需求，是单个开发者平时感知不到、只有规模上来后才会暴露的？

汪晟杰：目前没有发现，而且对于我们而言，因为本来需求就是诞生于腾讯这样一个大型企业的开发实践需求，可能我们最早就同时能感知到单个开发者使用体验层面和涉及到组织协作，或者复杂软件研发流程的续期。

“成为自己，而不是下一个谁”

InfoQ：在内部 roadmap 制定时，你们如何预测模型下一个迭代的能力提升点？如何确保产品和未来的模型能力相匹配。

汪晟杰：我们不会单纯“预测”模型能力，而是更关注如何把模型能力“转化”为实际生产力。产品研发流程当前是有完备的方法论的，而且目前看来在 AI 时代依然生效。那么我们可以围绕着产品研发的各个阶段做好场景拆解，在模型能力能够解决该场景的时候，做好产品化输出。

InfoQ：对 PM 来说，这类 AI 工具和传统互联网产品很不一样——模型每天都在变强，功能路线图很难像过去那样提前锁定。你们的产品管理方式和传统 PM 最大的区别是什么？

汪晟杰：需要拥抱不确定性，找到产品价值，而非功能；也要利用好产品功能数据，快速迭代，用数据验证功能价值。

InfoQ：CodeBuddy 的团队是怎么组建的？你们在挑选人才时最看重什么能力？是有工程背景，还是懂 AI 应用？哪些技能是“必选项”，哪些反而不重要？

汪晟杰：我们的团队核心是一批兼具工程能力与产品思维的“多面手”，在挑选人才时，我们最看重的是一个人驾驭 AI 的思维和能力——也就是能否从业务视角定义问题、用架构思维拆解任务，并引导 AI 高效执行。CodeBuddy 就像一把神兵利器，它真正增强的是那些能主动运用 AI 处理重复工作、转而聚焦于系统设计和价值创造的“智能协作架构师”。所以我们不再单纯强调工程背景或 AI 理论，更关注业务洞察、提示词工程和人机协作素养——核心是从“代码执行者”转型为“用 AI 创造价值”的驱动者。

InfoQ：你们还会招聘什么样的人才？

汪晟杰：除了上面的人才外，我们也会针对研发流程来招聘垂直领域的专业性人才，例如质量领域、设计领域。结合他们的背景知识和 AI 能力，来打造好我们的垂类产品和能力。

InfoQ：从未来发展来看，CodeBuddy 最想成为的是什么？一个 AI 版 VSCode？还是国内开发者的 Claude Code、Lovable？

汪晟杰：可能是成为自己，而不是成为别人。在软件开发领域，我们的目标其实是要解决两个方向的问题：人机交互和自动化。基于插件和 IDE 的产品形态，来增强人机交互的体验，提供产设研的统一协作平台。通过 CLI 产品形态，集成到研发流程中，提升自动化运作效率。

InfoQ：如果让你们对标 Cursor、Claude Code、Lovable，最想在技术上超越的“一点”是什么？

汪晟杰：作为 AI 应用，说实在的，应用层的技术上都拉不开差距。但我们可以用户体验上、生态链接上取得优势。

InfoQ：未来两年，你们最想打赢的“第一场硬仗”是什么？

汪晟杰：让生产力走出 CODING 圈子，覆盖更多的场景、用户和客户。