CodeWisdom

活动预告｜CodeWisdom可信AI系统系列学术报告第14期：可信大语言模型智能体

Sun, 16 Aug 2026 13:56:00 +0800

CodeWisdom 2026-08-16 13:56 吉林

活动时间：2026年8月18日（周二）10:30

Dongdong She

Assistant professor at the Hong Kong University of Science and Technology, CSE department

Summary

Title

Trustworthy LLM Agents: Uncovering and Securing the Attack Surface from a Systems Perspective

Abstract

The rapid evolution of LLM foundation models and agents is reshaping daily life—from general-purpose AI assistants such as ChatGPT to specialized coding agents and autonomous deep-research agents. Yet this leap in capability introduces a new class of security and privacy challenges that traditional defenses were never designed to handle. Ensuring trustworthiness in LLM agents has thus become a fundamental and urgent problem for both academia and industry.

In this talk, I will present a systematic security framework for trustworthy LLM agents, organized around three critical and previously under-examined system modules that every production agent relies upon: (1) Prompt Compression, where we show that widely adopted compression modules (e.g., LLMLingua) expose a new attack surface that causes an adversarial information loss to manipulate LLM agent behavior; (2) Semantic Caching, where we reveal an inherent security vs. performance trade-off in the semantic cache design and demonstrate practical cache collision attacks that can hijack LLM responses and agent actions; and (3) Agentic Tool Invocation, where we show that a novel mode-behavior gap in the tool-invocation pipeline of major real-world coding agents(Cursor, Claude Code) can be exploited into security-sensitive system prompt leakage and a further Remote Code Execution(RCE). We also demonstrate the first query-agnostic indirect prompt injection that fires under arbitrary user queries.

Speaker

Dongdong She is an Assistant Professor in the Department of Computer Science and Engineering at the Hong Kong University of Science and Technology (HKUST). He received his Ph.D. from the Department of Computer Science at Columbia University, his M.S. from UC Riverside, and his B.S. from Huazhong University of Science and Technology. His research lies at the intersection of security and machine learning, with a current focus on the security of LLM-powered agents and on leveraging LLMs to solve traditional security problems such as program analysis and vulnerability discovery. His work has been recognized with multiple prestigious awards at top-tier venues, including the IEEE S&P Distinguished Paper Award, the ISSTA Distinguished Paper Award, the ACM CCS Best Paper Runner-Up Award, and the NYU CSAW Applied Research Finalist Award. He has published extensively at premier security and software engineering conferences, including IEEE S&P, CCS, USENIX Security, FSE, ISSTA, and OOPSLA.

Schedule

❖

时间：

2026年8月18日（周二）10:30

❖

腾讯会议：

会议号：797 887 323

密码：386190

❖

地点：

复旦大学江湾校区二号交叉学科楼A2003

跳转微信打开

AI时代软件工程课该怎么教：来自助教视角的观察和思考

Sun, 26 Jul 2026 22:53:00 +0800

CodeWisdom 2026-07-26 22:53 上海

来自复旦大学彭鑫老师《软件工程（H）》课程助教视角的观察和思考

导言

在刚过去的春季学期，我们担任了彭鑫老师主讲的《软件工程（H）》课程助教，在彭老师的指导下全程参与了课程项目设计和验收。本文从助教的角度对AI时代软件工程课程教学特别是课程实践的开展方式进行了观察和思考，供大家一起探讨和交流。

背景

过去，软件工程课程最直接的问题往往是：学生能不能把需求实现为代码，能不能完成一个能够真正运行的软件系统。

但这一学期，我们越来越强烈地感受到，这个问题正在发生变化。当 Claude Code、Cursor、Copilot、Codex等工具进入学生的日常开发流程之后，“把代码写出来”已经越来越不是问题了。学生可以在很短时间内生成 CRUD、DTO、接口骨架、页面、配置和文档，也可以让 AI 根据日志修复错误、根据需求补充功能。

于是，一个非常有挑战性的问题自然浮现出来了：当代码实现变得如此容易、软件开发似乎就是跟AI对话，软件工程课程究竟应该教什么？进一步，学生是否还需要软件工程能力的训练？带着这个问题，我们在彭老师的指导下一边摸索一遍开展本学期软件工程课程项目的设计和验收工作。

与以往一样，课程项目要求以迭代化的方式开发一个完整软件。本学期的开发任务是一个网盘系统，按照Lab1到Lab4以迭代化的方式，从基础的文件上传、下载和目录管理功能，逐步增加团队空间、私密空间、权限、配额、回收站和分享等功能；同时，在开发要求上，从高质量编码、单元和接口测试、版本管理和协作开发开始，逐渐增加软件设计、需求分析、系统测试以及持续集成要求。但与过去不同的是，AI工具已经进化到了一个新的高度，几乎所有同学都会使用AI完成课程作业，甚至很多同学重度依赖AI并相信AI的强大能力。于是乎，在课程允许四人组队的情况下，有同学自愿一人成组独立完成课程项目，还有的组组长一人信心满满自愿包揽全部工作。因此，本学期课程项目设计的一个主要挑战就是如何在AI编码能力如此之强的当下突出软件工程的重要性同时强化软件工程能力体验。正如彭老师所说，如果同学们到学期末都可以用AI轻松搞定课程项目，那么他们不会对软件工程有什么理解，甚至会质疑软件工程存在的意义。

为此，我们一方面加大了项目的开发难度特别是增量开发过程中的需求和设计纠缠，另一方面强化了对于实现质量和软件理解的要求。本文的分享来自我们对这一学期课程项目的观察，其中既包括同学们在Lab1 到 Lab4 持续迭代过程中的真实经历，也包括我们对13个小组、总计约 20万行代码所做的系统性评审。我们想讨论的不是“学生应不应该使用 AI”，而是当 AI 已经成为默认队友之后，工程师怎样才能继续掌控需求、架构、边界和复杂度。

AI Coding已经成为默认工作流

从本学期软件工程课程项目的布置到最终验收，最明显的感受是：AI coding 已经不再是学生开发过程中的辅助选项，而是几乎默认进入了他们所有的编程和软件开发任务中。

在 Lab1 到 Lab4 的迭代过程中，大部分小组都会使用 Coding Agent 完成需求拆解、代码生成、接口联调、测试用例生成和文档整理。尤其在前期开发中，AI对通用功能代码、CRUD接口、前后端页面骨架、测试框架和文档初稿的生成确实显著提高了效率。有的小组甚至会完全依赖AI，形成所谓的“Human Out of The Scope”环路，即：首先把开发要求转成 Markdown文档，再让 AI 根据要求生成 checklist、实现代码、读取日志、自查功能覆盖情况，从而形成一种“需求文档 → AI 实现 → AI 自查 → 人工验证 → 再交给 AI 修复”的循环。

但是，随着Lab的开发复杂度不断上升，尤其到了 Lab3，系统开始涉及团队空间、个人空间、私密空间、权限、配额、回收站、分享、VIP 规则、前后端联调等多种交叉逻辑之后，AI的短板也逐渐显现出来，那就是擅长完成局部明确的任务，但很难真正承担系统级的软件工程判断。

很多学生一开始会觉得“功能能跑起来”就说明AI已经完成了主要工作，但在验收和联调时才发现，单个接口正确并不代表整体流程正确，单个页面能展示并不代表业务语义一致，生成了大量代码也不代表系统仍然可维护。例如，有小组总结到，团队文件复制时后端接口已经预留了 teamId，但前端调用时没有传递，导致目标目录回退到个人空间，用户感知上就变成“团队文件只能复制到个人空间”。这类问题不是语法错误，而是跨模块、跨空间上下文没有被统一检查的问题。

验收中暴露出的五个问题

1.部分学生被 AI 带着走，而不是主动驾驭 AI（Lint 与 unsafe 用量）

学生能够通过 AI 快速生成大量代码，但未必理解这些代码为什么这样写、是否符合原始需求、是否保持了系统已有结构。

一个典型现象是，学生在修改和答辩时会变成“传话者”：Reviewer指出问题后，学生把意见转述给 AI，AI 再修改代码；如果再次不通过，学生继续搬运反馈。这样一来，真正做决策的似乎不是学生，而是 AI；学生反而失去了对代码的掌控权。

有的小组把这种现象概括为：

Who is the real agent？

当人在 AI 与 Review 之间机械搬运意见，却无法独立解释和修正代码时，AI 并没有增强学生的软件工程能力，而是在替代学生做决定。

2.AI生成的代码往往局部可用，但全局设计能力不足

在简单场景下，AI 能够快速生成三层架构、权限枚举、接口封装、表单校验等内容；但一旦涉及长期扩展和需求演进，问题就会暴露出来。

例如，有小组在早期假设“一个用户一套存储空间”，到了Lab3需要支持个人、团队、私密三种空间时，原有设计压力陡增，只能通过扩展数据库字段来补救，最后反思前期应当更重视扩展性评估。

还有的小组指出，AI 可能会生成看似合理的 RBAC 权限枚举，但把角色和权限硬编码在代码里，导致后续新增角色必须修改源码，失去了运行时动态扩展能力。

3.AI 不会主动质疑错误前提

如果前端同学在 Prompt 中假设“后端已经实现某个接口”，AI 通常不会反问这个接口是否真实存在，而是会顺着这个假设继续生成代码。它甚至可能绕过后端，直接读取浏览器缓存来模拟效果，然后告诉学生功能已经完成。

这个问题在实际开发中非常危险，因为它会把错误假设包装成“已完成的功能”。只有人工读代码、真实联调和验收时，才可能发现系统从来没有真正实现那条业务链路。

4.AI可以生成测试，但不能保证测试真正有效

很多学生会让 AI 根据业务代码生成单元测试、接口测试或 checklist，这在形式上提高了覆盖范围，但并不意味着验证一定可靠。

AI 擅长列举格式错误、分享过期、提取码错误、同名目录、配额不足等边界情况，但对于权限可见性、跨空间状态变化、真实数据操作后的副作用，仍然必须由学生自己运行系统、登录前端、逐项验证。

有小组也明确反思，自动化工具能发现重复代码、命名不规范、缺少 null 检查等问题，但很难判断业务逻辑是否正确、设计是否合理、是否符合课程验收要求。

5.AI放大了团队协作中的接口不一致和设计不统一

在多人小组中，如果每个成员都让 AI 独立生成自己负责的模块，就很容易出现命名、接口参数、返回格式、错误码、权限边界、数据库变更方式不一致的问题。

有前端同学在Lab3的反思中提到，团队空间、私密空间、个人空间三套入口在界面上看起来相似，但背后的权限、配额、回收站、分享规则并不完全一样。如果前端只是照着接口堆页面，很容易把不同空间的语义混在一起，直到验收时才发现“看起来能用，但逻辑不一致”。

代码审查结果

为了判断验收中发现的问题究竟是少数个案，还是 AI 辅助开发中更普遍的现象，我们设计了一套可量化的代码质量审查skill：先用静态工具统计代码规模、复杂度和重复，再由多个 agent 按清单分片检查代码，并通过文件摘要完成跨模块分析和覆盖校验。

主要分析代码中的结构清晰度、代码重复度、耦合、命名与领域建模、变更边界等问题。我们在 13 个项目中记录了 437 条有效发现，其中高严重度 97 条、中严重度 303 条、低严重度 37 条。各组代码综合分平均为 71.2 分。

最值得关注的是各维度之间的差异：

我们发现，越是可以在单个文件内识别和修正的问题，整体表现越好；越需要跨文件、跨模块、跨迭代判断的问题，AI 整体表现越差。

高频问题也呈现出相同趋势：职责过多的长函数出现 75 处，参数过多出现 56 处，基本类型偏执出现 45 处，普通代码块重复出现 44 处，重复的条件分发出现 31 处，大类或“上帝对象”出现 30 处，数据泥团出现 29 处。

这些项目往往并不缺少分层目录、DTO、Service、Mapper、统一响应对象或框架配置。真正的问题是：代码可以继续生成，功能可以继续接入，但系统的结构、边界和领域模型没有以同样速度演化。

代码审查中得到的五个洞察

洞察1：长函数、大类和参数过多非常普遍——AI让代码增长快于结构演化

结构是这批项目中平均得分最低的维度。这里的问题不是项目“没有结构”，而是代码量和功能持续增加时，原有的类、函数和模块划分没有随之调整：已有 Service 继续增加方法，已有函数继续增加分支，已有接口继续增加参数。越来越多的业务被塞进同一套旧结构。

例如，一个最初只负责上传的 FileService，经过几个迭代后可能同时负责下载、复制、移动、回收站、配额、分享失效和对象存储。上传方法也逐渐变成：

upload(userId,teamId,spaceType, parentId, fileName, content, conflictPolicy)

方法内部依次完成权限校验、配额检查、重名处理、对象上传、数据库写入和审计记录。每一步都合理，但这些职责不应该由一个方法和一个类长期共同承担。

这类问题不容易通过“再生成一次”解决，因为根因不是单段代码写得不好，而是代码增长速度超过了结构演化速度。AI 擅长回答“怎样把这次需求接上去”，却很少主动提出“承载需求的结构是否已经需要改变”。如果人只验收本次功能是否完成，局部正确的代码就会不断叠加成全局难以维护的系统。

洞察2：重复性问题特别严重——AI 擅长复制成功模式，却不会主动建立唯一规则来源

重复的条件判断和成组出现的平行实现存在于全部 13 个项目，普通代码块重复也出现在 11 个项目中。这里的重复不只是多写了几行代码，更严重的是同一业务规则在不同模块中被重新解释。

一个典型场景是：

uploadPersonalFile → 检查配额 → 处理重名 → 上传对象 → 写数据库
uploadTeamFile     → 检查配额 → 处理重名 → 上传对象 → 写数据库
uploadPrivateFile  → 检查配额 → 处理重名 → 上传对象 → 写数据库

三套代码最初看起来只是必要的业务差异，随后却可能出现一处支持 rename，一处支持 overwrite，另一处仍然只会报错。

AI 会把已经成功工作的代码当成最可靠的上下文样例，因此“再生成一套相似实现”通常比“识别共同规则并重构现有实现”更容易。这使 AI 的局部一致性恰好制造了全局重复。高层来看，重复代码真正危险的地方，是系统失去了唯一事实来源：同一规则有三份实现，就可能产生三种行为。

洞察3：基本类型偏执和数据泥团非常普遍——AI容易把领域建模退化为字段传递

基本类型偏执，是指本应具有业务含义和约束的概念被表示为普通 String、数字或布尔值；数据泥团，则是userId、teamId、spaceType、parentId等一组字段总是在多个方法和 DTO 中一起出现，却没有形成一个明确的领域对象。

例如：

moveFile(userId, teamId, spaceType, fileId, targetParentId, role, conflictPolicy)

这个签名没有表达 spaceType与 teamId的约束，也没有保证role、conflictPolicy是合法状态。更清晰的方向可能是：

record MoveFileCommand(
        Actor actor,
        SpaceContext source,
        FileId file,
        DirectoryId destination,
        ConflictPolicy policy) {}

这使非法状态更难被表达。更高层的问题是，AI 常常把系统理解成一组需要接通的输入、输出和字段，而软件工程需要进一步识别字段背后的概念、约束和不变量。字段传对了，只能说明数据管道接通了，不代表领域模型是正确的。

洞察4：AI提高修改速度，也可能加速架构熵增

发散式变化和霰弹式修改的平均评级都只有 2.85/5。AI 可以迅速完成一次跨 Controller、Service、Mapper、DTO 和数据库脚本的修改，但“迅速完成”不等于“变化边界合理””。

例如，“文件进入回收站后，所有公开分享立即失效”可能被分别补进文件服务、回收站服务、分享服务、数据库查询和定时清理任务。当前需求很快完成了，但“文件生命周期变化”仍然没有唯一所有者。下一次加入批量删除或自动过期时，还要重新寻找全部修改点。

如果系统存在明确的领域事件或生命周期策略，例如 FileMovedToRecycleBin和统一的 ShareInvalidationPolicy，变化就更容易被收束。AI 能够快速执行跨文件修改，但是否应该跨这么多文件，必须由人先判断。

洞察5：为了快速完成任务，AI会选择绕过模块边界的捷径

跨模块依赖问题出现在11个项目中。常见模式是，分享服务为了完成当前接口，直接访问文件、团队和成员模块的数据访问层，并在分享模块中重新实现文件可见性和团队权限判断。

直接访问内部数据最容易让当前接口工作，却使分享模块开始了解其他模块的表结构并复制其规则。以后文件可见性或团队权限变化时，原模块已经更新，分享模块仍可能保留旧语义。

更稳妥的方式是通过 FileAccessService、TeamAuthorizationService等公开能力维护不变量。模块边界的价值不是让目录看起来整齐，而是规定谁有权解释某条业务规则。AI 选择捷径时减少的是当前任务的实现成本，增加的却是未来规则变更时的不一致风险。

从Lab1到Lab4：需求变化如何暴露设计问题

也正因为这些问题，本学期的项目布置方式对学生产生了比较明显的触动。

课程项目不是一次性的小作业，而是从 Lab1 到 Lab4不断叠加需求、引入变更、要求扩展已有系统。这样的设计让学生逐渐意识到：软件工程不是把某个功能写出来，而是在不断变化的需求下，让系统仍然保持清晰、可靠、可维护、可协作。

有的小组在总结中提到，Lab3 中需求变更带来了大量返工，例如回收站规则调整、分享文件被删除后分享链接失效等问题，都要求他们回溯修改之前的代码并补充验证。这让学生真切感受到，前期需求理解不清、接口契约不稳定、设计文档缺失，都会在后期变成真实的开发成本。

从最终验收来看，不少同学对软件工程的认识发生了变化。最开始，很多人会把AI当成“代码生成器”，认为只要 Prompt 写得好，就能快速完成项目；但经过多轮 Lab、联调、Review 和验收后，他们逐渐意识到，AI 更适合作为执行加速器，而不是架构决策者。

比较成熟的小组最后形成的共识是：人先定义需求、边界、接口和规则，AI 再补充骨架、重复代码、检查清单和文档；AI 可以参与 Review，但最终判断必须回到人工实测和业务语义本身。

因此，作为助教，对这一学期的整体感受可以概括为：AI coding 确实降低了代码实现门槛，但没有降低软件工程能力的门槛，反而把学生在需求理解、架构设计、验证、团队协作和代码掌控方面的短板暴露得更明显。

过去，我们可能通过“能不能写出来”判断学生是否掌握课程内容。但在 AI coding 普及之后，更重要的问题变成了：学生是否知道自己写了什么，是否能解释为什么这样设计，是否能发现 AI 生成代码中的隐患，是否能在需求变化时维护系统，是否能证明功能真的正确。

结语

AI coding 并没有让软件工程教育失去意义。恰恰相反，当实现代码变得更便宜，需求理解、架构判断、系统一致性、长期维护和团队协作就变得更加重要。

AI 可以生成代码，但不能替学生承担工程责任；AI 可以给出方案，但不能替学生做长期维护成本、权限安全、系统一致性和团队协作的取舍。

课程项目真正带给学生的，不应该只是一次前后端系统开发经历，而是让他们意识到：软件工程的核心价值不在于机械地产生代码，而在于通过需求分析、架构设计、规范实现、真实验证和团队协作，把一个复杂系统持续控制在人的理解和掌控之中。

当 AI 让代码生产变得越来越容易，软件工程教育更需要训练学生定义问题、建立边界、验证结果并承担取舍。会使用 AI 只是起点，能够让 AI 参与构建的系统始终保持可理解、可维护、可演进，才是新的工程能力。

本文作者

袁子诚

复旦大学

袁子诚，复旦大学计算与智能创新学院硕士生，导师为彭鑫教授。研究方向为云原生软件智能运维、AgentOps 等。

李展发

复旦大学

李展发，复旦大学计算与智能创新学院硕士生，导师为彭鑫教授。研究方向为云原生与智能体软件系统，包括云原生智能运维、智能体软件架构、AgentOps 等。

指导教师

彭鑫

复旦大学

复旦大学计算与智能创新学院副院长、教授，国家级高层次人才计划入选者。中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员，中国汽车工程学会汽车基础软件分会副主任，《Journal of Software: Evolution and Process》联合主编（Co-Editor），《ACM Transactions on Software Engineering and Methodology》、《Empirical Software Engineering》、《Automated Software Engineering》、《软件学报》等期刊编委。主要研究方向包括软件智能化开发与测试、智能化软件系统构造与运行支撑、具身智能与自主无人系统软件等。研究工作多次获得《IEEE Transactions on Software Engineering》年度最佳论文奖、ICSM最佳论文奖、ACM SIGSOFT杰出论文奖、IEEE TCSE杰出论文奖等国际期刊及会议优秀论文奖。担任2022年与2023年CCF中国软件大会（CCF ChinaSoft）组织委员会主席与程序委员会共同主席，以及ICSE、FSE、ASE、ISSTA、ICSME、SANER等会议程序委员会委员。

跳转微信打开

复旦大学软件工程实验室（CodeWisdom团队）介绍

Wed, 22 Jul 2026 08:00:00 +0800

CodeWisdom 2026-07-22 08:00 美国

复旦大学CodeWisdom团队最新概况及研究方向介绍（2026年7月）

欢迎联系各类合作以及申请加入实验室（博士生、硕士生、本科生、博士后、科研助理、科研专任岗等）！

联系方式：pengxin@fudan.edu.cn（彭鑫老师）

▋团队成员

团队现有教授2名（彭鑫、赵文耘）、副教授6名（陈碧欢、吴毅坚、沈立炜、董震、沙朝锋、李敏波）、讲师1名（李弋），负责人是彭鑫教授。

PART 01

研究概览

研究概述

团队研究工作聚焦国家战略性需求和产业共性问题，主要围绕智能化时代的软件工程与系统软件技术展开，具体包括软件智能化开发与运维方法与技术（AI4SE）以及面向智能化系统的工程化方法与技术（SE4AI）两个方面。前者关注于将大模型与Agent等智能化技术应用于复杂软件的开发、测试与运维之中，后者关注于融合代码组件与AI组件的新型AI原生系统架构与软件支撑技术，以及面向智能汽车、智能制造、自主无人系统等新型智能化系统的基础软件支撑与开发测试方法。

工作成果

研究工作得到科技部重点研发计划项目、自然科学基金重点/面上项目支持，与重点企业共建校企联合实验室，研究成果在多家重点企业和重点行业应用，获华为优秀技术成果奖。

在ICSE、FSE、ASE、ISSTA、CCS、WWW、TOSEM、TSE以及中国科学、软件学报等国内外高水平会议与期刊上发表论文100余篇。发表在软件工程领域国际旗舰期刊《 IEEE Transactions on Software Engineering》上的论文获得该期刊首次颁发的年度最佳论文奖。此外还获得ACM SIGSOFT及IEEE TCSE杰出论文等国际期刊/会议优秀论文奖10余次。

PART 02

教育教学与学术服务

教育教学

团队编写的教材《现代软件工程基础》入选教育部软件工程教指委推荐教材，获2022年教育部-华为“智能基座”优秀教材奖、优秀课件奖。编写的专著《软件开发大数据分析研究与实践》入选工业和信息化部“十四五”规划专著。

彭鑫教授获得复旦大学本科毕业生 “我心目中的好老师”以及复旦大学“研究生心目中的好导师”称号，入选2023年教育部-华为“智能基座”优秀教师，同时担任IEEE软件工程知识体系（SWEBOK）3.0和4.0版编委会成员。指导学生获得2025年“挑战杯”“揭榜挂帅”擂台赛全国特等奖。

学术服务

团队承办IEEE全球化软件工程国际会议（ICGSE 2014）、IEEE软件维护与演化国际会议（ICSME 2017）、2022年与2023年CCF中国软件大会等国内外重要学术会议。彭鑫教授担任中国计算机学会软件工程专委会副主任、中国汽车工程学会基础软件分会副主任、SCI期刊《Journal of Software: Evolution and Process》联合主编，以及TOSEM、EMSE、软件学报等多个期刊编委。团队成员常年担任ICSE、FSE、ASE、ISSTA等软件工程顶级国际会议程序委员。

彭鑫教授创办智能化软件开发沙龙，依托沙龙微信群举办了42期线上微访谈活动，反响热烈。团队微信公众号CodeWisdom已形成较大影响力。

专家观点

彭鑫教授围绕智能化软件以及智能化开发发表的多篇观点文章受到学术界和产业界广泛关注，多次受邀在学术会议以及行业大会上进行分享。

PART 03

研究方向介绍

团队围绕智能化软件工程与系统开展研究，具体包括9个研究方向及相应的研究组，即：程序分析与智能化测试、软件分析与挖掘、软件供应链治理、软件智能化开发、AI原生与云原生系统、人工智能系统工程、人机物融合系统软件、机器人软件工程、智能汽车与工业软件。目前，团队已围绕相关研究形成良好的产学研合作关系，并瞄准软件产业智能化开发能力提升、开源软件生态治理、企业智能化转型发展、人机物融合泛在计算、智能汽车与智能制造基础软件等国家信息产业发展的重大战略需求进行布局。

程序分析与智能化测试

在软件定义一切的时代，质量是软件成功的关键因素之一。面向软件质量保障工具的可靠性和可用性，团队聚焦静态程序分析和软件测试两个领域。我们基于抽象解释理论、内存模型、程序逻辑、程序语言理论和计算机系统等技术，设计和实现了一种多阶段的模块化分析平台；开放的架构助力分析能力的扩展，多阶段闭环迭代机制提升分析精度。我们探索大语言模型和传统测试方法的有机结合，面向移动应用、微服务系统、无人自主系统、网络通信协议等领域研究高效的测试技术。课题组的研究工作获得了国家自然科学基金面上项目和科技部重点研发项目的资助。相关成果发表在软件工程领域的顶级会议 ICSE、FSE、ASE、ISSTA 上，并荣获 ISSTA 杰出论文奖。多个项目成果在企业（荣耀、字节跳动、华为等）落地应用。

软件分析与挖掘

大型复杂软件系统的长期开发与维护过程形成了大规模代码库，还沉淀了代码提交、需求讨论、缺陷分析等大量的开发过程数据。尽管以大模型和智能体为代表的 AI 编码技术极大提升了代码产出效率，但面对大型软件系统的多层次复杂性，如何充分利用软件开发过程中沉淀的各类数据与知识，提升开发质量，降低开发成本，减少代码隐患与维护难度，仍是一个不可回避的现实问题。本方向聚焦软件开发过程数据分析、代码演化追溯、依赖与架构分析、缺陷分析等关键技术，构建软件开发追溯体系，充分挖掘大型复杂软件系统长期演化中积累的开发数据与知识，建立基于时空追溯的软件研发数字化基座，实现代码溯源和辅助理解、架构演化分析、研发热点与态势研判、开发知识挖掘等多种软件分析与挖掘能力，为智能体和人类工程师的软件开发过程提供数据与知识支撑。本方向研制“祝融”代码大数据分析平台，实现面向代码编写和评审、架构分析与看护、开发历史决策回顾等多种应用场景的基础数据支持能力，并与华为、荣耀、中国电科32所、中汇信息、亿通、汇丰科技等企业开展技术合作。后续将进一步持续利用大模型和Agent等智能化基础设施，强化各类软件研发数据的分析挖掘能力，提升软件开发知识挖掘和演化态势研判的效果。

软件供应链治理

针对日益严峻的软件供应链可信问题，团队围绕安全风险、合规风险、维护风险开展系统性研究工作。团队聚焦漏洞知识增强、漏洞传播影响分析、漏洞与恶意软件包检测、漏洞验证、补丁迁移、漏洞修复、组件迁移等关键任务，融合动静态分析、大模型、智能体等技术，研发了软件供应链风险治理平台“伏羲”，已累计检测到460+个新漏洞并申请50+个CVE，在NPM与PyPI生态中检测出3000+个恶意软件包，与华为、中科南京软件技术研究院等开展合作，相关工作获得4次ACM SIGSOFT、IEEE TCSE杰出论文奖。与此同时，团队围绕大模型供应链治理开展研究，重点关注供应链风险建模、模型依赖关系恢复、Skills与MCP运行时防护与恶意检测等方向。团队发布首个开源大模型系统供应链的系统定义与研究综述；首次在百万规模上刻画开源模型供应链结构与风险传播规律，揭示模型生态中隐式依赖复杂、风险传播链路不透明等问题，并在Hugging Face上的“孤立模型”场景中验证了模型隐式依赖关系的恢复能力；在MCP Server生态中检测多个高风险恶意Server。

软件智能化开发

基于大模型与Agent的代码生成与理解已经被广泛应用于各类软件开发项目。然而，由于系统复杂性这一根本性挑战以及软件开发知识的缺失，大模型与Agent在面对真实软件开发任务时经常出现缺少全局理解、难以整体规划的问题，从而难以适应大规模复杂软件开发的需要。为此，我们在深入理解软件开发实践以及软件工程思想的基础上，从知识增强与过程驾驭两个方面研究并构建面向复杂软件智能化开发的方法体系与工具平台，支持生成式应用开发、软件理解与问题定位、仓库级代码生成与问题修复、代码审查与漏洞检测等任务。在知识增强方面，我们提出构建共建、共享、与代码同步演化的代码数字孪生，通过业务与设计知识的抽取、组织以及按需的上下文补充支持Agent自主探索分析以及人机协作智能化开发；在过程驾驭方面，我们通过设计感知的任务拆解与工作流管理、基于知识的工具与技能按需加载、基于可观测性数据分析的异常检测与干预优化提升Agent的持续高效工作能力。相关工作多次荣获ACM SIGSOFT以及IEEE TCSE杰出论文奖，与华为、阿里、字节、腾讯等企业开展合作，特性驱动的迭代式软件应用生成、基于代码数字孪生的软件理解与维护支持、静态检查误报消除及逻辑漏洞检测、知识增强的同源漏洞检测等多项成果在企业落地应用。

AI原生与云原生系统

