大模型时代的软件工程人才培养智能化软件开发微访谈·第二十五期

菏泽炫佑科技

大模型时代的软件工程人才培养智能化软件开发微访谈·第二十五期

“智能软件开发沙龙是团队围绕智能软件开发、数据驱动的软件开发质量与性能分析、云原生与智能运维等相关主题，通过微信群访谈等方式举办的线上沙龙。通讯线路。 通过线上交流的方式，汇聚学术界和工业界的专家学者，分享前沿研究进展和行业实践，共同探索未来技术发展方向。”

大模型时代软件工程人才培养

智能软件开发微访谈·第25期

背景介绍

大型模型优异的代码生成和理解能力可以极大地提高软件开发的效率，甚至可以直接替代人类完成许多编码任务。 同时，大模型在需求分析、软件设计、软件测试、软件运维等其他软件工程任务中也表现出了强大的能力。因此，很多人认为大模型对软件工程产生了颠覆性的影响。软件行业和软件工程师。 甚至有人认为“AI让程序员失业”可能会逐渐成为现实。 那么，目前的大模式到底对软件行业有什么影响呢？ 哪些工作正在萎缩或即将消失？ 哪些软件工程能力变得不那么重要，哪些能力变得更加重要？ 软件工程师需要如何调整自己的能力和职业发展规划？ 大学计算机与软件工程等相关专业的培养目标、课程设置、教学方式和方法应如何相应调整？ 针对这些问题，我们邀请学术界和工业界的专家学者分享经验、发表看法，希望为高校和企业培养软件工程人才、提升人才能力提供一些有益的建议。

针对这些问题，本次微访谈邀请了多位学术界和工业界专家，共同探讨大模型时代软件工程人才培养的话题，总结行业实践和学术研究进展，探讨相关技术问题，并对未来进行展望。发展方向。

主持人

彭欣

复旦大学教授

客人

王吉

国防科学技术大学计算机学院教授，

博士生导师

马小星

南京大学教授

李格

北京大学计算机学院常任教授，

博士生导师

王浩芬

同济大学特聘研究员，

博士生导师

埃加

大连理工大学教授，

博士生导师

李莉

北京航空航天大学教授

何冕

上海友川信息技术有限公司创始人

张刚

软件工程博士，

CCF软件工程委员会常务委员

茹秉生

中国计算机学会技术前沿委员会研发效能主任委员

朱少民

同济大学特聘教授

林凡

阿里云研发部高级技术专家

采访话题

大模型时代软件工程人才培养

01

您如何评价当前以GPT-4为代表的大型模型在需求分析、软件设计、实现编码、软件测试、软件维护、软件运维等方面的能力？

02

目前的大模式对软件行业到底有什么影响？ 哪些工作正在萎缩或即将消失？ 哪些软件工程能力变得不那么重要，哪些能力变得更加重要？

03

大学计算机与软件工程教育中的一些相关课程，如编程、数据结构与算法、软件工程等，已经或将受到怎样的影响？

04

大模型和人工智能技术的发展将对高校计算机、软件工程等相关专业产生哪些影响？ 这些专业及相关课程的培养目标、课程设置和教学方法应如何调整？

05

您对计算机和软件工程专业的学生有什么建议？ 为了更好地适应大模型时代对软件工程师的要求，他们应该注重哪些基础、培养哪些能力？

问答记录

1

主持人：您如何评价当前以GPT-4、GPT-4为代表的大型模型在需求分析、软件设计、实现编码、软件测试、软件维护、软件运维等各方面的能力？

王吉：

近20年来，数据驱动/机器学习作为重要的使能技术，在需求质量、设计评估、代码完成、测试优先级等方面都取得了长足的进步。不过，AIGC这一次的影响似乎更大深远。 以前的机器学习主要是根据训练数据进行分类预测，而大型模型会生成与训练数据具有相似特征的新数据和新内容。 大模型理解自然语言的能力可以支持一系列软工程任务：理解并转换自然语言描述的软件需求； 代码补全和自动注释； 根据设计文档生成测试用例； 生成运维脚本等。大模型在应用的广度和深度上进一步发展，能力也得到提升。 从目前已知的报道来看，大模型体现了更强的需求分析、软件设计、实现编码、软件测试、软件维护、软件运维等综合能力。 这些能力不仅跨越了软件工程的非形式化阶段，从非正式到正式阶段，而且也体现了它们在正式阶段的重要潜力，如需求获取和分析、非正式需求到正式需求等。 归约、交互式定理证明策略生成等等。

马晓星：

这是一个很大的问题，我的**反应是 GPT-4 应该回答这个问题。

这个问题其实暗示着LLM是用来辅助传统软件工程框架下的一些环节和任务的。 我自己没有**手的研究，只是看了别人报道的一些资料，特别是彭欣教授等人。 说实话，我并没有密切关注，因为发展太快了。 如果你今天做不到，你可能会发现一些聪明的/两天就能做的事情，比如*近的 CVPR *佳论文《》等等。 我也希望从你那里得到一些*新的信息。

我的理解是，如果这些任务中的“常规”事情可以用自然语言清楚地表达出来（也就是说，很多人已经做过并在网上/公共文献中讨论过了），LLM就可以做到。 帮助，包括常见需求的组织、模式化设计、常规代码生成等。总之，LLM可以充当勤奋在网上寻找答案的软件工程师的“助手/秘书”，可以做一些文字总结，知识面广，但逻辑思维能力不深。

上面的回答本身也是“套路”。 也许更引人注目的讨论是LLM/AIGC未来的进展是否会颠覆软件工程领域。 原因有二：首先，“软件”作为对象的形式可能需要大幅扩展，以包含所谓的“软件2.0”（ ）。 其次，现有的软件工程实际上着眼于如何克服“人类”以计算为手段解决复杂问题的局限性。 这里的限制主要在于“沟通”和“解决”； 我想LLM/AIGC至少会对前者产生重大影响。

观点讨论

@平鑫：

王老师还特别强调了形式部分的能力，也就是说他不仅可以提供一些文字答案（代码生成也算），还可以存储一些形式内容。

这些能力不仅跨越了软件工程的非形式化阶段，从非正式到正式阶段，而且也体现了它们在正式阶段的重要潜力，如需求获取和分析、非正式需求到正式需求等。 归约、交互式定理证明策略生成等等。

李哥：

目前大模型在上述方面的能力主要还处于实现和编码阶段。 目前，基于大型模型的代码生成已经表现出明显优于传统方法的性能，并且一些能力在实际软件开发中逐渐实用化，特别是在代码补全方面，在实际应用中表现出了生产力的提升。 但同时我们也看到，目前大模型的能力还停留在“辅助”的角色，体现在帮助开发者提高开发效率。 在实际应用中，目前还没有直接使用大型模型来完成软件开发过程的场景。 。

王浩芬：

我对大模型需求分析、软件设计、实现编码、软件测试、软件维护、软件运维等方面的一些大致的想法和看法：

需求分析：能够了解用户问题和需求，但准确性和深度有限。 这些模型可以帮助识别需求和问题，但难以对复杂系统进行全面的需求挖掘，且缺乏业务领域知识。

软件设计：可以提供一定程度的软件设计建议，如设计模式、架构选型等。但对于具体的项目需求和特点，可能无法提供*优的设计方案，尤其是详细设计复杂的系统，仍然存在较大的局限性。

实现编码：可以生成代码片段，提供编程语言和库的使用示例，解决常见的编程问题。 然而，在复杂的项目和特定领域的编程任务中能力有限。 此外，生成的代码可能包含错误或可能不符合*佳实践。 考虑鲁棒性和效率的复杂代码仍然需要工程师自己开发。

软件测试：可以帮助生成测试用例，识别潜在的测试场景和风险，并解释测试结果。 但在自动化测试、性能测试、测试组织和管理方面的能力相对有限。

