生成式软件工程第一讲笔记：欢迎来到未来

这篇笔记对应蒋炎岩在南京大学讲授的《生成式软件工程》第一讲，B 站视频《欢迎来到未来》，时长约 100 分钟。

本课从一个现实变化出发：Agent 已经能够读懂作业、实现程序、执行测试。提交一份能运行的作品，越来越难单独证明提交者学会了什么。软件的生产方式正在变化，学习软件工程的方法也需要跟着变化。

本文由 AI 辅助整理，综合视频音轨转录、第一讲官方讲义和课件抽样核对，按问题与案例重新组织；最后一节单独记录实践思考。

一、计算机专业现在应该学什么

开场讨论的焦虑很具体：一种情况是，AI 完成了四年的作业，人却没有形成自己的能力；另一种情况是，认真训练了四年，发现市场对原先技能的需求发生了变化。继续把精力全部投入分数和简历，并不能自动解决这些问题。

讲义回顾了四个节点：1975 年的 Altair 8800、1993 年的 Mosaic、2007 年的 iPhone、2022 年的 ChatGPT。它们放在一起，指向计算能力逐步普及的过程。原本需要专业人员掌握的能力，变成更多人可以直接使用的工具；今天受到冲击的，也包括把需求转成程序的能力。

这门课因此带有明显的实验性质：亲自使用 Agent，观察哪些旧方法仍然有效，哪些环节需要重新设计。软件工程的中心问题仍然是怎样把事情做成，并让工程能够持续下去。

讲者用“信息差、能坐牢、能驾驭”概括大学教育与人的价值。展开来看，分别是：

• 知道有哪些可能。 理解计算机世界的基本构成，知道工具、接口、知识和解决方案在哪里。
• 承担决定的后果。 软件进入现实世界以后，仍然涉及责任主体，不能把所有问题都归给生成代码的模型。
• 组织能力与反馈。 把目标、人员、工具、实施过程和检验办法组织起来，最终交付有用的结果。

第三项是课程真正想训练的能力。即使实现速度越来越快，需求变化、人与人的沟通、系统维护和真实用户的使用过程，仍然会决定一个工程的成败。

实践、作品与课程本身

课程鼓励把实现交给 Agent，把注意力放到问题选择、设计和验收上。课堂中强烈反对沿用纯手工实现的惯性，目的是促使学生亲自体验新的生产方式，不能据此推出“程序原理已经不必理解”。

关于 token 的激烈说法，后续讲义也作了澄清：并没有真的要求没用工具的学生退学。它强调尽早实践，同时反对单纯攀比消耗量。花了多少 token，与是否学会解决问题，是两个不同的指标。

课程希望学生留下可以展示、运行、持续改进的作品，并能够解释自己做成了什么、遇到了什么困难、怎样改变了方案。一个仍有人使用的项目，会持续提供反馈；一次作业评分只能记录某个时刻的结果。

课程内容的制作也属于实验的一部分：保留文本源材料，用程序生成和渲染幻灯片，再把课堂讨论整理成可以检索、编辑的讲义。课程于是有了可继续维护的源文件和生产流程，而不只是一段只能从头播放的录像。

口头讲解还补充了幻灯片的生成办法：先由讲者写出讲授提纲，再让不同角色的子 Agent 从历史案例、相关工作和第一性原理等角度补充材料，最后汇总并比较质量。视频中紫色的补充文字属于生成内容，不能把课件上的每一句话都理解成讲者逐字写下或认可的结论。整理时需要同时看口述与画面。

二、从预测 token 到 Agent 的行动循环

讲义用下面的记号介绍自回归语言模型：

Pr[token | context]

它表示在给定上下文时，下一个 token 的概率分布。Token 是模型处理文本的单位，未必等于一个字或一个英文单词。

理解这个接口，有助于理解上下文为什么重要，但不能仅凭接口形式判断模型能做多少事情。生成出来的内容会继续进入上下文，中间结果能够成为下一步的依据，尝试和修正可以逐步展开。

