当我们驾驶自动驾驶汽车穿梭都市、用智能语音助手规划日程时，一个人、机、物三元融合的智能时代已悄然来临。然而，在这幅便捷生活的图景之下，软件安全风险如同一座座深海中的冰山：传感器采集的5%误差可能导致致命的转向，被我们无条件信任的编译器竟可能成为暗藏的“代码杀手”，而机器学习模型与硬件故障的叠加，更让问题的根源难以追溯。
如何为这个日益复杂的世界筑牢安全防线？
中国科学技术大学9511校友、南京大学计算机学院教授、国家级人才计划入选者许畅，在软件安全领域深耕十七年，正致力于破解这个时代的“安全困局”。从人机物系统的“第一道防线”输入验证，到守护软件“地基”的编译测试，他带领团队不断向基础软件的“卡脖子”难题发起冲击。
2025年5月17日，安徽寿县，许畅教授在第四届华夏计算机科技英才班学术交流会上作《智能人机物系统安全：从输入验证和编译测试的角度》报告，我们有幸在报告会前和他进行了一对一深度采访，本文为采访实录的上篇。
在本篇专访中，我们将跟随许畅教授的思绪，深入其学术报告的核心，探讨智能系统面临的根本性挑战、编译测试的“蝴蝶效应”，以及他对GPT时代软件“可成长性”与产学研结合的深邃洞见。这不仅是一场技术的剖析，更是一次对未来软件方法论的前瞻。
受访者：许畅（中国科学技术大学9511校友，南京大学计算机学院教授、博士生导师，国家级人才计划入选者）
采访时间：2025年5月17日
采访人：薄震宇、王劲博
编辑：郭东昊
【第一部分：智能人机物系统的安全挑战】
5%误差如何颠覆自动驾驶？
Q：
您的报告聚焦"智能人机物系统安全"，从输入验证和编译测试切入，能不能概括一下核心观点？
许畅教授：
当前我们正经历一场重要的技术变革：人机物融合时代的到来。在传统计算机时代，我们只需编写程序在电脑运行，而如今通过传感器、控制器等泛在计算技术，形成了人-机-物三元融合的生态系统。其次是大语言模型等智能化工具深度融入生活，这种新型AI与传统程序化预测有本质区别。
在这个背景下，软件安全面临全新挑战：一方面是系统复杂度呈指数级增长，软件开发与质量维护难度陡增；另一方面是人机物融合系统存在环境感知误差等固有风险。对此我们提出三大技术支柱：
第一是输入验证。以无人驾驶为例，传感器采集的环境数据存在5%以内的固有误差，但系统必须在这种不确定输入下保持可靠运行。输入验证就是要确保软件系统的"第一道防线"可靠。
第二是编译测试。就像CPU芯片故障会导致整个系统崩溃，编译器作为软件基础层，其可靠性直接决定上层应用安全。我们曾遇到编译器将正确逻辑编译成错误指令的情况，这种底层错误往往难以察觉却危害极大。
第三是系统调试。当出现问题时，需要精准定位是算法错误、编译错误还是硬件故障。特别是在智能系统中，机器学习模块的预测误差与编译错误可能相互交织，需要新的调试方法论。
Q：
您深耕软件质量保障领域多年，曾获国家科技进步二等奖、CCF青年科学家奖等荣誉。从您的经验看，当前智能人机物系统安全领域面临哪些核心挑战？近五年行业的研究重心发生了哪些显著变化？
许畅教授：
这个问题，我想从我的经历说起。我读书和做科研的时间比较久，本科5年、硕士3年、博士5年，读书一共13年。现在到南京大学工作已经15年了，中间还有两年在香港，工作共17年。这么多年下来，我看到软件的形态在慢慢变化。
最早的时候，我们都只是做普通程序，我也喜欢写程序，甚至本科时自己写游戏。这些经历让我慢慢转向软件科研的方向。最开始是PC端的软件，后来是移动软件，再到今天的智能人机物系统，软件和环境之间的关系变得更复杂了。
过去手机上没有什么软件，只能打电话发短信，但现在大家都知道可以点外卖、打游戏、放音乐。这种环境要求软件更轻量、更适应环境，特别是非功能性需求，比如能耗、性能、安全等。这些特性对软件提出了新的挑战。
比如一个看似简单的Excel，其实也属于一种终端用户软件，用户可以写公式、写脚本、自动更新数据——这其实也是程序。随着软件智能化程度提升，与机器结合的越来越多，带来了控制、传感等方面的不确定性，对软件质量的要求也更高。
我总结下来，现在做软件的人要关注两点：一是程序开发的效率，二是软件的开发质量。这两个方向是我们的重心，形态变了，但方法和目标没有变。
Q：
您提到研究重心从形态转向了方法，能否展开讲讲？
许畅教授：
是的，现在的研究更注重“软件的方法学”。这个词听起来很虚，但它很重要。就像古代的孔子、老子、孟子讲的那些思想，并不是讲一件具体的事情，而是讲“怎么做事情”的方法。同样，我们也希望不仅是写个程序，而是让后面的人也能沿用这个方法。
我们经常说，一个好的软件方法要能沉淀成工具，这样即使后面的人不懂这个方法，也能用工具做出来。比如判断一家软件公司是否成熟，有个重要标准是：有没有“个人英雄主义”。如果靠一个人撑着，一旦他走了，项目就崩了，这就是不成熟。反过来，如果工具和方法沉淀下来，别人也能接手，就是可持续的。
所以目前的挑战在于，不仅要关注“怎么做”，还要考虑“别人怎么接着做”，这是软件工程研究真正的难点，也就是方法论。
【第二部分：编译测试与基础软件的“破壁”法则】
“希望同学们突破课堂编程的思维定式”
Q：
您希望学生通过讲座获得哪些启发？
许畅教授：
希望同学们突破课堂上编程教学的思维定式。传统的编程教学是给定确定输入输出，验证算法正确性即可。但现实系统要面对三大挑战：
1）环境感知的固有误差，如自动驾驶的传感器误差；
2）人机物融合带来的输入不确定性；
3）基础层（编译器/芯片）可靠性对整体系统的影响。
这些复杂性要求工程师必须具备系统级思维，理解从物理感知层到智能决策层的全栈安全。特别是要重视基础软件研发，当前国际形势下，编译器等"卡脖子"技术的自主可控具有战略意义。
编译器的「蝴蝶效应」
Q：
编译测试在系统安全中的独特价值如何体现？
许畅教授：
编译测试的特殊性在于其"基础放大器效应"。我们做过实验：当编译器存在万分之一错误率时，经其编译的自动驾驶系统错误率会指数级放大到千分之一。这就像精密钟表里一个齿轮的微小偏差，最终导致整点报时完全错误。典型案例是某工业控制系统升级时，新编译器将安全校验代码优化掉了，导致系统直接执行危险指令。由于编译器被视为可信基础层，这类问题往往排查困难。我们团队研发的差分编译测试技术，通过多编译器交叉验证，成功发现并帮助修复了GCC编译器的数十个安全隐患。
这些实践说明，在智能时代，安全防护必须下沉到基础层。就像建造摩天大楼，地基的微小缺陷都可能导致灾难性后果。编译测试正是守护软件"地基"的关键技术。
Q：
您的研究方向涵盖软件工程、编译技术、系统安全等多个交叉领域。您认为这种跨学科融合对解决系统安全问题有什么必要性？
许畅教授：
我们现在不仅做软件本身，也要做工具链开发、操作系统、程序语言，甚至支持国产替代。每个方向都有自己的挑战。如果只关注其中一个面，可能会比较弱。所以我建议年轻人要广泛接触，才能有更全面的能力。做系统安全，本质上是多个方向合力的结果，靠单一角度使力可能无法解决根本问题。
【第三部分：GPT时代的展望与产业思考】
大模型：工具还是奴隶？
Q：
您提到大语言模型用途很广，是一个很好的工具。您觉得未来这类AI技术在编译测试、速度验证中会起到什么作用？
许畅教授：
简单说，像大语言模型这样的技术是一种表现形式，更早的时候是神经网络，还有各种机器学习算法。我们统一称它们为“智能化手段”。这些手段现在越来越有用，不仅在机器学习领域，在很多别的领域也在用。所以首先不要忽视它们——它们确实有用，我们要承认这一点。
如果我们未来想进入软件领域，首先要有基本的编程能力，再具备编译分析能力，然后结合智能化手段去做。拥有这些手段后，首先你要想清楚你想干什么，再去使用它，而不是直接丢个问题进去希望它帮你解决；如果你问得太粗，它也给不出想要的答案，即使给了你也不一定懂——因为你自己都还没弄明白你要干什么。所以，我们得先想清楚问题，再借助这些手段，效果才会好。这些智能化手段是助力，而不是替代。
软件的「可成长性」
许畅教授：
我现在重点关注的一个问题是：“软件的可成长性”。你们可能注意到，写代码时常常是“给定需求，写完就结束了”。但软件行业不是这样。很多公司都有自己的核心产品，它们不是一锤子买卖，而是一直在旧软件的基础上迭代。有时候必须要重写，但很多时候是在原有基础上不断加功能。
问题来了：你当初设计这个软件的时候，有没有考虑到未来会增加哪些功能？
所以，我本科、研究生时开始关注“设计模式”这个话题。它并不决定正确与否，但确实能影响软件是否好维护。有的软件加功能容易，有的找 bug 容易；但也有的软件“加个功能就全炸了”。这其实是软件可维护能力的体现，叫做“关注点分离”（Separation of Concerns），也就是你们说的“高内聚低耦合”。
高手与低手的区别不是有没有 bug，而是出了 bug 能不能快速定位，软件能不能维护。好的设计能让你清楚地知道在哪加代码，差的设计你加起来就很容易出错。质量，不只是说写得对，更重要的是“可复用性”。很多其他专业的人可能不太理解，觉得能跑就行，但是搞软件研究的人深刻明白这点。
所以我提到的“软件可成长性”就和这相关。当年我们关注设计模式带来的软件可复用性，现在我们关注更大范围的问题——软件是否能够不断演化。有的软件随着加功能，就变得不可维护。我们需要明确这些差别，并指导学生写出“可成长性更好”的代码。
而我当前的重点，就是将“代码能力”、“设计抽象”、“智能手段”这几个方面结合起来，构建一个真正“可成长”的软件系统。现在我们有大语言模型，也许可以借它的手段来辅助软件实现这样的“可成长性”。
Q：
您对国内软件质量保障领域的研究生态有何期待？您认为推进大软件领域的学术界与产业界的结合是否有助于这一点？
许畅教授：
我觉得这个问题对你们来说可能早一些，我就分享下我们现在的体会吧。
你们从本科到研究生，基本都是跟老师打交道，除非准备实习才会开始接触企业。实习时得刷题，甚至开始真正做项目。时代变了，以前学生本科想去实习，我是支持的，因为那时候是“黄金时代”，企业很多、机会多，大家实习后回来反而会觉得工作挺无聊的，于是更愿意继续读研。
那时候找工作不难，企业也不指望本科生能做出什么，安排点测试或者跟着师兄做点事就行。可现在不一样了，大家都意识到想找份“满意”的工作并不容易，于是会更认真地对待实习，也更愿意从中学习东西。
随着我们老师与工业界的合作越来越多，我发现很多时候我们说“工业界有很多真实需求”，这话说起来容易，但真正做起来挑战很多。比如，为什么好事做不好？其中有很多深层原因。企业确实面临很多困惑，他们自己也没有时间去解决。比如华为，从做电信起家，到现在做操作系统、编程语言、智能驾驶等，软件方面做得也非常不错。华为员工非常忙，这只是他们承受压力的一个方面。有的公司扛不住压力就倒闭了，而华为还在坚持，还在努力。这背后也是他们文化的一部分。
我现在是CCF系统软件专委的副主任，我们跟企业有很多合作。不只是学术界之间的交流，也搭建起了学术界与企业之间的桥梁。比如华为的员工很活跃，他们内部有KPI制度。你们做采访时也有KPI吧？完成任务、整理报告，其实也挺辛苦的。他们那边也有类似的制度，虽然我不清楚具体怎么规定，但我看到他们真的很主动，会组织workshop、走进高校、跟我们交流技术问题。
比如今天刚接待了一个华为部门，明天又是另一个部门来了，他们每个团队都有自己的任务，有问题就来找我们讨论。他们在一边被KPI驱动的同时，也确实提出了很多实际问题。我曾在香港读书时就听说，他们当时面临一个问题：他们招了很多程序员，但不都是最优秀的，比如清华北大的学生很多去了国外，早期招进来的程序员可能代码质量不高。后来招聘质量提升了，但仍面临大量历史代码。这时候，他们开始思考能不能通过一些方法或工具，让普通人也能写出高质量代码。这其实就涉及“软件工程化”思想，也是一种很了不起的理念——让普通人做出不普通的成果。他们每周都会发邮件来征询我们对某些战略问题的看法，是真的“求贤若渴”。我们在语言级创建、工具链开发等方面与他们有深度合作，甚至建了微信群实时沟通。他们还专门设立了众多的茶思屋，可以在特定环境下做测试。因为涉及保密，必须在他们的网络环境内操作，有问题可以直接找负责人解决。企业这么积极，也影响了我们。我觉得跟产业界合作并不复杂，不要害怕去实习。如果没机会实习，将来工作中也会接触到。也许哪天你就能做成一件事。
所以有时企业中很有干劲，他们很希望把事情做成。与他们合作，会觉得挺受鼓舞的，这只是一个侧面。将来我们大家都会觉得学术界和产业界结合的重要性。
（未完待续）