软件维护：可以帮助诊断和解决一些常见的软件问题，并提供持续集成和持续部署方面的建议。 但其对于重构、性能优化、安全漏洞修复等复杂维护任务的能力有限，也难以追溯复杂系统的逻辑和定位Bug。

软件运营：可以提供有关基础设施管理、监控和故障排除的一般建议。 然而，在高度定制的操作环境中，其建议可能并不总是准确和实用的。

总之，GPT-4这样的大型语言模型可以在软件开发的各个阶段提供一定程度的帮助。 总体来说，对软件全生命周期的了解还不够。 生成的设计和代码仍需要工程师进行审查和验证。 它可以成为软件工程团队的强大辅助工具或成员，但很难完全取代人类软件工程师，仍然需要人机协作。 软件工程自动化虽然有潜力，但要想独立开展复杂的软件工程，仍然有很大的差距需要进一步突破，而人类工程师的作用仍然非常重要。

观点讨论

@平鑫：@王昊芬 看来王老师不仅是人工智能方面的专家，而且对软件工程也有很深的理解。

江河：

大型模型在软件生命周期的各个阶段执行任务的能力是惊人的。 在此之前，我们使用AI技术更多的是专注于某个特定的任务，对特定的数据进行学习，然后进行预测分析等。如今，大型模型可以根据一些提示生成大段代码或文档，这已经颠覆了大家的认知在某种程度上。 这是一种以前很少发生的新兴知识现象。 当然，另一方面，大型模型仍然很难独立、完全准确地完成更大粒度的任务，需要人工干预和协助。

李莉：

目前，业界在智能软件开发（基于GPT-4等大型模型）方面做出了很多探索，涉及软件生命周期的各个环节（包括需求分析、设计、编码、测试、维护等）。 虽然在很多场景下都有不错的效果，但由于大模型的不可解释性，大模型需要与其他能力结合才能共同完成一项高效的任务。

具体来说，以GPT-4为代表的大型模型已被证明在软件实现编码、代码理解、软件测试等方面非常有用（X在这方面已经商业化）。

由于大语言模型是在大量自然语言上训练的，因此具有非常好的文本理解能力。 因此，从理论上讲，大型模型应该具有非常好的需求理解能力。 但在软件设计阶段，大型模型并不是很擅长。 虽然大模型具有很强的理解需求的能力，但现阶段还不能用人类可以理解的方式来表达（设计）。 所以，从感官上来说，它的需求分析能力还是有待提高的，或者说是需要提高的。 激发大型模型需求分析能力的新方法。

在软件维护和运维方面，由于大模型缺乏对工程级项目的理解能力（受Token数量限制）以及对工程开发流程的记忆能力，因此大模型完成软件维护显得困难作为一个整体。 但对于具体的本地维护问题，根据一些维护数据或者运维数据来发现问题并提供解决思路是可行的。

观点讨论

@平鑫：@王昊芬说得很全面，每个部分都有优点和缺点。

何眠：

从两个方面来看。

**：上限很高

上限很高，因为以GPT4为例，大模型本身所具备的理解能力、推理能力、交互能力和知识使其在理论上有可能胜任上述任务。

第二：目前带来的改进非常有限。 是因为我们今天还是在现有的模式中，让大模型去增强各种本地环节，比如代码生成、测试生成、战略运维等。

实际上，软件开发是一个复杂的系统，整体不等于各个部分的总和。 如果不能带来结构性的改变，大模型也不会带来本质的改进。 即使它在代码生成和完成等方面已经很出色，也无法改变这一事实。 然而结构的改变需要时间，需要实践和认知的积累，也需要适应当今的软件开发生态。 我还是很乐观的。

张刚：

主要说一下我个人的经历。 在软件测试、维护、运维方面我没有做过太多的尝试，但是在需求分析、软件设计、实现编码方面我测试了自己的表现。 我的感觉是，在这些方面，编码的效果*好，但需求分析和软件设计也能提供很好的结果，但在一定程度上更与人类开发人员的专业程度有关。 如果人类开发人员的问题定义和问题分解更好，大型模型可以表现出非常好的能力。 直接给出一个非常宏观的目标，并期望（或者基于LLM的申请等）直接给出更好的结果。 这应该还没有实现。

茹冰生：

1.需求分析：GPT-4等大型模型在需求分析方面具有一定的能力。 他们可以理解用户输入的自然语言描述并生成相关响应。 然而，这些模型可能无法完全理解复杂的需求和各种约束。 此外，他们本身也无法与用户进行有效沟通，明确需求。 而且，很多需求都需要垂直领域的业务知识。 如果面对一些创新需求，大规模模型的表现估计会差强人意。

2、软件设计：这些模型在软件设计方面的能力相对较弱。 虽然他们可以产生一些设计建议，但这些建议可能不够精确和系统。 另外，大型模型处理复杂软件架构和设计模式的能力有限，尤其是需要了解现有架构和设计并进行修改时，更是困难重重。 我认为软件设计的主体还是依赖于经验丰富的架构师，大型模型只能起到部分辅助的作用。

3、实现编码：Codex等大型代码模型在编码方面展现出强大的实力。 这些模型可以生成简单的代码片段，在某些情况下，还可以生成更复杂的代码。 然而，这些模型生成的代码很可能包含逻辑错误甚至安全漏洞。 目前，通过一些企业级实践，我们感觉大型模型在生成粒度更小、行为清晰的本地代码方面具有绝对优势，但无论怎样，*终生成的代码仍然取决于人。 通过和确认。

4、软件测试：我觉得这个应用是*有前途的，尤其是面向代码的测试用例生成，因为提示词可以包含被测代码，包含了比较完整的信息，所以在单元测试用例生成中，会有API接口测试用例生成中的许多实际应用。 然而，在端到端测试中，测试分析和设计需要了解需求。 这时，如果不能实现需求的结构化或半结构化表达，测试用例设计生成效果就不会很好。 当然，测试用例设计完成后，利用设计生成自动化测试脚本还是有很大的想象空间的。

观点讨论

@平鑫：@李立 非常同意。 另外，我觉得软件维护和运维还需要了解软件系统层面的广泛抽象（例如架构决策以及云环境等系统运行的复杂系统上下文）。 这个大模型暂时也有缺点。 “在软件维护和运营方面，大型模型缺乏理解工程级项目的能力（受Token数量限制）和记住工程开发过程的能力。”

@李丽：@ 同意。 我感觉测试的实现场景非常好，可以直接运行代码看到结果。 然而，还有很多工作要做。

朱少民：

我可能很乐观，因为GPT4已经给人留下了深刻的印象，并且已经看到了大型模型的AGI能力。 从早期人工智能技术的一些应用到今天人工智能技术更加全面的应用，我们可以利用链式思维（CoT）等工程方法，从始至终地使用人工智能技术，贯穿整个软件开发过程，但是不同的任务有不同的方法。 性能方面，在编程和测试时性能会*好。

需求分析：好得力助手，做客户/业务数据分析、形成图表、整理/优化需求文档、帮助定义功能、生成用户故事、挖掘需求场景等； 软件设计：生成部分UI设计，更多成为设计顾问/顾问

实现编码：用得着的地方，大模型可以完成50%的代码，*终可以达到80-90%

软件测试：单元测试、接口测试和编程类似。 系统测试会弱一些，但也可以帮助我们生成验收标准、测试用例、测试脚本、测试报告等。

软件运维：微软等公司做了一些工作，可以参与日志分析、监控发现异常、问题分类和根因分析等。

另外，我还请他回答：

观点讨论

@平鑫：@《实现编码：能用的地方，50%的代码可以通过大模型完成，*终可以达到80-90%》

这个比例的提升背后可能存在一些困难：一些与架构、核心业务关系不大的外围代码更容易生成； 但由于边缘代码已被自动生成功能覆盖，因此在向中心移动时可能会遇到很多困难。 例如，需要大型模型来理解需求和设计，生成的代码越来越需要考虑如何将其嵌入到复杂的设计结构中（而不是相对独立地存在）。 因此，这个比率的增加不会是线性的，并且应该变得越来越困难。