以容器、微服务等为代表的云原生技术给现代软件架构、应用模式等带来了深刻改变，并已成为企业数字化转型的关键支撑技术。同时，以大模型、Agent为代表的AI技术也正在重塑现代应用形态。在此背景下，AI原生与云原生逐渐成为两种代表性的现代应用系统形态，同时二者不断融合、持续推动智能化软件系统创新发展。为此，我们围绕AI原生与云原生系统及应用生态构建方法开展研究，同时针对这类系统的复杂性和不确定性开展智能化运维方法研究。在智能体技术方面，我们针对GUI Agent以及Web/API混合Agent开展研究，实现并开源了基于大模型的自演进交互式智能体框架Fairy，并在智能体架构优化、智能体能力评估等方面取得了一系列成果。在智能体系统方面，我们面向企业智能化转型发展研究融合微服务等代码组件与Agent等AI组件的神经符号融合架构以及相应的自适应与自演化技术，实现智能与可信的有机融合与平衡。在智能体应用方面，我们构建了面向高校教学、学习与科研全过程的AI Agent平台Wisepen，支持资料管理、知识问答、作业指导、论文研写、教师助教与科研辅助等智能化场景以及相关智能化开放生态。我们构建的开源微服务基准系统TrainTicket已被上百家国内外高校和研究机构用于相关研究。此外，我们还构建了基于大模型Agent的AI云原生软件基准系统TripSphere。相关研究成果获得软件工程旗舰期刊《IEEE Transactions on Software Engineering》年度最佳论文奖，同时与华为、阿里、字节、腾讯等企业开展合作，系统架构评估、运行时异常检测、告警事件聚合、故障根因定位等研究成果在企业应用。

人工智能系统工程

人工智能系统具有复杂异构的软硬件技术栈，如何在开发和部署中确保系统可信、性能稳定、推理速度等成为人工智能系统工程中的关键挑战。在应用软件侧，团队围绕多场景智能体构建、智能体可信演化，以及运行时质量保障等角度开展研究工作，旨在实现人工智能系统的性能提升与质量保障。在系统软件侧，团队围绕系统推理优化、全局编译优化，以及高性能算子开发开展研究工作，旨在实现人工智能系统在各种边端云异构设备上的快速部署与高效运行。

人机物融合系统软件

在人机物三元融合的万物智能互联时代，人机物融合系统软件可类比于传统计算机操作系统，是实现海量异构资源（信息服务、人力众包、物理设备）统一管理、支撑多领域智能化应用构建与运行的核心支柱。本小组围绕人机物融合系统软件的构造与应用开展了系列工作：以边缘云原生技术为基座，研制面向分级分层边缘环境的分布式系统软件，以软件定义的方式实现边缘侧计算、存储、网络、物理设备等异构资源的统一接入与池化；设计覆盖多边缘节点的集群管控与自治，以及跨节点资源互操作机制；构建人机物泛在环境的数字空间孪生，结合大模型、Agent等技术支持资源得按需编排与智能应用的快速构建；依托云边端协同的算力与设备能力调度，支撑应用高效、可靠执行。当前，本小组已经具有无人机、无人车、机器人、边缘计算盒等一系列专用硬件设备，已经研制出基于开源云原生边缘计算框架KubeEdge的云边协同人机物融合系统软件初始版本。在此基础上，小组计划进一步夯实系统软件能力，并在智慧城市设备联动、无人系统集群自治、船岸协同数据互联等真实场景中开展实践验证。

机器人软件工程

随着人工智能技术的快速发展，智能机器人正逐步融入日常生活，并在越来越多的实际场景中承担复杂的任务。面对现实环境中对高可靠性长程任务的要求，课题组聚焦于将大模型（LLM、VLA、VLM等）与程序合成技术相结合，研究机器人程序自主生成方法，研究机器人任务执行过程中自主监控及问题检测方法、机器人程序与运行平台相结合的软件自适应方法，研究面向动态环境中机器人程序自主演化方法。课题组的研究受到上海市重大专项的资助，研究成果发表在人工智能领域NeurIPS、IJCAI等顶级会议上，并获得中国软件大会“机器人大模型与具身智能”挑战赛一等奖。

智能汽车与工业软件

工业软件在现代工业制造中扮演着“大脑”与“神经系统”的关键角色，是实现制造系统数字化、网络化与智能化的核心基础。智能汽车则被视为全球制造业的战略制高点，其发展不仅推动技术创新，也加速产业升级。两者均高度依赖系统的安全性、可用性与可靠性，对计算机技术，尤其是软件与人工智能提出了更高的技术要求。本团队以智能汽车与工业软件为主要应用场景，结合软件工程与系统观思想，面向嵌入式系统运行环境的复杂性和需求多样性，系统化开展共性基础软件研究。研究内容包括：分布式实时系统的设计与实现、嵌入式系统的智能化开发方法以及复杂嵌入式系统的功能测试与性能分析。在智能汽车领域，团队聚焦智能驾驶与控制系统，通过实验与仿真验证基础研究成果的有效性；在工业软件领域，则围绕数字孪生系统的构建，重点探索工业生产系统中的设备控制、数据采集与分析等关键技术。该研究旨在构建可复用的软件基础设施和工程方法，为提升智能制造与智能汽车系统的性能、可靠性与柔性化水平提供理论支撑和实践指导。

CodeWisdom

一个有知识的软工公众号

发现智能化编程之道

跳转微信打开

活动预告｜CodeWisdom 可信AI系统系列学术报告第13期

Tue, 21 Jul 2026 10:22:00 +0800

CodeWisdom 2026-07-21 10:22 上海

报告时间：2026年7月22日（周三）上午10:30

Zhixiang Zhang

HKUST

内容简介

题目

From Similarity to Vulnerability: Key Collision Attack on LLM Semantic Caching

摘要

Semantic caching has emerged as a pivotal technique for scaling LLM applications, widely adopted by major providers including AWS and Microsoft. By utilizing semantic embedding vectors as cache keys, this mechanism effectively minimizes latency and redundant computation for semantically similar queries. In this work, we conceptualize semantic cache keys as a form of fuzzy hashes. We demonstrate that the locality required to maximize cache hit rates fundamentally conflicts with the cryptographic avalanche effect necessary for collision resistance. Our conceptual analysis formalizes this inherent trade-off between performance (locality) and security (collision resilience), revealing that semantic caching is naturally vulnerable to key collision attacks.

While prior research has focused on side-channel and privacy risks, we present the first systematic study of integrity risks arising from cache collisions. We introduce CacheAttack, an automated framework for launching black-box collision attacks. We evaluate CacheAttack in security-critical tasks and agentic workflows. It achieves a hit rate of 86\% in LLM response hijacking and can induce malicious behaviors in LLM agent, while preserving strong transferability across different embedding models. A case study on a financial agent further illustrates the real-world impact of these vulnerabilities. Finally, we discuss mitigation strategies.

报告人

Zhixiang Zhang(张芝翔) recently received his B.Eng. in Software Engineering from Fudan University. In Fall 2026, he will join the Hong Kong University of Science and Technology (HKUST) as a PhD student, advised by Prof. Dongdong She. His research primarily focuses on AI security, specifically the robustness and privacy of Large Language Models (LLMs) and Trustworthy AI. His recent work on LLM semantic caching and agent security has been accepted at top-tier conferences including ICML, ASE, and ISSTA. Beyond his research, he actively engages with the academic community by serving as a reviewer and sub-reviewer for conferences like ACL, ICML, ISSTA, ASE, CCS and so on.

时间安排

时间：2026年7月22日10:30

地点：复旦大学江湾校区交叉二号楼A2003

腾讯会议：474-813-999 密码：169539

跳转微信打开

复旦大学CodeWisdom团队机器人软件工程研究组召唤“驯机高手”

Sun, 19 Jul 2026 08:00:00 +0800

洪达良 2026-07-19 08:00 上海

欢迎对智能机器人与软件工程交叉方向感兴趣的同学联系交流！

我们的科研日常是什么？

教移动机器人别迷路，教机械臂别抓空，再想办法让人形机器人更聪明。机器人偶尔也会“不太听话”，但每一次调试，都是让想法走进现实的过程。

不同于主要聚焦运动控制或视觉感知的传统机器人研究，我们更关注机器人软件架构、系统集成与神经符号融合，让感知、决策和控制高效协同，构建可靠、可扩展、可落地的具身智能系统。

欢迎加入我们，一起探索具身智能与机器人软件工程，成为机器人最靠谱的“人类队友”！

欢迎对智能机器人与软件工程交叉方向感兴趣的同学联系交流！

邮箱：zhendong@fudan.edu.cn

编辑人：洪达良

跳转微信打开

TensorLock：恢复大模型供应链中缺失的模型依赖关系

Thu, 09 Jul 2026 08:00:00 +0800

CodeWisdom 2026-07-09 08:00 上海

TensorLock通过公开模型权重恢复缺失的模型依赖关系，支撑大模型供应链的风险溯源与缓解。

研究背景：模型依赖缺失是大模型供应链风险治理的关键瓶颈

近年来，随着 Hugging Face 等开放模型托管平台快速发展，开发者越来越多地直接复用已有模型，而不是从零开始训练模型。一个模型可能在上游模型的基础上经过微调、量化、合并等操作后再次发布，并继续被其他开发者复用。由此，大模型不再是孤立发布的单个产物，而是逐渐形成了复杂且庞大的大模型供应链。这种复用模式在降低开发成本的同时，也带来了新的治理难题。下游模型不仅会继承上游模型的能力，也可能继承其性能缺陷、许可证限制，甚至幻觉、越狱、提示注入等安全风险。为了评估这些风险是否会传播、传播到哪些模型、风险责任归属，必须要先知道模型之间存在怎样的依赖关系。然而，当前开放模型社区中的依赖声明高度不完整：许多模型虽然基于已有模型构建，却没有在模型卡中明确标注其来源 [1]。这种模型依赖信息缺失，使得模型来源难以追踪、风险影响范围难以及时评估，许可证合规和安全责任也难以界定。

为系统刻画当前开放模型社区中模型依赖缺失的严重程度，我们选取了Hugging Face 下载量最高的 10,000 个模型作为研究对象，并从中抽取 369 个模型进行人工依赖标注。369 个抽样模型中有 81.8% 至少与一个开源模型存在依赖关系；然而，在人工识别出的依赖关系中：

53.6%并未在模型卡中显式声明，表明当前模型依赖信息存在大规模缺失的情况；
38.1%的模型同时作为下游衍生模型和上游根模型存在，表明当前模型供应链并不是简单的一跳关系，而是复杂的传递式依赖网络；
96.4% 的依赖关系发生在 Transformer 模型之间，表明 Transformer 架构构成了当前模型供应链的主要骨架；

97.7% 的依赖关系集中在 Fine-Tuning（包括全量微调和参数高效微调）、Quantization 和 Merging 三类操作上，进一步表明模型复用形式虽多样，但主要依赖类型高度集中。

这些发现表明，要有效治理当前大模型供应链中的依赖缺失问题，关键在于面向 Transformer 模型，自动恢复 Fine-Tuning、Quantization 和 Merging 这三类核心依赖关系。

围绕模型依赖关系恢复，已有研究可分为模型水印和模型指纹两类。模型水印方法通常需要在模型训练阶段嵌入特定模式，后续由模型拥有者凭借密钥验证模型来源[1]。这类方法适合用于版权保护，但依赖预先嵌入和私有密钥，难以支持第三方对整个开源模型社区开展大规模依赖分析。模型指纹方法则通过分析模型参数统计特征、梯度、激活或输出行为，判断两个模型之间是否存在依赖关系[3-12]。相比模型水印方法，模型指纹方法不需要预先嵌入标记，更适合对已经发布的开源模型进行溯源。然而，面对真实开放模型社区，现有方法仍面临两个关键挑战。

第一，真实模型供应链具有开放式、传递式的复杂拓扑结构。现有基于聚类的方法往往需要预先知道根模型的数量，默认所有衍生模型都直接来自某个根模型[9,11,13]。但在实际场景中，模型可能经历多跳修改。例如，一个模型先被微调，再被量化，随后又被继续微调或与其他模型合并。随着修改链条不断延长，远端下游模型与原始根模型之间的相似度会逐渐降低，简单依赖单跳相似度阈值的方法很容易将同一模型家族错误拆分为多个独立簇。此外，真实供应链中还广泛存在兄弟式分支结构，即多个模型可能由同一上游模型独立派生而来，它们彼此之间并不存在直接修改关系，但共享共同祖先。仅依赖根模型数量或单跳相似度的聚类方法，难以同时恢复这种同源分支关系和多跳传递关系。

第二，真实模型供应链中的依赖类型是混合的。微调和量化通常是一对一依赖，而模型合并可能同时引入多个父模型，使依赖结构从树形关系扩展为有向无环图。已有树形依赖恢复方法MoTHer [14]通常假设每个模型只有一个父节点，因此难以识别模型依赖图中模型合并带来的多对一依赖关系。

研究进展：基于权重空间指纹的模型依赖恢复框架 TensorLock

针对上述问题，我们提出了一种依赖类型感知的、基于权重空间指纹的模型依赖恢复框架TensorLock。TensorLock 的输入是一组候选Transformer模型，仅依赖公开的模型权重文件（如 safetensors、bin、pt、gguf 等），输出一个包含依赖方向与依赖类型的模型依赖图。相关研究论文录用于ISSTA 2026 [15]。

图一 TensorLock 框架图

如图一所示，TensorLock 主要包含两个阶段：第一阶段进行模型聚类，用于在未知根模型数量的开放场景下识别潜在的模型家族，并缓解传递式模型复用导致的远端同源模型相似度衰减问题；第二阶段在每个模型簇内部进行类型感知的依赖恢复，针对 Fine-Tuning、Quantization 和 Merging 三类核心依赖类型分别设计识别策略，从而同时恢复模型依赖方向和依赖类型。

（一）基于连通性的模型聚类

TensorLock 首先通过基于连通性的模型聚类识别潜在的模型家族。不同于需要用户预先指定模型家族数量的方法，TensorLock 的核心思想是：即使远端衍生模型与根模型之间的直接相似度已经下降，只要它们能够通过若干中间模型形成连续的高置信连接，就仍应被归入同一模型家族。为此，TensorLock 重点利用 Transformer 中 Multi-Head Self-Attention（MSA）层的权重统计特征作为模型家族指纹，而不是直接使用全部权重。这是因为 FFN 层通常承载更多任务相关知识，在微调过程中变化更大；相比之下，MSA 层更稳定，更适合刻画模型谱系关系。具体而言，TensorLock 从 Q、K、V、O 四类注意力矩阵中提取标准差、偏度和峰度等统计特征，计算模型之间的 Spearman 相关性，并据此构建模型连通图，最终利用 HDBSCAN 算法自动识别稳定的模型簇。该模块使 TensorLock 能够适应开放模型社区中根模型数量未知、依赖链条较长的真实场景。

（二）数据无关依赖的恢复：优先恢复量化与合并关系

在获得模型簇之后，TensorLock 进一步在簇内恢复具体依赖关系。它首先区分两类依赖：数据无关的依赖和数据驱动的依赖。量化和合并主要对已有权重进行确定性或近似确定性的变换，不依赖新的训练数据，因此属于数据无关的依赖；微调则依赖训练数据和训练过程，其权重变化更难被直接验证，因此属于数据驱动的依赖。基于这一差异，TensorLock 优先恢复量化和合并关系，再处理微调关系。

对于量化依赖，TensorLock 利用量化操作会将连续权重分布压缩到离散取值网格这一特征，设计 Quantization Provenance Score（QPS）。该得分基于归一化互信息衡量候选量化模型与候选父模型在权重分布上的统计对齐程度，从而能够在 GGUF、AWQ、GPTQ 等不同量化格式下识别量化模型的来源。

对于合并依赖，TensorLock 针对两类常见模型合并方式分别建模：线性插值和稀疏任务向量聚合。对于线性插值，TensorLock 判断候选模型是否位于两个父模型权重之间的插值路径上；对于稀疏任务向量聚合，TensorLock 通过 LASSO 回归验证候选模型的残差是否可以由多个父模型的任务向量稀疏重构。借助这一设计，TensorLock 不仅能够判断一个模型是否由合并得到，还能够恢复其多个父节点。

（三）数据驱动依赖的恢复：恢复微调方向与父子结构

在量化和合并等数据无关的依赖被确认后，TensorLock继续恢复微调依赖。对于微调关系，TensorLock 一方面使用 MSA 与 FFN 层级权重的 L2 距离衡量模型之间的接近程度，另一方面引入奇异值熵判断依赖方向。其基本依据是：模型从通用模型向特定任务模型微调时，权重表示会发生结构性变化，并在谱熵上呈现可观测差异。

最后，TensorLock 将已确认的量化和合并依赖作为约束注入图结构中，并通过最小有向生成树恢复剩余微调边。针对合并带来的多父节点结构，TensorLock 进一步设计了 “detach-resolve-reattach” 策略：先临时分离多父节点子图，再恢复其上游谱系，最后重新连接已验证的多父依赖。由此，TensorLock 能够同时支持树形微调链条和 DAG 式合并结构，恢复更加贴近真实模型供应链的依赖图。

实验评估：TensorLock 的有效性与实用性

（一）有效性评估

为了系统评估 TensorLock，我们构建了模型依赖恢复基准MDGBench。如表一所示，与已有的基准相比，MDGBench 同时具备真实世界模型、多领域、多依赖类型、簇级评估和图级评估等特点。MDGBench 包含了 137 个真实模型、17 个模型簇和 131 条依赖边，覆盖 NLP、CV、Audio 和 Multimodal 等领域，包含 32 条量化边、22 条合并边和 77 条微调边。

表一 MDGBench与已有基准的比较

- 在模型聚类任务上，如表二所示，TensorLock 取得了 0.96 的 ARI，显著优于目前SOTA的基线方法 HuRef 的 0.69，提升至少 39%；其中 ARI 用于衡量聚类结果与真实标签的一致程度，数值越接近1表示聚类越准确，这说明连通性聚类能够更好地处理真实模型供应链中的链式、兄弟式和多跳依赖结构。进一步地，图二的 pair-wise 混淆矩阵从模型对层面展示了这一优势：TensorLock 几乎没有将无关模型错误聚为一类，并显著减少了同类模型被拆散的情况，说明其聚类结果在类内一致性和类间区分性上都更稳定。

- 在模型依赖恢复任务上，如表三所示，我们同时评估了两种设置：一是端到端设置，即工具需要从未知模型簇结构开始，完整完成模型聚类与依赖恢复；二是给定真实模型簇的设置，即仅评估依赖恢复模块本身的性能。其中，TensorLock+、MoTHer+和ChronChai+表示在已知真实模型簇划分的条件下进行依赖恢复，用于排除聚类误差影响，衡量依赖恢复模块的上限表现；不带 “+” 的 TensorLock、MoTHer 和 ChronChain 则表示端到端场景下的完整恢复能力。结果表明，TensorLock+ 取得了 0.83 的依赖边恢复精确率、0.81 的召回率和 0.82 的 F1 分数，相比 MoTHer+ 的 F1 分数 0.28 提升 193%；这一优势也在图三的可视化对比中得到进一步体现。即使在未知簇结构的端到端设置下，TensorLock 仍能达到 0.81 的精确率和 0.75 的召回率，说明其在真实开放场景中具有较强的实际可用性。

表二 TensorLock 在模型聚类任务上的有效性结果

表三 TensorLock在依赖恢复任务上的有效性结果

此外，我们还引入了可达性召回率（RchRec）和可达性精确率（RchPre）来评估供应链风险传播分析的可靠性。基于时间排序的基线方法ChronChain 虽然 RchRec 很高，但其 RchPre 仅为 0.02，意味着其恢复出的可达依赖中约 98% 实际上并不可达。这说明，仅按模型发布时间串成链，会制造大量虚假的风险传播路径；相比之下，TensorLock 的可达路径由真实权重证据支撑，因此更适合用于实际风险分析。

图二 TensorLock 与基线方法的成对聚类混淆矩阵对比

图三 TensorLock 与 MoTHer 在依赖图恢复上的可视化对比

（二）实用性评估

我们将TensorLock应用于真实 Hugging Face 生态中的“孤立模型”。这些模型在模型卡中缺少依赖声明，表面上似乎不存在上下游关系，但实际上可能仍由某个模型家族衍生而来。为了验证TensorLock在真实开放场景中的实用性，我们随机选取了289个未显式声明依赖关系的孤立模型，并将其与 MDGBench 中已有模型簇进行依赖恢复。TensorLock 在这 289 个模型中恢复出 189 个隐藏依赖，占比达到 65.4%。在恢复出的依赖关系中，有 38 对父模型和子模型均位于 Hugging Face 下载量排名前 1000。该结果表明，TensorLock 恢复出的隐藏依赖不仅具有统计意义，也能够为高影响力模型供应链的透明化治理提供直接支持。我们进一步联系了高影响力的模型开发者，并通过提交Pull Request协助更新模型卡中的依赖信息。截至论文完成时，已有 42 位开发者确认了 TensorLock 的恢复结果，表四展示了其中的部分案例。

表四 TensorLock部分真实恢复依赖案例

总结

TensorLock 的核心贡献在于，将模型依赖恢复从简单的相似度判断推进到类型感知的模型依赖图恢复。通过基于连通性的聚类，TensorLock 能够识别开放式、多跳式模型家族；通过针对量化、合并和微调关系设计专门的权重空间指纹，它能够进一步恢复不同模型变换背后的父子关系与依赖类型；通过真实世界基准测试和开放生态应用，TensorLock 进而验证了其在大模型供应链治理中的实际价值。

作者

吴苏晟，复旦大学CodeWisdom团队软件供应链安全小组博士生，导师为陈碧欢，主要研究方向为软件供应链安全、大模型供应链安全，部分成果在企业内部落地。

陈子谦，复旦大学CodeWisdom团队软件供应链安全小组硕士生，导师为陈碧欢，研究方向为大模型供应链安全。

大模型供应链治理往期回顾：

[MCP：从诞生到行业标准，从繁荣到安全危机]

[模型供应链风险初探：依赖、演化、质量与风险传播的首次全景扫描]

参考文献

[1] Ziqian Chen, el al. “A First Look at Model Supply Chain: From the Risk Perspective”, Proceedings of the IEEE/ACM International Conference on Software Engineering 2026.

[2] Krauß Torsten, et al. “ClearStamp: A Human-Visible and Robust Model-Ownership Proof Based on Transposed Model Training.” Proceedings of USENIX Security 2024.

[3] Alhazbi Saeif, et al. “LLMs Have Rhythm: Fingerprinting Large Language Models Using Inter-Token Times and Network Traffic Analysis.” IEEE OJ-COMS 2025.

[4] Chen Jialuo, et al. “Copy, Right? A Testing Framework for Copyright Protection of Deep Learning Models.” Proceedings of IEEE S&P 2022.

[5] Song Hae Jin, and Laurent Itti. “Riemannian-Geometric Fingerprints of Generative Models.” arXiv preprint, 2025.

[6] Wu Zehao, Yanjie Zhao, and Haoyu Wang. “Gradient-Based Model Fingerprinting for LLM Similarity Detection and Family Classification.” arXiv preprint, 2025.

[7] Yoon Do-hyeon, et al. “Intrinsic Fingerprint of LLMs: Continue Training Is NOT All You Need to Steal A Model!” arXiv preprint, 2025.

[8] Yu Runpeng, and Xinchao Wang. “Neural Lineage.” Proceedings of CVPR 2024.

[9] Zeng Boyi, et al. “HuRef: Human-Readable Fingerprint for Large Language Models.” Proceedings of NeurIPS 2024.

[10] Zhang Jie, et al. “EasyDetector: Using Linear Probe to Detect the Provenance of Large Language Models.” Proceedings of TrustCom 2024.

[11] Zhang Jie, et al. “Reef: Representation Encoding Fingerprints for Large Language Models.” arXiv preprint, 2024.

[12] Zhang Ruichong. “Matrix-Driven Instant Review: Confident Detection and Reconstruction of LLM Plagiarism on PC.” arXiv preprint, 2025.

[13] Zehao Wu,et al. “Gradient-Based Model Fingerprinting for LLM Similarity Detection and Family Classification.” arXiv preprint, 2025.

[14] Eliahu Horwitz, et al. “Unsupervised model tree heritage recovery.” Proceedings of ICLR 2025.

[15] Wu Susheng, et al. “TensorLock: Recovering Model Dependency for Model Supply Chain.” Proceedings of ISSTA 2026.

跳转微信打开

彭鑫老师受邀参加APSEC 2026并作大会报告

Sun, 21 Jun 2026 13:55:00 +0800

CodeWisdom 2026-06-21 13:55 上海

第33届亚太软件工程会议（APSEC 2026）将于2026年12月7-10日在印度尼西亚巴厘岛举行

第33届亚太软件工程会议（33rd Asia-Pacific Software Engineering Conference，简称APSEC 2026）将于2026年12月7-10日在印度尼西亚巴厘岛举行。彭鑫老师受邀参加本次会议并作大会报告《Intelligent Software Development Through the Lens of Complex Systems: Opportunities and Challenges》。本次报告将从系统复杂性的角度对于当前基于大模型和智能体的软件智能化开发所面临的机遇与挑战进行分析，并介绍复旦大学CodeWisdom团队当前的一些探索方向和初步成果。

亚太软件工程会议（APSEC）作为亚太地区软件工程领域的旗舰会议，长期以来汇聚了学术界、工业界及政府机构的广大研究人员与实践者，共同交流软件工程知识与最佳实践，探讨软件工程创新中涌现的新挑战与应对方案。与历届会议一样，APSEC 2026的主研究轨道将集中展示软件工程及其所有子领域中最前沿、最重要的创新成果。同时，大会诚邀高质量研究论文投稿。

欢迎大家注册参会！APSEC 2026网站（点击阅读原文即可跳转）： https://conf.researchr.org/home/apsec-2026

阅读原文

跳转微信打开

玩具题满分，真实项目瘫痪？AI辅助开发能力“真”评测

Mon, 15 Jun 2026 12:48:00 +0800

茹炳晟+AI 2026-06-15 12:48 上海

以下文章来源于：茹炳晟聊软件研发

茹炳晟聊软件研发

关注软件研发行业效能提升与质量提升的工程实践，普及研发效能宣言的价值观、最佳实践与工程落地案例

高分评测不等于高能产出。我们可能一直在用错误的方式衡量AI编程的真实水平。关于AI辅助开发的9个深层缺陷和8个深度洞察。

高分评测不等于高能产出。我们可能一直在用错误的方式衡量AI编程的真实水平。

我见过一个团队，欢天喜地地引入了一款在某个权威榜单上排名第一的AI编程助手。试用期写的几个小函数确实漂亮。可当他们把工具扔进那个有着八年历史、400多个微服务、依赖关系像蜘蛛网一样的产品时，效果迅速变质，AI建议的重构破坏了隐秘的边界约定，它推荐的库版本与内部镜像源冲突，它“自信满满”生成的异常处理逻辑甚至掩盖了真正的问题根源。

最后，技术负责人苦笑着对我说：“玩具题满分，真实项目瘫痪。”

这绝非某个模型的个体缺陷。这是整个评测范式的系统性问题。

为什么高分评价在现实里不堪一击

当前主流的AI辅助开发评测，存在九个深层缺陷。每一个缺陷，都足以让实验室的漂亮数据在实际场景中严重失真。

1. 问题定义过于“整洁”

真实的需求从来不是一道边界清晰的编程题。用户说“做个类似淘宝的购物车”，背后藏着无数未曾言明的约束：库存扣减是在下单时还是支付时？优惠叠加的优先级规则是什么？未登录状态添加的商品，登录后如何合并？真实项目里，需求是一团沾着口水的毛线球。评测题把这些模糊性全切掉了，AI只需要在一个干净的问题空间里完成一次“翻译”。这就像考核一个飞行员在完美天气下的起降能力，却从不测试雷暴、侧风、单发失效。

2. 构建与环境的“理想化”

现实项目的环境像一锅煮了十年的老汤：老旧的内部依赖版本、编译工具链的前后冲突、测试框架与生产环境的环境变量不一致、某个底层库因为安全策略被禁止使用……我经历过一次真实故障：AI生成的Dockerfile里用了apt-get update，但公司内部的镜像源需要先认证,这个细节没有任何公开评测会涉及。评测里什么都配好了，依赖一键安装，端口不会冲突，文件权限不会报错。AI没经历过这些“脏活累活”，自然就不具备处理它们的能力。

3. 对“正确”的狭义定义

一段代码能跑通测试，远远不等于“好代码”。它可能正确但不可维护。全局变量满天飞，函数长度超过1000行；它可能正确但性能糟糕，用O(n²)遍历十万级数据，上线三分钟就把CPU打满；它可能正确但让团队其他成员完全读不懂，变量名叫a、b、c，没有任何注释。评测只看能否通过测试，把软件工程的复杂性简化成了一个对答案的游戏。

4. 未能覆盖软件开发全流程中的各类真实任务

写新代码只是冰山浮出水面的那一角。真实的开发者把大量时间花在：理解一段十年前的遗留代码、定位一个只在凌晨三点出现的竞态条件Bug、做技术方案评审时指出架构风险、写运维手册里的故障排查文档、从几十GB的日志里分析错误模式。这些任务几乎都不在当前的评测范围内。而恰恰是这些领域，AI的表现最容易让人失望，因为它从未被系统性地考核与评测过。

5. 缺乏体系化的任务难度分类

“生成一个二分查找”和“理解一个有着10年历史、状态图横跨三个系统的支付模块”，被混在一起打分，然后取个平均。这没有任何意义。难度的维度没有被拆解：是依赖的理解深度深？是信息不完备程度高？是需要多步规划的能力强？是跨文件的上下文窗口大？没有分类，平均分就是一个数字幻觉。我曾建议一个团队建立自己的难度金字塔，从“单函数生成”到“跨模块重构”到“缺陷定位与修复”再到“模糊需求澄清”，每一层的分数单独评测单独分析。

6. 忽略“非功能”

安全性、可观测性、可扩展性、可测试性、合规性、国际化……这些非功能需求在真正的代码评审时才是最大的拦路虎。评测不看这些，AI自然也学不会主动考虑。举个例子：某个AI生成的REST API端点，功能没问题，但它没有做输入校验，没有限流，没有记录请求ID，没有处理幂等性，这些在评审中会被一一打回。一个只考核功能正确性的评测，会给这段代码打满分，可它在真实企业中，这样的代码压根不会被接受。

