To Run or Not to Run
系统分析 LLM 程序修复智能体中的代码执行成本与收益,说明执行反馈应被当作有成本的资源,而不是默认动作。
我是北京航空航天大学博士生,隶属于 SMAT 实验室,导师为黎立教授, 副导师为周鸣一。
研究聚焦于 AI for Software Engineering (AI4SE), 将大语言模型、程序分析与可验证的软件工程环境结合,构建更可靠的代码智能体与生态工具链。 工作横跨执行反馈、仓库级基准、变更影响分析、OpenHarmony 生态质量保障与低资源编程语言支持, 但都围绕同一个核心:让 AI 真正可靠地服务于软件工程实践。
大语言模型已经展现出很强的代码生成能力,但真实软件工程并不只需要「写出补丁」: agent 还要理解仓库、选择证据、控制执行成本、维护变更历史,并在特定生态中经得起验证。 我关注的核心问题是:如何把 LLM 的生成能力、程序分析的确定性与真实软件工程环境结合起来,构建可靠的代码智能体与生态工具链?
在代码智能体场景中,分析执行反馈何时值得使用(To Run or Not to Run), 并用轻量静态结构提升仓库导航稳定性(CodeAnchor); 在 OpenHarmony 生态中,把领域规则、静态分析、LLM 与真实反馈结合起来做修复、迁移和性能分析(HapRepair、Phantom Rendering Detection); 在评估层面,系统分析 LLM 究竟理解了什么代码知识,以及 AI4SE 工具应该如何被可靠衡量。
系统分析 LLM 程序修复智能体中的代码执行成本与收益,说明执行反馈应被当作有成本的资源,而不是默认动作。
研究轻量静态结构如何作为确定性锚点,提升代码智能体在真实仓库中的定位稳定性、复现性与导航效率。
识别和分析 UI 中不必要的渲染计算,帮助开发者发现隐藏的性能瓶颈,提升移动应用流畅度。
提出多智能体强化学习框架,动态评估 LLM 安全防线的越狱漏洞,揭示现有防御机制的系统性弱点。
四条主线共享同一个问题:如何让代码智能体在真实软件工程环境中既可靠又可验证。点击展开细节。
OpenHarmony 应用性能分析工具,用于检测 UI 中的 Phantom Rendering 问题。
FSE 2026 · GitCode
OpenHarmony 静态检查与自动修复工具,HapRepair 的核心模块。
FSE Industry 2025 · GitCode
Android → OpenHarmony 应用迁移工具,辅助应用进入鸿蒙生态。
迁移工具 · GitCode
AI 驱动的科研桌面应用:文献管理、智能阅读笔记与 Research Idea 生成。
Electron + TypeScript · GitHub
面向 Codex / Claude Code 的 SKILL 覆盖分析与优化框架。
Agent Skills · GitHub
OpenHarmony / 移动应用质量
合作主题:OpenHarmony 应用修复、Phantom Rendering / UI 性能分析、Cangjie 低资源语言微调
LLM 代码理解 / AI4SE 评估
衷心感谢 Wei Ma 老师带我走上科研道路。刚开始接触科研时,是他在选题、论文阅读、实验设计和写作上给予了持续而耐心的帮助;我的许多早期科研训练都离不开他的指导与支持。
合作主题:LLM 代码理解与语义评估、MazeBreaker 自适应评测、AI4SE 开源生态与实证研究
LLM Agent / 执行效率
也衷心感谢 Zhensu Sun。在我逐渐能够独立提出研究想法之后,他仍然在问题定义、实验设计、论文叙事和局限分析等方面给予了许多建设性的意见,帮助我学会把初步 idea 打磨成更完整、更扎实的研究工作。
合作主题:LLM 编程智能体、执行成本与延迟优化、代码生成与程序修复评估
平时喜欢运动,是陈奕迅和张敬轩的忠实歌迷,也爱玩 NBA 2K、FIFA 等体育类电子游戏。 相信好的研究和好的生活一样,需要节奏感。