智能化软件开发微访谈·第三十七期 DeepSeek火爆出圈对于软件产业影响几何？...-CSDN博客

CodeWisdom

DeepSeek火爆出圈对于软件产业影响几何？

微访谈 · 第三十七期

背景介绍

近期，DeepSeek推出的R1版本凭借其卓越的推理能力和创新的技术架构在智能助手领域迅速崭露头角，在春节期间成为各方关注和热议的焦点。很多人认为DeepSeek高效处理复杂任务的能力、显著的成本效益以及所采取的开源路线有望带来大模型部署及应用的普适化，由此对各行各业带来重要的影响。那么，DeepSeek火爆出圈对于软件产业会有什么样的影响？大模型的普适化部署及应用是否会带来软件产品及应用形态的变化？大模型强大的推理能力是否会颠覆现有的软件开发模式？面向未来，我们需要培养什么样的人机协作能力？围绕这些问题，我们邀请了多位来自人工智能和软件工程领域的学术界和工业界专家共同探讨和交流，希望能对当前的发展浪潮与未来的发展趋势有一个客观冷静认识和理解。

主持人

彭鑫

复旦大学

复旦大学计算机科学技术学院副院长、教育部长江学者特聘教授。中国计算机学会杰出会员、软件工程专委会副主任，《Journal of Software: Evolution and Process》联合主编（Co-Editor），《ACM Transactions on Software Engineering and Methodology》、《Empirical Software Engineering》、《Automated Software Engineering》、《软件学报》等期刊编委。2016年获得NASAC青年软件创新奖，2023年入选上海市东方英才拔尖项目。主要研究方向包括软件智能化开发、云原生与智能化运维、泛在计算软件系统、智能网联汽车基础软件等。研究工作多次获得IEEE Transactions on Software Engineering年度最佳论文奖、ICSM最佳论文奖、ACM SIGSOFT杰出论文奖、IEEE TCSE杰出论文奖等奖项。担任2022年与2023年CCF中国软件大会（ChinaSoft）组织委员会主席与程序委员会共同主席，以及ICSE、FSE、ASE、ISSTA、ICSME、SANER等会议程序委员会委员。

访

谈

嘉

宾

邱锡鹏

复旦大学

复旦大学计算机学院教授，担任中国中文信息学会大模型专委会副主任、中国人工智能学会自然语言理解专委会副主任，入选中国高被引学者和全球前2%顶尖科学家榜单、教育部“高校计算机专业优秀教师奖励计划”等，获钱伟长中文信息处理科学技术奖一等奖（第一完成人）、CCF-ACM青年科技奖等奖励，主持国家优青、科技创新2030重大项目课题、上海市基础特区等项目。主持研发了多个高影响力大模型MOSS、SpeechGPT、AnyGPT、InternLM。著作《神经网络与深度学习》被上百家高校作为教材。

王昊奋

同济大学

同济大学百人计划特聘研究员，博士生导师。他是全球最大的中文开放知识图谱联盟OpenKG轮值主席。他负责主持多项国家AI专项，发表100余篇AI领域高水平论文。他构建了全球首个可交互养成的虚拟偶像—“琥珀·虚颜”；所构建的智能客服机器人已累计服务用户超过10亿人次。目前，他担任中国计算机学会术语工委副主任，自然语言处理专委秘书长，信息系统专委常委，智能机器人专委会执委；中国中文信息学会理事，大模型专委会指导委员会委员，语言与知识计算专委会副秘书长；中国指挥控制学会大模型专委会常务委员；上海市计算机学会自然语言处理专委会副主任等社会职位。

熊英飞

北京大学

熊英飞于2009年从日本东京大学获得博士学位，2009-2011年在加拿大滑铁卢大学工作，2012年加入北京大学，现任新体制长聘副教授、软件研究所副所长。熊英飞的研究兴趣是程序设计语言和软件工程，特别是程序合成、修复、分析和验证。他的工作帮助产生了一系列不同规模的效果同期最优代码生成神经网络模型，如DeepSeek-Coder模型；大幅提升了缺陷修复的正确率、修复数量和修复效率；提出了最广泛使用的两大双向变换模型之一——基于差别的双向变换；成功自动求解大量算法问题，包括世界顶级算法竞赛中的问题。他的工作也被工业界采用，比如华为公司、中兴公司、新一代Linux内核配置项目等。他在OOPSLA担任副主席、ASE担任领域主席、IEEE TSE担任编委，PLDI、ICSE、FSE、OOPSLA、ASE、ISSTA等会议定期担任PC，5次在ICSE和FSE会议上获得杰出审稿人奖。他承担了优青、青年973、重点研发课题等科研项目。他获得国家技术发明一等奖（排名6）、电子学会自然科学一等奖（排名1）、CCF-IEEE CS青年科学家奖、MODELS十年最有影响力论文奖，5次获得ACM SIGSOFT/IEEE TCSE杰出论文奖，是IFIP WG 2.4唯一来自中国的成员。

张海龙

Gru.ai

Gru.ai CEO、开源中国联合创始人、CODING 创始人。复旦大学软件工程学士、CMU 计算机硕士。主导的新项目 Gru.ai 旨在创造全自动的软件开发 Agent，提高软件工程效率，在 Openai 主导的测评 SWE-Bench-Verified 中以 45.2% 的高分排名第一，在 Coding Agent 领域处于世界领先地位。

茹炳晟

腾讯

腾讯Tech Lead，腾讯研究院特约研究员，腾讯集团技术委员会委员，中国计算机学会(CCF)TF研发效能SIG主席，“软件研发效能度量规范”团体标准核心编写专家，中国商业联合会互联网应用技术委员会智库专家，中国通信标准化协会TC608云计算标准和开源推进委员会云上软件工程工作组副组长，国内外各大技术峰会的联席主席，出品人和Keynote演讲嘉宾，公众号“茹炳晟聊软件研发”主理人。著有多本技术畅销书《测试工程师全栈技术进阶与实践》《现代软件测试技术之美》《软件研发效能提升之美》和《多模态大模型技术原理与实战》等，译有《软件设计的哲学》《整洁架构之道》《现代软件工程》和《DevOps实践指南（第2版）》等。

陈鑫

阿里巴巴

阿里巴巴资深技术专家，负责通义灵码和阿里云云效产品技术，致力于企业研发效率、产品质量、DevOps方向研究和探索。在阿里8年带领过大数据测试团队、测试工具研发团队、软件研发平台团队。对研发协同、测试、交付、运维领域都有很深的见解。目前正在带领团队向极致效率、智能化、公有云等领域进行持续演进。

张伟涵

华为

华为公司云核心网产品线业务主管&技术专家。历任软件总工、产品代表、工程部部长等岗位。10+年核心网业务经验、参与2/3/4/5G网络代际演进、架构设计、产品孵化&落地等工作，具备丰富的网络架构、软件架构、产品化经验。当前主导软件能力建设及智能化软件工程构筑，专注于软件技术、软件工程、AI等领域的理论研究和工程实践。

刘焕勇

360人工智能研究院

360人工智能研究院知识图谱及文档理解算法方向负责人。曾就职于中国科学院，主持研制全行业事理图谱、360百科图谱、知识图谱平台、360版式分析模型等项目，360智脑大模型前核心成员，申请发明专利十余项、论文数篇，对外开源项目70余项。近年来在OGB-Wikikg2实体链接、ICPR多行数学表达式识别、CCKS多模态实体对齐、可解释类案匹配等评测中获得多项冠亚军，创立老刘说NLP技术社区，具备广泛影响力。

李彦成

开源中国

开源中国、Gitee研发总监，负责开源中国Gitee DevOps研发效能平台产品研发管理工作，前百度研发效能专家，百度效率云技术负责人，信通院标准专家。荣获22年度信通院优秀标准专家，OPU23年度优秀开源人物。2014年-2023年，DevOps领域工具研发工作，百度效率云技术负责人。2023年7月，加入开源中国，聚焦企业级DevOps平台产品，开源中国研发总监。

彭超

字节跳动

字节跳动软件工程实验室技术专家。2021年博士毕业于爱丁堡大学并加入字节跳动。研究方向包括LLM4Code、软件测试、程序分析等，主要负责代码模型的评估工作。在ICSE、ASE、FSE、ICSME等会议上发表数篇论文，担任FSE等会议PC成员。

魏昭

腾讯

腾讯代码智能资深专家，代码智能化算法团队负责人，多年一线大厂智能化算法，产品研发经验。带领团队持续训练和优化混元代码大模型，持续提升基于llm的代码补全/生成、仓库级代码生成，CR 生成等行业领先的代码能力，以及工蜂代码导航/搜索，代码智能冲突消解，补丁智能分析等算法和工蜂Copilot产品，并在公司内规模化应用。在国内外知名会议、期刊(含 FSE、ASE、ISSTA 等顶会)发表学术论文 18 篇，申请发明专利 16 项，其中授权 9 项。

王翀

南洋理工大学

南洋理工大学博士后。王翀分别于2023年和2018年从复旦大学获得博士学位和学士学位，现于南洋理工大学任博士后研究员。他的研究方向为智能化软件工程，致力于应用大模型和知识图谱等前沿智能化技术解决软件开发维护中的实际问题。他已在软件工程领域的顶级会议与期刊（ICSE、FSE、ASE、TSE、TOSEM等）发表于多项研究成果，并在ICSE和FSE担任PC。他曾获得上海市CCF优秀博士论文奖及IEEE杰出论文奖等奖项。

访谈主题

春节期间，DeepSeek火爆出圈。同时，我们也看到这次在知乎、CSDN、Reddit等问答社区的讨论量比社交平台传播量高大概30%-40%。您是如何看待这一现象的？您认为这一现象反映出哪些市场或技术趋势？DeepSeek哪些方面的特点和特性令您印象最深刻？

