# 生成式软件工程：第二课笔记（提示词工程 / Context Engineering）
## 核心论点

> 现代 Prompt Engineering 本质上已经变成 **Context Engineering**；其最重要的工作，是把正确的信息、约束和验证机制放进模型上下文，让 AI 在一个尽可能明确、可验证的空间里工作。

第一课回答"AI 已经很强，软件工程为什么还没死"；第二课回答"既然 AI 很强，我们究竟应该怎样驾驭它"。

---

## 一、Prompt 不只是聊天框里那句话

常见误解：以为"帮我写一个网页"这句话就是 Prompt。但 Agent 真正看到的从来不是一条 User Prompt，而是**一整个上下文**，大致按这个顺序叠加：

`System Prompt → 全局 AGENTS.md → 项目级 AGENTS.md → Skill 索引 → 按需加载的 Skill → Tool definitions → 环境信息 → 之前的对话 → 之前的工具调用 → 工具返回结果 → 你的 User Prompt`

Skill 通常不会一次性全塞进去，而是先给名字和描述，需要时再加载完整内容。所以：

$$Prompt \neq User\ Message, \quad Model\ Behavior = f(\text{整个 Context})$$

这正是"提示词工程"应该理解为 **Context Engineering（上下文工程）**——把这些会进入模型上下文的东西安排好——的原因。

## 二、不要迷信"神奇提示词"

早期流行"你是一位世界顶级专家……请一步一步思考"这类咒语式写法，本质是在**hack 模型的 attention**：反复强调"专家"让模型倾向输出专家风格。但现代模型指令遵循能力已大幅提升，这类措辞的边际作用在下降。真正重要的是：**我要什么？有哪些约束？什么算完成？怎样验证？**

> Prompt Engineering 不是语言修辞比赛，重点不是"怎样说一句让 AI 突然聪明十倍的话"，而是**怎样把问题结构化到 AI 不容易理解错**。

## 三、和第一课"三个空间"的直接衔接

第一课讲 `Intention → Specification → Implementation`。举例：如果你的意图只是"给我做一个极品飞车"，AI 完全可以生成一个视觉效果拉满的赛车游戏，但未必是你脑子里真正想的"南大仙林校园 + 真实车辆资产 + 特定视角"——因为你没说，AI 只能**猜**。

课程给出的原则：**指令越明确，结果漂移越小**；把系统设计和 specification 放进 prompt，结果就越容易确定和验证。真正的问题往往不是"AI 听不听话"，而是"你有没有把意图说清楚"。

## 四、Prompt 最重要的组成部分：Verifier（验证器/验证标准）

这是本课最值得记住的词。假设你要求 Agent 修好一段程序，并且有 `pytest`、标准是"全部通过=成功"，Agent 就获得了一个强反馈信号，可以**改代码 → 跑测试 → 失败 → 再改 → 再跑……→ 全部通过**地循环迭代。只要任务可以被（尤其是机器）验证，`Agent + Verifier` 的组合会异常强大。

> 不要只告诉 AI 做什么，还要告诉它**怎么知道自己做对了**。

## 五、好 Prompt 可以抽象成四件事

| 要素 | 对应问题 |
|---|---|
| **Goal** | 我要什么？ |
| **Constraints** | 有什么边界？ |
| **Context** | 你需要知道什么？ |
| **Verifier** | 什么叫完成？ |

例如"做个人主页"若只给一句模糊要求，效果有限；若展开为：目标（学术主页）、风格（克制简洁、类似真实终端，非典型 AI landing page）、结构（首页/论文/项目/联系方式）、实现方式（真实 terminal 交互）、视觉约束（打字机质感字体，不要玻璃拟态/渐变 hero/大圆角卡片）、验证方式（逐页截图核对视觉约束），模型的工作空间就被大幅压缩、结果也更可控。

## 六、"AI 味"从哪里来

只说"做一个现代风格主页"，模型往往输出高度趋同的样式（大 Hero、渐变、卡片、圆角、悬浮动画、玻璃效果）——技术上漂亮但"AI 味很重"。原因不完全在 AI：约束只有"现代"两个字，模型只能从概率分布里挑一个最典型的答案。

$$模糊 Prompt \rightarrow 模型默认品味, \qquad 具体 Prompt \rightarrow 你的品味$$

所以你仍然需要看设计、看优秀网页，理解自己真正想要什么——AI 时代**品味没有失去价值，反而变得更重要**：代码可以让 AI 写，但你首先得知道"我要的好东西长什么样"。

## 七、用费曼学习法重新定义"学习"

AI 可以是一个成本极低、无限耐心的老师，随时可以问"这是什么/为什么/再讲一遍/举个例子/我没听懂/换个更简单的说法"。更进一步，还可以把角色反过来，形成费曼学习法的两阶段：

