# 生成式软件工程：第一课笔记

## 核心论点

> AI 已经把"把一个明确任务做出来"变得很便宜；未来计算机专业真正稀缺的能力，是**定义正确的问题、设计正确的系统、约束 AI，并让软件长期保持正确、可维护和可演化**。

老师的激进总结：

> "**古法编程已经死了，软件工程暂时还没有死。**"

---

## 一、为什么开这门课

计算机史上的重大革命本质上都在把过去昂贵、稀缺的能力变成普通人的日用品：

**PC → 互联网 → 移动互联网 → ChatGPT**

今天的变化不只是"多了一个能聊天的软件"，而是**一大类原本需要专业训练才能完成的智力劳动正在迅速变便宜**。以前你需要：

- 会 Linux 才能配置 Linux
- 会写脚本才能自动化
- 会前端才能做网页
- 会系统管理才能排查机器问题
- 会读大量论文才能快速了解一个领域

现在 Agent 已经能完成其中相当大一部分工作。

由此产生尖锐问题：

> 如果 AI 可以帮你做作业、写代码、写简历，那么你大学四年究竟应该训练什么？

"AI 替我上大学"的例子就在表达这个矛盾：老师用 AI 出题，学生用 AI 做题，整个流程都完成了，**但学生本人没有得到训练**。这也是整门课的出发点。

---

## 二、第一层变化：LLM → Agent

### 1. 大语言模型

大语言模型本质上是一个**学习到的概率分布**：给定前面的上下文，不断预测

$$P(\text{next token} \mid \text{context})$$

然后一个 token 一个 token 地生成下去——ChatGPT 并不是"脑子里先形成完整答案再写出来"，而是在不断预测下一个 token。

课程采取的是**使用者/软件工程师视角，而不是模型研究者视角**：只需知道"有一个足够聪明的模型，可以接受输入、产生输出"，不深入研究怎么训练模型。

### 2. Agent 是什么

关键变化：以前模型只能

$$\text{输入文本} \rightarrow \text{输出文本}$$

现在可以

$$\text{思考} \rightarrow \text{调用工具} \rightarrow \text{观察结果} \rightarrow \text{继续思考} \rightarrow \text{再次调用工具}$$

形成一个 loop。例如用户说"帮我配置 Linux"，Agent 会：

1. 查看系统
2. 查配置文件
3. 修改配置
4. 执行程序
5. 发现报错
6. 分析错误
7. 修改
8. 再运行
9. 验证

模型可以输出特殊调用让程序运行，再把结果重新放回上下文，于是 Agent 能不断尝试直到任务完成——模型从**"回答问题的东西"**变成**"可以执行任务的东西"**，这就是今天 coding agent 强大的根源。

---

## 三、最重要的变化：学习方式反过来了

| 传统学习路径 | Agent-native 路径 |
|---|---|
| 先学习 → 理解原理 → 练习 → 最后做出东西 | 先让 Agent 做出来 → 观察它做了什么 → 遇到问题就问它 → 再回头理解 |
| `Knowledge → Action` | `Action → Reflection → Knowledge` |

老师概括为：

> 先用好它，先把东西搞出来，再回头复盘理解。

注意这不是"以后不用学习了"，而是**学习的顺序变了**，材料认为这种方式可能极大缩短传统计算机技术的学习曲线。

### 使用 Agent 的两个基础原则

1. **现在就开始用**：不要先学几十篇"Prompt Engineering 教程"，直接给它任务
2. **随时问它**：
   - 不知道 → "你为什么这么做？"
   - 不懂配置 → "这个配置是什么意思？"
   - 出了错 → "为什么失败？"
   - 不知道还能干什么 → "这个环境里你还可以帮我做什么？"

课程把仓库中的 Agent 配置文件比作 Agent 的**"临时基因"**：通过上下文和配置，让 Agent 知道自己处于什么项目、承担什么职责。老师总结："**开始用；随时问。**" 并进一步提出：

> **想象力是 Agent 能力上限的重要限制。**

---