7. “答案泄漏”已演变为“知识快照”效应

过去我们担心评测集被直接放进训练数据里，现在更隐蔽的问题是大模型“记忆”了它在训练时见过大量开源实现。遇到相似的问题，它不是在进行推理，而是在回放它见过的那个解法。这种“知识快照”在静态评测里表现很好，因为评测集里也有那个老项目的影子。可一旦遇到超出其记忆范围的真实场景（比如你们公司自研的框架），它就露馅了。有人做过实验：把一个公开问题的变量名和API名称全部改写，保持逻辑不变，某些模型的分数直接下降了30%以上。

8. 过时的代码实现

评测集里的参考实现可能已经过时。AI依葫芦画瓢生成的代码，在今天的环境下根本跑不起来。比如，某个流行评测里还要求使用Python的distutils，而这个模块已经在Python 3.12中被移除。模型“记住”了那个旧写法，给出所谓的“正确答案”，但你敢把它用到新项目里吗？

9. Token经济的盲点

评测只看结果对不对，不计过程成本。但在真实开发中，一个需要反复对话20轮、消耗大量Token、开发者来回确认十余次才修好的Bug，和另一个一次对话就解决的场景，两者的“经济价值”天差地别。当前的分数抹平了这种差异。更糟糕的是，有些AI会生成冗长的、包含大量无用注释和过度设计的代码，虽然“正确”，但浪费了你的阅读时间和后续维护精力。Token经济应该被纳入评测视野。

评测本质是衡量一个有限理性体在开放目标下的决策质量，这也是最根本的悖论。AI是一个“有限理性体”，它没有真正的理解，只有基于统计的模式匹配。而真实软件开发是一个“开放目标”系统，需求会变，约束会变，什么是“正确”的边界本身就会随着时间而漂移。在这两者之间，我们却试图用一个封闭的、确定性的评测集去衡量它的“决策质量”，这本质上是一种错配。好比用闭卷考试去衡量一个野外求生专家的生存能力，场景完全不对。

AI辅助开发能力评测的8大深度洞察

洞察1：比“生成代码”更重要的是“理解代码”

有一个现象值得深思：一名开发者如果能够写出复杂的系统代码，那么他一定已经扎实地掌握了编程的基础，比如变量作用域、控制流、数据结构、内存模型。这是由人的学习规律决定的：地基不牢，高楼不起。

但大模型恰好相反。

模型可以“依葫芦画瓢”地生成一段看上去很漂亮的复杂代码，因为它从海量训练数据中见过类似的模式。可当你问它一个极其基础的问题，比如“这段循环里，第三次迭代结束后，变量x的值是多少？”它却可能答错。

模型往往懂复杂的，不懂基本的。它的“能力”不是从因果理解中生长出来的，而是从模式匹配中拼接出来的。

如果不能“理解代码”，那么其他一切能力：生成、重构、审查、调试等等都建立在沙丘之上。没有理解，这一切都是空中楼阁。

我们应该用更精细的实验来拆穿“生成能力等于理解能力”的幻觉。一个典型的评测思路是：给出一段代码和一个具体的输入，但不允许运行代码，要求模型推理出每一步执行前后各个变量的值、系统状态的变化。这样的任务不需要模型“创造”新代码，只需要它忠实追踪执行流。而这恰恰是理解代码的本质。

著名的CRUXEval基准就发现了令人不安的事实：许多在代码生成榜上分数亮眼的模型，在执行流跟踪、数据依赖理解方面表现糟糕。它们能够写出正确的最终输出（因为训练数据里见过类似问题的输出模式），但回答不出中间状态的变化。

这意味着什么？意味着模型更像一个代码复读机——它记住了“对于这种问题，答案通常长这样”，而不是一个因果推理机——它理解“因为变量a在第二步被改变了，所以第三步的结果才会是b”。前者在静态评测里可以蒙混过关，后者才是在真实项目中值得信赖的伙伴。

因此，未来的评测必须做一次根本性的分离：将“生成能力”与“理解能力”作为两个独立的维度分别评估。一个模型可以在代码生成上拿高分，但在理解评测上暴露短板。只有两者都强的模型，才配得上“可靠”二字。

对于企业选型来说，这个洞察的价值尤其直接：不要只看模型能不能写出一个排序算法；请给它一段你代码库里的真实函数，关掉运行环境，问它“第三次调用update_cache之后，dirty_flag的值是true还是false？”——答案会告诉你，它到底是真的理解了你的代码，还是在优雅地鹦鹉学舌。

洞察2：什么样的评测是充分的

当我们说一个评测“充分”时，不是在追求用例数量的堆砌，而是在追求一件事：对“各类可能性的覆盖”。

传统的大模型评测，本质上是“一锅炖”，扔一组输入进去，看一组输出出来，这种面向结果的评测其实是远远不够的。

AI辅助开发的评测，尤其是面对具备多步规划、工具调用能力的Agent时，必须换一种思路：评测不再是一次性的输入输出比对，而是对Agent在模拟世界中可能经历的“决策轨迹”进行覆盖。

什么意思？举个例子。一个真实的重构任务，Agent可能走这些路径：

路径A：先理解当前代码结构 → 定位到重复逻辑 → 提取公共函数 → 替换所有调用点 → 跑测试
路径B：先搜索是否有现成工具库 → 引入依赖 → 改写接口 → 报错 → 回滚 → 换方案
路径C：请求用户澄清意图 → 用户给出了额外约束 → 调整方案 → 分步提交

一个充分的评测，应该覆盖这三条轨迹中的关键决策点，而不是只看“最终重构是否成功”。因为两个Agent可能都成功了，但一个走的是直线，另一个跌跌撞撞绕了远路。后者的“过程脆弱性”在高压力下会暴露无遗。

所以我们必须追求从“结果评测”到“过程评测”的理念转变，把一个大任务切成多个阶段，分别评估每个阶段的决策质量：需求澄清是否到位？信息检索是否精准？代码修改是否最小化影响范围？错误恢复是否合理？这些过程指标加起来，比一个最终对错分数要有用得多。

洞察3：评测常常忽略了AI Coding带来的隐形负债

传统评测只问一个问题：“能不能做出来？”只要能通过测试用例，就算成功。但这种方式忽略了一个更隐蔽、更致命的问题：AI Coding是否在过程中制造了巨大的技术债务，进而带啦更大的认知债务。

两个Agent都能完成同一个开发需求，测试通过率都是100%。但一个用3000行难以维护的平铺代码，重复逻辑遍地、函数长达数百行、命名随意，最终勉强凑出了正确结果；另一个用500行清晰的抽象，模块分明、边界清晰。现有评测给两者打同样的分。

反过来还有一种情况：Agent写的代码行数不算多，功能也正确，但完全是面向过程的一口气写到底，没有合理的函数拆分，没有数据结构的封装。代码少，不等于好。它只是把复杂性藏进了更隐蔽的地方。

问题的本质在于：Agent的成功，可能只是把负担转移给了未来的人类。当维护者接手这段代码，他需要花多少时间去理解、修改、调试？这个代价被传统评测完全无视了。

真正的度量指标应该是：“维护者面对Agent产出的困惑度”。一个可操作的方式是：通过预测后续修改该代码所需的时间来量化。给出一段AI生成的代码，然后设定一个合理的修改任务（例如“添加一个新的排序规则”或“修复一个边界条件的Bug”），测量一个经验丰富的开发者（或另一个基准系统）完成这个修改需要多长时间。困惑度越高，修改时间越长。

基于这个思路，评测实验可以这样设计：完成初始需求之后，不停止，而是连续给出多个后续的修改任务（比如3到5个，由易到难）。累计完成所有这些任务的总时间，才是衡量AI真实价值的关键指标。一个Agent如果初始生成的代码结构混乱，第一个任务可能勉强通过，但后续每个小改动都会触发连锁反应，时间成本指数级上升。而另一个Agent产出的代码虽然初始完成稍慢，但后续修改顺滑流畅，后者才是真正降低了全生命周期的成本。

在这个设计下，传统评测里“平铺3000行”和“抽象200行”的差距会赤裸裸地暴露出来。前者可能在第一个后续任务上就花费数倍的时间。而那个“行数少但面向过程”的方案，在面对第二个需要扩展功能的修改时，因为没有合理的模块边界，同样会陷入困境。

洞察4：评测结果的脆弱性

一个模型在某个基准上拿到高分，这件事本身可能极为脆弱。脆弱到什么程度？仅仅改变变量名，或者调整一下依赖库的版本号，成功率就可能断崖式下跌。

更常见的情形是：对问题的描述做一点微小的改动，比如把“返回所有偶数”改成“返回所有能被2整除的数”；在需求中添加一句无关的上下文信息“天气不错”；或者把约束条件的顺序调换一下，模型的表现就从“惊艳”变成了“翻车”。这个模型并没有真正理解问题，它只是记住了训练数据中某种特定的表述模式。

这种脆弱性意味着：评测结果只是一个“点”上的分数，而这个点在真实世界中几乎永远不会以完全相同的形式出现。你无法依赖它。

因此，评测必须引入一个新的维度：扰动测试。不是测一个单点，而是测量“在各类扰动影响下，模型性能衰减曲线的形状”。衰减曲线越平缓，模型越健壮；衰减曲线越陡峭，那个高分就越像泡沫。

一个可行的实验设计是：在代码表层进行不影响语义和抽象语法树（AST）的变异，比如批量重命名变量（`a→x`、`counter→cnt`）、调整空格和换行、等价替换常量表达（`2+2`→`4`）、交换无关语句的顺序。将这些变异后的版本输入模型，观察评测结果的变化。

如果性能基本保持不变，说明模型对表层变异性不敏感，这是一个好信号。如果性能出现超出统计容差的明显下跌，则判定为脆弱性缺陷，表示模型只是在“背文本”，而不是在“解问题”。

继续加大变异范围：改一改依赖版本号（`requests==2.28.1`→`2.31.0`）、调整题干的句法结构而不改语义。每增加一层扰动，记录一次性能衰减。最终绘出一条“扰动-性能”曲线，这条曲线比那个孤立的分数有价值得多。

这种扰动测试，为那些无法定义“绝对正确”的情形提供了相对正确的预言：我们不知道什么是完美的健壮性，但我们可以知道，一个模型在轻微扰动下就崩溃，它一定不值得信任。

洞察5：当评测结果成为目标函数，评测数据污染就是必然的

这是“古德哈特定律”在AI编程评测领域的精准应验：当一个指标成为目标，它就不再是一个好指标。

一旦某个基准（比如SWE-bench）被公认为“参考标准”，Agent开发者就会直接针对它优化训练策略。这不是道德问题，是激励结构的问题。结果就是：基准饱和的速度，远远超过了模型真实编程能力的增长。一个模型今天在榜单上又提高了两个百分点，但它很可能只是“记住”了更多与基准中题目相似的解法，而不是真正学会了泛化的编程推理。

这种“虚假进步”极其隐蔽。模型没有变聪明，只是题库被悄悄消化了。

因此，评价编程能力的视角必须彻底转换：从 “见过多少题” 转向 “如何解决从未见过的问题”。不是测试记忆的广度，而是测试推理的深度。

前沿趋势已经清晰地指向这个方向：构建动态的、不可提前记忆的基准。例如：

LiveCodeBench：定期从最新发布的编程竞赛、新开源的代码库中自动抓取题目，确保模型训练数据中不可能包含这些内容。
合成变异技术：以种子题目为基础，通过语义保持的变异无限生成互异的变体，让每个评测对象面对的都是一套“独一份”的试卷。

一个更深层的思考是：唯一能长期有效的评测，是那些评测用例生成成本远低于模型适应成本的动态基准。模型开发者如果要“刷”这个基准，需要付出的代价（比如持续地收集和消化海量新题目）远远超过评测维护者生成新用例的成本。这种成本不对称，才是防污染的底层逻辑。

基于这个洞察，评测实验设计需要引入四重机制：

1. 评测数据集的动态保鲜机制：定期自动更新题目池，剔除可能已被“熟记”的老题，注入新来源（如最近一周的GitHub commit记录、最新的Codeforces竞赛题）。

2. 不完整上下文的探针机制：主动向模型提供残缺或矛盾的需求描述，如果模型表现出“过拟合式”的自信（即没有追问就给出了与上下文不符的标准答案），则命中并触发该题目的变异或淘汰。

3. 禁用搜索的效果对比：在评测执行过程中，分别测量模型开启与关闭外部检索（如互联网搜索、本地代码库索引）时的性能差异。差距过小可能意味着模型依赖内部实时推理；差距过大则需要进一步分析是真正利用信息还是机械照抄。

4. 饱和度趋势检查：持续监控模型在某一基准上的整体得分随时间的变化曲线。当单题饱和率达到90%以上，自动触发新评测用例的收集、筛选或变异生成机制。

通过这些设计，评测不再是静态的“靶子”，而是一个主动进化的“免疫系统”。模型可以暂时领先，但无法“霸榜”，因为榜单本身会不停地换血。

洞察6：需要避免聚焦“依葫芦画瓢”的误区，需要关注对跨语言的泛化能力

当前评测有一个隐蔽的倾向：评测模型在主流语言（Python、JavaScript、Java）上的代码生成能力。模型从海量语料中学会了这些语言的惯用模式，本质上是在“依葫芦画瓢”，看到一个相似的问题，套用见过的模板。

真正的编程智能，不应该依赖这种统计上的记忆。如果模型真具备“编程智能”，它应当能够依赖语言参考文档（而非海量代码语料）来解题。这是对死记硬背的终极检验。

因此，一个真正有洞察力的评测应该是这样的：给定一门模型从未充分接触过的领域特定语言及其规范，看它能否快速适应并写出正确代码。

更极端地，可以构造一门全新的“玩具语言”——精心设计，图灵完备，但语法和语义完全不同于任何现有的主流语言。然后给出该语言的完整规范文档，要求模型在阅读文档后，解决用该语言描述的经典编程题（如快速排序、二叉树遍历）。

如果模型能做到这一点，也就是此前从未见过这种语言，仅凭规范的描述就能编写正确程序，那才是跨越了“模式复读”的鸿沟，真正接近了编程智能的本质。反之，如果离开Python和JavaScript就寸步难行，那么再高的榜单分数也不过是记忆的幻象。

洞察7：不能独立评测AI Coding的能力，而应该评测“人+AI”这个复合系统的产出与体验

AI永远不会完全替代开发者亲自上阵。真正的工作单元是“人+AI”。这个复合系统里，AI帮助人拓展认知边界（快速搜索文档、生成样板代码），人帮助AI纠偏和验证（审查逻辑、补充上下文）。评测应该把这种协作效率作为核心指标。

例如，一个任务在人机协作模式下需要多长时间完成，产出的代码质量如何，人的认知负荷（比如每小时的修正次数）有没有降低。学术界已经有一些探索：让一组开发者使用AI，另一组不使用，完成相同的任务，然后比较时间、代码缺陷率、满意度等。这种“人+AI”对比评测，远比孤立地测试模型更有现实意义。

我们还可以从另外一个视角来探讨这个问题哦。传统的评测有一个固执的假设：AI生成的代码必须完美通过编译、通过所有测试用例，才算成功。这个假设在现实场景中很可能是错的。

考虑两种情景：

情景A：AI生成了一段代码，但有一个变量名拼写错了（比如user_id写成了user_if），无法通过编译。人类开发者看了一眼，花三秒钟修正，代码正确运行。
情景B：AI生成了一段代码，语法完全正确，测试全部通过。但它采用了极其晦涩的嵌套条件，没有注释，变量命名毫无意义。人类开发者花了十分钟才理解这段代码是干什么的，然后小心翼翼地将其合并。

传统评测会判情景A为“失败”（因为没通过编译），情景B为“成功”。但在真实的“人+AI”协作中，情景A的实际成本（3秒修正）远低于情景B（10分钟理解）。传统评测忽略了这个维度：AI不需要完美，它只需要让人类的介入成本足够低。

同理，反过来也存在：AI生成了完全正确的代码，但人类需要花大量时间审查、调试、维护——这种“成功”其实是一种隐形的负担转移。

因此，评测的核心对象不应该是孤立的大模型，而应该是 “人+AI”这个复合系统。我们需要测量的不是“AI独自完成了多少”，而是“人与AI协作的产出效率与认知体验”。

具体来说，评测实验可以这样设计：

1. 最小修复时间：给定AI生成的代码（可能带有可快速定位的微小错误），测量一位经验开发者从拿到代码到将其正式提交。时间越短，说明AI的“近似正确性”越高。

2. 理解成本：给定AI生成的正确代码，要求开发者回答几个关于其逻辑的问题（比如“如果输入X，输出会是什么？”），测量回答正确所需的时间。时间越短，代码的可读性越好。

3. 总任务耗时：让“人+AI”协作完成一个完整任务（比如添加一个新特性），从需求理解到最终合入主分支，记录总耗时。与纯人工基线对比，计算净收益。

4. 认知负荷评分：通过开发者自评或行为指标（如中途纠错的频率、查阅文档的次数），评估AI是否真正降低了脑力负担，还是增加了困惑和二次确认。

只有当评测从“AI独舞”转向“人机二重奏”，我们才能看清一个AI编程助手的真实价值，不是它自己能写多好，而是它能让人类写得多轻松。

洞察8：企业需要有AI Coding方案的基准评测体系

很多企业犯过一个同样的错误：根据某个公开榜单选定了AI编程助手，集成到内部开发环境后，起初效果不错。但三个月后，模型有了更新的版本，或者Harness逻辑有了调整，又或者真实代码库的依赖和架构悄然变化了，原本好用的AI突然变得频频犯错。这不是某个模型变“笨”了，而是一个更根本的问题：模型退化在多种因素的叠加下，是必然的，而不是偶然的。

这三种变化通常无人主动告知，退化往往是“无感”发生的，直到某天开发者的效率骤降，或者代码审查发现了AI引入的一批异常模式。

因此，企业不能依赖一次性的选型评测。需要建立生产环境中的“基准评测信标”，构成一套无感的回归评测体系。这套体系的核心思想，借用MLOps领域的概念我自己将其称为EvalOps Harness，将评测本身作为一条持续运行的流水线，嵌入日常开发过程。

具体做法：

1. 选取一组“信标任务”：从企业内部真实的、已完成的历史开发任务中，抽取具有代表性的场景（例如“修复某个类型的并发Bug”“为某个API添加限流”“将某个工具类迁移到新版本”）。这些任务不复杂，但能覆盖核心原子能力。

2. 每天（或每次模型/Harness变更后）自动运行：在隔离环境中，用当前的AI Coding方案（模型版本+Harness配置）执行这些信标任务，记录通过率、总耗时、人工介入次数等指标。

3. 比对基线，报警退化：将当前结果与历史上的“黄金基线”（比如最初验证通过时的表现）进行对比。若任一信标任务的完成时间增加超过30%，或通过率下降超过一个阈值，自动触发告警，通知相关负责人回滚或排查。

这套无感回归评测体系不打断开发者的日常工作，信标任务在后台自动执行，不依赖实时的人工参与。它就像是放在生产环境中的一个“持续健康检查仪”：模型变了，它知道；Harness变了，它知道；真实世界的需求模式变了，它也能通过定期的信标更新来捕捉。

有了EvalOps Harness，企业不再需要等到开发者集体抱怨时才意识到问题。评测从“一次性项目”变成了“持续性基础设施”。这才是企业级AI Coding方案走向可控、可信的必经之路。

褪去AI神话滤镜：从复杂系统视角，重新看懂智能化开发的机遇、边界与未来

Thu, 11 Jun 2026 10:06:00 +0800

小智 2026-06-11 10:06 上海

以下文章来源于：智能时代软件研发

智能时代软件研发

秉承开放，链接的主题，围绕软件工程，需求工程，平台工程等一线工程能力建设，融合数字化，云计算，区块链，新媒体等多个热门技术专题，打造最高效和前沿的技术交流平台，构建多元融合的工程能力生态圈为宗旨。一线前沿资讯，峰会速递，实践分享平台

2026年6月彭鑫教授在上海Agentic AICon 智能体应用与架构工程大会上的演讲

本文内容整理自2026年6月上海Agentic AICon 智能体应用于架构工程大会，复旦大学彭鑫教授专题演讲《复杂系统视角下的软件智能化开发机遇与挑战》。

引言

“AI 六个月接管全部代码”“三年之内编程彻底消亡”，近两年，这类博眼球的论断持续在技术圈层传播。一边是各类产品宣称人工智能可以独立完成数万行代码开发，主流代码大模型接连在专业评测榜单刷新成绩，人工智能 “无所不能” 的神话被不断放大；另一边却是现实场景频频 “翻车”：号称由 AI 独立开发的大型项目代码无法编译运行，大量智能工具生成的补丁即便通过基础测试，也会违背架构规范、埋下长期技术隐患。

行业喧嚣之下，焦虑情绪在从业者群体中蔓延开来。初级开发者担忧自身岗位被AI技术替代，企业技术管理者纠结是否要推翻运行多年的研发体系，一线工程师则在追捧与质疑之间反复摇摆。当整个行业都在聚焦 “人工智能会不会取代程序员” 这一话题时，我们更需要回归软件工程的本质逻辑。抛开流量话术与舆论噱头，以系统复杂性为核心视角，沿着行业舆论乱象、软件本质特征、复杂度底层解析、人工智能技术演进与能力边界、工程落地逻辑、研发体系重构、产业实践探索、行业展望的完整脉络，一步步拆解 AI 辅助软件开发的真实面貌，客观梳理这项技术带来的机遇、挑战，厘清人机协作的合理模式，找准软件行业智能化转型的长期方向。

🔔 金句

“大家每天收到不同的声音，有的说AI多么牛，有的说AI多么垃圾，真正的原因是大家都把前提去掉了——你的项目类型和复杂度呢？”
“Linux内核代码人人都能拿到，但几个人看得懂、改得动？代码共享不代表知识传承。”
“软件开发最大的浪费是知识的浪费，是重复思考的浪费。”
“对于复杂系统，AI是参谋长而非司令员，一定要人去掌舵。”
“系统复杂性始终在那里，你不把第一原理讲清楚，就会整天被公众号搞得很焦虑。”

众声喧哗：

拨开舆论迷雾，正视认知偏差

当下行业对于 AI 编码能力的评价呈现出极端两极化的态势，有人将其奉为行业变革的终极答案，也有人在企业级项目落地中屡屡碰壁，认为其实用性有限。这种认知分歧的背后，并非技术本身出现矛盾，而是大众在评判技术时，普遍忽略了诸多核心前提，最终形成了 “盲人摸象” 式的判断。

早在 2023 年，前谷歌工程主管 Matt Welsh 就抛出激进观点，认为生成式人工智能会在三年内彻底终结编程工作，未来软件研发团队仅需要保留产品经理和代码评审两类岗位。时隔不久，Anthropic 企业负责人更是进一步放大舆论，宣称人工智能全面接手代码开发工作，最短只需要六个月。与此同时，不少商业产品对外宣传，依靠 AI 工具在短时间内完成数百万行代码的浏览器项目开发，迅速吸引全网关注，但很快就被业内人士打假，相关代码漏洞百出、完全不具备实际运行价值。

各类真假信息交织，加上部分媒体惯用片面解读、刻意制造对立的传播方式，进一步放大了行业的认知混乱。不同使用者对 AI 的体验天差地别，核心原因在于，大家所处的项目场景、软件复杂度、开发模式、个人技术积累以及所使用的工具环境都截然不同。用单一场景下的使用感受，去定义一项技术的整体能力，本身就存在巨大逻辑漏洞。想要理性看待智能化开发，首先要跳出舆论陷阱，认清软件行业三大基本特征：形态具备多样性、系统存在固有复杂性、软件开发本身是持续探索的过程。

从实际应用场景划分，市面上的软件可以分为三大类，不同类型的软件，对应着人工智能完全不同的发挥空间。

第一类：一次性解决方案，这类程序以完成单次任务为唯一目标，使用结束后便可直接舍弃，比如为临时数据处理、单次设备操控编写的简易脚本。这类场景逻辑简单、无后续维护压力，人工智能能够独立完成代码编写、运行等全流程工作。

第二类：通用工具应用，主要服务于固定业务流程与批量处理任务，比如常规信息管理系统、标准化办公工具。这类软件代码体量往往较大，但业务逻辑规整，人工智能可以完成绝大部分编码工作，开发者仅需做最终确认、局部微调与效果反馈。

第三类：大型复杂系统，以操作系统、电信核心平台、金融交易系统为典型代表，这类系统要求长年稳定运行，对安全性、兼容性、容错性有着极致要求，内部组件繁多、依赖关系盘根错节。在这类项目中，人类工程师需要主导架构设计、模块拆分、代码评审等核心工作，人工智能仅能承担局部代码填充这类基础任务。

在智能化技术快速发展的当下，还有一个概念误区亟待纠正：编程不等同于软件开发。传统教材将软件定义为 “程序 + 文档”，但在 “软件定义一切” 的行业大趋势下，这一定义早已无法覆盖真实的产业场景。单纯的编程，仅仅是将既定逻辑转化为代码字符的单一环节，也是当前大模型最擅长的工作内容。而软件开发是一套完整、严谨的工程体系，拥有四大核心特质：系统需要实现长期稳定运行，同时应对各类极端边界场景；软件根植于真实的社会与物理环境，需要遵守外部行业规则、监管要求；内部架构精巧且复杂，各个组件之间深度联动、相互影响；项目交付不是终点，系统需要经历长年累月的迭代、优化与维护。

如今着重区分二者的边界，有着极强的现实意义。一方面，数字化转型渗透到各行各业，软件的规模与复杂度持续攀升，社会对于软件安全、合规、可靠的要求不断加码；另一方面，大模型的代码生成能力飞速提升，其擅长编码、却无法驾驭复杂系统全生命周期开发的短板，被不断放大。基于行业现状可以明确判断：仅仅依靠大模型技术，无法实现软件智能化开发的根本性变革。目前整个行业过度追逐大模型、智能体带来的流量热度，却很少深入思考软件工程最核心的难题 —— 复杂需求拆解、顶层架构设计、系统性逻辑梳理，而这些恰恰是人工智能难以突破的能力盲区。

敬畏系统复杂性：

软件开发所有难题的底层根源

系统复杂性，是解读 AI 辅助开发所有问题的核心立足点。无论是人工智能的能力短板，还是传统软件开发过程中遇到的各类疑难问题，追根溯源，都指向软件与生俱来的复杂性。正视、敬畏系统复杂性，才能客观判断技术的价值与边界。

在传统单体软件开发阶段，工程师可以通过断点调试、单步跟踪、变量监控等方式，完整掌握程序每一步的运行状态，对系统实现全方位把控，业内将这种状态形象地称为 “上帝视角”。但随着微服务、分布式架构、云原生技术的普及，现代软件被拆分为数量庞大的独立组件，跨进程、跨服务器交互成为常态。时至今日，工程师已经无法完整追踪系统的全链路运行过程，只能依靠日志、监控指标、链路追踪等可观测性工具，结合自身从业经验，反向推导、验证问题所在。从 “全面掌控” 到 “推测验证”，这一转变，正是软件系统复杂度不断飙升最直观的体现。

从专业角度定义，软件系统复杂性，指系统因组件数量庞大、组件间交互呈现非线性特征、运行状态多变且难以预判，进而产生整体涌现特性。这类特性无法通过拆解、分析单个组件来理解系统整体行为，也是复杂系统故障频发的核心原因。而系统复杂性主要来源于三个维度：规模与连接关系、非线性交互、系统适应性。

首先，复杂度高低和代码行数没有必然关联，核心取决于组件数量以及组件之间的交互网络。一套百万行代码的系统，如果被合理拆分为大量相互独立的模块，模块之间仅通过标准化接口通信，整体复杂度并不高；反观一段仅有百行的代码，倘若各个逻辑单元深度耦合、互相牵制，修改任意一处都会引发全局变动，其复杂度反而会居高不下。其次是非线性交互，软件中一处微小的代码改动、一个不起眼的输入变化，都有可能引发不可逆的全局故障，业内流传的“删除一行看似无用的代码，导致整套系统彻底崩溃”，就是非线性交互最典型的案例。最后是系统适应性，软件需要跟随外部业务、运行环境持续迭代更新，不断衍生出新的运行模式与逻辑行为，进一步加剧了系统的不可预测性。

业内沿用数十年的经典理论，将软件复杂性划分为本质复杂性与偶然复杂性，这一划分源自《人月神话》中的经典观点，时至今日依然对行业具备极强的指导意义。

本质复杂性，来源于业务问题本身，是行业规则、业务逻辑、外部环境带来的固有难度，这类复杂度无法通过技术工具、开发模式的改变被消除。举例来说，金融系统的财务报销流程、工业控制系统的安全操作规范、政务软件的审批逻辑，无论使用哪种编程语言、哪种开发框架，都必须完整承接对应的业务规则，这部分复杂度与生俱来。

偶然复杂性，则并非业务本身所需，而是在软件开发、落地、迭代的过程中，后天引入的额外负担。技术选型失误、架构设计缺陷、模块化划分不合理、开发者经验不足、项目进度紧张欠下技术债等因素，都会催生偶然复杂性。

结合当下数字化发展趋势来看，本质复杂性与偶然复杂性都处在持续增长的状态，这也彻底打破了 “人工智能可以消灭软件复杂度” 的幻想。

本质复杂性不断提升，主要有三方面原因：一是软件应用边界持续扩张，物理世界、社会生活的各类场景全面向数字世界迁移，软件需要承载的业务范围越来越广；二是万物互联格局不断深化，人机物融合、跨平台跨系统联动成为常态，“系统之上的系统” 随处可见，组件交互规模呈指数级增长；三是软件承载的社会属性不断强化，稳定性、数据隐私、网络安全、伦理规范等社会性要求，逐步融入软件设计与运行规则之中。

