大四上 生成式软件工程 第一课：当 AI 会写代码以后，我们还需要学习什么？ 20260902

生成式软件工程第一课：当 AI 会写代码以后，我们还需要学习什么？【AI辅助生成】

一、生成式软件工程为什么会出现？

过去计算机技术的发展，本质上一直在降低某种能力的使用门槛。

从 PC、互联网、移动互联网，到如今的大语言模型与 Agent，越来越多原本需要专业知识才能完成的工作，正在迅速变得廉价。

以前，要完成一个技术任务，我们通常需要先掌握相关知识。例如配置 Linux，要学习 Shell、配置文件、系统工具，再经过大量试错才能完成。

现在，AI Agent 已经可以代替人完成相当一部分探索过程。

因此，一个很现实的问题出现了：

如果 AI 已经可以写代码、查资料、配置环境、完成作业，那么大学里的计算机专业学生究竟应该训练什么？

这也是“生成式软件工程”真正想讨论的问题。

---

二、从 LLM 到 Agent

大语言模型最基础的工作方式仍然是根据上下文预测下一个 Token：

\[P(\text{next token}\mid \text{context}) \]

然后不断生成后续内容。

但 Agent 和普通聊天模型之间有一个关键区别：

Agent 不只是输出文本，而是能够调用工具并根据执行结果继续行动。

一个典型过程是：

理解任务
↓
决定下一步操作
↓
调用工具
↓
读取结果
↓
分析结果
↓
再次行动
↓
验证任务是否完成

例如让 Agent 配置一个 Linux 环境，它可以自己查看系统、修改配置、执行程序、读取报错、继续修改并最终验证。

因此，大模型正在从：

回答问题

变成：

执行任务

这也是 Coding Agent 能力快速提升的重要原因。

---

三、AI 正在改变学习顺序

传统的学习模式通常是：

Knowledge
↓
理解
↓
练习
↓
Action

也就是先学习知识，再尝试完成任务。

Agent 出现以后，可以采用另一种模式：

Action
↓
Reflection
↓
Knowledge

先让 Agent 帮你完成任务，然后观察它做了什么；遇到看不懂的地方，再继续追问；最后通过复盘真正理解其中的知识。

因此，并不是“以后不用学习”，而是：

学习和实践的顺序正在发生变化。

以前经常是：

学会以后再做。

以后可能越来越多地变成：

先做出来，再通过做的过程学习。

---

四、使用 Agent 的两个基本原则

1. 尽早开始使用

与其先花大量时间研究 Prompt Engineering，不如直接把真实任务交给 Agent。

Agent 的能力很难单纯通过阅读教程理解，很多时候必须真正使用才能知道它能做到什么。

2. 不懂就继续问

例如可以不断追问：

• 为什么要这样做？
• 这个配置是什么意思？
• 为什么刚才执行失败？
• 有没有更简单的方法？
• 这个环境里你还能完成什么工作？

与传统软件不同，Agent 本身也是一个解释系统。

因此，使用 Agent 的过程，同时也可以成为学习过程。

---

五、Skill 为什么重要？

真正值得积累的并不是某一次 Prompt，而是：

成功完成任务的方法。

例如第一次让 Agent 完成一个网页操作任务：

打开网页
→ 登录
→ 找到页面
→ 填写信息
→ 提交

第一次执行时，Agent 可能需要大量探索。

但一旦路径跑通，就可以把这套经验沉淀为：

Prompt
Workflow
Script
Skill
Memory

下一次遇到类似任务，就不需要重新探索。

这意味着 AI 使用方式可以从：

每次重新解决问题

升级为：

不断积累解决问题的系统

而 Skill 之间还可以继续组合。

例如：

RSS 获取
↓
网页读取
↓
论文解析
↓
视频处理
↓
内容总结
↓
个人知识库

最后形成完整的信息处理流水线：

\[信息源 \rightarrow 处理 \rightarrow 知识 \rightarrow 行动 \]

---

六、个人能力飞轮

传统工作方式中，同一种劳动经常被不断重复。

今天搜资料，明天重新搜；今天整理信息，下周又重新整理。

Agent-native 的工作方式则可以变成：

第一次完成任务
↓
总结成功方法
↓
沉淀 Skill / Script
↓
自动复用
↓
发现不足
↓
修改 Skill
↓
能力继续积累

因此，真正有价值的事情逐渐从：

完成任务

变成：

建设完成任务的系统。

这是使用 Agent 时非常值得建立的一种思维。

---

七、AI 时代，计算机专业的优势在哪里？

如果普通人也可以通过自然语言让 AI 写程序，那么计算机专业还有什么优势？