//@朱少民：同意。 这也包括高级程序员的帮助。此外，人们也开始讨论适合GPT代码生成的架构，未来软件架构也将发生重大变化。

@何眠：需求过程中*大的挑战是准确描述需求。 我一直认为这是软件工程中*大的挑战。 CASE和MDA一直试图解决这个问题，但都没有成功。 业界的解决方案是“可执行的需求文档”，我认为是成功的。 但不受欢迎。

@朱少民：CASE，MDA解决不了的问题，可以通过人机交互智能来解决。

@江河：其实如果要求极其精确的话，编程就是编译器的工作了。 @何冕

@何眠：同意，大模型有机会帮助解决这个问题。

//@朱少民：同意，所以不要追求准确性。 软件的好处在于它可以不断发展。

@李丽：大模型直接忽略设计阶段。 如果需求极其精确，成本会非常高，不亚于自己写代码。

@何勉：我认为大模型有机会推动这个问题的解决，并且可以让BDD、ATDD等方法更加实用。 不要过于精确，但能够帮助收敛。

@李哥：同意。

@李丽：所以交互需求需要澄清。

//@朱少民：通过人机交互实现智能化。

@陈智宇：除了需求端驱动，别忘了测试端驱动，这有助于收敛。

@何眠：对。 大型模型应该有明确的收敛目标，例如测试验收条件和设计合同的清晰度。

@李哥：这一点我很同意，并且深信不疑。

@何眠：完全同意，但这是测试驱动的。 需要明确的是，这里的测试驱动是指验收测试驱动，而不是单元测试驱动。 也许行为驱动（BDD）不应该被误解。

@：接受条件ac需要细化到什么程度是另一个新问题。 我们也在尝试，还没有找到好的收敛方法，但是方向还是有希望的。

@何眠：这个BDD已经给出了例子。

@彭鑫：软件设计存在的原因主要来自于非功能方面

1）对于长期维护需求，考虑可扩展性和可维护性

2）出于运行时性能、可用​​性等考虑，考虑一些架构设计策略。 大模型时代软件开发中上述两方面的变化程度将极大地影响大模型的作用。

林凡：

我认为首先值得认可的是大型模型在软件生命周期的所有阶段都是有用的。 业界在这些方面做了大量的相关研究和探索，可以作为参考。

目前，软件开发过程中的任务根据任务的性质可以分为几种类型。

我把相关的研发任务分为三类。 对于专注于内容生成的任务，例如代码生成、测试生成和注释，大型模型已经可以达到甚至超过人类中位水平。 在这些领域，生成结果的可用性比结果的准确性更重要。 这就是大型模型*能发挥其优势的地方，有时甚至可以完全替代人类完成特定任务。

对于涉及部分内容理解的任务，比如需求的拆解和拓展、知识和文档的总结和打磨，大模型并不亚于普通业务人员。 但由于这样的业务场景，会出现很多不准确的情况。 完全数字化的暗知识和大型模型可以很好地辅助人类更高效地解决问题，但仍然无法实现完全独立的行动。

对于其他对结果精度要求较高的场景，由于大模型结果存在潜在的不确定性，我们无法真正信任大模型来完成任务，比如软件发布、运维变更等。模型可以提供一些参考信息，但*终的操作仍然需要人类来完成。

但我相信，随着大模型技术的进一步发展，这些界限可能会被打破，大模型可以覆盖的场景会越来越丰富。

观点讨论

@平鑫：@何眠，你能举一个你提到的“结构性变化”的例子吗？

例如，我们是否可以基于云原生平台、框架和低代码平台来实现更高抽象级别（接近*终用户）的应用程序开发？

@何眠：系统性的改变必须从两端开始，即需求和测试。 这是李革老师的观点。 李老师的解释非常深刻，我非常同意。 只有从需求出发，才能建立完整的脉络，并贯穿到后续的环节。 通过抓住测试，你可以建立一个更快的反馈系统。

@陈智宇：@何倬表示同意。

@何眠：问题到解决的过程就是需求的过程。

2

主持人：根据您的观察和了解，目前的大模式对软件行业有哪些实际影响？ 哪些工作正在萎缩或即将消失？ 哪些软件工程能力变得不那么重要，哪些能力变得更加重要？

王吉：

大模型正在重塑数千个行业，软件行业也不例外。 对于软件行业来说，软件工程的基本思想仍然会保留。 重要的变化是软件工程的各种活动将更加强调软件活动中的人机协作群体智能。 如今，大模型参与软件开发后正在努力提高生产力，但大模型的工作输出质量仍然需要系统的测量和评估。 不同的软件工程师使用大型模型得到的结果各不相同。 就岗位而言，目前还很难看出哪些岗位可以被大型模型应用完全取代，但有些岗位会随着生产力的提高而相对萎缩，比如“码农”。 但也应该看到，生产力的提高可以促进人们对于应用空间发展的巨大想象，进而引发更多的需求。 总体职位数量并不一定会减少，甚至可能促进大模型的应用。 许多更加高效、节能、可靠和安全的新工作。 软件工程能力总体来说还是很重要的，特别是软件工程基本原理的应用能力、工程决策能力、可信保障能力等软件工程的“核心”能力。 这些能力在大模型的人机协作中凸显出来，包括：利用大模型实现软件的快速设计、评估大模型的编码等。对于哪些能力重要性下降的问题，常识的重要性， such as API usage forms, and other will . In fact, it was not a core of . , are still , while . More , data- large model and have . For , you the of is to the level of after .

Ma :

There are two types of . One type does not reuse, or is even one-time. One type reuse in . These two types of have for clear .

I dare not say that I the . , the ideal I have come into with are all the and of large , and even the and lead the team to it. The of , doing like end-user , is in , now it is that large , as a means of human- based on , the "" I , end-user .

But at , LLM/AIGC has not seen any in terms of "". What LLM can do is the above- 1, the in-depth ( logic) of 2. So I think the to and solve such as , , and are still very . In , its in our field the of , and , reuse, basic of and , etc.

point of view

@Peng Xin: Well, large lead to a shift in the line labor and labor in .

Li Ge:

At , the role of large is in the stage. The first ones are those tasks with . In those that rely on or logic, large have not yet shown the of human labor. 。 If we want to make a , it is that more pure tasks will be by AI in the , and some may no a large of labor. This to the of in this area. will also . , " " work to or logic may more . At the same time, I also think that the to will more , in where code can be , code work that on human labor will not be able to meet .

point of view

@马晓星: The best paper of CVPR 23: The a way to use large for tasks in areas that rely on or logic. It is a to a DSL and let LLM this DSL.

@李哥: Yeah, let's go back and read the paper:)

@李丽: Ma has this paper times, and it seems that I have a lot. Be sure to read it later.

@ Zhu : Yes, go back and read the paper right away.

Wang :

The of large on the is still in its , and its truly has not yet , in:

Some basic code work will be , such as the of , CRUD and other codes.

The of some basic test cases will be .

such as and will be .

tasks such as and will be .

Entry-level work such as bug will be .

, the of will be .

that are by :

to use basic ​​and

and

Basic test case

bug and work

More :

and

In-depth of

and rapid

and

The of large on the is still in its early , and high-level are still very . work from work and its own value is an way to deal with large .

, the and can be :

tasks the most. The of large has on tasks such as image , , and , and has or some by the .

work fades away. in data such as data have been , and some work has been by large .

jobs face . need to deal with the data and by large and check their and .

The focus of work . need to pay more to how to with large , and , and .

point of view

@平鑫: @王昊fen It seems that Mr. Wang is not only an in AI, but also has a deep of . In the past few years, that AI would was a bit like wolf in the air, but after the of GPT4, it seems that the wolf has come.

