对话CodeBuddy黄广民：AI coding不能“开盲盒”，一款腾讯味儿十足的产品是如何诞生的

作者：董道力
编辑：王兆洋

最近一周，AI Coding产品简直如同井喷。

7月22日，腾讯也正式发布了它的AI coding产品：CodeBuddy IDE。

在多少有些相似的各家产品里，CodeBuddy 的特点也足够有差异性：它想让用户通过自然对话，就能实现应用从产品构想、设计、开发部署的全流程。而不只是强调自动写代码，或者在结果上只强调前端或者原形的展示。

作为互联网时代产品能力很强的腾讯，在今天AI竞争最激烈的AI coding赛道交出的产品究竟什么样？CodeBuddy真的可以搞定产品设计到代码落地的全流程？CodeBuddy和Cursor到底有什么不同？以及更深刻的，随着技术进步下去，AI coding会改变大厂人才结构吗？

在深度体验了一段时间CodeBuddy后，我们发现这个产品确实有点东西，另外我们也有机会和腾讯云开发者产品总监，同时也是CodeBuddy的产品负责人黄广民聊了聊，看看这款产品背后，腾讯的思考是什么。

1

实测CodeBuddy：这就是拥有一整个产品团队的感觉吗？

首先一起来仔细看看CodeBuddy这个产品。

如果要问当你打开CodeBuddy，第一眼感觉它与Cursor等最显著的差异体现哪里，那一定是CodeBuddy的工具栏：

它集成了Figma、MCP、预览等功能，在AI编程模式边上还有设计模式、计划模式的选项。

在打开界面后还有个小机器人在那儿陪着你。

我们尝试从0创建一个项目来体验一下。

我们的prompt也很简单直接：我想做一款AI编程工具，主要功能是“一句话生成一个网站”。

CodeBuddy并不会立即生成代码，而是给用户一些选项，帮助明确需求。就像老板想要做一个网站，成熟的打工人不会直接发个链接过去，而是摸清楚老板到底想要做什么。CodeBuddy问了我们几个问题，项目的目标用户是谁，你的网站是商业性的还是个人博客，你有没有想用的技术框架等。

这些问题在帮助用户完成需求澄清的同时，CodeBuddy也基于这些问题的答案生产了一套完整的预开发方案框架：

包括产品实施路线图、最小可行产品功能清单、原型结构 、技术架构、UI设计等。

这感觉就像一个专业团队，将产品制作前需要的计划，事无巨细的告诉用户。

大部分AI coding工具到此就结束了，而CodeBuddy与腾讯云联动，支持一键把文档上传到腾讯云中，把枯燥的文档通过网页展示出来，这样的一个作用是协作，用户可以通过链接把需求文档分享给其他人。

我们来详细看一下CodeBuddy生成的MVP计划。

MVP计划作为方案核心，并非简单文档聚合，而是对产品战略的结构化表达。其框架包含六大核心模块：项目概述、目标受众、MVP核心功能、技术架构、MVP开发阶段和业务指标。这个逻辑缜密性已超越多数未经过培训的小白，甚至不输一些新手产品经理了。

接下来，基于对AI生成方案的信任（其实是作为技产品小白别无选择），我们全盘采纳了CodeBuddy的MVP框架。

接下来是CodeBuddy的另一个亮点，它的设计能力。

以往AI编程的工作流是在确认需求后，将功能架构交给Lovable等擅长原型设计的AI工具，为什么不直接给Cursor？因为Cursor不擅长。

而CodeBuddy在原型设计上给出多个解决方案。里面最明显的一个“卖点”，就是它支持接入原型设计工具Figma，也就是说设计师在Figma中做完的软件/网站页面可以给到CodeBuddy，实现像素级生成。同时CodeBuddy也考虑小白用户，可以识别用户上传的图片，相当于把“草图变成网站”。

我们选了一个任务：将Lovable的界面进行“逆向工程”。我们把Lovable的页面截图上传给CodeBuddy，验证其设计能力。

在逆向还原Lovable界面的实测中，CodeBuddy首先继承了页面的风格，比如主色调、字体、卡片投影等。并且Lovable的关键文本元素如"Community"、"Pricing"等实现像素级复现，但是导航栏等部分响应逻辑存在偏差。