关键并不是“比普通人更会敲代码”。

而是：

计算机专业的人更清楚一个问题应该怎样被计算机可靠地解决。

例如统计大量试卷成绩。

一个简单的思路可能是：

让 AI 把所有试卷识别出来然后算分。

但一个更可靠的系统应该拆成：

图像采集
↓
OCR
↓
人工检查
↓
确定性程序计算
↓
生成 Excel
↓
抽样验证
↓
输出结果

这里最重要的是知道：

什么应该交给 AI，什么应该交给传统程序，什么必须由人确认。

例如：

• 图像识别可以交给 AI；
• 精确计算应该交给程序；
• 高风险识别结果应该保留人工校验。

因此，未来非常重要的一项 CS 能力是：

知道 AI 的边界。

---

八、会生成代码，不等于会做软件

这是整个课程非常重要的转折。

AI 很擅长完成一个明确任务，但：

\[会生成代码 \neq 会构建软件 \]

甚至：

\[代码能够运行 \neq 软件工程成功 \]

一个真正的软件系统不仅要“能运行”，还要考虑：

• 正确性；
• 可读性；
• 可测试性；
• 可维护性；
• 可扩展性；
• 可复用性；
• 需求变化后的修改成本；
• 团队成员能否长期接手。

所以 Vibe Coding 往往关注：

能不能跑？

而软件工程关注的是：

能不能长期可靠地跑？

“跑起来”只是软件生命周期的开始。

---

九、为什么 AI 很容易写出难维护的代码？

Agent 有一个很明显的倾向：

收到任务
↓
立即解决
↓
测试
↓
通过
↓
结束

这和做算法题非常像。

只要测试通过，就意味着任务完成。

但是软件工程的目标不是：

今天能不能 AC？

而是：

半年以后需求变化时，这套系统还能不能低成本修改？

因此，AI 很容易为了完成当前任务而：

• 大量硬编码；
• 不设计抽象；
• 不考虑未来修改；
• 不断打补丁；
• 最终形成难以维护的代码。

这也是 AI Coding 和真正软件工程之间最重要的区别之一。

---

十、软件工程的三个空间

课程中非常重要的一个框架是：

\[Intention \rightarrow Specification \rightarrow Implementation \]

1. Intention Space：意图空间

解决：

我到底想做什么？

例如：

做一个校园外卖系统。

这只是一个模糊目标。

---

2. Specification Space：规约空间

接下来要把模糊目标变成明确要求。

例如：

• 用户能够注册；
• 用户能够选择餐厅；
• 用户能够下单；
• 商家能够接单；
• 订单有明确状态；
• 支付失败能够恢复；
• 配送员能够查看订单。

只有到了这一层，需求才逐渐变得可以执行和验证。

---

3. Implementation Space：实现空间

最后才是技术实现：

• React 还是 Vue？
• Java 还是 Go？
• MySQL 还是 PostgreSQL？
• 数据库怎样设计？
• 微服务还是单体？
• API 怎样定义？
• 缓存怎样设计？

这些才属于具体实现。

---

十一、软件工程失败，本质上是三个空间之间出现 Gap

很多项目失败，并不是程序有 Bug。

更常见的问题是：

真正想要的东西
≠
写进需求里的东西
≠
最终实现出来的东西

也就是：

\[Specification \not\models Intention \]

或者：

\[Implementation \not\models Specification \]

例如用户真正想要的是一个简单好用的系统，但需求在不断沟通中变成了“功能越多越好”。

程序员最终把所有功能全部正确实现了。

代码没有 Bug，功能也全部存在。

但产品依然没人愿意使用。

这仍然是一次软件工程失败。

因此，大语言模型出现以后，软件工程最根本的问题其实没有改变：

如何减少 Intention、Specification 与 Implementation 之间的信息损失和理解偏差。

---

十二、生成式软件工程真正研究什么？

传统的软件开发流程大致是：

人提出 Intention
↓
人形成 Specification
↓
人设计 Implementation
↓
人写代码

AI 出现以后可能变成：

人提出 Intention
↓
AI 推测 Specification
↓
AI 推测 Implementation
↓
AI 快速生成代码

开发速度确实更快了。

但问题也随之出现：

AI 不仅实现得更快，也可能把错误理解实现得更快。

所以未来真正稀缺的能力，不一定是：

让 AI 再多写一点代码。

而是：

减少 AI 需要“猜”的地方。

---

十三、好的工程设计，比漂亮的 Prompt 更重要

面对复杂任务，一个常见做法是：

看到需求
↓
直接生成代码
↓
发现问题
↓
打补丁
↓
再次发现问题
↓
继续打补丁