以OpenAI O1/3和DeepSeek R1为代表的推理模型所表现出的慢思考和长推理能力与此前的大模型相比有什么特点和优势？一些观点认为过度慢思考，尤其是超长步骤或特别绕（啰嗦）的思考过程可能会起到反作用，您如何看待这一点？在实际应用中，您觉得这种能力能否转化为更高的实用性？这方面的能力将对哪些领域和应用场景带来重要的影响？

很多人认为近期以DeepSeek为代表的技术进步将带来大模型部署及应用的普适化，这将对软件产品及应用形态产生什么样的影响？一些行业已经喊出了“去APP和Agent化”的口号，对此您有什么看法？基于大模型的Agent将会成为未来软件产品及应用的主流形态吗？Agent是否仅适用于特定领域，如果应用于复杂软件系统中是否会带来潜在风险？

以OpenAI O1/3和DeepSeek R1为代表的推理模型在软件工程（包括软件开发、运维、测试及质量保障等）领域的表现如何？大模型强大的推理能力是否会颠覆现有的软件开发模式并对就业市场造成重要的影响？

未来，大模型将在软件工程领域发挥重要的作用，那么我们应当如何认识人（包括软件用户与软件工程师）与大模型的关系？软件工程中哪些环节适合基于大模型的自动化处理，哪些环节需要人机协同增强，哪些环节必须保持人的深度参与？我们需要着重培养什么样的人机协作能力从而更好地面对未来？在此过程中，哪些具体技能或思维方式尤为关键？如何建立对应的评估标准？

Q&A记录

Question 1

主持人：春节期间，DeepSeek火爆出圈。同时，我们也看到这次在知乎、CSDN、Reddit等问答社区的讨论量比社交平台传播量高大概30%-40%。您是如何看待这一现象的？您认为这一现象反映出哪些市场或技术趋势？DeepSeek哪些方面的特点和特性令您印象最深刻？

王昊奋：

技术社区（如知乎、CSDN）用户以开发者、科研人员为主，聚焦AI技术细节（如DeepSeek-R1的MoE架构优化、GRPO强化学习方法）和开源生态（MIT协议全权重开放），而社交平台更侧重大众化传播（如应用场景、舆论评价），这反映出AI技术传播分层的必然性：复杂技术需依托专业社区进行深度解析，也印证了行业从“概念炒作”转向“技术落地”的务实阶段，是好事。

DeepSeek R1探索出了一条高效低成本的推理模型技术路线。除了算法层面的创新，在效果上可比肩OpenAI o1等闭源模型，其他方面也不容忽视。开源的彻底性以及开源主导的创新（如MIT协议，权重+网络架构开放，推动全球开发者共建生态），训推成本的显著降低（500多万美元的训练成本，每百万Token输出16元等），即使是蒸馏得到的小模型其跨领域泛化和推理能力也不容小觑，且适合端侧部署，这就进一步推动了各种应用落地。其本质是通过“低成本技术民主化”打破AI商业化壁垒，为中小开发者提供可落地的工具链。

观点讨论

@彭鑫：开源、开放、普惠

邱锡鹏：

我最深刻的还是DeepSeek-R1-Zero，再次证明了RL Scaling的潜力。比社区对o1的复现更能scaling。

熊英飞：

我是从深度求索公司创立开始就和他们展开合作。我的学生朱琪豪实习期间共同负责了深度求索首个代码模型的开发，毕业之后也作为公司最早成员之一加入了公司。深度求索公司是一家技术主导的公司，从一开始就选择了硬核问题作为公司的研发重点：增强代码模型的推理能力。因为代码编写能力可以非常好地反映模型的推理能力，从根本上提升模型的效果。深度求索公司也有很好的技术探索氛围，像一个实验室一样不断探索和尝试各种工程改进方案的有效性。很高兴看到一家技术主导的公司能取得今天这样的发展和关注。我在这里想要引用梁总的一段话：“以后硬核的创新会越来越多。现在可能还不容易被理解，是因为整个社会群体需要被实施教育。当这个社会让硬核创新的人功成名就，群体性想法就会改变。我们只是还需要一段事实和一个过程。”

但从另一方面，深度求索的爆火我觉得更多是一个新闻传播上的偶然现象，可能值得新闻传播学的同行深入研究一下。在我看来，深度求索公司在技术上确实站在国内前沿了。但站在国内前沿的企业有很多家，大家各有特色和优势，我没有觉得深度求索大幅领先其他头部同行。同时，我们也要清醒地看到，我国大模型企业仍然处于追赶阶段，和国际头部企业比如OpenAI仍然有较大差距。大家要继续努力，争取我国从追赶到引领的转变。

观点讨论

@彭鑫：熊老师一方面肯定了DeepSeek的硬核技术创新，另一方面也提示我们保持冷静、充分认识到与国际巨头的差距

@张海龙：我观察到的现象更多的是 DeepSeek 在语言上的能力。这波 DeepSeek 出圈，对于大众的实际感受是语言能力太强了。

@茹炳晟：关于传播量这个话题，我看到一个有个更有意思的数据。过年期间，google trend上的数据表明，美国对DeepSeek最关心的地区并不是加州等高科技企业聚集的地方，而是华盛顿特区，看来一帮政客都在忙着查DS这股来自东方的神秘力量到底是个啥。

@张海龙：相反，实际使用中 DeepSeek 在代码和推理上没有媒体宣传的那么强

陈鑫：

DeepSeek R1模型是一个0-1的突破，训练成本低，效果好，第一次让中国模型可以接近海外SOTA模型的效果。这种突破本质上是让中国民众有了打破海外技术封锁和垄断的希望，在AI赛道上并不多见。类似的还有Cursor打破Github Copilot的行业垄断带来的爆火。所以可以预判，每一次国内出现可以挑战国外在最新科技垄断地位的产品或技术时，都会出现这种爆火破圈效应，带来海量传播，并且吸引更多人关注AI，尝试AI，最终依赖AI。

茹炳晟：

DS让人印象深刻的地方应该是有目共睹的，我总结了几个点。

首先是强大推理能力所表现出来的性能。其实O1的性能也不差，但是可惜的是O1用过的人太少，而且还是闭源，很大程度上限制了其传播，所以在用户感知这个层面，尤其是中国用户的感知里，AI展现思考过程属于DeepSeek的“发明”，这相当于openai把这波范式转变的热度拱手让给了DeepSeek。

其次才是成本。只有模型性能足够好，大家才会关注成本。由于各方面证据都表面，DS其实非常缺卡，所以不得不在工程实现上做各种极致的成本控制，DS的很多创新，包括MLA、DeepSeekMoE、FP8训练都是来自于受限的资源，这也印证了那句话“伟大的创新都是来自于稀缺”。最终实现了不到600万美元的低成本。当然“558万美元不包括与架构、算法或数据相关的前期研究和消融实验的成本”。这意味着，DeepSeek的实际成本更大。

接下来是技术。DS引入的pure RL（纯强化学习）的路子被证明是可行的。不需要准备推理数据，仅靠模型自主进化，就能够大幅度提升模型推理能力，这点在DeepSeek R1 Zero版本上得到了验证。原本业界都在各种尝试PRM（Process Reward Model）的技术路线，PRM对于COT数据标注的代价极高，现在被证明这个不是必须的，为业界指明了方向。

另外，由DS蒸馏的“小模型”启动了大规模的私有化部署热。之前的模型动不动就很大，一般人玩不起来。现在各种蒸馏小模型的出现，让infrastructure有事可以干了，终于有了性能、成本和实用性相对均衡的模型可以玩了。

还有一个大家比较容易忽略的点是DS在其他模型（qwen和llama等）上做的蒸馏实验，证明了高质量的long CoT数据能够激发现有高质量预训练模型的能力，其成本远低于预训练。而且DS还通过论文公布了完整的技术细节，让所以大模型从业者都感到意犹未尽。可以说这是DS给人类的伟大贡献，一点都不夸张，让AGI和ASI都更近了一步。还有一点，DeepSeek-R1采用 MIT许可协议，后续大家用起来改起来都没压力，而且可以形成规模效益。

观点讨论

@魏昭：赞同，DS的蒸馏为端侧模型的部署提供了路径

@张海龙：十分认同。DS 把“思考”过程展现出来，给了用户一种前所未有的体验。虽然 2023 年就出现了CoT，做 Agent 的开发应该习以为常，但是绝大部分人没见过，还是很震撼的。

刘焕勇：

这个爆火是一种必然，无论是国外的炒作，还是国内一贯的氛围，都决定了这个爆火一点都不奇怪。有吃瓜盲目跟风的群众，也有为了流量大肆宣扬的自媒体，也有一些从事大模型的一线开发、头部公司以及创业者。由于openai在技术开源上站到了对立面，所以这也成就了Deepseek的火爆，也说明了大家对开源的模型是积极拥抱的。但这种现场都说明了Deepseek确实让人眼前一亮，其相当于把openai-o1的开源出来了，这是过去一段时间一直难见到的景象，这给人一种很新鲜的期待，节后开展的大量部署、复现和体验潮，也说明了大家对大模型的能力其实有很多期待的，期待找到突破口，以推动落地，解决吃饭问题，在资本市场也需要一针强心剂。DeepSeek最大的贡献，一个是作为一种复现把openai-o1的开源出来了，这个可以作为平替使用，也开源了一些蒸馏模型，这个利好落地。一个是其用纯RL思路就能提升推理能力的新发现，这个的确在技术路线上是有一定启发意义的。但是，坦白讲，还有很多问题，Deepseek 并未解决，所以今后它怎么进一步发展，我觉得更值得去期待。

