科技日新月异的今天，以大模型、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时代的概念，并已成功在多家大型企业中落地实施。通过这一模式，企业才能真正抓住并充分利用大模型所带来的技术红利。