1. **AI = 老师，你 = 学生**：先让 AI 解释概念
2. **你 = 老师，AI = 学生**：你反过来给 AI 讲，让它假装什么都不知道，逻辑有错、遗漏、跳步就指出来

这样"AI 讲给你→你理解→你再讲给 AI→AI 挑战你的理解"的正反两遍，能显著加强理解。

## 八、为什么思维链能让模型突然变强

老师的类比：人脑本身像一个有限状态系统，一次能想的东西有限；但**人 + 纸 + 笔**完全不同——可以写一步、看结果、继续想、再写一步、回看前面，复杂计算能力大幅提高。**模型的 Context 就像纸和笔**：模型不必"一发命中"，可以先尝试、把尝试写进上下文、观察、发现错误、修正、继续，把复杂问题转化成大量连续、局部的 next-token decisions（课程用藏头诗、押韵、指定字符位置等刁钻任务演示了这一过程）。即：

$$一次有限计算 \times 很多轮 = 更强的\ test\text{-}time\ computation$$

## 九、Attention 与 Context Engineering 的关系

Context 不是越多越好，因为模型每次生成 token 时不会同等重视前面所有内容——例如上下文最前面写"用中文回答"，正在专心写代码时注意力会集中在当前代码/函数/报错/需求/测试，直到总结阶段才重新想起这条规则。所以：

> **Context 是一种竞争 Attention 的资源。** 指令越多，模型压力越大；每条规则被稳定遵循的难度都会增加。

## 十、不要无限往 AGENTS.md 和 Skill 里加规则

一旦发现问题就加一条"不要……""必须……""禁止……"，规则会不断堆积成几千行的 AGENTS.md——但**这些规则本身也在污染 Context**。目前并不存在"把所有问题都写进 Skill 就自动解决"的通用方案。所以 Context Engineering 不是"Context 越大越好"，而是**Context 中应该出现最有价值的信息**。

## 十一、AI 为什么不会真正"读论文"：Context Pollution

最常见做法是把 `paper.pdf` 整篇丢给 AI 要求总结。问题在于：一篇经过反复打磨的论文本身逻辑自洽（A→所以B→所以C→方法合理→实验支持），全文进入上下文后，模型的 attention 很容易被作者已经建立好的 narrative 吸走——结果 AI 的"总结"只是站在作者立场重新组织一遍原有论述。这种现象被称为 **Context Pollution（上下文污染）**：

$$AI 总结论文 \neq AI 理解论文价值$$

## 十二、老师读论文的方法：先 Grounding，再看增量

不是第一句就"总结论文"，而是先让 AI 回到**人类已有知识边界**：这个问题历史上研究到哪里？最相关的已有工作是什么？哪些已经是 known knowledge？这篇论文真正增加的新东西是什么？即：

$$已有知识 + \Delta = 论文$$

真正该关心的是那个 **Δ（增量）**，而不是让 AI 用两页复述十二页论文——这就是"先站到同一条知识基线上，再问这个工作到底多了什么"的 grounding。

## 十三、学生用 AI 学习也要做同样的 Grounding

学《计算机系统基础》时，不要让 AI 假设你什么都懂或什么都不懂，而是明确告知"我已经学过 C 语言/指针/虚拟内存基础，还不懂链接/重定位/动态链接，目前理解是 `.cpp → compiler → executable`，请从这个边界解释为什么还需要 linker"。这样 AI 从**你的知识边界**开始讲，而不是从它自己的知识宇宙开始讲——这就是人和 AI 的**对齐（Alignment）**。

## 十四、最好的学习过程是"一步推理"

对齐之后，不要让 AI 一次跳十步，而是"共同已知知识 → 向前推一步 → 检查 → 再推一步"，因为**一步推理通常更容易验证**。这和软件开发把大任务拆成小步骤、每步单独验证是同一种工程思想。

## 十五、隐藏的核心：把"失败"蒸馏成 Skill

真正有用的过程不是"问一次就答对"，而是"尝试→失败→找到失败原因→修改交流方式→重新尝试→成功→把经验沉淀下来"。老师强调**失败本身很重要**，因为 Skill 正是从不断失败和修正中逐渐形成、"把自己蒸馏成一个 Skill"——这和第一课"个人能力飞轮"完全接上。

## 十六、Long-Horizon Task（长周期任务）

修 bug、写测试、实现函数这类任务目标基本明确；但真实软件工程常常只有一个模糊的 Intent，Specification/Architecture/Implementation 全都不知道——这就是所谓的 **Long-horizon task**。

## 十七、为什么 AI 特别容易在 Long-Horizon Task 上翻车