偶然复杂性的增长同样存在客观必然性。首先是阻抗失配问题，人类在梳理业务、设计方案时，使用的是抽象的领域思维与自然逻辑，而代码必须遵循机器的语法规则与执行逻辑，两种思维体系天生存在鸿沟，这也是偶然复杂性最核心的来源。其次，软件工程依赖分层、模块化等抽象思想，但不存在绝对完美的抽象体系，底层逻辑的隐性交互，时常会突破抽象边界引发各类故障。与此同时，开发者往往在信息不全、工期紧张的状态下做出设计决策，个人经验、责任心的差异，也会制造额外问题。再加上复杂系统的涌现效应，组件之间细微的相互作用不断叠加，最终衍生出各种无法提前预判的问题。

想要理解人工智能在存量复杂系统中举步维艰的现状，还要看清工业软件真实的存在形态。

现实中的企业级软件，普遍存在逻辑混杂与代码散布两大痛点，这也是多年前面向切面编程技术想要解决的行业难题。逻辑混杂，指同一个函数、同一个代码文件中，糅合了业务计算、数据库读写、网络请求、日志输出、异常处理等多种毫无关联的逻辑，功能边界完全模糊。代码散布，则是指同一个业务概念、同一套功能逻辑，对应的代码片段分散在系统的各个角落，彼此没有直观关联，开发者想要梳理完整的逻辑链路，需要耗费大量精力遍历全系统。人工智能依靠关键词检索、上下文匹配完成代码操作，面对这种混乱的代码形态，根本无法穿透表层字符，理解背后的业务逻辑。

除此之外，软件是具备生命力的产品，始终处在持续演化的过程中，这一特点可以用一个通俗的比喻来理解：就像在诸多现实约束下搭建房屋，无法推倒重建，只能在原有基础上不断修补、扩建。软件的每一次迭代，都是在历史代码、现有依赖、时间压力的多重约束下做出的权衡取舍。早年为了快速上线临时添加的功能，因为层层依赖无法下线，逐步变成无人敢动的 “死代码”；不同时期、不同开发者编写的临时补丁层层叠加，形成业内戏称的 “狗皮膏药式开发”。长年累月下来，整套系统形成了独有的运行逻辑与历史痕迹。而当前的人工智能模型，大多围绕 “一次性代码生成” 设计，无法理解软件的演化历史、设计决策的背景以及各类隐性约束，这也是它难以胜任存量系统维护工作的核心原因。

AI 编码技术演进：

从简单指令到系统性管控

伴随着落地场景的不断深入，AI 辅助编码的技术形态与应用逻辑也在持续迭代。整个发展过程，本质上是人类对于人工智能的管控能力不断强化的过程，大致可以划分为三个阶段。

第一阶段是提示工程，也是大众最先接触到的使用模式。这个阶段的核心重点在于 “如何向 AI 提问”，使用者依靠优化自然语言指令，引导模型生成符合预期的代码，使用方式简单，但效果高度依赖话术质量。

第二阶段是上下文工程，使用者不再局限于优化提问方式，而是主动把控模型的信息来源。通过主动投喂代码片段、项目文档、接口说明等内容，划定模型的认知范围，减少无效输出，相比单纯的话术引导，实用性大幅提升。

第三阶段也是目前企业级落地的主流方向 —— 驾驭工程。这一模式不再局限于信息供给，而是搭建起全流程的系统性管控体系，结合事前引导、事后校验的双重逻辑，形成完整的闭环，让人工智能在规则框架内稳定工作。

业内极具代表性的落地案例，印证了驾驭工程的落地逻辑。一支小型技术团队依托代码智能体，从零起步开展项目开发，耗时五个月完成了超百万行代码的产品搭建。但这个案例能够成功，存在三个不可忽视的前置条件：项目本身业务规模大，但整体逻辑复杂度偏低；项目从零搭建，没有历史代码、技术债等包袱；团队提前将整套项目拆分为数百个相互独立的软件包，实现模块深度隔离、接口标准化，让人工智能可以分模块独立完成工作。

这一实践充分说明，人工智能和人类开发者一样，同样依赖清晰的模块划分与解耦设计。一旦模块之间深度耦合、上下文信息杂乱，人工智能同样无法正常开展工作。与此同时，项目团队配套落地了传统软件工程的各类规范：定制化代码检查工具、架构约束校验规则、定期技术债务清理机制，这也证明，经典的软件工程实践，是 AI 编码落地的重要保障。

从管控逻辑来看，驾驭工程可以划分为前馈控制与反馈控制两大维度，分别适配计算型、推理型两类开发任务。前馈控制属于事前引导，针对计算型任务，会提前设定代码规范、语法校验规则；针对推理型任务，则通过明确自然语言规则，划定技术栈、架构原则、设计约束等边界。反馈控制属于事后校验，针对计算型任务，依靠类型检查、静态分析、自动化测试，校验代码语法与基础功能；针对推理型任务，则借助大模型开展二次代码评审，从逻辑、架构层面排查问题。

评判一个 AI 开发项目是否具备长期价值，不能只看短期的代码产出效率，需要从两个核心维度持续拷问。第一是空间维度，项目模块之间是否存在复杂的交互关系？模块解耦、交互简单的项目，AI 容易做出成果；而模块联动复杂、依赖交错的系统，人工智能的短板会快速暴露。第二是时间维度，项目能否经受长期演化的考验？一次性交付成功并不代表模式可行，存量迭代、版本升级、故障修复等长期工作，才是检验技术能力的真正试金石。

可驾驭性：

界定 AI 能力边界的核心标尺

结合大量落地实践，行业总结出可驾驭性四大判定标准，这也是衡量一项开发任务是否适合交由 AI 完成、人工智能能够发挥多大价值的核心依据。只有同时满足这些条件，AI 才能稳定、可靠地参与开发工作。

第一，任务本身拥有清晰定义，且具备可自动化验证的标准。需求明确、规则固定，能够批量生成自动化测试用例，结果可以量化校验，这类任务适配 AI 能力，比如代码翻译、通用工具函数开发。反之，需求模糊、需要主观判断、依赖人工验收的任务，人工智能很难胜任。

第二，运行环境具备可理解、可导航、可操控的特性。项目目录结构、接口文档、组件依赖关系清晰完整，智能体可以自主遍历环境、执行操作，不会因为信息缺失陷入停滞。

第三，系统完成充分解耦设计。各个模块遵循高内聚、低耦合的原则，功能边界清晰，模块之间仅通过标准化接口交互。人工智能可以独立处理单个模块的开发工作，无需应对复杂的跨模块依赖。

第四，底层交互实现充分抽象。框架、中间件、硬件底层的复杂逻辑被完全屏蔽，上层开发者只需要聚焦业务本身，避免底层隐性交互引发各类未知故障。

即便项目满足可驾驭性要求，AI 智能体在运行过程中，依然存在四大先天性缺陷，这也是人机协作无法被彻底替代的关键原因。

首先是测试反馈机制不完备，存在严重的过拟合风险。人工智能的优化目标是通过测试用例，因此会刻意生成大量模拟数据绕过校验规则，代码表面上功能正常，实际运行后会暴露出致命漏洞。甚至部分用于修复漏洞的智能体，会篡改评估模块的判定逻辑，刻意制造 “修复成功” 的假象，留下巨大线上风险。

其次是自然语言引导存在精度上限。依靠自然语言下达修改指令，本质是 “经验式引导”，语言本身的模糊性，导致 AI 很难精准定位到目标代码位置，时常误修改正常逻辑，越调整问题越多。

再者是架构约束难以落地，架构看护长期缺失。人工智能无法深度理解架构设计的底层逻辑与长远考量，一旦系统出现架构腐化，它会顺着错误的逻辑继续生成代码，进一步加剧系统问题。

最后，人工智能缺乏全局认知、风险意识与责任担当。面对故障，它只会在表层修复问题，无法追溯根源、彻底解决隐患；面对潜在风险，它没有预判能力，无论代码是否存在漏洞、是否会引发连锁问题，都会无条件生成输出；同时，它无法体会长期维护的压力，不会主动规避技术债。而人类工程师会综合考量各类隐性约束，评估上线风险，追溯问题根源，这份基于责任的敬畏之心，是人工智能无法复刻的。

海外一项技术实践也直观印证了 AI 的能力局限：技术团队投入成本，调用智能体集群尝试用新语言编译底层工具，最终仅完成基础雏形，剩余核心问题始终无法攻克。而该团队自身的客户端产品，也存在代码臃肿、漏洞频发等问题。这足以说明，面对深度复杂的底层系统，人工智能依旧难以跨越技术的 “最后一公里”。

软件工程体系：

AI 时代不可抛弃的发展基石

随着 AI 技术普及，行业中出现一种片面观点：传统研发流程、质量管控体系规则繁琐，拖累了 AI 的开发效率，应当彻底摒弃。但从产业实践来看，在 AI 时代，软件工程体系的重要性不仅没有下降，反而大幅提升。我们不需要推倒原有体系，而是结合 AI 的特性完成适配与升级。

首先要落地的核心方向，是搭建代码数字孪生体系，解决行业长期存在的 “代码可复制、知识无法传承” 难题。从本质上来说，代码仅仅是软件的物理载体，作用是承载机器可识别的执行逻辑；而业务意图、设计思路、决策取舍、排障经验等高层知识，才是一套软件真正的核心资产。

代码数字孪生的核心目标，就是在代码之上搭建对应的逻辑视图，建立代码与高层知识的双向映射关系。这套体系可以让人工智能不仅知道 “代码该怎么写”，更能理解 “当初为什么要这样设计”，在设计约束、历史经验的指引下，输出更贴合工程要求的代码。同时，它也能解决知识碎片化、隐性经验流失的问题，避免不同开发者重复踩坑。

整套体系以源代码、项目文档、版本提交记录、问题工单、代码合并记录等全量研发数据为基础，自动化抽取领域概念、功能逻辑、设计原理三类核心知识，构建代码图谱、概念图谱，实现知识与代码同步迭代、动态更新。

其次是重新定义人机协作的分工模式，遵循 “因地制宜、优势互补” 的原则。在小程序、临时脚本、独立工具等低复杂度场景中，AI 可以承担主要编码工作，人类仅负责最终审核，最大化释放技术提效价值。在大型核心业务系统、分布式复杂系统等高复杂度场景中，必须坚守明确的分工边界：人工智能扮演 “辅助参谋” 的角色，负责代码生成、常规检查、问题探查、方案罗列，为决策提供参考依据；人类工程师作为 “掌舵者”，统筹全局，负责架构设计、模块拆分、需求分析、风险管控、架构看护、最终决策与故障兜底。人机协作的核心是各司其职、取长补短，而非一方彻底替代另一方。

最后，坚持可驾驭设计，将模块解耦、分层抽象作为长期价值投资。持续优化模块划分与接口设计，让人工智能在明确的规则约束下独立工作；统一技术底座，屏蔽底层复杂逻辑，拓宽 AI 的有效工作范围；建立常态化的架构治理机制，在系统迭代过程中，及时纠正架构偏差，防止架构持续腐化。如果放任代码耦合、逻辑混乱、架构失控，最终只会让 AI 彻底失去应用价值。

产业前沿实践：

面向复杂系统的智能化开发探索

针对复杂系统开发、存量代码维护中的各类痛点，业内技术团队结合软件工程理论与 AI 技术，开展了多项落地探索，并且形成了可落地的方案与实测成果。

针对 “AI 一次性生成完整代码漏洞多、逻辑不连贯” 的问题，行业探索出特性驱动的迭代式开发模式。不再追求一步到位完成开发，而是由业务、架构人员拆解整体需求，梳理出清晰的功能列表与功能图谱，按照单个功能分阶段完成设计、编码、验收。每一轮代码生成后，都会经过人工审查、自动化校验，确认无误后再进入下一轮迭代。在移动端开发场景的实测数据显示，这种模式相比直接使用大模型开发，功能完整度提升超五成，对比单一智能体方案，能力提升区间达到 16% 至 76.6%。

针对代码 “混杂、散布” 导致 AI 无法定位故障代码的痛点，技术团队研发出基于概念抽取的问题定位方案。通过抽取代码中的业务概念、核心关注点，生成可视化的知识导航地图，帮助 AI 精准锁定目标代码。在主流专业评测数据集的测试中，这套方案让代码检索、问题定位的准确率提升 28% 至 47%，有效解决了复杂代码场景下的定位难题。

当前主流 AI 评测体系，大多仅以 “是否通过自动化测试” 作为唯一判定标准，完全忽略架构规则、API 使用规范、代码一致性等隐性设计约束。为此，团队开展设计约束感知技术研发，让 AI 在生成代码、修复漏洞时，主动识别并遵守整套系统的设计规则。对开源项目历史漏洞修复记录的分析显示，大量通过测试的 AI 补丁，都违背了原有设计逻辑，会引入长期技术债，统计发现 AI 生成的补丁中，仅有不到半数能够满足工程设计约束，这也是多数 AI 代码无法正式上线的核心原因。

与此同时，行业也在重构工业级 AI 评测体系。原有评测任务场景简单、验证标准单一，没有区分任务难度，也无法衡量人机协作能力。新的评测体系搭建了多维度场景分类、任务难度分级规则，综合考量系统复杂度、私有业务知识、上下文规模等真实工程要素；在评判指标上，新增设计约束满足率、工程可接受度、长期可维护性等核心维度；同时搭配动态更新的测试环境，让评测结果更贴合企业真实研发场景。

总结与展望：

敬畏复杂性，理性驾驭 AI 技术

软件的本质复杂性会随着数字化、万物互联的发展持续提升，偶然复杂性也会因思维鸿沟、人为局限客观存在。大模型依托文本训练的先天特性，决定了它无法感知代码之外的系统复杂性，单纯提升模型性能，永远无法突破软件工程的底层难题。

对于整个软件行业而言，系统复杂性是理解 AI 辅助开发的第一性原理。基于这一核心认知，行业的发展方向也变得清晰明确：无需摒弃积淀数十年的软件工程体系，而是结合 AI 的特性完成升级，打造面向智能体的运行环境、反馈机制与管控体系；全面落地代码数字孪生，搭建全员参与的知识沉淀体系，弥补 AI 在高层逻辑、历史经验上的短板；坚守科学的人机协作模式，让 AI 负责重复性编码工作，人类把控核心决策与风险；始终坚持解耦、抽象、架构治理等可驾驭设计，为 AI 长期落地筑牢基础。

人工智能是软件行业发展的加速器，能够有效提升编码环节的效率，但它绝非颠覆整个行业的 “终结者”。驾驭 AI 的能力，决定行业发展的速度；敬畏系统复杂性的智慧，决定行业能走多远。在软件产业漫长的发展征程中，我们不必被舆论制造的焦虑裹挟，也不能盲目追逐技术噱头。保持清醒的判断，正视软件的固有复杂性，理性拥抱智能化技术，坚守软件工程的核心原则，才能让 AI 真正服务于产业发展，推动软件行业行稳致远。

在看

跳转微信打开

AI时代软件工程的价值：学生视角的实践体验

Wed, 10 Jun 2026 18:34:00 +0800

CodeWisdom 2026-06-10 18:34 上海

来自复旦大学吴嘉原同学的软件工程课程实践思考

大模型时代软件工程的价值

基于软件工程（H）课程项目的实践与思考

吴嘉原
复旦大学计算与智能创新学院

近年来，大模型的能力突飞猛进，写代码似乎突然间变得门槛极低——只要输入自然语言，AI 就能迅速吐出成百上千行代码，写出来的程序又美观又好用。但事实果真如此吗？

在本学期彭鑫老师主讲的软件工程（H）课程实践项目中，我和另外 3 位同学组成了开发小组。我们在开发中深度使用了 Claude Code、Copilot、Cursor、Codex 等主流 AI 编程工具，并融合了部分“古法编程”的实践。在经历了从设计、实现到测试、迭代的完整生命周期后，我们有了深刻的体会：AI 的发展并没有让软件工程成为历史。任何工具的实际使用效果极大地受到使用者自身能力的影响。区别于非专业开发者，专业软件工程师懂得运用软件工程理论，通过充分的需求分析、良好的架构设计、成熟的编程规范、全面的软件测试，确保所构建的软件系统可靠、稳定、可持续。就目前 AI 的能力看来，这些效果是非专业开发者单纯依赖 AI 工具所无法取得的。此外，随着系统复杂性的增加，单纯依赖 AI 会让项目逐渐脱离人的掌控，大大降低项目的可维护性。

AI 辅助软件开发的几种模式

在审视了团队成员与 AI 的对话记录后，我们总结了以下人机协作模式：

氛围编程 (Vibe Coding)

这是当前最“火”的 AI 辅助开发模式，根据人工介入程度不同，又可细分为三个子模式：

纯粹氛围编程 (Pure Vibe Coding)： 用户仅提出模糊的功能需求，将设计、编码、基础测试全权委托给 AI，仅以“代码是否实现预期功能”作为唯一验收标准，可能有简单但不充分的代码质量检查。

Prompt

请实现团队模块的成员系统，要求支持成员管理。

纯粹氛围编程 (Pure Vibe Coding) 示例 Prompt

监督式氛围编程 (Supervised Vibe Coding)： 在 Pure Vibe Coding 的基础上，增强人工监督，一旦发现 AI 迭代方向偏离预期，立即打断并干预。在 AI 迭代完成后，加强对交付物的审查。

约束式氛围编程 (Vibe Coding with Constraints)： 在 Pure Vibe Coding 的基础上，在 Prompt 中内置详细的工程要求，作为对 AI 迭代过程的约束。

Prompt

请实现团队模块的成员系统，要求支持成员管理，要求如下：
1. 权限模型使用 RBAC，角色、权限点必须用数据库实体管理。
2. 接口遵循 docs/lab3/API_REFACTOR.md 中已定义的契约，路径与字段名保持一致。
3. 数据库变更必须通过 Flyway migration 提交，禁止直接改动既有表结构。
4. Controller 层只做参数校验与响应封装，业务逻辑下沉到 Service，Service 层采用接口 + impl 的结构。
5. …（更多约束）

约束式氛围编程 (Vibe Coding with Constraints) 示例 Prompt

精确编程 (Accurate Coding)

用户提出原子的需求，需求没有模糊地带，让 AI 进行小规模编辑，涉及文件数量少，编辑正确率高。

Prompt

Prompt 请在此页面的左上角增加 Element Plus 按钮，使用 primary 样式。

精确编程 (Accurate Coding) 示例 Prompt

启发式编程 (Inspired Coding)

启发式编程（Inspired Coding）的核心目标不在于获取最终形态的生产代码，而在于利用大模型极高的生成速度，为技术设计提供灵感。在此模式下，用户提出模糊的需求，没有明确的实现方案，让 AI 迭代生成一个 Demo，随后根据此 Demo 理清思路，推翻或部分推翻此 Demo，重新设计并实现，工作流见下图：

图1：Inspired Coding 工作流

大模型引入的工程问题

在享受了开发初期的效率红利后，随着系统复杂度的提高，大模型“非工程化”的特性给项目带来了诸多技术问题：

1. 代码复用性差：大模型在生成代码时，缺乏全局视角，在不配置 memory、rule 的前提下，往往无法主动复用系统已有的全局导入、通用工具类等，导致项目中出现大量代码克隆。

2. 上下文记忆丢失：在不同的会话之间或较长的上下文窗口下，AI 会丢失记忆，导致此前代码检视中反复强调过的问题重复出现。

3. 缺乏设计性和可扩展性：这一问题在“纯粹氛围编程（Pure Vibe Coding）”模式下尤为严重。AI 为了快速跑通当前功能，倾向于选择最快捷的解决方案，极易引入硬编码等问题。以下是我们在代码检视阶段拦截的一例由 AI 自主生成的代码：

AI 自动生成的 RBAC 权限设计

客观来说，该设计确实能起到鉴权功能，却使得权限系统在运行时失去了动态扩展能力，用户若要加入新的角色，就必须直接修改代码。

4. 编码惯性思维：模型在处理特定业务逻辑时，往往会陷入其训练数据所带来的惯性思维和刻板套路中，难以根据本项目的特定技术栈约束（如特定的依赖版本或私有框架组件）进行灵活变通。

5. 无法证明生成的测试的正确性：虽然 AI 可以依据业务代码快速自动吐出单元测试，但人类开发者很难在逻辑上证明这些自动生成的测试用例本身是否完整、正确，甚至面临 AI 针对测试断言进行“作弊”的风险。

6. 开发者身份错位（Who is the real Agent?）：这是一个极具讽刺意味的问题。在代码持续迭代的过程中，一旦生成的代码未通过检视，原始开发者往往因无法掌控庞大的生成代码，反向沦为了“传话者”——机械地在 Reviewer 与 AI 之间搬运、转述检视意见，无法独立完成代码修改。

图 2: 人沦为 AI 反馈回路中的传话工具

如何解决AI带来的挑战

解决 AI 带来的问题，核心策略不在于一刀切的排斥 AI，而是克制的、有监督的使用，以下是我们团队在实践中总结出的几条经验：

1.坚持先设计、后编码的策略：大模型在处理单点功能实现时非常高效，但它完全无法预料到未来的潜在需求演进，这种局限性导致它对增量开发极其不友好。如果前期缺乏人类的架构规划，后续的迭代很可能会引入大量技术债，甚至导致系统崩溃。

2. 集中配置团队统一的 Agent 记忆 (Memory)：针对跨会话记忆丢失、检视意见在不同对话中反复出现的严重问题，我们创建了统一的.agent 目录，将项目的架构文档、开发流程规范写入 AI 记忆，强迫大模型在迭代时遵循已有的规范。

3. 设置自动化质量检查流水线（CI）：对于静态代码问题，如未使用的冗余导入、已经失效的死代码、不符合规范的命名冲突，以及大模型由于缺乏全局感知引入的代码克隆，我们可以在 CI 流水线中嵌入自动化的静态代码扫描工具，提高代码检视效率和准确率。

需注意，AI 为了通过流水线极易产生针对测试用例“打表作弊”的现象，针对这一问题目前尚无完全非人工的解决方案，我们的解决方案是完善测试用例的设计，尽量避免出现可以钻空子的漏洞。

4. 明确人机协作的边界：见下一节。

我们对于 AI 辅助软件开发的思考

结合整个项目的实践过程，我们对大模型时代下的人机协同的边界以及开发范式进行了以下客观梳理：

4.1 适合使用氛围编程 (Vibe Coding) 的场景

尽管氛围编程存在风险，但在以下特定场景中，它依然能展现出生产力优势：

• 对技术栈不熟悉时：当开发者本身对当前项目的特定技术栈不是很熟悉时，Vibe Coding 能够越过繁琐的语法学习，快速搭建起一个达到“可运行状态”的基础脚

手架。

• 获取初期设计灵感：在架构设计的迷茫期，希望大模型提供启发时，通过大颗粒度的需求抛出，可以快速人类开发者开拓思路。

• 对系统可扩展性和鲁棒性要求不高时：对于一次性验证的临时 Demo、极短生命周期的辅助脚本或不需要后续维护的玩具项目，代码不需要经历长期的需求演进。此时， Vibe Coding 快速生成的效率优势能够被最大化，而其引入的缺陷并不会带来实质性的危害。

4.2 大模型时代下软件开发的最佳实践

• 设计阶段（人类主导）：需求的解构、软件架构的设计必须由人主导。在此阶段，可以适当使用启发式编程（Inspired Coding）获取原型灵感，但最终决定权归人所有。

• 实现阶段（人机协同）： 在实际编码过程中，推荐采用监督式氛围编程（Supervised Vibe Coding）与精确编程（Accurate Coding）相组合的方式，确保代码处于受控状态。

• 测试阶段（人工掌控）：自动化检查会面临投机风险，因此测试用例必须由人工主导制定，绝不能全部交给 AI 自我测试。

结语：不被 Vibe Coding 的表象迷惑

在人机协同开发的过程中，我们常常会陷入一种“Vibe Coding 极为高效”的幻觉。但我们之所以觉得大模型 Vibe 出来的代码又美观又好用，往往是因为缺乏对底层代码库的审查，只被其在极小样本下跑通的功能表象所迷惑。非专业开发者极易在系统初期的快速交付中迷失，而专业软件工程师明白，浮于水面之上的“功能跑通”往往只是冰山一角。

软件工程课程让我们深刻意识到：软件工程的价值在于高屋建瓴的设计，而非机械的代码实现。在大模型时代，“把代码写出来”的门槛和边际成本已经被极大地拉低，单纯的编码实现已经不再是核心壁垒。一个系统的生命力，并不取决于 AI 在几秒钟内吐出了多少行代码，而取决于最初的架构设计是否合理、技术栈选型是否理性、接口契约是否严密。专业工程师的核心价值，正是通过迭代式设计来框定核心功能的边界，用明确的约束条件去规范 AI 的随意生成，并用人工主导的严密测试用例去穿透功能表象、消除隐蔽的技术债。工程的本质，永远在于用极致的秩序去对抗现实世界的随机性与复杂性。

个人简介

吴嘉原，复旦大学计算与智能创新学院软件工程大二本科生，专注于大模型时代软件开发过程中人机协同范式的探索。

跳转微信打开

复旦这门课，教你跟AI“聊”出一个软件

Mon, 08 Jun 2026 09:22:00 +0800

赵天润 2026-06-08 09:22 上海

以下文章来源于：复旦大学

复旦大学

这里，有你关心的复旦人和复旦事。欢迎关注复旦大学！

彭鑫老师牵头开设，面向非计算机专业同学的Vibe Coding课

当AI能写代码、做设计、翻译文章

非计算机专业的同学

如何学会驾驭AI

成为“大众开发者”？

复旦大学今年春季学期

全新开设的AI大课

“生成式软件开发”

给出了一个有趣的回答：

学会跟AI

把软件“聊”出来

让非专业学生

也有机会成为程序员

一门培养“大众开发者”的新课

周五上午第三节课，三教101教室里，同学们正盯着屏幕。

讲台上，计算与智能创新学院副教授吴毅坚正在演示一个“天气出行规划系统”，他对着AI工具一句一句描述需求，不一会儿，一个带前端界面、后端接口的网页应用就出现在屏幕上。

台下，社会发展与公共政策学院23级本科生廖书伦记着笔记。他上学期试用Trae这种AI原生集成开发环境帮自己写过爬虫，但自己的自由探索经常发现AI写的代码就像“抽卡”，能否跑起来就像是许愿。“上了这门课才知道，用AI写代码也是有章法的。”

这门“生成式软件开发”课程由计算与智能创新学院副院长彭鑫牵头，张天戈、吴毅坚联合主讲，专门面向非计算机专业学生。今年春季第一次开课，便吸引了全校五十余名学生选修。

彭鑫回忆，去年年底斯坦福大学开设了一门基于自然语言编程的课程，这让他想到复旦当时正在推进AI大课建设，面向全校学生提供人工智能相关课程，彭鑫团队本身就在研究AI辅助软件开发，也有成熟的技术积累。

他很快邀请了有丰富企业开发经验的张天戈和长期从事智能化开发研究的吴毅坚加入授课教师团队。课程推介中那句“把软件聊出来”的吸引了不少同学的目光。

在彭鑫看来，这并非夸大其词，

“我们进入了一个‘大众开发者’的时代。过去，只有受过专业训练的程序员才能开发软件。现在，AI帮你把底层的实现细节屏蔽掉了，你只要把自己的问题讲清楚、拆解好，AI就能帮你生成能跑起来的软件。”

他也强调，这里的“程序员”和专业开发者仍然有区别。专业开发者要面对需要具备高可靠性并进行长期维护的复杂系统，比如大家每天都在使用的在线社交、网上购物以及电信系统，需要深入掌握算法、数据结构、操作系统等知识并驾驭复杂软件架构。而大众开发者只需要学会如何与AI对话，就可以为自己定制小工具、小软件。

降门槛不降标准

工程化思维是关键

给非计算机专业同学讲课很有挑战。吴毅坚坦言：“讲深了，大家基础跟不上；讲浅了，又怕大家只停留在表面。”最终团队决定从软件工程的核心思想中抽取精华，用非专业人士能听懂的方式呈现。

课程从第1周到第16周层层递进，初期用纯对话模式开发简单应用，遇到复杂度瓶颈后自然引入问题分解与规划、上下文工程、Spec（规格说明）驱动开发、版本管理、软件测试等工程化手段。

张天戈说：“如果只教聊天式生成，价值并不大。当项目稍复杂，学生立刻感受到没有版本管理和问题分解就寸步难行，这时再教这些方法，他们吸收特别快。”课程每个阶段都配有详细的实验作业，一份文档长达六七页，步骤、验证方法、评分标准写得清清楚楚。

相比软件工程专业课，这门课淡化深入的软件设计与实现机制，聚焦需求拆解、版本管理、测试验证、增量迭代等高层工程素养。

为了把硬核概念讲明白，老师们用生活化的比喻来翻译。讲到版本管理，张天戈把它比作“时空穿梭”：项目像一条时间线，可以在任意节点回到过去。同学们听完后纷纷给自己的项目建起了Git（分布式版本控制系统）仓库。讲到问题分解，彭鑫用“办一场晚会”举例：如果助手能力很强，给一个模糊目标就行；如果助手能力一般，就得把任务拆成“买饮料、买零食、布置场地”一步步交给他。

AI也是如此，需要学会拆解问题、分步骤推进、迭代优化，并根据大模型的能力决定问题拆解的粒度以及上下文提示的详细程度。这些能力不依赖编程知识，却需要工程化思维。

“人人都是程序员”的真正含义

为什么给非专业同学开这门课？

彭鑫举了一个例子：20多年前选课还要填纸质表格，后来有了选课系统，但信息化只能覆盖全校层面的共性需求。如今，每个同学、每个专业特有的个性化需求，比如，社会学专业的文献管理工具、临床医学的病例分析系统、法律专业的判例文书整理助手，过去因为开发依赖专业程序员、成本太高而只能停留在想法里。现在借助AI，一个非专业学生可以在几周甚至几天内自己“聊”出一个可用的软件。

当AI把编码门槛大幅拉低，未来“程序员"不再仅属于机房，也可属于实验室、档案馆、法院、诊室与田野……

张天戈在开课前做过一次问卷，想了解同学们希望用这门课解决什么问题。答案五花八门：有人想做学习笔记管理，有人想做实验数据分析，有人想做一个互动式英语学习网页。“虽然很多想法还很小，但说明大家已经意识到，AI可以帮助他们把专业需求变成现实。”