## 四、为什么 Skill 很重要

这部分比"Prompt 怎么写"重要很多。假设让 Agent 做一件事：打开网页 → 登录 → 找到某个页面 → 填表 → 提交。第一次 Agent 可能需要探索，但一旦找到正确路径，就可以把这次**一次性的成功经验**，沉淀成**脚本 / Skill / Workflow / Memory**，下次直接复用：

> Agent 走通一次以后，可以把成功路径沉淀成确定性的脚本，也可以形成记忆。

于是个人能力出现一个飞轮：

- **第一次**：告诉 AI "帮我处理这件事"，Agent 花很多时间探索
- **第二次**：把探索结果整理为 Skill
- **第三次**：Agent 直接调用 Skill

多个 Skill 还可以组合，例如：

`RSS Skill → 网页读取 Skill → 论文读取 Skill → 视频处理 Skill → 总结 Skill → 个人知识库`

于是产生 `信息源 → 处理 → 知识 → 行动`，而不是每天人工重复操作。老师特别类比 Unix：

> Unix 强大的原因之一就是程序可以自由组合；Agent 的不同 Skill 也可以互相组合，产生 1+1>2 的效果。

---

## 五、"个人能力飞轮"

传统工作方式：今天搜资料 → 明天重新搜资料 → 后天重新整理 → 下周重新总结 → **每天重新劳动**。

Agent-native 工作方式：

```
第一次完成任务 → 总结方法 → 沉淀 Skill/Script → 以后自动执行
    → 发现不足 → 改进 Skill → 能力继续积累（回到自动执行）
```

于是工作不是不断重复"**做任务**"，而是在不断建设"**做任务的系统**"。老师认为 Skill 生态使"复用别人的能力"变得极其容易——这实际上已经开始接近"软件工程"了。

---

## 六、CS 人的新优势：知道 AI 的边界

误解：既然普通人说一句话 AI 就能编程，CS 还有什么用？老师的答案：

> CS 人真正的优势不再主要是"我会敲代码"，而是"我知道计算机系统能做什么，以及应该怎样把一个问题变成计算机可以可靠解决的问题"。

例如任务"帮我统计 140 张试卷的成绩"：普通人的 prompt 可能只是"帮我自动统计这 140 张试卷"，但懂 CS 的人会立即拆解：

`图像采集 → OCR 识别 → 人工确认 → 确定性算分 → 生成 Excel → 抽样验证 → 提交`

更重要的是知道**什么可以交给大模型，什么不应该**：OCR 可以用 AI，但精确加法要交给确定性程序，而不是让 LLM 心算。材料明确说老师不会让大模型负责加分，而用脚本计算，并保留人工检查，因为 OCR 会出错。这体现的核心能力就是：**知道 AI 的边界**。

---

## 七、真正进入"软件工程"的地方

前半节课在告诉你"AI 非常强"；后半节突然转向：

> **但是强不等于能构建好产品。**

老师总结：

> 一个产品是系统性工程。前端、后端、交互、运营等任何环节出了问题，产品都可能失败；即使 AI 每一项都能单独完成，也不意味着整个系统能成功。

换句话说：

$$\text{会生成代码} \neq \text{会做软件}, \quad \text{代码正确} \neq \text{软件工程成功}$$

这就是"生成式软件工程"存在的理由。

---

## 八、关键案例：AI 会"做出来"，但做出的东西可能是垃圾工程

老师设计了一个 Excel/二维码类的小项目测试 Agent。关键不在项目本身，而在实验结果：**AI 最终确实完成任务了**，但：

> 生成出来的系统大量硬编码，难以维护。

> Agent 完成任务能力很强，但产生的系统可能无法继续维护，会直接掉进软件维护的泥潭。

| 判断标准 | Vibe coding | 软件工程 |
|---|---|---|
| 关注点 | 能运行吗？能 → ✓ Done | 正确吗？可读吗？可测试吗？可以修改吗？可以扩展吗？可以复用吗？需求变化怎么办？半年以后别人能接手吗？ |