大致的原型有了，接下来，就让CodeBuddy按照生成的网页，以及MVP计划，完善项目。

在这一步我们顺便测试了一下CodeBuddy的prompts优化功能。

产品小白知道自己想要什么，但很难用有逻辑的精确的产品语言表达出来。此时prompts优化功能的作用就体现出来了。可以发现，CodeBuddy对原文理解到位，优化后逻辑清晰。CodeBuddy把我们的简单一句话，拆解成5个不同步骤，涉及了业务逻辑、用户体验、后端性能等方面。

promtps：好好好，那继续完善项目的各个功能 修改后promtps："请继续完善当前项目的所有功能模块，确保每个功能都经过充分开发和测试。具体包括:1)核心业务逻辑的优化与错误处理;2)用户界面的交互体验提升;3)后端API的性能调优;4)数据库查询的优化;5)安全性增强措施。要求所有功能实现完整闭环，保持代码风格统一，并确保各模块之间的无缝集成。同时建立完善的文档说明和单元测试用例。"

在正式启动项目开发前，CodeBuddy会对整个项目展开系统性规划 —— 涵盖项目分析、技术栈确认、设计优化及任务拆分等环节。我们可以看一下CodeBuddy的官方案例来体验一下。

可以看到，CodeBuddy会先分析整个项目的产品需求文档，找出核心功能，随后确认技术架构，前端用什么语言，后端用什么语言。同时还会确认项目的设计风格，页面规划，交互方式等。最后生成一个详细的计划列表，告诉用户自己会先做什么在做什么。

这不就是包含了产品经理、设计师、程序员、项目经理的产品团队吗？

此外，用过Cursor的用户，想必对其indexing&doc功能留有印象。简单来说，Cursor在执行任务前，会先读取项目的所有文件，以此为基础提升编程辅助效果。而这一功能，CodeBuddy直接整合进了项目执行环节：它会自动逐个读取文件，省去了用户在执行前手动确认的步骤。

经过等待，CodeBuddy完成任务后会给出一份简报，清晰说明自己完成了哪些工作，以此证明它并未 “摸鱼”。

我们来看一下，全程没有修改过，完全由CodeBuddy生成的项目“一句话生成一个网站”。

整体上来看是一个比较完整的网站原型。首页，基本上遵循了我们上传的图片，一个输入框以及一些建议。下半部分是网站功能介绍，甚至有用户评价的假数据。当我们在输入框中输入点需求，项目会弹出一个工作页面，页面左侧是一些主题、网站类型选择，右边是预览界面，甚至还有发布功能。

我们来做第一次版本迭代，通过截图，修改页面。我们将页面中的某个部分截图发送给CodeBuddy，并让他删除，这一步CodeBuddy运行的很快结果也很ok。此外，CodeBuddy还能点对点的修改项目UI元素，打开预览模式后，用户可以直接在页面上精准选择需要修改的地方。

感兴趣的读者可以查看一下项目：https://github.com/ddlpmj/CodeBuddyTest.git。

整个项目的框架已经完成了，后续接入编程大模型添加一个预览框等。截止到这一步，其实已经可以看出CodeBuddy和Cursor等AI编程工具的差别主要在于编程之外，比如产品文档的设计、产品开发规划、技术架构规划、提示词优化等等，这些都是Cursor所欠缺的，而这些恰恰又是小白和大型复杂项目所需要的。

1

对话黄广民：CodeBuddy让创意直通代码，模糊角色界限，重塑研发全流程

这只是我们实测的一个案例，在诸多测试后我们对CodeBuddy充满好奇，也和黄广民聊了聊背后的思考。

以下为对话实录。

从内部辅助编程工具，到对外AI IDE产品

硅星人：CodeBuddy这个产品背后的开发故事是怎样的，经历了哪些关键节点？

黄广民：我们的AI辅助编程工具项目始于2023年初，当时看到GPT对生产力的影响，又受海外Copilot启发，就想着做辅助编程工具。公司里我们部门和工蜂团队各自做了3-4个月，后来沟通后整合了，资源、需求池、代码全共享，既服务腾讯内部也面向外部，那会儿团队才十几二十人。

2023年底到2024年初，能明显感觉到这工具提升生产力。当时代码生成率约20%，但内部接受度很高，所以2024年初加大投入，优化模型、增强端侧能力、调整补全策略。

