驾驭 AI 的软件工程：可信性判断、双重驾驭与智能化工程师培养

（AI 预测 + 可信性判断）× 迭代 = 决策

【讲座观点 · 总纲】AI 完成「解」——基于机器学习数据训练所得、以概率方式预测性生成候选答案； 人完成「证」——对生成结果做可信性判断（验证）。编程是「难解难证」问题（第四章详述）， 可信性判断无法被自动化完全替代——因此不是 AI 颠覆软件工程，而是软件工程驾驭 AI。

核心公式把解题过程拆成两个可分离的环节：生成解与验证解，二者反复迭代直至得出可接受的决策——这是全部理论的出发点。

从「软件难控」到「软件工程驾驭 AI」的一条链式递推

讲座的论证是一条链式递推——任一环节松动，结论就松动。把链条画出来，是为了看清哪里是承重墙（其中最重的一环是「编程 = 难解难证」，第十章的四问集中于此）。

七个维度：动机 → 原理 → 核心 → 方式 → 目的 → 手段 → 本质

讲座骨架按七个递进的设问展开，对应本页第二至第七章：

问题模型转换 + 没有「三包」+ 创造制造融合

【讲座观点】软件开发本质上是「把现实世界复杂的问题模型转换为计算模型」——从自然语言需求到程序代码， 从整体到局部逐层分解、从抽象到具体逐步精化。这是创造性过程、决策性任务，且在最一般意义上是不可判定的计算问题； 效率、质量、成本的目标三角存在内生矛盾：成本一定时，提高效率与保障质量互斥。

【讲座观点】整个软件工程史可以读成「解耦创造与制造的持续努力史」：瀑布式开发（按系统功能规约需求）→ 面向对象开发（按问题域对象及其关系规约）→ 迭代开发（遵循人类认识复杂事物的规律：原型速成、敏捷开发、开发运维一体化 DevOps（Development and Operations，开发与运维一体化））——但收效有限，1+1=1 的困局始终未解。 这一铺垫很重要：第五章的「1+1 > 1」正是把它与 AI 的突破接起来。

逻辑使能 vs 数据使能：两类算法，一条关键等式

【讲座观点】软件系统的算法出现两条基本路线——这是全篇的技术枢纽：

关键等式由此建立：预测 + 可信性判断 = 决策。 预测性算法的输出是概率意义上的预测，而非逻辑意义上的可判定结果——它擅长解决高维、非确定、逻辑规则难以描述的问题， 但它的可信性必须外置。当这类算法超大规模工程化形成大语言模型后，软件的面貌从「确定的符号计算」扩展为 确定的符号计算与非确定的概率计算相融合，同时打开了两个空间： AI in SW（软件解决问题的空间）与 AI for SE（解决软件开发与演化问题的空间）， 共同挑战是面向不确定性的可信保障。

事前预测提效 24%，实测用时反而增加 19%

46% 不信任 vs 33% 信任——而官方把结论写得更直接

【讲座观点】Stack Overflow 2025 开发者调查（样本约 49,000）：46% 的开发者主动不信任 AI 工具的准确性，33% 信任。核查等级 ✅ 可信（高）。

【整理补充 · 讲座未引用、但支撑力更强的同源数据】同一份官方报告的 AI 章节还有两组更直接的一手表述—— 引用第五章理论（人工可信性判断）时，建议优先使用它们：

四起截至演讲前 6 天的真实事件——「需要驾驭」的现实论据

三个不同的「52%」：绝不可互相印证

【整理补充】一段代码可以「有错但更快」，也可以「正确但更慢」——错误率（③）与效率指标（②）分属不同量纲，不可互证； METR 的 −19% 与 Peng 等人的 +55.8% 虽同为「效率」，但实验情境相反，同样不可抵消或平均。另注意：agent 用户 70% 认同省时、69% 认同提效， 但仅 17% 认同改善了团队协作（全部影响项中评价最低）——「AI 提升了个体产出」不能推出「AI 提升了团队工程能力」。

三条可自动化，一条不可

