嘉宾｜杨萍、路宁、林云
策划｜华卫
自生成式 AI 爆火以来，技术开发者便首当其冲地感受到了这股科技新浪潮的冲击。大家对其既充满期待，也不乏担忧。如今，代码助手已成为各家争相落地生成式 AI 的重点场景之一，国内的一线大厂已经开始实践。一个备受关注的问题随之而来：AI 驱动的代码研发是否会全面取代程序员的角色？对此，业界的讨论此起彼伏。
那么，AI 走上研发岗后，到底能不能代替程序员？面对 AI 代码研发的应用局限和一系列待明确的规则，谁将比程序员更先“翻车”？在日前的 InfoQ 《极客有约》X AICon 直播中，我们有幸邀请到字节跳动 Code AI 团队的技术负责人杨萍、研发效能领域的专家路宁和上海交通大学计算机科学与工程系副教授林云，一起深入探讨这些问题。
部分精彩观点如下：
生成式 AI 要达到革命性的标准，需有数量级的效率提升，但基于对现有技术局限性的理解和未来发展趋势的预测，实现可能性不大。
预计在当前和未来一段时间内，生成式 AI 的代码应用将是开发者工作流程中的重要组成部分。
无论 AI 技术还是非 AI 技术，首先应该是非侵入式的，引导用户而不是破坏他们的心流，这是编程工具的首要原则。
程序员仍然是责任的主体，需要对使用的 AI 工具生成的代码负责。
生成式 AI 对软件开发领域的最大影响之一是能够缩小不同经验水平开发者之间的差距。
从数据标注到模型训练再到软件工程改进，是未来复合型高层领导者需要掌握的能力。
以下是访谈实录，为方便阅读，我们在不改变嘉宾原意上进行了整理编辑。
完整视频可查看：
https://www.infoq.cn/video/tz4asMmNaiwWx3Gx3yp4
在 8 月 18-19 日将于上海举办的 AICon 全球人工智能开发与应用大会上，杨萍老师将出品【大模型产学研结合探索】专题，分享大模型的最新研究成果以及在不同行业的实际应用案例。林云老师也将在专题论坛上带来分享 《语言模型驱动的软件工具思考：可解释与可溯源》，路宁老师将带来演讲《大模型辅助需求代码开发》。大会演讲议题议题已 100% 上线，查看大会日程解锁更多精彩议题：https://aicon.infoq.cn/2024/shanghai/schedule
当前 AI 做代码研发的能力边界
杨萍：首先，我们将讨论 AI 在代码研发中的能力边界。生成式 AI 能否引发编程领域的生产力革命，还是仅仅是过度炒作？
我个人认为，AI 对编程领域的革命具有长期潜力，但短期内可能会有波折，甚至可能被低估。以我们团队和公司的实践为例，AI 在编程领域的主要应用是作为编程助手，特别是在代码补全方面。这一场景实际上只解决了编程任务中的一小部分。目前，像 Copilot 等编程助手已经展现出优秀的产品和能力，我们也取得了一些阶段性进展。然而，我们对生成式 AI 的期望不止于此。我们希望它不仅能在代码补全上取得突破，还能在编程的其他任务，如理解、问答等方面展现潜力。尽管短期内可能会有波折，但随着生成式 AI 在逻辑推理、数学和知识经验等方面的能力提升，我们对其长期潜力充满信心。
路宁： 关于生成式 AI 是否能够引发一场革命，我认为关键在于它能否在各个工作领域带来显著的效率提升。确实，AI 在减轻开发者负担和提高工作效率方面已经取得了一定的成果，但要达到革命性的标准，我们需要看到数量级的效率提升。历史上的蒸汽机、电力和信息革命都带来了巨大的效率飞跃，而不仅仅是小幅度的改进。
目前，尽管 AI 在某些特定任务上表现出色，如代码解释和补全，但在处理复杂或创新性任务时，其表现往往不尽人意。这些任务通常需要深入的专业知识和理解，而目前的 AI 模型在这方面的能力有限。即使未来 AI 模型的能力有所提升，我认为要实现数量级的效率提升仍然是非常困难的。因为编程和其他创造性工作本质上需要大量的私有知识，这些知识对于 AI 来说很难完全掌握和表达。尽管模型能力的提升可能会带来一定程度的改进，但要达到革命性的水平，我认为可能性不大。这种考虑基于对现有技术局限性的理解和对未来发展趋势的预测。
林云： 在讨论知识的表达和 AI 的潜力方面，我比路老师持更为乐观的态度。当前的大语言模型已经能够将大量知识压缩进模型之中，尽管模型能力还有待提升，但我认为这主要是因为知识的不足。从长远来看，编程的难点不再仅仅是算法的复杂性，而是对领域知识的深入理解。
传统机器学习方法在知识刻画和压缩方面存在不足，但随着语言模型的发展，我们已经看到海量的人类知识可以被压缩并存储在模型中。这些模型不仅能够解压这些知识，还能在此基础上进行创新。例如，Sora 技术能够创造出夏天下雪的场景，或者合成既像猫又像狗的图片，这显示了模型将离散知识连续化，并泛化出类似人类的创造力。
我认为，语言模型在知识层面为我们提供了无限的想象空间。同时，我们也面临着通用知识与专用程序之间的问题。通用知识库可能无法解决特定程序的需求，而这些需求往往存在于项目的维护库中。我们正在推进 AI 原生的软件工程，目的是构建合理的软件工程范式，让语言模型能够更好地吸收、利用和泛化现有的知识库。
从这个角度来看，我对 AI 的未来发展持乐观态度。例如，开源项目如 Linux 经过长期演化，其许多特征和功能已经固化，代码提交历史中隐含了多年的知识积累。在这种情况下，语言模型可以发挥更大的作用，帮助新手接近资深开发者的水平。语言模型生成的内容可能无法达到 100% 的准确性，特别是在产品迭代的最后阶段。我们需要一套机制，一方面从语言模型中提取和利用知识，另一方面在泛化过程中把握好最后的质量关。这涉及到知识的确认和精确性的平衡，因为想象力和泛化能力越强，精确性可能就越弱。因此，如何在保持创新的同时确保精确性，是我们课题组目前关注的两个重要方面。
杨萍：我们三位对生成式 AI 在编程领域的革命性影响有着共同之处，同时也存在不同的看法。为了更明确地探讨这一主题，我们可以在接下来的讨论中逐步深入交流。现在，让我们转向第二个问题：生成式 AI 在实际业务中的应用程度。路老师，请您首先分享您所在公司中 AI 的实际使用情况，包括它在业务中的部署方式和您是如何考虑这些问题的。
路宁： 在讨论 AI 在编程领域的应用时，AI 的使用生态非常广泛，随着人们对 AI 的熟悉度提高，工具的使用也变得多样化。例如，使用 ChatGPT 等工具已成为常态，衍生出多种不同的应用方式。代码补全是 AI 最直接的应用之一，用户无需特别学习即可适应。此外，AI 也被用于代码问答和作为搜索工具，帮助用户将问题转化为模型能够理解的形式，从而得到解答。AI Developer 等专业人士尝试从零开始生成简单的应用，无需人工干预。在测试领域，AI 的应用更为广泛，包括生成单元测试、接口测试和需求文档等。
大模型应用背后都有特定的场景和任务，推理简单或开放性的任务往往获得较好效果。简单任务容易理解，而开放任务则意味着有多种可能的解决方案，例如编写单元测试时，从不同角度编写的测试可能都是可接受的。此外，有些任务依赖的上下文较少，不需要复杂的私有知识，如单元测试。还有一些任务类似于翻译，例如将自然语言翻译成 API 调用，这些任务的效果通常较好。但这些任务大多是辅助性的分支任务，与需求分析、架构设计和代码编写等核心开发任务不同，后者的难度更大。
至于部署方式，AI 的使用情况包括直接在 IDE 或 Web 上裸用，或者将 AI 能力嵌入到现有的平台和工具中。通常，模型是远端部署的，用户通过接口与之交互。
杨萍：生成式 AI 在字节跳动的业务中主要扮演着辅助开发者的角色。我们进行了广泛的探索，特别是在帮助 PM 理解和编写 PRD 方面，利用 AI 的文档生成和续写能力，目的是简化 PRD 的编写，使其更易于理解，并与 DevOps 环节更好地结合。在编码领域，生成式 AI 的应用也非常广泛，包括代码补全和问答，这些功能在字节跳动内部有很高的覆盖率，大约 60-70% 的研发人员每天都会使用基于生成式 AI 的助手产品。预计在当前和未来一段时间内，这些应用将继续是开发者工作流程中的重要组成部分。
AI 的能力不仅连接了 PM 的 PRD 和后续的测试及运维（OPS）环节，而且在编码阶段，我们也探索了更复杂的生成式 AI 应用，例如基于 AI 的虚拟开发者，尽管其实际业务价值仍在论证中，但我们已经在结合 AI Agent 进行缺陷修复和定位的探索，并取得了一些进展。在测试领域，我们也利用生成式 AI 生成文本类的测试用例，并理解测试场景，以及生成与代码更接近的单元测试和接口测试。这些能力在不同团队中得到了不同程度的应用，并有效地提升了团队在编写测试用例和构造数据方面的效率。
对于线上运维，我们主要利用已有的生成式 AI 能力与 AI Agent 结合，进行问题定位和故障排除，以及线上问题的自愈。在生成式 AI 的部署方面，我们采取了分层策略。首先，我们会在内部部署和评估一些开源且合规的模型，并根据实际业务场景提供更高可用性的模型服务。对于有特定限制的场景，我们可能会提供更小尺寸的模型在 PC 端运行。我们也看到行业中在编程助手方面采用终端和云结合的方式来提供多种模型部署选项。
在架构服务和模型结合方面，我们看到生成式 AI 的趋势是窗口越来越长，能力越来越强，这意味着以前需要用 AI Agent 和其他框架来支撑的能力，随着模型本身能力的提升，在架构方面需要做的工作可能会减少。目前，选择技术架构和模型部署方式更多地是根据实际业务价值和场景来决定，而不是遵循统一的标准。
林云： 在研究角度，我们与字节跳动合作开发了一种 AI 辅助的代码编辑技术。这项技术主要针对的是大量现有代码的修改，而非从头编写全新代码。开发过程中，我们面临的挑战是如何交互式地帮助开发者进行代码的替换或删除。我们认为，代码生成只是简单应用，更复杂的是定位需要修改的代码位置。对于长期演化的业务，定位修改点尤为困难。编辑后的代码会产生连锁反应，需要考虑其他部分的相应修改。自动定位和生成代码，尤其是包含增、删、改的编辑，是我们要解决的关键问题。
此外，需求的描述往往不足以生成准确的代码，因为模型缺乏必要的信息。我们希望通过人的反馈来增强模型的信息量，解决编辑的自动定位、智能生成和反馈循环问题。这些研究成果已在 ISSTA'24 会议上发表。我们还尝试进行测试用例生成。传统上，测试用例被视为约束求解问题，关注分支和路径覆盖。但随着语言模型的发展，我们开始考虑需求覆盖，即测试用例本质上是特殊形式的代码，需要将需求转换为代码进行验证。测试代码和被测代码虽由不同人编写，但都基于同一需求，通过交叉验证来保证软件质量。我们目前正在使用 RAG 模型来实现需求到测试用例的翻译。
我们还在探索代码调试问题。虽然正确代码的生成很重要，但 bug 的修复方法因人而异。我们希望 AI 技术能够生成因果链，帮助开发者理解错误发生的原因，并构建从错误发生点到输出位置的路径。这样，开发者可以根据 AI 提供的因果链来决定如何修复 bug。目前，我们正致力于将调试问题转化为寻找代码执行路径中出错步骤的问题，利用语言模型构建遍历路径，以识别和解决错误。这些是我们在自动编程领域重点研究的三个场景。
杨萍：林老师刚才深入讲解了 AI 在代码相关场景中的应用。接着，我们可以探讨一个相关的问题：在实际应用中，AI 代码研发领域最受开发者欢迎或接受程度最高的功能场景是什么？
林云： 在讨论 AI 在代码研发中最受欢迎的功能场景时，我们从长期研究和用户实验中得到的最大感受是，新兴软件工具的首要任务是不干扰用户。编程本质上是一种需要心流的活动，一旦被打断，效率会大幅下降。例如，我们曾设计过一个自动编辑代码的软件，尽管我们的一键替换功能在技术上是正确的，但用户在实际使用中却因为替换过多而选择撤销修改，因为这种突然的改变太突兀，影响了他们的心流。一个好的用户体验，无论是 AI 技术还是非 AI 技术，首先应该是非侵入式的，引导用户而不是破坏他们的心流。这是编程工具的首要原则。
其次，设计 UI 和人机交互方式在赋能过程中可能比技术本身更重要。一个技术即使非常先进，准确率高达 95% 或 96%，但如果接口设计和人机交互出了问题，用户可能也不会采用。国内很多时候偏重技术，比如训练模型达到 99% 的准确率，但国外有一个庞大的社区专注于人机交互（HCI），研究如何将技术与良好的 HCI 设计结合起来。
最后，反馈是评估工具好坏的关键。AI 技术以训练模型为中心，一旦模型训练完成，AI 的工作似乎就结束了。在软件工程中，模型训练只是开始，后续的运维、数据监测、概念漂移等问题都需要持续关注。当 AI 工具开始部署后，如何在后续维护、观测、监测和调试中形成良好的闭环，对于工具的长期成功至关重要。
路宁： 在 AI 代码研发领域，有几个功能场景因其高效性和易用性而受到了广泛的欢迎和接受。首先，代码补全是一个发展较早且技术成熟的功能，它通过减少干扰的方式，使得开发者能够轻松接受并使用。其次，将大模型作为知识库使用，特别是在搜索性质的任务中，这些模型能够快速提供所需的信息，极大地方便了开发者的工作。另外，代码解释功能也是大模型擅长的领域之一。它们能够理解代码并迅速给出解释，帮助开发者更快地理解现有代码，显著减少了理解代码所需的时间。像单元测试这样上下文较少、任务相对简单的功能，因为效果显著，也受到了开发者的青睐。总的来说，受欢迎或接受度高的 AI 功能都是那些能够提供显著效果、简化任务的简单应用。
杨萍：代码补全无疑是 AI 在编程领域中最受欢迎的功能之一。它之所以受到青睐，是因为它与开发者的编码习惯高度契合，提供了一种无缝且流畅的体验。通过线上实验，我们发现不同经验水平的开发者对代码补全的触发频率有不同的偏好：初阶开发者更倾向于更频繁的补全以依赖 AI 生成代码片段，而中高级开发者则希望在需要时才触发，以避免压迫感。
除了代码补全，受欢迎程度高的 AI 功能场景也遵循研发人员的时间分配规律。研究显示，开发者大约只有 20% 的时间实际用于编写代码，其他时间可能用于搜索信息、思考问题或参与会议和文档编写。生成式 AI 和其他 AI 手段在研发领域的迭代，通过解决研发人员花费大量时间的任务或提高效率的需求，逐渐变得更受欢迎。
在字节跳动，除了代码补全，大家特别关注的是单元测试生成。由于业务迭代速度快，编写和维护单元测试对研发人员来说可能是一种负担。他们希望 AI 能够在单元测试方面提供更多支持，帮助他们更高效地迭代。
另一个常用场景是搜索和问答。开发者在日常工作中并非一直在编写代码，一个优秀的工程师每天的代码产出可能在 200 到 400 行之间。从代码补全到搜索问答，再到单元测试，如果能在这些场景中充分发挥生成式 AI 的核心能力，无论是生成代码、利用大模型存储的知识和经验进行问答搜索，还是与代码编写紧密相关的单元测试，都可能开发出更多受研发人员欢迎的 AI 应用。
杨萍：那么我们进入下一个问题：我们可以在多大程度上寄希望于 AI 代码研发？这些平台工具是否有能力的极限？
字节跳动对生成式 AI 在代码研发方面的前景抱有很高的期望。字节的业务线众多，技术栈丰富，公司特别希望能够利用生成式 AI 的能力来改善技术栈的迁移、维护，以及提高业务代码的效率。在实践中我们也发现，生成式 AI 目前的能力有明显的短板。例如，无论是通用模型还是专用领域模型，它们在理解或记忆业务上下文方面存在难度。尽管未来模型能力可能通过设计如 RAG 或 Memory 外挂功能得到提升，但目前看来，要实现质的飞跃还有一定难度。
为了弥补 AI 在这些方面的不足，字节跳动采取了服务架构和业务场景设计相结合策略。例如，在线上问题排障时，面对大量日志数据，公司会通过知识抽取、经验提取和查询来抽象和总结日志，生成更简洁的上下文。此外，字节也在扩大模型窗口方面进行工作，以便在更长的上下文窗口中发挥模型的能力。字节跳动也在提示工程方面进行了相应的工作，将现有能力与服务设计、业务场景紧密结合。除了线上排障，公司还在需求测试等领域探索与 AI 结合的实践。
我们目前仅处于利用生成式 AI 改善现有平台工具的早期阶段，随着模型能力的进一步提升，以及对平台工具本身的迭代和设计，生成式 AI 有望在开发者相关的平台工具上取得更多发展。对于 AI 的潜力，我们不设限，期待未来 AI 能在字节跳动的平台工具和研发效能方面有更多的应用落地。
路宁： 我从两个角度来讲，一个是从工程师的角度，另一个从管理者角度。
从工程师的角度来看，对 AI 代码研发的期望主要集中在两个方面：一是能够处理更多类型的任务，二是提高这些任务的执行效果。工程师希望通过 AI 来丰富任务生态，比如缺陷定位修复、日志分析、问题排障等，并且希望这些任务的执行效果能够通过不断学习和尝试来提升。这涉及到提升模型能力以及基于模型的应用能力，从而打磨这些任务。
同时，工程师也尝试利用 AI 去冲击更核心的任务，比如通过少量代码完成需求，实现设计和规划。我们会拿真实需求来利用当前最好的大模型完成，尝试减少代码编写量。通过这些尝试，工程师会发现需要补充哪些知识，如何分类这些知识，以及如何从历史数据中加工出这些知识，比如从历史代码中提取编码任务的经验知识，或从问题修复记录中提取缺陷识别的知识。
从管理者的角度来看，他们关心的是 AI 代码研发能在多大程度上降低成本和提高效率。管理者希望得到具体的数字，看到成本和效率提升的空间。然而，目前业界在这方面还难以给出明确的答案。尽管任务执行得很好，但要衡量端到端的成本降低和效率提升非常困难。整个推演过程需要学界和产业界共同努力，提升模型能力，找到不同类型任务的私有知识的更好刻画和生产方式。无论是通过 AI Agent 还是工程师自己的推理和规划，都可以逐步提升任务完成的效果。这是一个多方向努力的过程，需要从不同角度探索和提升。
林云： 如果将语言模型视为一个压缩大量知识的实体，它的潜力上限是非常高的。编程、文档编写甚至运维等领域，很多时候问题解决的快慢不在于智商差异，而在于知识量的差异。如果语言模型能够大量压缩知识，它可能让初学者无限接近专家的水平。
在实际应用中，语言模型的实用性上限会遇到瓶颈，主要有两个方面的限制。首先，语言模型基于 Transformer 架构，需要处理长上下文，而上下文的选择非常棘手。解决问题本质上是降低不确定性，也就是减熵。如果把所有任务都外包给语言模型，从能耗角度来看并不经济。例如，代码重命名任务，虽然语言模型可能识别出 90% 的重命名情况，但使用专门的重构工具可以保证 100% 的准确性。从实用角度出发，将语言模型与现有工具结合，形成一个混合模型，可能是一个发展方向。
其次，训练语言模型无法保证其学习到的代码是无缺陷的，也无法保证是最佳实践。如何选取高质量数据对语言模型进行训练，以及如何处理代码这种高频演化的材料，都是挑战。代码与自然语言不同，它需要持续更新和维护。我们正在探索如何有效分离好的实践和有缺陷的代码。例如，使用 nonparametric datastore 技术，让语言模型学习环境并维护整个代码库。这样，当代码被修复后，语言模型可以快速感知并生成更新的代码。
总结一下，语言模型在理论上具有极高的潜力，但在实际落地时面临许多挑战。一方面，我们不应完全依赖语言模型，而应结合其他技术提高效率和准确性。另一方面，对于代码这种高频演化的材料，如何将有益的知识压缩进模型，同时排除不良知识，是一个重大的工程挑战。
AI 代码研发的局限
杨萍：最近有新闻报道国外一个技术团队在使用 ChatGPT 生成代码进行开发时遇到了严重问题，这甚至导致了上万美元的业务损失。这一事件引发了关于企业是否应该限制程序员使用 AI 代码工具的讨论。两位老师如何看待这个事情？
林云： 我们不能限制程序员使用这些工具。这就像制造锅炉一样，尽管锅炉技术有爆炸的风险，但我们不能因此停止炼钢。同样，自动驾驶技术虽然有可能导致事故，但我们并不会因此放弃其发展。我们应该接受在使用新技术过程中可能产生的损失，并在经历这些之后继续向前发展。
路宁： 安全性确实是使用 AI 代码工具时需要考虑的一个重要问题。目前出现的案例中，责任归属通常非常明确：可以追溯到编写代码的个人或公司。即便不是由模型生成的代码，工程师同样可能犯错误，责任链是清晰的。这些问题并非 AI 特有的，即使在没有 AI 大模型的时代，类似的系统性问题也一直存在。因此，我认为这不应该成为阻碍技术发展的障碍。
杨萍：我的观点与两位老师相似，在考虑技术进步时，我们应关注技术发展过程中是否有足够的配套措施，如验证和堵漏技术，来确保安全性和有效性。例如，自动驾驶技术近期出现的交通事故引发了关于是否应限制技术使用的讨论。同样，AI 代码研发场景也面临类似的考量。
我认为，我们不应限制程序员使用 AI 代码工具。在字节跳动的实践中，随着使用人数的增加，AI 生成代码的比例也在提高。但重要的是，无论工具如何发展，从当前的代码补全到未来可能的项目生成，以及更多的验证工具和手段，它们都旨在使使用 AI 代码工具更安全、更流畅。但最终，程序员仍然是责任的主体，需要对使用的 AI 工具生成的代码负责 。
杨萍：下一个问题是：如何界定 AI 生成代码的版权与法律责任？
林云： 从 AI 代码的版权角度来看，遵循现有的版权法规是一个重要议题。AI 在训练过程中可能学习了受版权保护的代码，并在生成时无意中使用了这些代码。这种情况下，责任归属可能变得模糊，因为 AI 本身无法承担法律责任。类似于程序员可能访问并使用受版权保护的代码，AI 也可能生成类似的代码。我基本上同意杨老师的观点，即谁提交的代码谁负责。为了解决这一问题，可以采用版权库的检索机制来进行后续验证。如果 AI 生成的代码涉及版权问题，可以通过版权检索来识别，并采取相应的措施来解决，比如联系版权持有者或修改代码以避免侵权。
杨萍：生成式 AI 在带来生产方式变化的同时，也可能引起内容安全、算法歧视、侵犯知识产权和信息泄露等安全隐患。在 AI 代码研发中，企业应如何确保数据安全和用户隐私？
路宁： 确保数据安全和合规性是使用 AI 代码工具时必不可少的。首先，必须采取一些技术手段，例如数据匿名化、审计、对敏感数据的访问控制以及数据加密等。这些措施有助于保护数据不被未授权访问或滥用。对于企业来说，部署 AI 模型可以解决大量问题，提高效率。同时，即使企业使用 SaaS 厂商的服务，这些厂商也应遵守数据安全的要求和标准。整个行业可以建立相关的规范，甚至通过法律来约束，以确保数据安全。
需要注意的是，如果没有与模型厂商进行适当的对接，直接使用 AI 模型可能会引发不少数据安全问题。尤其是在处理大型项目时，如果模型能够访问项目代码的大部分内容，这对企业来说是一个巨大的风险。因此，需要充分应用前面提到的技术手段，以降低这些风险。
林云： 从人类文明发展角度来看，知识应当是共享的。我们之所以能够达到今天的教育水平，是因为有人愿意分享他们的思想和知识，这是从更高层次的理想主义角度来看的。当涉及到隐私和数据保护时，这主要归结为访问控制问题。这与 AI 模型训练本身关系不大，而是关乎于如何控制提供给 AI 的数据集。通过限制对数据的访问，可以在一定程度上保护数据不被滥用。但现实中，这种限制可能难以实现，因为总有人试图获取他人的知识和想法。
长远来看，分享可能比保密更好，但并非所有人愿意无偿贡献自己的知识。因此，从数据资产的角度来解决这个问题可能是一个途径。例如，如果存在一种技术，能够让人们为自己的精妙代码设定条件：每次 AI 训练使用自己的代码时支付一定费用，那么很多人会很更愿意分享，因为他们能够从中获得收益。
杨萍：在生成式 AI，特别是在代码领域的训练和应用中，确实存在不少争议。例如，有时会有原始作者发现自己精妙的代码片段被使用在模型中，而未得到适当的声明或补偿。从我个人的角度来看，企业在关注数据安全和用户隐私时，应该将这两个问题区分对待。
用户隐私主要涉及模型使用过程中的数据保护。例如，用户在使用模型时提出的私密问题，不希望这些问题成为训练数据，也不希望它们出现在他人的问题列表中。对于这类个人相关的数据，需要进行严格的过滤和保护。
对于企业来说，开发人员在职期间产生的代码通常被视为公司资产。企业需要从保护自身代码数据资产的角度出发。随着模型部署的发展，除了通用和集中使用的形式，还有私有化部署和私域数据保护策略。企业在实践过程中，会采用多种技术选项，确保能够实施不同的数据保护政策，维护数据资产的安全。
杨萍：基于以上谈到的问题和局限，那么 AI 和人类开发者的最佳合作方式是什么？当前，一个流行的比喻是将 AI 视为“副驾驶”，也就是辅助角色，而人类开发者则是“主机驾驶”，掌控主导权。这种合作方式也可能是动态变化的。AI 的能力在不断进步，它可以在不同情境下提供不同程度的协助。请两位老师谈谈自己的看法。
林云： Copilot 这个概念非常形象，它传达了一种协作驾驶的感觉，这在人机合作中是一个非常合适的比喻。它避免了“替代程序员”这样的说法，减少了人们的焦虑感，转而强调人机协作的重要性。
从知识量的角度来看，现代的大语言模型如 GPT 已经证明了其拥有超过任何个人的知识量。我们能够信任 AI 在许多行为上自主工作。但更进一步的协作方式是，AI 不仅是一个助手，而且是一个增强功能的工具，能够在编程的同时提供教育。例如，企业中资深程序员的离职可能会带来巨大的损失，因为他们的许多隐性知识往往是口头传授的。
如果能够利用语言模型学习这些编程习惯，并通过某种范式以教育的形式传授给新的程序员，这将是一个更加有效的协作方式。语言模型作为一个概率模型，可以提供知识支持，而人类开发者可以利用自己的直觉和经验进行检查。语言模型作为一个知识的载体，可以在编程过程中提供实时的、现场式的教育，帮助开发者在实践中学习和成长。这种交互式的教育过程，不仅能够提升开发者的技能，还能够传承和积累项目经验，这是一种理想的人机协作模式。
路宁：Copilot 和市面上出现的 AI Developer 工具的定位有所不同。AI Developer 更像是一个独立工作的开发者，你给出需求后，它尝试独立完成整个任务，不提供中间过程的修改机会，这种方式类似于雇佣了一个远程的开发者，但你不能在过程中进行干预和调整。协作模式的选择基本上完全取决于工具的能力。如果一个工具能够独立完成整个任务，那么与它协作的意义就不大。
目前，Copilot 所采用的模式，是因为现有的 AI 能力只能做到这个程度。但无论哪种模式，最根本的一点是，人类开发者需要负责最终的检查和验证。随着技术的发展，我们甚至可能发展出一整套丰富的检查和验证方法和体系，甚至为此开发出专门的工具。
生成式 AI 的软件开发前景
杨萍：AI 大模型的兴起正在对低代码平台造成一定冲击，未来低代码平台会彻底被生成式 AI 终结吗？
我的看法是，低代码平台不太可能被生成式 AI 终结。首先，低代码平台的出现主要是为了满足企业中 IT 人员的需求，他们希望通过不编写复杂代码的方式来搭建应用程序，执行一些搭建类的任务。低代码平台提供了一个环境，让 IT 人员可以通过拖放等简单操作来完成如网站搭建或页面展示等工作。其次，尽管 AI 大模型在生成能力和多模态理解方面取得了巨大进步，特别是在 2023 年和 2024 年，但要充分发挥这些模型的生产能力，一个重要的前提是能够精确描述我们的需求。
然而，在低代码平台的拖拽过程中，我们对自己需求的理解可能本身就是模糊的，这使得我们难以准确描述我们想要搭建的平台或页面的具体需求。利用生成式 AI 或大模型取代现有的拖拽式低代码平台，这在很大程度上取决于我们是否能够精确地描述我们的需求。基于这些考虑，低代码平台将继续存在，并不会因生成式 AI 的出现而终结。
路宁： 低代码平台通常具有非常丰富的层次和深度。它们在设计和功能封装方面非常复杂，许多 SaaS 厂商提供的低代码平台已经深入特定领域。因此，仅仅在交互层面上进行创新，是远不足以替代整个平台的。这些平台的复杂性意味着它们不太可能通过交互层的简单替代来被解决。我认为，大部分低代码平台没有被生成式 AI 替代的问题。实际上，当低代码平台引入 AI 技术后，它们的体验将变得更好，功能也将更加完善。
对于那些特别简单的低代码平台，它们可能只提供了一层非常薄的领域特定语言（DSL）来做简单的翻译工作。在这种情况下，如果 AI 模型变得足够强大，能够完成这些平台的大部分功能，那么开发这样的低代码平台并将其作为商业产品可能就变得不太现实了。
林云： 我们可以从两个方面来看待语言模型与低代码平台的结合使用。
作为任务执行的 Agent：我们可以将语言模型视为一个能够执行特定任务的智能体。例如，如果需要搜索文档或调用搜索引擎，语言模型可以完成这些任务，然后利用低代码平台的接口来生成更多的代码。这种方式下，语言模型负责处理需要智能决策或搜索的部分，而低代码平台则用于快速生成代码框架。
内容填充与定制化：低代码平台擅长生成应用的框架，而在框架生成之后，填充具体内容可以是语言模型的工作。这样，低代码平台提供了一个经过多年知识积累和验证的稳定基础，而语言模型则在这个基础上进行定制化和个性化的内容填充。
在选择使用哪种技术手段时，不应过分关注手段和形式本身，而应关注哪种手段和形式最高效，效果最好。如果语言模型能够以更高的效率提供所需的确定性，那么就应该使用语言模型。反之，如果语言模型和低代码平台结合使用能够更高效地完成任务，那么这种混合方式肯定是更佳的选择。
杨萍：生成式 AI 对软件研发和开发者的根本性影响是什么？对于从业者，特别是即将从学校走向行业的求职者，应该怎么看待和应对这些转变？
林云： 生成式 AI 对软件开发领域的最大影响之一是能够缩小不同经验水平开发者之间的差距。例如，一个拥有 10 年编程经验的资深程序员原本可能相对于只有 1 年经验的新手具有明显优势，但随着 AI 技术的应用，新手程序员借助强大的 AI 模型，其能力可能迅速提升至相当于有 5 年经验的程序员水平，从而减少了经验差距。这种技术的出现极大地解放了生产力，使得资深开发者不再拥有绝对优势，而新手开发者也能够更快地提升自己的能力。这也意味着软件开发领域的从业者需要不断提升自己的技能，以保持竞争力。
生成式 AI 还能够让人们从繁琐的代码细节中解放出来，转而更多地关注管理和战略层面的问题。随着 AI 模型承担起更多日常编程任务，开发者可以将注意力转向更深层次的思考和更广泛的业务问题。从个人发展的角度来看，AI 的辅助作用使得人们能够更自然地向管理层发展。就像过去学生时代专注于写代码，而现在作为团队领导者，需要进行更多的高层思考和决策。这种转变部分得益于团队中有其他成员处理日常琐碎任务。
路宁： 当每个工程师都拥有一个知识帮手，即 AI 模型时，他们所需的技能将会发生迁移。在这种情形下，知识变得容易获取，而关键的能力转变为如何运用这些知识解决问题。
拥有知识的 AI 模型可能在某种程度上是“懒惰”的，因为它需要工程师掌握如何驾驭它，使其成为解决问题的工具。这类似于工程师成长为架构师的过程，其中对问题分析、拆解和定义的能力要求变得更高。由于 AI 随时可以提供语言细节和常见算法的支持，工程师在这些硬性技能上的需求可能会降低。然而，工程师需要更多地发展那些偏架构师的能力，比如分析问题、规划解决方案和整体设计。他们需要变得更善于利用 AI 模型的知识库，将其转化为实际解决问题的能力。
杨萍：伴随着生成式 AI 进入到软件开发流程，过程中是否需要产生一些新的职业角色？新的角色将以什么方式加入企业呢？是在企业内部产生，还是说需要通过招聘来实现？
路宁： 总体来看，生成式 AI 的出现可能会导致一些新的角色出现，但这些变化可能并不像我们想象的那么剧烈。正如之前讨论的，AI 技术将引发技能的迁移，而这些迁移后的技能，现有的工程师们也能够掌握。
工程师的工作内容和性质可能会有所变化，但他们的核心身份仍然是工程师。他们可能需要学习一些新的专业技能，比如验证和检查 AI 生成的代码，或者掌握如何与 AI 协作的新技能。随着对 AI 工具的熟悉和掌握，工程师们将能够更有效地利用这些工具来提升自己的工作效率和质量，而不是被完全取代或转变为完全不同的角色。
林云：AI 技术的发展确实会带来一些变化，这些变化不只限于编程领域。例如，会有数据标注工程师这样的新角色已经出现，他们的工作是为模型训练提供数据，而这项工作并不要求高学历，哪怕是中专生或小学生也能参与。此外，数据外包也成为常态，例如标注用户界面元素或医疗图像等。
从简单层面来看，AI 技术可能催生一批以服务模型为主的人员，他们的工作内容相对简单，但能有效降低企业成本。例如，医学领域中，研究生也在标注 CT 图像，以支持 AI 在医疗领域的应用。从更高层次来看，未来可能会需要更多复合型人才。这些人不仅要懂软件工程，还要理解 AI 模型的工作原理，以便将 AI 技术融入到软件工程中。如果企业需要构建自己的大语言模型，那么技术领导者不仅要是架构师，还需要理解 AI 模型如何训练，从而重新设计软件工程的范式。
未来程序员的工作可能不再仅仅是代码交付，他们的编码过程本质上也是在进行数据标注，同时完成标注和交付的任务。为了训练更好的 AI 模型，人员的标注工作变得至关重要。从数据标注到模型训练再到软件工程改进，是未来复合型高层领导者需要掌握的能力。
杨萍：AI 代码研发的终极形态会是什么？未来开发者的核心竞争力体现在哪些方面？
路宁：AI 代码研发的终极形态是难以预测的，尤其是考虑到未来可能出现的 AGI（通用人工智能）。在 AGI 的影响下，我们目前所知的软件开发和组织形态可能会发生根本性的变化。目前可见的状态是，代码研发作为内容生产的一种形式，是其中较为复杂的。像音频、文案、视频等内容生产可以直接应用 AI 模型生成的结果。而代码研发则涉及更多中间步骤和隐性知识，其终极状态更加难以控制。
我们可以预见，在短期内，大部分编程任务将能够借助大模型来完成。工程师的工作将转变，他们不仅是使用工具，而是需要更深入地理解这些工具——即“相对白盒地”使用它们。工程师需要擅长驾驭他们的知识助手，与它们合作定义、规划并完成软件开发工作。
林云： 讨论 AI 代码研发的最终形态确实是一个难以预测的话题。从管理层的角度来看，软件开发往往是一个不断响应客户需求和反馈的过程。软件开发可能本质上是一个通过迭代来澄清和满足客户需求的过程。
个人认为，很多时候在没有进行实际迭代和交互之前，我们并不清楚自己真正想要的是什么。这种认识往往在实际操作和调整中逐渐明晰。例如，在低代码平台中，用户可能在拖动按钮并看到效果后，才意识到按钮应该放置在界面的哪个位置。AI 代码研发的最终形态可能不仅仅是关于技术的进步，而是更多地帮助我们理解自己真正的需求。
杨萍：AI 代码研发的终极形态是一个难以界定的概念。从我的角度来看，未来开发者的核心竞争力将包括几个关键方面。
工具使用的熟练度：目前，AI 代码研发仍处于早期阶段。对于初阶开发者来说，生成式 AI 能够快速提供之前需要众多辅助工具才能获得的知识和经验。因此，如何有效利用生成式 AI、模型本身或类似 ChatGPT 这样的工具，将成为未来开发者的一个核心竞争力。
与 AI 的动态平衡：未来，开发者将与 AI 形成一个动态平衡过程。开发者利用 AI 提升工作效率，同时，他们在工作中积累的经验和知识也将反馈给模型，以优化其性能。提供有价值的问题和反馈给模型，也是未来开发者的核心竞争力之一。
与模型的交互能力：随着模型与开发者交互的增加，无论是通过自然语言还是其他方式，如何清晰地描述问题、需求和想法，以及如何与模型有效互动，将是开发者发挥其作用的关键能力。
传统核心技能的持续重要性：除了与 AI 相关的技能外，目前定义的开发者核心技能，如编程、算法和问题解决等，仍将在很长一段时间内发挥重要作用，帮助开发者与生成式 AI 和模型更好地互动，并产出更好的结果。
对于终极形态，确实难以具体描述，因为在未来的很长一段时间里配资平台官网，我们可能需要不断思考如何与模型共存并发挥更大的作用。
文章为作者独立观点，不代表股票配资门户网观点