讲者回忆 GPT-4 给五岁儿童解释扫描电子显微镜的经历，口头描述了一个通过投掷物体、根据反馈推测看不见的形状的类比；本次生成的课件则改用了逐点扫描、接收信号并重建图像的说明。这两个版本不宜混在一起当成当年模型的原话。例子要说明的能力，是根据听众重新组织知识，让对方理解重要的因果关系，而不只是复述仪器定义。

后来的推理型模型，把更多计算用于尝试、检查和修正。这里涉及两个概念：

概念	在这一讲中的意义
Chain-of-thought，思维链	通过中间步骤推进求解，使后面的生成能够利用前面的结果
Test-time scaling，推理时扩展计算	在执行任务时投入更多计算，探索和检查更多可能

更多计算是否能换来更好的结果，还取决于任务是否提供了有效的反馈。反复扩写同一个错误，并不会因为过程变长就更接近正确。

Agent 多出来的是什么

Agent 把语言模型接到了工具和环境上。它可以读取文件、运行命令、访问网页，再根据执行结果选择下一步行动。

可以把这个过程记成：

观察当前情况 → 决定下一步 → 调用工具 → 读取结果 → 继续或结束

支撑这个过程的外围系统通常称为 harness。它涉及工具接口、状态、环境和反馈机制。评估 Agent 的能力，也就不能只看底层模型回答问题的表现，还要看它有没有合适的观察手段、能否执行必要动作，以及怎样判断任务已经完成。

PPT 从 ChatGPT、推理模型谈到 Agent，贯穿其中的是反馈循环能够延伸得更长。ReAct 所代表的推理与行动交替，让模型有机会根据工具返回的信息修正下一步；搜索等工具增强了获取材料的能力，同时也把一部分可靠性要求转移到了检索、来源选择和信息整合上。

聊天模型能够说明安装系统的步骤；具备相应工具的 Agent，则可能真正完成安装，并继续处理执行中遇到的错误。这种从建议到行动的变化，是后面一系列案例的基础。

PPT 还保留了对模型未来计算形式的开放讨论：自回归生成之外，Diffusion LM 等方法提供了其他生成方式；上下文也可以被设想为更灵活的可修改状态。外围 Agent 系统本来就在读取观察、调用工具、接收结果和压缩记忆，不断改变下一轮使用的上下文。这些讨论涉及未来方向与系统抽象，不是使用当前 Agent 前必须解决的理论前提。

三、把日常工作交给 Agent，学习入口也会改变

Debian：先得到能检查的环境

讲者介绍了安装在 USB 设备上的 Debian 环境：安装和配置由 AI 协助完成，并通过 QEMU 运行验证。终端、编辑器的配置，可以直接描述期望行为；不熟悉的操作，也可以整理成随手查阅的说明。

这个案例改变了学习的起点。过去，做一件事情之前可能要先花很长时间准备环境；现在可以先获得一个可运行的系统，再围绕具体问题学习它的原理。

其中仍然包含明确的检查：能否启动、配置是否生效、行为是否符合要求。环境准备的门槛下降了，验收环节仍然存在。

邮件：把检索、拟稿和提醒连起来

邮件案例使用能够查找历史邮件的 skill，让过去的通信成为参考。新邮件进入后，可以分类归档、检索类似回复、拟出符合使用者习惯的草稿，再通过提醒事项呈现；提醒事项也可以成为向 Agent 传递后续要求的入口。

讲者同时说明，复杂邮件的回复草稿往往还要自己修改，简单例行回复才比较容易直接采用。现场还通过提醒事项发出打印最近一张发票的要求，稍后收到了完成通知。附件归档、调用打印机与返回提醒，让这个例子有了可观察的实际结果，也保留了本人决定哪些事务可以委托的边界。

值得关注的是工作流的连接。检索旧邮件、理解新请求、生成草稿、通知本人，本来是分散的动作；接在一起之后，工具开始参与完整事务的处理。

读书和论文：材料变多，理解仍要检查

Agent 能整理电子资料，也能把视频内容转换成可阅读的材料。材料获取的效率提高后，还要区分“得到摘要”和“理解论证”。

讲义提出的阅读方法包括：追问结论靠什么证据成立，找出隐含假设，寻找反例，离开原材料后自己复述，再返回核对。这样的使用方式能够暴露理解中的空白。只保存一份看起来很完整的总结，往往看不出这些空白。