2024年5月，这工具在公司内落地不错，我们就想着对外发布，帮更多外部企业提升效率，于是当月对外发布了。

2024年我们开始孵化IDE产品形态，内部已经在试用了，但没广泛推广。25年年初我们对IDE做了重新的定位——希望它能解决软件工程全生命周期的问题。于是又重新打造了就是今天看到的这款CodeBuddy IDE。

硅星人：在你们自己测试、使用中，包括用户案例收集里，最惊艳最印象深的作品是什么？

黄广民：有一个外科医生做的健康管理软件印象挺深的吧。我们有个用户是外科医生，想用我们的插件来做个健康管理软件——用户输入体检指标，能快速识别问题并给健康建议。不过开发中遇到了些问题。比如在小程序里读取Excel数据做呈现，他卡壳了。我跟他一起用Prompt工程解决，把内容转成JSON，再用数据渲染页面，这问题就搞定了。

第二个问题是UI美化。他（医生）对审美有要求，但AI生成的页面不好控，小程序多页面风格还可能不统一，加上他不会写CSS，想微调排版也难。最后也是通过调整Prompt解决了。如果用我们今天发布的IDE来编写，就可以精确调整UI了。

硅星人：医生算是我们身边的高知群体了，他在使用AI Coding工具时，有什么优势和劣势

黄广民：优势很明显，他们对业务理解深，他知道应用要做成什么样，这是他的大优势。不足主要是缺工程训练。他不知道怎么精准提问，常把很原始的想法直接丢给AI，导致生成的内容没严格约束，技术方案也跟不上他的想法；而且他提的需求往往很大，模型没好好拆解的话，生成效果就差。后来我跟他交流时，把工程里的最佳实践教给他，告诉他做项目得先拆解需求，再让CodeBuddy去实现子任务，这样才能更精准地达到业务要求。

AI编程不能变成“开盲盒”

硅星人：我体验产品的过程里发现很多产品字节都还挺有意思，比如，你们把「设计模式」和「计划模式」作为核心功能分离了，而同类产品（如Cursor）更倾向一体化交互。这种设计是出于怎样的考量？

黄广民：我们之所以将设计模式和计划模式单独分离，主要有两方面考量：一方面，传统研发过程本就分阶段，而不同角色的诉求各有侧重。像Cursor更多面向开发者，没兼顾产品经理、设计师等角色的使用体验。但我们的产品希望覆盖所有相关角色—— 产品经理需要写需求单，设计师需要用自然语言生成设计稿，这些都是他们的高频诉求。高频诉求作为独立功能存在，能更好满足各角色的使用需求，是合理的。

另一方面，这两个模式能为后续的 Coding Agent（编码阶段）提供规范和约束。如果没有前期的这些规约指导，生成的代码可能像 “开盲盒”，需要花大量时间调整，造成不必要的浪费。而按研发流程先明确前期规约，给下游代码生成强约束，能让生成的代码更符合诉求，成功率也会大幅提升。

硅星人：体验中我发现，相较于Cursor，CodeBuddy当前没有indexing&docs选项，这功能还挺重要的，每次做项目前都要确认indexing阅读率百分百。CodeBuddy采用了每次执行项目前读取一遍所有文件，这两种方法CodeBuddy是怎么取舍的。

黄广民：关于indexing相关功能的设计，我们主要基于这些考量。我们其实尝试过两版Codebase Induction方案。第一版是本地对代码仓库做embedding，靠语义搜索召回内容，但效果一般；第二版换成远程服务端版本，效果也没达预期。

核心问题在于，单纯的index搜索只能召回关联内容，却搞不清这些内容之间的依赖关系——而项目里的文件、类型间其实有很强的依赖关联。语义召回的内容是离散、片段化的，模型很难借此真正理解整个项目，所以评估下来效果不理想。后来我们就回归到模拟人类理解项目的模式：就像开发者面对陌生工程时，会先看目录结构、找关键文件再深入理解一样，CodeBuddy现在也是这么做的。这种方式看似“笨”，但效果更好。大项目可能会多花点时间，但这些时间是前置的，很值得——要是前期对项目理解不到位就贸然修改，后期调整的时间会比前期理解的时间多得多。