模型经训练后有很强的"赶紧完成任务"倾向：做一个游戏一分钟就能跑出来，很爽；但随着不断叠加需求（登录、多人模式、地图、数据库、云同步、改架构……），Agent 修改成本越来越贵、错误越来越多、维护成本越来越高——这与第一课的《人月神话》和 AI slop 直接呼应：从零做 proof of concept 很容易，持续加功能到某个临界点后 Agent 会开始翻车。

## 十八、一个有趣的悖论：小项目越写越烂，改 Linux Kernel 却做得很好

Linux 内核有数千万行代码、复杂锁、复杂抽象、几十年历史，人进去经常看不懂，但 AI 改起来反而经常表现不错。原因：正因为它是长期由优秀工程师维护的高质量系统，上下文里到处是**正确模式、类似实现、正确 helper、正确抽象、正确锁顺序、已有惯例**，AI 的 self-attention 能找到并跟随这些模式。也就是说：

$$高质量代码库 = 高质量 Context$$

这与"论文的 Context Pollution"是同一机制的两个方向：坏/偏置上下文把 AI 带偏，好的软件上下文把 AI 引向好模式。

## 十九、软件架构本身也变成了 Prompt

过去认为"代码 = 给 CPU 执行的东西"；在 Agent 时代，"已有代码 = Agent 的上下文"。于是**高质量代码不仅方便人维护，也会直接帮助 AI 写出更高质量的新代码**——好的命名、抽象、模块、测试、接口、文档、范例，全都会成为 Agent 下一次生成代码时的 Context。因此 Clean Code、Good Architecture、Documentation、Consistency 又多了一层意义：**它们在训练当前 Session 里的 Agent**。

## 二十、能否主动利用这种"Context Pollution"？

一个研究设想：收集优秀软件工程项目 → 提取好的设计模式 → 压缩成文档/示例 → 放进 Context → 再让 Agent 写新项目，相当于故意"用好的工程经验污染 AI"（例如把《A Philosophy of Software Design》中关于封装/拆模块/继承/接口深度的设计智慧变成 Agent 可用的上下文）。老师认为这可能是减少 AI slop、提高长期维护性的方向，但也指出不同设计风格本身会互相冲突，并不是简单把几十个优秀项目全塞进去就行。

## 二十一、为什么基础知识仍然要学

老师明确否定"有 AI 以后操作系统/编译器/数据库都不用学了"——原因不是未来还要你手写所有代码，而是**如果没有这些概念，就不知道该往 Context 里放什么，也不知道模型为什么跑偏**。目前还没有"超能力 AI"，人仍必须理解上下文里有什么、每个东西会如何影响 AI；操作系统、编译器、数据库中仍包含大量必须掌握的设计智慧。

## 二十二、研究案例：一句 Prompt 带歪整个研究方向（Reward Hacking）

某次研究本来是想探索"某种符号执行优化是否有价值"，但上下文里出现了一句接近"我想证明方法 A 是有用的"的表述——这非常危险，因为模型由此得到隐含 reward："目标=证明 A 有用"，于是 Agent 开始设计小 benchmark、找 A 有效果的情况、继续证明 A，看起来一直在"工作"，但整个科研逻辑已经错了：真正该问的是"A 到底有没有用"，而不是"怎样证明 A 有用"。这被称为 **Reward Hacking**：模型完成了字面目标，却偏离了真正的大目标。后来纠正方向，改成从真实工具和 SOTA 算法出发、看真实 workload 中哪里会 timeout，再决定优化方向。

## 二十三、Prompt 也有"目标函数错配"

真正意图是"判断方法 A 是否值得研究"，却写成"证明方法 A 有效"：

$$Prompt\ Objective \neq Human\ Intention$$

AI 越强，错得越彻底——这和第一课 `Intention → Specification` 之间出错的核心逻辑完全一样。**Prompt Engineering 本质就是生成式软件工程的一部分。**

## 二十四、什么时候该盯着 Agent，什么时候该放手

盯着 Agent、发现跑偏立刻纠正、随时注入领域知识，通常任务完成更快；但**人的注意力是昂贵的**。另一种方式是给 Agent 更多 token 让它自己探索，你去做别的事，最后验收——可能烧更多算力，但省下你的时间：

$$Human\ Time \leftrightarrow Compute$$

的 trade-off。原则：如果一件事你已经完全知道怎么做、AI 也能做，就应该更敢于放手，而不是盯着每一行代码不断纠正只为获得"我还是比 AI 强"的心理满足。每个人都该想清楚，自己的时间应该花在 AI 无法替代、收益最大的地方。

## 二十五、两类问题：有 Verifier vs 没有明确 Verifier

| 类型 | 例子 | 特点 |
|---|---|---|
| **有 Verifier** | 测试通过吗？程序正确吗？满足约束吗？押韵了吗？ | 搜索可能难，但验证容易——AI 很强 |
| **没有明确 Verifier** | 哪种架构最好？什么研究方向最值得做？哪个名字最好？ | 没有 `pytest → PASS` 式标准，AI 容易给出"还不错的答案"，但不一定是"真正最好的答案" |