系统最终会越来越复杂。

更好的方式则是：

理解问题
↓
设计抽象
↓
建立中间表示
↓
分别验证
↓
最后生成目标实现

例如同一套业务逻辑可以先建立一个统一的中间表示，再分别转换到 Python、Excel 或其他目标平台。

这样可以分别验证：

业务逻辑正确？
↓
中间表示正确？
↓
目标代码转换正确？
↓
最终结果正确？

这体现了一种非常重要的工程能力：

高手的优势通常不是 Prompt 写得更复杂，而是能为问题设计更好的结构。

---

十四、从“最小正确核心”开始

面对复杂系统，不应该一开始就要求：

给我做一个完整而完美的系统。

更可靠的方法是找到一个：

最小正确核心。

然后逐步扩展：

解决最小输入
↓
验证核心逻辑
↓
验证边界情况
↓
建立合理抽象
↓
逐渐扩展系统

这与传统软件工程中的很多思想完全一致：

• Separation of Concerns；
• Modularity；
• Abstraction；
• Incremental Development；
• Testability。

AI 出现以后，这些经典原则并没有过时，反而变得更加重要。

---

十五、Token 不能代替架构

《人月神话》中有一个经典观点：

一个已经失控的软件项目，仅仅增加更多人手，并不能自动解决问题。

AI Coding 时代也有类似现象。

如果一个系统本身的结构已经出现严重问题，那么：

错误架构
+
更多 Token

往往不会自动变成：

好架构

反而可能只是生成更多混乱代码。

所以需要牢记：

更多 Token 不是架构设计的替代品。

模型能力更强，也不能替代工程判断。

---

十六、未来应该训练的四层能力

第一层：使用 AI

掌握：

• 大语言模型；
• Agent；
• Tools；
• Browser Use；
• Computer Use。

这是基础能力。

---

第二层：复用 AI 能力

不要每天从零开始。

逐渐完成：

Prompt
↓
Workflow
↓
Script
↓
Skill
↓
Agent System

把个人经验积累成可以重复调用的能力。

---

第三层：理解计算机系统

能够判断：

• 什么应该让模型完成；
• 什么应该让程序完成；
• 什么必须人工检查；
• 什么地方需要数据库；
• 什么地方需要保存状态；
• 什么地方必须测试；
• 什么地方应该建立抽象。

核心依然是：

知道系统与 AI 的能力边界。

---

第四层：软件工程能力

完整过程包括：

发现问题
↓
澄清 Intention
↓
形成 Specification
↓
选择 Architecture
↓
指导 Implementation
↓
验证
↓
持续演化

未来 AI 可以越来越多地承担 Implementation，但前面的判断、设计和后面的验证仍然非常重要。

---

十七、AI 时代的人类价值

当 AI 可以极低成本完成大量实现工作之后，一个工程师真正的价值可能逐渐变成：

• 找到值得解决的问题；
• 把未知问题拆成低成本实验；
• 用证据判断一个方向是否值得继续；
• 在错误方向上及时止损；
• 判断 AI 什么时候做错了；
• 决定什么时候应该重构甚至推倒重来；
• 让系统能够长期运行和演化；
• 对最终结果负责。

过去工程师经常通过：

“我能够把它实现出来”

体现自己的价值。

未来越来越重要的可能是：

我知道应该实现什么。

我知道怎样验证它值不值得实现。

我知道怎样把复杂问题拆开。

我知道 AI 在什么时候是不可靠的。

---

十八、整节课的核心逻辑

可以把第一课概括成：

AI 能力快速增强
↓
写代码、查资料、执行操作越来越便宜
↓
单纯“会写代码”的稀缺性下降
↓
Agent + Skill 大幅提升个人能力
↓
开始承担更复杂的软件任务
↓
AI 暴露出误解需求、硬编码、缺少架构、
难以维护等问题
↓
软件工程的重要性重新显现
↓
Intention
→ Specification
→ Implementation
↓
尽可能缩小三者之间的 Gap
↓
生成式软件工程

---

总结

生成式软件工程并不是单纯研究：

怎样让 AI 写更多代码。

真正的问题是：

当“生成代码”本身越来越廉价之后，我们怎样利用人、AI、工具、测试、规范和架构，共同构造一个正确、可靠、可维护、能够长期演化的软件系统。

未来工程师的核心竞争力，也可能逐渐从：

我会不会实现

迁移到：

我能不能定义正确的问题
↓
设计正确的结构
↓
控制 AI 的行为
↓
验证最终结果
↓
并对系统长期负责

这或许才是 AI 时代软件工程真正需要重新学习的东西。