aiXcoder总裁刘德欣：1.0时代没有真正解决企业领域知识问题

科技日新月异的今天，以大模型、Agent等为代表的人工智能技术正引领各行各业的深刻变革。软件开发领域，一场由AI驱动的产业智能化升级快速演变，进入智能化软件开发2.0时代。

近日，我们采访了硅心科技(以下简称：aiXcoder)总裁刘德欣，主要围绕企业如何落地领域化大模型，如何更好地拥抱智能化软件开发2.0时代等话题进行深入探讨。以下内容根据采访实录整理。

1.0时代没有真正解决企业领域知识问题

没有充分考虑真实开发场景的复杂需求

ENI:请刘总简单介绍下智能化软件开发1.0时代及其发展现状?

智能化软件开发1.0时代可以说是通过引入大模型技术，集中实现了软件开发的一些初级自动化场景，包括代码生成、代码补全、单元测试生成和缺陷检测等。系统也支持基本的需求捕获和拆分等任务。但是，这些功能通常是以独立的方式执行，不能深入理解和应用企业特定的业务逻辑。

目前国内外的玩家主要有GitHub的Copilot、Amazon的CodeWhisperer、百度的comate 、阿里的通义灵码、甚至包括我们aiXcoder的上一代产品等。各家产品在功能和能力上差异并不大，缺乏明显的差异化。尽管产品在宣传中，强调了具有更强的上下文理解能力和更大的参数量，甚至与GPT-3.5等模型进行比较占据优势，但实际上并没有真正解决大模型与企业领域知识融合的核心问题，使得它们无法满足企业基于自身的业务落地大模型的需求，简单来讲，觉得大模型学不会自己企业的领域知识，幻觉和生成结果不确定性严重;而这种孤立性和对业务逻辑的理解不足，也导致了其产品对软件开发复杂需求的处理浮于表面，实际上代码输出的准确性和实用性往往会大打折扣，限制了其在实际企业业务环境中的应用效果和用户的信任度。

ENI: 您认为智能化软件开发1.0时代具体存在的问题有哪些？

刘德欣:智能化软件开发1.0存在的问题主要问题是不进行有效个性化训练而直接落地大模型，这会直接产生两大缺陷：应用模式缺陷和技术缺陷。

首先，从应用模式来看，主要缺陷表现在两个方面。

第一，在训练层面，缺乏对业务原始需求与设计的考量。1.0时代的产品往往只关注代码本身的语法和结构，忽略了代码必须服务于具体的业务需求和逻辑，所以并没有将需求分析和设计文档等企业背景知识融合进模型的训练中，导致生成/补全的代码往往缺乏业务逻辑，从而使产品的准确性和可用性不足。

第二，在测试层面，无法形成需求到测试的闭环。测试自动化在1.0时代通常只基于现有代码进行，忽略了测试的本质是验证需求的完整性和正确性，没能深入到需求层面，而是仅依赖于代码级的表面生成，没有实现对原始需求的全面交互和验证。

其次，从技术缺陷来看，主要表现在三个方面。

一是环境依赖信息的缺失，现在的大模型训练主要是在开源代码及企业代码上的训练，缺乏足够的项目上下文支持。尽管各大模型厂商都在上下文长度上下足功夫，生成的代码在语法上看似正确，但这并不能从根源上解决这一技术缺陷。

二是当前的智能化开发辅助主要依赖于大模型的语言能力，通过模式匹配和简单的Prompt指令生成代码。然而，这种方法仅停留在表层语言模型的使用上，无法深入理解复杂的业务逻辑和编程规范，导致大模型在实际应用中的表现不尽如人意，影响了结果的有效性和可靠性，尤其是生成内容的可靠性仍然存在较大问题。

三是微调方法的局限性，尽管在1.0时代我们采用了全参微调(Fine Tuning)、以及LoRa、Adapter、Prompt等PEFT高效参数微调(部分参数微调)方式，甚至尝试使用RAG和MoE等方法让大模型学习特定领域知识，但这些常规微调技术和方法仍存在局限性。尽管它们在某些特定任务中表现出一定的效果，但由于没有充分训练企业领域的专有数据和背景知识，这些方法在真实业务应用中的表现往往难以达到预期，无法完全满足实际业务的需求。

