1
课程资源：
整理由 Claude Sonnet 5.0 Medium 生成.
评论区推荐：https://www.bilibili.com/video/BV1pb8o6yE8f#reply315318290080
如果一份编程作业可以直接交给 AI 读题、写代码、跑测试，最后交出一份像模像样的结果，那这份满分证明的到底是谁的能力？
过去我们习惯把"作品"当成"能力"的痕迹：能做出一个程序，大概就掌握了对应知识. 但今天，同一份作品背后，可能是真正理解系统的人，也可能只是复制粘贴了一句话的人——作品还在，作品与能力之间的对应关系却变了.
由此产生的焦虑很真实：AI 帮我上完了大学，最后我什么都没学会怎么办？老老实实学了四年，毕业时发现训练的技能不值钱了怎么办？这些问题需要亲自试一试：当实现软件的成本发生剧变，什么能力还值得训练.
一门站在交叉路口的实验课¶
课堂用四个历史节点回看计算机改变生活的过程：1975 Altair 8800、1993 Mosaic、2007 iPhone、2022 ChatGPT，共同点是：原先只有少数人掌握的能力，逐渐进入普通人的日常生活. 今天，"把一个想法变成能运行的软件"也在经历这种变化.
《生成式软件工程》是一门实验性课程，讨论 AI 时代仍然有用的"软件工程智慧"：怎么让工程不失败？ 演示跑起来只是开始，系统还要承受需求变化、真实用户、错误输入，以及人与人的协作
大学还能教给你什么？课堂给出三个说法：
- 信息差：知道计算机世界里有什么、知道哪里能找到答案
- 能坐牢：做了决定之后要有人承担后果
- 能驾驭：能把人、工具和反馈组织起来，最终做成一件事 ← 课程最关心这一项
课程鼓励动手实践，喊出"禁止古法编程"——打破把亲手敲每行代码当成学习成果的习惯；实现可以交给 Agent，人的注意力更多留给问题、设计和检验. Token 要求自费，但不鼓励 tokenmaxxing（以消耗更多 token 为目标的攀比），值得投入的是问题与实践本身.
课程本身也是一个实验：讲义是 Markdown（source of truth），经过生成渲染成幻灯片，课堂讨论被记录整理成可阅读、可搜索、可重组的内容. Everything is code 在这里很具体——保留可编辑的源材料和构建过程，即便老师不再维护，课程也有机会被持续更新（"数字永生"的思路）.
从语言模型到能够行动的 Agent¶
自回归语言模型可以理解为一个条件概率分布：给定已有上下文，预测下一个 token，即
这个接口看似简单，但"预测下一个 token"描述的只是计算如何展开，不能直接拿来判定能力上限——模型输出的文字会进入后续上下文，先写下中间结果，再基于它继续计算，发现矛盾再修正. 一个静态的概率分布，因此可以展开成很长的计算过程.
举例：向五岁小朋友解释扫描电子显微镜，可以说成一支很细的"电子铅笔"一行一行扫过样品，把各处信号强弱画成屏幕上的亮暗点——不需要先学完仪器课程，也能抓住"扫描、测量、拼图像"这条因果链. 令人惊讶的能力是模型能面向听众重新组织知识.
推理型模型让"先尝试、再检查、再修正"更有效：
- Chain-of-thought (CoT)：把中间步骤留在上下文中
- Test-time scaling：使用模型时投入更多计算，换取更深入的尝试（是否值得取决于能否获得有效反馈）
Agent 更进一步：可以调用工具（读文件、执行命令、查网页），观察操作结果，决定下一步. 语言模型 + 程序 + 工具 + 环境共同构成一个反馈循环，承载这个循环的外围系统常被称为 harness. 理解 Agent 要看它能观察什么、操作什么、操作后能否知道自己做对了没有.
先用好，再理解原理¶
很多人第一次用 Agent，只是把它当成一个更会聊天的搜索框；真正有意思的变化发生在把日常任务交给它的时候.
- 课堂演示：Debian 装在 U 盘上，安装配置全由 AI 完成，还在 QEMU 里验证；终端/编辑器配置用自然语言提要求，不熟悉的操作让它整理成速查文档
- 邮件助手：能查历史邮件的 skill 把过去回复变成参考材料，收信后判断归档、拟回复草稿、通过提醒事项通知
- 读论文：Agent 能整理材料、把视频转讲义，但一份漂亮摘要不能证明阅读发生了——更深入用法是让它帮忙追踪论证（结论是什么、证据在哪、有哪些没说出口的前提）、提反例，再合上材料自己复述、回原文核对
限制我们的，经常是还没想到"这件事也能委托". 观察一天里重复、烦琐、又能判断对错的数字任务，往往就是最好的起点.
工具可以组合，成功经验可以复用¶
通用 Agent 已经能做不少事，专门的工具/插件能缩短它的探索路程. 以浏览器为例：普通使用者看到网页、按钮、输入框；CS 学生还知道背后有 DOM、网络请求、事件、状态——调试接口能提供比逐像素猜测更直接的观察与操作方式.
"对计算机世界里有什么有概念" 这件事很重要：不一定要亲手实现每个接口，但要知道任务可能在哪一层被解决. 例如用网页自动化处理学校办事大厅的重复事务，把成功操作沉淀成脚本——第一次让 Agent 探路，之后重复使用可检查、可修改的程序，昂贵的探索就变成了可复用的资产.
这些能力还能相互增强：网页/视频/论文可以是信息源，检索/分类/总结是处理过程，文档/提醒/文件上传是输出动作——接口接得起来，它们就不再是孤立功能（这也是软件工程一贯的思想：分解问题，再通过组合获得比单个部件更大的能力）. 但插件数量不等于系统质量：一环误解结果，下一环可能放大错误，链条整体是否可靠仍取决于每一步能否核实数据和动作.
编程能力的边界，比作业大得多¶
把 Agent 只用来做作业，属实大材小用. 可以现场制造工具，解决以前不值得专门开发软件的小问题：
- 考试统分：拍照 → 离线模型识别姓名/学号/小分 → 按相反顺序复核并读出算式（如"11+12+13+14+15=65"）→ 教师检查后誊写 → 汇总进教务系统模板. 重点不只是识别文字，而是原始照片、小分、算式、总分、表格构成一条可回查的链，反序复核能把错位、漏项、误识别暴露出来
- 思考题：一台严格管控"文件流出"的机器，如果仍能显示画面，信息真的"只进不出"吗？——课堂的二维码 Excel 案例正是从"重新解释部件用途"出发：Excel 公式也能计算，屏幕也能承载编码信息
要建立的是一种 CS 眼光：不要只按应用程序的名字想象用途，要看它实际提供了什么输入/计算/输出能力（同理，视频可由脚本+分镜+字幕+时间线描述，物体可由 CAD 模型+制造指令描述）. Everything is code，把 Agent 的工作范围从"写一个程序"扩展到了许多可由计算过程驱动的产物.
案例复盘：二维码 Excel 为什么掉进了泥潭¶
"Idea 有了，就差一个程序员"这个老梗在 AI 时代还没过时——前端、后端、交互、部署、运营要共同成立，任何环节出问题整体都可能失败，能生成每个部件不代表能组织好整个系统.
需求：只用 Excel 2019 及以前兼容的公式，把可能长达数千字符的字符串 Base64 编码后拆成二维码帧，刷新时循环播放，扫描拼接后应还原为完整字符串，且要用接近真实环境的方式验证公式确实算对.
看似具体的需求里其实藏着大量未决选择：字符串编码方式？一帧装多少内容？输入变化时公式/工作表要不要重建？"按 F9 刷新"和"一秒一帧"怎么配合？工作簿能打开就算完成，还是每帧能被真实解码器读回、拼接还原原文才算完成？
实测记录：
| 尝试 | 结果 |
|---|---|
| GLM-5.3 (第一次) | 首轮思考 25 分钟，撞上输出长度限制，共耗时 6 小时完成 |
| DeepSeek V4 Pro | 交出硬编码版本，指出问题后承认需要重新设计 |
| GLM-5.3（经提示调整后） | 200K 上下文内完成正确且可维护的版本，公式可复用，工作表结构不随文本变长而膨胀 |
硬编码尤其说明问题：用户要的是对不同输入都成立的计算过程，模型却可能交出一个只让当前输入看起来正确的结果——演示成功和需求实现之间，隔着一个很大的差别.
所以判断 AI slop 不能只看文件多大、代码多丑，更关键的是修改有没有局部性：改一处会不会迫使整个系统重来？如果每次变化都要重新解释全部隐含关系，项目就已经接近《人月神话》里的焦油坑——越挣扎越消耗，加入更多生成能力也可能只是更快地把自己埋进去.
Intent、Spec、Impl 之间的缺口¶
这是本课的一条主线：
- Intent（意图）：真正想达成的目标，往往连提出者自己都没想清楚（"做一个好用的工具"包含大量未表达的期待）
- Spec（规格）：把意图具体化后，能描述行为与约束的规格
- Impl（实现）：程序实际执行的计算——必须在每个分支上做出确定动作，不能留"到时候看着办"
从 Intent 到 Spec 需要产品判断，从 Spec 到 Impl 需要设计与实现判断. 同一意图允许许多规格，同一规格又允许许多实现，每一步看似合理，最终仍可能离用户想要的东西很远. 即使程序通过了现有测试，也只能说明满足了这些检查，不能推出规格忠实表达了真实意图.
模型怎么填补这些空白？很大程度上靠猜——总不能每选一种颜色都问用户；但在架构、数据表示、验收标准上猜错，代价就大得多. 这也解释了为什么"立即遵循指令"有时会把事情做坏：模型迅速进入实现，许多重要选择还没被看见就已经固化在代码里，之后每一步都在维护早期决定，走进一个很难掉头的方向. 好的协作需要让重大假设及时显露，也要给推翻假设留出空间.
让大工程获得及时反馈¶
软件工程讨论的是怎样在人与工具的共同协作下把一件大事做成，包含技术，也包含组织、沟通、责任、动机. LLM 时代失败的定义没有根本改变：软件没有满足真实意图与约束，就是失败.
学校题目通常几分钟/几小时内有答案；真实工程的反馈可能很晚才来（用户开始用才发现流程不对，需求改变才发现结构无法维护）. 长程任务难就难在，还没有明确分数的时候，也要持续判断方向.
拆解、验证、迭代仍然有用：
- 拆解：把大问题变成能看清因果的小问题
- 测试 & 持续集成：让已发现的错误不再轻易回流
- 小步修改：让新的失败尽早出现，便于定位和回退
以二维码 Excel 为例，更好的顺序是：先拿短字符串完成单帧二维码，让独立解码器真实读回原文（验证最核心的计算）→ 扩展到不同输入/Base64/分片 → 验证多帧顺序与拼接 → 最后处理刷新/兼容性/性能. 每一步都留下可执行检查，逐步消除具体的不确定性，而不是等整个文件写完才看能不能用.
当生产变便宜，什么成为瓶颈¶
课堂用一个夸张算式说明新的成本结构：假设生成能力提高一千倍，即使只有 1% 是垃圾，垃圾的绝对量也达到旧时代全部产量的十倍. 错误率很小和维护负担很小，不是一回事.
生成可以越来越快，逐行阅读却难以同样加速——新的工程工作因此更依赖好的规格、独立检查器、测试、可观测性和清晰接口，让判断也能跟上生产，把人的注意力花在最值得判断的地方.
"古法编程死了" 表达的是一个正在发生的机会：对边界清楚、能得到有效反馈的任务，手工实现的稀缺性正在下降. 但软件工程还没死——一个人有机会调动过去需要一个团队才能拥有的实现能力，去解决以前连开始都不敢想的问题.
课堂把最后的问题说得很直接：
"为什么我要招你，而不是买一个 $200 的 Claude Max？除了你可以坐牢，你还提供了什么？"
把目光放回这学期：我发现了什么值得解决的问题？我怎样把模糊愿望变成可以检验的目标？失败发生时，我凭什么知道该换一条路？——这比单独展示"AI 替你生成了多少代码"更能说明学到了什么.