在百度工作一年半成功升职，这位AI程序员分享了这些晋升秘籍。

据了解，文心快码已经参与了超过27%的代码，协助了超过80%的工程师。

在最近的云智大会上，它又get了新的技能——代码架构解释和代码审查。

衡量自动化编程的关键指标是什么？理想态AI编程产品的实现技术路径会是什么？AI编程产品的PMF将会在什么时候出现？

新火种「365行AI落地方案」邀请到了百度智能云技术委员会主席孙珂博士，我们一起聊了聊文心快码最近的新升级，编程自动化时代距离我们还有多远。

亮点概述现在，大家下班后可以将代码交给大模型来批量审查，第二天上班时再针对修正建议进行修改，提升了效率和质量。我们更关注的是在每千行代码里，到底有多少代码是被大模型处理过的。现在的应用形态分为两种大趋势：一种趋势是指助手或Copilot的逻辑，程序最终的运行和交付由程序员来主导的；另一种趋势就是像代码解释器这种，整个程序的最终运行和交付是由大模型自己主导的。我更期待什么时候能够出来一款由大模型完全主导的、自动化生成的、能够稳定运行并且实用化、商业化的应用。我认为这款应用将代表诞生了第一个实现PMF的产品。可能未来有一天，我们只需要一个对话框告诉网站接下来要干什么事情，大模型就能生成按钮出来，点一下，这个任务就完成了。…

（以下内容根据直播对话整理）

与其开会，不如直接让大模型来审查代码

新火种：前段时间，云智大会上看到文心快码有两个能力的升级：一个是代码架构解释，一个是代码审查。请先为我们介绍一下这两个功能，以及如何赋能企业开发工作流的呢？

百度孙珂：文心快码的定位，就是赋能企业程序员开发的全工作流程。从这个出发点去看，我们能注意到程序员的日常工作状态下，并不是完全在Coding（编程）。实际上在工作流的开始，比如新进一个项目组，或者刚开始启动项目时，需要对项目的代码架构，有个整体性的理解。

我本人也是干了快20年的程序员，特别不喜欢突然接手了别人几万行或者几十万行的代码，这种需要一点点地对着PRD和注释来梳理整个代码的逻辑脉络。我过去觉得干这个事情还挺痛苦的。

在大模型出现后，我们注意到大模型能够帮助阅读代码、帮写注释等等。除了写代码，我们是不是可以考虑让大模型更早期地参与项目，让大模型快速地把代码架构梳理出来。相信在企业客户里会有非常多程序员，面临着和我类似的痛苦经历。我们就是基于这样的考虑，提供了第一个升级点——代码架构解读。

另一个升级点，就是代码审查。这也是我们日常开发标准化流程的一部分，很常见也很重要，叫做Code Review。程序员在前期开发、调试完代码后，在正式发布前，会邀请到公司里的资深程序员组成评审小组，来审查最终完成的代码，检查代码是否合乎规范等等，主要目的就是提升代码质量。

在我们和企业研发负责人的沟通中发现，这个非常常见的研发环节，在研发流程中靠后，而且需要耗费很多精力去完成。同时我们也注意到，大模型其实还挺擅长干这件事的。它可以直接阅读企业内部的开发规范，再基于规范审核代码，审核后还可以标注出违反规定的地方、提出修正建议。

现在可以有这样的解决方法：大家下班后将代码交给大模型来批量审查，第二天上班时再针对修正建议进行修改，提升了效率和质量。

新火种：那么文心快码是否已经在百度内部，或者其他服务的企业中，实现了怎么样的效率提升呢？

百度孙珂：百度是一个拥有大量程序员和研发工作的公司。我们这款产品的前瞻功能，都会优先在百度内部用起来。

其实文心快码在百度内部，已经推广了快两年的时间。现在超过27%的代码都是由文心快码生成或者辅助撰写的，百度内部有超过80%的工程师都在使用文心快码。在百度内部，这也是非常强的提效工具，能够把全局的研发效率提升10%以上。

除此之外，像喜马拉雅也在使用文心快码。文心快码辅助他们程序员开发的代码，大概占了公司总体新增代码的三分之一。而且对工程师的覆盖率也很高，差不多有90%。所以可以看到，文心快码对于程序员coding密集型的公司，是一个很有效果的提效神器。

新火种：现在有更多开发者和我们反馈说，在日常工作流中已经在使用大模型来提高开发效率了。之前也有第三方机构调查说，可能五年之后，使用AI代码助手的工程师能达到75%。您觉得现在AI编程的发展，对开发者的能力提出了什么样的新要求呢？

百度孙珂：这是个很有意思的问题。大模型技术在做的，就是把我们从日常繁琐的工作中逐步解放出来。比如代码助手可以帮你读代码、写代码、审代码等等，也能写注释、写单元测试，这些都是每一个程序员的基础能力。我认为大模型会逐渐替代这些工作。