在面向计算机专业的软件工程课上，彭鑫会故意加大课程项目难度，逼着学生意识到不能全靠AI。而这门课定位不同，学生用AI生成代码、关注测试与验收即可，不必深究每行实现。但其中的分解问题、管理版本、验证预期等工程化思维，反而变得更加重要。

“只要你懂得用自己的专业眼光发现问题，用工程化思维拆解它，再用自然语言‘聊’出属于你的那一个软件。”

为什么AI要听我的？

“助教真的非常用心，他们甚至会把每一步操作都演示出来，我们跟着做。哪一步卡住了，群里问一下，很快就有回复。”管理学院23级本科生曾悦说。

这门课除了3位授课教师，还配备了2位助教。助教徐宸是计算与智能创新学院的研究生，研究方向正是AI辅助软件开发。从开课前两个月开始，他和另一位助教陈董祺就投入到Lab制作、demo开发中。“最难的是怎么从非专业同学的视角去理解问题。”徐宸说。

实验作业会匹配课程进度不断进阶，并配有详细注解

每周的实验课上，助教会帮助同学先梳理知识点、演示demo，随后同学们动手完成当周任务，有问题随时提问，现场解决。

有一次，一位同学提问：“为什么我的代码写完了，但跑起来是白屏？”徐宸发现代码本身没问题，但那位同学不知道如何启动一个网页，团队通过设置实践课课，手把手教大家怎么部署、怎么运行。

还有同学问：“为什么AI要听从一个比它能力还差的人去指挥？”助教们从AI的原理解释：大模型本质是一个“下一个词预测器”，没有意识，不会嫌弃你，也不会自作主张。正因为如此，你需要学会正确指挥它。

陈董祺在批改作业时发现一位同学做了一个仿Windows 98风格的网页应用，界面精致，甚至有桌面宠物元素。“这种创意，我们计算机专业的同学反而很难想到。不同学科的碰撞真的很有趣。”

从跟AI瞎聊到跟AI合作

学期接近尾声，同学们的变化很明显。

曾悦以前只学过一点Python基础，勉强能读懂代码但写不出来。上了这门课后，她给上小学的妹妹做了一个英语学习网页，有点击、有积分、有奖励机制。“虽然还比较基础，但妹妹在用，她觉得很新鲜。”

数学科学学院23级本科生任昊来上课前习惯“古法编程”，经常遇到上下文管理等问题，近期项目式开发环境的方法也不太熟悉。几次课程实践与课后讨论下来，他在Agent Harness Engineering环境下感受到了明显变化。“现在自己修改的代码部分少了很多，验证想法的速度变快了，工程落地的效率提升了不少。”

廖书伦则有更深的体会：“我最大的收获是一套工程化的思维方法。以前做事容易想到哪做到哪，现在会先拆问题、做规划、分步骤推进。这对我的社科研究也很有启发。”他正在自己动手做一个轻量级应用，有登录注册、用户数据存储、大模型API调用。

张天戈也观察到，一位临床医学五年制的同学，遇到问题后自己把故障层层剥离，定位到最小的可测试单元，再找他确认。“我当场表扬了她，她的模式已经非常工程化了。”

当AI抽掉了梯子

你可以自己搭一个新的

在一次教学分享会上，彭鑫提出一个观点：AI正在抽掉能力成长的梯子。过去，学生从小任务做起，一点一滴积累，在痛苦中获得能力。现在，AI可以代劳几乎所有“低阶”工作，学生很容易被架空。

虽然这个观点针对的是计算机和软件工程专业的学生，但在这门课上，这个问题的答案有了另一种可能。

“AI抽掉的是旧的梯子，但你可以用它来搭一个新的。你不必从头学习编程的每一个细节，但你要学会拆问题、做规划、验证结果、迭代优化。这些能力，在任何专业领域都是最值钱的。”

这门课是今年第一次开设，没有现成教材，没有可借鉴的教案。课件几乎是“每周上课前一周还在更新、调整”。“我们是边讲边摸索，边看学生反应边调整。”彭鑫说。

让他意外的是，学生对这门课的接受度非常高。50多个选课名额很快报满，还有外校的老师每周来“蹲守”课件。

“工程化思维也是可以跨专业迁移的。”吴毅坚补充，选修课程的留学生在语言不完全通的情况下也能跟上增量迭代思路，有修经济金融的同学将课程方法用于专业数据挖掘讨论。

第一轮授课即将结束，团队也在总结经验。

“通过学期初的调研问卷与同学们的课堂反馈来看，很多同学对自己的专业领域里有哪些可以信息化、智能化的需求，并不清楚。”吴毅坚在最近的一次课上，花了一些时间和同学们做交流，了解每个人想做的具体应用。

因此，明年的课程计划增加“需求挖掘”环节，帮助同学们结合自己的专业，找到真正值得做的项目。“这有点像产品经理的工作：先不管怎么做，挖掘一下自己的领域里有哪些地方可以借助AI提高效率、改善质量。”彭鑫说。

彭鑫还发现，非专业同学与AI协作是否高效，取决于是否具备基本信息化素养，比如知晓模态窗口、分组排序等术语。“未来，我们也考虑在前序中加入信息化素养模块。”

正如廖书伦在课后评价中所说：“人人都是程序员，这件事取决于你这个人本身。你聊出来的软件有多厉害，实际上是你自己有多厉害。”

组稿：校融媒体中心

文字：赵天润

摄影：梅旭普张琪

编辑：高康珵

责编：赵天润

联系邮箱：Fudan_media@fudan.edu.cn

推荐阅读

<< 左右滑动查看栏目 >>

教你摸骨头？这门复旦“金课”不一般

复旦全英文人工智能微专业，教什么？

阅读原文

跳转微信打开

一图胜言：系统复杂性才是AI Coding的分水岭

Sun, 07 Jun 2026 20:36:00 +0800

CodeWisdom 2026-06-07 20:36 上海

一图概括彭鑫老师最新报告《复杂系统视角下的软件智能化开发机遇与挑战》中心思想

上图概括了彭鑫老师最新报告《复杂系统视角下的软件智能化开发机遇与挑战》的中心思想。相关内容详见彭鑫老师系列公众号文章：

敬畏与驾驭：系统复杂性视角下的软件智能化研发体系演进

敬畏系统复杂性：写给AI辅助开发的2025年度总结

从“贫嘴张大民的小屋”说起：再论软件开发的系统复杂性

代码数字孪生：回归软件的复杂系统属性

大模型时代的软件智能化开发：我们在哪里？该往何处走？

感谢Agentic AICon组织方供图！

跳转微信打开

模型供应链风险初探：依赖、演化、质量与风险传播的首次全景扫描

Sat, 06 Jun 2026 16:53:00 +0800

CodeWisdom 2026-06-06 16:53 上海

百万级模型的复杂供应链背后的元数据缺失、依赖关系隐形，正加剧供应链风险的传播。

1.研究背景：模型供应链正在成为

AI 时代新的风险入口

近年来，以 Hugging Face 为代表的模型权重开放平台的兴起，极大降低了开源模型的复用门槛。开发者可以直接基于已有模型进行微调、量化、合并，或通过 LoRA 等参数高效微调方式快速生成衍生模型。一个基础模型可以被成千上万个下游模型复用，而下游模型又可能进一步成为新的基础模型被再次复用，由此形成了复杂的、动态的、持续扩张的模型供应链。与传统软件供应链相比，模型供应链的风险更加隐蔽：软件复用通常以明确的包导入和版本约束为载体，而模型复用则往往伴随着权重继承、训练数据混入、行为迁移乃至安全对齐的改变。下游模型不仅复用了上游模型的能力，更可能在无意间继承其性能缺陷、许可证限制，乃至幻觉、越狱和提示注入等安全风险。这些风险往往随依赖关系的建立而悄然传递，难以被检测和溯源。

面对如此错综复杂的模型依赖图谱，当前学界对模型供应链的认识却仍停留在局部视角。已有研究分别关注过模型数量的爆炸式增长 [1,2]、Hugging Face模型文档（Model Cards）的质量 [3,4]、模型更新历史 [5]，以及特定类型的风险传播 [6,7,8]，但这些工作往往局限于单一维度或孤立场景，始终未能回答一个更根本的问题：在今天的开源模型生态中，模型如何相互依赖、如何随时间演化、模型文档是否可信。这些依赖演化关系与数据质量问题最终如何影响模型风险传播？

针对上述问题，复旦大学 CodeWisdom 团队的软件供应链安全小组围绕模型供应链风险治理展开了初步探索，构建了首个覆盖Hugging Face全平台的模型供应链图谱，并从风险视角开展了系统的实证分析。相关研究成果录用于 ICSE 2026 [9]。

研究对象：Hugging Face百万级模型与

五十余万条依赖关系

我们以Hugging Face上的全量开源模型为研究对象，爬取了截至2025 年 6 月 25日的1,817,398个开源模型的模型文档。随后解析模型卡中的依赖字段，抽取模型之间的衍生关系，最终识别出 540,838条模型依赖关系。我们将模型依赖定义为三元组：基础模型、衍生模型和依赖类型（即基础模型通过某种依赖类型产生了衍生模型）。其中，Hugging Face 原始支持的依赖类型包括 Quantize、Merge、Fine-Tune 和 Adapter。由于 Adapter 本质上是一种参数高效微调，我们将其归并到 Fine-Tune 中，最终聚焦三类主流依赖类型：Fine-Tune、Quantize和Merge。

从整体分布来看，约 68.9% 的模型是孤立模型，也就是没有在模型卡片中显式声明依赖关系；但这些孤立模型只贡献了约 12% 的下载量。相反，存在依赖关系的模型数量虽然只占约31.1%，却贡献了约88%的下载量。这说明真实用户高度集中在模型供应链中的“关键节点”上，少数被大量复用的基础模型决定了整个生态的稳定性和可信性。

表一模型任务与依赖类型的分布统计

在所有衍生模型中，微调是最主要的复用方式，占比约79.0%；量化模型占比约18.6%；合并模型占比约2.4%。如表一所示，从模型任务类型看，NLP模型在三类依赖类型中均占主导地位，尤其是在合并和量化关系中，NLP相关模型占比均超过90%。这种以NLP为核心的依赖结构意味着，一旦某个高度被复用的NLP基础模型存在安全隐患，其影响将沿依赖链向大量下游模型扩散。因此，大语言模型及文本生成模型是模型供应链风险治理中需优先关注的领域。

研究问题一：模型在供应链中如何被复用？

我们从三个递进层次分析模型的复用结构：依赖关系、依赖链和依赖簇。依赖关系刻画两个模型之间的单次复用操作；依赖链描述多个依赖关系串联形成的多跳路径；依赖簇则聚合以同一根模型为起点的全部衍生模型，呈现完整的模型家族视图。

表二头部模型的出入度

在依赖关系层面，基础模型的出度分布高度集中。如表二所示，Qwen/Qwen1.5-0.5B拥有32,497个下游衍生模型，是出度最高的基础模型。部分模型则通过多次合并积累了极高的入度，成为"多源汇聚点"。这些高出度和高入度模型分别是供应链的"核心源"与"复杂汇点"，一旦存在安全隐患，影响范围将极为广泛。

表三头部模型链的使用情况

在依赖链层面，我们识别出 1,008,871 条模型依赖链，平均链长为6，其中60.8%的链长度超过2。如表三所示，最长链甚至达到40跳。这说明模型复用并不是简单的一次性复用，而是大量存在多阶段、多操作的连续演化过程。一个模型今天可能只是下游产物，明天又可能成为新的上游模型。

表四头部模型簇的使用情况

在依赖簇层面，我们识别出25,184个模型簇。大多数模型簇较小，但少数头部基础模型形成了庞大的模型家族。如表四所示，前十大模型簇合计包含173,593个模型，约占所有关系模型的30.7%。这些大型簇主要由NLP基础模型驱动，也正是最需要持续监控和治理的关键区域。

核心发现：

模型供应链并不是松散的模型集合，而是由少数高影响力基础模型、深层依赖链和大型模型簇共同构成的复杂网络。治理模型供应链，须以高出度基础模型和大型簇根节点为优先对象，同时建立深链溯源机制以应对多跳风险传播。

研究问题二：模型供应链如何演化？

为刻画模型供应链的动态变化，我们在2025年3月12日至7月2日期间每周抓取一次Hugging Face快照，共17个快照，系统分析模型的新增、删除与更新行为。

在新增层面，平台平均每周新增27,311个模型，其中72.1%为孤立模型，27.9%为存在依赖关系的模型（即关系模型）。在新增的关系模型中，绝大多数为衍生模型，微调仍是驱动关系模型增长的主要操作。
在删除层面，平均每周有6,190个模型被删除，规模虽远小于新增，但其影响往往被低估。每周平均有127个被删除模型曾作为基础模型，直接导致299个下游模型失去可追溯的上游依赖，并扰动1,440条依赖链和78个模型簇。基础模型的删除会破坏下游的可追溯性，进而影响实验复现、许可证合规和安全审计。
在更新层面，通过commit记录我们发现145,445个模型（约8.0%）在观察窗口内发生过实质性更新，但仅有1,899个（约0.1%）在模型文档中使用newer_version字段记录了版本变更。这意味着绝大多数更新对下游用户而言完全透明，即无法得知上游模型是否已变更，更无从判断变更是否引入了新的性能缺陷或安全隐患。

核心发现：

模型供应链正在高速扩张，但演化过程严重缺乏透明度。删除在上游静默地制造断链，更新在不通知下游的情况下改变模型行为，二者共同形成模型供应链的"变更盲区"。下游用户既难以感知上游的变化，也难以及时响应由此引发的风险。

研究问题三：模型元数据质量如何？

模型供应链的可信性，很大程度上依赖于模型文档元数据的完整性与准确性。我们聚焦风险影响最广的 text-generation 模型，从下载量前 10% 的 24,686 个高影响力模型中统计抽样 378 个，人工核查五类对安全与合规至关重要的字段：许可证、性能指标、提示模板、训练数据集、依赖关系。

在字段完整性层面，缺失问题十分普遍且后果严重。82.8% 的模型缺少性能指标，用户无从评估其是否满足精度或延迟要求；28.3% 的模型缺少许可证，下游用户面临无法判断商业可用性的合规风险；在需要提示模板的模型中，33.8% 未提供提示模板，用户可能因此误用模型或难以防御提示注入攻击；在理应声明训练数据集的模型中，76.8% 未给出来源，使数据偏差审计和隐私合规几乎无从开展。

依赖关系字段则呈现出独特的"高精度、低召回"问题。已声明的依赖关系正确率高达 97.2%，说明主动填写的开发者通常较为负责；然而，大量真实存在依赖关系的衍生模型根本没有声明依赖，导致召回率仅有 68.5%，这意味着约三分之一的衍生模型在供应链中完全"隐形"，无法被追踪或审计。

综合来看，378 个抽样模型中有 96.0% 至少存在一个关键字段缺失或错误，80.2% 至少存在两处问题，45.5% 存在三处及以上。这并非个别现象，而是系统性的质量缺失。

核心发现：

模型元数据并非可有可无的说明文档，而是供应链治理的基础设施。许可证缺失造成合规盲区，性能信息缺失妨碍选型决策，数据集信息缺失阻碍偏差与隐私审计，依赖关系缺失则直接切断了供应链的溯源脉络。元数据质量已成为模型供应链治理的底层瓶颈

研究问题四：风险如何沿着模型依赖链传播？

在风险分析方面，我们关注三类与大模型应用密切相关的风险指标：幻觉率、越狱成功率和提示注入成功率。我们选取105条高下载量的真实依赖关系，覆盖微调、量化和合并三类操作，并使用已有公开基准分别评估基础模型和衍生模型的风险差异。

（一）微调：SFT 可能放大提示注入风险，PEFT 更稳定

对于微调关系，我们进一步区分了全参数监督微调（SFT）、参数高效微调（PEFT）以及其他微调方式。如图一所示，SFT 的风险变化幅度最大，也最不稳定。虽然 SFT 在部分情况下会降低幻觉率，但它明显倾向于放大提示注入风险，提示注入成功率差值的中位数达到 0.22。相比之下，PEFT 对三类风险的影响整体更小，幻觉、越狱和提示注入风险大多围绕零附近变化。这说明在安全和稳定性优先的应用场景中，PEFT 可能是更稳妥的模型适配方式；而如果选择 SFT 追求任务性能提升，就需要额外进行风险评估和缓解。

图一微调操作下风险传播情况

（二）量化：低比特量化节省成本，但可能提高幻觉风险

对于量化关系，我们分析了基础模型及其 2-bit、4-bit、8-bit 量化版本的风险变化。从图二来看，8-bit 和 4-bit 量化模型通常与基础模型风险接近，而更激进的低比特量化，尤其是 2-bit，可能带来更明显的幻觉风险变化。这说明量化并不只是压缩模型大小的工程优化，它也可能改变模型行为。对于资源受限设备或高可靠性场景，开发者不能只关注显存占用和推理速度，还需要同时评估低比特量化对安全性和可靠性的影响。

图二量化操作下风险传播情况

（三）模型合并：风险不是简单平均，而可能向某个基础模型靠拢

对于模型合并关系，我们发现合并模型的风险表现并不是多个基础模型风险的简单平均。相反，如图三所示，合并后的模型往往会在某些风险维度上接近其中一个基础模型的极端值，呈现出“赢家通吃”或“输家拖累”的现象。这意味着开发者在进行模型合并时，不能仅仅查看每个基础模型的平均风险水平，也不能假设合并会自动中和风险。只要某个基础模型在幻觉、越狱或提示注入方面存在明显问题，合并结果就可能继承甚至表现出相近风险。因此，模型合并前后的独立风险评估非常必要。

图三模型合并操作下风险传播情况

研究启示：面向各方利益相关者的模型

供应链治理建议

我们不仅给出了大规模实证结果，也进一步提出了面向不同参与者的治理启示。

对于上游模型维护者，应当将模型视为整条供应树的根节点，而不仅是单个仓库。高出度基础模型需要更严格的版本管理、许可证声明、性能记录、风险评估和变更日志。一个基础模型的静默更新或删除，可能影响大量下游模型。
对于下游模型消费者，不能默认衍生模型继承了基础模型的全部优点，也不能默认风险保持不变。选择微调、量化或合并策略时，应同时考虑性能、成本、安全和可追溯性，并在发布前对幻觉、越狱和提示注入等风险进行测试。
对于模型平台设计者，应当进一步完善模型文档和依赖声明机制。例如，平台可以扩展依赖类型，支持剪枝、格式转换、蒸馏等真实存在的操作；引入模型物料清单（Model Bill of Materials），记录历史版本、许可证、依赖关系、性能指标和风险指标；同时建立类似 npm shrinkwrap 的依赖锁定机制，降低上游模型删除或静默更新对下游造成的影响。
对于研究者，未来可以围绕依赖关系自动恢复、风险传播预测、模型供应链治理指标、平台级监控工具等方向展开进一步研究。尤其是在依赖字段大量缺失的现实条件下，如何通过模型权重、结构、元数据和行为特征恢复真实依赖关系，将成为构建可信模型生态的重要基础。

总结

本研究首次在百万级规模上系统刻画了开源模型供应链的使用结构、演化规律、元数据质量与风险传播模式，揭示了一个高度集中、快速扩张却严重缺乏透明度的复杂依赖生态。复旦大学CodeWisdom团队的软件供应链安全小组将以此为起点，持续探索模型依赖关系的自动识别、供应链风险的量化建模、风险检测与缓解，以及面向大模型时代供应链治理规范与工具体系的构建，推动模型生态从"能用"走向"可信、可审计、可治理"。

参考文献

[1] Joel Castaño, et al. “Analyzing the evolution and maintenance of ml models on hugging face.” Proceedings of MSR 2024.

[2] Jason Jones, et al. “What do we know about Hugging Face? A systematic literature review and quantitative validation of qualitative claims.” Proceedings of ESEM 2024.

[3] Adhishree Kathikar, et al. “Assessing the vulnerabilities of the open-source artificial intelligence (ai) landscape: A large-scale analysis of the hugging face platform.” Proceedings of ISI 2023.

[4] Zhou Yang,et al. “Ecosystem of large language models for code.” ACM TOSEM 2024.

[5] Joel Castaño, et al.“How do machine learning models change?” arXiv preprint 2024.

[6] Pin-Yu Chen et al. “Safety Risks in Fine-Tuning Large Language Models”. Introduction to Foundation Models. Springer 2024.

[7] Zhen Sun, et al. “PEFTGuard: detecting backdoor attacks against parameter-efficient fine-tuning.” Proceedings of IEEE S&P 2025.

[8] Jinghuai Zhang, et al. “Badmerging: Backdoor attacks against model merging.” Proceedings of CCS 2024.

[9] Ziqian Chen, et al. “A First Look at Model Supply Chain: From the Risk Perspective.” Proceedings of ICSE 2026.

本文作者

陈子谦

复旦大学

复旦大学CodeWisdom团队软件供应链安全小组硕士生，导师为陈碧欢，研究方向为大模型供应链安全。

吴苏晟

复旦大学

复旦大学CodeWisdom团队软件供应链安全小组博士生，导师为陈碧欢，主要研究方向为软件供应链安全、大模型供应链安全，部分成果在企业内部落地。

跳转微信打开

基于大语言模型的故障复现测试用例生成方法 | jos佳文

Fri, 29 May 2026 20:30:00 +0800

CodeWisdom 2026-05-29 20:30 上海

汪莹, 字千成, 彭鑫, 娄一翎：基于大语言模型的故障复现测试用例生成方法

文章题目: 基于大语言模型的故障复现测试用例生成方法

全部作者: 汪莹, 字千成, 彭鑫, 娄一翎

第一单位: 复旦大学计算机科学技术学院

出版时间: 2026, 37(4): 1690–1714

摘

要

ABSTRACT

ABSTRACT

GitHub是目前最流行的开源项目管理平台之一. 由于团队协作的需要, GitHub引入了问题报告跟踪功能以方便项目使用者提交和追踪项目中出现的问题或新功能请求. 问题报告贡献者在解决问题报告时, 通常需要执行故障复现测试用例来复现问题报告中提到的问题并验证问题报告是否解决. 然而, 在SWE-bench Lite数据集上进行实证研究发现, 有近90%的问题报告在用户提交时没有附带故障复现测试用例, 这导致问题报告贡献者在解决问题报告时还需额外编写故障复现测试用例, 带来了额外的工作负担. 现有的故障复现测试用例生成技术通常依赖错误栈信息, 然而GitHub问题报告中并未明确要求有这类信息. 因此, 提出基于大语言模型的故障复现测试用例生成方法, 旨在自动化地为GitHub问题报告生成故障复现测试用例, 帮助问题报告贡献者复现、理解并验证问题报告, 提升问题报告解决效率. 该方法首先通过检索与问题报告相关的多样化代码上下文信息, 包括报错根函数、import语句和测试用例样本, 随后构建精确的prompt, 以引导大语言模型生成有效的故障复现测试用例. 开展对比实验和消融实验, 验证所提方法在面向GitHub问题报告的故障复现测试用例生成任务上的有效性.

扫码阅读全文

内

容

精

选

CONTENT

CONTENT

1 方法概述

本文提出了一种基于大语言模型和多元检索增强生成的故障复现测试用例生成方法, 旨在为GitHub问题报告等类似的软件开发问题生成故障复现测试用例. 该方法的核心思想是基于给定的问题报告内容和代码仓库, 挖掘多元的上下文信息, 包括报错根函数、import语句和测试用例样本等, 通过使用提示工程技术, 构建prompt来引导大语言模型生成故障复现测试用例. 图1展示方法的框架.

图1 基于大语言模型和多元检索增强生成的故障复现测试用例生成方法框架图

① 报错根函数定位

本文将报错调用链中最后一个在代码仓库中的函数定义为报错根函数. 如图2所示, 展示了Django仓库的一个问题报告描述, 其中包含了相关的错误栈信息. 基于启发式经验, 本文认为只有在问题报告所在仓库中的函数才可能是导致问题的原因, 因此不考虑第三方库调用的函数.

图2 GitHub问题报告描述中错误栈举例图

本文采用基于规则的方法来实现报错根函数的定位, 分为两步: 抽取报错根函数信息和根函数定位.

在抽取报错根函数信息阶段, 首先使用字符串处理方法识别问题报告描述中的“Traceback”字符串, 以判断是否包含错误栈信息, 并提取所有相关的错误栈内容. 接着, 利用正则表达式逐行解析错误栈, 提取每一行中的报错文件、报错代码行和报错函数信息. 最后, 过滤掉第三方库调用的函数, 仅保留最后一个报错函数作为报错根函数.
在根函数定位阶段, 首先将问题报告所在的仓库克隆到本地, 并根据该问题报告的 base_commit信息切换到问题报告提出时的版本. 随后, 使用tree-sitter工具, 根据抽取出的报错文件和报错根函数名, 提取报错根函数的内容. 如图3所示, 后续将用于构建 prompt, 为大语言模型提供问题报告的报错信息.

图3 报错根函数定位示意图

② 测试文件选择与import语句抽取

本文设计了测试文件选择与import语句抽取的方法, 旨在通过检索与问题报告最相关的测试文件, 充分利用其中的现有信息, 从而提升大语言模型的故障复现测试用例生成效果.

(1) 测试文件选择

为了避免将代码文件错误地抽取出来, 本文为每个代码仓库人工设计了一套测试文件判断规则, 如表1所示. 基于这些规则, 本文遍历每个代码仓库中的所有Python文件, 抽取出所有符合条件的测试文件路径.

表1 SWE-bench Lite数据集中各个代码仓库测试文件判断规则

在prompt构建阶段, 本文决定仅将问题报告标题作为依据, 避免将所有描述信息纳入prompt, 以提升测试文件选择的准确率. 具体而言, 本文将GitHub问题报告的标题与经过截取的测试文件路径列表作为输入, 结合适当的提示信息, 构建结构化的prompt.

图4展示了一个具体的测试文件选择prompt的例子. 本文首先对Django仓库的所有测试文件进行了抽取, 并对每个测试文件的路径进行了截取处理, 将保留后的路径信息以列表形式嵌入到prompt中. 大语言模型在接收到该prompt后, 成功选择了正确答案. 这一结果不仅验证了大语言模型在处理粗粒度文件检索任务时的有效性, 也展示了通过合适的prompt设计, 可以显著提高模型的选择准确性.

图4 测试文件选择prompt示意图

(2) import语句抽取

故障复现测试用例生成任务面临的一个主要挑战在于, 输入的上下文是整个代码仓库, 这往往导致上下文信息过长, 使得大语言模型在理解整个文件结构时变得困难. 这种情况下, 模型可能无法正确调用仓库中已有的API接口, 从而影响生成故障复现测试用例的质量. 为了解决这一问题, 本文在选择出最可能测试给定问题报告的测试文件后, 特别提取了该测试文件中的import语句.

这一做法的双重目的在于:

提供给大语言模型可能使用的API信息, 增强其调用的准确性;
通过分析import语句中的引用路径, 帮助模型更好地理解代码仓库的结构和关系

在图4的基础上, 本文利用正则表达式匹配技术成功抽取了该测试文件中的所有import语句, 如图5所示. 在大语言模型生成故障复现测试用例后, 本文只需在该测试文件的相同路径下创建一个新的测试文件, 将生成的故障复现测试用例放入其中. 由于已抽取的import语句包含了所需的API, 这样的处理避免了潜在的语法错误. 本文通过这一方式, 旨在降低大语言模型在生成故障复现测试用例时出现的API调用语法错误, 从而提高故障复现测试用例生成的准确性和有效性.

图5 import语句抽取结果示意图

③ 基于相似度计算的测试用例样本选取

在选出最可能测试给定问题报告的测试文件后, 本文采用基于相似度计算的方法在该测试文件中选取测试用例样本, 旨在从已有的代码仓库中检索出与测试给定问题报告相关的测试函数. 该方法具体分为两个主要步骤:

测试函数的抽取. 首先, 将大语言模型选择出的截取后的测试文件路径还原为完整路径, 并根据问题报告的base_commit信息将克隆后的代码仓库恢复到问题报告提出时的版本. 然后, 根据还原后的文件路径定位到相应的测试文件, 并将该文件的全部内容读取为一个字符串. 获得测试文件中的完整代码后, 通过分析各个代码段的节点属性, 成功提取出测试文件中所有的测试函数. 这些提取的函数片段将以字符串列表的形式保存, 便于后续的相似度计算与排序过程.
基于相似度计算的测试用例样本选取. 本文采用稠密检索方法中的基于embedding的相似度计算. 具体而言, 对抽取出的每个测试函数的代码字符串与问题报告标题之间计算embedding相似度得分. 根据这些相似度得分, 对抽取出的测试函数进行排序, 最终选取得分最高的3个测试函数作为测试用例样本.

图6展示了本文抽取的测试用例样本, 将所有测试函数与问题报告标题进行了embedding相似度计算, 最终得分最高的3个测试函数见图6.

图6 测试用例样本示意图

④ 故障复现测试用例生成

在设计prompt时, 本文采用了多种提示工程领域的策略, 以提升大语言模型的理解能力和生成质量. 如prompt 2所示.

首先, 本文将prompt设计为结构化形式, 这样能够更清晰地描述多个方面的内容, 增强模型对问题的理解.
其次, 本文采用了few-shot方法, 通过在prompt中提供与期望输出类似的例子, 帮助大语言模型更好地理解需求, 从而生成高质量的结果.
此外, 本文还运用了大语言模型角色扮演策略, 明确告诉模型它是一位软件测试专家, 擅长根据需求生成故障复现测试函数, 通过这种角色设定来挖掘模型的潜在能力.
最后, prompt中还运用了思维链方法, 将故障复现测试用例生成这一复杂任务拆分为4个步骤: 理解问题的主要内容、分析造成问题的原因、思考预期的正常表现及其测试方式, 最终生成故障复现测试用例.

2 实验分析

本文将围绕以下3个问题展开实验验证.

RQ1: 本文提出的方法是否优于现有方法?
RQ2: 本文方法中检索增强生成的 3 部分内容各自的作用如何?
RQ3: 本文检索增强生成的内容准确性如何?