从客户角度来看，我们发现很多大模型在通用的场景或者主流的测评集上表现都不错，声称也能达到30%到50%的准确率。但是一旦拿到企业中去应用，通常发现准确率下降到了10%以下。即使用各种方式做微调，效果也不尽如人意。对于企业而言，技术团队和商务团队尽力引入并上线了智能软件开发产品，也进行了相应的微调，但如果最终结果无法达到预期，可能会引发内部大量用户和软件开发人员的投诉，带来巨大的风险。

综合来看，真实企业软件开发场景是非常复杂的，具有很强的业务逻辑、拥有明确的编码规范和独特的代码风格，在多阶段的复杂开发流程中涉及多角色、多工具、多团队的共同协作参与。尽管智能化软件开发1.0时代提供了一定的软件自动化支持，但其并没有真正解决企业领域知识问题，也没有充分考虑真实开发场景的复杂需求。所以基于这样一个背景，aiXcoder率先提出了软件开发2.0时代的概念，并已成功在多家大型企业中落地实施。通过这一模式，企业才能真正抓住并充分利用大模型所带来的技术红利。

aiXcoder总裁刘德欣：结合领域知识治理并训练选择真正理解业务的大模型

ENI:aiXcoder如何定义智能化软件开发2.0时代的？

刘德欣:智能化软件开发2.0时代：首先通过严格的数据治理和链式管理，对企业的特定领域知识进行全面的结构化处理，确保从需求定义、设计、编码到最终代码提交的每个环节都得到精准记录和系统关联。在此基础上，进行低成本、高度个性化的模型训练，构建基于领域软件工程的大模型。通过多智能体协同自动化、传统软件开发方法和最佳实践的有机结合，全面保障了开发流程的高效性与结果的准确性，使大模型从单一的代码生成工具转变为与企业开发过程深度协同的智能体集合，显著提升了开发效率和产品质量。

我们所定义的智能化软件开发2.0时代，其核心概念并不复杂。可以用一个公式来概括：智能化软件开发2.0 = 专业软工领域大模型 + 多Agent协同 + 传统软件工程方法。

首先，本阶段的智能软件开发强调对软件研发流程的高度数据治理。整个开发全过程，从需求分析、概要设计、详细设计、编码实现、测试，直到最终产品上线，每一个环节都通过结构化的数据治理和全面的数据链管理进行链式数据追踪，确保原始需求被精确记录并与系统紧密关联。这种全链条的协同工作方式，不仅使得大模型能够最大程度地理解企业特定的业务逻辑，还能够在开发的每一个阶段中准确实现这些逻辑。同时，基于经过治理的领域化数据集，对模型进行个性化训练，使大模型能够深入学习并应用企业的领域知识，从而构建一个低成本、高度个性化的企业领域化大模型，这将是最关键的一步。此外，在实现领域个性化的基础上，通过多Agent方式解决软件开发流程中的各类问题，并结合传统的软件开发工具和最佳实践，确保领域大模型输出的准确性和可靠性。

同时，通过对经过治理的领域化数据集进行个性化训练，使大模型能够深入学习和应用企业的领域知识，从而构建一个低成本、高度个性化的企业领域化大模型。在实现领域个性化的基础上，我们通过多Agent协同的方式解决软件开发流程中的各种问题，并结合传统的软件工程工具和最佳实践，确保领域大模型输出的准确性和可靠性。

这种结合了专业软工领域大模型、多Agent协同，以及传统软件工程工具与最佳实践的协同自动化方式，正是我们所定义的智能化软件开发2.0时代。

ENI：根据智能化软件开发2.0时代的定义和特性，刘总，您认为企业在迈入2.0时代时，应该重点关注哪些关键行动或策略？有哪些具体的准备工作是企业需要优先考虑的？

刘德欣:结合多年来对软件工程领域的深刻理解，以及aiXcoder在企业领域化大模型落地方面的丰富经验。我们总结了以下4个核心策略，帮助企业更好的拥抱智能软件开2.0时代。

第一是面向领域的开发数据治理，这一点非常关键。简而言之，企业需要对最原始的需求文档进行深入治理，将自然语言表达的“大白话”需求逐步转化为精确的开发语言描述，从需求分析、设计，到开发、测试及运维等环节的数据、知识都进行整合并进行全链条数据治理，并确保数据质量、规模与多样性，以服务于领域大模型的构建与优化。值得一提的是，这种数据管理框架和方法能够高效复用，日后大模型产生的海量数据都是基于该框架治理，从而可持续用于训练，这有助于提高企业在应对市场变化时的灵活性和响应速度。

