ICSE 放榜之后技术群里最不缺的就是论文清单。但说实话每次看到那种翻译一遍标题、贴一排官网链接的清单我都觉得信息量约等于零。读者需要的不只是有哪些论文而是这些论文解决了什么问题、方法值不值得追、结果能不能用。这个系列的中篇我打算把 ICSE 2025 清单中间那一批论文按主题拆开讲清楚每类研究在做什么、为什么值得读以及哪些方向有机会落地。ICSE 全称是 International Conference on Software Engineering国内一般直接叫软件工程顶会CCF A 类和 FSE 一起被视为这个领域最硬的两个会议。2025 年这届投稿量继续涨录用率依然残酷。如果你只追热榜看到的永远是那几篇 AI 炼丹论文但真正决定领域走向的往往是清单中段那些看起来没那么惊艳、却把问题做透的研究。1. 今年 ICSE 的选题风向AI 从辅助工具变成了研究基础设施在整理中篇之前我把 ICSE 2025 论文全集的标题和摘要粗扫了一遍一个很强烈的感受是AI 已经不再是软件工程研究里的一个子方向而是几乎所有子方向都在用的底层设施。程序分析论文在用大模型做别名分析测试论文用大模型生成断言缺陷预测论文用大模型抽取特征连需求工程都在讨论怎么用大模型从自然语言描述里生成规约。这种变化不是一篇文章带来的而是整个研究方法论正在切换。过去很多年软件工程研究的传统套路是分析-建模-验证靠的是程序分析、形式化方法、经验研究。这两年大家默认的流程变成了构造 Prompt-调用模型-验证结果论文里讨论的重点也从单纯的准确率扩展到了稳定性、成本、上下文窗口管理以及如何在工程约束下让模型输出可信。你去看这批中篇论文的实验部分几乎每篇都要交代模型版本、温度参数、Prompt 模板、API 调用成本这在三年前是不可想象的。对普通开发者和工程团队来说这个风向值得关注。它意味着过去需要专家手工完成的任务——写测试、查缺陷、改 Bug、审代码——正在变成可以用 AI 半自动完成的任务。但同时也意味着理解程序分析基础原理的人会越来越值钱因为大模型只是把方案提供给你怎么验证、怎么兜底、怎么处理边界情况仍然需要硬核的工程能力。换句话说AI 拉低了操作门槛但没有降低判断门槛。这一批论文里还有一类变化值得单独说Agent 化。摘要里频繁出现agentplanningtool use这些词意思是模型不再只做一次推理提交结果而是在一个循环里反复读取代码、执行命令、观察输出、修正方案。这已经不是简单的补全代码而是把模型当作一个能自主执行任务的团队成员。对工程实践来说这才是真正可能改变工作流的东西。2. 中篇论文清单六个方向里值得细读的摘要与背后逻辑我把这批论文按主题归成六类每一类都会告诉你这个问题是什么、研究者现在用什么方法做、以及它离实际工程有多远。这六类不是按论文数量排的而是按对一线开发和团队管理者的参考价值排的。2.1 代码生成从接着写到仓库级理解和代码生成相关的论文在清单里占比最高但今年大家关注的明显不是单函数级补全了。越来越多的论文把问题定义成仓库级生成给定一个仓库的现有代码结构模型要能在正确的位置生成正确的新代码。难点主要在三个地方——跨文件的上下文依赖、第三方库的版本差异、以及生成结果和既有代码风格的一致性。解决思路通常分两类。一类在 Prompt 上下文上下功夫用静态分析定位真正相关的符号和调用链再把这些信息喂给模型而不是简单地把整个仓库塞进上下文既费钱又容易让模型抓不住重点。另一类在生成后的验证上下功夫通过编译、规则校验或测试过滤低质量结果宁可生成慢一点也要保证输出能用。这两类思路其实都在做同一件事给大模型加护栏。这类研究离工程实践有多远以目前各大 AI 编程助手的迭代速度来看仓库级生成的能力正在快速产品化。我的判断是半年到一年内主流 IDE 插件就会用上类似的上下文筛选策略这是这批论文里最值得盯着看的方向。2.2 测试生成让机器理解测试意图自动化测试生成在 ICSE 一直有稳定的存在感今年被大模型推到了一个新高度。传统工具比如 EvoSuite、Randoop 擅长生成覆盖代码行的测试但生成的断言质量一言难尽可读性也差工程师拿到手基本还是要重写。大模型的出现让研究者开始追求有业务语义的测试先从文档、Issue 或代码上下文推断这段代码应该满足什么行为再生成一套完整测试包括标准的 Arrange-Act-Assert 结构。这类论文的评估最难做。测试好不好不是行覆盖率和分支覆盖率能完全衡量的。一批覆盖率一样的测试可能一个能抓住隐藏缺陷另一个什么都测不出来。比较有共识的做法是结合变异测试把生成的测试放到变异体上跑看它们能不能真正杀掉变异。能通过变异测试考验的方案才算是实用导向的方案。从落地角度看大模型生成测试已经有了商业产品雏形但它在真实项目上的表现还很不稳定核心问题在于测试意图的获取。文档写得稀烂、Issue 描述模糊的项目生成出来的测试往往也是花架子。所以我的建议是可以试用但别指望它能替代你思考这段代码到底要保证什么。2.3 自动修复补丁质量比数量更重要自动程序修复合集里的位置一直很稳今年最大的变化是传统基于模板的修复方法逐渐被基于大模型的方法替代。论文关注的焦点也从能不能修变成了怎么确定修对了。没有测试暴露缺陷的时候修复结果对不对本身就是个很棘手的问题。一些工作尝试用形式化方法约束补丁的合法空间另一些工作训练专门判断补丁语义是否等价的模型。从工程角度看这条线离落地最近。GitHub Copilot 的自动建议、各种 AI 代码助手的缺陷提示背后都能看到类似研究的身影。但真正要做到在 CI 阶段自动修复并且通过全部测试还有一段路要走。一个很现实的问题是自动修复生成的补丁万一在没覆盖到的场景里引入新 Bug责任是谁的这不仅是技术问题也是工程责任问题。我对这类研究的态度是关注补丁质量的评估方法比关注修复成功率更有价值。因为就算你不在生产环境用自动修复理解什么样的补丁算正确补丁这件事本身就能提升你自己的代码评审水平。2.4 仓库挖掘与经验学习从历史数据里找规律这类研究经常被贴上数据挖掘的标签今年依然稳健。Git 提交、PR 评审记录、Issue 讨论、代码评审时的行内评论都成为研究对象。大模型让以前很难处理的非结构化文本可以被挖掘了。比如自动总结代码变更的 commit message自动为一个 PR 生成初步评审意见从历史故障数据中学习故障模式这些都是热门小方向。这些研究的共同特点是不需要修改编译器或运行时直接作用于软件研发过程的数据流所以产品化路径非常短。很多论文的实验结果直接就可以做成 IDE 插件或 CI 机器人。比如说基于历史提交训练的变更风险预测模型已经能比较准确地标记出哪些代码改动需要更多人工关注这东西放在大型团队的 Code Review 流程里价值很大。我个人对这类研究比较偏爱因为它们做的是软件工程自身的功课。在一个到处讲 AI 取代程序员的时代能回头把研发过程本身的数据利用好是性价比非常高的事情。2.5 需求与架构AI 时代还有两个硬骨头需求工程和软件架构在 AI 时代显得没那么性感但这届 ICSE 上它们反而有不少有意思的内容。需求工程方向论文在讨论如何用大模型从用户反馈、产品文档甚至法律条款中抽取需求以及如何验证 AI 生成需求的正确性和一致性。这其实是个很难的问题用户说要快一点到底是要更低的延迟还是更高的吞吐量模型很难判断。架构方向则开始关注架构决策记录的自动生成以及微服务系统里依赖关系与性能问题的自动检测。这类研究短期内不会成为热搜但对做中大型系统的团队反而是最能直接抄作业的。一个能自动从代码变更和讨论中生成架构决策记录的助手对维护老系统的团队来说比再增加十个自动化测试还有用。如果你所在团队正在经历系统重构或者架构治理建议重点关注这类论文的实验方法哪怕只看摘要和结论也能给你提供不少思路。2.6 漏洞检测与供应链安全把风险前置安全方向的论文数量比往年多了不少核心诉求是把漏洞发现的时间往前移。传统静态分析工具用规则匹配已知模式对未知漏洞无能为力大模型的长处在于理解和推理上下文。问题在于误报率。好几篇论文都在解决同一个核心矛盾怎么在保留大模型理解能力的同时把误报压到工程师能接受的范围。常见做法是大模型加静态分析双通道——先用规则和依赖分析缩小范围再让大模型做深度判断最后再用可达性分析确认漏洞是否能被实际触发。供应链安全也开始借助软件物料清单SBOM和漏洞数据库的关联分析识别哪些风险实际上是内部可达的而不是简单地把 CVE 列表甩给运维。这类研究的价值在于把安全从上线前扫描变成了开发中持续防御。对于金融、医疗这类监管严格的行业这方面的论文值得产品和技术负责人专门花时间读。3. 从论文到落地顶会研究怎么进入你的日常工具箱很多人会问读这些顶会论文到底有什么用我的回答是今天开发工具里的很多能力两三年前就在 ICSE 上以论文形式出现过。AI 代码补全的上下文选择策略早期论文就在研究怎么用静态分析选取相关代码片段IDE 里的重构建议和坏味道检测很多理论模型早已发表甚至 Git 提交信息自动生成也有好几年的学术积累。从论文到产品的路径通常有三条。第一条是作者毕业后进入大厂或创业公司把研究成果直接带进工业界。第二条是论文附带开源实现社区自发使用和迭代慢慢形成事实标准。第三条是云厂商看重某些能力把论文方法集成进托管服务。这里面的时间差短的一两年长的五六年但大部分有价值的研究最终都会以某种形式进入开发流程。那怎么判断一篇论文将来会不会进你的工具箱三个标准。第一它有没有定义清楚一个你在真实开发中会遇到的问题而不是为了发论文硬造出来的问题。第二它有没有给出可以复现的开源实现实验是否透明。第三它有没有正视自己方法在真实场景下的失败案例。满足这三条的论文哪怕现在只是原型也值得持续关注。4. 不靠转发清单建立自己的 ICSE 论文追踪管道我对收藏即学到这件事一直很警惕。与其把别人整理好的清单存进收藏夹吃灰不如建立一条自己的轻量追踪管道每年花几小时就能跟上顶会动态。最基础也最可靠的渠道是会议官网和官方程序册论文标题、作者、摘要都在里面DBLP 可以按作者跟踪Google Scholar 的 Alert 功能也很好用设定几个你关注的方向有新论文就会推送过来。很多人喜欢等别人整理其实官网放出的时间往往比社区整理早一到两周。拿到论文列表之后我的习惯是分三步走。第一步先刷摘要把论文粗分成三级必须精读、值得浏览、看个标题就够。第二步对必须精读的论文用五问法过一遍问题是什么、为什么重要、方法是什么、验证了什么、有什么局限。第三步把真正对你当前项目有启发的内容记录到表格里。这个表格不需要多复杂我的格式是这样的方向论文主题一句话贡献开源链接可落地性阅读状态测试生成基于 LLM 的断言生成用文档和上下文推断测试意图生成带语义的断言GitHub 链接中期可用已精读读论文正文时我的顺序和大多数人不太一样。我通常先看图、再看表、最后才读方法细节。图能告诉你系统的整体架构表能告诉你方法的真实收益。如果图表都没能说服我那方法细节通常也不用读了。这个方法对顶会论文尤其适用因为好的工作一定会在图表里把核心亮点说清楚。5. 清单的中段为什么更值得认真读顶会论文也有自己的二八定律。最受关注永远是最佳论文、Keynote 和社交媒体上传播最广的那几篇它们确实代表了一个方向的前沿。但清单中段那些论文——既不是当届热点也不是团队官网首页挂出来的宣传稿——往往是工程研究的血肉。它们的问题定义更具体实验更踏实限制条件写得更老实反而更容易在你自己的项目里找到对应场景。我举一个自己的经历。前年我在给团队做 Code Review 工具选型翻了很多评测文章都不满意最后是在一篇普通的 ICSE 论文里找到了一个让机器自动理解代码提交影响面的方法。那篇论文在当时互联网上几乎没有讨论但它定义的问题和我的场景高度重合而且作者把实验数据完整开源了。我照着论文实现了原型效果远超预期。这之后我就养成了一个习惯每届顶会除了关注热门论文一定要专门留出时间看中段论文。读 ICSE 论文清单别只盯着标题刷。建议你按照自己当前的技术短板来筛——如果你正在为测试质量发愁就重点找测试生成方向的论文如果你在搞架构治理就搜架构决策相关的关键词。逐篇读过之后你会发现真正能在三个月内帮你改进工作方式的往往就是这些被清单中段淹没的朴实工作。如果让我总结这一批 ICSE 2025 中篇论文的共同气质那就是两句话AI 在往工程纵深走工程在给 AI 设护栏。代码生成、测试生成、自动修复这些方向已经不再是能不能做的探索期而是进入了怎么能做得稳、做得可控的深水区。我个人整理清单的习惯是每周挑一篇真正读透不贪多。论文清单不是收藏夹读完、跑通、写笔记才算真正拥有它。下篇我会把剩下几个方向收尾到时候见。