大模型技术重塑智能研发新范式

在大模型诞生之后，智能开发一直被视为 AI 落地的典型场景，走在前沿的开发者也快速接受了代码推荐为主要形态的 AI 辅助编程。但在此之后，我们期望大模型可以带来更大的效率提升，甚至对开发过程进行重塑与变革，使用全新的人与机的协同关系来让开发进入“真正的智能时代”。

在 2024 年 10 月 19-21 日举办的 QCon 全球软件开发大会上，百度前端架构师、百度技术组织委员会 Web 方向负责人张立理带来了主题为“大模型技术重塑智能研发新范式”的演讲，从代码推荐到更大规模生成，从辅助到与人协同的角度，在开发工具能力发展、组织与团队引入 AI 、开发者改变开发形式这三个角度，讲述面向智能化变革面对的挑战与解决方法。

内容亮点：

• 通过 IDE 做成块、成篇的代码推荐的交互形式。

• 为了让编程现场和模型更好地结合在一起，有很多的细节与挑战。

• 把 AI 从编程这个环节，推向更广阔的 Devops 链条，并与现成平台结合让用户真正受益的案例。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

我分享的主题是《大模型技术重塑智能研发新范式》。在我看来，重塑并不是简单地将模型作为一个工具来使用，而是要让模型深入到研发的每一个环节，承担更多的功能和责任，实现真正的变革。我将从几个不同的角度来分享我对重塑的看法以及我的实践经验。

我来自百度的工程效能部，我们的主要任务是推动智能研发场景和相关产品的内部实施，比如我们的百度文心快码。在这方面，无论是我自己的使用体验还是对工具的研发，我都投入了大量的精力和积累了丰富的经验。

我将从几个视角来探讨所谓的重塑。首先，从研发工具的角度来看，自从 GitHub Copilot 大约两年半前推出以来，这一类代码助手应用经历了怎样的发展，带来了哪些变化。其次，从企业或团队的角度出发，如果我们想要将智能研发落到实处，真正提高效率，那么团队需要考虑哪些因素。最后，从开发者的角度来看，随着大模型技术的发展，我们开始接受以大模型为基础的产品，那么在此基础上，我们有哪些实践可以更好地利用这些大模型，以提升我们的开发效率。在演讲的最后，我还会进行一些总结，并对未来进行展望。

研发工具的发展

智能化的发展背景与落地诉求

我们先来探讨一下智能研发工具领域在这段时间里除了基础能力之外的发展和演变。随着大模型技术的迅速发展，早期在智能研发领域的产品，比如 GitHub Copilot，主要提供的是代码补全功能，这是一种纯粹的辅助，旨在帮助开发者在编写代码时提升速度和效率。然而，现在的工具已经不仅仅局限于这种辅助功能，它们已经从简单的补全转变为代码的生成，从辅助角色转变为与开发者协同工作，分担一部分任务，让开发者能够专注于其他部分。此外，这些工具已经从单一的代码层面进化到理解整个工程的层面，开始承担起工程层面的任务。这种转变体现在几个方面：代码生成的体量、工具承担的职责、生成的效果、提供的能力，以及最终的用户体验和交互方式。

Go Fat：更大规模的代码补全

Go Fat，是指智能研发工具在不断扩展其功能和能力。以代码续写为例，这是大家在使用这类工具时常见的功能：当你输入一行代码后，工具会显示一段灰色的幽灵文本，这是模型基于推理预测你接下来可能要编写的代码片段。你只需按下 Tab 键，这段文本就会上屏，替代你手动敲击键盘，从而提升编写效率。

传统的续写功能大多是以行为单位的，比如 JetBrains 的官方智能功能，称为 Full Line code completion，就是基于整行的补全。但以行为单位的补全与我们编写代码时的逻辑概念并不完全吻合。因此，许多工具开始尝试承担更多的代码生成任务，实现更大规模的补全。例如，快捷的代码补全可以扩展到一个分支，如果有注释作为引导，工具可以生成整个方法的逻辑代码，提供更大范围的补全，进一步提升开发效率。

在智能研发工具的发展过程中，我们不可避免地面临一个挑战：多写多错。在有限的上下文中，单行代码的准确率相当高，但随着代码行数的增加，准确率会下降。对于开发者来说，判断一行代码的正确性可能只需要 0.5 秒，但判断 10 行代码的正确性则可能 5 秒都做不完，这种复杂度的增加是非线性的。因此，在处理多行代码时，准确率变得极其重要。