还有像被称为固定手势的，比如非常熟练地啪一下写出好几行的for循环。这些重复敲几百上千次的指令，大模型如果能逐渐帮我们省略掉，还是很值得期待的。所以大模型对于程序员来说，主要还是减负的效果。

在我看来，未来程序员更重要的能力是偏架构性的。也对应着高级别程序员的头衔，架构师。

这意味着基础的工作逐渐被大模型节省掉，那么程序员可以花更多精力在更精髓的点上，比如这个程序架构如何设计，如何安排函数之间的互相调用关系，如何拆分功能等等这一系列更有决定性意义的工作。这也是对未来程序员能力的要求。

新火种：我们看到文心快码从去年入职百度AI程序员，过了一年后晋升为了AI架构师，这个职级的升级，百度是怎么定义的呢？

百度孙珂：我们内部对工程师的要求是，架构师要能处理一些更宏观的任务，比如跨文件、跨项目的任务。我们对文心快码的定义也是类似的。

文心快码一开始，也是仅仅处理当前页面、某段代码的续写，就像是一个普通的小RD一样，每天只是帮忙续写敲代码。再往后，随着大模型能力的提升，我们可以让文心快码帮我们驾驭更多项目级文件间的依赖关系。

文心快码在处理任务时，不仅仅在看当前页面，也能看到项目甚至公司里所有相关知识和文件的依赖。你会发现它越来越像个架构师了。

新火种：相当于文心快码集成了整个企业私域的知识，然后去处理一些项目级任务。

百度孙珂：是的。这也是我们这次很重要的升级，文心快码增强了对企业知识整体的阅读和使用能力。你会发现当把文心快码这样的产品放到企业中应用时，会让你的代码生成得更得心应手，而且贴合企业的使用习惯。

新火种：在产品升级上，会更多围绕企业的需求，还是依赖现在大语言模型的能力呢？这两者的优先级是什么样的？

百度孙珂：说实话，我们做决定的时候，更多还是考量客户的诉求。

之前很多客户反馈说，代码辅助的工具很好，但是写出来的东西和自己企业的知识库或者已有开发出来的东西关系不大。这意味着把面向公共的代码辅助产品推广到企业内部使用的时候，需要结合企业已有的代码知识库，包括像接口之类的结合。

新火种：是不是可以说，这种要让企业用起来的定位，是文心快码的优势和独特性？

百度孙珂：我们对于文心快码的定位很简单，就是期望企业能把它很好地用起来。包括我本人就是RD出身，一般想东西都很朴素，就是希望把能最直接立刻帮到我们的功能，提供给企业客户。我们也确实看到了，能够结合企业的知识、企业的研发流程，以及未来更多与研发工程师深度结合的功能，会是我们产品相比较有优势的地方。

新火种：结合咱们的经验，您认为应该怎样打造定位为企业级的编程产品呢？

百度孙珂：首先要定义清楚边界。我们的产品不会面向过多的角色拓展功能，比如暂时不会涉及过多产品经理相关的PRD等功能。主要还是聚焦于RD这个工种上，顺着RD的研发工作流去规划我们的功能，从项目创建、研发、调试、到测试等每个环节上都要实现部署。当然实际实现上会有先后顺序和技术成熟的问题。

我们现在的一个基本判断是，现在文心快码还是定位在偏辅助形态的工具，我们会在每个研发环节上挖掘对程序员有价值的功能，希望能让工程师能立刻用起来。我们也在努力探索的另一个方向是，未来还会更加面向自动化的项目创建和编程。

新火种：现在文心快码已经从AI程序员升级到AI架构师了，那接下来有可能担任什么样的职位呢？

百度孙珂：这个架构师的职位已经是很高了（笑）。再往上走可能没办法给他更高的头衔了，不然就是CTO了。

但是在功能上它会有更多的变化。比如从续写升级到代码的辅助生成能力，能够把大模型结果和程序员正在写的代码结合起来。在审查能力上，我们也会去做更多的事，除了代码规范，还有安全性的检测等。

更近一些的升级，是我们还会增强单元测试等测试环节的能力，未来一到两个月就会发布。

所以接下来可能不是用架构师来形容，而是可以称为全栈工程师，能够从前到后都解决很多问题。这是我们的预期。

关键指标是大模型生成代码的渗透率

新火种：我们也看到咱们未来的计划有，实现直接从文字到应用这样端到端的生成。现在端到端也是很重要的一个趋势，不知道这个会是什么时候实现呢？

百度孙珂：没错。大模型就是大语言生成式模型，我们能看到的主流的大模型应用方法或者生成方向，都是用大模型直接生成文字，这也是C端产品比较主流的使用方式。你还可以用大模型去做任务上的规划，或者生成一系列跟代码相关的内容。这个过程中也衍生了非常多的应用形态，包括刚才提到的所谓从文字生成应用这种端到端的方式，也有现在我们正在聊的代码助手。