张伟涵：

首先我认为这是一次出圈的现象，由中国公司在大幅降低训练、推理成本的基础上，生成效果追平OpenAI，Anthoropic等头部公司的故事。社会上多多少少参杂了一些爱国、民族情绪，广大的自媒体行业，各种噱头百出，大大推动了AIGC的全面普及。但也带来了信息的良莠不齐。

在这次各界热议的话题中，和以往不同的是，各个方面的应用都有设计，反而代码、软工层面的话题占比不是很高。

其次从企业角度来看，这是AI领域洗牌的一个信号，DS以开源姿态带来的技术普及，会加速这个领域的洗牌节奏，我预计今年会有大量从事AIGC的初创公司，会被整合、收编或清退出场。特别是没有商业模式支撑，还没有变现的纯技术公司。

另一方面，对于业务稳定（传统行业）是一轮利好，新的低成本的技术，将会激发企业拥抱变化，加速企业业务重构，这将必不可免的带来企业学习AI、应用AI，研究AI的热潮。这对以信息差为生的自媒体个人创业是个机会窗。

最后，从技术角度来看，Transoformer系的模型开始阶段性稳定，进入系统性优化阶段，DS从模型架构、训练、推理、部署等全方位的优化。当然印象深刻的是对模型架构的优化，从MLA的公式算法级优化（低秩矩阵），到MTP的训练效果提升都是意向不到的地方。但所有的优化没有跳出Transoformer架构的范围，这也是我前面提到的进入系统性优化阶段的原因。

彭超：

DeepSeek 的爆火我总结有几个方面的原因：低训练成本和推理价格，打破了传统大模型依赖算力堆砌的路径；进一步推动了国产替代的发展；春节期间大家更有时间尝试 DeepSeek，并产生了”国产 AI 崛起“、”引起美国恐慌“的热搜，外加一些自媒体的传播。这次的爆火和出圈，让中小企业也看到了希望，各大算力供应商、云厂商也纷纷部署 DeepSeek，推动了 AI 普惠化的转变。

印象最深刻的特点是 R1 模型会展示深度思考的过程，有利于模型的 debug，也会促进各类领域模型深度思考数据的生产和模型训练。另外，R1 提供了各种尺寸的模型，满足不同场景、推理算力的需求，小参数量的模型在 Mac 上可以直接本地推理，各类 AI 应用类 App 也纷纷部署了“满血版”模型，这些都促进了大模型的普及，让大家觉得这些技术不再遥远。

魏昭：

DeepSeek的爆火出圈反映了其技术实力和创新性得到了广泛认可。在市场方面DeepSeek的低成本和高性价比极大的推动了AI技术的平民化，对全球AI市场格局产生了深远影响；其开源策略和技术路线的创新，为AI领域带来了新的趋势和方向。技术上DeepSeek通过自研的混合专家模型（MoE）和多头潜在注意力机制（MLA）等先进技术，显著提升了模型的计算效率和推理能力；通过纯强化学习驱动的推理能力突破，实现了无需监督微调即可获得强大的推理能力，而不仅仅是依赖硬件算力的堆砌和大力出奇迹。

因此我们研发的工蜂Copilot(腾讯AI代码助手)也接入了DeepSeek R1，在代码生成、单测生成、CR生成等软件开发的各个场景为腾讯开发人员赋能。

DeepSeek R1强大的推理能力和CoT展示印象深刻。在Codebase的一个Bug分析场景中，CoT逐步检查每个代码文件，寻找潜在的问题，通过多层问题归因分析，能有效的识别如：contents.subSequence(start,end)中边界校验缺失的缺陷(end=-1导致越界异常)并给出修复方案contents.subSequence(start,end==Diagnostic.NOPOS?contents.length():end)。在Bug修复中不仅仅给出修复结果，也充分的展示Bug的分析过程，这有助于开发人员的审核和校验。

王翀：

火爆出圈应该是多方面因素导致的，一方面DeepSeek-R1取得了非常大的技术进展，用较低的成本达到了跟OpenAI O1差不多的水平；另一方面DeepSeek是开源的，不仅仅公开了模型参数可以直接下载部署，也发布了详细的技术报告给大家提供了复现的途径。

DeepSeek-R1让我印象最深的是在处理问题时给出了完整的思考过程，看下来不仅提升了推理的效果，也增加了结果的可解释性。

李彦成：

对中国公司突破大模型技术感到震撼和惊讶，不只是美国公司可以做出好的大模型，中国公司一样可以。说明中国的模型厂商可以上桌了，只是不是主位，但是足以震撼到海外媒体。反映出世界对于中国大模型的认可，和国人多么渴望国产技术能在世界范围内崭露头角和获得认同感。我认为这一现象反映出市场对优秀大模型技术的看好和渴望，也印证了大模型技术受到越来越多的人关注，不只是技术人员，开始影响到各行各业。

DeepSeek令人印象深刻的是工程能力，提出了非常多优秀工程方法，极大的降低了训练成本和推理成本，我认为最令人印象深刻的是DeepSeek的开源，如果DeepSeek不开源，热度不可能这么高，甚至会有更多质疑的声音。开源本身代表一种组织的先进能力，更进一步体现出公司的实力，开源的llama已经为facebook的市值带来了泼天的富贵，这已经证明了开源能力对于一家公司的重要性。DeepSeek的开源也会将国内大模型公司开源推向高潮。

Question 2

主持人：以OpenAI O1/3和DeepSeek R1为代表的推理模型所表现出的慢思考和长推理能力与此前的大模型相比有什么特点和优势？一些观点认为过度慢思考，尤其是超长步骤或特别绕（啰嗦）的思考过程可能会起到反作用，您如何看待这一点？在实际应用中，您觉得这种能力能否转化为更高的实用性？这方面的能力将对哪些领域和应用场景带来重要的影响？

王昊奋：

之前的大模型可以称为指令型大模型，这次的推理模型核心优势在于通过显式的长思维链实现深度思考。特点包括1）透明化推理路径：如DeepSeek R1展示完整的"思路链"，包含每一步推导和验证过程，类似人类解题的逐步分析；2）复杂任务突破：在数学竞赛（如AIME 2024）、科研分析等场景表现突出，R1在MATH-500测试中准确率达97.3%，超越多数模型；3）强化学习驱动：R1通过纯强化学习训练，无需监督微调即可自我验证和反思，实现更优泛化能力。

过度慢思考存在1）冗余步骤与效率矛盾：部分任务中，模型可能陷入“自我循环”（如DeepSeek-R1-Lite在长推理链中出现死循环或错误答案固化），导致资源浪费与用户体验下降；2）场景适配性问题：有研究表明，思维链（CoT）在分类任务中可能导致准确率下降30%，说明“慢思考”并非万能，需结合任务类型动态调整推理深度。所以大家看到了OpenAI的GPT5希望是将指令型模型如chat型的和o3等推理模型进行整合，进一步体现什么时候应该思考，怎么思考，思考的深度等灵活性和适配性。

慢思考与长推理能力是AI向深度认知迈进的关键标志，但其价值需结合场景灵活释放——在复杂问题中发挥“人类级严谨性”，在简单任务中避免“过度设计”。在教育（解题过程可视化）、金融分析（复杂数据推演）、算法设计（长逻辑链验证）将直接受益。未来，模型需进一步优化推理链的动态剪枝能力，并在各种应用场景中寻找效率与深度的平衡点。

观点讨论

@彭鑫：让我想起来我们在回答问题的时候也会有不同的状态和策略，如果在完全放松的情况下可能会快问快答，但如果觉得这个问题特别有深意或者有什么坑的时候可能会严谨起来。

邱锡鹏：

1. 在预训练规模短时间内不太容易扩大规模的情况下，通过内部和外部慢思考机制，使模型能够在不增加参数量的情况下，可以继续提升模型能力。

2.“过度慢思考，尤其是超长步骤或特别绕（啰嗦）的思考过程可能会起到反作用”这一点我觉得是个很好的研究方向。深度神经网络架构中也有类似的解决方案，比如早退机制，推理时的优化也类似

3. 推理能力强化后，可以对Agent有更多的帮忙，提升下游的能力。

观点讨论

@沙朝锋：

Daman Arora, Andrea Zanette.

Training Language Models to Reason Efficiently. https://arxiv.org/abs/2502.04463

In this work, we propose to train large reasoning models to reason efficiently. More precisely, we use reinforcement learning (RL) to train reasoning models to dynamically allocate inference-time compute based on task complexity. Our method incentivizes models to minimize unnecessary computational overhead while maintaining accuracy, thereby achieving substantial efficiency gains.

张海龙：

模型内置的 CoT 确实带来了更好的推理能力，在时间不敏感的任务上，可能会有更好的效果。但是，实际使用中，我们发现需要谨慎甄别任务，不能盲目的所有任务都用 CoT 模型，有时候反而效果不好。

在实际使用类似于 o1 这样的模型的时候，需要对业务场景做详细分析，把真正需要“推理”的任务找出来。另外，“思考过程”在很多应用场景下是没有必要显性表达的，因为最终不会使用这个思考过程。

陈鑫：

从本质上说过去模型一直在快思考模式，并没有很强的计划、执行、反思能力，而推理模型在这方面取得了重要突破。在Claude 3.5 sonnet上做的AI Coding Agent以及MCP扩展，同样是利用大模型实现了计划、执行、反思能力。很明显R1在文本创作、代码生成准确率等方面超过了非reasoning模型，尤其是在文本创造力上面超过了大家的预期。这种思考能力在AI Coding的需求分析，架构设计方面非常适合，会成为未来生成模型的重要补充。