硅星人：在AI编程模式下，CodeBuddy有Ask和Craft模式，相较于Cursor缺少了manual和background（云端模式）模式。这么设计是出于什么考虑？ Cursor中background模式也是一个Beta阶段，你觉得background模式有必要吗？

黄广民：关于模式设计，我们目前聚焦两种模式，主要是因为manual模式已属过渡产物。在agent模式推出前，manual模式是主流，但随着模型进化，agent模式能更好帮用户达成目标——人机交互大幅减少，只需最后确认代码采纳即可，所以manual的用户逐渐减少，自然无需再保留。

而对于background模式（即任务全由模型完成、无需值守，仅关注结果），其本质是人机交互从多到少的演化，但目前它还处于Beta阶段，我们暂未推出。一是用户使用门槛高；二是它更面向专业开发者，且存在矛盾点——插件提供AI操作UI，却不在本地运行（本地已有代码仓库和环境），反而在后端沙箱运行代码，显得多此一举，不太适配大部分用户场景。

不过，background模式在被集成场景可能是未来趋势：比如用户提交代码后，沙箱里的CRAgent拉取代码、完成评审、修复甚至合并，再推结果给开发者，这更偏向L4、L5阶段的高级形态。

核心是如何用更少的步数解决用户问题

硅星人：CodeBuddy整合了Figma转代码、Supabase后端等功能，试图覆盖产品设计到开发的全流程。这些整合里的挑战是什么？

黄广民：我们考虑到当下主流设计工具（国内外都以Figma为主），所以肯定要支持Figma，不过整合过程中挑战不小，尤其是和Figma的对接，核心难题是怎么实现设计稿的一比一还原。

Figma自身的开发者模式能生成CSS、HTML样式，靠AI生成的话，很容易丢失关键信息，还原度根本达不到生产要求。所以我们做了大量优化，结合规则转换和AI调整，目前已经能做到95%以上的还原度了。

硅星人：您认为用户对AI生成代码的「容忍迭代次数」（如20次内完成需求）是竞争关键指标吗？CodeBuddy如何定义当前技术下的体验平衡点？

黄广民：用户对AI生成代码的容忍迭代次数，无疑是AI工具的关键指标。

从我们后端数据来看，用户完成单个任务的平均轮次在 10 次左右，大家的容忍度大概在 20 到 30 次之间。我们也在努力平衡轮次，核心是思考如何用更少的步数解决用户问题—— 内部会持续跑Benchmark，对比不同 IDE、不同Agent 在相同任务下的消耗成本、迭代轮次和完成时间，不断优化这一指标。

硅星人：人们都在关注AI coding和模型之间的关系，一种普遍的“误解”是最终能力都来自模型能力，但事实上这中间依然有大量工程挑战，如何解决这些挑战也是AI coding类产品的竞争点之一。CodeBuddy在这方面主要做了哪些事情？

黄广民：对，由于当前模型在推理能力和上下文窗口上存在限制，工程层面的优化就变得尤为关键。

以代码补全为例，它作为用户高频操作，对响应速度要求极高——若超过600-800毫秒，用户可能就失去耐心，宁愿自己编写。因此补全场景会采用小模型，核心目标是“又快又准”：上下文不能过长，但必须包含足够关键信息，比如待补全代码的前后内容、依赖的头文件、方法签名及语法树等，这些都需要在工程层面精准抽取，确保模型能一次性补对。

（CodeBuddy的）Craft Agent也面临类似的上下文限制问题。对此，我们的策略是让Agent快速检索相关上下文，对过往交互内容进行总结，将这些总结作为“二次上下文”反馈给模型。这样能避免重复操作已有的路径，减少模型和用户的不必要负担。本质上，这些优化都是为了在模型限制下，用更少的步骤、更高的效率解决问题，贴合用户对迭代次数和响应速度的容忍度，这也是我们持续通过Benchmark对比优化的核心方向。

丰富的交互、美丽的页面设计，都不如生成效果好

硅星人：今天AI coding 的竞争最大的一个落点就是“快”，我们了解到Cursor内部也在近乎极致的做功能迭代，但同时这类产品又非常早期，这意味着可以做的也有很多，那么CodeBuddy在今天的开发优先级是什么？迭代速度？产品交付质量？新的创新的功能？背后思路是怎样的？

黄广民：在AI应用里，最核心的命题无疑是解决生成效果问题。如果生成效果不佳，哪怕做再多交互、视觉上的表面优化，用户也不会买单。