口述中还有一个具体方法：先以已有知识为背景，把论文真正新增的内容分离出来，再拿着原文和分层总结继续对话。阅读视频也采用相似思路，把语音转成文字，并在画面明显变化时保留截图，最后根据自己的已有知识寻找值得看的新增内容。讲者描述的效率提升是个人使用体验，不能作为所有人都会得到同样收益的保证。

这也适用于这篇笔记：文字把内容集中起来之后，还需要带着自己的问题回看案例，才能把别人的演示转成自己的判断。

四、工具组合与成功经验的复用

Agent 的通用能力，可以通过合适的工具获得更直接的观察与操作方式。

浏览器就是一个例子。屏幕上呈现的是网页和按钮，程序内部还存在 DOM、事件、网络请求与状态。知道这些层次，就更容易选择适合任务的接口，不必把每一次操作都变成对像素位置的猜测。

这体现了计算机基础知识的一种价值：即使不亲手实现所有代码，也能够知道问题可能在哪一层被解决，知道应该让工具读取什么、操作什么。

课堂中途还出现了一个即兴案例：视频采集设备断开后，讲者让 Agent 检查 USB 状态，并尝试用软件方式重连，随后画面恢复。它与安装系统的例子呼应：知道操作系统能够提供哪些控制手段，就有机会把模糊的故障现象转成可以检查的任务。

讲义中的学校办事大厅案例，还引出了经验的复用。第一次可以让 Agent 探索流程；流程跑通以后，再把稳定部分沉淀成可检查、可修改的脚本。下一次处理同类事务，便不必完整重复探索。

PPT 把它联系到 Programming by Demonstration，即从操作示范中形成程序。一次成功操作还只是案例；能够检查、修改并重新执行的脚本，才把经验转成了软件资产。课堂展示了 Agent 使用浏览器开发工具的过程，其中也出现过页面跳转和访问失败，实际探索并非总是一次成功。

信息来源、处理过程和输出动作，也可以继续组合。例如把网页、论文和视频作为输入，把检索与分类作为中间步骤，把文档和提醒作为输出。单个工具的价值由此进入更长的工作流程。

与此同时，组合增加了需要解释的状态：信息从哪里来，哪个步骤已经完成，失败后从哪里恢复。工具数量增加，并不能保证整条流程正确；某一环误读的结果，还可能成为下一环继续行动的错误依据。

工作流能否帮助改进工作流

PPT 进一步提出一种设想：观察一天的数字操作，让 AI 发现反复出现的模式，再生成自动化流程。这个过程需要经过回放验证、人工确认和异常收集，才能判断自动化是否真的减少了负担。

这里值得区分两个阶段：发现重复模式属于探索，长期运行的自动化需要稳定的接口和错误处理。把探索时的偶然成功直接当成可靠流程，容易在环境变化时失效。

课件用一个简化算式说明长流程的困难：假设每一步独立成功的概率都是 99%，连续 100 步全部成功的概率约为 0.99^100 ≈ 36.6%。这不是对实际 Agent 的测量；真实步骤也未必独立。它用于说明，仅提高单步成功率还不够，还需要状态记录、重试、权限管理、验证与故障恢复。

讲者在这里也表达了对 OpenClaw、Hermes 一类产品所展示方向的兴趣，以及对当时模型和 harness 稳定性的保留。应把这看作授课时的体验判断，不是对产品此后表现的结论。

五、两个具体案例：统分工具与二维码 Excel

统分工具：从重复劳动中找需求

考试统分是一个很具体的临时软件需求。讲义描述的流程包含：

1. 按操作指令拍摄试卷。
2. 由本地模型识别姓名、学号与各题得分。
3. 以与录入相反的顺序复核，报出身份信息、各项分数和求和结果。
4. 教师核对后，把总分记录到试卷。
5. 汇总为教务系统能够接收的 Excel 格式。

其中的复核步骤很有意义：系统需要让人看得出错位、漏项和识别错误，而不只是展示一个最终总分。原始图像、识别出的分项与计算结果，也应该能够互相对应。PPT 把这种反序检查与报数联系到 readback，即用回读确认信息的机制，并提出可以进一步让 Agent 录入系统；课堂同时保留了日常专用界面可能更好用的取舍。