, as Wang Ji said, on the one hand, some jobs will , but on the other hand, there will be more , and new jobs may also .

@李丽: But in the short term, it will be an for the until a wins.

Jiang He:

The equal-size model plays a role in to a . , all walks of life are large , the is the of large on the , and are the and faced by . One of my deep is that some large have begun to how to use large to . , was by , and were not .

I that large are for -level , and that a large of will be . With the of large , will , and the of may . It is worth that many of large are based on and task . and task are the work of , and this type of work be in the short term. In the , how to do , how to do , how to , etc. will .

Li Li:

of it has been that large can , the has the trend of All In large . At , the on the is on the major their to large and their . They are still in the stage of the high of large . It seems that few have begun to sort out which can be used by large . ( , dog head saves life).能够明确的是大模型能够赋能软件行业降本增效，但目前，大模型能直接解决问题的场景还比较有限，通常需要结合传统工具链完成（也就是大家所熟知的大模型的“插件”系统）。我认为这也是一个长期发展的方向，大模型适合解决的问题直接解决，传统工具链更适合解决的情况，大模型直接调用传统工具链解决。因此，传统软件开发工具链的构建任然需要，暂时还不能被大模型完全替代。不过能够感受到，提示词工程师的热度正在上升（不过提示词工程师的门槛视乎不高）。

不过在软件产品侧，尤其是某些垂类领域，已看到有被大模型替换的趋势，比如数据分析类、咨询服务类、教育类等产品。从事这些领域的软件工程人员，目前来讲，应该是机会，短期有爆发的可能。但长远来客，可能需求会明显减少。

不过长期来看，如果大模型按照目前的速度发展，可能很多普通的软件开发职位都会被模型替换掉。

观点讨论

@彭鑫：@何勉嗯，这个是SE for LLM-based 了。

@何勉：原来是有专门定义的。

何勉：

大模型对于软件行业的影响带来两个方面的变化：**个是软件的智能化（也就是智能化软件的开发），第二个是软件开发的智能化。

软件开发的智能化大家讨论的比较多了。我重点说软件的智能化，可能当前也更迫切，我在工作中就遇到很多挑战，其实蛮迫切的。

GPT（预训练模型）给软件行业带来的两个直接的变化。

**是交互方式的变化，自然交互已经成为可能，它会让软件形态和生态发生根本变化，其中一个就是过去独立各个应用的边界会消融，这是我们已经看到的变化。

第二是AI技术的平权，GPT极大降低了AI应用的经济门槛、数据门槛和技术门槛，今天的很多软件和系统都有机会应用AI改善自己的体验和效率。

这两个叠加，就让软件的智能化，成为GPT对软件行业*迫切的影响。所以如何开发智能软件，已经成为眼下非常迫切的问题。有一系列问题等着我们去探索，比如：

自然交互（包括自然语言和多模态等）该怎么设计，在LLM赋能下，过去分离的应用和系统该怎么融合，打造一个以用户为中心的全新体验。 就是一个例子

软件的智能部分怎么和"经典的结构化"软件配合，什么才是一个理想的Agent（智能体），智能体之间如何交互等等。

团队的协作方式和流程需要怎样的改变，比如在不确定更高的智能软件开发中，业务怎么和技术更好的协作。

如何应用好LLM，改造和开发带来全新体验的智能化软件，当前是一个很大挑战和机会。我认为这也是软件工程研究的范畴。

张刚：

我的理解和前面的老师们也差不多。从软件技能的角度， 就是“越简单的、越普遍性工作所受的影响越大”。

例如，当前不少企业把“人头”形式的外包作为人力资源的补充，但是和这类应用能形成很好的替代。

由于信息安全的原因，企业目前在大模型的能力做开发上目前还是很谨慎。但是这类问题迟早会解决，不影响总体趋势。

高级程序员和架构师、需求分析师等岗位的上下文更复杂，我理解当前还很难被大模型代替。不过，对于这类工作其实是有正面影响的。现在在软件开发领域，可以形成“超级个体”。以前我们总希望有通才型专家，现在这个是可能的。超级个体具备很高的效率，端到端，打通价值的能力。

此外，由于大模型带来了全新的交互方式， 也会影响架构，这些岗位更需要关注其中的范式迁移。

朱少民：

1.影响是显著的、全方位的，涉及软件行业的各个方面，包括软件产品、软件服务，会基于大模型产生一批新的应用，传统的call 、智能语音音响等智能系统都可能面临重构，重新再做一遍。

2.目前看，软件研发的岗位都在，只是团队规模可以缩小，人员比例会发生比较大的变化、多数岗位的初、中级人员可以大大降低，例如在目前工作量不增加的情况下，有领域大模型的（如需求大模型、代码大模型、测试大模型等）而且应用基础比较好的情况下，数据分析人员、编程人员、测试人员等可以减少20%-50%。

3.技术能力或具体的写代码能力、测试能力要求会下降，而综合分析能力、架构设计能力、复杂问题分解能力、评审能力、批判性思维能力、沟通协调能力等变得更加重要、需要进一步加强。

林帆：

我的回答比较简单。我们确实偶尔能看到新闻报道一些偏内容生产的行业，比如新闻、媒体相关的企业通过使用大模型节约了大量人力成本，替代了很多人工的工作。在软件行业里，大模型确实也极大的提升了开发者的个体战斗力，在有些比较通用的业务场景里，可以实现5倍乃至10倍效能提升。

不过我们也应当看到，这些大幅提效的故事基本都还是新闻里的个案，从现实的角度来看，我们还没软件行业有AI大规模替代人类的事情发生。正如产品名称一样，大模型对于开发者的参与更多还是以辅助者的角色出现，人依然是软件研发的主力，所以大家现在都还不用慌。

从更长远的视角来看，大模型一定会对软件研发的过程产生影响。我的猜测和之前的几位嘉宾差不多，在越是局部化的、规则化的场景，比如编写代码、编写测试的环节，大模型的参与程度会越高，发表的报告称在启用的文件中，有超过40%的代码是通过辅助生成的。反之，在越是偏全局性、经验性的环节，比如架构设计、产品验收，以及需要对结果负越大责任的环节，比如线上运维、运营决策等，越不会被大模型所直接取代。

观点讨论

@朱少民：技术上可行，但有其它影响因素。

例如，多数研发人员管理人员只想增加人，不会愿意减少人，所以优化人员的阻力会非常大。大家都乐意说，同样的人，干更多的事，结果做了一些没必要的功能、把产品做复杂了。

@马晓星：您提到的这个责任谁负的问题，非常关键。现在LLM/AIGC的特点之一就是不负责哈。

@彭鑫：@马晓星软件出问题，总是还是要有人背锅嘛。

@林帆：大模型大规模应用之后，责任谁来担也是一个值得探讨的事情。

@彭鑫：@林帆自动驾驶也有类似的烦恼。

@王戟：软件出问题，*后还是人背锅。

@朱少民：谁、谁交互的，谁负责。

@何勉：负责任的必须是人类，否则我就对人类的前途感到悲观了。

@江贺：大模型是辅助决策工具，*后还是要人来决策。

@何勉：前面有一个问题是什么样的职位会被替代，一个简单的回答是大模型时代的软件工程人才培养智能化软件开发微访谈·第二十五期，不需要负责任的职位会被替代。

@彭超：我觉得你们说的是大模型作为一个chat的助手是这样去用吧。但如果模型作为一个基座被包装成了一个服务，比如自动代码评审，这个功能的开发认为负责构造，比如“ the code {code}”，对于用户来说他不负责，他只负责拿结果、决定是不是采纳，如果生成的的结果不好，是用户负责，还是功能的开发人员负责，还是模型的提供方负责呢？如果大模型用来做客服机器人了，和交互都是客户，模型的输出结果是错的，难道也是客户负责吗？