还有一种，是大模型现在具备的代码解释器的能力。它的运作方式是先让大模型生成一段代码，更进一步把代码的运行包裹到解决方案里；不仅生成代码，还把代码放到运行环境里运行，再返回结果。这步执行后，有时候直接返回结果，有时候还会利用大模型的反思和调试能力，进一步修正结果。

这意味着，你可以看到现在的应用形态分为两种大趋势：一种趋势是指助手或Copilot的逻辑，程序最终的运行和交付还是由程序员来主导的；另一种趋势就是像代码解释器这种类型，整个程序的最终运行和交付是由大模型自己主导的。

这两种趋势之间很有意思的区别是，程序员主导的可以写一些正式的商业化程序，需要保证稳定性、规模和整体架构的可控性。而纯粹由大模型主导生成的程序，生成一个较小的应用是没问题的，效果比较稳定的话大概是50-100行代码的应用。

那么我认为，这两种趋势会逐渐向同一个方向靠拢。也就是说，程序员主导的助手类应用可能会从提供一两行的代码，到推荐一整个函数，让程序员能够无脑确认并稳定运行。大模型主导的应用则会写越来越多的代码，在这个过程中保证去生成一个更复杂的、端到端的任务，让程序自动运行。未来有一天也许两种方式会达到交汇。

我看到不少创业项目，已经在尝试这种交汇的方式。但走这条路，需要尝试解决很多规划性问题，来保证整个程序、整个结构的规划稳定，还要做大量的反思动作。实际上往前走的每一步，可能都要花费数倍于之前的token去解决相关问题。

按照第一种趋势，产品需要设计跟用户深度交互的能力，在交互过程中收集用户的真实反馈和人类的checking行为，帮助大模型把越来越复杂的代码生成能力进一步优化。而第二种趋势，会是一种很好的探索产品形态的路径。

我更期待的，是什么时候能够出来一款由大模型完全主导的、自动化生成的、能够稳定运行并且实用化、商业化的应用。我认为这款应用将代表诞生了第一个实现PMF的产品，从这个时间点开始后续产品的发展会加速。

这款产品也许最长不过三年的时间就会出现，我对它的形态有很多的畅想，我们也想看有没有机会先做一款出来。到了那一步以后，有了用户验证和商业化的反馈，产品就能够高效地进行深度迭代，也能够极大激发这个方向快速地成长。

可能未来有一天，我们的网站上不需要按钮，也不需要提前写什么功能，我们只需要一个对话框告诉网站接下来要干什么事情，大模型就能生成按钮出来，点一下，这个任务就完成了。我还是挺期待这样的一天的。（笑）

新火种：Karpathy曾经提到说自动化编程也可以像自动驾驶划分为L1到L4的发展阶段。您是如何看待代码生成的L1到L4的阶段的呢？

百度孙珂：我心中有一个L2，也有一个L4，但我没有划分中间的L3。我认同我们一定能走到 L4，而且甚至觉得这一天不会太遥远。

这和刚才提到的一样。程序员主导的产品需要解决数据收集的问题，通过很好的产品设计和产品交互来收集人的行为，特别是要收集到人类解决问题中的判断。大模型主导的产品，就是按理想态做端到端的产品形态，对模型进行深度打磨，这就非常需要前面收集到的数据。所以两条路需要同时往前走，而且缺一不可。

就像现在的自动驾驶，所有新能源车上都装备的是L2，但已经有正在研发的L4了，L2可以反哺L4的技术的。我们也很期待两条路合拢的时候，也许意味着真的到了解放双手的时候。

新火种：文心快码的团队也是两条路线并行吗，还是有更加注重的一条路线？

百度孙珂：百度作为一家非常AI导向的公司，我们肯定是要去做很多潜在的技术布局的。同时，我们也在致力于去把这些技术能够快速的落地，交付到所有用户手上。所以，可以认为两条路它一定是会都存在的，而且我们永远不缺乏向前探索的、聪明的工程师正在日夜奋战，往那个理想路径上前进。

新火种：现在市面上已经有很多的编程产品，您觉得现在有什么比较关键的指标可以用来评估这些产品？

百度孙珂：这是一个很好的话题。业内现在大家比较常用的，也是对编程辅助这类产品的普遍认知，更多的是停留在“我光标到这了，开始给你写”。所以一个非常通行且常用的指标就是写出来后采不采纳，我们称之为采纳率。这个指标我们也会用，并且也在努力对其进行优化。

但我作为一个做了多年策略的人，会觉得这个指标不太能完整地衡量我们对整个研发过程的提效。所以，我们也做了很多其他的指标，会根据不同的功能，有各种各样的指标逻辑，当然也会很琐碎。