所以我们的开发优先级，首先必然聚焦在提升生成效果上，通过优化生成效果来进一步提高开发效率，这是我们的核心关注点。

其次，数据显示开发人员实际聚焦在开发过程的时间占比仅约37%，其余大量时间都花在沟通对齐上。

因此我们也在思考，如何大幅缩短这部分时间，具体来说，就是在整个研发生命周期中，想办法消除不必要的浪费，这也是我们重点考量的方向。

硅星人：在Cursor有先发优势的背景下，CodeBuddy目前是更侧重侧重吸引/培育什么类型的新用户，专业程序员、产品经理/设计师，或者是纯小白？还是你们对这种比较简单的划分有不同定义？

黄广民：目前我们在三类用户群体上都有推广动作，不过策略和侧重点不太一样。对于专业开发者，推广会更侧重产品的技术深度，比如代码生成的精准度、与复杂项目的适配性，以及如何通过Agent模式减少他们的重复劳动，提升核心开发效率。

而针对有互联网经验的人群，像产品经理、设计师这类，推广会更贴合他们的工作场景，比如强调如何用自然语言快速生成需求文档、设计稿，以及这些成果如何无缝衔接后续开发，降低他们跨角色协作的门槛，让他们不用懂代码也能推动创意落地。

至于小白用户，推广则更注重简化操作和引导性，比如通过更直观的交互、一步到位的任务模板，让他们即使没有技术基础，也能快速上手，用AI工具把自己的创意变成实际的成果，降低入门的心理门槛和操作难度。

整体还是围绕我们“逐步向上游扩展”的理念，针对不同群体的核心诉求去做推广，让每个群体都能感受到产品对自己的价值。

硅星人：目前市面上比较流行的AI编程工具，大致可以分为Lovable和Cursor两种类型，前者偏向生成原型，后者偏向编程。CodeBuddy的slogan是“设计和开发实时融合”，那是否可以理解为在做一个类似Lovable+Cursor之间的东西。

黄广民：从用户场景和画像来看，Lovable和Cursor的用户群体其实都是我们的目标用户。

虽然这两者聚焦的点各有不同，但我们的产品希望能把他们覆盖的能力、涉及的工作环节更好地串联起来——从一个想法的诞生，到设计落地，再到最终的代码生成，以及后续的部署、分享、运行，形成一个完整的闭环。

硅星人：CodeBuddy作为腾讯的一款产品，这些产品设计思路，哪些带有独特的“腾讯味儿”？把文档上传到腾讯云这个功能我用了很惊艳，未来会不会增加一键接入混元大模型？

黄广民：我们的工具在打通腾讯生态上，一方面已经通过内置混元大模型，以及接入腾讯云的API知识库、插件工具等，实现了与腾讯云产品的良好联动。

另一方面，腾讯自身的小程序开发生态其实是个重要方向——目前已有300多万小程序开发者，市面上小程序数量达1000万款，这是个非常庞大的群体。所以后续我们会和小程序开发场景做更紧密的结合，目标是让小程序开发变得更易上手：只要有好的创意，就能快速生成对应的小程序，降低开发门槛，让更多人能把想法落地到小程序场景中。

硅星人：腾讯内部会使用CodeBuddy吗，有多少项目用到了CodeBuddy，有一个量化的指标吗。可以谈谈你在开发中，用AI Coding的程度，大概占比多少，有没有印象特别深刻的场景？

黄广民：在腾讯内部，目前有90%的开发岗员工都在使用CodeBuddy。

我自己每天开发都会用到它，有两个印象很深的场景：一个是2024年我开发一个C++项目，我已经十年没碰过C++了，是CodeBuddy帮我快速掌握了最新特性，比如智能指针这些。那年我提交了差不多14万行代码，至少一半是AI帮忙写的。

另一个是CraftAgent的重构：1.0版本我们花了一个半月才开发上线，后来让CraftAgent自己重构2.0版本，只用了不到两周就完成了，等于它自己重构了自己。

CodeBuddy这类AI辅助工具本质是SaaS产品

硅星人：近期Cursor修改收费模式引起热议，有竞品的模式是按照一次请求（对话）而非token计费。付费似乎也在变成竞争的关键环节，CodeBuddy会采取什么样的收费模式。您觉得AI产品应该采用什么样的收费模式。