智能开发产品从几个角度对准确率进行优化。首先是触发时机，并不是所有情况下都适合进行多行补全。例如，当你写了一半的代码时，补全这一行会更准确；但如果在此基础上继续补全三行，准确性就会降低。此外，如果没有上下文联系，比如只写了一个方法名“do work”，此时补全多行代码显然是不合适的，因为缺乏足够的信息，只能进行猜测。因此，大多数产品会在特殊的语法节点进行控制，比如 if、for 语句，或者在有注释、连续空行以及其他逻辑的情况下，选择最合适的多行补全时机。

其次是推理逻辑，即模型能够获取的信息，包括前文、后文、相关文件、依赖文件以及库检索等。这部分在后续的开发者个人的章节会详细描述。

模型推理时不会因换行符而停止，而是会持续推导，但这种持续推导会导致错误率增加。因此，我们需要在语法层面控制结束位置，比如在 if 块结束时停止推理。

最后是质量检查，以规避模型的一些常见错误行为，比如输出连续重复的 token 或者与光标后的代码重复的内容。通过这些检查，我们可以隐藏不合格或明显低质量的推理结果，因为这些结果不仅不会提升效率，反而会增加开发者阅读代码的负担，降低效率。

根据我们的数据，多行推理的采纳率甚至可以超过平均值。在采样数据时，平均采纳率 大约为 41%（并非最新数据），而多行推理，包括主流语言，可以达到 50% 以上。这表明，当产品和模型结合得当时，进行更大规模的补全可以取得更好的效果。

Be Rich：丰富的生成能力

Be Rich，即工具的生成能力。除了补全代码，智能工具还提供了更丰富的功能。以代码调优为例，大模型天生具备解释、分析、总结和摘要的能力，因此，当我们要求模型进行代码优化时，它在局部代码规模上的表现是相对可靠的。例如，对于一段代码，模型能够指出其中的重复部分可以提取，建议将明显的字符串转换为常量，指出违反类型安全的地方，并提供修复后的代码。这样，我们不仅在编写代码的过程中使用模型，还可以在代码已经存在的情况下，进一步通过模型进行局部重构和优化，这些能力正在逐渐落地。同时，我们通过产品校验确保优化后的代码与实际代码能够无缝合并，没有任何逻辑上的损失，从而获得最佳的代码重构和优化效果。

另一个能力是函数拆分。我们并不是简单地让模型自由地做拆分，而是针对特定场景进行特殊的模型提示词优化。以前端 React 组件拆分为例，首先，我们会从组件中提取通用逻辑作为通用函数，这些函数可以在任何地方复用。其次，组件中有一个称为 hook 的概念，这是组件特有的可复用逻辑，我们也会将其提取为独立的可复用单元。最后，我们会将一个组件拆分成多个小组件，然后将它们重新组合在一起。这是我们在日常工作中进行代码拆分的常见实践。我们作为产品开发者所做的，就是将工程师的日常经验和实践转化为模型的提示词和产品能力，沉淀到我们的产品中。这样，经验丰富的工程师的实际效果可以让更广泛的开发者受益，这远远比简单地告诉模型去拆分函数要准确得多。

Seek Deep：更深度地了解全库

Seek Deep，即更深度地了解整个代码库。过去，模型对于代码库的理解非常有限，以前它们在帮助编写代码时，主要依据的是光标前后的内容，以及中间应该写什么。然而，随着技术的进步，通过 Embedding（嵌入）和向量化等手段，我们现在可以对整个代码库进行索引和理解。

最典型的例子是分析函数的作用。以前，模型可能只能逐行解释这个函数是做什么的。但现在，有了对整个代码库的理解后，我们可以清晰地看到业务逻辑流程，这不仅仅是函数调用的流程。我们可以了解这个业务逻辑的含义，它先做什么，后做什么，以及哪些模块会使用到这个业务逻辑。这种理解类似于流程图，能够直观地展现出来，让你不仅知道一个函数的作用，还能了解这个函数在整个项目中扮演的角色。

Create By Trust：值得信赖的工作