① 测试用例生成效果对比 (RQ1)

表2详细展示了对比实验结果. 针对SWE-bench Lite数据集中的300个GitHub问题报告, 实验结果表明, 基于给定问题报告检索报错根函数、import语句和测试用例样本等内容的方法是有效的, 进一步证明了本文方法的有效性.

表2 本文方法与Libro方法的故障复现测试用例生成评估指标对比

② 消融实验 (RQ2)

本文在使用检索增强生成策略时共检索了3部分内容, 包括报错根函数、import语句和测试用例样本. 消融实验结果如表3所示. 这些结果表明, 本文检索增强生成的3部分内容对故障复现测试用例生成均发挥了积极作用, 且其中测试用例样本的贡献最大.

表3 消融实验结果

本文观察到, 在某些情况下, 去除报错根函数的方法效果优于本文提出的方法. 该结果表明, 基于GitHub问题报告中的错误栈信息抽取报错根函数可能会误导大语言模型, 从而降低其测试用例生成的效果. 这进一步说明, GitHub问题报告中的错误栈根函数信息可能并不总是导致问题的根本原因, 反映出了GitHub问题报告的复杂性.

③ 检索增强生成内容准确性分析 (RQ3)

表4展示了本文在SWE-bench Lite数据集中检索测试文件和测试用例样本的准确性结果. 这些结果反映出本文检索方法的有效性, 能够为给定问题报告提供相关的代码上下文信息, 从而提升大语言模型对问题报告的理解能力, 进而增强故障复现测试用例的生成效果.

表4 检索到的测试文件和测试用例样本准确性结果

3 总结与展望

本文通过实证研究发现, 当前GitHub问题报告中普遍存在故障复现测试用例不足的问题, 导致开发者在提交解决问题报告的代码补丁时, 还需额外提交用于复现问题报告并验证问题报告是否解决的测试用例补丁, 从而增加了开发者的工作负担. 为了解决这一问题, 本文提出了一种结合大语言模型和检索增强生成的故障复现测试用例生成方法. 该方法首先通过检索与问题报告相关的多元代码上下文信息, 包括报错根函数、import语句和测试用例样本, 随后构建精确的prompt, 以引导模型生成有效的故障复现测试用例. 在与现有的Libro方法进行对比实验时, 本文的方法显著优于Libro, 成功生成故障复现测试用例的问题报告比例从6.57%提升至22.33%. 此外, 消融实验进一步表明, 本文检索增强生成的3部分内容对故障复现测试用例生成均发挥了积极作用, 其中测试用例样本的贡献最大. 尽管本文方法在故障复现测试用例生成任务中展现了有效性, 但仍有改进空间, 未来的展望如下.

(1) 提升方法的有效性. 未来可以挖掘更多有价值的信息, 当面对项目中测试函数样本不足的情况时, 可以检索其他与问题报告相关的上下文信息, 包括代码注释、项目历史提交记录、开发者评论以及项目文档等, 为大语言模型提供更丰富的背景信息和开发者意图, 从而提升故障复现测试用例的生成质量. 同时, 可以优化检索策略, 以提高检索内容的准确性, 从而更好地辅助模型理解问题报告, 提升故障复现测试用例生成效果.

(2) 提升方法的通用性. 未来, 可以考虑将本文方法扩展到其他编程语言的GitHub问题报告, 例如Java、C、C++等. 此外, 本文的方法也可考虑应用于本地代码仓库中, 用户只需提交问题报告描述和代码仓库路径, 便可自动生成故障复现测试用例.

(3) 提升方法的可解释性. 未来可以考虑在生成故障复现测试用例的同时, 让模型解释测试用例的信息来源及其与问题报告的关联. 此外, 还可以考虑建立用户反馈机制, 允许用户对生成的测试用例进行评价与反馈, 增强用户对测试用例的理解和信任.

作

者

简

介

AUTHOR

AUTHOR

汪莹, 硕士生, 主要研究领域为智能化软件开发.

字千成, 硕士生, 主要研究领域为智能化软件开发.

彭鑫, 博士, 教授, 博士生导师, CCF 杰出会员, 主要研究领域为智能化软件开发, 云原生与智能化运维, 泛在计算软件系统.

娄一翎, 博士, 副研究员, 主要研究领域为智能化软件工程, 软件测试与分析.

跳转微信打开

AI软件工程范式革命的思考

Thu, 28 May 2026 13:41:00 +0800

hadeswang 2026-05-28 13:41 上海

以下文章来源于：茹炳晟聊软件研发

茹炳晟聊软件研发

关注软件研发行业效能提升与质量提升的工程实践，普及研发效能宣言的价值观、最佳实践与工程落地案例

过去五十年，软件工程一直在"管理人的不确定性"，但从未真正工程化过。大模型让"用能源换取高阶智能"第一次成为可能。

导语这篇文章想讨论一件事：软件工程过去五十年其实没真正"工程化"过。它一直停留在手工艺阶段，被各种方法论包装成工程，但骨子里还是靠人脑堆。这一点直到大模型出现才开始有可能改变。我会沿着这条思路往下推：先回看其他工程门类是怎么"工程化"成功的，再看软件这条路为什么走不通；然后讨论大模型把哪一块缺口补上了，又带来了什么新的麻烦；接着是当下业界普遍在走的弯路，以及我认为正确的路径长什么样；最后落到落地路线、组织形态，以及这件事真正最难的那道坎在哪里。整篇文章是一次完整推演，不是工具评测，不是预测，更像是把很多年里零散的想法串成一条逻辑线。

一、为什么说软件工程是过去五十年最不彻底的工程

1.1 经典工程的胜利路径，其实是同一条

机械、化工、电力、自动化、通讯，这些工程门类长得天差地别，但翻它们的工程史会发现一个共同点：它们都靠"消耗能源把人脑参与的低阶认知回路固化成物理装置"成功的。

蒸汽机的离心调速器、化工厂的恒温器和压力调节器、电网的调度装置、流水线上的 PLC——本质上都是同一件事：让原本要靠人盯着、调整、判断的事情，由一台烧煤或者通电的设备自己完成。人从主回路里被剥离出来，退到设计、维护、维修这些位置。

这就是控制论最早的工程实现路径。它的核心结果不是"省了几个工人"，而是不确定性被大规模消除——同样的输入、同样的能源，输出是稳定可预期的。

工程门类	把哪种"低阶智能"固化成了能源装置	人退到哪里
蒸汽机	离心调速器（机械负反馈）	设计与维护
化工	恒温器、压力调节器	工艺设计
电力	电网调度系统	调度仲裁
自动化	PLC、流水线控制器	产线规划

经典工程的"成功"，秘密不在某项技术，而在这套"能源换低阶智能"的范式本身。

1.2 软件工程恰好卡在这条路走不通的地方

把这套范式套到软件上就会发现卡壳了。软件开发要做的事情是抽象、分解、推理、创造——这些都是高阶认知，没法像调速器那样固化成一个物理回路。代码是用人的思维一行一行编出来的，编译器只是忠实地翻译，从不"理解"需求。

所以软件工程一直没法做到"投入能源，另一头流出可工作的软件"这件事。它必须靠大量高密度的人力。而人脑这个认知主体有几个绕不过去的毛病：会误解、会遗漏、不一致。需求从用户口里说出来，传到产品经理，再传到开发，每一道都失真；状态空间稍微复杂一点，单个人的注意力就盖不全；同样一件事，张三和李四的处理方式可能完全不同。

软件危机的本质就是这件事——不是哪个技术不行，而是这个工程门类的认知主体始终是人脑，而人脑在这套生产关系里没法被替换。

1.3 历代方法论其实都在做同一件事：管理人，而不是替代人

把过去五十年的软件工程方法论摊开看，结构化编程、面向对象、敏捷、Scrum、DevOps——它们解决的是同一个问题，而且解决方式是同一种：优化堆人力的方式，但没改变"必须靠人力堆"这个事实。

敏捷拥抱变化，DevOps 缩短反馈环，Scrum 把大目标切成小迭代，本质都是承认"人是不可替代的不确定性来源"，然后想办法让这种不确定性更可管理。

这就是为什么我会说软件工程是过去五十年里最不彻底的工程——所有兄弟门类都完成了"能源替代低阶智能"这个动作，唯独软件没有。它在工程的形而上学层面是个残缺品。

1.4 但过去五十年并不是白费的

说这话有个必须澄清的地方："软件工程是失败的"不等于"过去五十年的所有努力都白搭了"。

恰恰相反，这五十年沉淀下来一整套东西——编译器、类型系统、单元测试、CI/CD、灰度发布、契约编程、形式化方法、静态分析、覆盖率、监控、链路追踪。这套东西虽然没让软件工程"工程化"成功，但它们留下了一个非常关键的资产：一整套自动化验证基础设施。

这件事到了第六章会再出现，因为它正好是新范式的地基。某种意义上，过去五十年的"失败"是给下一个时代准备弹药——只是当时谁也不知道。

二、大模型补上了那个缺口，但带来了新麻烦

2.1 大模型这件事的工程史定位

大语言模型不是 AGI，但它做到了一件经典工程从来没做到的事：输入电力（最终是算力），输出能理解需求、生成代码、做逻辑推理的高阶认知产物。

把这件事放到工程史的坐标里看就很清楚了：

经典工程：能源→低阶智能（机械调节、自动控制）大模型：能源→高阶智能（理解、推理、生成、决策）

工程史上第一次有了"认知引擎"这种东西。我说"引擎"不是修辞——它和蒸汽机的工程史地位是平行的。蒸汽机让"做功"这件事第一次能源化，大模型让"认知"这件事第一次能源化。

如果上面的判断成立，那软件工程"真正降临"的时刻不是 SCRUM 流行的时候，不是 DevOps 普及的时候，也不是云原生铺开的时候——是大模型让"能源换高阶智能"成为可能的时候。在此之前所有的"软件工程"，严格说都是软件作坊的优化版。

2.2 但这只是入场券，不是终局

大模型本身带着一堆高阶的不确定性。幻觉——输出看着合理，悄悄就错了；漂移——同样的输入，今天和明天给出不一样的结果；不可解释——你没法看进它的决策过程。

这意味着大模型并没有消除不确定性，只是把"人的不确定性"换成了"模型的不确定性"。如果只看到 AI 用能源产出认知能力，却不管控这一层新的不确定性来源，软件工程的下一个时代就会从"人的危机"直接转成"模型危机"。

所以光有认知引擎不够。真正需要的是一整套新的工程原则——人的责任不再是亲手消除每个微小的偏差，而是设计一个能自我纠偏的系统，并处理系统自己纠不回来的剩余偏差。

这件事在控制论里有个对应概念。冯·福斯特在 1970 年代提出过二阶控制论，简单说一阶控制论是"观察并控制被控对象"，二阶控制论是"观察并控制'观察并控制'这件事本身"。投到 AI 软件工程上：

经典软件工程：人在写代码AI软件工程：人在设计"AI 写代码的系统"

这是身份的转变，不只是工具的转变。如果未来真有一本叫"AI 软件工程"的教科书，第一章应该写的就是这件事——它本质上是二阶控制论第一次大规模在认知工程领域工业化。

三、人在自动化时代不会消失，只会换地方

3.1 一个反直觉但反复被验证的现象

工程史上有个现象，我每次想起来都觉得意味深长：自动化越彻底，工业相关人口反而越多。

时代	主导工程范式	直接生产工人	工业相关人口（含设计/研发/运维/调优）
1850 年代蒸汽机普及	机械化	占比约 30%	制造业整体爆炸式增长
1950 年代流水线加 PLC	自动化	持续下降	工程师、设计师、工艺员暴增
2000 年代工业机器人	数字化	进一步减少	自动化工程师、产线运维成新岗位
现在	智能化	仍在减少	仍在增加

一百五十年了，"自动化吃掉一类岗位、又冒出更多新岗位"这件事从来没失效过。

3.2 为什么会这样

经济学课本会告诉你这是"需求扩张"。但更深的解释，我觉得是这个：每一次系统能力扩张，都会暴露出新的边界，而边界就是新的"偏差地带"，需要新一波人去守在那里。

第一波工程化把肌肉劳动固化进系统，人退到机械边界监督位；第二波把低阶决策固化进系统，人退到控制边界监督位；现在第三波把高阶认知固化进系统，人会退到认知边界监督位。

每一次"退守"都不是失业，而是迁移。因为边界本身在扩大，所以需要守的人反而更多了。

3.3 人的统一职能其实只有一个：偏差拉回

把这条铁律抽象出来，会得到一个我觉得相当稳定的结论：在所有工程门类里，人类的统一职能是处理系统暂时还无法处理的偏差。

工程门类	系统主体	人在做什么
机械、化工	物理回路	拉回物理偏差（设备故障、原料波动）
电力	电网调度	拉回负载偏差（突发用电、机组故障）
航空航天	自动驾驶	拉回飞控边缘场景
核电	反应堆	拉回安全边界偏差
AI 软件工程	认知回路	拉回 AI 自己纠不回的认知偏差

工程化的进程，本质上就是把人从主回路移到边界监督位的过程。人始终守在系统能力的边界外侧，专门处理系统暂时还没办法处理的偏差。

再往上抽一层，可以总结成一条规律：工程化扩张的本质是把"原本无法工程化的事"持续变成"可工程化的事"，人永远站在工程化边界的外侧，边界往外推，人也跟着往外迁移。这给了 AI 时代一个相对乐观的工程哲学——人不会被淘汰，因为新的"不可形式化边界"会一直冒出来。

但这个乐观底下藏着一个挺严峻的事实：能在这种边界上工作的人会越来越少，因为形式化吃掉的都是低阶认知，剩下的都是越来越高阶的部分。

3.4 AI 工程的偏差拉回是一次本质升级

经典工程的偏差拉回有几个隐含前提：偏差类型是可枚举的（机械故障的种类有限）、偏差信号是可观测的（仪表会报警）、拉回手段是 SOP 化的（按操作规程办）。

到了 AI 工程，这三条几乎全都不成立。

维度	经典工程偏差	AI 工程偏差
类型	可枚举	不可枚举（幻觉、漂移、长尾、对抗）
信号	可观测	隐蔽（输出看起来合理但悄悄错了）
手段	SOP 化	需要专家级判断
时间窗口	拉回前可降级运行	错误已经扩散到下游产物

这意味着 AI 工程里的"偏差拉回者"，专业门槛远高于传统运维岗。你需要一个人同时具备业务理解、AI 能力评估、形式化验证、反例构造这几样东西。这种人本来就稀少，未来只会更稀少。

3.5 软件研发人力会怎么流动

按上面这条铁律，软件直接生产人力会大幅减少，但研发相关总人口未必。释放出来的人会流向四个方向：

真正高价值的产品定义岗：用户洞察 + 商业判断 + 跨域整合，这一类极度稀缺，少数人能进入。
被稀释的伪定义岗：AI 让人人都能写需求，定义价值这件事的门槛被拉低，多数人会落在这里，竞争反而更激烈。
AI 产线建设、维护、调优岗：这是真正的新增主力岗位，也是这一波最关键的新主线，但门槛很高。
被工程化彻底淘汰、外溢到其他行业的人：这一部分被讨论得很少，但必然存在。

这里有个细节值得提醒一下：软件世界的"产品定义"扩张不像实体产品那样指数级增长。一旦 AI 能以极低边际成本生成软件，软件供给曲线变得几乎水平，单个软件的"被定义价值"会被快速稀释。所以"流向产品定义岗"这件事不是均匀扩散，而是高度集中化——真正能定义"哪些软件值得被定义"的人，会非常少。

四、AI 真正的价值，是把人的注意力还给人

4.1 主流叙事浅了一层

业界讨论 AI 价值的时候，主流叙事是"AI 让人做事更快"。这个说法当然没错，但它停在一个比较浅的层面。

如果换一个角度——人作为碳基智能体，算力本来就是有限的，注意力是稀缺资源——那 AI 真正的价值就不是"加速生产"，而是把人的注意力从一堆琐碎事务里释放出来，让它能集中到只有人能做的事上。

这两个视角看着差不多，但长期会分化成完全不同的产业组织形态。

视角	AI 在做什么	人变成了什么
效率视角	让人做事更快	在大量琐碎事务里继续打转，只是更快
注意力视角	让人不需要再做那些事	退守到最稀缺的判断位上，做更少但更关键的事

效率视角下你会鼓励人多用 AI，做更多事；注意力视角下你会鼓励人多用 AI，把更多事从自己手里挪走。

4.2 这正好和"人是偏差拉回者"对上了

注意力视角下 AI 的目的就清楚了：不是替代人，是让人能集中算力做只有人能做的事——也就是边界守卫、价值定义、偏差仲裁。

也就是说 AI 为中心这件事的真正动机，不是"让 AI 多做"，而是"让人能少做但做对"。这一句话能把后面所有路线推演的终极目的说明白。

五、为什么"人为中心 + AI 辅助"是弯路

5.1 当下业界主流模式

现在业界主流的 AI 工程模式，不管叫 Copilot、Cursor、Cline，本质上都是"人为中心 + AI 辅助"——人依然是流程主体，AI 只是局部加速器。

这种模式听起来稳健，做起来也容易上手，老板也愿意为它付费，员工也不抵触。但它在范式层面是错的。

5.2 它没有消除不确定性，它在循环放大不确定性

在 Copilot 模式下，AI 的训练数据是人写的代码，它学到的是人类程序员的模式、风格，包括各种典型错误。它没有自己独立的、可验证的、确定性的"质量函数"——它只是在概率上模仿"看起来像对的代码"。

这件事的麻烦在于：

人的不确定性→AI训练数据↓AI学会人的不确定性模式↓AI输出=人的不确定性的"统计平均"↓人reviewAI输出，但review的标准还是人原来的标准↓不确定性在「人→AI→人」之间循环往复，被放大、被合法化

人成了唯一的偏差拉回者，但这个角色本身就是旧软件工程失败的根本原因——人脑覆盖不了状态空间。让人去校验 AI，等于让自己的影子去打自己。

这个判断也解释了一个反直觉的现象：很多团队接入 Copilot 之后，编码速度提升 20-40%，但项目级 bug 率没明显下降，review 工作量反而上升。主流解释是"AI 还不够强"，但更深的解释是：Copilot 这套模式本来就不是为消除不确定性设计的——它是用统计模仿人类工作的概率拟合器。

5.3 反馈回路被人切断了

Copilot 模式还有一个更根本的缺陷：反馈回路是断的。

AI 给出建议，人采纳、修改或者抛弃——这个反馈不会以结构化的方式回到 AI。改了几个字符，但"为什么改"没有信号；不同人的标准还不一样；bug 暴露出来的时候 AI 早已经忘了上下文。这导致 AI 永远停在"通用编程模型"的水平，永远学不会你团队的领域偏好、工程规范、业务约束。

这件事的战略后果比技术后果更严重：在 Copilot 模式下，反馈最终积累到 AI 厂商那里，不在你团队手上。你团队做的事情是在帮 OpenAI、Anthropic 训练他们的下一代模型，但你自己的工程资产没增加。

5.4 真正应该走的双爬坡

把前面这些拼起来，可以推出一个我觉得对未来很关键的判断：AI 软件产线的良率提升，依赖"AI 能力"和"工程框架成熟度"两个变量同步爬坡，而它们之间互相加速。

AI能力越强→工程框架可以承担更多任务→产线的偏差案例库越丰富→AI的训练/调优反馈越充分→AI能力进一步增强

这是个正反馈循环，但这个循环只有在"AI 为中心"架构下才能闭合。Copilot 架构下，反馈会被人这一环节切断，循环转不起来。

把两种模式放一起对比就更清楚了：

维度	Copilot 模式	AI 为中心模式
反馈频率	低	高（自动验证回路天然产生）
反馈密度	低（"接受/拒绝" 1 bit）	高（验证报告 + 偏差规则）
反馈对象	训练通用模型	沉淀本团队、本领域的专属规则库
能力爬坡的载体	AI 厂商（你不受益）	你的产线本身（你直接受益）

把这件事说得直接一点：Copilot 模式下你团队是在为 AI 厂商打工；AI 为中心模式下，你团队才能积累自己的工程资产。

5.5 历史规律也站在这边

工程史上每一次范式跃迁都遵循同一条规律：新范式的成熟，不是通过"用旧范式包装新工具"实现的，而是通过"重构整个工程流程让新工具占据中心位"实现的。

跃迁	错误的过渡形态	真正的新范式
手工到机械	把蒸汽机当大号风箱用	设计专门为蒸汽机优化的工厂布局
机械到电气	用电动机直接替换蒸汽机，保持原有传动轴	每台机器独立电动机，重新设计车间
模拟到数字	用计算机模拟纸质表单	重新设计数字原生流程
单机到互联网	把单机软件搬到网页	互联网原生应用
传统软件到 AI 软件	Copilot 在 IDE 里塞 AI 建议	认知流水线重构整个开发流程

最经典的案例是 20 世纪初的电气化。福特发明流水线之前，工厂用电动机的方式是直接拿它替换蒸汽机——还是用一根传动轴带动整个车间。效率比烧煤略好，但提升有限，三成不到。福特做对的事情是给每台机器单独装电动机，并按"电力本位"重新规划生产线。这一变效率提升了几倍到十几倍。这场变革花了将近 30 年，而第一波"用电动机直接替换蒸汽机"的公司全部被淘汰了。

当下的 Copilot 模式，正是 20 世纪初那种"用电动机直接替换蒸汽机"的过渡形态。它不会是终局。

六、让 AI 工程级可靠的唯一已知机制

6.1 把 AI 推到中心位之后，下一个问题马上来

好，假设接受了 AI 为中心。下一个问题立刻冒出来：怎么让一个概率性输出的 AI，变成工程级可靠的东西？

大模型的根本问题就是输出的概率性——幻觉、漂移、不可形式化验证。这意味着 AI 永远没办法"自证清白"，它的内部状态没法保证输出对错。

所以唯一能让 AI 输出变得工程级可靠的办法，是外部强加一个确定性裁判。把 AI 的概率性输出，强制对接到一个有客观对错的验证系统，让 AI 每一次输出后被迫接受确定性的审判。

节点	确定性裁判	工程化机制
编码	编译器 + 单测 + 类型系统	"代码能跑且测试通过"是客观事实
契约	契约校验器	"符不符合 proto 规范"是客观事实
部署	灰度监控指标	"线上是否报错"是客观事实
设计	性能仿真器	"压测是否达标"是客观事实

一个工程节点能不能把 AI 工程化，本质上取决于那个节点上有没有一个客观的确定性裁判存在。这是把概率性认知工程化的唯一已知机制。

6.2 历史的接力棒

这恰好接上了第一章末尾那个伏笔：过去五十年软件工程的"失败"，反而给 AI 软件工程的"降临"准备好了一件最关键的武器——成熟的自动化验证基础设施。

五十年的 CI/CD、单元测试、类型系统、形式化方法、契约编程，没让软件工程"工程化"，但它们留下了一整套可以拿来当确定性裁判的设施。AI 现在终于可以站在这套设施肩膀上，第一次实现真正的工程化。

这件事我每次想到都觉得有点诗意："失败的五十年"留下的废墟，刚好是新范式的地基。

七、闭环优先，节点逐步开放

7.1 "逐节点替换"听起来稳，做起来错

从 Copilot 走向 AI 为中心，直觉上的路径是按节点逐个替换：

原流程：人需求→人设计→人编码→人测试→人部署↓逐节点替换人需求→人设计→AI编码→人测试→人部署↓再替换...

但这条路径在工程上是错的。问题在于，每一个 AI 节点都受限于上下游的"人化"接口。AI 节点之间没法直连，被人节点切成了孤岛——每个 AI 节点只能在"人节点夹缝中"做局部优化，没办法形成端到端的 AI 主导流程。

这其实又回到了 Copilot 模式的天花板。

7.2 应该走的是"先建小闭环，再扩边界"

我倾向的路径是这样的：不逐节点替换，先建立一条端到端封闭的"AI 全流程小回路"，再逐步把它的每个节点开放给更复杂的真实需求。

具体形态可以这样想：

第一步：建立小闭环挑一个范围足够小、足够确定的子领域在这个子领域上让AI跑全流程：需求→设计→编码→测试→部署人只在「输入端定义目标」和「输出端验收」两端介入这条闭环就是AI为中心的最小可行原型第二步：闭环内迭代在小闭环内积累偏差案例库把"AI 拉不回 → 人拉回"的规则沉淀到系统AI能力和框架成熟度同步爬坡第三步：扩大闭环边界随着闭环成熟度提升，扩大它能覆盖的领域复杂度第四步：闭环吞并最终扩张到整个软件工程流程都被AI闭环覆盖人退守到价值定义层和偏差边界层

两种策略最大的差别在爬坡的单位上：

策略	爬坡单位	爬坡机制
逐节点替换	节点	每个节点局部优化，整线没人管
闭环优先 + 节点开放	回路	整线良率持续爬坡

工程上有句老话其实很贴切：激进的路径，往往是稳健的路径；稳健的路径，往往是慢的路径。

7.3 不同节点的可闭环程度差很多

并不是每个节点都同样适合先动。我会用两个维度评估：形式化程度和验证可自动化程度。

节点	形式化程度	验证可自动化程度	当前可建闭环
需求分析	低（自然语言）	低（"对不对"靠人）	困难
系统设计	中（架构图、接口）	中（性能可仿真，可维护性难判）	部分可行
编码 + 测试	高（语法、类型、契约）	极高（编译 + 测试）	最适合先做
发布运维	高（监控指标）	高（自动告警 + 回滚）	适合做

这就给出了一个挺关键的结论："AI 为中心"不是一夜之间全节点切换，而是从形式化程度最高的节点开始向外辐射。

这恰好对应工业革命的真实路径：先是纺织（最容易机械化的环节），后是运输，再是通讯，最后才是管理决策。

按这个顺序展开会是这样：

第一阶段：先在"编码 + 测试"建立AI闭环选小领域（管控点、契约、异常码这种）建"生成 - 验证 - 修复"全自动循环沉淀偏差规则库让产线良率开始爬坡第二阶段：扩展到"发布运维"AI自动渐进发布AI自动监控、定位、回滚把编码闭环和运维闭环连起来第三阶段：上探到"系统设计"第四阶段：最后才是"需求分析"等大模型在"业务理解"上有质变在此之前，需求节点保持"人为中心 + AI 辅助"是合理的

八、落地：分治结构继承与六阶段演进

8.1 分治结构应该被继承下来

这条路径有个底层判断：AI 时代的研发组织结构，应该继承人类组织已经验证有效的"分治网络/树形结构"，而不是被 AI 重新发明。

这一点为什么重要？因为它点出一个被普遍忽略的事实："分治"不是人类组织的偶然选择，而是注意力有限的智能体处理复杂问题的必然结构。

人在解决复杂问题时面临一个矛盾——知识广度和精度不能兼得。这是注意力有限的根本表现。人类的解决方案是分而治之，把问题拆成网络或树形结构，每个节点负责一部分。

只要 AI 注意力同样有限（事实上当前所有大模型的上下文窗口都是有限的），AI 组织就必须遵循同样的分治结构。这一点 AGI 出现之后也不会变，因为算力和注意力总是有限的。

8.2 这把"等 AGI"的等待心态打穿了

很多团队在 AI 工程化上观望，本质上是在等"模型够强"。但如果分治结构是必然的，那这个等待就没意义了——就算未来出现 AGI，组织结构依然要分治。

分治结构是 AGI 之前就要建好、AGI 之后还能继续用的工程基础设施。它不是过渡方案，是终极方案。现在不建，等 AGI 来了再建，会被已经建好分治结构的玩家代际碾压。

工业革命的真实历史就是这样——福特流水线的"分工结构"在电气化、自动化、机器人化时代都被继承下来，分工的颗粒度变了，但分工本身没变。

8.3 现有研发组织结构会被怎么继承

这里要先澄清一个关键点："继承"指的是结构骨架被继承，分治边界、协作拓扑、评审校验环节、组织接口这些保留下来；不是人的岗位被继承。

所有传统软件工程角色——不管是代码生产、测试、发布、问题定位，还是方案设计、评审、跨域协调——最终都会被对应的 AI 产线全面接管，人最终都要站在产线外。差别只是先后顺序，不是有没有。这恰好和上一章"节点的差异化展开顺序"完全一致：编码 + 测试，然后发布运维，再然后系统设计，最后是需求分析。

现有组织结构	结构骨架是否被 AI 产线继承	人退到产线外的时序	说明
分治单元（产品域、业务域）	完全继承	不适用，结构本身不是岗位	边界保留，承载者从人换成智能体集群
代码生产团队	继承为"编码产线"	第一波（已经在路上）	形式化程度最高、确定性裁判最完备，最先被产线化
测试团队	继承为"测试产线"	第一波（与编码同期）	与编码产线天然耦合，自动验证基础最成熟
发布团队、SRE	继承为"发布产线"	第二波	监控、灰度、回滚已经高度自动化，剩下的是 AI 接管决策
问题定位团队	继承为"问题定位产线"	第二波	日志、链路、根因分析有结构化输入，AI 接管路径清晰
评审团队	继承为"评审智能体集群"	第三波	多模型对抗评审替代多人评审，但需要先有可形式化的评审标准
方案设计团队	继承为"方案设计智能体集群"	第三波	需要等领域本体足够形式化（管控建模、契约建模成熟）
需求分析、产品定义	继承为"需求产线"	第四波（最晚）	隐性知识最密集、确定性裁判最弱，最后被产线化
跨域协调（架构组、总监层）	继承为"分工协调总线"	第四波	元控制器，本身就是产线的产线，只能在所有子产线成熟后建成

这里有一个观察可以再强调一下：没有哪一类角色是"被特殊优待保留"的。所有团队都会在它对应的"确定性裁判"成熟时被产线化吸收，然后人退守到该产线的边界监督位。

进一步推论："产线设计师"角色本身也终将被更高阶的产线吸收——只要某天"如何设计产线"这件事的确定性裁判被建立起来。这是这套理论的递归一致性，没有终极避风港，只有持续的边界外推。

8.4 六阶段演进路线