【讲座观点】驾驭 AI 的核心就是可信性判断（验证）。它既是核心公式的右半部分，也是第四章论证链上 最承重的一环（蓝底节点）。

难解易证 vs 难解难证（hard to solve, easy / hard to verify）

【讲座观点】这个判据把「AI 会不会取代程序员」的经验争论，转化为关于验证复杂度的可判定问题——这是全篇最有方法论价值的一步。编程归属于「难解难证」一侧：生成的代码读起来比写起来还难，自动化验证不足以支撑充分的可信保障。

间接驾驭（人在马下）vs 直接驾驭（人在马上）

1+1 > 1：AI 首次打开了「创造与制造分离」的空间

【讲座观点】软件工程七十年来解耦创造与制造的成效有限（创造 1 次 + 制造 1 次 = 1 次）； AI 使 创造 1 次 + 制造 1 次 > 1 次 首次成为可能——软件创造性开发（原型式开发）与软件制造性开发（重构式开发） 两个阶段相对分离独立：前者「在快的基础上追求更加精准」，后者「在精准的基础上追求更加高效」。 由此也回答了「历史上第一个技术性解法」这一原创贡献：七十年想做而没做成的事，由 AI 提供了实现路径。

【讲座观点 · 为什么间接驾驭做不了软件制造（三步论证）】① 软件问题、需求、边界约束涉及多个抽象层次，难以精准表达、一步到位； ② 人工编程基于程序语义和逻辑，编程过程本身构成非形式化证明，编程完成即有保障；AI 生成代码缺失这种基本可信保障； ③ 「人在马下能达到骑在马上的效果吗？！」——不能。

【讲座观点 · 直接驾驭如何解决「人工难以验证端到端生成的代码」】人工编程本是解证融合（在解中证、在证中解）； 解证分离后「读代码比写代码难」，人工验证必须走解证融合途径：基于人工解决问题的框架全程引入大模型加速—— 通过过程解决问题而非端到端（需求与问题在过程中逐步描述清楚）； 每一步人机达成共识，通过人机融合实现解证融合。 目标设定刻意克制：在达到人工编程可信度的基础上，取得比人工编程更高的效率。

从软件视角看，驾驭 AI 只干两件事；智能应用分「探索型」与「部署型」

【讲座观点 · 现场原声补全】本章正文（间接 / 直接驾驭）回答的是「怎样驾驭」，录音稿补全了它上游的一维——驾驭的目的：从软件视角只干两件事：

第二件事再分两类，与两种驾驭方式严格对应——这也补全了第八章三阶段路径中「部署型 / 探索型智能应用」两个此前未展开的定义：

对照可见培养顺序的深意：先做安全可信要求更高的部署型（直接驾驭），再做既用即抛的探索型（间接驾驭）—— 与第八章「先直接、后间接」的路径设计互为印证。

演示文稿中有一处术语倒置，恰好出现在最可能被抄进笔记的那一页

【整理勘误 · 三方独立确认】原讲座「智能化软件工程师的能力需求」页中，「驾驭AI进行软件开发」条目下标注为：

软件制造性开发（间接驾驭），软件创造性开发（直接驾驭）   ← 与正文相反

正文的正确口径是「创造性开发（间接驾驭）；制造性开发（直接驾驭）」。 把这一页用作教学素材时必须口述更正——照抄即整套记反，而第五章培养路径的设计理由（先直接驾驭、后间接驾驭，见第八章）也随之失效。

问答恰好都问在本章要害上：创造与制造的目的之别

【现场问答 · 主持与提问：课程组织方张天老师】问：创造性开发与制造性开发，各自面向的目的是什么？

【李宣东答 · 要点】① 创造性开发面向的是软件需求——「软件工程里最深最难的问题就是需求」。 ② 过去需求没搞定就得开发：创造与制造融合在一起，要等代码写出来才知道创造对不对——那时候已经晚了，但回不去了，因为成本太高。 ③ 现在两个阶段可以分开：先创造——用大模型快速做出非常接近实际系统的原型（demo），对系统需求形成更深刻的认识；再做重构式二次开发（制造），这一步要求质量。 ④ 「创造性开发的质量天花板，够不到制造性开发质量要求的地板」——demo 能大大缓解「做出来的东西不是想要的」，但不是根本解决。 ⑤ 现场追问「人在马下搞创造？」，答：「间接驾驭用于创造，直接驾驭用于制造」——与本章口径一致。

