导读 百度工程效能部前端经理、Comate AI IDE 的负责人——杨经纬老师分享百度智能化研发落地的实践。
今天的介绍会围绕下面五点展开：
1. 背景：智能代码助手的现状
2. 智能代码助手的发展趋势
3. 关键问题与解决方案
4. Comate 产品演示
5. 落地效果与未来展望
分享嘉宾｜杨经纬 百度 研发经理
编辑整理｜刘金辉 平台开发工程师
内容校对｜郭慧敏
出品社区｜DataFun
01
背景：智能代码助手的现状
作为一名 AI 技术爱好者，我在 PPT 制作、文案撰写及视频创作等领域均积极应用人工智能技术。当前，人工智能技术发展迅速，为生活与工作带来了诸多便利。本次分享将聚焦软件工程领域的智能化研发进展，并按逻辑顺序展开探讨。
先看一下智能代码助手的现状。用一个词概括这个行业就是太卷了。现在 AI 编码进入了一个爆发性的增长阶段。截至今年年中，整个行业的估值已经翻了十倍，甚至我认为这是一个非常保守的估计。
举个例子，Claude 的公司 Anthropic，已经成为一个巨型吸金机器，有望成为继 OpenAI 之后，第二个进入千亿市值的独角兽公司。从行业现状来看，不仅有像 Anthropic 的大模型公司进入了这个赛道，像一些创业公司，还有互联网大厂，也都在下场做这个行业。当前 AI 代码助手行业正处于快速发展阶段，尽管偶尔会有某个产品被市场认为是领先者，但整体来看，过去两三年间，行业内的变化速度非常快。比如说最开始的 Copilot，很快就被 Cursor 超越了。现在 Claude code 也有后起之秀的势头，不知道后面会发展得如何。
根据最近的分析报告，2024 年美国新增了 67 家独角兽企业，其中 25 家专注于生成式 AI 领域。大家可以看到里面占比最高的就是编程助手。
这四个编程助手的独角兽创始人，他们的平均年龄是 27 岁，都非常年轻。
有很多我们熟悉的公司，第一位创始人是 2000 年的，大家非常熟悉的 Cursor，第二位是 Magic 公司的创始人，这家公司专注于代码模型的开发，也是 00 年。97 年这个是 Devin，然后 Windsurf 96 年，Devin 刚把 Windsurf 收购了。可以看到这几个人非常年轻，而且他们四个是这些独角兽公司里面仅有的四位 95 后。
这说明了什么问题？当前生成式 AI 行业正处于技术红利期与用户需求迅猛增长的叠加期，这几个年轻人也很好地抓住了这个机会。可以看到这个行存在很大的机遇，同时也存在着很多的挑战。我们来看一下它整体的发展趋势。
02
智能代码助手的发展趋势
这是我们梳理的产品形态的变化，还有用户群体的变化。
我们知道 IDE 有编辑区、问答区。我们能够感受到用户行为模式正逐渐从编辑区向问答区发展。每个区域也有自己发展的历程。例如，在编辑区，最初的功能是补全/续写，该功能刚推出时，人们惊叹于其流式输出的新颖性，但现在感觉非常稀松平常。如今，已发展到采用超级补全功能，如 Tab 等形式。它不仅仅能够帮你预测要写的内容，也可以预测接下来要改的位置。
再往后发展就是对话部分。最开始就是简单的普通问答，我们把问题告诉模型，在对话区进行代码输出，我们再把这个代码 copy 到代码文件里。现在已经发展到了智能体的形式，它能够独立思考并拆解任务、自主执行，自动写入代码，中间不需要人的任何干预，智能体形态是当前最先进的智能研发模式之一。
此外，智能代码助手的整体形态也在发生很大的变化。最初，大家主要开发插件，随后出现了 Web IDE 和云 IDE 等形态。到后来，大家都发展出来了自己独立的 AI IDE，以及 CLI 命令行工具形态，满足不同场景的多种需求。
用户群体中，没有任何编码经验的小白，也可以跨越技术障碍，将注意力从代码细节转移到实际需求上，即他们的目标和任务所在。除了代码小白，我观察到行业里现在一些专业研发也在尝试 web coding 实践。他们会尝试将任务分解成可控的单元，并亲自参与前后环节的定制工作，以串联整个端到端的流程。我最近发现行业里确实涌现出来了非常多的独立开发者，因此，这一趋势值得我们高度关注。它可能会引发未来研发模式的颠覆性变革。
03
关键问题与解决方案
1. 智能代码助手面临的关键问题
再来看一下，在做智能代码助手建设时我们面临的关键问题。首当其冲的是代码准确率。不管是阶段还是功能，用户最关心的就是准确性，你推荐给我的到底有没有用。我们针对代码准确性这一关键问题，投入了大量工作，包括数据工程、上下文理解、工具链调用等，这些待会会和大家详细分享。
另外我们的 Comate 是行业里支持端最多的产品，所以对应的研发成本也在上升，因此我们建设了多端复用能力。另外除了 coding 阶段，也要把 AI 带来的效率提升覆盖到 DevOps 研发全流程。
2. 代码推荐准确率提升
接下来，我将围绕这三个关键问题展开，首先探讨代码准确率，将其自下而上划分为三个层次。最核心的就是模型层，模型基本上决定了产品的上限能力。针对此，我们做了很多数据工程相关的工作。中间层是研发现场，主要关注上下文工程。再往下就是提示词、工具，代表的能力就是智能体。
3. 模型训练
接下来，我们来看模型训练部分，我们与文心团队共同构建了一个专门的代码模型。模型训练部分的工作主要是由文心团队来做的，目前阶段模型训练的 80% 的工作集中在数据工程环节。里面包括了数据生产、数据清洗、数据标注。
我们来看一下在这个环节是怎样做的。首先是数据源，很多同学都会比较好奇我们的训练数据是从哪儿来拿的？下面是一些典型场景。
每个不同的数据源有对应适合训练的场景。比如说百度内部的企业代码里包含丰富的实际业务落地的代码。所以它很适合在续写补全的业务场景里进行训练。在社区论坛中，人们会提出问题，并得到许多回答，尤其是那些高质量的社区。这块的数据适合做一些问答的训练，再包括官方文档、开源代码，这些都是常见的训练数据来源。
4. 数据生产-数据源&数据格式
再看一下数据格式，我们主要用的是 SFT 还有 DPO。SFT 通常是由一对输入和输出组成的 source target 的模式。举个例子，比如说续写一般是填空的模式，那它的 source 输入就是前后的代码，输出就是中间需要补全的那一块。DPO 的数据格式和它是不同的，通常是由一个输入对和对应偏好标签组成。它一般适用于有输出的偏好，或者需要排序的任务。
在续写场景中，基于 SFT 的方法有时会遇到问题，如无法正常截断或输出过长，都不符合预期。这时，我们会使用 DPO 进一步增强效果。比如说我给出一个输入过长的、一个正好的，再给它标记一下哪个是更偏好的，用这种形式提升数据的准确性。
5. 数据生产
数据生产我们采用了基于代码解析、基于大模型、基于人类反馈三种方式。
基于代码解析过程基本分四个环节。首先选择代码库，一般我们都会选择高质量代码库，如集团内优秀代码库与开源高星代码库。然后进行解析，解析过程中，我们将其抽象为 AST 语法树，用以标记代码的具体含义。这个后面具体说明 AST 语法树长什么样子。
通过这个语法树，我们可以把 source target 识别和提取出来，在提取的时候，也要注意保证数据的完整性。比如在提取单测数据的时候，除了被测代码，还有生成的测试代码，我们也要把被测函数的参数提取出来，确保上下文的完整性。基于代码解析，我们能够解决大部分问题。但是有一些比较特殊的垂直场景可能缺少数据，所以有时候也会基于大模型生产一些数据，也分为四步。第一步就是选择高质量的大模型，比如说像 Claude 模型，构造一些 source 数据。这些 source 数据就是我们输入的数据，一般也是从实际的业务代码来的。然后再去定义生成任务，就是设计 prompt 提示词。设计好了之后，通过模型再去生成对应的 target 数据，最终组成多个 source target 的训练数据。
在 AI 大模型的生产数据过程中，我们通常不能期望一次就成功。因此，建议先进行小规模的测试，选取几百条数据进行评估。只有当这些数据经过 review 的准确度达到比如 98% 以上时，才可考虑大规模生产。如果达不到，我们还需要反复调试 prompt。另外此能力上线后，也希望得到一些用户实际的使用反馈，从而帮助提升模型的效果。这就是第三种方式--基于人类反馈。
这里面需要强调的是，我们用的基本上是厂内的数据，厂外的数据是不会收集的。这一块数据格式就是用 DPO 的格式。举个例子，我们在给用户推荐续写数据时用户采纳了推荐代码，但用户采纳后一分钟内又进行了修改，那么这次修改后的内容应被视为需要记录的正例样本，而原先推荐的内容则被视为负例样本。用这种 DPO 的格式交给模型，形成一个大模型的数据飞轮。就可以让我们的模型越用越精确。
这个即为刚才提及的 AST 语法树，左侧展示源代码，中间是抽象后的语法树。比如说第一排抽象的是注释语句，去标记注释语句在几行几列。然后按照这个格式提取出来，提取成我们想要的 source target 模式。
6. 数据清洗
生产完数据之后，我们需要对这些数据进行处理。包括对冗余数据进行去重，把低质数据过滤。同时，对于涉及个人隐私数据，我们也进行妥善处理。这个数据清洗是行业的通用做法，就不具体介绍了。
7. 数据标注
有一些模型处理标准比较高，就需要进一步的数据标注。我们可以用模型标注，也可以用人工标注。我们定义好任务，选择合适的模型配置参数，设定任务提示词，基于这个提示词对数据进行标注。
人工标注的成本一般比较高。所以模型标注可以作为人工标注的前置环节。我们把一些简单的模型，易处理的任务先交给模型，然后再让人工标注。人工标注时，标注人员需充分理解标注标准，确保一致性，否则所得数据可能与预期存在差异。另外对标注人员的能力也会有一些要求，有很多任务在实际标注时是要求在某一个级别以上的同学参与的。
8. 数据工程落地实践
刚才所述即为数据工程处理的流程，整个过程繁琐且复杂。在此过程中，若自行操作，可能会遇到优化路径不明及生产流程搭建繁琐等问题。针对这些问题，我们在集团内部给大家提供了 Comate Stack 这样的 AI 原生应用研发的一系列的工具，这里面包括了 prompt 工程、数据工程，还有效果评估。
，时长00:58
比如说数据标注，之前我们在标注代码的时候，是用 excel 标注的，也没有高亮，格式也很混乱，标注过程艰难。有了这个数据标注平台之后，标注效果提升了。我们只需要填写标注任务，然后再在这个界面上会有每一条要标注的数据，下方会提供具体操作选项，如标注下一条数据或跳过等，用户操作非常便捷。而且我们提供了很多的标注模板，方式也比较灵活和多样。
9. 数据评估
，时长00:49
下面是数据评估，我们可以通过模型进行自动评估。这里面要填任务名称，以及需要评估的模型和数据集。把这些东西都填完了之后，提交模型就可以帮助我们自动进行评估。
最后会形成一个评估报告，它支持多模型对比，还有在线筛选、对比等非常丰富的能力。整体在数据工程上形成了一套标准的工程化能力。
10. 上下文理解
接下来看一下研发现场的上下文工程。上下文工程这个概念最近比较火，以往我们也会去探索一些相关的内容，但是之前探索的是单点，比如说像系统 prompt、RAG 等。现在对于上下文工程其实有了更加全面和结构化的定义。在这里列出的，不仅仅是向大模型发送的单一提示，而是模型在返回响应前所接收到的全部内容。这里面就包含了非常丰富的内容。比如像系统指令的提示，包括示例和规则，然后还有用户的提示词。
我认为，当前行业内对用户提示（prompt）的撰写越来越重视，其实对应着我们以往传统软件工程里提需求、做技术设计等前置环节。如果你提得很粗糙，一句话需求，那出不来什么好的效果。因此，我们应该提出足够详细和全面的要求，尽量控制好力度。
还有就是检索信息以及工具，包括我们系统的内置工具、MCP 连接的工具，还有定义的结构化输出。
上下文引擎的一个关键能力是信息检索，即我们能否通过检索引擎从庞大的上下文中精准提取所需内容，这是非常关键的。我们在做检索引擎的时候，从 RAG 到以 Graph RAG 为代表的组合检索方式，一直到现在的专属模型。
模型在回答问题时，会首先从我的外挂知识库中检索相关信息，并将这些信息提供给模型，从而使模型能够更精准地回答问题。如果没有的话，可能就会有一定的缺失。此方法的优势在于能够外挂知识库，相比以往的SFT模型，成本更低，周期更短。但是它也有一些问题，因为它是先进行切片 Embedding 再进行检索的。因此，当涉及代码间的关联性或全局性问题时，它无法处理。另外就是我们的知识库体积越大，检索的效果就会明显地下降。随后，我们探索了一系列检索方式，包括关键字检索、向量检索，以及重点介绍的知识图谱检索。
针对关联性的问题，它的原理就是我们把代码显化成实体。它的关联性像这个图一样，通过这种方式，对实体间的关联性理解会更强，而且可解释性更强，可以追溯推理。它适合哪一些场景呢？比如说我要升级当前项目中身份验证的服务，哪些模块会受到影响？或者在解释函数时，通过生成时序图来辅助理解。这种带有实体关联的方式，能够更深入地帮助理解，并生成层次更丰富、内容更详实的时序图。然而，它也存在问题，即实体间的关联如何确立，需要我们预先处理，从而增加了一定的成本。所以本质上依赖于大量的结构化数据，要以高成本去换高精度。另外就是动态的更新也容易引发数据的不一致。
再下一个阶段就是检索效果最好的专属模型。这条路线很多厂商也都在尝试。这里面比较典型的，Windsurf 号称说用这种方式召回，是传统 Embedding 系统的三倍，它的原理就是短时间内通过模型的大量算力去直接处理这个代码的文本，消除 Embedding 带来的误报。例如，在需要高精度检索的场景中，如精确地定位需要修改的代码段，使用大模型进行文本索引和查询是十分适用的。然而，这种模型的使用成本较高，因为它需要大量的算力来换取精度。因此，在决定是否采用这种模型时，必须仔细评估其成本效益。此外，这个专属模型的效果受到一定技术壁垒的限制，因此需要进一步的技术突破。
11. 提示词工具
接下来是提示词与工具典型案例，即新一代研发智能体 Zulu。它的特点是能够自主拆解任务、分布解决问题，并在 IDE 中直接编辑文件等。整体的流程就是拿到用户需求之后，把系统提示词检索、召回上下文、项目环境的这些信息给到模型。模型在拆解的任务中，每一步都会调用不同的预置系统工具，在 IDE 中进行处理，处理完成后即完成任务。
这里面重点探索的技术之一就是系统提示词，其实就是 prompt。别看它听起来很简单，但是实际上不同模型的 prompt 是不一样的。最复杂的 prompt 至少能达到几千行，所以它是一个结构化的提示词工程。
我们一般把它分成四个块。一个是人格设定，就是智能体是谁，我的性格偏好是什么样的。第二部分就是行动约束，比如说我要遵循一定的格式规范，或者在什么范围之内能做哪些事情，能够调用哪些工具。
第三部分就是目标设定，这里面包括了行为流程，这个流程并非预设的、一成不变的步骤序列，如固定的第一步、第二步等，而是用自然语言的方式去描述出来整体行动的原则。比如说我需要先去收集大量的信息，然后再去做任务的拆解，用这种方式去设定行为流程的框架，也会去做一些细节的纠正。例如，在实际应用时，我们经常会遇到用户的一些不良案例（bad case）。这些 bad case 其实跟他的动作偏好相关。因此，我们需要在提示词中增加指导语，如请勿如此操作、请按如下方式执行等。
第四部分就是最重要的动态信息，就是用户现场输入的一些信息。这个动态信息一般会放在最后，静态内容在前去符合这个 Transformer 的结构，而且对缓存是非常友好的。我们可以把前面的这些静态信息放在缓存里节省成本。
这里面我们也总结了一些经验。比如说在格式方面，一般来说都是用 xml 格式的， markdown 也有但是很少。这两种用于结构化提示词的效果比较好。另外像 Deepseek 不建议用单独的 system 消息，需要用 user 消息。再比如说 system prompt，它的语言并不重要，用中文和英文的效果都差不多。
12. 工具链-使用工具自动化完成任务
接下来就是我们怎样使用工具自动化完成任务，这个整体的流程跟刚才有点类似，就是用户发起请求，然后智能体进行任务流程推理。在这个过程中就会调用一系列的工具，工具一般分为三类，信息收集、代码编辑，系统交互。需要注意的是，这些工具其实是有数量限制的。现在一般把它控制在 20 个以内，不然模型在调用的时候会混乱，调用的准确性会明显地降低。例如，cursor 在调用系统工具和 MCP 工具时，产品上存在 40 个工具的限制，这是当前模型技术需要突破的一点。
在调用完工具之后，Agent 会检查结果进行验证。如果验证失败了，他会去重新进行反思，重新规划任务。有一个反复验证、重新规划的流程，最终完成任务。在这里面我们也会给他设定一定的规则。刚才说的要优先去收集信息，然后鼓励他一次计划多个任务。另外，在阅读方面我们可以更加积极。以上提到的部分是关于提高准确性的。
13. 多端支持
接下来看一下在多端支持方面我们做了哪些工作。我们支持的端是行业内最丰富的，包括 VS Code、Visual Studio、Eclipse、Xcode 等，还有独立的 AI IDE。每个插件背后其实都对应着起码两三个人。研发和对齐成本会直线上升。所以我们做了一个中间的复用层，通过 Kernel 制定了大部分的业务逻辑，基于 LSP 去完成跨端的通信。Webview 就是用 web 技术去实现的 UI 层，也就是像侧边栏的界面复用，就是用的 Webview 层。通过这种复用方式，我们已经实现了多端的 85% 以上的复用。很多的能力只要中间层写完之后，其他端验证一下就可以上线。
我们之前的 Xcode 插件开发速度相对较慢。使用了中间层之后，一个人用 1 个月的时间就追平了之前半年的开发的进度。用这种方式，多端的研发进展效率还有能力的一致性都得到了比较好的保障。
14. 研发全流程智能化建设
接下来是研发全流程的智能化建设。我们最早在行业里面推出开放平台，与实际业务紧密结合，沉淀了大量共建能力。现在 MCP 和 Agent 出来了之后，这个方向也在朝着去往 MCP 的形式转化，然后和 Agent 相结合，可以让业务做一些自定义的智能体，还有多智能体协同这样的模式。我认为，随着 Agent 的发展，将会涌现更多专项和自定义 Agent，为业务提供更优质的个性化定制效果。这里面大家看到的是已经和业务共建沉淀的一些能力。
15. 典型场景 F2C：设计稿一键转码
举一个例子，F2C 就是我们和厂内团队一块共建的。他们以往有一个 F2C 的传统方式，从 Figma 的设计图能够像素级的去还原页面，形成高还原度的代码。这个还原度在行业内也是比较顶尖的，水平能达到 90% 以上。但存在一个问题，即与当前项目代码的适配度不佳。所以我们把他的这项能力拿到了 Comate 的研发当中。因为 Comate 研发现场自然地就有用户的开发的上下文，用户的代码环境等等。把这些结合起来，即将原有的 Comate 技术与新开发的 Image to Code 技术相结合，汲取两者的优势。形成了既能够像素级去还原页面，又能够高适配工程代码的能力。
16. 范式变革
在整体的流程上面，我们再把 Agent 融入整个研发全流程的工具流。在概念上面，我们把它叫作数字员工，希望为每一个研发者配备一个专业的数字团队，这里面包括像编码数字员工、单测数字员工、测试数字员工等等。
以我们实际的流水线举例。在此流程中，我们可以看到名为帝霸哥的工具，它负责调试环节。帝霸哥就是在调试环节发现一些错误，它能够帮你自动地去解决这个错误。此外，它可以查看详细情况，了解其具体工作原理，这就是修复完成去执行验证的过程，最终查看结果，如果符合预期就采纳，采纳之后我们也可以给它进行自动化的提交，这就是数字员工的案例。
我们旨在将数字员工无缝融入现有的研发流程，确保用户能够便捷使用。我们在实践中发现，在业务原有的路径上面融入我们的工具，大家的接受程度会比较高。
04
Comate 产品演示
接下来，我们将展示 AI IDE 产品。
六月底，我们刚发布了 AI IDE，作为 AI 时代工程师的工作台，它解决了众多场景中的实际问题。例如，在编辑区，我们提供了超级补全功能，支持结对编程。同时，智能体的引入实现了人与 AI 的分工协作，助力端到端的开发流程。在连接扩展这块，我们提供了 MCP 开放平台等能力，帮助你连接更多不同业务的工具能力，让你在开发的时候能够连接万物。技术沉淀与经验传承一直是团队管理中的痛点。为此，我们提供了自定义规则和 prompt，以便大家更好地沉淀经验。
还有就是我们提供了一些心流体验的能力。比如说把对话和编界区结合起来，还有刚才提到的 Figma2Code，以及元素级调试，这里面这几个标黄的会给大家演示一下。
1. 智能体 Zulu
，时长00:29
第一个是智能体，我要创建一个设计师作品展示的网站，大家对此应该已有所了解。目前的流程主要是拆解任务，进行多文件编辑。左侧可以看到实时的输出，就像有人在进行代码编辑一样。多个文件编辑完成之后，我们可以进行预览，一个非常美观的页面就出现了。
2. MCP
，时长00:46
这是 MCP 的能力，它允许我们与众多外部工具进行连接，实现我们想要尝试的各种功能。它与 GitHub 和 SQLite 进行连接。我会查看 GitHub 上的项目，选择第一个进行尝试。之后，Zulu 用 MCP 访问 SQLite，查看数据库中的具体信息。获取信息后，辅助他完成编码任务。更新文件后，让工程师进行审查，他表示满意，随后提交 PR。通过 GitHub 的 MCP 进行提交，整个流程顺利完成。MCP 让模型的能力没有边界，我们可以灵活地连接万物。
3. 规则
，时长00:23
在规则这一部分，我们可以把团队的一些实际规则定义出来。这里包含了项目架构、代码规范、测试规范，以及我们在过程中期望固化的流程等，所有这些都被整合在其中。我们可以看到定义完规则之后，生成的代码就是按这个规则来实现的。例如，在开发过程中，我们应当为每个代码模块生成单元测试，并确保测试覆盖率和准确率达到行业标准，以确保代码质量。下面就是跑完单测的结果。
4. Figma 转代码
，时长00:35
然后就是刚才提到的 Figma 转代码，我们可以在 Figma 里面把链接贴过来让它进行生成，首先从 Figma 形成结构化的代码，然后生成高还原度。接着，利用 Image to Code 技术，对现有项目进行适配，以确保生成代码的高可用性。最后就可以看到最终的还原度是非常高的。在我们业务的实际共建当中，还原度也是受到多个业务认可的。
5. 界面修改
，时长00:43
最后一个要演示的就是界面修改，我们在生成一些前端页面的时候内置了一个浏览器。你可以在 IDE 里面看到当前的页面。如果对这个页面的某一部分不满意，需要针对这一块做定制化的需求。用户可以轻松地使用鼠标选中所需内容，并将其拖放至编辑区，随即内容便会在此处展现。这样的话模型识别的会更加精准，再用自然语言进行调整，效果也会更好。比如说这里我想加一个目录，目录里边包括首页、文档，还要做一些适配，就可以用这种方式去做。执行完毕后，系统将自动生成目录，且该目录能够根据不同屏幕尺寸进行自适应调整。
05
落地效果与展望
1. 落地效果
在行业内部，我们已经获得了不少认可，我们的 AI 代码生成工具在集团内部的使用占比也达到了 43%。
2. 赋能千行百业，加速行业发展
另外我们跟多个行业的标杆企业也达成了长期合作。我们希望通过智能代码助手这种方式，帮助不同的行业和公司加速创新和发展。
3. 内容总结
总结而言，我们最初探讨了智能代码助手领域的发展趋势，以及当前面临的技术挑战。包括准确性的提升、多端的建设，还有研发全流程的提效。然后演示了产品核心能力，展示落地的效果。
4. 经验总结与展望
在研发智能研发的过程中，我最大的感触就是还是要和用户站在一起，以用户的角度去考虑问题，实践出真知。从实践当中我们可以汲取非常多的经验来反哺我们，在产品上面去做更好的决策。最后就是我们的官网公众号，还有我个人的小红书。今天分享的内容就是这些，感谢大家的聆听。
06
问答环节
Q1：库的插件是自己开发的，还是调 MCP 服务生成的界面元素。
A1：我们是跟集团内部团队合作的，有一套自研的方式，是我们自己开发的。
我们自己会做一些控件的识别，循环组件这种特殊的处理识别。一般行业内通用的功能，我们都有的。而且最近我看他们也开放了 MCP 的能力。或许与我们的一些方向相吻合。
Q2：能否实现全量页面生成以及是否支持增量的 UI 修改。
A2：如果修改的话，还是建议用刚才演示的那种调试的模式。现在还是一个完整的设计图，然后去生成代码。
Q3：AI 生成的代码的采纳率占比 43% 是指发布到线上的代码比例，还是指提交代码的比例。
A3：我们最早在做 Comate 项目是 22 年，刚开始做的时候就面临公司的灵魂拷问，就是这个东西价值到底是什么？用什么指标来衡量它的价值？
当时我们定义了两个关键指标：一个是采纳率，这是一个技术指标，表示生成的量中被采纳的比例，它反映了准确性，但并非结果指标；另一个是代码生成占比。代码生成占比其实也面临了一些统计的问题。目前我们的定义是：通过采纳量计算留存率，再除以入库量，以此近似估算入库代码中 AI 生成的比例，尽管这不是完全准确，但与真实数据相差不大。
另外其实它跟完全准确差不多。因为我们中间又加了一个留存率的概念，就是说我生成一大段之后，有没有修改，修改了多少，最后有多少被留下，这个就会让准确率明显地提升。这是这样的一个指标，然后也是我们回答公司灵魂拷问的第一个指标。
43% 的代码由 AI 完成，这究竟意味着什么？对于百度来讲代表着什么？其实还有另一个指标，就是说我们最终看的结果是人均需求交付量，就是一个人在单位时间内他能完成多少需求，百度内部人均需求交付量自实施以来提升了 20%，即每位工程师的工作效率提高了 20%。
以上就是本次分享的内容，谢谢大家。
