揭秘CodeBuddy：黄广民讲述腾讯风格产品的诞生之路

最近这一周，AI编程产品的出现简直是层出不穷。

在7月22日，腾讯也终于推出了他们的AI编程工具：CodeBuddy IDE。

在众多类似产品中，CodeBuddy的独特之处在于：它希望用户能通过自然的对话，完成从想法构思到设计再到开发和部署的整个流程，而不仅仅是自动生成代码，或者只关注前端展示和原型设计。

作为互联网领域实力雄厚的腾讯，他们在如今竞争激烈的AI编程市场推出的产品到底如何呢？CodeBuddy真的能实现从产品设计到代码实施的全流程吗？CodeBuddy跟Cursor之间又有哪些不同？更重要的是，随着技术的不断进步，AI编程是否会改变大厂的人才结构呢？

在深入体验了CodeBuddy之后，我们发现这个产品确实不简单，另外我们还有幸与腾讯云的开发者产品总监、CodeBuddy的负责人黄广民聊了一聊，探讨一下这款产品背后的腾讯思考。

实测CodeBuddy：真的像拥有一个完整的产品团队吗？

首先，我们来仔细看看CodeBuddy这个工具。

打开CodeBuddy，最明显的区别就是它的工具栏设计：

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

打开界面后还有一个小机器人陪着你，非常有趣。

我们尝试从零开始创建一个项目，来感受一下它的功能。

我们的提问非常简单明了：“我想做一个AI编程工具，主要功能是‘一句话生成一个网站’。”

CodeBuddy并不会立刻给出代码，而是先提供一些选项，帮助我们更清晰地表达需求。就好比老板想要一个网站，成熟的员工不会直接发个链接，而是会先搞清楚老板的具体想法。CodeBuddy也问了我们一些问题，比如项目的目标用户是谁、网站是商业用途还是个人博客、有没有特定的技术框架等。

CodeBuddy：让你的项目从头到尾有条不紊

要想清楚需求，CodeBuddy会先问你一系列问题，这样才能帮你理清思路。就像公司老板想要一个网站，成熟的员工不会直接丢个链接，而是会先搞明白老板心里想的是什么。通过这些问题，CodeBuddy能够为你打造出一套完整的预开发方案框架。

这套方案包括了诸如产品实施路线图、最小可行产品功能清单、原型结构、技术架构和UI设计等内容。你可以想象成一个专业团队在帮你规划，事无大小都一一列出，真是细致入微。

不过，大部分的AI编程工具到这里就结束了。但是，CodeBuddy可不一样，它能和腾讯云无缝对接，轻松一键把文档上传到云端。这样一来，枯燥的文档就能变得生动，通过网页展示出来，实现了协作，用户可以通过链接分享这些需求文档给其他人。

接下来，我们来具体看看CodeBuddy生成的最小可行产品（MVP）计划。这个计划可不是简单的文档堆砌，而是对产品战略的清晰表达。它的框架分成六大模块：项目概述、目标受众、MVP核心功能、技术架构、MVP开发阶段和业务指标。这种条理清晰的逻辑，甚至超越了很多刚入行的小白，简直不逊色于一些新手产品经理。

基于对AI生成方案的信任，虽然我们作为技术小白也没什么选择，但我们还是决定全盘采纳CodeBuddy的MVP框架。

而且，CodeBuddy还有一个让人惊喜的地方，就是它的设计能力。以前AI编程的流程是确认需求后，把功能架构交给像Lovable这样的原型设计工具。你可能会想，为什么不直接交给Cursor呢？因为Cursor在这方面不太行。

但CodeBuddy在原型设计上提供了多种解决方案。其中一个特别亮眼的功能就是它能够接入Figma这款原型设计工具。换句话说，设计师在Figma中完成的页面可以直接交给CodeBuddy，实现像素级的生成。同时，CodeBuddy也为小白用户考虑周到，它能够识别用户上传的图片，简直就像把“草图变成网站”。