观点讨论

@茹炳晟：reasoning不是说模型真的会像人一样会思考了，reasoning的本质还是预测下一个token，预测的token去激活更多相关的内容（知识）而已，所以其本质依旧是CoT，只是模型基于NTP的自动化CoT。但是当这些高质量CoT数据汇总到一起的时候，基础模型的能力就可以很大程度被提升，当然，基础模型本身也要给力。

熊英飞：

推理模型是一个很大的进展。因为Transformer结构的特点，每一个Token输出前只能经过固定层数的计算，所以无法回答需要经过较多思考才能回答的问题。在o1出来之前，各家的模型都达到了和4o接近的效果，我和朱琪豪都觉得模型的发展到了一个瓶颈。o1用输出Token序列替代了人的思考过程，使得模型的思维能力可以进一步增加，能够应对需要较长时间思考才能得到答案的场景，比如复杂算法的设计和编写，复杂代码逻辑的理解等。

但这不代表推理模型就适合所有场景。“言多必失”，因为大模型的幻觉，简单的问题想多了反而更有可能想错了。DeepSeek R1在一些评测中并没有V3的分数高，也是这个原因。

观点讨论

@张海龙：“思考过程”在很多应用场景下是没有必要显性表达的，因为最终不会使用这个思考过程。

@张海龙：OpenAI 最初选择不显示思考过程实际上在工程上是没问题的，只是没想到原来大众这么喜欢看思考过程。

@茹炳晟：让人感觉不再黑盒了。

茹炳晟：

相比传统大模型，以DS为代表的推理大模型的特点非常突出。首先推理大模型展现出了显式推理过程，使结果更具可解释性，便于技术用户验证逻辑，而非“黑箱”生成，我称其为可被观察的慢思考机制。其次是显式推理过程的自我推翻和复盘过程，也就是论文里面提到的“aha moment”，让我们看到自我进化的可能性。

最重要的一点，我认为是，慢思考和长推理能力是一种后劲很足的能力。Agentic Workflow的短期价值很明显，看起来能解决问题，但是能够结局的问题域很长尾，这样长期价值相比会主动推理的模型会低很多。

推理长度随着模型训练慢慢变长，在开始的时候是好事，可以激发更多的思考，但是推理的本身也是其实也是NTP的过程，并不是单独的额外过程，太长不等于好。太短当然也不行，因为问题本身的上下文没有被激发。所以还是要看问题类型，对于事实性（明确答案）的知识不宜走推理。

刘焕勇：

以OpenAI O1/3和DeepSeek R1为代表的表现出的慢思考和长推理能力与此前的大模型相比，其实就是3点。一点是其在数学题等评估测试榜单上的效果提升很明显，能力更强了。另一个点，就是其有显式的推理维链条，这可以理解为一个可解释性的观察入口，这个很有趣，也成就了第一个点。第三个点是，这种能力的提升和形式化的推理链条，实际上增加了推理时间，这是在等待感官上的差异。当然，我们可以认为，这类过度慢思考的动作，首先对于一些时延性要求很高的场景其实是难以忍受的，其是典型的以时间换性能空间，能不能落地，得算笔账；然后就是，并不能说慢思考，就一定能保证效果好。因为慢思考，可能会思考过度，思考过度，很可能太发散，生成一些有幻觉的token，与之产生的噪声也会更多，可能会影响最后的答案生成，进而影响性能。至于影响多大，得看具体场景，具体任务去试。当然，这种能力既然出来了，必然有存在的价值。我这里说3个有确定收益的场景。例如，1）前面说的可解释性问题，在一些jf的场景中，一直都很难相信大模型的推理，觉得那是概率，那是盲盒。又如，2）对于AI 搜索，是利好的，现在豆包、纳米搜索、秘塔等搜索都接了Deepseek-R1，就说明是有用的。在这个场景里，用户的输入意图是不确定的，模糊的，正好可以利用R1猜用户意图的能力，去发散，去扩召回，并且在总结阶段进行深度分析，这正好用上了推理分析能力，如最近的Deepresearch，但另外就是，AI 搜索这种场景是低容错的，并且审查对不对，其实蛮难，所以上了就不错。又如 3）在写作能力上的确超强，其不同于之前大模型流行的三段论写法，还有声有色的，网上也有很多段子，四字总结的，骂人的，编字典的各种。也有一个不确定的收益场景，那就是Agent，R1的推理能力强，去做推理规划，生成task-flow，这是有机会的，但谨慎乐观。当然，也有一个很确定的负收益场景，那就是事实问答，比如RAG。我们测下来，其实的确是负的，容易过度发散，超纲答题。当然，这些都是目前暂时的情况，后续随着模型的迭代，可能情况又不一样了。

张伟涵：

关于问题2的个人实践和思考：

首先慢思考、快思考这一技术是在去年10月份从OpenAI引入的，大大提高了模型输出的精准性，相比于慢思考提升了模型推理的能力。这迅速也成为了业界的共识。慢思考的方式一直没有回答或面对模型是否具备推理能力的质疑，一定层面上慢思考回应了这个问题。

在应用上，慢思考毫无疑问的降低了模型的响应度，时延大大提升，这对围绕模型为中心的应用，特别是人机交互式应用带来较大的挑战。但是由于推理的精准度的提升，快慢思考结合的场景成为了新的应用方向，Agent成为了追逐的热点，一方面通过慢思考提升任务的规划、拆解，提升意图理解；另一方面，通过快思考的配合，提升任务执行的精准度。这个角度我持积极态度同时也在积极探索。

慢思考的引入，会大大提升复杂类任务的可行性，在软工层面，增量特性开发，特别式复杂系统的增量开发将成为可能。当然需要RAG的配合，其实也是某种意义的Agent的实现。

彭超：

优势：模型在多步推理中逐步展开思考，提升了解决复杂任务的能力，在制定规划、撰写方案等场景表现优异。同事，模型展示的思考过程也可以帮助用户了解模型的推理路径，对于不太满意的答案也可以针对性地纠偏。劣势：过长的推理过程导致的响应时间延长，影响用户体验。同时，也看到模型在思考过程中可能“跑偏”，或者产生过多无关信息，导致最终答案文不对题，有时会降低结果的可用性。

以软件工程 AI Agent 为例，在应用时，我们可以和 GPT-4o、DeepSeek V3 等模型结合，让不同模型处理不同类型的任务，提高总体的表现。

观点讨论

@张伟涵：认同，是Agent场景化应用的催熟的技术保证

李彦成：

慢思考和长推理能力是一种问题分解方式，具备深度思考能力，对特殊推理问题会有更准确的结果。实现了对人类专家级推理过程的拟态复现。

对于啰嗦来说，我认为是一种失误或者是一种性能问题，只是一个过程点，经过收集数据后，会有减少这种现象。这种能力在逻辑解释问题有优势，例如在医疗诊断、法律条款解析等领域。在非实时任务方面会有重大应用。

观点讨论

@茹炳晟：还想到一点，长思考链会让我们比较容易被幻觉骗了，“合情合理”的推理过程看起来逻辑完整，但是结果可能是错的，人工辨伪的难度其实提升了

@彭鑫：是，有些“胡说八道”看上去更加诚恳亲切了

魏昭：

推理模型所表现出的慢思考和长推理能力一是能提升复杂问题的解决能力，二是每个step都有明确的依据和步骤，具有很好的连贯性和逻辑性，能够解决此前大模型处理复杂问题时出现逻辑跳跃、不完整的情况。

在实际应用中，比如软件开发，仓库级代码改写和生成方面，慢思考和长推理能给出详细的需求分析、系统规划，需求拆解、设计、生成等一系列逐步优化的解决方案有助于生成准确的代码。

但在某些实时场景，比如代码补全，开发人员倾向于快速获取补全代码；简单的常识性问题回答，用户是更倾向于直接快速回答，过多的背景分析或假设验证让答案显得不直接。所以需要根据场景来选择是否需要慢思考和长推理。

我们在实际应用R1的开发过程中也收到用户反馈R1存在思维链冗余，展现大段没太多作用、车轱辘的思考过程而影响体验，以及思维链推理正确，但结果不正确的情况。

王翀：

优势主要有两个：一个是能够显著增强对用户意图的推断和子步骤的拆分（长CoT）并增强推理的能力；另一个是提供的完整的思考过程可以极大增强用户对结果的信任程度。

过度慢思考确实存在，尤其是针对一些不太复杂的任务的时候，这种现象更加明显，可能反而带来性能下降。

慢思考对大部分最终用户（End User）来说是一个非常实用的能力，不仅提升效果的同时，最重要的还是还是上面提到的可解释性。但另一方面，这一能力也可能是一个潜在的巨大威胁。因为会让用户过度信任输入的结果，带来额外风险（以上关于可解释性带来的好处和问题，过年期间有律师朋友在聊天时提到过她在用R1分析发条和判例时有类似体会）。

观点讨论

@彭鑫：有几位嘉宾提到这种慢思考能力有利于复杂软件开发能力，这方面大家有实际体验吗？

我个人不是太乐观，因为复杂软件理解和维护涉及的系统设计和上下文太复杂，我不觉得是目前这种文本上的推理能搞定的。

@熊英飞：用github copilot，涉及项目定义的函数较多的时候，o3-mini显著强于4o和claude

@张伟涵：结合我团队的实践，有积极的方面，但也有消极的方面。

@魏昭：针对仓库级代码改写，简单的加一些逻辑或者字段修改体验还不错，但复杂一点的业务逻辑还是搞不定，但找Bug有cot过程还是不错的。

