背景
大语言模型的实践应用，正引发软件工程的革命。为此，我们在杭州聚集了产业、学术和研究机构的前沿实践者和专家，在6月4日-5日期间进行了为期两天，以《探索AIGC下的软件工程新范式》为主题的深入的闭门研讨会议。
经过交流和讨论，我们一致认为：AIGC正在催生软件工程的新范式，LLM作为催化剂和创新引擎正在开启软件研发和创新效能的倍增，甚至带来指数级提升的可能。面对范式迁移，我们无法靠臆想来推断未来，唯有躬身入局，识别机遇、解决问题，在实践中不断试错和进化。而在这一过程中，产、学、研有效协作与持续地深入交流至关重要。
会议中，我们分别就6个主题进行了探讨，识别了当下LLM在哪些方面带给软件工程重大机会，以及为把握这些机会而亟需解决的重大问题。现将讨论的内容整理成文与行业同仁共享，以激发更多的思想碰撞，促成更多跨领域实践合作。
主题1：应用生态的范式迁移
应用生态指的是：软件以何种形式交付给用户。例如：今天的软件主要以独立应用的形态（如移动应用、SaaS应用、PC应用等）交付。我们认为LLM带来了前端交互形式的变化，以及后端推理、规划、连接能力的提升，这将极大改变应用生态。而应用生态的形式变化，将很大程度上决定未来的软件工程的走向。
达成的共识：
1.LLM将带来交互方式的彻底变革，意图导向的自然交互方式将成为现实
过去命令行用户界面（CLI）和图形用户界面（GUI）交互的共同特点是：要求用户将意图转化为机器可以识别的命令，并以命令的形式与机器交互。大语言模型时代的交互方式，将由命令导向式向意图导向式交互迁移——人类表达意图，意图的理解和执行由更智能的机器完成。意图导向的交互模式的实现，背后需要整合一系列智能的能力，并将带来全新的多模态的自然交互方式，自然交互界面（NUI，Nature User Interface）的技术元素已趋向完备。
2.交互方式的变革与LLM推理能力相结合，将带来以用户为中心的融合应用生态
过去，由于交互方式以及后端资源割裂的限制，软件实体不得不按具体任务、商业实体和所承载的硬件被分割成为独立应用或功能模块。大语言模型时代，传统应用间的界限将被消融，智能助理（或其他形态的智能体）将以用户场景为主题整合工具和资源，服务一类场景下的完整用户任务。大模型时代，我们需要以用户为中心，跨越商业实体、特定硬件设备以及传统应用的边界，构建融合的新型应用生态。
可见的重大机会：
1.交互模式变革带来新的商业机会
历史上每一次交互模式的革命都会产生全新的商业模式。大语言模型赋能下新的交互模式，带来交互和体验升级的同时，更蕴含着巨大的业务创新机会。
2.应用生态的变迁孕育以用户为中心的商业形态
应用大模型的能力，打破传统应用的边界，整合工具和资源，服务好一类场景下的完整用户目标，将可能取得竞争的优势。从以平台为中心到以用户为中心的应用生态变迁，将改变商业竞争格局，并带来全新的业务可能。
亟需解决的问题：
1.探索新的交互设计模式
LLM的能力将带来新的交互模式，但如何应用LLM的能力，实现意图导向的自然交互模式是一个全新的命题。自然交互不等于自然语言交互，它应该是多模态的，更加意图导向、智能和个性化，能够持续学习、进化并确保隐私及安全。适配大模型时代的交互和体验设计方法是一个新命题，需要持续探索和总结提炼。
2.探索和构建新的应用生态
传统应用和应用内不同功能模块的边界正在消融，OpenAI的插件市场、Windows Copilot等展示了可能的方向。但这些都尚处于早期，以什么样的技术、架构和方法整合不同的工具和资源，构建新型的应用生态是需要不断探索和总结的重大主题。
主题2：应用架构的演进
技术环境的发展是应用架构演化的关键驱动因素。LLM提供了良好的意图理解能力、推理能力和知识内建能力，为用户交互、商业能力组装、服务或组件的开发带来了新的技术选项。我们认为，LLM优先的应用架构已经开始涌现，并且将逐渐成为主流方案；LLM原生的应用架构也成为可能。同时，我们也看到，应用架构的演进将是一个价值导向、长期和持续渐进的过程，其中仍然存在许多关键挑战和困难需要解决。
达成的共识：
1.考虑LLM优先的架构模式
LLM在人机交互、流程规划、数据处理等领域都表现出了巨大的潜力。从长期来看，LLM有可能作为应用内核，在此基础上构建LLM原生的应用。
从架构的演进路径上，既有应用架构会逐步通过LLM的能力获得增强。LLM原生能力会和既有软件系统彼此融合，长期共存，但是在架构设计时，为了利用LLM在交互、复杂问题处理和开发运维成本方面的优势，应优先考虑基于LLM能力的解决方案。其中既包括从既有的软件系统中逐步增加LLM能力，也包括在LLM平台增加插件的方式。
2.采取LLM友好的架构策略
为了最大化发挥LLM的价值，架构方案和基础平台的设计应该采取有利于LLM的上下文获取、能力调度、功能实现的方案。例如：
•采用便于LLM获取业务上下文的应用架构，如事件驱动架构；
•采用基于领域划分的架构，便于按特定领域组织数据和模型；
•采用合适的API声明，利于LLM对服务能力的理解和调度；
•采用适于获取用户意图的交互方式，便于LLM规划用户意图的达成；
•建立以“提示工程”和LLM的推理能力为核心的应用开发方案；
可见的重大机会：
1.利用LLM改善人机交互体验
基于对话或LLM生成的用户界面，将会大幅提升人机交互的便捷度和灵活性。
2.利用LLM规划业务流程和构造系统
使用LLM来组织业务流程，形成推理和规划，通过灵活组装既有或新开发的商业能力，满足用户需求，降低开发成本，实现业务上下文密切相关的个性化。
3.利用LLM形成数据整合和数据洞察
利用LLM对复杂数据和复杂流程的处理能力，整合多领域、多维度的数据，产生有效洞察。
4.构建LLM原生系统或组件
LLM接受用户需求或组件契约，经过和人类开发者的协作，产出可运行的解决方案或组件。
5.构建支持大模型优先架构的基础设施
LLM优先的架构产生了对于个性化交互、流程推理和规划、数据整合以及大模型服务等多方面的基础设施的需求。
亟需解决的问题：
1.探索LLM优先的架构的应用场景和设计模式
LLM为软件架构引入了基础且重要的新技术能力。系统实现中的问题，有些适合LLM解决；有些则更适合传统的程序逻辑解决。在涉及复杂推理和知识工程领域的问题（如：信息的分类、提取，知识的表达和应用，复杂数据、流程处理等）LLM具有优势；在强调确定性和一致性的领域(如：结构化的数据处理和查询，涉及物理世界的动作执行等）既有的基于程序逻辑的实现则更为有效。充分应用LLM的能力，并与传统的程序逻辑更好的配合，为设计更加智能、灵活，开发成本更低，更易于维护的系统带来可能。我们需要在实践中持续探索LLM优先的应用架构，沉淀相关的设计模式。
2.研究和探索LLM原生的应用架构的可能性和使用场景
随着LLM能力的增强以及更多的工具和设计方法的完善，LLM可以处理问题的边界将不断扩大。我们相信在一些领域，LLM将会成为缺省的问题解决方案。尽管今天还有许多问题要解决，但是对LLM原生架构模式，特别是在特定领域的应用（如：智能助理等）将成为可能。我们需要在实践中持续探索LLM原生的应用架构和设计模式。
3.适合LLM的API定义、领域模型表示和工具
通过为LLM提供高质量的领域知识表达和上下文表达，可以提升LLM在特定领域的表现。同样，更适合LLM的API定义和工具，可以更好地发挥LLM的流程规划和系统构造能力。
4.多模型协同的范式和解决方案
通过整合多个模型的能力，可以优化成本效益、提升模型反馈的质量和稳定性，以及为特定领域提供更高效的解决方案。
5.数据安全的挑战
LLM对数据安全带来了诸多挑战，例如数据隐私泄露、数据滥用等。需要通过有效的数据安全管理和模型训练及发布策略等，积极应对上述挑战。
主题3：BizDevOps实践和组织协同范式迁移
BizDevOps代表了当下软件交付的先进实践和理念，它要求打通从业务、开发、到交付、运维和运营的端到端的价值交付链路，业务和技术融合，建立快速和有效的价值交付和反馈调整闭环。BizDevOps的价值链路为AIGC在软件工程的应用提供了系统的线索，AIGC则为BizDevOps提供了新的技术工具，并带来新的可能。
达成的共识：
1.AIGC可以加强今天BizDevOps实践体系中的各类实践
BizDevOps价值链条中，各个环节的工作都有相当部分是AIGC所擅长的理解性和生成性工作，如：意图的理解，文档的生成，代码的理解、生成和重构，缺陷的检测和修复，测试用例和测试数据的生成，运维策略的设计和实施等。在这些领域LLM都可以发挥作用，并增强相关的实践，提高软件设计、开发、维护和运维的效能。
2.只有重构BizDevOps的实践体系，AIGC才可能带来效能的非线性提升
软件工程是人类历史上最复杂的大规模智力协作活动。尽管，AIGC在BizDevOps各个独立环节的应用都存在机会，并带来效能的提升。但如果AIGC的应用局限于原有模式下，对各个独立环节的加强，则其对效能改进的影响将是有限的，不可能带来非线性（倍增或指数级增长）增长。只有重构BizDevOps实践体系，AIGC才能开启研发和创新效能的非线性提升，而这是一个长期的过程。
可见的重大机会
1.AIGC在BizDevOps各个环节和跨环节的应用
AIGC在软件工程中应用的机会首先来自对现有实践的加强。BizDevOps每一个环节都包含理解性和生成性的工作，AIGC可以降低这些工作的门槛，并改进质量和提升效率。同时，通过AIGC贯穿不同的环节应用，将带来更大的可能，如：在需求分析和代码生成环节的综合应用。
2.AIGC对组织和协作方式的重塑，加速业务和技术的融合
AIGC的加强下，不同职能的技术门槛在变低，业务和代码的理解门槛也变低。传统的职能（如：产品、技术，前端、后端算法）和功能的壁垒有消融的趋势，个人和团队都有机会变得更加跨功能和跨职能。在AIGC的加强下，打造更加跨功能和跨职能的团队的条件更加成熟，业务与技术更紧密协作和融合更加可能。
亟需解决的问题：
1.在各个环节探索有效应用AIGC的新工作方式
AIGC在BizDevOps的各个环节的应用，理论上可行。但是AIGC作为一个超级队员加入到研发活动中，是一个新生的事物。如何在各个环节充分应用AIGC，并探索AIGC与人类的有效协同方式，是一个新的命题。我们一方面要鼓励积极的尝试，另一方面需要不断沉淀最佳实践，并改进工具和基础设施。
2.探索AIGC赋能下，新的组织和协作方式
LLM带来了新的应用生态和应用架构，一方面，对组织的高效协同特别是业务和技术的高效协同和快速反馈提出了更高的要求；另一方面，AIGC降低了组织的技术和知识壁垒，为跨越职能和功能的协同提供了可能。在AIGC赋能之下，业技融合的迫切性和可能性都在增加。我们急需探索AIGC赋能下，新的业技融合的组织和协作方式，它也将成为数字化和智能化的重要推动力量。
3.研究AIGC赋能下，基于全新的应用架构的BizDevOps范式
需求是对业务问题的解决方案的精确描述，软件是现实世界的解决方案在数字世界的映射。从需求出发在AIGC的加强下设计精确的解决方案，并应用AIGC的能力将解决方案映射为数字世界的实现，同时辅助对解决方案的测试和验证，是一个值得探索和长期投入的方向。它有可能带来全新的系统开发和交付范式，从本质上提升交付的速度，降低组织协作的复杂度、加速业务反馈，并提升系统的智能化程度和灵活性。
主题4：工具平台建设
技术发展最终需要为人服务，对于软件开发者来说，研发工具平台是技术的重要承载。LLM在软件工程的应用，必然会对软件研发工具的建设提出更高要求，涌现更多新机会，同时也会带来新的问题。我们需要在软件研发过程中，寻找那些适合AI去解决的问题场景，通过将LLM应用到研发工具和平台上，才能最大化地将AI技术普惠到软件研发领域的方方面面，助力研发效率的倍数级提升。并提供可行的路径及遵循的原则，确保LLM在研发工具平台上的落地。
达成的共识：
工具和平台建设上，面临重大的机会和挑战。我们认为工具平台建设，需要遵循的原则是：
•数据可用性原则：数据和模型为AI提供高质量输入，高质量的输入源成就高质量的LLM。软件研发全生命周期必须是数字化的，研发团队需要构建良好的知识体系，知识需要被沉淀。
•以人为本可控原则：人是主体，AI是客体的人机关系。AI是知识的储备和助手，提供解决方案和建议，由人做为解决问题的主体。人类培训机器，机器辅助人类，即AI是人的Copilot。同时，为用户提供基于LLM的工具和平台的可控性，用户可以自主选择使用或停用LLM技术，同时可以获得自身数据的控制权。
•研发效率优先原则：提高软件研发效率，降低人工成本。因此，工具和平台应该遵循这一原则，提高软件研发效率和质量。基于LLM的研发工具和平台应该释放生产力，而不是消耗生产力。智能无处不在，人机共生。软件研发过程即人与AI的协作交互过程，应该极大简化人机交互方式。
•数据隐私保护原则：一方面需要对AI的所有任务执行都必须留痕，加强AI的行为安全。同时，研发过程数据，会涉及到企业代码等知识产权数据和用户数据，数据安全领域将迎来越来越多的挑战，需要构建新的数据安全围栏，避免隐私权及伦理风险。
可见的重大机会：
1.数据处理及知识沉淀的能力要求越来越高
目的是获得有价值的模型，软件研发全生命周期数字化的要求越来越高。数据和模型成为企业的核心数字资产，避免过量分散的数字化成为数字债，在数据资产存储、研发数据建模、数字资产及债务治理等工具诉求越来越高。
2.AI成为软件研发过程中的 Copilot, Co-Integrator和Co-Facilitator
软件研发领域的模型，指导和建议人的行动。AI与人共同协作，倍数级提升软件研发的效率。整个工具和平台发展上，经历以下几个阶段。
￮LLM as Copilot：不改变软件工程的专业分工，但增强每个专业技术，基于AI的研发工具平台辅助人完成任务。极大提升个体工作效率。解决“我懒得做”及“我不擅长做”的事。如服务于一线研发人员的内容生成工具（文档、编码、测试、发布、运维），提升生产力。AI是对专业工作的增强。对人的要求是需要更广的知识面，提升意图表达的能力。
￮LLM as Co-Integrator：跨研发职责及角色的协同增效。基于AI的研发工具平台解决不同的角色之间辅助沟通。解决信息沟通对齐的问题，提升角色间互动效率。如服务于一线管理人员的协作辅助工具，提升协同效率，如需求选择、排期、协同发布等。AI需要提供跨领域（职能）的知识管理。对于人而言，需要为AI提供上下文，完成知识对齐。
￮LLM as Co-Facilitator：影响软件研发流程的角色分工，基于AI的研发工具平台辅助决策。辅助计划、预测发现和协调的工作。解决信息整合分析、决策依据，提升组织决策效率。如服务于管理层提供更多的知识洞见，辅助管理决策。AI提供跨学科“会诊”的能力。对于人才的培养，需要越来越复合型人才。
3.人机的交互形式发生演变
人机交互的体验升级，帮助研发人员善用AI的能力。提示工程成为重要的研发实践。从命令式，到声明式，再到意图导向。所有的工具和平台都需要提供AI的能力，并基于此进行重大升级。
4.数字安全的要求越来越高
涉及到监管、隐私及数据安全的要求，在工具和平台体系建设上，会有更多的安全策略及数字围栏的要求。专业领域大模型、私有大模型、数据安全领域的工具的建设成为必需品。
亟需解决的问题：
1.模型成本的问题
大型模型成本包括硬件成本和能源成本两个方面。一方面，大型模型需要大量的计算资源和存储资源，因此需要购买高端的服务器、显卡、内存、存储设备等硬件设备，这些设备的价格往往很高。另一方面，大型模型需要大量的能源来提供计算和存储服务。高性能服务器和显卡的功耗通常很高，需要耗费大量的电能，这也是成本的主要来源之一。除此之外，大型模型的训练和调优需要大量的时间和人力成本。需要专业的技术人员进行模型的设计和调优，以及对训练过程进行监控和优化。
2.数据安全及监管要求
LLM需要使用大量的用户数据和企业研发数据，包括个人身份信息，企业代码信息等，如果这些数据被黑客入侵或内部人员泄露，将导致用户的个人隐私及企业知识产权受到侵犯。需要有一套系统的方法实践，来加强数据保护措施，建立完善的安全管理机制，监测和处理潜在的安全风险。同时，不同国家和地区的政策法规的要求不同，需要有清晰的政策法规，明确LLM的工具和平台的相关规定和要求，如数据隐私保护、公平性、模型透明度等方面的要求，以及相应的监管措施。
主题5：人员能力计划和培养
软件工程本质上是人类大规模的脑力协作，由于高复杂度而催生出了不同的专业角色分工。LLM在软件工程的采用，将在众多工程领域产生突破，甚至于颠覆，由此也敦促我们必须认真审视专业能力的变迁和专业角色的定义。LLM及相关的AI技术仍然在高速演进中，我们很难精确地针对未来的专业人员进行能力建模，但我们认为必须建立开放合作的产学研社区，才能够推动LLM在软件工程领域的高质量应用，保证人才资源的可持续发展。
达成的共识
坚守以人为本：新兴技术的应用是以创造人类更美好的工作和生活环境为初心，虽然LLM为代表的AI技术浪潮给大家展现了未来可期的颠覆，但我们坚信只有不忘初心，一切美好才能够最终实现。打造数字化世界的软件工程仍然需要人类进行大规模的脑力协作，LLM的加入并不改变这一本质。在采用LLM重塑软件工程的旅途中，帮助研发团队及各专业人员提升效率、增强职业幸福感应该是应用的首要出发点。
保持开放合作：面对AI技术的持续发展，软件工程产生新范式已经是不争的趋势，然而新范式的具体方法和实践还需要相当长的一段时间去试验和沉淀。在互联网、大数据及云计算领域，我们见证了全球知识开放共享带来的巨大行业发展，推动了很多复杂问题上的智力共创。我们相信在软件工程新范式演进的过程中，这种开放合作的模式需要强化；在采用LLM的新型工程方法及实践的探索和沉淀上，我们也需要在人员能力计划和培养上保持这种开放心态，为一线研发人员创造安全的试错空间。
可见的重大机会
1.利用LLM辅助各研发专业提效
目前在开发人员中形成的copilot模式将逐步成熟，并延伸到研发相关的其他专业，从而显著提升从需求分析、产品设计到测试验证各个环节专业人员的工作效率，大幅度减少事务性重复劳动，使其更加专注于软件研发中的创造性劳动。
2.利用LLM降低研发各角色协同成本
由于个体脑力限制难以应对与日俱增的软件“复杂性”本质难题，而大规模集体脑力协作的背景下，软件研发过程中大量时间花费在了不同专业、不同思维个体之间的交流和共识之上。LLM在知识存储上的全面性、以及在推理问题上的针对性，能够被有效利用来促进跨角色之间的高效沟通，并且有可能更加精准地协调相关专业资源的调配及相关问题的发现。
3.利用LLM形成更高效的知识管理和培养体系
软件研发面临着业务持续演进和技术持续发展的双重高“可变性”，往往造成研发过程中知识积淀的碎片化，从而很难建立高效的人员培养体系。LLM针对数据的持续学习和推理能力，给我们打开了知识管理的新可能。研发过程中的数据有可能成为LLM的学习语料，持续扩展LLM的知识上下文，进而加快研发团队在人员能力培养上的步伐。
亟需解决的问题
1.LLM重塑软件工程的目标及方向
LLM的崛起给我们展现了现代技术突破“涌现”的特质，某一个领域的爆发并非是一个单点技术的突破，而是多项技术持续发展和交汇的结果。这种涌现性带来了发展目标上的不确定性，由此也带来了一些研发组织在采纳LLM时，以降本为主要目的急功近利，缺乏针对软件工程的全局性思维，很容易引入安全合规等方面的系统性风险。从交付价值的角度出发，研发各专业人员能力要求的变化，以及对应的分工变化，是更需要持续解决的问题。
2.相关专业社区的建立和相关课题的研讨
本次LLM催化的软件工程范式变革牵涉广泛，涉及到软件工程的整个产业链，由此也需要产、学、研、媒针对不同专业形成社区，开展持续的碰撞和研讨。研讨的方向不仅仅局限于目前LLM带来的研发方法和实践的改造，也需要考虑针对新方法和新实践的能力要求，以及如何才能有效地培养专业人员。特别是高校在未来人才培养方向上，如何适应LLM带来的新技能要求，如何帮助新一代建立正确的模型价值观。
主题6 ：代码智能
代码智能是指根据工程师意图自动补全和生成代码，特别是利用大语言模型的知识储备和生成能力，自动编写、优化、分析、查错。编码是一种更为严谨的写作，编码也是一个典型的规划和推理过程，期间工程师会调取丰富的上下文并利用来自于领域和遗留系统中的隐性知识，因此利用大语言模型辅助编码，特别是完成完整的需求编码任务，相比文字写作更具挑战，更有趣。
达成的共识
1.大模型让代码智能领域的工作再次活跃起来，应用生态发展迅猛
Copilot的出现让大家看到了大模型的威力，惊叹于其代码补全、缺陷识别等方面的能力。类似的工具，比如Bloop、Cursor等等，从不同角度探索代码检索、问答与补全的应用。工程师哪怕直接通过ChatGPT、Claude等工具也能方便地完成诸如代码解释、测试代码生成、优化代码设计等有趣的工作。与会的百度、阿里巴巴、蚂蚁集团、招商银行、Thoughtworks等公司，阿里云云效、aiXCoder等工具厂商也在积极尝试调优擅长编码的大模型，特别是利用企业私有代码调优大模型，并利用其生成使用公司私有组件和库的函数，包括尝试模拟工程师的思考过程一步步写公司需求的代码。还有同学尝试如何利用大模型辅助软件设计。虽说现在的效果很难达到令人满意的程度，但都扎实地走在代码智能的路上。
2.对不同性质编码工作的生产力提升效果参差不齐
对于陌生语言或领域入门、通用算法生成等方面效果显著，而对于开发熟手、或在大规模软件中参与协作的工程师来说帮助就相对小些，相信未来会逐步覆盖更多性质的开发工作，这需要一个过程。另外，利用大语言模型也会让非专业工程师有机会开发一些应用，比如在ChatGPT的指导下利用外部工具打造个人应用，这对参与者来说效果非常显著。我们做了分析探讨，认为对于专业大型软件开发团队来说，仅仅依靠代码智能，在中短期内整体效能很难实现非常显著的提升。
3.利用大模型从需求逐步生成代码以及辅助软件架构设计的挑战很大
从需求生成代码目前效果不太理想，当然这方面的尝试也仅有短短几个月时间，其中也面临不少需要深入挖掘的问题：如何模拟工程师的规划和推理过程？如何获取有效的上下文？如何表达工程师使用的领域及系统的隐性知识？如何设计交互过程？如何选择适合子任务的模型？如何有效地针对私有代码调优模型？等等，这些问题都需要反复实践，甚至要更强模型的出现。
辅助软件架构设计也是一个难题。模型应该如何有效学习到设计知识？Github上有大量优秀的项目，但如何表达其架构设计？决定设计选择的外因在哪？设计演进的过程能分析到吗？如何表达设计意图？这些或许都需要更多的投入和时间。
4.私有代码大模型是追求代码智能极致效果的必经之路
最终，我们是希望利用大模型帮我们完成需求代码的，而不仅仅是基于通用编码知识补足片段。通过in-context learning的方式能一定程度解决模型学习私有代码和设计的问题，但配合公司私有代码调优后的大模型才会拿到最佳的续写效果。
可见的重大机会
1.每位工程师都面临着提升自己竞争力的巨大机会
充分利用Copilot的工程师尝到了甜头，更有工程师在积极尝试提示词工程，在各个场景下帮助自己提效，甚至据此开发小应用，提出内部工具创意和业务创新的建议，团队也能感受到他们的提升和贡献。这对工程师来说并没有很高的门槛，每位工程师都有机会从中获益，就像当年会用搜索引擎的工程师总会先人一步。
2.每家软件企业都有机会受益于大模型时代提效的红利
对公司来说，这往往不需要多大的投入，其效率提升的比例通过传统手段则是极难获得的，因为代码智能深入到了生产力的最核心环节。
3.有条件调优/训练代码大模型的企业将有机会获得更大优势
在通用大模型基础上针对下游任务调优私有代码大模型会涉及到不菲的成本，包括数据准备和模型训练的成本。为追求效果，也会逐渐选用更大的基础模型，从8B到13B再到20+B甚至60+B，成本也会随之增加，这也会形成一定的壁垒。
4.副驾工具及模型服务中有巨大商业机会
稳定的工具市场会面临洗牌的机会，小厂商拼创新也有机会，大厂商在模型服务上优势明显。
亟需解决的问题
1.企业内外的信息安全问题亟待解决
这是最直接的挑战，各公司态度松紧不一，面临的风险较大，需要有系统性的方案。使用Copilot，代码片段会跨越公司安全边界，而这对于绝大部分企业都是不被允许的。如果企业利用私有代码调优/训练模型，这意味着访问模型的人有相同的代码权限，对于内部开源的企业还好，否则也打破了原有的权限管理机制。
研讨会参与人（以下排名不分先后）
李 戈 北京大学
张 贺 南京大学
何 勉 优川信息
陈 鑫 阿里云
刘志伟 蚂蚁集团
李永彬 达摩院
欧 红 招商银行
徐晓强 百度
肖 然 Thoughtworks
张燎原 阿里云
郝逸洋 aiXcoder
李力行 aiXcoder
陈展文 招商银行
路 宁 理想汽车
张 刚 英慕科技
刘名威 复旦大学
娄一翎 复旦大学
姜 伟 蚂蚁集团
黎槟华 达摩院
林 帆 阿里云
黄峰达 Thoughtworks
刘 星 阿里巴巴
王 怡 阿里巴巴
刘力华 阿里云
张 裕 阿里云
景 韵 高效运维社区
6月4日5日于杭州
声明：本文来自云效，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