【现场问答 · 在场教师】问：小学生、机关公务员都能用大模型开发出可用系统了，专业程序员的编程能力还重要吗？ 答：对专业的人而言，固有编程能力是基础——编程能力是 1，其他能力是后面的 0：1 后面的 0 越多能力越强；没有这个 1，其他都是 0。 一句话：「只会编程不够，不会编程出局」。

【现场问答 · 李宣东补充澄清】问：创造性开发是不是更容易、要求更低？答：恰恰相反—— 创造性开发要求更高，需要更有经验的资深程序员来做。 因为创造意味着要「指挥一堆 engineer（智能体），在有限时间内搞出一个确实是你想要的东西」，要考虑方方面面； 反而初级人员适合做制造性开发——制造是按要求、按规定来做，有明确的质量门槛。 关键边界：创造性的结果不能当制造性的结果来用，但创造本身的价值极大（demo 让需求发现前移）。

【整理补充 · 问答的增量价值】问答把「1+1 > 1」的动机补全了：创造先行的原因不是「AI 写得快」， 而是需求本身不可能在编码之前一次想清楚——这正是第四章「难解」的另一面。 原型（demo）的本质，是把「需求发现」从制造阶段前移到创造阶段的手段。

(AI)X Engineering ∈ Software Engineering

【讲座观点】驾驭手段首先是软件工程原理、方法和技术本身： 软件需求、设计与实现方法层对应提示词工程、上下文工程、TDD、SDD； 软件过程与项目管理层（3P：人员 People、问题 Problem、过程 Process）对应 Agents、Harness、Agentic Engineering。 总论断：(AI)X Engineering ∈ Software Engineering——一切 AI 工程化热点都是软件工程的子集； 且 AI 热点技术生命周期很短，「每次都认为解决了问题，即刻又发现还是没有解决」。

【现场原声 · 30 年前的四个工程段子（录音稿补强）】讲座展示了一张李老师 30 年前上课用的 PPT，讲四种工程之别： 机械工程——在亮着灯的屋子里抓一只黑猫（问题清楚、解决问题的过程也清楚）； 化学工程——在黑屋子里抓一只黑猫（反应前后面目全非，肉眼看不见）； 软件工程——在没有猫的黑屋子里抓一只黑猫（没有标准答案，整个过程本身就是探索与创新）； 系统工程——在没有猫的黑屋子里抓到了猫，还宣称「我抓到了」。 讲座的对应判断：现在的 AI 热点技术恰恰像第四段——每次宣布「搞定了」，很快又发现什么都没有。

【现场原声 · 一个「单循环 → 图」的当场例证】讲座转述了近期热点的一次反复：某框架主张「为每个智能体设计一个循环，让它自己跑，一切搞定」， 提出不到一周即改口「不行，还要搞 graph」——智能体不是单循环，每一步都可能有循环，圈套圈就成了图。 而「设计循环、把几个循环套起来，再加点东西——这不就是程序吗？」 这正是「(AI)X Engineering ∈ Software Engineering」的现场注脚。（转述自录音稿；ASR 对该框架名称无法确证，故不点名。）

面向智能体的高抽象级逻辑编程与场景运行时

【讲座观点】技术层要点：面向智能体的高抽象级逻辑编程（Agent-oriented Programming）； 开放、动态、不确定的运行时——人机物融合的场景计算机、 场景世界模型（LLM + 物理和逻辑约束规则，用以约束开放不确定运行时中的 Agents）、 Agents 交互协同的 Agent 系统、管理 Agents 的泛在操作系统。

编程抽象基本单元的演进：寄存器 → 变量 → 对象 → 智能体（Agent）抽象

【讲座观点】编程抽象的基本单元一路演进：