> **"跑起来"只是软件生命周期的起点，不是终点。**

### 为什么 AI 特别容易写出这种代码

模型经过后训练以后，很习惯：`收到任务 → 马上开始做 → 测试通过 → 获得 reward`，于是形成一种很强的倾向——**"赶快把题做完"**。材料直接说：AI "上手解决问题的欲望太强"，这和学生刷题很像：一道算法题走完 `输入 → 程序 → AC` 就结束了。但工程问题不是"今天 AC 了吗？"，而是"半年后需求改变，你还能不能低成本修改？"——这需要完全不同的优化目标。

---

## 九、核心理论：三个空间

### ① Intention Space（意图空间）

我到底想干什么？例如老板说"我想做一个校园外卖系统"——这只是 intention，非常模糊。

### ② Specification Space（规范空间）

接下来必须把意图翻译成 specification，即"这个系统具体应该满足什么要求？"：

- 用户可以注册
- 用户可以选择餐厅
- 用户可以下单
- 商家可以接单
- 订单需要有状态
- 支付失败要恢复
- 配送员可以查看订单
- ……

### ③ Implementation Space（实现空间）

最后才是实现空间，例如：React/Vue？Java/Go？MySQL/PostgreSQL？数据库 schema 怎么设计？微服务还是单体？接口怎么定义？缓存怎么设计？——这些属于 implementation。

于是软件开发其实是：

$$\text{Intention} \rightarrow \text{Specification} \rightarrow \text{Implementation}$$

### 软件工程失败的本质：三个空间之间出现 Gap

这是这节课最核心的一句话之一。例如老板真正想要"简单好用的选课系统"，产品经理理解成"功能越多越好"，程序员理解成"把需求列表实现完就行"——最后所有功能都有，但谁都不会用。此时程序代码可能完全没有 bug，但软件仍然**失败**。为什么？因为：

$$\text{Implementation} \not\models \text{Specification}$$

或者更早：

$$\text{Specification} \not\models \text{Intention}$$

老师因此说：

> 即使到了大语言模型时代，软件工程失败的定义没有变化，本质依然是 intention → specification → implementation 的翻译出了问题。

### "生成式软件工程"研究的根本问题

> 怎样利用 AI 强大的实现能力，同时减少 Intention → Specification → Implementation 之间的错误？

传统流程：`人提出 intention → 人写 specification → 人设计 implementation → 人写代码`

现在流程：`人提出 intention → AI 猜 specification → AI 猜 implementation → AI 疯狂写代码`

速度确实快很多，问题是：**猜错得也更快**。所以未来真正有价值的人不是"能让 AI 多写 20% 的代码"，而是**能减少这种"猜"的人**。

---

## 十、工程品位案例：老师自己的 QR 项目为什么做得更好

其他 Agent 基本上：`需求 → 直接写 Excel 公式 → 不断 patch → 越来越复杂`。

老师采用的思路则近似：`问题 → 先设计抽象 → 建立中间表示 → 分别验证 → 生成目标实现`。他先让 AI 设计类似中间语言/DSL 的抽象，使相同逻辑既能在 Python 中执行，又能翻译成 Excel，然后分别验证：

`逻辑正确？ → Python 执行正确？ → Excel 翻译正确？ → 最终结果正确？`

材料里明确将它类比成编译器的中间语言。这就是软件工程和"让 Agent 干活"的区别：

> **高手不是 prompt 写得更花，而是给问题设计了一个更好的结构。**

### 不要一开始扩大问题

> 软件工程第一步不要扩大，做最简单的东西，不会失败。

意思接近于：不要第一句话就"给我造一个完美系统"，而应该先找**最小正确核心**：

`先解决一个输入 → 验证核心算法 → 验证边界 → 建立抽象 → 逐步扩展`

这背后和很多传统工程原则是同一种思想：separation of concerns、modularity、abstraction、incremental development、testability。所以 AI 出现以后，很多经典软件工程原则反而更加重要。

---

## 十一、《人月神话》为什么又出现了