@茹炳晟：我也持有怀疑态度，原本的代码和设计就是一拖“草台班子”，而且实现又有各种不一致，再加上文档（正确的依据）缺失，就更摸不着头脑了

@彭鑫：是的。有几位嘉宾提到的慢思考能力有效的场景应该是不太依赖深层代码理解（特别是复杂设计）而只是照顾到代码库中多处的一般性考虑的场景（例如仓库中定义的API，或者某个变量被引用的多个地方）

Question 3

主持人：很多人认为近期以DeepSeek为代表的技术进步将带来大模型部署及应用的普适化，这将对软件产品及应用形态产生什么样的影响？一些行业已经喊出了“去APP和Agent化”的口号，对此您有什么看法？基于大模型的Agent将会成为未来软件产品及应用的主流形态吗？Agent是否仅适用于特定领域，如果应用于复杂软件系统中是否会带来潜在风险？

王昊奋：

随着模型推理能力增强和成本下降，基于大模型的Agent应用展现出显著潜力，正推动软件产品形态向智能化、自动化方向重构。一方面，传统APP可能被更灵活的Agent替代。Agent能自主执行跨应用任务（如屏幕控制、工作流自动化），并通过多模态交互降低使用门槛。例如，微软、Salesforce等企业已部署Agent处理客服、销售等复杂流程。另一方面，部分行业提出“去APP化”，实质是强调以Agent为交互入口，通过自然语言或意图识别直接满足用户需求，而非依赖固定功能的应用。但短期内APP与Agent可能并存，逐步过渡到以Agent为核心的混合形态

Agent并非局限于特定领域，其在企业服务、教育、医疗等多领域已有落地案例。然而，复杂系统中部署Agent可能引发风险：一是技术层面，如自主决策失误或协同机制缺陷等。更具体来说，Agent在复杂软件中可能导致逻辑不可控，例如金融交易系统若依赖Agent自主决策，可能因模型偏差引发系统性风险；二是安全层面，模型易受攻击，需强化防护，也可能生成式Agent可能被恶意利用（如自动生成攻击代码）；三是伦理与治理问题，需建立约束框架。

邱锡鹏：

1. 软件产品形态的转变：传统的软件产品通常基于固定功能模块，通过独立的应用或服务提供特定的功能。而大模型的应用使得“智能化”和“个性化”成为可能，软件产品将更多地变为基于自然语言和交互的智能系统。

2. 去APP和Agent化的口号：这一口号在某些行业确实在流行，尤其是在企业应用和个人生活领域。例如，用户不再需要下载大量的单一功能的APP，而是通过一个集成的智能Agent来进行各种操作。这种变革也意味着传统的App Store和应用开发的生态系统可能会受到挑战，取而代之的是以大模型为核心的智能Agent系统。这个趋势可能会让软件的体验更加无缝，并且在跨平台、跨设备的整合上更具优势。

3. 基于大模型的Agent是否会成为主流？：从目前来看，基于大模型的Agent有很大可能成为未来软件产品的主流。随着大模型计算力的提升和普及，用户可以通过智能Agent轻松地获得定制化服务，甚至在复杂场景下能够自动推理和处理问题。

4. 是否仅适用于特定领域？：Agent在许多特定领域已经有了非常成熟的应用，大厂已经转向这种方式。但在应用于更加复杂的软件系统时，可能会面临一些挑战。例如，复杂的软件系统往往涉及到大量的依赖关系、交互式操作和复杂的工作流，而现有的Agent技术可能在推理能力、状态跟踪、上下文理解等方面尚显不足

5. 潜在风险：尽管Agent能在许多领域提升效率和用户体验，但也有一些隐患。首先是数据隐私和安全问题，智能Agent需要收集大量的用户数据，这可能带来数据泄露的风险。其次，过度依赖Agent可能使得用户在某些情况下失去对信息的主控权，导致智能Agent做出偏离用户意图的决策，或者由于技术的限制而产生错误的决策。在复杂系统中，Agent可能无法完全理解系统的复杂性，尤其是在需要高度精确和有条理的操作时，Agent的“泛化”能力可能不足以应对。。此外，基于大模型的Agent如果在复杂系统中运行不当，可能会出现误判、错过关键细节、或者在跨系统协作中产生不一致的情况，这些都可能对整个系统的稳定性和可靠性带来潜在风险。

观点讨论

@张海龙：推理模型的出现并没有改变大模型 LLM 的本质，我认为目前的 AI 能力不足以支撑 Agent 去完成复杂的任务。我相信未来会出现很多垂直的 Agent 完成一个一个垂直的任务。

@张伟涵：其实没有那么悲观，在有业务压力的情况下，一个个应用已经出现了

@彭鑫：@张海龙针对垂直agent，能否举几个例子？

@张海龙：比如我们正在做的 unit test，还有很多创业公司在做的 code review, e2e test 等等

@茹炳晟：垂直场景我很看好，比如海龙说的场景

熊英飞：

我觉得基于人工智能去解决越来越复杂的任务一定是未来趋势，目前可以看到基于人工智能的自动驾驶、自动办公、网络搜索都在不断取代传统软件或者拓宽传统软件的范畴。但这并不代表所有计算都要通过大模型进行，还是要看应用场景。比如一个计算器，直接调用CPU指令计算加减乘除肯定比调用大模型要快速和准确很多。

陈鑫：

在AI Coding领域基于大模型的Agent一定是主流，因为大模型需要与开发者环境进行频繁的交互。并且对话式人机协同编程模式将成为主要编程模式，这种编程范式会从简单任务例如小工具开发、原型开发、前端开发等逐步走向复杂任务，例如复杂业务逻辑编写。DeepSeek在这方面除了让更多企业关注到AI带来的影响力之外，并没有实际上的推动。但人类这种意识的改变也是至关重要的。

观点讨论

@彭鑫：软件形态的变化应该结合特定的软件层次来谈。在应用层，去app化应该会是一个趋势，app通过解构再重构被API和服务化，然后通过agent形成新的用户服务能力。但在应用层之下，各种业务服务和系统支撑应该还会沿用目前的云原生以及操作系统、中间件等复杂软件系统。

@茹炳晟：软件形态的重构方向有两个，一是从以功能中心到以任务中心：传统APP以功能菜单为核心，而Agent化应用以用户目标为导向（如“规划一次巴黎旅行”自动调用航班、酒店、景点API）。

@茹炳晟：二是自然语言成为交互核心，以后流量的入口不在在各个APP了，而是agent来决定把流量给到哪个app，哪个时候我们还需要APP么，app现在抢的是人的时间，之后抢的是agent的导流，这么看商业模式都可能变了。谁有入口谁就是王

@张伟涵：@彭鑫彭老师，这块有点不同意见。去app其实并没有商业上或应用场景上的诉求和动力。站在用户角度，最关注的是问题是否能解决，而不是用什么技术解决。在Agent场景下，反而一些使用API或代码能解决的问题，使用大模型调工具能获得更确定的答案。我们已经在实践mcp了，大模型负责拆解，工具或API负责确定性

@张伟涵：对于问题三，很明显，由于开源的推动叠加推理成本的下降，第一波热潮将会出现在芯片厂商（GPU/NPU/XPU），以成功部署应用为目标的硬件设备将会层出不穷，同步的，各类推理服务提供商，也将大展拳脚，推动各自推理平台的推广，比如投机解码技术当前被重拾。最后，端侧也会再来一波，本地化部署将会把2C的领域热炒一遍。

对软件产品的应用，最直接收益的是大企业，以往受制于信息安全的问题，OpenAI、Claude等模型在企业中往往无法使用，现在将成为现实，这将驱动企业大规模开始本地部署以提升模型在软工领域的应用。至少当前我的团队已经完成满血版V3和R1的部署和应用。再深入一步，以cursor、cline为代表的IDE和插件，将大大降低大型企业的应用门槛，如直接使用cursor和本地部署版的DS对接，包括cline与本地部署版V3的对接。

Agent一定会应用与软工领域，这个我前面已经提到了。

@彭鑫：@张伟涵主要差异是？

@茹炳晟：我认为是局部自闭环场景，而且这个自闭环场景本身就有复杂度，慢思考应该是适用的。但是大量依赖原有设计和实现理解的场景，我比较悲观

@彭鑫：是，软件开发的难题在于经常面临相关业务或技术知识的缺失，所以开发人员的有效代码量以及花在“编码”上的时间并没有那么多，很多时间都花在拉通、对齐甚至吵架上了

@茹炳晟：对的，需求能扯清楚会面代码都不是难事，难的是要啥很难说清楚。需求结构化把业务知识能够有效沉淀是大模型在软件生成领域很关键的前置步骤

刘焕勇：