我们选择了一个任务，就是对Lovable的界面进行“逆向工程”。我们把Lovable的页面截图上传给CodeBuddy，来看看它的设计能力。

在实际测试中，CodeBuddy成功继承了页面的风格，比如主色调、字体和卡片的阴影等。同时，Lovable的一些关键文本元素，比如“Community”和“Pricing”等，也实现了像素级的复现。不过，导航栏等部分的响应逻辑还是有一些偏差。

大体的原型已经有了，接下来就让CodeBuddy根据生成的网页和MVP计划，进一步完善这个项目。

在这个过程中，我们顺便测试了一下CodeBuddy的提示优化功能，看看效果如何。

让产品想法变得清晰可行的CodeBuddy

很多刚入行的小白知道自己心里想要的产品，但一旦要用逻辑清晰的语言表达出来，就会觉得很难。这时候，CodeBuddy的提示优化功能就显得特别重要。你会发现，CodeBuddy能准确理解原文，并且在优化后逻辑变得非常明了。

它把我们那句简单的话，拆分成五个步骤，涵盖了业务逻辑、用户体验和后端性能等多个方面，真的是很全面。

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

在项目开发正式启动之前，CodeBuddy会对整个项目进行系统化的规划，涉及项目分析、技术选型、设计优化和任务拆分等多个环节。我们可以通过查看CodeBuddy的官方案例来进一步理解它的工作流程。

你会看到，CodeBuddy首先分析项目的产品需求文档，抓住核心功能，然后确认技术架构，比如前端和后端使用什么语言。同时，它还会明确项目的设计风格、页面布局和交互方式，最后生成一个详细的计划，让用户清楚知道接下来要做什么。

这不就是一个集产品经理、设计师、程序员和项目经理于一身的高效团队吗？

此外，使用过Cursor的用户应该对它的索引和文档功能印象深刻。简单来说，Cursor在执行任务前会先读取项目的所有文件，从而提升编程辅助效果。而CodeBuddy则把这一功能直接融入到了项目执行过程中：

它会自动逐一读取文件，这样用户在执行前就不需要手动确认了。

等待之后，CodeBuddy会提供一份清晰的报告，说明自己完成了哪些任务，确保用户知道它并没有偷懒。

最后，让我们看看CodeBuddy全程生成的项目示例，真的是“一句话就能生成一个网站”。

轻松生成网站原型，CodeBuddy来帮忙！

整体看，这个网站原型还算完整呢。首页的设计基本上是根据我们上传的图片而来的，有个输入框和一些建议。而下方则是网站功能的介绍，甚至还有模拟的用户评价。你知道吗？当我们在输入框里填写需求时，系统会自动弹出一个工作页面，左边是不同主题和网站类型的选择，右边则可以实时预览，甚至还有发布功能哦。

现在我们要进行第一次的版本升级，我们可以通过截图来修改页面。比如我们把页面某个部分截图发给CodeBuddy，让他来删除。结果CodeBuddy工作得非常迅速，效果也不错。此外，CodeBuddy还可以直接修改项目的UI元素。在预览模式下，用户可以一目了然地选择需要调整的部分。

对这个项目感兴趣的朋友可以看看这个链接：
https://github.com/ddlpmj/CodeBuddyTest.git。

CodeBuddy：让创意与代码无缝连接，改变研发模式

项目的框架已经搭建好了，接下来我们会接入编程大模型，增加一个预览窗口。到目前为止，我们其实能够清楚地看出CodeBuddy与Cursor等AI编程工具的不同之处，主要体现在编程以外的方面，比如产品文档的设计、开发规划、技术架构以及提示词的优化等等，这些都是Cursor所缺乏的，而这些恰恰是新手和大型复杂项目所急需的。

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

这只是我们在测试过程中发现的一个实例，经过多次测试后，我们对CodeBuddy产生了浓厚的兴趣，因此也和黄广民聊了聊他的思考过程。