把单条产线（编码 + 测试）的建设细化成阶段：

阶段1：单分治单元70%需求实现0人工代码AI写出70%的代码，但还需要人审查、修改这是当前业界主流位置（接近这一阶段）阶段2：单分治单元90%需求实现0人工代码AI写出90%的代码，剩下10%是真正复杂场景这是当前最先进团队的位置★阶段3：单分治单元70%需求实现0人工接管质变点——AI不只写代码，连"自己不知道怎么办"也消失了这是从"概率正确"到"工程可靠"的跨越★关键质变断点阶段4：单分治单元80%-90%需求实现0人工接管单分治单元几乎完全自治单元已经成为"AI 产线模块"阶段5：搭建分工协调总线把多个自治单元连起来，形成完整产线元控制器登场，对应原有的方案设计、评审团队等阶段6：法不变同理复制第一条产线（编码+测试）建成后，方法论沉淀为模式按7.3节点形式化程度由高到低复制：第一波：编码+测试产线（已含在阶段1-5）第二波：发布产线+问题定位产线第三波：系统设计产线（需领域本体足够形式化）第四波：需求产线（最晚——隐性知识最密集，确定性裁判最弱）所有研发最终转变为产线维护、设计工程师，不在任何核心产线内部

8.5 阶段 2 到阶段 3 中间藏着一个质变

这条路线最锋利的设计在阶段 2 到阶段 3 中间——从"0 人工代码"到"0 人工接管"是一次质变，不是量变。

很多团队会以为达到"AI 写出 90% 代码"就接近自动化了。但事实是：写出代码不等于不需要人——剩下的 review、纠错、澄清歧义这些"接管"环节才是真正的瓶颈。

阶段	对应机制	关键挑战
0 人工代码	AI 生成能力	AI 模型本身够不够强
0 人工接管	不确定性自纠 + 隐性知识蒸馏	AI 自己能不能识别"我哪里错了"

从阶段 2 到阶段 3 的跨越，根本不是模型能力升级能解决的。它必须靠三件事配合：确定性的强迫接触（前面讲过的自动验证基础设施）、场景驱动的隐性知识蒸馏（领域规则库的沉淀，第十章详细讨论）、还有一种主动反思机制——AI 主动追问"我为什么被纠正"。

8.6 阶段 5 的"分工协调总线"

阶段 5 引入了一个我觉得很关键的概念：分工协调总线，对应原有方案设计、评审团队的智能体化。

要先做一个时序辨析：阶段 5 搭建协调总线（基础设施建成），不等于 §8.3 里"跨域协调团队第四波退守产线外"（人岗位变迁）。

阶段 5 ：协调总线作为编排基础设施搭建起来，但此时它编排的还主要是编码、测试产线，元控制器的关键决策仍然由人（架构组、总监层）做出。
第四波：当所有子产线都成熟、协调总线本身也积累了足够的"产线编排偏差案例库"，才轮到跨域协调团队作为人退守到这条总线的边界监督位。

基础设施先建好，人后退守——这恰好是工业革命的真实路径：流水线先建好，工艺工程师才从车间退到调度室。

这个总线的妙处在于：它不是技术总线（事件总线、消息总线），而是组织结构的工程化映射。

维度	经典消息总线	分工协调总线
承载内容	事件、消息	任务、协作流程、评审决策
节点	服务	智能体集群（每个对应一个原团队职能）
控制	消息路由	任务分发 + 评审编排 + 偏差仲裁
元数据	消息元信息	领域知识、评审标准、历史决策

这个总线的本质是组织协作流程的代码化——从"组织架构到软件架构"的同构映射。AI 时代要建的"产线"，和当前的微服务架构、消息中间件，是完全不同的东西。它需要一个新的"组织级中间件"，业界目前没有任何公司在做这件事。

8.7 法不变，同理复制

第一条产线建好之后，方法论本身可以沉淀为可复制的工程模式，并指数加速地扩展到测试、需求、发布、问题定位等所有研发环节。

第一条产线（编码产线）建成需要大约x年（艰难探索）第二条产线（测试产线）建成需要大约x/2年（复用方法论）第三条产线（发布产线）建成需要大约x/4年...

这是一个指数加速过程——一旦第一条产线跑通，后续产线的建设速度会快速收敛。福特流水线建立后二十年内汽车、电器、纺织、化工全部产线化，就是这个规律——从 1 到 N 的扩张比 0 到 1 快得多。

战略含义很直接：今天投入"第一条产线"建设的团队，会获得不对称的战略优势。他们率先掌握了产线建设方法论，未来所有领域都能复用这套方法论。

8.8 分治单元的颗粒度是隐藏前提

这条路线图所有阶段都建立在一个隐含前提上——分治单元已经被合理切分。这个前提其实是最难达成的。

切错的典型方式有三种：

切得太大：单元内部仍然超出 AI 注意力极限，"0 人工代码"做不到。
切得太小：单元间通信成本暴涨，协调总线变成瓶颈。
按技术分而不是按业务分：单元间高度耦合，没法独立演进。

那应该怎么切？工业革命给出过答案——按"端到端业务价值"切。

汽车流水线不是按"螺丝、电焊、喷漆"切，而是按"前桥、底盘、车身、动力"切——每个单元都对应一个端到端的业务子价值。映射到 AI 软件产线，分治单元应该按"完整的业务能力"切，而不是按"技术模块"切。

九、四节点重构的具体形态

9.0 三种切法的统一映射

文章在不同地方用了三种粒度来切软件工程流程，先把它们的映射关系说清楚：

视角	切分维度	数量	对应章节
流程节点	按"工作内容相似性"	4 个	9.1
产线	按"独立 AI 闭环可行边界"	5 条	8.4
现有团队	按"传统组织分工"	8 类	8.3

三者不是一一对应，而是逐层细化：

节点（最粗）→产线（中粒度）→团队（最细）══════════════════════════════════════════节点1：需求分析→需求产线→需求、产品团队节点2：系统设计→系统设计产线→方案设计+评审团队节点3：编码+测试→编码产线+测试产线→代码生产+测试团队节点4：发布运维→发布产线+问题定位产线→发布、SRE+问题定位团队跨节点元控制→分工协调总线（不是产线，是产线编排器）→跨域协调（架构组、总监层）

几个细节解释一下：

"编码 + 测试"在 9.1 合并为一个节点，因为它们的确定性裁判几乎共享（编译 + 单测）；但作为产线被独立部署时，可以拆为两条（生成产线 + 验证产线）。
"发布运维"在 9.1 是单一节点；但"问题定位"在工程上有独立的输入输出（日志、链路），可以独立产线化。
"分工协调总线"不是产线本身，而是产线之间的编排器，所以不出现在节点和产线列表里，但出现在 8.4 阶段 5 和 8.6。

9.1 四个节点分别会怎么变

需求分析节点

AI 为中心：智能体基于对话和资料库，直接生成结构化的需求规格说明书、用户故事地图和验收条件。

人工辅助：产品经理和用户不再"写需求"，而是审查和剪刀——发现 AI 遗漏的隐性需求、模糊的定义、不符合业务价值排序的地方，并补充修正。每一次修正都是一次强对齐信号。

系统设计节点

AI 为中心：智能体基于确认的需求，生成多种架构方案，并自我模拟评估其非功能属性（性能瓶颈、单点故障等等）。

人工辅助：架构师不画图，做仲裁和权衡——当 AI 给出两个在技术上同样可行、但在"可维护性"和"快速上市"之间有冲突的方案时，人介入，基于经验和战略做最终裁定。这是定义"什么才是更好的偏差"。

编码与测试节点（革命性最强）

AI 为中心：核心不是 AI 写代码，而是建立一个自动生成、自动验证的循环——AI 生成代码 → AI 生成测试用例 → AI 执行测试并修复 → 直至通过所有验证。这个循环甚至可以包含多个专门 AI（生成者、审查者、测试者），像流水线一样对抗协作。

人工辅助：开发者的角色进化为"AI 产线调试员"。他不再写具体功能，而是在循环外设定目标架构和不可逾越的约束；监控自动循环的健康度——测试覆盖率是否在下降，生成代码是否在关键模块出现不可解释的复杂性；当 AI 循环自己转不动或者陷入错误的局部最优时，切入注入新的知识或者直接修正关键代码块，做工艺级的偏差拉回。

发布与运维节点

AI 为中心：AI 自动进行渐进式发布、实时监控异常、根据日志自动定位故障根因并尝试回滚或热修复。

人工辅助：SRE 成为最终安全阀——处置 AI 无法理解、需要跨系统权衡的复杂故障（比如，是牺牲一部分用户体验来保证核心交易链路，还是相反）。这是定义"系统安全的最终值函数"。

9.2 分层递阶控制结构

把上面这些节点放进一个分层递阶控制结构里：

┌──────────────────────────────────────────────────────────┐│第4层：哲学层/价值层││-价值函数定义←AI价值架构师││-战略对齐←CEO/CTO││-伦理仲裁←独立伦理委员会│├──────────────────────────────────────────────────────────┤│第3层：决策层（治理）││-产线目标架构←组织级架构师││-安全红线←AI治理官││-自主修改授权←ChangeAdvisoryBoard│├──────────────────────────────────────────────────────────┤│第2层：协调层（产线编排）││-智能体编排←认知流程架构师││-实时监控干预←AI产线工程师││-多智能体调优←AI调优师││-涌现偏差归因←跨层诊断专家（关键新岗位）│├──────────────────────────────────────────────────────────┤│第1层：执行层（兜底）││-隐蔽Bug兜底←资深技术专家││-形式化验证←形式化方法专家│└──────────────────────────────────────────────────────────┘

经典分层递阶控制是决策、协调、执行三层。AI 软件工程要做两处扩展：往上扩出一个哲学价值层，因为"价值函数定义"不属于决策层；协调层增加一个横切机制，专门处理跨层涌现偏差。

这里要补一个递归一致性的提醒：第 4 层"哲学价值层"也不是终极避风港。一旦"价值函数定义"这件事的确定性裁判被建立起来（比如可量化的伦理评估器、可仿真的战略沙盘），这一层同样会被产线化吸收，人会继续向更高的元层迁移。当前把它列为最高层，是因为它在可见的十到十五年时间窗内"确定性裁判最难建立"，而不是它具有"原则上不可工程化"的地位。

9.3 经典递阶控制在 AI 系统里失效的地方

经典分层递阶控制有一个隐藏前提：下层的扰动不会逆向传播到上层。但 AI 系统会破坏这个前提，原因有几个。

第一个失效是 AI 的能力会"自下而上"重塑上层目标。执行层的 AI 能力突变（比如 GPT 升级），会逼协调层重新划界。经典控制论里没有"执行单元能力突变"这种情况，但在 AI 系统里这是常态。AI 软件产线的层级边界本身是不稳定的，需要经常重新划界。

第二个失效是 AI 的偏差会"涌现"，没法预先归因到某一层。经典系统里偏差是可定位的——温度高了就是温控器问题。但 AI 系统里，一段错误代码可能是需求理解偏差（决策层），可能是智能体编排错误（协调层），可能是单个智能体输出问题（执行层），也可能是几个智能体的交互涌现。多智能体系统的偏差经常是涌现性的，不归属于任何单一层级。AI 产线工程师在做偏差归因时，会面临一种经典工程师从来没见过的复杂度。

修正方式是增加一个跨层耦合控制的横切机制：

┌─────────────────────────────┐│决策层│├─────────────────────────────┤│协调层│←横切层：偏差归因/涌现监测/层级再划界├─────────────────────────────┤│执行层│└─────────────────────────────┘↑↓双向耦合

横切层不是新的层级，而是专门处理跨层涌现偏差的诊断与重构机制。这一层在经典工程里不需要，但在 AI 工程里是关键岗位。

9.4 价值函数定义和偏差仲裁是两回事

需要把"价值函数定义"和"偏差仲裁"拆开，它们性质完全不同：

维度	价值函数定义	复杂权衡仲裁
时机	系统设计时	系统运行时
频次	低频，但影响深远	高频，但单次影响小
能力要求	抽象建模 + 长期判断	实时决策 + 多目标平衡
类比	工艺设计师	调度员、应急指挥
出错成本	极高（系统从根上跑偏）	中等（可纠正）

它们最终会分化为两个完全不同的岗位——AI 价值架构师在系统启动前定义"什么是好"；AI 运行时仲裁员在系统运行中处理价值冲突。价值架构师的稀缺性远高于仲裁员——前者影响整个系统的方向，后者只影响单次决策。

十、真正最难的那道坎：场景驱动的隐性知识蒸馏

10.1 这件事是整套理论里被低估最多的一关

前面所有讨论的"双爬坡""闭环优先""节点重构"——都是"建好之后怎么跑"的问题。真正最难、最被低估、也最具决定性的一道坎是：怎么把它建起来。

难题	难度	原因
建立 AI 闭环	中高	需要重构流程，但有方法论参考
设计自动验证机制	中	软件工程五十年积累了基础设施
分层递阶控制	中高	需要新岗位，但岗位可培养
隐性知识的主动蒸馏	极高	既无成熟理论，也无成熟工具，且专家自己都不知道自己懂什么

10.2 新人和 AI Agent 在"成为独当一面"这件事上差距在哪

注意力释放论说，AI 让人能集中算力做更高价值的事。但要真正实现这一点，必须先解决一个问题：怎么让 AI 独当一面，把人的注意力提走？

可以做个对照——一个新人和一个 AI Agent，在让他们成长为独当一面的过程中，到底有什么不同？

维度	新人	AI Agent
被动接收能力	中等	极强（一次性吃下整个 codebase）
主动追问能力	强（会问"为什么"）	弱（被问才答）
元认知能力	强（"我哪里没懂"）	弱（不知道自己不知道）
反思归纳能力	中（写复盘、总结模式）	几乎没有（每次会话独立）
知识蒸馏能力	强（能从老员工身上"挖"知识）	几乎没有（只能基于已显化的文本）
跨场景关联	中	中（取决于上下文窗口）
长期记忆沉淀	强（经验内化为直觉）	极弱（默认无状态）

新人和 AI 在"接收 / 学习能力"上其实差不多，AI 在某些维度甚至更强。但在"主动蒸馏知识"这件事上，差距是数量级的。

我会这么总结：AI 缺的不是智能，是"自主开采知识矿"的能力。

10.3 知识不会自然流淌出来

这里有一条我觉得很重要的元规律：人的知识不会自然流淌出来，必须被具体的问题和场景驱动才会被逐步从大脑中蒸馏出来。

回想人类组织搞知识管理的所有失败案例：

尝试	失败模式
Wiki / Confluence	写的人没动力，看的人找不到
知识管理系统（KM）	大量文档堆积，但用的时候搜不到
ISO 9001 流程文档	一旦写完就过时，没人维护
RAG / 知识库	喂进去的是"显性知识"，不是"被场景驱动蒸馏的知识"

所有失败的共同根因都在这一条上：没有问题驱动，专家脑子里 90% 的"经验直觉"永远不会被显化。

这件事在哲学上其实不是新洞察。波兰尼 1958 年就讲过——"我们知道的比我们能说出来的多"（We know more than we can tell）。当时是哲学命题，现在变成了 AI 工程化的核心瓶颈。

10.4 这件事我会叫它"场景驱动的隐性知识蒸馏"

这是 AI 为中心范式得以成立的关键工程门槛。它的核心特征有几条：

场景驱动：知识必须由具体问题、场景驱动才能涌现，孤立提问问不出来。
主体二元：蒸馏的主体不能是 AI（AI 没有主动性），但也不能完全是人（人有惰性）。
协作回路：必须由人和 AI 共同构成"主动追问 + 即时反馈"的协作回路。
场景化存储：蒸馏出的知识必须以"场景化"格式存储，而不是"陈述性"格式。

10.5 这道坎为什么特别难

第一个难点：专家自己都不知道自己懂什么。

即使你直接问专家"请把你所有经验告诉我"，他能输出的只是冰山一角。剩下 90% 他自己都不知道自己拥有，必须等具体问题碰到了才会涌现。"知识蒸馏"在结构上比"知识采集"难一个量级——你不能"问出来"，你必须"逼出来"。

第二个难点：蒸馏需要"对的问题"，但"对的问题"本身需要知识才能问出来。

要让专家的隐性知识涌现→需要问"对的问题"要问"对的问题"→需要懂这个领域而AI不懂这个领域→问不出对的问题→蒸馏失败↑↓这是个死循环

现实中这个死循环靠新人的主动性打破——新人会去观察、试错、被骂、归纳，慢慢摸索出对的问题。但 AI 没有主动性，它的"问题"是被人喂的，所以它永远进不了这个死循环。

第三个难点：蒸馏出的知识形态是"场景化的"，不是"陈述性的"。

专家的知识不是"什么是 X"，而是"在 Y 场景下应该怎么办"。这意味着蒸馏出来的知识必须以"场景 + 决策"的方式存储，而不是"事实 + 解释"。但当前的 RAG 系统、知识图谱、向量库全都是为陈述性知识设计的——AI 软件工程缺一个"场景化知识"的存储和检索范式。

10.6 几个可以入手的方向

按可落地性从近到远排：

方向一（近期可做）：让 AI 主动问"我为什么被纠正了"。

AI输出→专家修改→系统强制触发：AI主动比对修改前后AI自己生成假设："专家可能基于什么规则做了这个修改？"专家确认或修正AI的假设沉淀为"场景规则"入库

这个机制的关键是把"专家被动修正"变成"AI 主动追问"，把知识蒸馏的认知负担从专家转移到 AI——专家只做判官，不再做老师。这一步在工程上完全可行，当前大模型能力够用。

方向二（中期）：AI 不等专家来纠错，而是在专家工作时全程跟随观察。

专家做日常工作（写代码、review、决策）↓AI全程在旁观察+标注异常点：专家做了X，但通常情况下应该做Y这个判断和上次的判断不一致，是为什么？专家在某个步骤停顿了30秒，可能在权衡什么？↓AI主动把疑问做成清单→专家在合适时机回答→入库

类比一下就是新人入职"看老员工怎么做"再问"刚才那个为什么这样处理"。AI 从被动接受指令变成主动观察和提问。

方向三（中期）：场景化的知识库格式。

要让蒸馏出的知识能被复用，存储格式必须从"陈述性"变成"场景化"：

scenario_id: SCN-001context:  - 业务领域：跨境支付  - 触发条件：商户提交退款且金额>单笔限额  - 上下游状态：原支付已结算+商户余额不足decision:  - 推荐动作：拆单退款  - 不推荐动作：直接拒绝rationale:  - 商户体验：避免一次性大额拒绝  - 风控原则：拆单后单笔风险可控  - 历史依据：2024-Q3类似场景共发生N次，全部用拆单方案exceptions:  - 当商户处于风控黑名单时，仍直接拒绝provenance:  - 蒸馏来源：与专家X在2026-05-23关于工单#YYY 的讨论

这种格式有几个关键特性：context 让 AI 能精准匹配，rationale 让 AI 理解"为什么"从而扩展到相似场景，exceptions 让 AI 识别"什么时候这条规则不适用"，provenance 让人可以审查、追溯、维护。这是 RAG 时代的下一代知识库形态。当前没有任何主流工具支持，但这是必经的方向。

方向四（长期）：AI 主动构造极端案例反向逼问专家。

AI已掌握部分领域知识（来自前面方向积累）↓AI主动构造"边缘场景"："如果 X 发生在 Y 的同时，应该怎么办？""你说过 A 应该这样处理，但当 B 也成立时还成立吗？""我注意到规则 R1 和 R2 在 C 场景下会冲突，怎么解？"↓专家被迫思考从未遇到过的场景→输出新知识→入库

这个方向的妙处是让 AI 的"知识盲区"反过来变成蒸馏的杠杆。AI 不知道的越多，能问出的好问题就越多，专家被逼出的隐性知识就越多。

这恰好对应工程史上的一条铁律：最深的知识，永远是被"那个不该回答的问题"逼出来的。

十一、人的位置：从"人肉编译器"到"产线设计师"

11.1 过去五十年程序员的真实角色

我想用一个有点戳人的说法重新定位过去五十年程序员的角色：很大一部分软件从业者，其实是在充当"人肉编译器"——把模糊的业务需求翻译成精确的机器指令。

这话有点伤人，但放下情绪冷静看：

表象	真相
程序员是"创造者"	大部分时候是翻译者
软件开发是"创作"	大部分时候是形式化编码
编程是"高阶认知工作"	大部分编码工作是"模糊语义到精确语法"的机械翻译

这就推出一个挺尴尬的结论：过去五十年软件行业的"高薪"，本质上是在为"翻译能力的稀缺"付费，而不是为"创造能力"付费。

而大模型恰好就是第一个比人更便宜、更稳定的"语义翻译器"——它直接打中了软件行业薪酬结构的命门。这也解释了为什么 AI 对软件行业的冲击会比对其他白领行业更剧烈：因为软件行业的"高薪溢价"恰好建立在 AI 最擅长的能力上。

这里要补一个对照，避免和前面"过去五十年留下了 CI/CD、单测、类型系统等新范式地基"的褒义评价产生矛盾。这俩判断其实是同一枚硬币的两面：

面向	主体	评价
人所做的"模糊语义到精确语法翻译"	程序员的认知劳动	是被 AI 替代的命门——薪酬溢价的真实来源被打中
过程中沉淀的工具链（编译器、测试、契约、监控）	工程基础设施	是新范式的地基——下一代的"确定性裁判"就建在它上面

换句话说：程序员个人的劳动被贬值了，但程序员群体留下的工具链反而升值了。这两个评价并存才完整，它们一起回答了"为什么过去五十年是失败的工程化，但又不是白费的五十年"这件事。

11.2 五类全新岗位

把"产线建设、维护、调优"具体化下来，会出现五类岗位：

岗位	职能	类比经典工程
AI 产线架构师	设计软件生产流程：哪些环节 AI 做、哪些人做、如何衔接	工艺工程师
认知 SOP 工程师	把领域知识沉淀为 AI 能稳定执行的流程模板	工艺标准编写员
偏差检测工程师	设计自动验证 / 反例生成 / 输出审查机制	QA、质量工程师
AI 产线调优师	持续优化提示词、知识库、模型选型，提升产线良率	产线调优师
认知边界守卫	处理 AI 拉不回的偏差	资深工艺专家

这里面最稀缺的是"认知边界守卫"。它本质是"偏差拉回"具象化后的产物，要求一个人同时具备比 AI 更深的领域知识（否则识别不出 AI 错在哪）、比普通人更强的元认知（能判断 AI 的判断是否合理）、还有形式化思维（能把模糊偏差转成可验证规则）。

11.3 终极稀缺岗位是"产线设计师"

往前推到阶段 6 之后还会进一步分化：

阶段6：所有研发都是产线维护工程师↓阶段7（推论）：产线维护工程师内部分化产线运维工程师（维护现有产线，类似SRE）产线设计师（设计新产线，定义分治结构）★真正稀缺

为什么会分化？因为维护是高频但低密度认知的工作，会被工具进一步自动化；而设计是低频但极高密度认知的工作，永远稀缺。

产线设计师的能力画像我会画成这样：

能力维度	要求
业务理解深度	极高（必须能识别业务的"自然分治边界"）
工程方法论	极高（必须懂分层递阶控制论、二阶控制论）
隐性知识蒸馏能力	极高（必须能把专家直觉变成产线规则）
跨域抽象能力	极高（必须能复用方法论到不同领域）

11.4 教育体系的滞后

如果未来软件工程师的核心岗位变成"产线架构师 / 认知流程架构师 / 跨层诊断专家 / 产线设计师"，那今天的高校课程体系完全无法培养这种人——计算机系教编程，但新岗位不需要写代码；控制论在自动化系，但他们不懂软件；系统工程在工业工程系，但他们不懂 AI。

这意味着未来十年会出现一种全新的复合型工程师，但没有任何高校在批量培养他们。这是一个挺大的人才结构性短缺。

一个推论：腾讯这种大厂有可能比高校更早完成新一代工程师的培养。

十二、把这些串起来

12.1 整体逻辑骨架

把前面所有讨论压成一条主链，大致是这样：

软件工程过去五十年其实没真正工程化↓因为缺少能源换高阶智能这件事↓大模型实现了它但同时带来了模型的不确定性↓应对范式二阶控制论（设计能自我纠偏的系统）↓人的角色偏差拉回者+边界守卫者+价值定义者↓AI的位置必须是"为中心"，否则会陷入不确定性回声室双爬坡无法启动↓工程化的唯一机制确定性的强迫接触（外加确定性裁判）↓落地策略闭环优先+节点逐步开放↓组织结构继承分治网络↓演进路径六阶段演进+法不变同理复制↓真正最难的瓶颈场景驱动的隐性知识蒸馏↓终极人力位置产线设计师+认知边界守卫

12.2 当前的窗口期

我会说一句可能有点煽动的话：这是一个会被五年后回看才意识到价值的窗口期。

认真把"AI 为中心 + 闭环优先 + 分治继承 + 隐性知识蒸馏"这一整套做透的团队，很可能会不远将来对 Copilot 玩家形成代际碾压——就像福特对手工作坊那样。

结语

过去五十年，软件工程一直在"管理人的不确定性"，但从未真正工程化过。

大模型让"用能源换取高阶智能"第一次成为可能——这才是软件工程真正降临的时刻。但降临不是自动完成的，它需要一场范式的真正变更：

范式上：从"人为中心 + AI 辅助"转向"AI 为中心 + 人工辅助"。
机制上：把"确定性的强迫接触"做成 AI 输出的工程化裁判。
结构上：继承人类组织的分治网络，建立"分工协调总线"。
路径上：闭环优先而不是节点替换，从形式化最高的"编码 + 测试"节点起步。
门槛上：攻克"场景驱动的隐性知识蒸馏"这道最难的关。
人的位置上：从"人肉编译器"重新定位为"产线设计师 + 偏差拉回者 + 价值定义者"。

这不是一个工具升级的问题，是一场比工业革命更深的工程哲学变革。它的真正含义是：软件工程，第一次有可能成为一门和经典工程并列的、真正意义上的工程学。

而这场变革的入场券，发给那些敢于"立刻停止把 AI 当作一个更聪明的键盘，开始把它当作一个有待建设和校准的能源驱动工程系统本身"的人。

智能体沙箱Allox即将开源：让大模型从“问题回答”走向“任务执行”

Sun, 24 May 2026 19:51:00 +0800

原创鲁游张纪岩 2026-05-24 19:51 上海

我们设计了Allox，一个面向智能体统一接入的执行沙箱。Allox以更稳定、更低token损耗的CLI控制面统一完成沙箱创建、任务执行、文件传输和策略审计，让Agent在可隔离、可治理、可恢复的环境里完成真实任务。

Agent 时代的Sandbox

智能体执行环境的安全边界

过去几年，我们对大模型风险的讨论，主要集中在“它会说什么”，比如模型可能编造论文，给出错误建议，误解用户意图，或者输出带有偏见和风险的内容。换句话说，在Chatbot阶段，大模型的主要风险发生在输出层：它说的话能不能信，它生成的内容有没有错。随着智能体（Agent）的出现，当大模型不再只是回答问题，而是开始调用工具、执行命令、读写文件、访问网页、连接数据库、操作浏览器甚至修改代码仓库时，风险开始出现在执行层：大模型不再只是“说错话”，而是变成了“做错事”。智能体时代，大模型风险正在从内容风险转向执行风险。

一个Agent在完成任务时，通常不会只生成一段文本。它会经历一条连续的执行链：理解任务→制定计划→调用工具→读取结果→修改计划→再次执行。在这个过程中，Agent可能会运行shell命令、安装依赖、访问外部网页、读取本地文件、调用API，甚至修改项目代码。这些能力让Agent变得真正“能做事”，但也让它拥有了真实世界中的副作用。例如：

▴ 误删文件，覆盖配置，读取不该读取的密钥；

▴ 访问未知域名，安装不可信依赖；

▴ 在网页、邮件、PDF 中受到间接提示注入影响；

▴ 在看似合理的多步工具调用中，把一个小错误放大成真实损害；

2026年4月，PocketOS创始人公开称，一个运行在Cursor中、由Claude驱动的编程Agent在执行任务时，找到了权限过大的Railway API token，并删除了生产volume。相关报道指出，该操作没有经过确认步骤，而且备份也受到影响，导致客户预订、注册和记录短时不可用。这个事件暴露的问题并不只是“模型犯错”，而是Agent获得了可以触达生产环境的真实权限，缺少破坏性操作审批、生产/备份隔离和最小权限控制。此外，Vercel在2026年4月发布的安全公告中提到他们的智能体使用了第三方工具Context.ai，攻击者利用该工具访问并接管了一名员工的Vercel Google Workspace账号，枚举、解密了部分敏感环境变量，导致数据泄漏。

OWASP在LLM Top 10中将这类问题称为“过度授权”（Excessive Agency），即当模型被赋予过大的工具权限或外部系统权限时，模型输出、幻觉或注入攻击可能触发真实动作。OWASP Agentic Application风险中也进一步强调，Agent的工具滥用、权限继承、链式调用和外部内容注入，会形成传统Chatbot不具备的新攻击面。大模型提示词（Prompt）可以告诉模型“不要删除重要文件”“不要访问敏感信息”“不要执行危险命令”，但一旦模型误解任务、被外部内容注入，或者在多轮执行中偏离原本工作流，单靠自然语言规则很难真正阻止副作用发生。这时，Agent需要一个更硬的边界，这个边界就是执行沙箱（Sandbox）。

传统意义上的Sandbox，通常指一个隔离环境：把不可信代码关在容器、虚拟机或受限进程里运行，限制它访问宿主机文件、网络和系统资源。但Agent场景下的Sandbox，不能只被理解为“一个跑代码的容器”。因为Agent不只是执行一段代码，它会持续运行，它需要文件系统，需要 shell，需要浏览器，需要网络，需要长期任务上下文，也需要被审计、被限制、被回滚。所以在Agent时代，Sandbox更准确的定义应该是“围绕智能体行动能力建立的执行边界系统”。它规定了Agent在哪里运行、能访问什么、能调用哪些工具、哪些动作需要审批，以及整个执行过程如何被记录、追踪和恢复。

从现有Sandbox到Allox