我说下我的想法，最近DeepSeek为代表的技术进步将带来大模型部署及应用的普适化，这个需要承认的，因为其推理能力上去了，并且还有蒸馏出的小参数版本，并且现在国内的算力资源逐步完善，加之越来越多的人开始使用大模型去做落地（前面说过了，R1给了人一种新的期待，所以会有更多尝试的场景），所以这其实有了一个新的部署流量出口。所以会有更多的结合可能。但是产品和应用的形态，我谨慎乐观，因为其只是能力稍强一些，并没有解决之前大模型所不能解决的问题，所以产品和应用的形态上不会发生改变。更多的形式还是做一些替换或者组合操作，替换之前的大模型，在链路上组合其他模型进行预测，比如和cluade这个模型结合进行编码，也已经有这种例子了，效果也不错。一些行业已经喊出了“去APP和Agent化”的口号，这个其实是大家的一个痛，是逼不得已的。2024年，不少人因为吃了agent这个饼倒闭的倒闭，以至于大家都形成共识说，agent就是一个任务形式流，用户根据自己的场景去编排流程，比如用coze去搭建。但从严格意义上来说，这不叫agent，因为agent是自主规划的，流程是动态结构，前面这种是静态的，任务形式是固定的。而为什么大家要去 agent化，是因为伤到了。agent预测并不稳定，并且在复杂场景搞不定，也不够聪明。跟媒体和学术论文宣扬的是两回事儿，落地很难。所以，我认为至少在目前这种大模型的能力条件下，“去APP和Agent化”是最稳妥的落地打法。我们继续说，基于大模型的Agent将会成为未来软件产品及应用的主流形态吗？我觉得不会是主流，是一个配角存在，因为它还“不够格”，还需要等待，还需要历练，发展。目前Agent落地的，很多都是简单特定场景，就是前面说的，做成任务流，这比较好控制，好管理，能增效一点算一点。但如果应用于复杂软件系统中，是一定会带来风险的。因为复杂软件系统存在着权限、任务流、规则、日志、监控等多个复杂因子，其牵扯到的节点很多，以现在大模型agent 的能力来看，既不能保证系统的稳定运行，也不能保证系统的安全性，却又徒增了许多安全隐患以及管理成本。大家做软件系统开发，都是稳字当头，其他先不先进的，反而是其次。

彭超：

最直观的影响是大模型使得软件具备了更强的多模态处理能力，文字、图像、语音等信息可以直接被大模型处理、理解和生成，建立不同模态的数据关联，也提高了软件的决策能力，可以自助规划并根据反馈实时调整。为了软件应该会朝着 AI Native 的方向发展，用户可以通过大模型的交互界面以及背后的知识库管理、联网搜索、代码执行沙箱等，直接获取服务和信息。因此，基于大模型的 Agent 有较大可能成为未来软件产品的主流形态，与用户进行流畅的对话交互，完成重复性、规律性的任务。当然这其中也存在着各类风险和挑战，如理解偏差、决策失误、隐私和数据泄露等问题。

李彦成：

随着大模型部署及应用的普适化，我认为更多的应用愿意接入大模型，大家不再会在意接入成本，软件的易用性会增强，大模型会打破软件交互形态，更多的是面向对话框获取数据，交互数据，更多的是做选择，不用再操作繁琐的流程。

“去APP和Agent化”的口号过于乐观，目前场景很难找到，因为大模型的幻觉，很多任务无法百分百执行正确，限制了很多场景应用。

未来软件产品及应用在短时间会在Agent上有个爆发，但是受限于大模型的能力，如果未来1年内没有延续能力增强，Agent将会发展受限。

我认为发展Agent还是要把大模型放在铁轨上运行，无危险操作可以由大模型执行，如查看、增加动作，对于修改、删除，如果无法用Agent做到百分百正确，仍然需要人来选择判断。

观点讨论

@茹炳晟：行业软件像CAD这类应该还是现有的逻辑，但是toC APP可能会有范式变化

魏昭：

软件产品及应用形态方面，APP的概念可能会模糊化，将逐渐被Agent取代。未来各个领域一定会出现基于大模型的领域Agent，特别是在软件工程领域一定会发挥巨大作用。软件开发模式也将从传统的需求分析、设计到代码实现向基于大模型的强化学习+知识蒸馏+提示工程的模式转变。

观点讨论

@赵俊民：大家心目中的AI 手机是不是也是只是一个agent交互界面

@彭鑫：@魏昭 “软件开发模式也将从传统的需求分析、设计到代码实现向基于大模型的强化学习+知识蒸馏+提示工程的模式转变。” 这方面我相对没那么乐观

王翀：

Agent作为直接跟普通End User交互的智能助手（例如操作手机App完成用户日常需求），个人认为类似场景是有前景的，且已经能看到市面上一些相关的产品了，应该会成为未来一种新的应用形态。当然，其中也会有一些挑战，比如隐私和安全问题等。

针对特定领域，个人觉得Agent成功与否除了取决于背后大模型本身的能力之外，还有很多“数字化、知识化”方面的工作需要去做。针对那些本身已经具备很完善数字化、且有成熟工具集的领域，Agent应该可以处理的很好。但是很多行业的数据并没有很好的管理起来，甚至还停留在口口相传的阶段，面对这些领域，做好数字化和知识化才能对Agent进行赋能。

针对复杂软件系统，（1）如果将Agent作为其中的组件，那必然会带来比传统软件更大的风险，需要对大模型/Agent的不确定性和能力边界有清晰认识之后，做出谨慎决策。（2）如果Agent的操作/交互对象是复杂软件系统，那同样需要对该软件背后的业务场景等知识有一定认识和积累之后，才能做到Agent驱动的“软件自动化”。

Question 4

主持人：以OpenAI O1/3和DeepSeek R1为代表的推理模型在软件工程（包括软件开发、运维、测试及质量保障等）领域的表现如何？大模型强大的推理能力是否会颠覆现有的软件开发模式并对就业市场造成重要的影响？

王昊奋：

以OpenAI O1/3和DeepSeek R1为代表的推理模型在软件工程的诸多方面展现了显著的技术突破和实际应用潜力。其在代码生成、补全和错误修复方面表现突出。例如，DeepSeek-R1在Codeforces平台上评分超过96%的人类程序员。另一方面，大模型通过智能化的代码检查和测试用例生成，提升了测试覆盖率和效率。然而，在复杂软件工程任务（如多语言处理、实际工作流整合）仍存在局限，且响应时间、API限制等问题可能影响实际应用。

关于开发模式变革，大模型可能推动自动化编程工具普及，辅助代码生成、测试用例编写等环节，但短期内难以完全替代人类开发者。模型仍需要人类干预处理复杂逻辑和系统设计。大胆预测就业市场将呈现结构性调整：基础编码岗位可能减少，但会催生AI协同开发、系统架构设计等新型岗位，同时企业对掌握AI工具的开发者需求将增加。这种变革更可能形成"人机协作"的新模式，而非完全颠覆现有体系。

熊英飞：

目前业界应该已经一致认为大模型能带来软件生产率的大幅提升了。至于是否会对就业市场造成冲击，我觉得这更多取决于信息市场的潜力有多大。

第一，目前的信息系统还有很大的发展空间，比如学生劳务发放本质就是两个账户之间转账，用支付宝微信这样的界面十秒钟就能完成，但北大的财务系统需要填数十个选项，花费十几分钟才能完成。更不要说大量的事务还需要传统手填表格，根本就没有信息化。传统上，我们没有足够多的人力去做好这些小众的信息化需求，但有了大模型提高软件生产率之后，这方面的需求就有望得到满足了。

第二，大模型带来很多新的应用类型，比如智能驾驶、智能办公等，这些应用都需要对应程序员去开发。

第三，大模型本身的基础设施也还需要更多程序员去开发维护。

我个人是持比较乐观的态度，计算机的就业市场还能坚挺很多年。

观点讨论

@茹炳晟：利用AI 辅助编程可以用很快的速度完成80-90%的工作，但对于剩下10-20%，效率会快速递减甚至无法完成。

@魏昭：我现在偏向乐观一点，特别是前端代码生成，业务逻辑少

@张海龙：我觉得对于很普通的程序员是有影响的，但是对于有架构和业务能力的程序员是利好。

@彭鑫：基础编码岗位可能减少：这里有个悖论群里谈到过好几次，那就是以后能较好驾驭大模型的高级程序员都如何成长起来呢？

@张海龙：@彭鑫这个问题本身可能有点问题。事实上有很多“普通”程序员，工作很长时间也没啥成长。

@赵俊民：未来对工程师在创造力和想象力方面更重要，体力活，搬砖的程序员可能有压力了

@茹炳晟：一个我看到的例子“作为一个不会前端的后台工程师，每当我尝试让 AI 帮我写前端代码时，带来的挫败感总是强化我另一个念头：与其让AI 给我生成各种我兜不了底的代码，不如让 AI 先教我学会前端开发。”

@张伟涵：熊老师，站在企业角度，大幅提升效率至今仍然是个美好的愿望。都相信肯定会提升，但如何衡量，带来何种变化，目前还不是很明显，所以大幅提升，不敢题啊

@张海龙：未来程序员的单兵能力会越来越强，一个人相当于现在一个 team 很有可能

@魏昭：@赵俊民是的，纯粹的仅仅编写代码的码农应该要被取代的

@彭鑫：我听到的普遍说法是提高了开发人员的幸福感。如果说到大幅提高生产率，那么第二天领导就会让你出裁员名单了。

@张伟涵：@彭鑫 @熊英飞彭老师是懂的，但这个不是本质。因为谈效率，你必须得有一个闭环系统，能快速的获得反馈来修正和调整。这块业界和学术界一直没有明确的答案。即使没有大模型的出现，传统的效率都很难衡量。

@彭鑫：确实，端到端的效率不太好衡量。而且每一次的任务和任务上下文（就像流水一样）都是不一样的，没法在一个水平线上对比开发效率

张伟涵：

以o1为代表的慢思考模型在任务拆解上，特别是加持RAG后（当前OpenAI o1不支持）效果很好，特别是从0到1的系统开发，能够搭建工程，新建文件，启动调试等功能给程序员带来的极大的效率提升点。

特别是前端开发类，模型已经充分掌握了各类前端框架的使用方法。我估计前端领域将会迎来新的开发模式。

但是对于复杂系统的增量开发，当前没有任何银弹，没有，never，即使顶级的模型，最多只能做到辅助，行继续写的辅助。这是让人多少有点失望的领域。去年一年的探索，我们也仅仅勉勉强强让模型认识私有框架，提供函数级语句级内容生成，需求级的生成多少有点妄想。