以下是我们对话的内容。

从内部辅助工具到对外的AI IDE产品

硅星人：能和我们分享一下CodeBuddy背后的开发故事吗？这期间经历了哪些重要节点呢？

黄广民：

我们的AI辅助编程工具项目从2023年初开始的。当时我们看到GPT对生产力的影响，再加上受到海外Copilot的启发，就决定开发一个辅助编程工具。最开始，我们部门和工蜂团队各自工作了3到4个月，后来经过沟通整合，资源、需求和代码全部共享，既服务于腾讯内部，也面向外部，那时团队才十几个人。

到2023年底和2024年初的时候，能明显感受到这个工具在提升生产力方面的效果。当时的代码生成率大约是20%，但内部用户反响非常好，所以在2024年初我们加大了投入，优化模型，增强端侧能力，并调整补全策略。

2024年5月，这款工具在公司内部应用得不错，我们决定对外发布，帮助更多企业提升效率，于是当月正式发布了。

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

硅星人：在你们的测试和用户案例中，有没有什么让你印象深刻的作品？

黄广民：

有一个外科医生开发的健康管理软件让我印象深刻。这个用户想用我们的插件来制作一个健康管理软件，通过输入体检数据，快速识别问题并提供健康建议。但在开发过程中遇到了一些障碍，比如在小程序中读取Excel数据时遇到了困难。我和他一起用Prompt工程的方法解决了这个问题，把数据转换成JSON格式，再用数据渲染页面，这样问题就解决了。

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

#小程序://智算助手/GzOydzMnEFjQbhj

硅星人：医生作为高知识群体，在使用AI编程工具时，有什么优势和劣势呢？

黄广民：

优势非常明显，他们对业务的理解非常深刻，知道应用要实现什么，这是他们的强项。不过，他们在工程训练上有所不足。他们往往不知道如何精确提问，常常把比较原始的想法直接告诉AI，这样生成的内容就没有严格的约束，技术方案也跟不上他们的想法。而且，他们的需求往往很大，如果模型没有好好拆解，生成效果就会差。后来我跟他交流时，分享了一些工程最佳实践，告诉他在做项目时得先拆解需求，再让CodeBuddy来实现子任务，这样才能更精准地满足业务需求。

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

硅星人：在我体验你们产品的过程中，发现很多功能都很有意思，比如你们把“设计模式”和“计划模式”分开，而其他类似产品（比如Cursor）更倾向于一体化交互。这种设计考虑了哪些因素呢？

黄广民：

我们将设计模式和计划模式分开，主要有两个方面的考虑：首先，传统研发过程本身就分阶段，而不同角色的需求各有侧重。比如Cursor主要面向开发者，而没有兼顾产品经理、设计师等角色的使用体验。但我们的产品希望覆盖所有相关角色——产品经理需要编写需求文档，设计师需要用自然语言生成设计图，这些都是他们的高频需求。将这些高频需求作为独立功能存在，能更好地满足各个角色的使用需求，这样的设计是合理的。

说到这两个模式的作用，其实它们是为后续的编码阶段提供了一种规范和约束。要是没有这些前期的规约，生成的代码简直就像“开盲盒”，你得花不少时间去调整，结果很可能就是白白浪费时间。所以呢，提前明确这些规约，给下游的代码生成设定一些强制性的约束，能够让生成的代码更符合需求，成功率也会大大提高。

硅星人：在使用过程中，我注意到相较于Cursor，CodeBuddy缺少了indexing和docs选项，这功能对我来说挺关键的，因为每次启动项目前我都得确认indexing的阅读率是百分之百。CodeBuddy是怎么在执行项目前处理所有文件的，这两者之间有什么权衡呢？

黄广民：

关于indexing功能的设计，我们其实考虑了多方面的因素。我们曾尝试过两种Codebase Induction方案。第一种是在本地对代码仓库进行嵌入，利用语义搜索来召回内容，但效果不太理想；第二种是改用远程服务，结果依然没有达到我们的预期。