Create By Trust 指的是创造值得信赖的工作成果。在许多情况下，模型生成的内容可能存在错误，这使得开发者对这些错误抱有一种焦虑心态。为了解决这个问题，我们可以在一些特定场景下让模型介入，例如在运行一个命令时。开发者经常会遇到命令执行出错的情况，这时可以让模型尝试修复错误。模型能够非常准确地定位到具体文件的某一行或几行，并在文件中直接修改代码。采纳模型提供的代码后，有一个明显的好处：你可以重新运行该命令，并立即看到结果。如果结果显示正确，即表示命令执行成功，这种成功与否的反馈能够给工程师带来对结果好坏的信赖感。

At Your Hand：更贴合现场的交互

At Your Hand，我们希望智能研发工具的交互更加贴合程序员的工作现场。程序员的工作现场主要是代码编辑区，而不是旁边的目录树。许多产品在侧边栏中加入了对话功能，这是一种基础形态，更多是用户想到时才去使用，而不是真正融入到工作流程中。现在，大多数产品都在推广一种称为 Inline Chat 的功能，它直接在代码编辑区内弹出对话框。在这个对话框中，你可以输入具体的代码需求，由于它是从代码区触发的，所以更倾向于直接生成代码，而不是进行解释或问答。然后，它可以直接在编辑区内写出代码，不仅可以新增代码，还可以选择一段代码进行修改。这种形态更加紧密地与工作现场结合，使焦点不需要转移，使用起来更方便、更友好、更快捷。

企业落地智能研发经验

从企业和团队的角度来看，我们希望智能化能力能够融入团队和研发流程中，以整体提升工作效率。然而，不同人对智能化工具的接受程度是有差异的。有些人能够迅速适应并认为这些工具非常有用，而有些人可能不太习惯，甚至有些人可能会抵触，因为这些工具改变了他们的工作流程和习惯，需要一个适应过程。

对于团队而言，我们追求的是更高的使用率和更好的效率提升。那么，如何实现这一目标呢？首先，模型在代码场景中具有天然的优势，几乎所有的大模型都会强调自己在代码领域的性能。代码领域的基准测试非常多，因此我们可以认为模型本身是准备好的。其次，开发者通常更容易接受先进的理念，他们一直在跟随技术变革的步伐。第三，与工程效率不同，开发效率在一定程度上是可以量化的。

基于这些认识，我们认为智能化在开发领域的落地相比其他领域更为可靠。因此从团队角度出发，我强调两件事情：第一，要让智能化工具的存在不断被所有人感知到，建立起心智模型；第二，要让大家对模型生成的效果产生信心，因为如果生成的效果经常是错误的，那么几次之后大家就不会再使用它了。为了实现这两点，我们有一些解决方案和推荐的手段。

感知存在：融合 Devops 必经链路

我们采取的第一种方法是将其融入 DevOps 的必经链路中。如果智能化工具仅存在于 IDE 编辑器里，那么它的使用权实际上掌握在最终的开发者手中，他们可以通过卸载插件或更换 IDE 来避开这些工具。因此，建立智能化工具的存在感会有一定困难。我们的思路是在 DevOps 的整个链条中寻找智能化可以嵌入的环节，比如需求查看、代码评审、测试检查、CI/CD 以及线上部署等，这些都是开发者不可避免要接触的环节。在这些环节中突出智能化工具的存在，让用户逐渐习惯于在开发过程中有模型的伴随。

为了实现这一目标，我们主要做了两件事情：智能化评审。在代码评审阶段，我们会利用模型去评审代码，使用各种技术如 RAG 和全库代码召回，建立代码之间的关联，找出潜在的漏洞，并将模型的评论发表在代码旁边，让用户决定是否采纳这些评论。如果用户认为这些评论有参考价值，他们可以选择采纳并进行修复，或者直接使用模型提供的修复方案。

我们取得的结果是，自从将代码评审集成到我们的平台上后，公司所有有效的代码评审评论中，有 20% 是由模型产生的，其中采纳率为 15%。虽然这个采纳率不是特别高，但我们已经认为这足以让大家感知到模型和智能化的存在。

我们选择了 CI/CD 流程中的一个关键环节——构建失败时的场景，来展示智能化工具的能力。几乎所有开发者在 CI/CD 流程中都会遇到构建失败的问题，而我们提供的解决方案是让模型帮助分析和解决这些问题。因此，我们在日志中出现错误的地方添加了一个入口，开发者点击后，模型会自动进行问题分析，并给出大概的解决方案。虽然这个功能不直接产生代码，主要是依靠分析和网络搜索能力来提供帮助，但它仍然能够提升开发者对智能化和模型的接受度。