但，这也是有希望的，我们近期在R1上的实践（有多模型配合+RAG，具体方案不便），基本可以达到领域语言对其的程度，这驱动我们把模型当成一名新员工看，从新员工的角度来应用模型。（探索中）

说到开发模式，一定会改变，至少当前我的前端组已经改变，我将逐步尝试让程序员只做审核，不让输出具体内容的模式。但是，回到本源，大模型的出现替换或替代的是不思考的工作或人，任何想躺下来不思考，靠模型来完成工作的想法的人将会被无情的替代。但任何有思考的将会替代其他。比如有可能程序员被替代，也有可能产品经理被替代。核心是是否有思考，是否愿突破自己的边界。

刘焕勇：

以OpenAI O1/3和DeepSeek R1为代表的推理模型在软件工程（包括软件开发、运维、测试及质量保障等）领域的表现如何？这个问题，我不在行，所以不做过多评价。但是目前以我们进行一些需要推理分析的场景，例如司法检察院场景的筛选、证据链发现，且分析效果的确是有收益的。所以类比到运维、测试故障分析上，应该也会又收益。此外，对于大模型强大的推理能力是否会颠覆现有的软件开发模式并对就业市场造成重要的影响？这个问题，我觉得颠覆不了，颠覆这个口号喊了很久了，但该怎样还是怎样，在就业市场上，淘汰的是低端技术开发者，这个的确是。但资深的，有门槛和经验要求的，倒也安全。

观点讨论

@茹炳晟：我个人的感觉，随着LLM的深入落地，基础编码岗位会减少，但是资深工程师的价值会被进一步放大。强者越强，他们更多地做设计和分析，更好地理解和结构化拆解需求

@魏昭：是的，领域专家应该还是很值钱的

@张伟涵：是的，甚至会替代产品经理

@彭鑫：如果一个产品经理可以被大模型取代，那这个产品的创新性一般也不太强

@刘焕勇：只会画原型的产品经理会很麻烦

@茹炳晟：我的感觉是更好地赋能产品经理，让他们的SWOT等更具有全局视野

@张伟涵：提供了从底向上重构的机会。有追求的工程师，把自己熟悉的领域交给模型，自己扩展不熟悉的领域，跨层向上思考问题，结合商业场景结构，迅速实现落地，成为可能。有思考，有追求的工程师逆袭的机会大大变大

@茹炳晟：也让谈的原型实现成本更低，更容易低成本迭代改进

@张伟涵：@刘焕勇是的，因为模型生成的看不懂，有问题也不会调，最后一公里会很难受

@彭鑫：我觉得大模型是很好的参谋，负责收集、加工、整理、按需提供信息和知识，决策还是人的事

@茹炳晟：决策必须是人，否则我感觉就要完蛋了

@魏昭：我觉得还是要分场景吧，简单的场景是否agent就决策掉了

@茹炳晟：所以copilot的名字还是起得很好的，必须是co，只有人才能是主驾驶。

@彭鑫：@张海龙你前面说到“许愿式编程我是不看好的”，这里的“许愿式编程”是不是指陈述需求让大模型生成完整应用的这种？

@张海龙：我指的是自然语言提需求

@茹炳晟：@魏昭实现层面感觉可以，但是需求上要什么，要的最终结果应该还是由人说了算

@张伟涵：@彭鑫@茹炳晟不会完蛋的，我们内部曾经有过一次有意思的推演：

AGI实现后，大模型自己发觉自身的成本过高，电力消耗过大，对于新知识的学习训练成本很高。从而触发模型自我改进。然后模型找到了蛋白质突起神经元，然后开启蛋白质的低成本模型改造。然后迭代中一次次的失败，有了四角兽，有了两脚兽，有了觉醒

然后循环了，碳基硅基相互引导了

彭超：

在较为复杂的任务和 Benchmark 上，如评测大模型和 Agents 的 SWE-bench上，只使用深度思考模型无论是在 Agentless 还是在 Agent 系统上评测，目前都暂时还没有取得最好的成绩。随着各类好用的 IDE、Agent 的普及，简单 App、小程序和网站的开发门槛已经被明显降低，因而未来一些基础的、重复性代码编写、测试用例执行的岗位需求有可能会减少，但是相应的和大模型结合的新兴岗位也可能会应运而生。另外，在专业、复杂的软件开发和运维任务中，还没有看到“颠覆”的明显信号。

观点讨论

@陈鑫：DeepSeek R1思考能力上了一个很大的台阶，预计在未来需求分析，架构设计方面起到关键作用，这种作用会强化在复杂任务的AI辅助效果。届时AI对生产力的提升将进入全新阶段，并且加速开发者的能力分化。善于使用AI辅助编程的开发者的生产力将大幅领先于不用AI的开发者。

@赵俊民：Deepseek一个搞定所有知识检索，学习编程，学习技术方式感觉完全颠覆，再也不需要去看那些晦涩编程书籍

@茹炳晟：资深工程师使用AI 辅助编程时，与初级工程师差别很大的。资深工程师会运⽤多年⾟苦积累的⼯程经验来塑茹炳晟造和完善 AI 的输出，LLM 加速了他们本身就能干的活，他们的专业知识反过来保证了代码的可维护性。初级工程师只关注功能实现，会很轻易接受llm生成的代码，从而留下各种质量隐患，初级工程师在用LLM构建他们自己都不能完全理解的“脆弱”系统。

李彦成：

DeepSeek R1在论文中已经表述了软件工程能力不如DeepSeek V3，我们实测发现和上一个版本能力差距差不多，R1反而能力会强一些，可能受益于推理能力的增强。

大模型强大的推理能力会增强软件开发模式，并不会颠覆，可以增强从0到1的过程，做快速简单的Demo验证，但是对于复杂的系统，我们根本看不到从0到1的Demo演示。可以增强迭代过程，但是更多是局部操作，无法更加宏观的修改代码。人理解需求都要非常长的一个过程，甚至不同的人对需求的理解也存在偏差，大模型无法精确理解这些，但是可以帮助程序员加速验证过程。AI代码助手更像是一个放大器，越优秀的程序员，效率越高，对于初级程序员，放大效率有限。由于会增强软件研发模式，会减少软件工程师数量，催生出更多的AI工程师岗位。

魏昭：

当前基于推理的大模型技术正在推动软件开发范式从单点的代码补全、生成（Copilot模式）演进为具备深度推理能力的智能体模式（Agent模式）。包括通过思维链技术实现复杂需求的拆解，结合多轮反思验证机制保障需求理解的准确性；支持仓库级代码生成与重构，但在复杂业务逻辑处理和精确定位代码修改位置方面仍需优化；基于语义推理的日志分析和性能模式识别能力，提升故障定位效率等。

新型人才更加需要强大的模型输出审查能力，提问能力及其多角度引导模型的交互能力等，因此将催生包括模型输出审计师，设计新型开发流程的人机协作架构师等新职业。

王翀：

根据我目前的体验，大模型在软件工程领域中一些相对原子、well-defined的任务上具有非常不错的表现；但是在一些相对复杂的场景下，想要端到端地来使用大模型很多时候表现并不好。

至于“大模型强大的推理能力是否会颠覆现有的软件开发模式”，我认为得看具体的业务领域和软件形态。一些“短平快”的业务场景和开发模式可能确实会很大程度上颠覆。比如，简单的小程序、网页、App的开发需求应该可以很大程度上自动化。但是对于传统互联网大厂和一些传统行业所积攒的海量存量代码和复杂软件系统，离完全自动化应该还有很大距离。此类软件的开发中，编码实际上只占据很小一部分，大量的时间花在了理解代码背后的业务逻辑和各种设计决策以及团队沟通交流上，未来很长一段时间应该还是人机交互或者以人为主。

观点讨论

@彭鑫：而且很多小应用网上实在太多，大模型背也背下来了。所以以后千万不要拿贪吃蛇这种级别的应用生成速度提升来推及企业开发迭代速度的提升。

Question 5

主持人：未来，大模型将在软件工程领域发挥重要的作用，那么我们应当如何认识人（包括软件用户与软件工程师）与大模型的关系？软件工程中哪些环节适合基于大模型的自动化处理，哪些环节需要人机协同增强，哪些环节必须保持人的深度参与？我们需要着重培养什么样的人机协作能力从而更好地面对未来？在此过程中，哪些具体技能或思维方式尤为关键？如何建立对应的评估标准？

王昊奋：

在大模型与软件工程的协同发展中，人与AI的关系应定位为智能合作伙伴。人类（包括用户和工程师）需主导战略规划、创新设计及伦理决策，而大模型则承担自动化执行和辅助分析任务，形成互补式协作。代码生成、测试用例生成、持续集成/部署（CI/CD）等重复性任务可通过大模型高效完成，而基础性代码修复、文档生成等低层级操作也适用自动化；需求分析（大模型可快速生成需求草案，但需人类结合业务场景细化验证）、架构设计（AI提供模式建议，人类需权衡系统扩展性和领域约束）、代码优化（模型生成优化方案，工程师需评估性能与可维护性平衡）等需人机协同增强；创新性功能设计、复杂系统集成等需创造性思维的环节、涉及伦理审查、隐私安全的关键决策以及跨领域知识融合与模糊需求解读等必须人类深度参与。

软件工程师需强化领域知识深度与AI工具驾驭能力。其中，交互设计能力（掌握提示词工程以精准引导模型输出）、系统思维（将碎片化AI输出整合为可信解决方案）和批判性评估（快速验证AI输出的逻辑完备性与业务契合度）等是需培养的核心能力。而评价标准中不仅包含代码生成准确性、测试覆盖率、部署成功率等技术指标，还将引入需求对齐度、人机交互频次优化率等协作效能，以及面向业务价值的创新功能占比、缺陷率下降幅度等指标。