问题的关键在于，单纯的索引搜索只能召回相关内容，却无法搞清楚这些内容之间的依赖关系。实际上，项目中的文件和类型之间有着密切的依赖关系。语义召回的内容往往是零散的、片段化的，模型也很难通过这些内容真正理解整个项目。因此，我们决定采用一种更接近人类理解项目的方式：就像开发者在面对一个陌生的项目时，首先会查看目录结构，找到关键文件，再进行深入理解。CodeBuddy现在的做法也是这样。虽然这种方式看起来有点“笨”，但效果却更好。大项目可能会花些时间在前期理解上，但这些时间是值得的——如果在理解不到位的情况下贸然修改，后期的调整成本会远远超过前期的理解时间。

硅星人：在AI编程模式下，CodeBuddy有Ask和Craft这两种模式，而Cursor还多了manual和background模式。你们为什么选择这样的设计？我觉得Cursor的background模式虽然还在Beta阶段，但你觉得它有必要吗？

黄广民：

在模式设计方面，我们目前主要集中在这两种模式上，主要是因为manual模式已经成为过渡产品。在agent模式推出之前，manual模式是主流，但随着模型的进步，agent模式能够更好地帮助用户实现目标——人机交互大幅减少，用户只需最后确认代码的采纳即可，因此manual模式的用户逐渐减少，自然不需要再保留。

至于background模式（即任务由模型完全完成，无需人工干预，只关注结果），它本质上是人机交互从多到少的演变，但目前还处于Beta阶段，因此我们尚未推出。原因有两个：一是用户使用门槛较高；二是它主要面向专业开发者，但又存在矛盾——插件提供了AI操作的UI，但并不在本地运行（本地已经有代码仓库和环境），而是在后端沙箱中运行代码，这让人觉得有些多余，不太符合大多数用户的使用场景。

不过，background模式在某些集成场景中可能会成为未来的趋势：例如，用户提交代码后，沙箱中的CRAgent会拉取代码，完成审核、修复甚至合并，然后把结果反馈给开发者，这更接近L4和L5阶段的高级形态。

核心在于如何用更少的步骤解决用户的问题。

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

黄广民：

我们考虑到现在主流的设计工具都以Figma为主，因此当然要支持它。不过，在整合的过程中挑战可不小，特别是与Figma的对接，最大的难题就是如何实现设计稿的一比一还原。

Figma的开发者模式可以生成CSS和HTML样式，但如果依赖AI生成，就很容易丢失关键信息，导致还原度根本无法满足生产要求。因此，我们进行了大量优化，结合规则转换与AI调整，现在已经能够达到95%以上的还原度了。

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

黄广民：

毫无疑问，用户对AI生成代码的容忍迭代次数是AI工具的一个重要指标。

根据我们的后端数据，用户完成单个任务的平均轮次大约在10次左右，大家的容忍度大概在20到30次之间。我们也在不断努力平衡迭代次数，关键就是思考如何用更少的步骤来解决用户的问题。内部我们会持续进行基准测试，比较不同IDE和不同Agent在相同任务下的消耗成本、迭代轮次和完成时间，不断优化这些指标。

硅星人：大家都在关注AI编程与模型之间的关系，普遍存在一个“误解”，认为最终能力完全依赖于模型，其实这中间还有许多工程挑战，解决这些挑战也是AI编程类产品的一大竞争点。CodeBuddy在这方面做了哪些努力呢？

黄广民：

对，目前模型在推理能力和上下文窗口上存在限制，因此在工程层面的优化显得尤为重要。

让代码生成更简单，CodeBuddy的创新之路

以代码补全为例，这可是大家经常用到的功能，对速度的要求可是相当高的哦——如果反应时间超过600-800毫秒，用户可能会心急，索性自己动手写了。因此，在补全的场景中，我们会选择小巧的模型，目标就是要“又快又准”。当然，输入的上下文不能过长，但必须要足够包含关键信息，比如待补全代码的前后内容、需要的头文件、方法签名以及语法树等，这些都需要在工程中精确提取，这样才能确保模型一次就能补对。