通过这种方式，我们不断地训练工程师对模型的感知，最终使得大部分工程师都能接受并使用智能化工具。目前，我们内部有超过 80% 的工程师都在使用智能化工具，这是我们努力的结果。

效果信心：利用 CI/CD 确保效果

一旦大家都开始接受并使用智能化工具，工具的效果就显得尤为重要。如果效果不佳，即使开发者开始使用，最终也会放弃，因为不良的工具反而会影响他们的工作效率，这是我们不能接受的。因此，确保智能化工具的有效性和高效性是我们接下来的重点工作。

我们要建立工程师对模型生成结果的信心。模型不能确定自己生成的代码是对是错，我们也无法判断，因为项目环境和工程需求千变万化，我们不能代表实际的开发者去决定代码的对错。在开发领域，这个问题可以通过 CI/CD 来解决，因为持续集成的存在，代码可以通过编译、运行单元测试、实际运行来确定其正确性。这种反馈可以同时回到模型，让模型不断修正自己产生的结果，提高准确率。

我们最终以单元测试的形式落实了这个场景，称之为 UT Agent 单测智能体。我们的方案分为以下步骤：

首先是代码解析，确定源代码是什么，源代码中需要测试的部分是什么，与要素无关的部分先排除，因为大模型的窗口有限，我们也不想浪费资源。

其次是确定被测代码的依赖，将相关文件中的内容全部拿出来供模型参考。生成后，我们需要运行这些测试，运行结果会形成报告，报告中会显示哪些单元测试未通过。未通过的测试有两种情况：单元测试本身写错了，或者业务代码有问题。我们目前用模型来判断，但模型判断的准确性我们还在评估中。从保险的角度出发，我们假设业务代码是正确的，所有错误都是单元测试用例的错。虽然这并不完全正确，但许多工程师在编写单元测试时也是这个思路：他们的逻辑写完后，补充单元测试是为了通过测试，而不是修改代码。因此，我们让模型重新修正所有错误的测试用例，能修正的就修正，不能修正的就删除这个测试用例。

通过运行强化 2 点，第一准确性（运行错误的修复 / 删除），第二是覆盖率（提高），如果覆盖率不全面，我们通过覆盖率报告找出未覆盖的代码，然后通过提示词工程来提升覆盖率。例如，我们会对代码进行大模型解释，让模型解释代码的特殊之处，如分支、循环条件等，然后让模型在测试中覆盖这些条件。通过修复和提升覆盖率这两个子任务，生成更多的测试用例，并存储起来进行增量检查等操作，最后通过我们的用例管理器合并成最终输出。这样做的好处是，因为有了实际运行，所以结果一定是正确的。通过这样的形式，我们就能更好地建立工程师对我们的信赖感。

在我们的实验室中，我们对不同复杂度的函数进行了单元测试生成的实验。我们使用的是文心的一个较小的模型，实验结果显示，它的表现基本上超越了 3.5 和 GPT-4 模型。需要指出的是，这是在实验室条件下的结果，我们可以让它运行多轮，比如十几二十轮，以得到这样的结果。然而，在实际生产环境中，运行这么多轮是不现实的，不仅是费用问题，花费 10 分钟来生成一个单元测试，时间也是不可接受的。

因此，在生产环境中，我们的目标是确保生成的单元测试正确率是 100%，因为它能够运行，所以必然是正确的。其次，我们的行覆盖率目标是 30% 以上，目前我们大约能达到 50% 左右。再次，我们的生成速度目标是小于 30 秒，即半分钟内就能生成一个方法的单元测试，这是基于 Java 项目我们能够达到的效果。这些目标有助于建立工程师对模型生成结果的信心。

除了在编辑器中提供支持，我们还把这种能力整合到了代码评审中。当你提交代码时，模型会在后台为你生成单元测试，你不需要在本地等待运行结果，模型生成单元测试后，会在后续再次为你提交一份代码，告诉你合并这份代码后，单测覆盖率能提升到多少。这种做法在我们内部非常受欢迎，因为它减轻了工程师的心理负担，他们不需要担心单元测试的正确性，因为这些测试是能够通过的，覆盖率指标也随之提高。

开发者智能工具使用实践

作为开发者，我们拿到了这些智能开发工具，如何更有效地使用它们，以及如何将它们用得更好，我想分享一些实践经验。