邱锡鹏：

工程师利用大模型加速开发流程，如代码生成、测试用例设计、文档编写等，但需保持对系统整体架构和业务逻辑的掌控。

大模型可以帮助生成初步的需求文档或系统设计，但需要人类工程师进行细化与验证。大模型可以提供架构建议，但架构的最终设计需要人类的全局视角和业务理解。

大模型可以辅助创新，但真正的创造性工作（如新算法设计、新商业模式）需要人类的独特思维。大模型技术发展迅速，工程师需要不断学习新工具和方法。

评估标准可以看大模型是否显著提升了开发效率，减少了多少重复性工作。

观点讨论

@张海龙：我认为未来的软件工程师都会有两个 AI 辅助，一是 Copilot 类，就是同步跟人工作，另外一类是 Agent，跟人类异步工作，帮助完成一些非关键任务。

@张海龙：人类还是要负责定义 what，实现上有大量的 AI 服务

熊英飞：

推理模型出现之后，大模型迎来新一轮的高速发展，暂时还看不清上限在哪里，可能难以清晰的预测未来，也不清楚未来人们应该掌握的核心技能。我这里想要引用OpenAI首席产品官Kevin Weil对东京大学副校长同样提问的回答：“从现在开始将AI用起来，将之融入工作生活。一旦遇到新问题，尝试用AI解决，以此逐渐跟上AI发展的步伐。”

陈鑫：

软件开发者的设计、编码、测试阶段一定是大模型最先发挥价值的领域，并且出现大幅的效能提升和替代。在涉及到需求设计、理解和多模态的方面由于AI能力所限仍然需要大量人力参与，例如产品设计、手工测试等领域。未来开发者最重要的是需要学会与AI配合做好架构设计和验证工作，大量的执行层面的逻辑编写将不再重要，这时候开发者将回归软件的本质，更多的时间花在设计方面。

茹炳晟：

人和模型的分工我觉得要分层来看，首先是自动化层，比如重复性任务（如单元测试生成、日志分析）、模式化代码（CRUD接口）、文档转换（翻译）等这类任务可以由AI来主导，这也是AI最擅长的领域。其实是需要人机协同的领域，比如架构设计（AI提供备选方案，人类决策）、代码审查（AI标记潜在缺陷，人类确认）、故障排查（AI定位根因，人类修复）。最后是人类主导层，像创新性需求挖掘（如未被用户明确表达的需求）、伦理审查（如AI生成的算法是否存在歧视）、复杂系统权衡（性能、成本、可维护性的多目标优化），这些我觉得依然要长久依赖人类专家。

刘焕勇：

在未来，人（包括软件用户与软件工程师）与大模型的关系，其实一直是使用者和工具的关系，这个不会变的，大模型无论如何，都是一个工具，工具的属性就是让人拿来解决特定的问题，至于其能到什么发挥到多大的价值，那么就得看其所能参与到的环节。现在大模型最多的用法就是做代码补全，或者写一些初步代码，然后工程师去改，也有用大模型进行代码审查、优化的，也有用大模型进行开发流程思路设计的。一个完整的开发流程，包括需求理解->系统设计->编码开发->调试测试->上线监控。我觉得大模型都可以参与到这些环节里，但每个环节都没办法全自动化处理，都需要人机进行协同增强，这其实体现的，就是一个副驾驶的意义。至于人机协作能力，我稍微跑下题，从人的角度上而言，需要着重培养发现问题和提问的能力，这是高校在现在这个时代十分需要做的一个工作，因为很多工作都可以让大模型去参与，但怎么参与，怎么去更好地发挥大模型的优势，怎么让其更高效，需要提想法，以及优化思路，因为大模型需要针对特定场景做特定微调或者特定的去教，发现问题了得解，不足得优化。实际上，按照最近培养员工这块的经验来看，现在大模型时代下，发现问题的能力、建模的能力、解决问题的思路，这些是十分欠缺的。很多人过度依赖大模型，其实在某种程度上，对于新手，正要打基础的人来讲，并不是太合适；评估标准这块，我觉得也不用纸面上的评估，直接让其去解决一个特定的项目场景，从一个具体的项目出发，看其能建模、提出什么问题、解决什么问题就好，也很好量化。

观点讨论

@茹炳晟 ：领域知识的抽象和建模能力和批判思维能力我个人认为是最重要

@刘焕勇：现在大模型正在让高校的计算机学生水平钝化

@彭鑫：对我们考虑大模型时代的计算机和软件工程专业学生能力培养也很有益

@刘焕勇：@彭鑫所以彭老师和高校的老师，可以多引导下，工业界需要有思考力的优秀人才。

张伟涵：

谈到这基本已经跟DS没有太多关系了。我始终持有一个观点，人和模型的分界线是“思考”，人要始终保持高纬度的思考，停留在“道”的层面，让模型去做“术”的事情。

做“术”的事情，分几个阶段，首先一些简单的重复的活动将被模型替代，去年一年的实践充分证实了这个观点。在软工层面要从程序员的作业活动本身开始分析，把作业活动中的上下文切换、知识查找等活动逐步降低。这是我们追求的第二步，目标是程序员的所有动作（键盘敲击，鼠标点击）只跟价值内容产生有关，都是带思考的内容，其他都由模型来处理，模型推动开发活动的每一个环节前进，在光标停留较长时，提供代码推荐、函数解读；在编码过程中实时检查语法、低级错误，辅助生成注释；在编码完成，主动切换至UT或调测状态；整个过程程序员始终关注内容，专注价值输出。

总结下，需要业务思考的部分由程序员主导，模型辅助，上下文切换类的工作由模型主导，程序员确认的方式呈现。

在我的团队里，我们的蓝图是通过模型构筑团队能力的底线，将领域知识，专家经验训练道模型中，以此来卡位整个团队的能力。

观点讨论

@茹炳晟：领域知识的抽象和建模能力和批判思维能力我个人认为是最重要

彭超：

软件用户通过大模型获得更智能和便捷的服务，软件工程师则将大模型视为提升开发效率和质量的得力助手（甚至是 peer）。在这个过程中，人都应该更理解大模型的工作原理、存在的缺陷和问题，从而更好地编写 prompt，最大程度上激发大模型的潜能。另外大模型缺乏人类的创造力、情感和道德理解，因此人应该还是软件工程的主导者，负责监督过程和做出关键决策。

适合大模型处理的环节：代码和测试用例生成，简单的 debug 和缺陷修复等。在需求分析、复杂问题解决、项目架构设计上，还需要人机协同。在涉及安全、隐私、用户体验等重要的环节上，人应当扮演关键的角色。

在这个过程中，应该注意发展自己的大模型使用技巧，如提示工程、对模型结果的解读能力等。同时我们需要具备对大模型生成的代码的评估能力，依然需要保持较好的编程基本功。

李彦成：

人和大模型是一种协同关系，像一对伴侣，只有更加互相"了解"对方，才能一起协作的更好。开发人员要更加了解大模型的原理，知道如何构建Prompt，如果构建Agent，利用好大模型的特性；大模型要更加"了解"人，提供个性化服务，提升推理能力，知识能力等，趋近于AGI。我认为在开发过程中，有非常多重复性任务，开发人员要时时刻刻想着可自动化的流程，让大模型替你执行这些任务，解放开发人员做更多高纬度的思考，如架构、性能、稳定性、可维护性。如果测试领域能有所突破，将大大改变软件开发模式，即使大模型提供的代码不准确，可以利用更多的尝试和验证弥补这些不足。对于软件人员，未来更多的要不断的探索大模型可赋能的点，自己动手最重要，只有自己亲自尝试过，才能更了解大模型能做哪些。

魏昭：

人与大模型将形成一种人机协同开发模式，从基于实时上下文感知的智能辅助Copilot模式演进到领域任务的Agent模式。软件工程中的单点代码补全生成、测试用例生成等适合自动化处理，系统的需求分析、仓库级代码改写，生成等需要人机协同完成，复杂业务逻辑开发，核心架构设计，隐私数据处理，合规审查、伦理风险等需要人的深度参与。

能力培养包括大模型输出的复杂思维链的强大审查、判断、批判性思维能力；多角度引导模型深度思考的提问能力等。

王翀：

未来开发人员与大模型之间应该是协作关系，是互为信息和知识的生产者和消费者的关系。可以预见的是，大模型在未来的“推理”能力应该会越来越强。但是，只有推理能力还不够，还需要有基本的上下文信息和facts知识作为基础，才能产生可靠的输出。对于某些软件工程任务，上下文信息和facts知识是相对容易获取的（甚至大模型本身已经具备），这时候个体的人更多地是作为信息和知识的消费者来对大模型输出进行甄别和确认。但是对于复杂软件维护这类任务，只靠软件代码和文档等原始制品作为大模型的输入是不够的，我们需要对此类场景事先对相关软件制品做好深度的知识化，才能按需地满足大模型进行推理所必要上下文和领域知识。当然，在进行知识化的过程中，需要人的参与来提供一部分专家知识并借助大模型进行信息的整合处理。

至于在各个环节中人机参与的比例，很难用一句话说清楚，需要看上下文和知识有多大程度上需要由人来提供。

类似的，未来人机协作能力很多时候体现在：一是能否高效地提供模型推理所需要的额外信息和知识；另一个是能否对模型输出的信息进行有效的甄别和确认。所需要的具体技能点以及评估标准我暂时没什么思路，还需要多看看其他老师的想法。

访谈结束

CodeWisdom

一个有知识的软工公众号

发现智能化编程之道