@朱少民：给客户提供服务的是产品，产品正在进行交付的过程，如果有问题，是交付产品的人。而在软件研发过程中，围绕大模型构造的是研发工具（可能是购买的，页可能是二次开发的）。如果是二次开发的，总体水平不好，工具开发团队承担，但单个输出结果需要使用工具的人进行、验收。

@彭鑫：这个应该要看工具和用户的契约。如果工具承诺的是提供“推荐”，例如搜索引擎提供若干选择用户自己决定怎么利用，那么应该用户自己负责；如果工具承诺的是直接的自动化处理，例如编译器，那么应该工具（及其提供者）负责。

@彭超：赞同彭老师说的。大模型不仅仅可以作为辅助决策工具，要具体问题具体分析，一上来就让用户负责，用户都不敢用了。国家也提倡搞负责任的大模型。

@彭鑫：嗯，前两个问题都是从大模型技术发展以及对工业界软件工程师的影响的角度去讨论的。接下来让我们把视角转移到大学教育上，看看计算机和软件工程等相关专业的教育教学以及职业发展会受到什么样的影响。

3

主持人：据您的观察和了解，大学计算机和软件工程专业教育中的一些相关课程，例如程序设计、数据结构与算法、软件工程等，已经或将受到什么样的冲击和影响？

马晓星：

LLM/AIGC作为编程辅助工具、学习过程的资料查询、整理工具，引进到相关课程里面，恐怕是不可避免的。在计算机和软件工程的专业教育里，基础的程序设计、数据结构与算法，操作系统等课程不能削弱。但软件工程类课程可能需要进行较大的变革，以适应AI4SE 和SE4AI的时代需求。

王戟：

不同软件工程师使用大模型的产出参差不齐，说明了软件工程教育在大模型时代变革的重要性。课程受到冲击和影响需要分成不同的受众来谈，专业和通识。专业方面，课程受到冲击应该有两个方面。一个方面是素质能力培养的内容方面，现有的核心课程，程序设计、数据结构与算法、软件工程都是需要的，核心内容，计算思维的培养上不应削弱。依赖机械、重复的训练得到技能将更可能被大模型取代，高层抽象和批判性评估能力会更为重要。同时新的软件开发范式的教育需要变革，例如人机协同的群智软件开发范式，这里还涉及到相关的机器学习和AI知识的课程。另一方面，课程的教学和人才培养方式上，大模型是支撑智慧教育的*新技术手段，毫无疑问会提高人才培养的个性化和针对性，成为学生和教师的助手，变革现在的教学方式和手段。怎样强化不同层次的能力建设成为一个重要的课题。对于通识，软件工程在大模型时代的变革会使得相当一部分应用软件开发成为终端化/通识化编程，这样大模型支持下的数据驱动的计算思维能力和平台使用能力将成为重点，需要有新的探索。

观点讨论

@彭鑫：@马晓星但是从学习的角度呢？学生太容易从大模型那里获得帮助，从而弱化了编程等方面的能力的培养。

@马晓星：这个我倒不担心。我们不会纸带打孔，但也学会了编程。

@王戟：@马晓星软件工程课要做范式转型。

@马晓星：@王戟十分赞同。关键是咋弄。

@王戟：@马晓星突出人机协作的群智范式。

@彭鑫：比如，程序设计和数据结构这类课程是否允许学生通过大模型帮助来做课后作业？

@张刚：感觉这个和中小学生能不能用计算器来解数学题是类似的。特定的阶段不要用，越过了特定的阶段随便用。

@王戟：看什么阶段和什么场景了。上来就是大模型不可取。

@朱少民：要经常提醒学生，大模型的能力不是自己的能力。

@黎立：目前是不是也没有必要迈这么大的步子。

@陈振宇：大模型可以帮助老师布置作业。

@王戟：这个可以有，不过谨防出错题。

@黎立：反正都是大模型出的题，大模型求解，就算提出错了，大模型也能懂。

李戈：

上述课程的教学已经受到了大模型能力的影响，有好的影响也有不好的影响。一方面，我们会担心学生在提交作业的过程中利用大模型来自动生成程序，从而导致减少了思考和练习的机会；另一方面，AI在某种程度上也在扮演“提示员”或“助教”的角色，对于有些问题，学生们可以通过询问或类似系统得到及时解答，这有助于及时解决学生的问题，当然这里也可能会有输出“假答案”的风险。不过，我认为大模型是人类在软件开发领域的一个“工具”，我认为还是应该学会利用这个工具。因此，我们的课程教学内容和考核方式应该随之做一些改变。

王昊奋：

对大学计算机和软件工程专业教育可能受到的冲击和影响，我有以下几点看法：

程序设计课程需要加强对新编程范式的教学。大模型的出现可能会改变程序设计的方式。传统的手动编码可能会减少，而更多的关注可能会放在如何有效地使用和调试大模型上。因此，课程内容需要包括与大模型集成和使用相关的内容。

数据结构与算法课程的核心内容不会改变。大模型的出现并不意味着数据结构和算法的重要性降低。相反，对于理解和有效使用大模型，对数据结构和算法的理解仍然是必要的。因此，数据结构与算法课程可能需要强调与大模型相关的概念和技术。

软件工程课程可能需要包括与大模型相关的内容，如模型集成、模型测试和验证、模型优化等。此外，对于数据质量和隐私保护的重视也可能在软件工程课程中得到强调。

需要注意的是，大模型的出现并不意味着传统的计算机和软件工程课程就会完全被取代。传统的基础知识和技能仍然是非常重要的，而大模型只是为现有的知识和技能提供了一个新的工具和方法。因此，需要我们不断更新课程内容，以适应新技术的发展，并培养学生具备与大模型相关的知识和技能。

观点讨论

@彭鑫：嗯，我上学期软件工程课是允许同学们用大模型的，反正是迭代式、阶段性的课程项目要求，小组作业而且要在云开发平台上留下开发历史（代码提交、缺陷、测试等）

@何勉：重要的学习的过程，以及在过程的交互和领悟。

@彭鑫：@李戈嗯，可以类比计算器的影响。一方面小学还是要教算术，另一方面到了初高中有些课程和考试就允许学生用计算器起了。

@朱少民：小学生听话，大学生就没那么容易了。

江贺：

从我们周边大学的情况看，计算机类的这类课程还没有受到影响。但是，老师们都在讨论大模型的影响，我想未来的一些课程学时有可能会压缩，比如程序设计。同时，系统分析与设计类的课程应该要加强。

黎立：

我还是觉得大模型的能力还不能完成替代传统软件工程工具链，更多的是一种相互结合共同完成特定任务的状态。因此，软件工程工具链的基础课程，比如程序分析、数据结构等任然是非常重要的课程。

软件工程课程可能是一个例外，随着开发范式的不断变化，软件工程过程本身也在变化。大模型时代，以为中心的开发范式或将成为主流。该课程可能需要与时俱进，增加相应的内容。

观点讨论

@陈振宇：@黎立赞同，如何结合是难点。

@朱少民：@黎立咱们的观点基本一致。

何勉：

不做学生很久了，只能说我的观点。面临变化是，我们需要关注“革故”和“鼎新”两个方面，不过“鼎新”比“革故”重要的多。

先说“故”。“程序设计、数据结构与算法” 都是建立在“结构化”的世界观上的，这是我们看待世界和解决问题的方式，决定了我们的思维范式。结构化编程，面向对象编程，函数式编程都建立在这个世界观的基础之上。这是“故”，在可见的未来还是非常重要的。我不认为它需要被“革故”。在大模型时代，它依然会是重要的思维方式和解决问题的思路。

更重要的是“鼎新”。我们需要建立另一种世界观，就是“机器学习”的世界观。它与“结构化”的世界观中强调“明确的规则和算法”以及“结构化和模块化”不同，它强调从数据中学习模式和规律，并使用这些学习到的知识来进行预测、分类、决策和生成。我觉得我们应该把“机器学习”和“大数据”不仅仅当成一个技术，而是一个基础的思维方式和解决问题的范式，它是和"程序设计"对等的解决问题的思路。应该像“数据结构”、“算法”一样成为专业基础课。