口述特别区分了识别和求和：模型识别各项得分，确定性的脚本负责加总；教师检查识别结果，并对最终成绩负责。这个安排把“模型看错分数”和“算术计算出错”分开处理，也说明该交给模型的部分与该交给普通程序的部分，并不相同。

这类需求过去可能因为使用频率不高、专门开发不划算而一直靠人工完成。实现成本下降之后，针对某个具体流程临时制作工具，变得更值得尝试。

重新认识应用程序的能力

另一个案例从受限计算机环境出发：如果机器仍能显示画面，信息是否真的完全不能输出？课堂用 Excel 公式和屏幕二维码讨论计算与输出通道。

这个案例在课程里的作用，是训练对已有部件的重新认识。Excel 包含计算能力，屏幕承载输出，已有应用可以被组合成意料之外的工具。它也说明，理解系统的实际能力，比记住产品通常用来做什么更有用。

PPT 进一步把远程桌面的鼠标输入看作接收方向，把二维码画面看作发送方向，再考虑怎样在这样的通道上组织通信协议。这里强调的是系统抽象：网络通信依赖可编码的信息通道与收发约定，并不限于某一种名为“网卡”的设备。课程借此把对应用的认识推进到输入、计算、输出和协议的层面。

同样的思路还可以延伸到视频和实体设计：视频可以由脚本、分镜和时间线组织，物体可以用 CAD 数据和制造指令描述。只要产物具有可计算、可编辑的表示，Agent 就有机会参与它的生产过程。

不过，能够生产部件，并不意味着已经能够组织复杂工程。二维码 Excel 接下来的开发过程，正好展示了这一点。

“AI 造航母”的反问也在讨论整体协作。产品涉及前端、后端、交互和运营等多个环节，一个关键环节无法成立，整体体验就可能失败。PPT 用另一个简化假设说明这种效应：如果十个必要环节各有 90% 的独立成功率，全部成功的概率约为 0.9^10 ≈ 35%。这个例子与前面的长流程算式共同提醒我们，局部能力提升，并不会自动消除接口和协作中的风险。

六、二维码 Excel：为什么生成了很久，仍然难以维护

这一节是第一讲最值得保留的工程案例。它足够小，可以理解全部目标；又包含兼容性、输入变化、验证和维护问题，不是只看一张截图就能验收的演示。

需求看起来已经相当具体

根据官方讲义，目标大致包括：

• 使用 Excel 2019 及更早版本兼容的公式。
• 接收可能很长的字符串，进行 Base64 编码。
• 将编码结果拆分为多个二维码帧，循环显示。
• 接收端扫描各帧、拼接数据后，可以还原完整结果。
• 使用接近实际运行环境的办法，验证公式的正确性。

这份要求仍然留下许多待决定的事项：字符编码怎样选，分片规则怎样定义，输入长度变化是否需要重建工作表，刷新操作和播放频率如何配合，以及怎样判断生成的二维码是真的可读。

其中最容易被忽略的一点是验收对象。能打开工作簿、能看见类似二维码的图案，只能证明一部分过程执行了。真正需要检查的是输入能否经过编码、分片、显示、扫描和重组，最终恢复为同一份内容。

课堂记录里的失败与调整

官方讲义记录了几次具体尝试：一次 GLM-5.3 开发经历了约 25 分钟的首轮思考、输出长度限制和约 6 小时的完成过程；一次 DeepSeek V4 Pro 尝试生成了硬编码结果，被指出问题后需要重新设计。讲义还提到约 2 MB 的工作簿，以及随需求变化而增加的维护难度。

这些是讲者的个案记录，不是本文独立复测的性能数据，也不适合据此给模型排出普遍适用的名次。

硬编码版本的问题尤其明确：需求要的是适用于不同输入的程序，交付结果却可能只对当前示例成立。示例正确掩盖了计算过程不通用的问题。

后来，讲者通过调整方向，使 GLM-5.3 在约 200K 上下文内完成了更可维护的版本。关键变化在于公式和计算模板可以复用，结构不再随着输入增长而不断复制扩张。