我们还在做一个端到端的指标衡量。我们注意到，程序员不管怎么写代码，最终都会有一个check in的动作，也就是提交代码。现在我们衡量的是，在单位时间里，程序员生成的代码数量是否有提升，以及在单位时间内，程序员每千行代码里有多大比例是由机器生成或修正的。

这个数据意味着大模型在多大程度上，把它的能力渗透到了程序员开发过程的方方面面。所以，我们更关注的是在每千行代码里，到底有多少代码是被大模型触碰过的。

新火种：有没有一个理想的数值，比如大模型渗透到百分之多少，能代表这个能力是有效的？

百度孙珂：其实每渗透一点进去，都能满足我的预期。像刚才说到，百度有百分之二三十的代码已经由大模型生成了，这可以认为是我的基线。短期一到两年内，我们会认为百分之50到70的比例，是一个不错的水平。

但在我心目中，我认为这个比例越高越好。也许未来的所有的代码实现，都是由大模型生成的，程序员只需要把需求提供给大模型就OK了。所以这个比例在我心中是没有上限的。

保证企业和个人用户的体验一致很重要

新火种：企业的程序员和个人开发者，对于文心快码的关注点和需求是否有什么不同吗？

百度孙珂：这是一个很有意思的问题。其实我刚才提的指标，基本上都是企业比较关心的事。

对于个人程序员，其实并不会真的仔细衡量自己的效率，他们更像是日常的C端用户，更关心的是功能好不好用、能不能用。比如某个功能的点击路径是否足够少，能不能用最简洁的方式操作，像有些程序员会有很极客的执念，比如我规定自己写程序不能动鼠标，一定要保证双手都在键盘上，只用快捷键解决问题。

用户实际上关心的是每个功能是否能更高效，用更少的点击和更少的操作达到解决问题的目的。他们也许不会把研发环节定义得这么细致，但他们每天都在处理类似的事情。他们能够用大模型处理每天事情中的八、九成，也许最后每一个操作都有大模型在辅助，我认为这基本就是个人程序员用户最期望得到的了。

新火种：如何平衡满足个人程序员和企业程序员之间不同的需求呢？

百度孙珂：文心快码有两个版本，一个是面向公有云的，在公域通过baidu.com可直接搜索到并免费下载使用，高级功能也有一些限免策略；另一个是面向企业的，会提供相关售卖服务以及企业部署。

个人和企业用户的差异点，实际上就是大家到底在关心什么问题。在企业内部，需要更多地深度结合企业知识，关注与企业相关规范、研发流程等的深度结合和挂钩。

对于公有云版本的个人用户，他们更关心能否快速获取开源网站上的示例代码并适配到自己的程序中，以及是否可以在文心快码框架内解决编程过程中遇到的问题。

我们还可以看到一个诉求差异，就是代码语种的分布不同。比如企业中java等语言使用更多，公域里除了java外，对python等AI相关的语言，也有更多的诉求。但其实两者没有冲突。

如果能同时满足两者的需求，那么当企业的程序员摘掉工牌在家做自己喜欢的事情时，就可能成为公有云用户。整体体验的一致性是很重要的。

新火种：在面向企业端的时候，是否有构建企业生态这方面的相应措施？

百度孙珂：我们是期待有更多企业参与到整个服务生态中。有的交付企业会希望自己将文心快码与自身企业内部做深度整合，要求我们只保留服务端、插件端等，其他的重新根据他们自身ID重新打造一套。对于这些诉求，我们都是会通过企业生态的方式来构建和推广。

比如我们会给生态企业提供只有后端服务能力、没有插件的版本和接口，相关插件代码及向外推广的服务都可以由生态企业来完成。此外，我们还有更灵活的版本，将产品封装成一体机形态，也交由生态企业对外推广和售卖。

我们也有面向程序员教育的生态建设。要知道，中国有700-800万正式程序员，还有近十倍的在学程序的人。我们会与很多教育机构合作。面对这群用户，我们会有一些不同之处，比如不仅帮他们续写代码或理解项目，还会提供调试bug等辅助能力。这是我们大致的生态构建情况。

新火种：最后您还有没有补充分享给我们观众的呢？

百度孙珂：今天聊的很开心。整体就是想和大家聊一聊文心快码这款产品，从商业化到具体功能实现，以及未来的发展规划等。我们产品的迭代速度还是蛮快的，接下来一到两个月内将有两个版本的大升级，无论是效果还是功能都会有大幅度提升，会让大家很惊喜。希望大家可以多多关注。

关于365行AI落地方案

AI技术的落地应用不仅限于科技领域，它已经渗透到各行各业，成为推动产业升级的重要力量。因此，“365行AI落地方案”主题策划应运而生，我们寻找各行各业中成功应用AI技术的案例和方案，分享给更多的产业内人士。