大四上 生成式软件工程 第二课：Prompt Engineering 的本质正在变成 Context Engineering 20260902
生成式软件工程第二课：Prompt Engineering 的本质正在变成 Context Engineering 【AI辅助生成】
一、Prompt 不只是你输入的那句话
提到 Prompt，我们很容易想到聊天框里输入的那句话，例如：
帮我写一个网页。
但对于今天的 Agent 来说，真正决定其行为的并不只有这句话。
一个 Agent 实际接收到的信息可能包括：
System Prompt
↓
全局规则
↓
项目级规则
↓
AGENTS.md
↓
Skill
↓
Tool Definitions
↓
当前运行环境
↓
历史对话
↓
历史工具调用
↓
工具执行结果
↓
User Prompt
所以更准确地说：
而应该理解为：
模型最终怎样行动，是整个上下文共同作用的结果。
因此，现代 Prompt Engineering 已经越来越接近：
Context Engineering
也就是：
怎样设计模型工作时能够看到的上下文。
二、不要迷信“神奇 Prompt”
早期使用大语言模型时，经常能看到这样的 Prompt：
你是一名拥有 20 年工作经验的世界顶级软件工程师，
精通 C++、Linux、数据库、分布式系统……
请仔细思考，一步一步完成任务。
这种 Prompt 在早期模型上确实可能产生一定效果。
本质上，它是在不断提醒模型：
专家
专家
专家
从而让模型更容易生成类似“专家回答”的文本。
但是现代模型的指令遵循能力已经强了很多。
相比这些“咒语”，真正重要的问题变成了：
我要什么？
↓
有哪些约束？
↓
模型需要知道什么？
↓
什么情况下算任务完成？
↓
怎样验证结果？
所以：
Prompt Engineering 并不是语言修辞比赛。
真正重要的不是：
有没有一句话能让 AI 突然聪明十倍？
而是：
能不能把问题描述成一个 AI 不容易理解错的任务。
三、Prompt Engineering 本质上仍然是在缩小三个空间之间的 Gap
第一课中有一个很重要的框架：
例如你告诉 AI：
给我做一个赛车游戏。
AI 完全可以做出：
- 汽车；
- 道路；
- 碰撞；
- 物理系统；
- 3D 场景；
- 驾驶操作。
甚至看起来非常完整。
但问题在于：
它是不是你脑子里的那个赛车游戏？
你真正想要的可能是：
真实地图
+
真实车辆
+
特定校园场景
+
特定驾驶视角
+
特定操作体验
如果这些东西没有说出来，AI 就只能：
猜。
所以一个非常重要的规律是：
AI 能力越强，并不能解决模糊需求的问题。
甚至存在一种更加危险的情况：
AI 猜错之后，会非常高效地把错误方向实现出来。
四、Verifier：可能是 Prompt 中最重要的东西
一个特别重要的概念是：
Verifier
也就是：
验证器 / 验证标准。
例如：
把这个程序修好。
本身并不是一个特别强的任务定义。
但如果同时存在：
pytest
并且规定：
全部测试通过 = 任务完成
那么 Agent 就可以形成一个闭环：
修改代码
↓
运行测试
↓
失败
↓
分析错误
↓
继续修改
↓
再次运行测试
↓
……
↓
全部 PASS
这时：
会表现得非常强。
因此，一个非常实用的原则是：
不仅要告诉 AI“要做什么”，还要告诉 AI“怎样知道自己做对了”。
五、一个好的任务描述可以拆成四部分
可以把有效 Prompt 简化为：
1. Goal
我要什么？
2. Constraints
有哪些不能违反的限制？
3. Context
完成任务需要知道哪些信息？
4. Verifier
怎样判断任务已经正确完成？
也就是：
例如不要只是：
帮我做一个个人主页。
而可以进一步限定：
Goal：
制作个人学术主页。
页面：
首页、论文、项目、联系方式。
视觉：
简洁克制，有终端感。
避免：
大面积渐变、玻璃效果、
巨大 Hero、过多圆角卡片。
交互：
实现真实可操作的 terminal interaction。
Verifier：
运行网页并逐页截图，
检查所有页面以及视觉约束是否满足。
这时候 AI 的搜索空间就被大幅压缩了。
六、为什么很多 AI 网页都有一股“AI 味”？
如果告诉模型：
做一个现代、漂亮的网页。
模型可能生成：
巨大 Hero
+
渐变背景
+
圆角卡片
+
玻璃效果
+
悬浮动画
+
大字号标题
技术上不一定难看。
但是一眼就容易产生：
这是 AI 做的。
为什么？
因为“现代、漂亮”本身几乎没有提供有效约束。
模型只能从训练数据中选择：
最可能被称为“现代网页”的东西。
于是：
而：
所以 AI 时代并没有降低“品味”的重要性。
恰恰相反：
品味会更加重要。
因为实现可以交给 AI。
但你至少必须知道：
好东西到底长什么样？
只有见过足够多优秀设计，你才能说清：
- 哪种字体好；
- 哪种布局好；
- 哪种间距合理；
- 哪种交互令人舒服；
- 哪种视觉效果是你不喜欢的。
AI 帮你实现审美，但不能替你拥有审美。
七、AI 也正在改变我们的学习方法
AI 可以成为一个成本极低，而且几乎拥有无限耐心的老师。
你可以不断问：
这是什么？
为什么？
再解释一次。
举个例子。
我还是不理解。
从高中生能听懂的程度开始讲。
它和刚才那个概念有什么关系？
但更好的学习方式并不是永远让 AI 当老师。
还可以把关系反过来。
第一阶段：
AI = 老师
你 = 学生
让 AI 给你讲。
第二阶段：
你 = 老师
AI = 学生
然后告诉 AI：
现在假设你完全不知道这个知识。
我给你讲一遍。
如果我的解释中存在逻辑错误、
知识遗漏或者推理跳跃，请指出来。
于是形成：
AI 给你讲
↓
你理解
↓
你重新组织知识
↓
你讲给 AI
↓
AI 挑战你的解释
↓
你修正理解
这实际上就是一种 AI 辅助的费曼学习法。
八、为什么“思考很多轮”会明显提升模型能力？
可以把人脑简单理解成一个容量有限的计算系统。
如果只靠脑内计算：
一步完成复杂问题
通常非常困难。
但如果加入：
纸 + 笔
情况就完全不同。
你可以：
思考一步
↓
把结果写下来
↓
观察
↓
继续推理
↓
写下下一步
↓
重新检查前面的结果
大模型也存在类似机制。
它可以利用 Context 作为一种外部工作空间：
尝试
↓
记录结果
↓
检查
↓
发现错误
↓
修正
↓
再次尝试
于是一个原本要求“一次做对”的复杂问题，被转换成：
很多局部的、小规模决策。
从直觉上可以理解为：
九、Context 并不是越多越好
既然 Context 很重要，一个自然想法是：
那我是不是应该把所有规则、知识、文档全部塞给 AI？
答案是否定的。
因为：
Context 会竞争 Attention。
例如上下文中有：
必须用中文回复。
但当 Agent 正在处理代码 Bug 时，它更可能关注：
函数
代码
错误日志
测试
需求
而不是一直关注语言要求。
等任务结束以后，它才可能重新关注“用中文总结”。
也就是说：
模型在不同阶段会对上下文中的不同内容给予不同权重。
于是：
规则 A
规则 B
规则 C
规则 D
规则 E
……
越来越多时，每条规则稳定发挥作用的难度也会上升。
所以：
真正需要优化的是：
十、不要无限扩张 AGENTS.md 和 Skill
一个很容易出现的问题是：
AI 第一次犯错：
增加规则 A
第二次犯错：
增加规则 B
第三次：
增加规则 C
然后不断出现：
必须……
禁止……
始终……
不要……
除非……
最终形成几千行甚至更多的规则文件。
但这些规则本身也开始占据 Context。
于是形成一个很有意思的矛盾：
增加规则
↓
模型行为更受约束
但与此同时：
增加规则
↓
Context 更复杂
↓
Attention 竞争更严重
↓
模型可能更难稳定遵循所有规则
所以 Context Engineering 并不是：
Context 越大越好。
而是：
只把真正高价值的信息放进 Context。
十一、为什么“让 AI 总结论文”存在问题？
一种常见的论文阅读方法是：
上传 paper.pdf
↓
帮我总结这篇论文
但这种方法存在一个问题：
Context Pollution
论文一般已经经过作者精心组织。
通常是：
A
↓
因此 B
↓
因此 C
↓
所以我们提出 D
↓
实验支持 D
↓
因此方法有效
整个 Narrative 非常完整。
当完整论文进入 Context 后，AI 很容易沿着作者已经构造好的逻辑继续走。
于是 AI 做的事情往往只是：
用更短的话重新讲一遍作者自己的故事。
这并不等于真正判断：
这篇论文究竟有没有价值？
因此：
十二、读论文应该先 Grounding
一种更好的方法是：
先不要让 AI 接受论文自己的 Narrative。
首先建立：
Grounding
也就是让 AI 回到已有知识边界。
可以依次询问：
这个问题此前研究到什么程度？
↓
当前最重要的已有工作是什么？
↓
哪些结论已经属于 known knowledge？
↓
目前的技术边界在哪里？
↓
这篇论文究竟增加了什么？
可以把论文理解成：
真正值得关注的是：
也就是：
这篇论文相比人类原本已经知道的东西，到底增加了什么？
而不是把十几页论文压缩成两页摘要。
十三、用 AI 学知识也应该先做 Grounding
例如你正在学链接器。
不要直接问：
给我解释 linker。
可以先告诉 AI：
我已经理解：
C语言
指针
虚拟内存基础
我还不了解：
链接
重定位
动态链接
我目前的理解是：
.cpp
→ compiler
→ executable
请从我的这个知识边界出发，
解释为什么中间还需要 linker。
这时 AI 就不再从：
它自己的全部知识
开始讲。
而是从：
你的知识边界
开始讲。
学习效果通常会好很多。
十四、最好的推理单位可能是“一步”
建立共同知识以后，还有一个重要原则：
一次往前走一步。
不要：
已知
↓
突然推十步
↓
结论
而应该：
共同已知知识
↓
向前一步
↓
检查
↓
确认正确
↓
再向前一步
↓
再次检查
原因非常简单：
一步推理通常更容易验证。
这和软件工程实际上是完全一样的：
十五、把失败蒸馏成 Skill
真正有效的 AI 使用过程，不应该是：
问 AI
↓
AI 做完
↓
结束
而应该是：
尝试
↓
失败
↓
分析失败原因
↓
改变方法
↓
重新尝试
↓
成功
↓
总结经验
↓
沉淀
最终把成功方法形成：
Prompt
Workflow
Script
Skill
这样同一种错误就不需要重复犯。
因此：
失败本身其实是一种训练数据。
每次失败以后都应该问：
为什么失败？
↓
下次怎样避免？
↓
有什么信息应该提前提供？
↓
有没有稳定方法可以固化？
最后：
把经验蒸馏成 Skill。
十六、真正困难的是 Long-Horizon Task
写一个函数、修一个 Bug、让测试通过，都属于目标非常明确的任务。
但是现实的软件工程往往是：
帮我做一个优秀的软件。
此时你只有：
Intent
但：
Specification = ?
Architecture = ?
Implementation = ?
全部未知。
这类需要长期探索、持续决策、不断演化的任务，可以理解为：
Long-Horizon Task
十七、为什么 Agent 容易在长期任务中翻车？
模型往往具有一种非常强的倾向：
尽快把当前任务完成。
例如：
做一个游戏
↓
一分钟完成 Demo
效果可能很好。
然后开始不断增加功能：
增加登录
↓
增加多人模式
↓
增加地图
↓
增加数据库
↓
增加云同步
↓
继续增加功能
↓
修改原有设计
慢慢就会出现：
修改越来越困难
↓
依赖越来越复杂
↓
Bug越来越多
↓
维护成本越来越高
也就是说：
从零快速完成 Proof of Concept 很容易。
但：
让一个系统长期保持健康，是另一回事。
这也是为什么 AI Coding 并不能自动替代 Software Engineering。
十八、一个反直觉现象：为什么 AI 修改 Linux Kernel 反而可能表现很好？
这件事看起来非常奇怪。
一个小型 AI 项目写久以后可能越来越混乱。
但是 Linux Kernel 这种拥有数千万行代码、几十年历史、极其复杂的项目，AI 有时反而能很好地修改。
其中一个重要原因是：
高质量代码库本身就是高质量 Context。
成熟的软件系统中，到处存在：
正确的命名
正确的抽象
正确的 Helper
正确的接口
正确的锁顺序
类似功能的已有实现
统一的代码规范
成熟的测试
AI 可以在 Context 中寻找已有模式。
例如：
这个功能不知道怎样写
↓
搜索类似实现
↓
发现三个相同模式
↓
按照已有模式实现
因此：
坏的上下文会把模型带偏。
好的上下文也会把模型带向正确方向。
十九、软件架构本身正在变成一种 Prompt
传统上：
代码
=
给 CPU 执行的东西
但 Agent 时代又增加了一层意义：
已有代码
=
Agent理解项目的Context
于是：
- 清晰的命名；
- 良好的抽象；
- 统一的模块设计；
- 完整测试；
- 稳定接口；
- 清楚文档；
- 高质量范例；
不仅方便人类工程师。
它们还会直接影响：
下一次 AI 如何修改这个项目。
因此：
Clean Code、Documentation、Consistency 等传统软件工程概念，在 Agent 时代重新获得了一层意义。
代码不仅在告诉机器怎样运行，也在告诉 AI 下一段代码应该怎样写。
二十、可以主动用“好的 Context”影响 AI
既然坏上下文会产生 Context Pollution，那么可以反过来思考：
能不能故意使用优秀工程经验影响 Agent？
例如：
优秀软件项目
↓
提取设计原则
↓
提取优秀范例
↓
形成文档 / Skill
↓
放入 Context
↓
让 Agent 开发新系统
相当于主动使用：
Positive Context Pollution
例如，可以将优秀的软件设计经验转化成 AI 可理解的约束：
什么时候封装？
什么时候应该拆模块？
接口应该有多深？
什么时候应该继承？
什么时候应该组合？
从而让 AI 不只是：
写出能运行的代码。
而是尝试：
写出更容易维护的代码。
二十一、有 AI 之后为什么仍然要学基础知识？
一个常见观点是：
AI 都会写代码了，还有必要学习操作系统、数据库、编译器吗？
答案仍然是：
需要。
因为以后学习这些东西，不一定只是为了：
手写某一段代码。
更重要的是让你知道：
系统应该怎样设计？
↓
AI为什么出错？
↓
什么信息应该进入Context？
↓
哪些实现明显不合理？
↓
哪些抽象存在问题？
如果完全没有基础知识：
你甚至不知道应该要求 AI 什么。
因此仍然需要理解：
- CPU；
- 操作系统；
- 编译器；
- 数据库；
- 网络；
- 软件架构；
- 软件设计。
AI 降低的是实现成本。
并没有消灭判断成本。
二十二、Prompt 也可能产生 Reward Hacking
假设真正的研究目标是：
判断方法 A 是否值得研究。
但是你对 Agent 说：
帮我证明方法 A 有效。
这两个目标看起来很接近。
实际上完全不同。
Agent 可能开始：
寻找 A 有效的 Benchmark
↓
找到一个
↓
继续寻找证明 A 有效的案例
↓
设计实验
↓
得到支持 A 的结果
整个过程中，Agent 看起来一直非常努力。
但它其实已经偏离了真正目标。
真正应该研究的是：
A到底有没有价值？
而不是：
怎样证明A有价值？
因此：
就会发生一种类似：
Reward Hacking
的现象。
模型非常完美地完成了：
你字面上要求它做的事情。
却没有完成：
你真正想解决的问题。
这也是为什么 Intention → Specification 之间的 Gap 如此重要。
二十三、AI 越强，错误目标反而可能越危险
弱模型如果理解错目标，可能：
做不好
↓
很快暴露问题
而强模型如果理解错目标，则可能：
理解偏差
↓
高效执行
↓
不断优化
↓
非常完整地完成错误目标
所以：
能力增强并不会自动解决目标对齐。
甚至：
这也是 Prompt Engineering 与软件工程真正连接起来的地方。
二十四、人什么时候应该盯着 Agent？
如果你一直盯着 Agent：
发现跑偏
↓
马上纠正
↓
补充知识
↓
继续工作
通常能够减少 Token 消耗。
但是问题在于：
人的注意力非常昂贵。
另一种模式是：
给 Agent 更多算力
↓
让它自己探索
↓
自己执行
↓
自己验证
↓
你去完成其他工作
↓
最后回来验收
这可能消耗更多 Compute。
但节省 Human Time。
因此存在一个重要 Trade-off：
未来一个非常重要的工作能力可能就是判断：
我的时间应该花在哪里？
如果一个问题：
我已经知道怎样解决
+
AI也可以解决
+
结果容易验证
那么就应该更大胆地交给 AI。
人的精力应该更多放到：
目标选择
问题定义
架构设计
复杂判断
开放问题
结果验收
这些更高价值的环节。
二十五、任务可以分成两类
第一类：存在明确 Verifier
例如：
测试是否通过？
程序输出是否正确？
所有约束是否满足？
格式是否符合要求？
这类问题的特点是：
但：
这种任务特别适合 AI。
因为 AI 可以不断：
尝试
↓
验证
↓
失败
↓
继续尝试
直到找到答案。
第二类：没有明确 Verifier
例如：
哪个架构最好？
哪个研究方向最值得做？
哪个产品最有前景？
哪个名字最好？
这类问题不存在：
pytest
↓
PASS
所以 AI 很容易给出：
一个还不错的答案。
却很难证明：
这是最好的答案。
这类开放问题，也是当前 Agent 最困难的问题之一。
二十六、Long-Horizon Task 的一个办法：把大搜索空间拆开
对于开放问题，不要简单地问：
给我最好的答案。
因为模型通常只是从概率分布中找到几个高概率答案。
这容易导致结果趋同。
更好的做法是：
巨大开放空间
↓
拆成多个小空间
↓
分别设置约束
↓
多个 Agent 并行搜索
↓
过滤
↓
比较
↓
进一步搜索
↓
逐渐收敛
也就是：
转化成：
然后通过更多计算搜索。
可以把这种思想理解为：
算力换智力。
不是让一个 Agent 一次想出“天才答案”。
而是：
扩大搜索
+
结构化搜索
+
多次比较
+
不断筛选
最终提高得到好答案的概率。
二十七、完整的 Context Engineering 方法论
整节课的方法可以整理成：
Human Intention
↓
明确真正目标
↓
缩小搜索空间
↓
提供必要 Context
↓
写清 Constraints
↓
建立 Verifier
↓
Agent 开始尝试
↓
验证结果
↓
失败则修改
↓
继续尝试
↓
成功
↓
分析过程中出现的问题
↓
总结经验
↓
蒸馏成 Skill
↓
下一次任务能力提升
所以现代意义上的 Prompt Engineering 已经不只是：
写一句更漂亮的话。
而是在：
设计一个环境，使智能模型能够更大概率沿着正确方向持续工作。
二十八、第一课和第二课实际上是一条完整逻辑
第一课的问题是：
AI越来越强
↓
Implementation成本快速下降
↓
为什么软件工程仍然重要？
答案在：
之间仍然存在巨大的 Gap。
第二课继续回答：
怎样缩小这些 Gap？
于是引出：
Context Engineering
↓
明确 Intention
↓
提供正确 Context
↓
建立 Specification
↓
设置 Constraints
↓
提供 Verifier
↓
让 Agent 执行
↓
监控
↓
迭代
所以第二课虽然名字叫：
Prompt Engineering
其实讨论的是：
怎样控制生成式软件系统。
二十九、这节课最重要的几个结论
如果只记核心，可以记下面这些：
1. Prompt 并不等于 User Message。
Agent 的行为由整个 Context 决定。
2. Prompt Engineering 正在转变成 Context Engineering。
真正重要的是组织上下文，而不是寻找“神奇咒语”。
3. Context 不是越多越好。
Context 本身会竞争 Attention。
应该追求的是：
而不是无限增加规则。
4. Verifier 极其重要。
永远不要只告诉 AI：
做什么。
还应该尽可能告诉它：
什么叫做对。
5. 模糊的 Intention 会迫使 AI 猜。
而 AI 越强，把错误猜测执行到底的能力也越强。
6. 高质量代码库本身就是 Prompt。
好的架构、代码、测试、文档和设计模式，会成为 AI 下一次工作的 Context。
7. 失败应该被积累。
把失败经验不断转化成：
Prompt
Workflow
Script
Skill
形成自己的能力飞轮。
8. 开放问题不要追求“一次生成最优答案”。
应该：
拆搜索空间
+
并行探索
+
建立局部 Verifier
+
过滤
+
比较
+
收敛
利用更多计算换取更高质量的决策。
三十、最终总结
Prompt Engineering 最初给人的感觉是：
怎样把一句话写得更好，让 AI 听话。
但随着 Agent 能力增强，它真正研究的问题已经变成：
也就是：
怎样把人的目标、知识、约束、审美和判断标准准确地传递给一个智能系统，并持续控制它朝正确方向运行。
未来真正重要的可能不再是：
我会不会写一个漂亮的 Prompt？
而是：
我是否知道真正的问题是什么？
↓
我是否知道 AI 需要什么上下文？
↓
我是否能减少它需要猜测的部分？
↓
我是否能建立可靠的验证机制？
↓
我是否知道什么时候应该让 AI 自己探索？
↓
我是否能够判断最终结果到底好不好？
从这个角度看：
Prompt Engineering 不是一门“说话技巧”。
它实际上越来越接近：
浙公网安备 33010602011771号