第二是基于领域数据的个性化模型构建。通过利用治理好的领域知识数据集，并充分考虑企业算力资源、代码量等因素，对大模型进行灵活的个性化训练及参数调优，确保大模型能够精准捕捉并反映企业业务需求，使其逐步掌握企业特定的业务流程与逻辑、专业术语和编码规范。进一步地，通过应用PEFT、MoE、RAG和AI Agent等技术和方法，确保个性化训练能够根据企业具体业务需求进行灵活调整和优化。这样的策略不仅增强了模型的业务适应性，还提升了模型训练效率和输出的准确性。

第三点是将大模型的先进能力与传统软件工程的方法和工具相结合。许多企业在引入大模型后，往往倾向于完全依赖大模型，忽视了原本效果优异的软件开发工具。这种做法实际上并不合理，因为大模型虽然具有强大的能力，但其生成结果并非总是精准无误。为了确保大模型输出结果的准确性与可靠性，企业应继续结合和利用传统的软件工程工具与方法，使其与大模型协同工作，从而保障开发流程的时效性和结果的高质量。

最后一点是面向各场景的智能协同。通过引入Agent技术，将其与企业特有的软件开发流程和现有的软件开发工具相结合，以提升开发流程的透明度和效率。同时，确保所有自动化过程的合规性和可追踪性，实现需求分析、设计、编码、测试和部署等各个开发场景的深度协同。通过系统化的数据共享和流程整合，开发团队能够在各个阶段实现无缝衔接，从而更加高效地应对复杂的项目需求和快速变化的市场环境。

ENI: aiXcoder如何帮助企业落地智能软件开发2.0时代？

刘德欣:在与很多大型企业交流的过程中，我们发现目前企业普遍面临着搞不懂、训不转、学不会三大挑战，展开来讲，就是企业缺乏优秀人才，现有的技术人员搞不懂模型应该如何训练。有些企业技术积累较好，试图通过开源模型+各种微调的方式，尝试让大模型的能力更贴近企业的真实开发环境要求，最终还是发现大模型学不会企业的领域知识，效果不尽如人意。

为此，我们发布了一个大模型落地框架 LLM Adoption Framework(LAF)，旨在帮助企业了解如何将大模型与领域知识相结合，并利用我们的经验，帮助来自各个领域和行业的企业有效地部署和落地领域大模型。具体来说，该框架是一种咨询的方法论，分为以下三个阶段：我们首先会根据企业的商业目标进行全面评估，深入了解企业已开展的工作，以及为何未能实现大模型落地的预定业绩目标，并分析导致这些差距的原因。基于这些差距企业应该怎么选择模型，怎么准备和处理数据，如何训练模型，可以通过哪些数据治理的方法来达到预期的状态。此阶段旨在精确构建并优化大模型，确保模型深度融合并体现企业特有的领域知识。在这一阶段，不仅进行模型架构的设计与搭建，还包括针对企业独特业务逻辑和领域特定数据的深入治理及训练过程。这一阶段主要涉及产品化的过程。我们将帮助企业将领域大模型与其内部多个平台通过API进行集成，并确保模型能力能够有效输出到业务端，所有这些都需要根据企业的实际需求进行定制化实现。

总而言之，aiXcoder的LAF并非特定于任何一个开源/闭源提供商，而是大量利用aiXcoder提供的大模型训练、领域经验和软件工程最佳实践为企业提供更具体的深度咨询和指导。同时，aiXcoder的LAF不仅限于aiXcoder模型使用，企业可以选择任何闭源和开源模型，它是通用的，并非“独门秘籍”，可以根据企业“领域知识”量身定制大模型落地实施及行动计划。

最后，总结一下我们的观点：

.无论是开源还是闭源，选择专业的软件工程大模型，而不是通用大模型。

.不关注大模型厂商宣传支持了多少功能和HumanEval、MBPP、MultiPL-E等常规的“打榜”评测集评测结果，要关注大模型实际生成内容是否真的理解企业的业务。

.务必要结合领域知识治理并训练，再做进一步微调。直接使用常规的全参微调、高效微调、RAG等方式帮助不大。

.大模型落地要高度自治、，企业业务的复杂程度和连续性，更不允许绑定某个大模型厂商解耦。

.一定要做个性化训练，不能直接落地代码大模型，同时培养自己的技术人员，有效规避直接部署模型的高风险。