黄广民：关于AI产品的收费模式，目前行业还在探索中，Cursor调整模式也是对商业模式的尝试，可能说明之前的模式尚未实现盈利。

像CodeBuddy这类AI辅助工具本质是SaaS产品，采用token计费其实不太合适。

C端用户很难理解每次请求消耗多少token，对他们来说，一次交互就是一次请求，所以按请求（比如对话次数）计费可能更合理，用户能直观知道一次多少钱，更容易接受。当然，具体定价还是要结合成本核算，毕竟商业模式的核心是平衡用户接受度和商业可持续性，这也是行业需要持续探索的方向。

目前国内市场的AI辅助工具，（ToC）整体还处于未盈利状态，基本都采用免费模式。在ToB领域，行业正处于快速发展阶段，大家的重心还是先聚焦于帮助B端企业提升效率，商业模式的探索会在这个基础上再逐步推进——先解决用户的核心价值需求，再考虑商业层面的可持续性。

AI放大能力，低技术用户独立开发简单应用，全栈工程师需求转向架构把控

硅星人：CodeBuddy试图覆盖从产品设计到代码实现的完整流程。这是否意味着未来「低技术背景用户」能独立完成应用开发？团队如何看待由此带来的职业角色变革？

黄广民：从目前的情况来看，开发门槛的降低确实会让低技术背景的用户有能力独立完成一些简单应用的开发，他们可以借助AI工具把创意落地，不用再完全依赖专业程序员。

但对于复杂的企业级应用，还是离不开专业开发者。因为AI虽然能处理大量细节编码工作，甚至比人写得更规范，但它缺乏基于业务场景的需求拆解能力和架构设计能力，这些需要人来主导。

这种变化也会带来团队结构的调整。比如我们团队现在招聘更倾向于全栈工程师，核心是看他是否有开阔的技术视野和扎实的架构能力——毕竟很多基础编码环节AI能高效完成，而如何基于业务拆解需求、搭建合理架构，这些才是更关键的，需要人来把控。所以并非不需要技术程序员，而是对技术人员的能力要求在变化，从“专注细节编码”转向“聚焦业务理解、架构设计和AI协作”；同时，产品经理、设计师等角色的作用可能更突出，因为他们能更直接地通过AI工具推动创意落地，但核心技术岗位依然不可或缺，只是能力重心在迁移。

硅星人：您觉得1-2年内的未来，会不会设计师、产品经理成为项目/产品的起点。过个5-6年，真正意义上的纯小白，直接成为起点？您有相关的判断吗？

黄广民：随着AI辅助开发的深入，角色界限变得模糊会是一个明显的趋势。

海外硅谷没有专门的产品经理角色，大家更偏向全栈，这背后其实是工具在打破“专业壁垒”——当AI能帮产品经理生成设计稿、写基础代码，帮设计师理解开发逻辑，帮开发者更精准捕捉产品需求时，跨角色的协作门槛会大幅降低，每个角色都能触达研发流程的更多环节。

国内未来很可能也会朝着这个方向发展：不再有严格的“产品经理只做需求、设计师只画稿、开发者只编码”的界限，更多人会具备“从想法到落地”的全流程能力。AI工具就像一个“能力放大器”，让有创意的人能自己推动设计，让懂设计的人能参与开发，让开发者也能更好地理解业务本质。

硅星人：昨天Trae2.0发布，前几天AWS发布kiro，您这边会感到压力吗？你是怎么看到大厂之间AI Coding工具的竞争，有没有一个最关键的竞争指标？

黄广民：目前AI Coding工具领域还处于蓝海阶段，各家厂商都在不同赛道探索，这是好事——大家先一起把市场做起来，还没到“抢地盘”的地步，也没有明显的竞争指标说谁能一统江湖。往后很可能会出现不同维度的AI Coding工具，分别服务不同用户、不同研发流程和角色，帮他们把核心工作做得更好。

其实海外也是如此，一开始有Copilot，后来Cursor、Claude这些也吸引了不少用户，没有哪个产品能完全统一市场。这类工具的本质是帮用户达成业务目标，粘性很难靠数据或社交关系，核心还是看产品体验和生成效果——做得好，自然能吸引用户。

点个爱心，再走 吧