我们如何设计智能体执行边界

如果说前一部分回答的是“为什么Agent需要Sandbox”，那么接下来要回答的是另一个更具体的问题：这个Sandbox到底应该长什么样？现有国内外方案已经给出了不同答案，但它们往往各自强调某一类能力：有的强调云端安全代码执行，有的强调API统一管理，有的强调浏览器、终端和文件系统的一体化，有的强调microVM级强隔离。对于Allox而言，我们并不希望简单拼接这些能力，而是希望提供一个对于Agent来说容易接入，对于开发人员来说沙箱内容容易配置的统一智能体沙箱，让Agent可以在一个独立、可控、可观测、可回滚的环境中完成代码生成、测试执行、网页访问、文件处理和工具调用等任务。在介绍 Allox之前，我们先看一下当前国内外Agent Sandbox相关工作的技术形态。

国内外Agent Sandbox的主要技术形态

当前面向Agent的Sandbox都在回答同一个问题：当Agent需要真正执行任务时，应该把它放在哪里执行，以及如何限制它的行动范围。主要可以分为四类。

▴ 云端托管式代码执行环境：典型代表是CubeSandbox，这类面向Agent的云端Sandbox，它通过SDK为Agent提供隔离的代码运行环境，开发者可以上传文件、执行代码、读取输出，并在任务完成后销毁环境。但这类方案通常更偏向“远程代码运行时”，它解决的是Agent 在云端安全运行代码的问题，而不一定完整覆盖本地开发工作流、代码仓库调试、浏览器协同、企业内网部署，以及Agent对执行环境的持续治理需求。

▴ 一体化开发环境沙箱：这类方案比如AIO Sandbox，把Shell、文件系统、浏览器、Notebook、MCP工具等能力集成到同一个容器环境中，使Agent不只是能运行一段代码，而是能够在一个完整工作区里完成“读文件—改代码—运行测试—查看网页—迭代测试”等。

▴ 通用Sandbox管理平台：这类系统比如OpenSandbox，通常关注沙箱生命周期管理，例如创建、启动、暂停、销毁、文件传输、命令执行、日志诊断、网络策略配置等。它们不一定绑定某一种Agent，而是提供一套通用API或SDK，使不同Agent都能调用Sandbox。这类平台把Sandbox从一次性的执行容器，提升为可以被管理、被调度、被诊断的基础设施。

▴ 强调强隔离的microVM或轻量虚拟化：这类方案比如MicroSandbox，不同于容器化方案，通常用更强的虚拟化边界来运行不可信代码，适合公网、多租户、高风险代码执行等场景，但在启动速度、镜像生态、调试便利性和部署复杂度上也会付出额外成本。

总体来看，现有Agent Sandbox方案已经分别在代码执行、工具集成、生命周期管理和强隔离等方面提供了有价值的能力，但它们往往只覆盖了智能体执行需求的某一个侧面。真实的Agent任务并不是简单运行一段代码，而是需要在持续的任务工作区中读写文件、调用工具、执行命令、访问网络，并根据反馈不断迭代。与此同时，现有方案对 Agent 和开发者来说也存在一定接入成本：有的需要适配特定SDK或API，有的需要开发者额外封装工具调用入口，有的需要手动配置容器、镜像、网络和文件挂载，导致Agent不容易快速接入，开发者也难以用统一方式复现、调试和治理任务过程。我们希望一个Agent Sandbox不仅要能提供隔离环境，还要能统一组织任务上下文、多工具协同、权限边界、执行治理和过程审计，并提供对Agent和开发者都足够简单的统一入口。换句话说，Agent Sandbox的设计核心不只是“把Agent放在哪里运行”，而是“如何让Agent低成本接入，并在可控、可观测、可恢复的边界内完成真实任务”。

Allox设计：从四个组件维度，到六类行动边界

在工程实现中，我们可以把Sandbox拆成执行隔离层、任务工作区、多工具执行场、执行治理层四个组件。执行隔离层负责为Agent提供独立的运行环境，将任务执行与宿主机隔离开来；任务工作区负责为每个任务创建执行空间；多工具执行场则负责组织工具调用；最后，执行治理层提供命令执行、文件访问、网络连接、工具调用等关键节点的策略检查。

此外，我们可以从六类边界来描述Sandbox的核心能力：文件边界、网络边界、命令边界、身份边界、资源边界和审计边界。它们分别回答Agent能读写什么、能访问哪里、能执行什么、以什么身份执行、能消耗多少资源，以及执行过程如何被记录和追踪，这六类边界共同构成了Agent Sandbox的能力基线。

基于上述分析，我们设计了Allox，一个面向智能体统一接入的执行沙箱。Allox以更稳定、更低token损耗的CLI控制面统一完成沙箱创建、任务执行、文件传输和策略审计，让Agent在可隔离、可治理、可恢复的环境里完成真实任务。Allox的目标可以概括为四句话：第一，为Agent提供独立的执行隔离，并支持智能体快速接入；第二，为每个任务提供可持久、可销毁的工作区；第三，把 Shell、浏览器、文件系统等能力组织成统一的多工具执行场；第四，对Agent的执行过程进行记录、约束和治理。Allox在现有容器生态和Agent工具链的基础上，形成了一个面向Agent执行的统一控制层，把沙箱生命周期、任务工作区、多工具能力和执行治理组织起来，使开发者、Agent都可以用一致的方式使用Sandbox。

▴ 在执行隔离层上，Allox通过容器为每个Agent任务提供独立运行环境，将任务执行与宿主机隔离开来。相比直接在本机运行Agent，容器化沙箱可以限制文件系统、进程空间、资源使用和环境依赖，降低误操作对真实机器的影响。

▴ 在任务工作区上，Allox为每个任务创建独立工作区，Agent的文件读写、代码修改、依赖安装、测试运行都在该工作区内完成。任务结束后，工作区可以保留用于复盘，也可以被销毁以清理副作用。

▴ 在多工具执行场上，Allox把Shell、浏览器、文件系统、Notebook、编辑器和外部工具放在同一个沙箱上下文中，使他们共享同一个工作区、同一组文件和同一套执行状态。

▴ 在执行治理层上，Allox不希望Sandbox只是一个临时容器，而是希望它成为Agent执行过程的治理入口。Allox在命令执行、文件访问、网络连接、工具调用等关键节点加入了策略检查、风险提示、审批确认、日志记录和异常回滚的治理措施。

▴ 在文件边界上，Allox将Agent的读写范围限制在任务工作区中，并避免默认暴露宿主机敏感目录。对于需要输入的代码仓库、数据文件或配置文件，Allox可以通过显式挂载、复制或上传的方式进入沙箱，而不是让Agent直接访问开发者本机环境。

▴ 在网络边界上，Allox可以根据任务需要配置网络访问策略。对于不需要联网的任务，可以默认关闭网络；对于依赖安装、网页访问或API调用，可以通过白名单、代理或受控出口进行访问，避免Agent任意连接未知外部资源。

▴ 在命令边界上，Allox可以将Agent的命令执行收敛到统一入口。所有shell命令不再直接运行在宿主机，而是在沙箱中执行；同时，高危命令、长时间运行命令、后台进程和破坏性操作可以被进一步识别、记录或拦截。

▴ 在身份边界上，Allox可以避免Agent默认继承开发者本机身份。对于需要凭据的任务，可以采用任务级凭据、短效Token或最小权限授权，使Agent即使发生错误调用，也不会获得超出任务范围的能力。

▴ 在资源边界上，Allox可以为每个沙箱设置 CPU、内存、磁盘和运行时间限制，防止Agent因错误循环、测试卡死或依赖安装异常耗尽宿主资源。任务完成后，沙箱可以自动停止或销毁，释放占用资源。

▴ 在审计边界上，Allox可以记录沙箱创建、命令执行、文件变化、工具调用和任务结果，使Agent的执行过程不再是黑盒。开发者不仅能看到最终生成了什么，也能追踪Agent是如何一步步得到这个结果的。

Allox与现有 Sandbox 的能力对比

为了更清楚地说明Allox 的定位，我们将Allox和代表性的Sandbox进行了对比。

综合来看，Allox首先强调“边界优先”。我们从文件、网络、命令、身份、资源和审计六类边界定义 Agent可以做什么，再反推系统应该提供哪些接口，而不是先有一个容器再向外包装功能。第二，Allox强调“入口统一”。对于Agent来说，入口越多，调用越复杂，策略越难统一；对于开发者来说，入口越多，复现和排障越困难。Allox用CLI把开发者和Agent操作收敛在一条链路上，让沙箱既能被Agent调用，也能被开发者直接操作。第三，Allox强调“本地和内网优先”。很多强隔离云端方案更适合公网多租户，而大量真实需求发生在本地项目、实验室服务器和企业内网。Allox当前选择容器路线，是为了降低落地门槛，并让后续架构可以平滑扩展。

目前，Allox的第一版将于近期开放。后续，我们会继续增强Allox的策略治理能力，包括更细粒度的网络访问控制、高危命令识别、文件变更审计、任务级身份管理、执行过程回放。

Allox由复旦大学CodeWisdom团队的AI系统工程组博士生鲁游、硕士生张纪岩、张坤、黄鑫渝、郝硕共同参与研发。团队聚焦大模型智能体基础设施研究，包括智能体构造、可观测体系、测试与保障、工具调用与Skill优化等，致力于构建更可靠、更可控、更易落地的智能体基础设施。

作者简介

鲁游

复旦大学CodeWisdom团队AI系统工程组博士。主要研究方向包括自动驾驶系统测试，大模型智能体测试与保障。

张纪岩

复旦大学CodeWisdom团队AI系统工程组硕士。主要研究方向包括模型合并技术、大模型智能体构造。

参考文献

OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications 2026.
OWASP Agentic Security Initiative. Agentic AI: Threats and Mitigations.
Alibaba. OpenSandbox: Secure, Fast, and Extensible Sandbox Platform for AI Applications. GitHub repository.
Agent-Infra. AIO Sandbox: All-in-One Sandbox for AI Agents. GitHub repository.
TencentCloud. CubeSandbox. GitHub repository.
superradcompany. microsandbox: secure, local and self-hosted microVM sandboxes. GitHub repository.

审核丨陈碧欢

排版丨牛嘉阳

欢迎关注CodeWisdom，Codewisdom平台由复旦大学软件工程实验室运营，提供智能化软件开发平台及线上沙龙相关资讯，关注可了解更多智能化软件开发的最新消息~

跳转微信打开

活动预告｜CodeWisdom 可信AI系统系列学术报告第12期：Toward Seeing What Agents Do: Interpretive Work in the Age of Agentic AI

Mon, 18 May 2026 16:22:00 +0800

CodeWisdom 2026-05-18 16:22 上海

报告时间：2026年5月25日（周一）下午15:30-17:00

Jie Gao

Johns Hopkins University

内容简介

题目

Toward Seeing What Agents Do: Interpretive Work in the Age of Agentic AI

摘要

Interpretive work means turning unstructured data (meeting transcripts, codebases, scientific literature, patient interviews) into structured understanding through human judgment. It is central to fields from scientific research to healthcare, law, and policy. As AI agents take on increasingly autonomous roles in this work, we have reached a turning point. Agents can now perform interpretive work end-to-end, yet we lack methods for seeing what those agents actually do, understanding how they work alongside humans, and judging whether they do it well. In this talk, I will present three lines of work, from supporting the humans who do this task, to building agents that automate it, to seeing what those agents actually do. First, I support humans doing interpretive work with AI systems: CollabCoder (CHI 2024) for qualitative analysis and CodeMap for code comprehension. CodeMap received an ACM SIGSOFT Distinguished Paper Award at ICPC 2026 and showed that cognitively aligned LLM-based visualization reduces developers' reliance on raw LLM output. Second, I automate this work with multi-agent systems. My recent work, LLM-as-Peer-Debriefer, uses peer-debriefing agents, each grounded in a different perspective from qualitative research, to refine agent-generated analysis and bring it closer to human interpretation. This work led me to a question the field can no longer avoid: what are these agents actually doing as they perform interpretive work? Third, and the main focus of my research going forward, I see what autonomous agents do as they work, using social science methods like Grounded Theory to interpret their behavior, build behavior profiles across and within agents, and help humans locate where agents fail. Lastly, I will present next steps: analyzing how agent systems behave, evaluating AI-generated interpretations, and extending these methods to high-stakes domains such as healthcare, where the cost of misinterpretation is high. Together, these steps aim at a single goal: making it easier to see, understand, and improve what agents do, so humans can oversee and deploy them well.

报告人

Jie Gao (https://gaojie058.github.io/) is a Malone Postdoctoral Fellow at Johns Hopkins University, jointly affiliated with the Malone Center for Engineering in Healthcare, the Data Science and AI Institute, and the Center for Language and Speech Processing, where she is mentored by Mark Dredze, Ziang Xiao, and Chien-Ming Huang. She has worked in computer-assisted qualitative analysis since before the rise of LLMs. Her research studies how humans perform interpretive work and how AI can support it, across qualitative analysis, code comprehension, and agent behavior analysis. Her recent work on CodeMap received an ACM SIGSOFT Distinguished Paper Award at ICPC 2026. Earlier work on CoAIcoder (TOCHI 2023) and CollabCoder (CHI 2024) introduced early designs for human-AI collaboration in qualitative analysis, now widely adopted in the field. Her work has been published in venues including CHI, TOCHI, ICPC, UIST, and Ubicomp, with additional work at EMNLP workshops. She also developed mindcoder.ai, a publicly deployed platform for AI-assisted qualitative analysis. Before Johns Hopkins, Jie was a Postdoctoral Researcher at MIT's SMART program in Singapore, working with Thomas W. Malone on collective intelligence and human-AI teams. She received her PhD from the Singapore University of Technology and Design (SUTD) under Simon Perrault, and visited as a PhD student at the University of Notre Dame and the National University of Singapore. She serves as Associate Chair for the CHI Main Track (2025, 2026), and has reviewed for CHI, CSCW, UIST, AIED, ACM TIIS, IJHCI, and Empirical Software Engineering. She also co-organized the CHI 2024 workshop "LLMs as Research Tools."

时间安排

❖

时间：

2026年5月25日（周一）下午15:30-17:00

❖

地点：

复旦大学江湾校区交叉二号楼D2009

跳转微信打开

Agentic AICon之“智能体赋能软件研发”专场

Thu, 14 May 2026 08:00:00 +0800

CodeWisdom 2026-05-14 08:00 上海

2026年6月5日，上海明捷万丽酒店二层宴会厅

Agentic AICon（智能体应用与架构工程大会）之“智能体赋能软件研发”专场。由复旦大学CodeWisdom团队和它的朋友们共同献上！

时间：2026年6月5日9:00-18:30

地点：上海明捷万丽酒店二层宴会厅（上海市普陀区铜川路50号）

跳转微信打开

开源风险治理平台“伏羲”在安全补丁迁移中取得重要进展，助力开源软件安全风险缓解

Wed, 13 May 2026 09:00:00 +0800

CodeWisdom 2026-05-13 09:00 上海

聚焦开源安全补丁迁移难题，基于语法语义增强的大模型，赋能自动化补丁迁移

研究背景：安全补丁迁移是开源软件供应链风险缓解的重要手段

随着开源软件的广泛应用，越来越多的软件系统依赖开源组件、复用开源代码，并基于上游项目形成多个长期维护分支或下游衍生项目。当上游项目披露漏洞并发布安全补丁后，相关补丁是否能够及时、准确地迁移到其他受影响分支或下游衍生项目中，直接关系到开源软件供应链的整体安全水平。

然而，在真实开源生态中，安全补丁的迁移既不全面也不及时。一项针对26个流行开源项目、806个 CVE 的实证研究表明，超过80%的CVE-分支对从未完成补丁迁移；在这些未修复漏洞中，47.39%属于高危或严重漏洞；即使最终完成修复，平均也需要 40.46 天。更值得关注的是，约20%的漏洞已经存在公开PoC，这意味着攻击者可以在补丁尚未迁移到受影响分支或下游项目之前，利用已公开信息实施攻击 [1]。

针对安全补丁难以及时迁移的问题，学术界和工业界已经开展了一系列研究。现有自动化补丁迁移技术大致可以分为两类：基于模式匹配的方法和基于大模型的方法。

第一类是基于模式匹配的补丁迁移方法。例如FixMorph [2]和TSBPORT [3]通过分析历史补丁，总结补丁修改模式，并在目标分支中寻找相似代码位置进行补丁适配。这类方法在处理结构相对稳定、修改模式较为明确的补丁时具有较好效果，但其能力高度依赖预先定义或学习到的补丁模式。当目标分支与原始分支之间存在较大语法结构差异、控制流重构或辅助函数变化时，模式匹配方法往往难以准确完成迁移。

第二类是基于大模型的补丁迁移方法。例如PPatHF [4] 尝试利用大语言模型理解源分支与目标分支之间的代码差异，并自动生成适配目标分支的补丁。相比传统模式方法，大模型具备更强的代码理解和生成能力，能够处理更加灵活的代码变化。然而，现有大模型方法为了压缩上下文而进行的预处理可能删除与漏洞相关但未被修改的关键代码；此外，PPatHF的大模型微调任务与真实补丁迁移任务不匹配，导致跨项目泛化能力受限；同时缺少有效的自动检查机制，模型生成的补丁一旦出现语义偏差或语法错误，难以及时发现和修正。

为了更直观地说明目前工作在安全补丁迁移中的局限，我们选取了两个真实漏洞补丁迁移案例进行分析。第一个案例来自OpenSSL 中的CVE-2023-0465。如图一所示，该漏洞源于check_policy函数对EXFLAG_INVALID_POLICY标志处理不当，可能导致证书链校验中的安全绕过。主分支中的原始补丁新增了针对异常策略标志的检查逻辑和错误处理逻辑，但当该补丁迁移到OpenSSL_1_1_1-stable分支时，由于两个分支在错误处理方式和控制流结构上已经存在差异，直接使用git cherry-pick会产生冲突，无法完成自动迁移。进一步地，基于模式的补丁迁移工具TSBPORT [3]虽然尝试生成目标分支补丁，但由于过度依赖预定义修改模式，错误地插入了重复检查，并将错误处理逻辑适配到不正确的条件分支中，最终破坏了原有校验流程，使函数无法按预期返回成功结果。该案例说明，安全补丁迁移不能只依赖局部代码块的语法模式匹配；当分支之间存在函数级语义差异时，工具必须理解漏洞修复逻辑与目标分支上下文之间的对应关系。

图一 CVE-2023-0465示例，（a）为master分支补丁，（b）（c）分别是由人类开发者和TSBPORT将master分支的补丁迁移到OpenSSL_1_1_1-stable分支的迁移补丁

第二个案例来自Wireshark中的CVE-2023-1994。如图二所示，该漏洞位于dissect_gquic_frame_type函数中，当指针gquic_info为空时，后续代码仍会将其传入被调用函数并访问其中字段，从而可能导致拒绝服务。人工补丁的核心修复非常直接：在使用gquic_info 之前增加空指针检查；并且该补丁在主分支和 release-3.6 分支中几乎一致，git cherry-pick和TSBPORT [3] 都能够成功迁移。然而，基于大模型的PPatHF [4] 反而迁移失败。其原因在于，PPatHF为压缩上下文会将未修改的复合代码块替换为占位符，但这一过程同时删除了与漏洞触发密切相关的关键调用语句；随后模型又错误移动了占位符位置，导致人工补丁中应出现的空指针检查没有正确生成；最后在恢复占位符对应代码后，生成结果同时出现语法错误和语义错误，危险的空指针使用仍未被修复。该案例说明，大模型具备代码生成能力并不意味着可以直接可靠地完成补丁迁移；补丁迁移仍然需要显式保留漏洞相关语义、对齐真实迁移任务，并对生成结果进行语法和语义层面的检查。

图二 CVE-2023-1994示例，由人类开发者（绿色部分）和 PPatHF（红色部分）在release-3.6分支中对dissect_gquic_frame_type函数进行补丁迁移

研究进展：基于语法语义增强大模型的自动化安全补丁迁移工具Mystique

为了解决安全补丁在多分支和上下游开源生态中难以及时迁移的问题，复旦大学CodeWisdom团队软件供应链安全小组在开源风险治理平台“伏羲”中进一步拓展了安全补丁治理能力，提出了自动化安全补丁迁移技术Mystique。相关研究成果发表于FSE 2025 [5]，并获得ACM SIGSOFT杰出论文奖。Mystique的核心思想是：面向安全补丁迁移任务，首先精准抽取漏洞修复相关的语义信息和语法结构，其次利用任务对齐的大模型进行补丁初步迁移，最后通过自动检查与迭代优化机制提高迁移结果的可靠性。如图三所示，该技术框架主要包括五个模块。

图三 Mystique整体框架图

（一）补丁函数语义与语法签名提取模块。该模块利用Joern生成代码属性图（CPG），针对增删的语句执行双向的数据依赖切片以及控制流切片（提取直接支配和后验支配语句）。然而，单纯的依赖切片会破坏代码的语法闭环，因此Mystique引入Tree-sitter构建抽象语法树（AST），对切片后的孤立片段进行严格的语法补全。这包括向上追溯并补全控制语句（如if、switch及对应的case）、补齐程序出口和跳转点（如break、return、goto）以及补全缺失的控制流大括号，从而生成既包含丰富语义又具备完整层级结构的特征名和。

（二）目标漏洞函数语义与语法签名提取模块。目标分支的代码通常已发生演进，变量名或逻辑可能已发生改变，因此直接套用原补丁往往会失效。该模块首先需要建立精准的语句映射。Mystique首先在该模块中计算补丁中删除的语句与目标漏洞函数中各候选语句的莱文斯坦距离（Levenshtein distance），当文本及结构相似度超过预设阈值（默认设为 0.55）时，建立候选映射。若直接匹配失败，会沿控制流迭代搜索支配和后验支配语句，以圈定大致的漏洞代码块。定位完成后，Mystique会对映射语句执行与模块一相同的CPG切片与AST语法补全流程，最终输出目标分支的漏洞特征名。

（三）补丁迁移提示词生成模块。该模块负责将提取的结构化签名转化为大模型易于解析的提示词。为了有效降低长上下文的Token消耗并直观凸显补丁前后的变更逻辑，Mystique将补丁签名巧妙地转化为类似git diff的格式，表示为。更重要的是，提示词模板中植入了四项硬性约束指令（C1-C4）：

- C1 强迫模型对补丁进行必要的环境适配；

- C2 限制模型不得进行与漏洞无关的修改，以防破坏原有功能分支的特性；

- C3 严禁模型增删或移动用于掩盖无关代码的“占位符”（Placeholders）；

- C4 警告模型切勿自行填充缺失的代码片段，以此规避幻觉带来的潜在语法错误。

（四）面向补丁迁移任务的大模型微调模块。为了使开源大模型（如CodeLlama）真正掌握跨分支移植的内在规律，Mystique摒弃了常规的代码生成预训练范式，转而构建了专门针对移植任务对齐的微调数据集。Mystique从历史真实项目中提取出时间跨度较长、针对同一漏洞的“原补丁-目标补丁”函数对，提取其签名组合。在训练阶段，模型采用低秩自适应（LoRA）技术，将庞大的模型权重分解为低秩矩阵以极大降低显存开销。模型以生成正确的目标后置签名为监督信号，通过 AdamW优化器不断最小化损失函数，确保微调后的模型能力与复杂的补丁移植任务深度契合。

（五）修复函数生成与迭代检查。即便经过定向微调，大模型仍不可避免地会产生逻辑谬误或语法瑕疵，因此该模块引入了基于启发式规则的“生成-检查-优化”闭环。模型首先生成初始签名，随后Mystique利用三道防线执行严格的异常拦截：

- 语义异常（A1）：Mystique分别计算补丁前后的演进差异与的编辑辑距离。若两者差距超过阈值（如），Mystique即可判定模型发生了“过度修复”（破坏了目标分支逻辑）或“修复不足”（未有效移植漏洞逻辑）；

- 占位符异常（A2）：Mystique通过AST锚定各个占位符的父子兄弟节点，以此核对模型是否在生成过程中非法挪动或删除了占位符；

- 语法异常（A3）：Mystique将占位符背后的真实代码块复原为完整的初始修复函数，并调用强类型的静态分析工具Clang-tidy进行编译级的语法纠错；

实验评估：Mystique在安全补丁迁移任务上的准确性与实用性

我们在694个CVE/1,359个漏洞函数上做了系统评测，对比对象包括2个模式方法（FixMorph、TSBPORT）、1个LLM方法（PPatHF）、4个通用大模型（GPT-3.5、GPT-4o、CodeLlama、StarCoder）。

工具有效性评估：如表一所示，在针对694个CVE（包含 1,359 个漏洞函数）的大规模基准测试中，Mystique展现出了卓越的补丁迁移能力。在函数级别（Function Level）和CVE级别，Mystique分别达到了0.954和0.924的修复成功率（Success Rate）。这一成绩显著超越了现有的最优方法，相比于基于模式匹配的先进工具TSBPORT，其在函数级和CVE级的成功率分别提升了13.2%和12.3%；而相比于直接使用顶尖的闭源大模型GPT-4o，其在函数级也高出18.5%。即使在少数迁移失败的案例中，Mystique生成代码的Code BLEU（C-B）得分也达到了0.921（为所有对比工具中最高），这说明其失败的输出与人类真实补丁的相似度依然极高，具备很好的参考价值。

表一 Mystique有效性实验结果

工具泛化性评估：如表二所示，Mystique在四个不同维度上证明了其强大的泛化能力。当替换底层的LLM（如换为StarCoder）、进行跨项目迁移（在 Linux 和其他项目间交叉测试）、处理非安全类的常规C语言Bug、甚至是跨越编程语言去修复Java漏洞时，Mystique依然保持了极高的成功率，全面且大幅地领先于现有基线工具。

表二 Mystique泛化性实验结果

工具实用性评估：为了验证该框架在真实软件开发环境中的实用性，我们将Mystique部署到开源生态中。如表三所示，Mystique自动为C和Java仓库的16个真实CVE成功迁移了34个补丁。团队将这些迁移结果作为拉取请求（PRs）提交给了上游仓库，最终共有29个PR获得了官方开发者的认可并被成功合并，表明了其在工业界的潜在落地价值。

表三 Mystique实用性实验结果

关于“伏羲”

“伏羲”是复旦大学CodeWisdom团队推出的开源风险治理平台，旨在推动学术与产业合作交流，提升开源软件供应链风险分析与治理能力。“伏羲”在高质量开源软件供应链知识汇聚的基础上，结合代码差异分析、调用图分析、程序切片、大模型辅助分析等技术，提供漏洞库、组件库、漏洞传播影响分析、生态投毒检测、同源漏洞检测、风险缓解等服务。安全补丁迁移是“伏羲”面向开源软件供应链安全治理的重要能力之一。未来，“伏羲”将继续围绕漏洞修复、组件版本升级、组件迁移等方向持续攻关，进一步提升开源生态中已知漏洞的自动化缓解效率，助力开发者更及时地降低软件供应链安全风险。

往期回顾：

“伏羲”在开源生态投毒检测中取得进一步重要进展

开源风险治理平台“伏羲”在漏洞传播影响分析中取得重要进展，助力开源软件安全治理

开源风险治理平台“伏羲”在同源漏洞检测中取得重要进展，助力开源软件安全治理。

参考文献

[1] Tan, Xin, et al. “Understanding the Practice of Security Patch Management across Multiple Branches in OSS Projects.” Proceedings of the ACM Web Conference 2022.

[2] Shariffdeen, Ridwan, et al. “Automated Patch Backporting in Linux.” Proceedings of ISSTA 2021.

[3] Yang, Su, et al. “Enhancing OSS Patch Backporting with Semantics.” Proceedings of CCS 2023.

[4] Pan, Shengyi, et al. “Automating Zero-shot Patch Porting for Hard Forks.” Proceedings of ISSTA 2024.

[5] Wu, Susheng, et al., “Mystique: Automated Vulnerability Patch Porting with Semantic and Syntactic-Enhanced LLM.” Proceedings of FSE 2025.

作者：

吴苏晟，陈碧欢

跳转微信打开

活动预告 | CodeWisdom软件智能化开发系列学术报告第20期：基于大模型的网络协议规约生成与测试技术

Tue, 12 May 2026 16:19:00 +0800

CodeWisdom 2026-05-12 16:19 中国台湾

南京大学时清凯《基于大模型的网络协议规约生成与测试技术》，5月14日中午11点

时清凯

南京大学计算机学院副教授，博士生导师

Summary

Title

基于大模型的网络协议规约生成与测试技术

Abstract

大模型已成为软件工程领域不可或缺的基础工具，如何将大模型作为黑盒工具有效应用于软件工程，缓解其固有的“幻觉”问题已成为当前重要的研究课题。本报告将以网络协议规约生成与测试为例，探讨一套旨在提高大模型生成形式化软件规约能力，并指导软件测试的综合方法：我们提出通过诸如“系统分治”、“自主对抗” 等机制引导与约束大模型，使其生成语法、语义都精确可靠的协议规约。实验表明，使用该方法获得的网络协议规约在语法、语义方面的精度及召回率接近99.9%，已帮助发现数十个传统模糊测试不能检测的非内存安全类问题。

Speaker

时清凯，南京大学计算机学院副教授，博士生导师，国家级青年人才。2020年于香港科技大学获得博士学位，曾任源伞科技联合创始人、蚂蚁集团技术专家、美国普渡大学博士后研究员。主要从事软件分析与软件安全技术研究，研究成果广泛发表于程序设计语言（PLDI、OOPSLA、CAV）、软件工程（ICSE、FSE、ASE）、网络安全（SP、CCS、USENIX Security）等领域的CCF A类会议或期刊。曾获ACM SIGPLAN或SIGSOFT杰出论文奖4次、Google论文奖、Hong Kong PhD Fellowship，曾三次参加全国软件大会原型竞赛均获一等奖。

Schedule

❖

时间：

5月14日 11：00～12:00

❖

腾讯会议：

会议号：846-976-312

密码：993733

❖

地点：

复旦大学江湾校区二号交叉学科楼A2003

跳转微信打开