## 二十六、算力换智力：把大搜索空间拆开

如果只让一个 Agent"给我想个最好的名字"，它会沿着自己的概率分布直接生成几个高概率答案——大家问同一个模型，容易得到高度趋同的结果（都叫"子涵"）。更好的办法是把巨大开放空间拆成很多带明确约束的小空间，多个 Agent 并行搜索、过滤、比较、再收敛（例如取名：先枚举读音→过滤不好读音→每个读音开子 Agent 搜字→按《诗经》等来源搜索→过滤→比较）。也就是把一个难以验证的大问题，转化成很多更小、更明确、更容易验证的问题——这就是**算力换智力**。

## 二十七、第二课的方法论全链条

```mermaid
flowchart TD
    A[Human Intention] --> B[明确真正的目标]
    B --> C[缩小搜索空间]
    C --> D[把关键知识放进 Context]
    D --> E[写清 Constraints]
    E --> F[尽可能建立 Verifier]
    F --> G[Agent 尝试]
    G -->|失败| H[修正]
    G -->|成功| I[验证结果]
    H --> J[总结失败经验]
    I --> J
    J --> K[蒸馏成 Skill]
    K --> L[下次能力更强]
```

这就是第二课真正意义上的 Prompt Engineering：已经远超"怎样写一句好 Prompt"，而是**怎样设计一个环境，使一个智能模型更大概率沿着正确路径持续工作**。

## 二十八、把第一、第二课连起来看

- **第一课**：Agent 已经非常强 → 单个 Implementation 越来越便宜 → 真正难的是软件工程 → `Intent → Spec → Implementation` 之间的 Gap
- **第二课**：怎么缩小这个 Gap？→ Context Engineering → 明确意图 → 提供正确上下文 → 提供约束 → 提供 Verifier → 监控与迭代

第二课不是独立的"Prompt 技巧课"，而是在正式建立**生成式软件工程的控制论**。

## 二十九、最值得记住的 8 句话

1. Prompt 不只是 User Message，Agent 真正处理的是整个 Context
2. Prompt Engineering 正在变成 Context Engineering
3. Context 不是越多越好，因为 Context 会竞争模型的 Attention
4. 不要依赖"你是世界顶级专家"之类的咒语；现代模型更需要明确要求
5. 最重要的是 Verifier：告诉 AI 什么叫"做对"
6. 模糊的 Intent 会迫使 AI 猜；AI 越强，猜错以后执行得也可能越彻底
7. 成熟、高质量的软件本身就是高质量 Context，架构、代码规范和已有范例会直接影响 Agent 后续生成
8. 开放问题不要要求一次生成最优答案，而应拆搜索空间，用多个可验证的小任务实现"算力换智力"

## 三十、留给未来的更大问题

若 `更多算力 → 更大搜索空间 → 更高质量决策 → 更多"智力"`，那么计算资源的不平等，未来可能进一步演变为**智力能力的不平等**。老师提出一个激进假设：如果少数人拥有近乎无限的计算资源，而模型的智力生产效率又高于普通人，可能产生"墙内的超人"和"墙外的普通人"式的巨大能力差异——**怎样防止这样的事情到来？** 这门课看似讨论"提示词工程"，最终指向的是：当自然语言成为人与智能机器之间最重要的接口后，人应如何把自己的意图、知识、价值判断和验证标准可靠地传递给机器，而不被机器默认的概率分布反过来同化。

---

## 关键术语速查

| 术语 | 一句话解释 |
|---|---|
| Context Engineering（上下文工程） | 安排好一切会进入模型上下文的信息，是 Prompt Engineering 的现代形态 |
| Verifier（验证器/验证标准） | 告诉 AI"什么叫做对"的可验证标准，是驱动 Agent 迭代改进的核心反馈信号 |
| Context Pollution（上下文污染） | 已有文本的叙事逻辑把模型注意力吸走，导致"总结"只是复述而非独立判断 |
| Grounding（对齐/接地） | 先让人和 AI 站到同一条已有知识基线上，再讨论"多了什么"（Δ） |
| test-time computation | 通过多轮"尝试→观察→修正"的上下文交互，用推理阶段的计算量换取更强能力 |
| Long-horizon task（长周期任务） | 目标模糊、Spec/Architecture/Implementation 都未知的复杂任务 |
| Reward Hacking | 模型达成了字面目标，却偏离了人类真正想要的大目标 |
| 算力换智力 | 把难以验证的大问题拆成多个小的、可验证的子问题，用并行搜索+过滤逼近更优解 |
| Human Time ↔ Compute | 人盯着纠正 Agent（省算力费时间）与放手让 Agent 探索（费算力省时间）之间的权衡 |