像CodeBuddy的Craft Agent也面临类似的上下文限制问题。为了解决这个，我们的策略是让Agent快速查找相关的上下文，对之前的交互进行总结，然后把这些总结作为“二次上下文”反馈给模型。这样就能避免重复操作，减轻模型和用户的负担。归根结底，这些优化都是为了在模型限制的情况下，用更少的步骤和更高的效率来解决问题，符合用户对迭代次数和响应速度的期待，这也是我们一直通过Benchmark对比进行优化的核心方向。

说到底，丰富的互动和漂亮的页面设计，都不如生成的效果来得重要！

硅星人：现在AI编程的竞争，最大的焦点就是“快”。我们了解到Cursor也在不断地进行功能迭代，但这类产品还处于早期阶段，这意味着可以做的事情还有很多。那么，CodeBuddy现在的开发优先级是什么呢？是迭代速度？产品的交付质量？还是新的创新功能？你们背后的思路是怎样的呢？

黄广民：在AI应用中，最关键的无疑是解决生成效果的问题。如果生成效果不够好，就算再多的互动和视觉上的优化，用户也不会满意。

因此，我们的开发优先级首先是提升生成效果，通过优化来进一步提高开发效率，这是我们的核心关注点。

另外，数据显示开发人员在开发过程中的时间分配中，实际用于开发的时间只有大约37%，其余的时间都花在了沟通上。

所以我们也在思考，如何大幅度缩短这部分时间，具体来说，就是在整个研发周期中，想方设法消除不必要的浪费，这也是我们重点关注的方向。

硅星人：在Cursor有优势的情况下，CodeBuddy目前更侧重吸引什么类型的新用户呢？是专业程序员、产品经理/设计师，还是完全的小白？或者你们对这些简单的分类有不同的看法？

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

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

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

总的来说，我们的理念是“逐步向上游扩展”，针对不同群体的核心需求进行推广，让每个用户都能感受到产品的价值。

硅星人：现在市场上比较流行的AI编程工具，大致可以分为Lovable和Cursor两种类型，前者偏向生成原型，后者偏向编程。CodeBuddy的口号是“设计和开发实时融合”，是不是可以理解为在做一个类似Lovable和Cursor结合的产品呢？

黄广民：从用户场景来看，Lovable和Cursor的用户群体其实都是我们的目标用户。虽然这两者的聚焦点不同，但我们的产品希望能将它们的功能和工作环节更好地串联起来——从一个想法的形成，到设计落地，再到最终的代码生成，以及后续的部署、分享和运行，形成一个完整的闭环。

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

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

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

未来开发的趋势：AI工具让每个人都能参与

硅星人：最近大家都在聊腾讯内部是不是在用CodeBuddy，这款工具被多少项目利用呢？有没有什么量化的数据可以分享？还有，你在开发过程中，AI的参与程度大概占到多少？有没有特别印象深刻的经历？

黄广民：

在腾讯，我们内部的开发人员中，有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工具的市场还像一片蓝海，各个公司都在不同的方向进行探索，这其实很不错——大家一起努力把这个领域做热闹，尚未进入“争夺市场”的阶段，竞争指标也没有明确到谁能称王称霸。未来很可能会出现多种类型的AI Coding工具，分别满足不同用户的需求、适应各自的开发流程和角色，帮助他们更高效地完成核心工作。

说到国外的情况也是如此，最开始是Copilot，然后又有了Cursor和Claude等一系列工具，吸引了很多用户，至今没有哪款产品能完全垄断市场。这类工具的根本目的是帮助用户实现他们的业务目标，用户的粘性并不能仅靠数据或社交关系来维持，最关键的还是产品的使用体验和生成效果——如果做得好，自然会吸引用户的青睐。