核心发现
方法论
论文采用质性研究方法，分析2024年1月CCF Beautiful Lake Seminars中的六场专题讨论。24名参与者包括17名学术研究者和7名产业从业者；作者先用NVivo进行转录、开放编码和意见卡片整理，再通过Open Card Sorting按主题聚类，并由其他作者复核，最终归纳出覆盖软件生命周期七个方面的26项挑战。
关键结果
- 研究识别26项关键挑战，覆盖需求与设计、编码辅助、测试代码生成、代码审查、软件维护、漏洞管理，以及数据、训练和评估。论文同时梳理CodeX、AlphaCode、CodeT5、CodeLlama、StarCoder和DeepSeek-Coder等代表性系统。
- 代表性模型显示规模与数据迅速扩张：CodeX使用约159GB公共GitHub代码；AlphaCode在12种语言上预训练，并在5000人Codeforces竞赛中超过54.3%参赛者；DeepSeek-Coder使用2T tokens，其中87%为代码。
- 论文并未开展统一的模型对比实验，而是形成问题框架。其证据来自研讨会讨论、既有研究和模型案例，因此26项挑战是研究议程，而非性能排行榜或因果验证结果。
研究意义
论文的重要性在于把“LLM能否写代码”转化为“如何让LLM可靠地参与完整软件生命周期”。它指出，自然语言与程序语义之间的鸿沟、模型输出不稳定、数据持续变化、隐私与许可证风险，会同时影响质量、效率、安全和可追责性。对学术界而言，该框架帮助研究者超越单一代码生成指标；对产业界而言，它提醒团队必须把模型接入测试、审查、供应链治理和人工责任体系，而不能把生成结果直接视为可部署软件。
技术贡献
技术贡献主要是系统化整合，而非提出新模型或新算法。论文总结LLM4SE流程中的数据构建、微调、提示和下游任务，并具体讨论Topological Sort for Dependency Analysis、Adapter Tuning、LoRA、Prefix Tuning、Prompt Tuning、Zero-shot、Few-shot与Chain-of-Thought。它进一步将这些机制映射到需求设计、代码生成、测试、审查、维护和漏洞管理，形成从模型训练到工程落地的端到端研究地图。
新颖性
相较于聚焦单项任务的代码生成综述，本文以SDLC为主线，结合24位学界与业界参与者的共同讨论，提出跨阶段的26项挑战清单。其新颖性在于研究议程与工程流程的对齐：模型能力、数据治理、评估标准和责任边界被放入同一框架，而不是只比较HumanEval上的通过率。
局限性
- 参与者仅24人，且讨论集中于一次研讨会；主题选择、发言权重和作者编码都可能造成选择偏差，挑战的重要性尚未通过大规模问卷或产业数据验证。
- 论文没有提供统一基准、统计显著性、消融实验或26项挑战的优先级，因此不能据此判断某一技术路线优于另一条路线。
未来方向
后续研究应建立覆盖真实仓库、企业代码、持续集成日志和安全事件的动态基准，评估功能正确性、可维护性、安全性、许可证合规和开发者负担。还需研究检索增强、工具调用、执行反馈、长期上下文、数据溯源和可审计代理，并通过真实团队实验验证LLM是否带来持续的生产率与质量收益。
AI 总览摘要
大语言模型正在改变软件工程，但真正的难题已不再是模型能否生成一段看似合理的代码。GitHub Copilot X、GitLab Duo等工具展示了自然语言驱动开发的潜力；然而，需求含糊、代码语义复杂、模型输出不稳定，以及训练数据中的隐私、版权和恶意内容，使“生成”距离“可靠交付”仍有明显差距。
Gao等人以软件开发生命周期为主线，研究LLM4SE的整体流程。论文分析了24名参与者在六场专题讨论中的观点，结合NVivo开放编码、意见卡片和Open Card Sorting，归纳出26项挑战。框架涵盖需求与设计、编码辅助、测试代码生成、代码审查、维护、漏洞管理，以及数据、训练和评估。作者还梳理了CodeX、AlphaCode、CodeT5、CodeLlama、StarCoder和DeepSeek-Coder等模型，并讨论LoRA、Adapter Tuning、Prompt Tuning与Chain-of-Thought等机制。
论文的核心讯息是：LLM4SE应被视为“模型、工具、测试、知识库和人工治理”的协同系统，而不是自动程序员。规模数据带来能力，也带来污染、泄漏和分布漂移；提示可以改善任务适配，却不能保证事实正确；代码生成可以加速开发，却必须由执行测试、静态分析、审查和安全扫描闭环验证。研究的直接产物不是新的性能数字，而是一份面向未来的研究议程：建立真实、动态、可审计的评估体系，让软件质量、安全与责任和模型效率同等重要。
深度分析
研究背景
软件工程从结构化编程、模块化设计发展到面向对象、云计算和AI4SE。早期AI已用于需求分析、自动修复和项目管理；LLM则进一步支持自然语言到代码的端到端流程。CodeX、AlphaCode、CodeT5、StarCoder和DeepSeek-Coder说明代码模型能力快速提升，但工程可靠性仍未解决。
核心问题
核心问题是如何把概率性、会产生幻觉且持续更新的语言模型，安全地嵌入确定性要求很高的软件生命周期。自然语言与程序语义存在鸿沟；需求、依赖、上下文和安全约束常不完整；公开代码还可能包含低质量、恶意、隐私或许可证敏感内容。
核心创新
- ��以SDLC而非单一代码生成任务组织问题。
- ��基于17名学者和7名产业人士的研讨讨论，形成26项挑战。
- ��把数据构建、微调、提示技术与下游任务连接起来。
- ��同时覆盖质量、效率、可靠性、可信度和安全，而非只关注HumanEval得分。
- ��将模型案例与工程治理问题放在同一研究地图中。
方法详解
- ��数据构建：从GitHub、Software Heritage等来源收集代码；StarCoder2采用长行、自动生成文件、字母比例和编码数据过滤。
- ��数据组织：利用Topological Sort for Dependency Analysis按依赖顺序组织文件，并用特殊token表示提交信息等类型。
- ��模型适配：Adapter Tuning冻结主模型；LoRA注入低秩矩阵；Prefix Tuning加入层前缀；Prompt Tuning改变任务输入。
- ��推理提示：比较Zero-shot、Few-shot和Chain-of-Thought。
- ��任务映射：覆盖设计、编码、测试、审查、维护和漏洞管理。
- ��质性分析：NVivo开放编码、意见卡片、Open Card Sorting与多作者复核，归纳26项挑战。
实验设计
本文不是受控模型实验，而是研讨会驱动的质性研究。24名参与者进行了六场约四小时的专题讨论，主题包括大模型软件工程、代码智能、质量保证、数据与评估、开源工程及未来趋势。作者以NVivo编码并交叉复核。论文引用HumanEval作为代码生成标准数据集，并报告模型训练规模，如AlphaCode的967B tokens和DeepSeek-Coder的2T tokens，但没有提出新的统一测试集或消融实验。
结果分析
最主要结果是26项挑战的分类框架，而非某模型的胜负。论文显示，AlphaCode在5000人Codeforces竞赛中超过54.3%的参赛者；DeepSeek-Coder的训练数据为87%代码、13%中英文自然语言；StarCoder训练token超过1T。上述数字说明能力基础快速扩大，但不能证明真实企业软件质量同步提升。
应用场景
LLM可用于需求探索、软件建模、代码补全、API推荐、智能问答、文档生成、测试生成、模糊测试、代码异味检测、重构、日志分析、根因定位、漏洞扫描和供应链分析。实际部署应配合版本控制、沙箱执行、静态分析、测试门禁、人工审查、数据脱敏和许可证检查。
局限与展望
研究受单次研讨会、有限样本和质性解释影响，26项挑战缺少优先级及独立量化验证。模型表格的数据口径也不完全一致，训练数据规模不能直接代表能力。未来应开展长期、跨组织和任务闭环实验，建立可复现基准，并测试代理在真实仓库中的回归率、安全事件、维护成本和开发者信任。
通俗解读 非专业人士也能看懂
可以把软件团队想成一家大型餐厅。传统做法是顾客先写菜单需求，厨师设计菜谱，采购食材，厨师做菜，质检员试吃，经理检查卫生，最后再端上桌。大语言模型像一位速度极快的实习厨师：你告诉它“做一道适合过敏者的菜”，它能马上给出菜谱、步骤，甚至帮你修改旧菜单。
问题是，这位实习厨师并不总知道食材是否新鲜，也可能把网上看到的错误菜谱当成正确答案；他还可能忘记顾客的过敏信息，或者使用来源不明、不能商用的食材。因此，论文强调不能只看它做菜快不快，而要检查需求是否理解、材料是否安全、成品是否符合标准、过程是否可追溯。
论文组织了24位专家和从业者的讨论，列出26个风险点，覆盖从想菜单到维护厨房的全过程。模型可以帮助写需求、做设计、生成代码、编写检查方案、寻找漏洞和分析日志，但每一步都需要试运行、复核和责任人。真正成熟的做法不是让机器独自开餐厅，而是让它成为受监督、可检查、可纠错的高效助手。
简单解释 像给14岁少年讲一样
想象你在做一个超大型游戏。你只要对一个很聪明的聊天机器人说：“帮我做一个有排行榜、组队和反作弊功能的游戏。”它可能几秒钟就写出一堆代码，还能解释每段代码做什么。听起来像开挂，对吧？CodeX、CodeLlama和DeepSeek-Coder就是专门学习代码的模型。
但代码不像普通作文，少一个符号、漏掉一个规则，游戏就可能崩溃；更糟的是，漏洞可能让玩家盗号。机器人也可能误解你的要求，生成看起来漂亮、实际不能运行的代码。它学习过的大量公开代码还可能有错误、秘密信息或版权限制。
这篇论文没有说“某个机器人赢了”，而是邀请24位研究者和工程师讨论整个开发过程，最后整理出26个挑战：需求、设计、写代码、测试、审查、维护和安全都包括在内。就像游戏上线前要反复试玩、找bug和检查外挂，AI写出的代码也必须经过测试、分析和人类审核。
所以最好的结论不是“AI会取代程序员”，而是“程序员多了一个速度超快但会犯错的队友”。你可以让它先写草稿、找线索、生成测试，但不能把最终决定完全交给它。未来的关键，是让这个队友记得上下文、说明依据、接受检查，并在出错时能被及时发现。
术语表
Large Language Model (大语言模型)
通过大规模数据训练、预测和生成文本或代码的模型。它通常基于Transformer等架构，但论文重点讨论其在软件工程中的应用。
作为LLM4SE的基础能力，支持设计、编码、测试和维护。
LLM4SE (大模型软件工程)
将大语言模型整合进软件开发生命周期的研究与实践范式。其目标不是单纯生成代码，而是辅助完整工程流程。
论文围绕该范式归纳26项挑战。
LoRA (低秩适配)
冻结原模型，仅训练低秩矩阵，以较少参数适配新任务。它降低了微调成本并减少灾难性遗忘风险。
论文将其列为代码模型的主要微调技术。
Chain-of-Thought (思维链)
要求模型逐步展开推理，而非直接给出答案的提示方法。它可能改善复杂任务表现，但推理文本不等于真实正确性证明。
用于增强代码生成等软件工程任务的任务理解。
HumanEval
用于评估代码生成的标准数据集，通常通过单元测试判断生成函数是否正确。它主要衡量局部编程能力，不能覆盖完整软件质量。
论文将其作为CodeX之后广泛采用的评估基准。
Software Development Life Cycle (软件开发生命周期)
从需求、设计、编码到测试、部署和维护的完整过程。论文用它组织LLM在不同阶段的作用与风险。
是论文提出跨阶段挑战框架的主线。
开放问题 这项研究留下的未解疑问
- 1 如何评价模型对真实大型仓库的长期影响仍不清楚。HumanEval等局部基准无法反映回归缺陷、架构一致性、维护成本和团队协作效果。
- 2 模型生成代码的许可证、隐私和安全责任如何追溯尚无统一机制。需要数据溯源、来源标注、可审计日志和跨组织治理标准。
- 3 不同提示、模型版本和上下文会导致结果变化。社区需要动态基准和真实CI流水线实验，以测量可靠性而非一次性成功率。
应用场景
近期应用
受控代码助手
企业可在私有代码库中部署模型，用于补全、文档、测试草稿和代码问答。前提是数据脱敏、权限隔离、沙箱执行、静态分析与人工合并审核；预期收益是减少重复劳动，而不是取消质量门禁。
安全与维护副驾驶
维护团队可让模型总结日志、分析用户评价、定位根因、生成修复候选并辅助漏洞扫描。所有修复应通过回归测试、依赖检查和安全审查，尤其避免把未经验证的补丁直接部署到生产环境。
远期愿景
可审计的端到端软件代理
长期目标是让代理从需求出发，调用检索、编译、测试、静态分析和部署工具，形成可追踪证据链。实现这一愿景需要稳定的长期上下文、动态知识库、可靠评估、权限控制和明确的人类责任边界。
原文摘要
With the advent of large language models (LLMs) in the artificial intelligence (AI) area, the field of software engineering (SE) has also witnessed a paradigm shift. These models, by leveraging the power of deep learning and massive amounts of data, have demonstrated an unprecedented capacity to understand, generate, and operate programming languages. They can assist developers in completing a broad spectrum of software development activities, encompassing software design, automated programming, and maintenance, which potentially reduces huge human efforts. Integrating LLMs within the SE landscape (LLM4SE) has become a burgeoning trend, necessitating exploring this emergent landscape's challenges and opportunities. The paper aims at revisiting the software development life cycle (SDLC) under LLMs, and highlighting challenges and opportunities of the new paradigm. The paper first summarizes the overall process of LLM4SE, and then elaborates on the current challenges based on a through discussion. The discussion was held among more than 20 participants from academia and industry, specializing in fields such as software engineering and artificial intelligence. Specifically, we achieve 26 key challenges from seven aspects, including software requirement & design, coding assistance, testing code generation, code review, code maintenance, software vulnerability management, and data, training, and evaluation. We hope the achieved challenges would benefit future research in the LLM4SE field.