首先，我想谈谈我对智能开发的总体看法。OpenAI 上个季度收购了一家专注于 AI 应用的公司，这家公司的口号是“not using AI truly with the AI”，我认为这非常符合我对 AI 的理解，即我们与 AI 的关系将逐渐从使用 AI 转变为与 AI 协同工作。

基于此，我总结了一些使用这些工具时的行为准则和实践。这些实践包括使用模型进行代码理解和检索，例如我们常说的 RAG，作为开发者，我平时是如何使用这些工具的，如何通过 RAG 来强化效果。此外，还包括知识管理，即如何管理自己的知识，以及如何与 AI 协同工作。基于这些实践，我期望作为开发者，我们能够主动拥抱智能化，与 AI 协同提升自己的生产效率，增强竞争力，并构建个人的能力壁垒。

一种全新的找代码方法

在查找代码方面，我提出了一种全新的方法。回想一下，我们传统上是如何找代码的？通常情况下，我们会根据自己的需求，大致想象一下所需代码的样子，比如是否有一个名为 getXX 的方法，然后在代码库中搜索这个代码。如果运气好，找到了相关代码，我们还需要通过查看引用、调用、定义等方法在代码中跳转，最终在大脑中理解逻辑关系，补全出我们想要的结果。

有了智能工具后，这个过程变得截然不同。首先，由于 embedding 技术的应用，大模型能够处理整个代码库的代码。其次，大模型天生具备总结和解释的能力，这使得我们可以使用自然语言去检索和理解代码。我的实践包括两点：第一，我描述的是我要寻找的功能，而不是代码的样子，我不需要想出具体的函数名或方法名，而是直接表达我的需求。第二，很多时候我检索的目的不仅是为了找到代码，而是为了确认一段逻辑，所以我需要将总结的需求也一并表达出来。

例如，如果我们要在代码库中找到一个创建应用表单的代码，而我们对这个代码库完全不熟悉，也不知道表单的确切名称，我可以直接告诉模型我们要找的是创建应用的表单。模型给出的结果是在一个目录下有两个文件，一个叫 Info，一个叫 UI ，虽然名字与创建表单没有直接关系，但它们合在一起就是真正的创建表单代码。这个过程比我用一些莫名其妙的关键词去找代码要高效、准确得多，尤其是当我对代码库不熟悉时，这种方法尤其有用。

再看另一个例子，如果我想知道一个目录下有多少个路由，即暴露了多少个 API，模型可以迅速帮我做出完整的总结，告诉我有哪些路由以及它们的位置和功能。如果我自己来做这件事，我需要逐个查看目录下的 Controller，然后在每个 Controller 中寻找方法和 Annotation，再手动记录每个 Controller 中的内容。而模型可以一步到位完成这项工作，比我自己做要高效得多。

让相关代码先走一步

要提高模型输出结果的准确性，我有一个建议，那就是让相关代码先行一步。由于大模型已经固定，我们无法对其进行微调或重新预训练，我们能做的就是优化提示词。因此，我们需要了解模型和产品在一定程度上的行为和逻辑，尤其是在代码场景中，我们不能手动编写提示词，只能编写代码。所以，了解产品是如何构建这些提示词的，就能帮助我们配合它生成更好的提示词。

有几个实践可以分享：第一，如果与 import 相关，即文件依赖，你可以先写 import 语句。第二，相关的文件可以先打开放在一边。第三，如果是在对话中，可以附加一些额外的信息。

先写 import 语句

在纯代码场景中，如果你知道文件依赖什么，可以先写 import 语句，再写代码。这时，几乎所有的智能化产品都会根据你的 import 语句去寻找，并将其中的函数签名等信息提供给模型。有了这些上下文，模型就不需要猜测方法名、参数名等，从而提高了准确性。

当我们在代码中写入 import 语句后，模型会读取被 import 的文件，找到里面所有的方法签名。假设有一个名为 getPrice 的方法，它接受一个名为 coupon 的参数（优惠券），模型就能够准确地补全代码，调用 getPrice 方法并传递一个 Coupon 参数。如果模型没有 import 语句的上下文，它可能会胡乱猜测方法名和参数，导致生成的代码不准确，甚至无法使用。因此，import 语句是一个非常重要的环节，它能帮助模型准确地理解代码的上下文，从而生成正确的代码。