口头讲解的关键补充：先设计中间表示

视频比官方讲义更具体地解释了这次架构调整。讲者先让 Agent 构造一套小型符号系统，用 Python 的对象或操作表示异或、拼接等计算。它相当于一层中间表示：同一份计算既可以在 Python 中执行，也可以转换成 Excel 公式。

这样，验证就能够分开进行。在 Python 一侧检查 Base64 编码与二维码计算；在转换层检查各个基本操作生成的 Excel 公式是否保持相同含义，再把它们组合起来。算法逻辑与工作表里的坐标、公式表达被分离，修改时就更容易定位影响范围。

这不是“换一个更长的提示词”那么简单。讲者主动选择了类似编译器的结构，使问题能够在更容易运行与检查的环境中求解，再转换到目标环境。视频没有给出足以独立复现整套实现的完整代码，因此这里保留架构思路，不把它写成已经复现通过的教程。

维护成本取决于怎样表达计算

输入变长，数据量、帧数和计算工作量增加，都很正常。真正需要警惕的是：为了表示同一个算法，必须复制更多结构；稍微改一点要求，就需要同时调整大量相互依赖的单元格。

PPT 对这点给出了更明确的表达：相对于输入长度，公式模板和工作表的算法结构应尽量保持固定；随输入增长的应主要是数据、计算量和帧数。课件用 O(1) 与 O(n) 区分这两类增长。这里的固定结构是设计目标，不表示整个工作簿的存储或执行成本与输入长度无关。把输入从 1 KB 改成 10 KB 时，究竟有哪些东西必须扩张，是一个很直观的检查问题。

因此，AI slop 不只是外观粗糙或生成文件很大。一个更有用的观察角度是修改的影响范围：变更能否限定在清楚的位置，还是每次都要重新梳理整个系统。

当修改不断牵动其他部分时，项目就进入了讲义借《人月神话》说明的困境：工作越积越多，局部修补持续制造新的问题。继续投入生成能力，也未必能够纠正一开始的结构选择。

七、Intent、Spec、Impl：真正困难的两次转换

二维码案例引出了课程的核心框架：

Intent（意图） → Spec（规格） → Impl（实现）

层次	需要回答的问题	二维码案例中的例子
Intent	最终想完成什么，为什么值得做？	在特定环境里转移一段文本，并能确认结果正确
Spec	哪些行为与约束必须成立？	版本兼容、可变输入、分片与恢复规则、验收方法
Impl	程序怎样执行这些行为？	公式、数据布局、二维码生成与刷新过程

真实意图常常是不完整的，需求提出者也未必已经想清楚所有取舍。规格需要把这些想法变成可以讨论与验证的要求。实现则必须继续补全每一个执行细节，不能把关键行为停留在含糊描述里。

每一次转换都存在多种选择。程序通过测试，只能证明它通过了这些检查；如果规格本来就没有表达真实意图，测试全绿也不能证明产品有用。

Agent 会主动补足不少空白，否则每一个变量名都询问用户，任务根本无法推进。但不同空白的重要性不同：局部命名通常容易修改，数据表示、架构和验收方式选错，后续返工的代价可能很大。

PPT 也把测试看作对目标的一种有限代理：如果检查奖励的是某个替代指标，模型可能很好地优化这个指标，却没有完成原本想解决的事情。它展示的“实现满足规格”关系，仍然缺少“规格表达了正确意图”这一环。

工程工作因此需要识别关键假设，让它们尽早接受讨论或实验。立即开始大量实现，有时会让尚未考虑清楚的决定提前固定下来；之后的修改又围绕这些决定展开，最后很难重新选择方向。

八、把迟到的反馈提前

课堂把软件工程放回长程任务的语境。学校题目通常有明确答案，反馈也来得快；工程里的问题，可能要等到用户开始使用、业务改变或其他人接手维护时才暴露。

PPT 特别强调长程任务中反馈稀疏、延迟的问题，并把软件工程放在技术、人、组织与管理共同作用的范围里。人的动机和持续推进能力同样影响结果。能在短题上不断获得分数，并不自然等于能够在迟迟没有明确评价的工程里持续做出合理决定。