我的观察是在今天的智能化软件开发中“机器学习”世界观非常重要的，但不容易建立，所以对高校有很大的期待。（这里“智能化软件”并不是一类特定的软件，我想未来绝大部分软件，或多或少都会有“智能化”的成分）

张刚：

总体来说，我的理解还是要重视基础。计算机专业本来也不只是培养学生的应用能力，更多的是全局理解，系统思维和方法论。我一直认为，在任何阶段，基本功都很重要，如果基础不牢，未来发展一定是受限的。所以，我觉得并没有削弱程序设计、数据结构与算法等等的重要性。但是，这里的重要更多的是思维层面和认知层面。

第二个部分是，对于各种繁琐的细节，确实不需要知道那么多了。 所以，在教学中更好利用大模型的能力， 减少那些常识性的、记忆性的知识，关注”懂“，而不是”会“， 可能是有必要的。

软件工程自身可能会因为大模型的到来发生不少的变化。 毕竟软件开发是一种智力活动，现在来了一个新的、有点全能的智力活动参与者，所做的产品又可能是融合了大模型的交互、融合了大模型的架构的，玩法肯定不一样了。

所以，如何把大模型和软件工程有效融合，这个期待方法论上的更新。

观点讨论

@彭鑫：是，越来越多的系统中会是AI模型会和传统的代码模块共存的局面。

朱少民：

课程的具体知识教授没那么重要，而课程知识结构的建立、分析问题的思维训练、解决问题的能力训练等显得更加重要。我过去几年一直提倡“问题驱动教学模式”，在大模型时代更具有价值、更值得践行。

对《程序设计》、《数据结构与算法》等基础性课程影响比较小，但对《软件工程》、《软件项目管理》等偏工程方法、项目管理的课程影响比较大，这类教材可能要重写，就像过去，我们开始写《现代软件工程》的教材，现在需要写符合新时代特征的《软件工程3.0》教材。

观点讨论

@李戈：问题驱动教学模式。

@茹炳晟：同意。

@王昊奋：我们一直在尝试PBL。

茹炳晟：

llm的出现我感觉不会动摇计算机基础课程的重要性，这是基础。

4

主持人：大模型和人工智能技术的发展将对大学计算机和软件工程等相关专业带来什么样的影响？这些专业的培养目标、课程设置以及相关课程的教学方式与方法应当如何调整？

马晓星：

要说有啥影响，首先从社会认知上，计算机，特别是软件工程，不再是*热门、*前沿的了，AI才是。

计算机科学技术，作为母学科，总是还有自身的一亩三分地；软件工程这个学科，以及这个职业，本来从计算机中分离出来就有些勉强；现在智能化大潮来了，软件工程如果不及时变革，恐怕会有一些的危机– 不是说不需要了，而是成为一个工具性的、支持性的行当，可能会相对边缘化。

为此，我认为，必须把人才培养目标从传统的以“信息化”为核心转向以“人机物融合智能化”为核心。“软件定义一切”是实现人机物融合的途径。随着这一趋势走向深入，系统复杂性向软件集中。我们培养的学生，将来要解决的问题比原来的软件开发要复杂得多。这要求对整个软件工程专业人才培养体系进行改革。我们也在摸索之中。

我个人一点初步思考是，人机物融合系统的构造运维，除了涉及传统的计算机和软件，还要面对不确定的人和物的部件。除了传统软件这种大致属于符号主义的智能实现方式之外，还可能用到神经网络（连接主义）、反馈控制（行为主义）等智能实现方式。为此，也许我们一方面要加强概率论、博弈论、随机算法、*优化方法、机器学习、模式识别、数据挖掘、人机交互、物联网等智能化课程，另一方面也要朝系统工程的方向拓展软件工程的内容。但说增加是容易的，难的是如何在有限的课程体系内做到这些。

观点讨论

@彭鑫：确实，新一代软件工程人才不能还是只关注于信息化和互联网软件系统，而是要以软件思维去思考更加广阔的人机物融合系统的问题了，具体到课程设置上可能要加强以机器人、智能汽车、工业生产线等新型信息化载体上的软件系统开发和运维了。

@李戈：马老师还是很敢直言的。

@王戟：这个影响不是LLM造成的，之前就有。

@彭鑫：我觉得管理学也可能涉及，因为人也在系统中，因此可能产生“软件定义的管理学”。

@黎立：非常同意马老师的观点，软件工程学科本身需要更多的突破。

@何勉：这一拨“连接主义”相对“符号主义”之争，带来冲击和思考。相应的软件工程当，我们非常有必要反思“软件工程”的基础理论和实践。

王戟：

大模型和人工智能技术的发展对计算机和软件工程专业的影响是变革性的，所以培养目标上会有新的期待，包括AI4SE，以及SE4AI。相应的专业课程设置需要有新的变化。例如需要增加关于大模型基础和技术方面的内容，注重交叉领域知识和能力的培养。具体实施的方法和方式有多种，例如工程和编程可以是增加课程，也可以是增加原有课程的教学模块，还可以是通过大作业项目的训练和实践等等。同时，大模型的引入对教学效率的提高，一些传统课程课时可以减少甚至合并，把时间放在核心能力的培养上。值得注意的是，大模型对教学的变革也需要一个稳健的策略，不能一哄而上，带偏了。例如，大模型产出的质量能否满足教学要求，大模型依然需要相应的成本。可以先探索将大模型作为教学工具引入，然后观察和总结大模型在教学方法、教学内容、教学理念等方面带来的改变。软工也在关注大模型产出的质量以及大模型训练和推理的绿色节能等重要问题。教学变革的实施中可能会遇到客观条件的制约。

王昊奋：

大模型和人工智能技术的发展,我认为会从以下几个方面影响相关专业：

培养目标上，需要更加强调算法思维能力、数据思维能力和人工智能尤其是大模型应用能力的培养。

课程设置上，课程设置可能需要调整，以便更好地覆盖人工智能和大模型相关的内容。新增或调整的课程可能包括机器学习、深度学习、自然语言处理、计算机视觉等。此外，还可以增设以人工智能和大模型为主题的专业选修课程，以满足学生个性化的学习需求。

教学方式上，增加案例教学、项目教学、竞赛教学等形式，启发学生的创新思维。

教学方法上，加强对在线资源、开源框架和平台的应用，鼓励学生动手实践。

加强人工智能前沿技术和发展方向的跟踪，及时调整课程内容，不断优化人才培养方案。

积极组织学生参与人工智能相关课题和项目研究，培养学生的研究和自主学习能力。

加强与企业的合作，了解企业对人工智能人才的需求，并积极邀请业内专家进行教学。

人工智能和大模型涉及多个领域的知识，增加跨学科的合作。鼓励计算机和软件工程专业与其他领域如数学、统计学、心理学等进行交叉学科合作，以培养学生多领域的综合能力。

江贺：