打开相关文件

如果我们想在代码中写入一个 APP ID，直接让模型补全是不可能的，因为模型无法知道具体的 APP ID 是什么。但是，如果我们打开了一个包含 APP ID 的环境变量文件，模型就能够准确地复制这个值。这就是打开相关文件的作用，它能让模型访问到正确的信息。

例如在三层架构中写 Controller 时，我们知道 Controller 依赖于 Service 和 DAO。这时，你可以将 Service 和 DAO 的文件打开放在一边，不用关心它们的位置。智能化工具通常会跟踪你最近打开的文件，并从中提取一些信息给模型，这样模型就能更准确地提供 Service 的方法给 Controller。

在对话中附加额外的信息

在对话场景中，我们可以通过附加相关文件来提升模型的性能。这里有一个典型的例子：假设我要写一个前端组件，这个组件的作用是向后端发送请求，获取一个数组，并将这个数组转换成表格。如果我只把需求发给模型，而没有提供任何上下文，模型可能会返回社区中最流行的技术栈，例如使用 Axios 进行请求，用 React 编写组件，使用 useEffect 发起请求，并用几个状态管理钩子。这是最基本的做法，但实际上，业务代码往往会大量使用社区的生态系统，而不会直接使用原生的 API。

为了解决这个问题，我采取了一个简单的步骤：在相同的提示词前附加了一个文件，即 package.json。这个文件记录了我安装的所有第三方社区依赖，类似于 Java 的 pom 或 gradle 文件，或者 Python 的 requirements.txt。我只是附加了这个文件，没有做任何其他改动。模型立刻就能识别出我安装的组件库和请求库，并告诉我将使用这两个库来编写代码，结果非常准确地编写出了与我们业务技术栈相匹配的代码。

这个例子展示了仅仅通过附加一个简单的本地文件，模型的能力就能得到多大的提升。我认为这是一个非常好的实践，现在我几乎在生成与项目相关的代码时，都会不加思索地附加相关文件，它总能取得很好的效果。当然，我也可以进一步附加其他文件作为参考，比如挂载一个目录并告诉模型就在该目录下工作，但这种方法相对麻烦一些。相比之下，告诉模型依赖关系是一个更简单、更直接、更容易操作的方法。

Focus，Let AI Run The Errands

软件开发是一个复杂且精细工作。在这个过程中，你可 能会遇到各种琐碎的问题，比如忘记了正则表达式的语法、 环境变量如何获取。这些问题可能会打断你的思路，让你不 得不停下手中的工作，去打开浏览器搜索答案。此外，你还 会面临很多重复性的工作，当你修改数据表字段时，还需要 相应的更新 CRUD 逻辑，当你更新代码逻辑时，还需要更新相 应的单元测试。还有，当你实现一些复杂的功能时，除了核 心算法和逻辑，你还要考虑工程实现、边界条件、异常处理 等非常多的细节。以上这些工作，事实上由 AI 来实施，效率是高于人力的。

不需要和机械比拼力量和速度，不需要和 AI 比拼记忆和 推理，专注人最擅长的事情，将宝贵的精力聚焦在有价值、 有趣味的任务，其他琐碎与重复的劳动，交给 AI。

总结与展望

展望未来，我认为 AI 的落地与无人驾驶的发展非常相似。无人驾驶技术从 L0 级别发展到 L5 级别，而目前 AI 的发展阶段，我认为可能处于 L1 和 L2 之间，更接近 L1，L2 可能还没有达到。这个变化中最重要的一点是责任转移（Transfer of responsibility），即责任开始从人类向非人类转移。这种变化和发展是不可避免的，最终将走向无人驾驶的时代，这也是一定会到来的。

作为工程师，我们可以为这个时代的到来做好准备。我们需要更新自己的观念，并在日常工作方式和实践中做出相应的改变。这意味着我们需要适应 AI 带来的新工具和新方法，以便在未来的研发工作中保持竞争力。通过积极拥抱 AI 技术，我们可以提高工作效率，构建个人的能力壁垒，并为即将到来的 AI 时代做好准备。

嘉宾介绍：

张立理，百度前端架构师，百度技术组织委员会 Web 方向负责人。2023 年起参与百度智能开发工 具 Comate 的 IDE 端架构、模型提升等方面工作，对续写、生成、问答等软件开发环节的大模型应用有丰富经验。