【讲座观点】自然语言非形式化、有歧义、面向思维表达效率；程序语言形式化、抽象层次不断提升、不断接近自然语言。 分工结论：间接驾驭主要采用自然语言；直接驾驭需同时采用自然语言与程序语言。

【整理补充 · 理论出处】把 agent 界定为具有自主性、反应性、预动性与社会性的实体，在智能体研究领域有经典理论先声 （Wooldridge & Jennings, 1995）。讲座的贡献不在提出 agent 概念，而在把它放到「编程抽象层级演进」的坐标上——与寄存器、变量、对象并列为第四级抽象，这一坐标定位是讲座的原创表述。

【现场原声 · 上世纪 80 年代的先声（录音稿补强）】讲座现场补充：面向对象诞生（80 年代末）的同时就有了「主动对象（active object）」的设想—— 对象是被动的，「如果这个对象变成主动的、又有智能呢？」今天的智能体正是这一设想的落地形态： 智能来源于与大语言模型交互——遇事问模型，按答案完成任务。

大模型辅助训练大模型 + Agent 自我动态修改 Harness

【讲座观点】RSI（Recursive Self-Improvement，递归自我改进）是「AI 颠覆论」最常引用的机制， 其现状是「大模型辅助训练大模型 + Agent 自我动态修改 Harness」。讲座的判断： RSI 的本质就是解证自我迭代，核心驱动仍然是可信性判断—— 自我改进的每一步都需要判断「这次改进是否更好」，而这一步判断并不因为迭代的主体变成 AI 就被自动解决。 结论三连：对质量的关注是软件工程的根基；搞定可信性判断，才能颠覆软件工程；可信性判断是人工智能固有的障碍—— 因此人工智能无法颠覆软件工程。

【现场原声 · 「根基」的出处（录音稿补强）】「根基」指 Pressman《软件工程》经典教科书中的层次图： 基座是对质量的关注（A Quality Focus），其上依次为软件过程（Process）、软件方法（Methods）、软件工具（Tools）—— 讲座现场展示的正是李老师 30 年前讲这页内容的 PPT，并给出对应解读： 「你要颠覆软件工程，得把这个根基掀掉；只要根基不动，AI 热点怎么翻新，都还在软件工程之内。」

本质表述：驾驭 AI 的本质是「面向不确定性的可信保障：做正确的事，正确地做事」——在软件系统这个更大的范围内解决「可信可解释人工智能」难题。

结论依赖一个未被讨论的隐含前提

【整理补充 · 三方独立收敛的质疑点】「AI 无法颠覆软件工程」依赖隐含前提——「可信性判断永远是 AI 的固有障碍」。 若未来验证技术取得协同突破（讲座自己承认的自动化验证途径中的「形式化验证 + 强自动化测试」），该前提即松动，结论随之失效。 讲座未讨论这一反事实。

驾驭 AI 的本质，是运用软件工程原理、方法和技术的能力

【讲座观点】就业市场收缩、仅需编码的初级岗位被大幅压缩；张力在于「工业界不招初级程序员，但高级程序员都是从初级成长起来的」。 （注：「国外工业界似乎不招初级程序员」一句讲座原文已用「似乎」弱化，无权威统计支撑，按观点而非事实处理。）

第 (3) 条是点睛之笔：驾驭 AI 不是一套独立的新技能，而是软件工程能力在新对象（智能体）上的迁移。 「护城河」随之改写——过去 = 程序设计技术；现在与将来 = 程序设计技术 + 软件工程原理、方法和技术。

为什么先消失的是「只会编码」的岗位：从大规模系统分解讲起

【现场原声】讲座用一张自嘲「画得丑陋、几次想重画、后来发现越丑陋印象越深」的图，解释「仅需编码」的初级岗位被压缩的结构性原因：

推论链条：模块级编码 AI 可代劳 → 同样产出所需人数收缩（讲座口述示意：原来 7 个人的活，4 个人就够了）→ 留下的人不再在模块层编码，而是每人负责一个子系统的分解与推进，带着大模型干—— 「这就意味着你要会几乎软件开发的所有方面」。这正是上面四层能力模型 (0)–(3) 的就业市场版论证。