我比较关注的是从业人数的需求可能会下降。已有产业的技术进步，通常会带来就业需求的下降。可能3-5年后，我们就不需要招收这么多学生了:(。同时，我们的课程要适应在大模型工具下的开发实践。我们可以把大模型工具看成是一个水平不稳定的结对编程伙伴，程序员可以随时低成本地给它安排任务，但是它不能确保一定正确。怎么循循诱导这样的伙伴，本身也需要学习。未来，可能我们还会衍生出提示工程这样的课程。

黎立：

对于课程设置，我个人相对保守。大模型的到来，并没有简化计算机和软件工程人员需要学习和掌握的知识，反而是需要学习的知识变得更多了。因此，我认为大部分现有的软件工程课程还应该保留，但是需要逐步引入大模型相关的课程（包括大模型训练/推理优化经验、大模型应用框架、以为中心的软件开发等）。

教学方式上可能也需要有一些变化。比如学生可能通过等大模型协助学习以及完成相应的课后练习，怎么利用好大模型资源而不是限制其使用，是一个需要探讨的问题。

张刚：

对于这个问题，我理解到了两个方面：

1， 大模型更好地支撑软件工程教学。大模型对于专业能力的培养带来了更多可能。 在实践教学上，软件工程的教育其实是比较难做的。因为它讲的更多是方法论，为了理解这些方法论，需要一些练习项目做支撑。考虑到总的学习周期，这些题目要么就很小，或者较大的题目，学生的负担就比较重，走不了几个循环，很难在短期内建立对软件工程的深入理解。 大模型能让具体的工程项目更快落地，也就加快了学习循环，能让“探究性学习”成为可能app开发，有些令人兴奋的想象空间。

2， 在软件工程教学中融入大模型的方法体系。需要充分考虑大模型引起的软件形态和架构层次的影响，甚至是软件生态层次上的影响。这个演进可能很快。 这部分知识目前肯定还没有进入专业培养体系，因为是新事物，大家也都在探索。这方面我觉得，或许也值得老师们和同学们一起探索，比如一些开放性的探究课程， 或许对于这种快速发展的领域能有更快、更好的效果。

观点讨论

@彭鑫：@张刚**点说的特别好，比如精确的需求表达的价值可能借助大模型很容易就让学生看到了

何勉：

关于“软件工程”，我们可能需要反思的更彻底。首先是“软件工程”这个词是诞生在**次“软件危机”1968年NATO的软件工程会议。为了应对“软件危机”，我们希望从工程方法中借鉴经验，比如：系统化的设计和实施，严谨的计划和管理，追求标准化的顺序过程等，强调结构化的分解和后续的合成。我们把软件开发当成一个“工程问题”，这样的认知会决定了后续行为。

软件开发中有“工程问题”的成分，但*本质的真的是一个“工程问题”吗？

它更可能是一个“复杂系统”和“知识创造过程”，或者说是：在“复杂系统”中进行不确定的“知识创造”和探索的活动。如果，这是一个事实，那我们对解决问题的思路就会非常不同，比如在“复杂系统”中你一定要承认系统地“复杂性”，不要试图用机械的方式去管控，而是要：1）要想方设法缩减行动和（有意义的）结果在空间和时间上的距离；2）建立即时和有效的多层次的伺服和反馈机制。

团队的成功就很值得研究，我认为它就是在复杂系统中取得成功的范例。我*近在做智能软件的开发，我感觉这个问题就变的更加突出了。

大模型引入一方面带来“智能软件”让这个问题变的突出；但是我觉得“软件开发的智能化”有机会一定程度解决这个问题，我也认为，“智能软件开发”带来的新模式和范式也应该把软件开发看成“在复杂系统中进行不确定的知识创造和探索的活动”，LLM完全有能力让在“复杂系统”中进行不确定的“知识创造”和探索的活动过程更高效和有效，其核心就是1）在LLM辅助下建立更即时有效的反馈；2）维护始终统一的上下文，缩短行动和结果反馈之间的空间和时间距离。

观点讨论

@邹欣：插一句，这个要谈“银弹“ 问题了。

@黎立：或者更本质的问题，还是要讲清楚，软件工程，相较于其他兄弟学科，特点在哪？研究界也一直很关心这个问题。

@何勉：是的，这是软工的一个根本问题，关于问题是什么的问题。

@邹欣：我认为，化学系/化工系的区别，可以类比为计算机科学/ 软件工程的区别。 还可以参考《工程学，无尽的前沿》

朱少民：

有积极的影响，也有挑战，特别是对大学计算机和软件工程等相关专业的老师更有挑战，因为像这样的工具，比我们的老师懂得多，学生可能会去问它，而不问老师、不和老师交流。

培养目标（如12项工程能力）基本不变，可以微调。但课程设置会有较大改变，例如会增加大模型、提示工程、批判性思维等课程，具体设置需要时间研究、需要集体研究来决定。教学方式，侧重问题驱动教学方式，以学生为中心，教师精心设计问题，把问题抛给学生去分析、去解决，真正提升学生的思维能力、动手能力。

观点讨论

@黎立：确实。需求工程这类课本身还是比较抽象的。能够借助大模型展示直观的例子，就能让学生快速理解。

林帆：

我的感觉是，大模型会带来的改变可能来自两个方面，一是学科内容，二是授课的形式。 ,

学科内容方面的影响主要会来自业界软件开发实践的具体变化。比如对于“软件工程”的课程，过去我们关注的都是人与人如何协同的问题，从瀑布到敏捷一直如此，未来我们就要考虑如何把各种专家大模型融入到软件研发的过程里面来。比如花更多精力在需求描述和架构设计上面，把开发、测试这些以往*耗时间的工作交给大模型，软件的研发流程和迭代周期可以进一步缩短。因此相应的课程内容也就需要与时俱进。相应的在“程序设计”这样的课程里面，学生不仅要知道怎样先代码和怎样将代码变成程序，还要知道在不同的场景下，怎样利用大模型来更快的实现程序，也就是和大模型协同的技巧。

,

授课的形式方面，大模型本身也是一位很好的学科老师，不仅能够快速解决各式各样的技术问题，还能根据不同学生对知识理解的程度，千人千面而且不厌其烦的用不同方式辅导学生理解特定的知识点。因此在课程设计的时候，如果能够更好的利用大模型这位“助教”，也许能够帮助更多同学提高自助探索问题的积极性，让学习的过程变得更有趣。

对于软件专业这个学科。可以肯定的是，计算机和软件专业是距离大模型行业*近的相关专业之一，大模型蓬勃发展，一定会对软件专业的发展起到正向的、利好的作用。

具体到大模型会对大学的课程设计和专业定位的影响，我觉得还是要分类来看。

一类是基础原理性的课程，还是需要踏实的学。大学的目的是教会学生系统性的知识，就像在大学本科有计算机组成原理这类课程，即使现在几乎没有人会直接编写汇编程序了，但如果要把高级语言理解透，搞懂内存的工作方式、CPU的工作方式依然十分必要，汇编的知识依然会有帮助，不然就是空中楼阁。

另一类是偏实践性的课程，比如软件设计、数据库应用等等，我们不但应当让学生掌握大模型的原理，还应该鼓励学生通过大模型来更快、更好的解决实际问题，让大模型进入课堂。站到巨人的肩膀上很重要，大模型和人工智能现在就是这样的一位巨人。

茹炳晟：

我的核心观点是：对大模型的有效使用是关键，能顾熟练使用提示，将大模型作为工具将成为我们必备的技能，所以应该要有这样的学科设置让我们学会清晰的表达需求。

5

主持人：您对计算机和软件工程专业的同学们有什么建议？为了更好地适应大模型时代软件工程师的要求，他们应当着力打好哪些基础、发展哪些能力？

王戟：

大模型是变革性的使能技术，计算机和软件专业的同学们需要积极的拥抱这个变化。大模型会重塑软件工程范式，人机协同群体智能的新范式会有重大进展。另一方面，或许更为期待，就是软工能在大模型的发展历程中发挥更重要的作用。软件毫无疑问是大模型的基石，而大模型在未来软件系统和生态中有重要位置。软工能做什么，能为构建更好、更节能的大模型做出什么贡献，是个重大课题。同学们应该为此而努力。为了适应这个要求，可用“守正创新”粗略的概括。守正就是计算思维能力、程序语言和形式化能力、编程能力、平台能力需要加强，我们需要有能构建新一代大模型的人才。创新就是我们需要学科方向的交叉，软件工程与人工智能的交叉，特别是符号推理与数据驱动的交叉，需要打好机器学习和人工智能的基础，软件人才一定会是复合型的。未来的软件人机物泛在融合，在系统、形态、价值、生态等方面有新的内涵或外延，大模型本身也将成为未来软件系统和生态的组成，需要我们能积极主动的融合多个方向上的使能技术。同学们需要为此准备起来，打好软件思维基础，熟练构造和使用先进平台与工具，养成反思的习惯。

观点讨论

@陈振宇：赞同。

@李戈：软件毫无疑问是大模型的基石，而大模型在未来软件系统和生态中有重要位置。软工能做什么，能为构建更好、更节能的大模型做出什么贡献，是个重大课题。同学们应该为此而努力。

@黎立：人机协同群体智能，推荐2023软工十大热点词之一。

@彭鑫：人机物融合也是今天晚上的热词。

@王昊奋：也是CNCC论坛中好几个论坛提到的关键词。

@马晓星：我对问题看法和王戟老师基本一样的，就是学好现有的课程；积极拥抱大模型这样的新生事物。

@彭鑫：其实很大部分在于软件哲学。为此，我们需要在软件工程的“哲学”思想基础上结合具体的领域，例如智能制造、智能机器人、智能汽车，去好好实践并探索出某个领域里面的具体软件工程方法和技术。

李戈：

软件是现实世界的解决方案在计算机系统中的映射。软件开发工具的更新迭代，并不能改变软件的这个属性，因此我建议以软件开发为专业的同学，可以更加注重对“所在领域问题域”的认知，加强对“解决方案设计能力”的提升，而不仅仅止步于对编程语言的熟练应用，同时，也要意识到软件开发是一个复杂的过程，软件工程也是一个内涵丰富的学科，不会因为某个技术的推出就颠覆。所以我们既要积极拥抱新的开发工具和技术手段，又要对软件工程的基础理论和技术保持充分自信，同时AI软件的产生也会给软件工程带来新的内涵。

王昊奋：

对计算机和软件工程专业的同学，我有以下几点建议：

打好基础。坚实的计算机基础知识仍然很重要，比如数据结构、算法、操作系统、计算机网络等，这是做好一切的基础。编程是软件工程师*基本的技能之一，要掌握至少一门编程语言，并学习其核心原理，不要停留在语法层面，这将有助于你理解和优化大模型的底层实现。

多学习一些前沿的技术。大模型的发展与数据科学和机器学习密切相关。了解机器学习的基本概念、常用算法和工作流程，学习常见的数据处理和特征工程技术，可以帮助你更好地理解和应用大模型。另一方面，大模型往往需要在分布式系统上进行训练和推断，因此对于分布式系统和高性能计算的理解和应用是必要的。学习分布式系统架构、并行计算和高性能计算技术将帮助你更好地处理大规模数据和复杂计算。

多实践。除了技术知识，良好的软件工程实践也非常重要。学习团队协作、版本控制、测试和调试等软件工程的基本技巧，以及敏捷开发和持续集成等现代开发方法，能够提高你的开发效率和代码质量。

持续学习和创新思维。大模型以及整个软件工程行业都在快速发展变化，所以要有持续学习的意识并保持创新思维。密切关注领域的*新动态，参与开源项目或者参加相关的竞赛、会议等活动，不断提升自己的技能和知识。

总而言之，打好计算机基础，学习前沿技术并付诸实践，同时培养终身学习的意识和思维方式，具备系统设计和工程实现的全局观，是应对未来发展的关键。

江贺：

积极拥抱变化。大模型的出现和演进是一种历史进程，无论我们喜欢与否，大模型时代已经来了，与其消极回避，不如积极应对。我们的同学一方面要学习好程序开发的基础课程（比如数据结构、程序设计等），另一方面，要积极用好这个新工具，掌握类似提示工程这样的课程。

黎立：

无论是否是在大模型时代，软件的基础是代码。因此我建议计算机和软件工程的同学们任然要打好代码基础，数据结构、算法、操作系统、程序分析等核心基础课程要学好。

当然，在学好基础课程的前提下，我建议同学们对大模型的理论基础有一定的了解，并动手尝试一些以大模型为基础的新型软件开发范式（比如, )等。