《人月神话》最著名的思想：一个已经延期的软件项目，再增加人手，往往只会让它更加延期。课程把它类比到 Agent：

| | 传统项目 | AI 项目 |
|---|---|---|
| 起点 | 项目已经烂了 | 代码已经变成 AI slop |
| 加码 | + 更多程序员 | + 更多 token |
| 结果 | ≈ 更烂 | ≈ 更多 AI slop |

> 一个产品已经开始产生 slop 时，投入更多 token 可能只是继续在失败的基础上堆东西。

所以：**Token 不是架构的替代品**，模型更聪明也不是工程设计的替代品。

---

## 十二、未来学生真正应该训练什么：四层能力

不是简单地"学更多编程语言"或"学 Prompt Engineering"，而是四层能力：

1. **会使用 AI**：模型、Agent、Tools、Browser use、Computer use ——基础能力
2. **会让能力复用**：`Prompt → Workflow → Script → Skill → Agent system`，不要每天从零开始
3. **懂计算机系统**：只有懂 CS，才能判断什么让模型做、什么让程序做、什么必须人工确认、哪里需要数据库/状态/测试/抽象，也就是**知道边界在哪里**
4. **软件工程能力**：`发现问题 → 澄清 intention → 形成 specification → 选择 architecture → 指导 implementation → 验证 → 演化`

这才是这门课真正想训练的东西。

---

## 十三、人类价值

课程最后假设导师问你："**为什么我要招你，而不是花 200 美元买一个 AI？**" 材料给出的回答：

> 能找到值得解决的问题；把未知拆成便宜的实验；用证据让坏方向及时停下；并对长期结果负责。

这几句话其实比"古法编程已经死了"更重要，因为它重新定义了未来工程师的角色。以前工程师最大的价值可能是"我会实现"；未来越来越变成：

- 我知道应该实现什么
- 我知道怎样验证它值得实现
- 我知道怎么把问题拆开
- 我知道什么时候 AI 做错了
- 我知道什么时候应该推倒重来
- 我能让这个系统长期工作
- 最后结果出了问题，我负责

---

## 十四、整节课逻辑图

```mermaid
flowchart TD
    A[AI 能力迅速增强] --> B[单个任务越来越便宜<br/>写代码/查资料/操作]
    B --> C["会不会写代码"价值下降]
    C --> D[普通人能力升级<br/>Agent + Skill + Workflow]
    C --> E[CS 人的新优势<br/>理解计算边界]
    D --> F[做更大的系统]
    E --> F
    F --> G[AI 开始暴露弱点<br/>误解/硬编码/slop<br/>缺架构/难维护]
    G --> H[软件工程仍然必要]
    H --> I["Intention → Specification → Implementation<br/>缩小这些 Gap"]
    I --> J[生成式软件工程]
```

这门课**不是一门"教你怎么用 AI 写代码"的课**，更准确地说，它研究的是：

> 当代码生成本身越来越不值钱之后，我们应该怎样组织人、AI、工具、规范、测试和架构，可靠地构造真正的软件系统。

---

## 关键术语速查

| 术语 | 一句话解释 |
|---|---|
| Agent-native 学习法 | 先让 Agent 做出来、观察、提问，再回头理解原理的反向学习顺序 |
| Skill / Workflow | 把一次性探索成功的路径沉淀为可复用脚本/流程 |
| 个人能力飞轮 | 任务完成→总结方法→沉淀 Skill→自动执行→改进→能力持续积累的循环 |
| Intention Space（意图空间） | 最原始、模糊的需求出发点 |
| Specification Space（规范空间） | 把意图翻译成的具体系统行为要求 |
| Implementation Space（实现空间） | 技术栈、架构、代码等具体实现 |
| AI slop | AI 生成的、堆砌 patch、难以维护的低质量代码/系统 |
| Vibe coding | 只关心"能不能跑起来"，不关心可维护性的编码方式 |
| "临时基因"（Agent 配置文件） | 仓库中的 Agent 配置/上下文，让 Agent 知道自己处于什么项目、承担什么职责 |