【现场原声 · 五年前后的名校差别（录音稿补强）】讲座现场补充了一个就业市场的历史对照： 「五年前，南大毕业生和其他学校毕业生在企业里差别不大——只要代码写得好，企业不管你是哪个名校毕业的。」 因为彼时「写代码」只是一项单项技能，高中生都可能写得更好；而 AI 把这项单项技能的门槛抹平后， 企业要的就不再只是「能写代码」，而是「会分解子系统、能带大模型、懂几乎所有软件开发方面」的综合能力—— 这正是名校培养体系（基础课 + 工程实践 + 软工方法）的差异开始显现的地方。

【整理补充 · 两个口径说明】①「7 人 → 4 人」为讲座口述示意，非统计数据，引用时按观点处理； ② 该图与第三章 METR −19%（资深开发者在真实大型代码库上的效率实测）不冲突——一个讲岗位结构的长期演化，一个讲个体效率的实验切片，量纲不同。

先手工编程，再直接驾驭，最后间接驾驭——顺序里有深意

【整理补充 · 顺序的内在逻辑】先「直接驾驭」（人在马上）、后「间接驾驭」（人在马下）看似反直觉，实则一贯—— 站在马下比骑在马上更考验判断力：你必须能预判马往哪跑，才有资格放开缰绳。 间接驾驭要求更高的判断力，与「1–2 年级先死磕手工编程」一脉相承。这一顺序也解释了第五章勘误为什么危险：若把创造 / 制造记反，整套培养路径的设计理由随之失效。

【现场原声 · 课程安排预告】录音稿提到：软件工程课拟从一学期拆为两学期，并基于大模型全面提升高年级软工课程的学习质量—— 与下方「放大器」定位一致（讲座口述，具体以南大实际教学安排为准）。

AI 是放大器；学习的本质是建构个性化的专业世界模型

【讲座观点 · 一条关键教学主张】不是在软工课上学习驾驭 AI，而是通过驾驭 AI 提升软工课程的学习质量—— 把 AI 定位为学习软件工程的放大器（amplifier），基于 LLM 全面提升个人独立开发系统的规模与复杂性。

【现场原声 · 杀鸡用牛刀】为什么过去学生不信软工方法有用？「我告诉大家这是一把牛刀，但课堂上只能杀一只鸡给同学们看 ——一门课撑死万把行，凭什么说它能杀牛？」现在有了大模型，个人独立开发系统的规模与复杂性可以真正上量，牛刀终于能用来杀牛—— 这就是「放大器」的具体含义。

【讲座观点 · 收束点】AI 基于概率统计生成解、缺失世界模型，因而不能自我进行可信性判断； 人通过专业学习建构自己的软件专业世界模型（基本能力：程序能力、算法能力、系统能力、工程能力；综合能力：解决问题能力、专业知识学习能力、驾驭 AI 能力）， 从而能自信地持续学习、判断并驾驭 AI。AI 不能自我验证的根因不是算力不足，而是缺失世界模型——这使「可信性判断」成为一项结构性而非阶段性的困难，也正是学习不能外包给 AI 的根本理由。

【现场原声 · 讲者自己的 40 年注脚】「我 40 年前本科毕业，当年课程上的很多东西走出校园就过时了——但没有白学： 那些东西构成了我的世界模型，我靠它不断地学、不断完善……所以我到现在六十多了，还能跟上当今技术发展的趋势。」 世界模型的价值一半在解决问题，另一半在支撑持续学习——这正是课间那位同学问「AI 这么强了为什么还要学」的正面回答。

讲座概念 ↔ 工程对应物 ↔ 可检验什么

结果层自动验证 + 过程层可靠性评估 + 关键节点人工确认

【整理补充】讲座强调「关键节点人工确认」，工程实践擅长另两项——三者合起来才是完整的可信性判断，也是第七章前提分析的一次实证装置：

照抄笔记会记反、撕掉情境会误引、不同量纲会混用

Q1–Q4：把结论变成可检验的问题

把本专题接进已有的学习链条