感觉现在的大模型已经成为风向标了，学生都会非常感兴趣。反而应该多鼓励学生们沉下来，多把软工基础课程学好。

观点讨论

@朱少民：是，需要更扎实的基础，否则更有风险。未来竞争更激烈，更需要好的基础，才能长出更强的能力。不过，“基础”要包含哪些内容，值得探讨、探索。

@彭鑫：系统也很重要，同学们需要树立“软件不是存在于真空之中，而是存在于一个复杂系统上下文之中，并且会随着时间推移不断演化”的观念。这里的系统既包括软件运行所处的软硬件环境（例如云平台及相关软硬件基础设施），又包括软件所处的更大范围的社会物理系统。

@林帆：是的，玩都很容易，但真正能玩出高度来，还是要靠过硬的基本功。

张刚：

我有两个建议：

大模型带来了应用形态的范式级迁移，毫无疑问， 需要更多关注大模型带来的影响，以及由此产生的创新机会。

关注基础能力。大模型对于软件工程来说， 更重要的是能力增强，是生产力的提升。我把它看作是一种能力放大器。它有强者恒强的效果。所以，需要更好的打好基础，特别是基础的问题定义、问题分析和抽象的能力，对架构和设计的理解的能力等等。

何勉：

学好专业课和专业的基础课依然是重要的，同样重要的是领会其背后的价值观，解决问题的范式。“机器学习”显然是一个新的范式，应该成为软工和计算及专业的基础，需要深入的学习理解。它是计算机和软件工程的一个变量，变量往往意味着机会。

刚才群里有一个支线，好像是关于谁负责、谁背锅的问题。这一点很重要，作为人类一定要对自己的决策和行为负责，这是人类的*后底线。你能负多大责任才能获得多大的回报，今天的学习和实践就是为将来负起更大的责任。

朱少民：

1）拥抱变化，带着好奇心了解新生事物，与时俱进；

2）同时还是要打下坚实的知识基础，不能依赖大模型，而且分析问题和解决问题的能力还是要建立在自己拥有的认知和知识的基础之上的。

3）打好基础：数学、数据结构与算法、面向对象的分析/设计/编程、编译原理等依旧是重要的基础课程，好好学习，深刻理解；

4）重在能力的培养：对计算机/软件发展等正确的认知，计算思维、分析性思维、批判性思维、创造性思维、工程思维等一系列思维能力，发现问题的能力、洞察力等。

5）和我一样，持续学习、终身学习。

林帆：

其实未来的这一代学生可能大模型玩起来比我们还溜，毕竟他们才是智能化原生的一代。现在的同学都很聪明，不用我们太过操心。只要挑选出*好的大模型，把它们介绍给同学，然后多给他们实践的机会，相信他们很快会发明出比我们能想到的更有创意性的用法。大模型的潜能还要很多值得挖掘的地方。

“Hi，这是*新的大模型MOSS，请多关照”

就是这样。

上面是有点开玩笑的话，回正经来说，我觉得对于学生来讲关键的就两点。

**是培养兴趣，对大模型有兴趣，对新技术有兴趣，然后在玩的过程里，去理解智能化是怎么回事，有哪些局限和问题，然后去探索、去解决相关的难题。

第二点就是打好基础和多动手，光有兴趣和动力还不够，得踏实花时间把原理弄清楚，练好数学、算法这些基本功。*后就是要实践出真知毕竟软件不像物理、化学这类理论性毕竟强的学科，软件光靠想没有用，需要拿出实际的作品出来。

观点讨论

@江贺：未来，学生毕业就是“导师”了，大模型的导师。

茹炳晟：

我的核心观点是：大模型时代，软件工程的关键会更偏向需求工程和知识沉淀，同时计算机的基础理论继续保持其原有的重要性。以前你会编程就可以做软件工程师，现在你的知识结构必须更加多元化，才能做好软件工程。

访谈结束

一个有知识的软工公众号

发现智能化编程之道

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等