拆分、测试、持续集成和小步迭代，在这里有共同作用：缩短决策与反馈之间的间隔，减少一次错误影响的范围。

官方讲义据二维码案例提出了一条更容易验证的推进路径：

1. 先选短输入，生成一帧，并让独立解码器读回结果。
2. 改变输入，确认得到的是通用计算，而非示例专用结果。
3. 加入 Base64 和分片，验证分片前后数据一致。
4. 检查多帧顺序与重组。
5. 再处理刷新、兼容性和性能。

每一步都有明确的不确定性要消除，也有可以留下来的检查。这样更容易知道失败从哪里开始，而不是等所有功能堆完才尝试打开最终文件。

对于学校办事大厅这样的系统，同样可以先跑通一件真实事务，确认数据提供者、状态变化和异常处理，再逐步扩展。撤回、重试、人工接管都属于完整流程；先画出所有表单，并不等于已经设计好办事过程。

九、生成便宜以后，审查会成为什么

讲义用一个假设算式提醒读者：如果总产量变成原来的一千倍，即使问题产物只占百分之一，其绝对量仍然是旧产量的十倍。

这不是关于某个模型实际错误率的统计，而是对成本结构的说明。错误比例很低，与维护负担很轻，并不等价。

代码生成可以快速增长，人的逐行阅读速度却很难同步增长。规格、独立检查工具、测试、可观测性与清晰接口，因此承担了更重要的作用：让判断过程也能跟上生产过程，把人的注意力集中到真正需要判断的地方。

讲者对手工编程的强烈表态，可以放回这个语境理解：边界清楚、能够获得有效反馈的实现任务，其稀缺性正在下降。软件工程所面对的组织、检验和维护问题，目前仍然存在。

同时，课程也没有假设某种人类能力永远不会被模型赶上。设计、品味、工程判断如果继续变便宜，人仍然要面对更根本的问题：什么事情值得做，谁决定目标，谁承担后果。这是课程提出的开放问题，不是已经确定的未来结论。

十、我的实践思考：让 Agent 的产出可解释、可复核

下面是结合本讲整理的做法，并非课堂原话。

开始一个任务前，我可以先留下三段很短的说明：使用者遇到什么问题，完成后要观察到什么变化，用什么证据确认变化已经发生。这样能够尽早暴露 Intent 和 Spec 之间的缺口。

进入实现后，先选择一条可以实际运行的最小流程。对于数据处理工具，优先验证输入到输出是否一致；对于界面功能，优先确认用户能否完成核心操作；对于会持续演进的程序，增加一次小需求，观察结构是否容易修改。

遇到 Agent 长时间反复修补时，需要重新检查最初的假设。仅仅追加“继续修复”，可能是在维持一个越来越昂贵的方向。二维码案例提醒我，停下来改变数据表示或计算结构，有时比继续生成更多实现更重要。

做完以后，留下必要的验证结果和设计依据，把重复成功的过程沉淀为脚本或 skill。下一次复用时，仍然核对输入和环境是否符合前提。这样积累的才是能够继续使用的经验。

对于学习，也可以用同一套标准：我能否独立解释问题，能否指出一个失败，能否说明为什么改过的版本更好。代码是谁逐行输入的，越来越难单独回答这些问题。

来源与整理说明

• B 站视频：欢迎来到未来（BV1pb8o6yE8f）
• 蒋炎岩：2026 年秋季《生成式软件工程》课程主页
• 第一讲官方讲义：欢迎来到未来
• 第二讲官方讲义：提示词与上下文工程，用于核对第一讲有关 token 的说法在后续课程中的澄清。

官方讲义标注采用 CC BY-NC 4.0 许可。本文对其中的课程内容进行了选取、改写、重排和说明，保留讲者与原始来源的归属；个人实践部分已单独标明。模型名称、运行耗时和上下文规模来自讲义中的课堂记录，未进行独立复测。

音轨使用本地语音识别转录，并结合官方讲义与画面校正术语。转录含错字和一段明显重复，不能作为逐字引用依据。课件核对使用从视频中按两分钟间隔抽取的 50 张画面；抽样不能覆盖所有短暂画面，本文也未复刻课件全文。