CS146S 第一周笔记总结：Introduction to Coding LLMs and AI Development

Stanford University · Fall 2025 · 讲师：Mihail Eric 课程网站：themodernsoftware.dev

---

📅 课程安排

日期	主题	内容
Mon 9/22	Introduction and How LLMs are Made	课程介绍 + LLM 原理
Fri 9/26	Power Prompting for LLMs	Prompt Engineering 技术详解

---

第一讲：课程介绍 & LLM 是如何制造的（9/22）

1. 课程定位与核心理念

这不是一门 "Vibe Coding" 课程。 Vibe coding（YOLO 式地盲目接受 AI 生成的代码）不足以构建真正好的软件。距离 vibe coding 能够可靠地构建生产级软件，可能还需要 2-10+ 年。

这门课的目标是让有经验的工程师真正成为 10x 工程师。

行业现状（2025）：

• 坏消息：软件工程行业正在被大幅重塑，CS 专业入学人数下降了 20%
• 好消息：软件开发者的生产力有潜力达到历史最高水平。借助 AI 编程，工程师可以以前所未有的速度掌握新的技术栈和工具

核心观点：

"You won't be replaced by AI. You'll be replaced by a competent engineer who knows how to use AI." （你不会被 AI 取代，你会被一个懂得使用 AI 的工程师取代。）

• 如果你唯一的价值是知道如何从 StackOverflow 复制粘贴，那你会被 AI 取代
• 如果你能进行系统性思维、理解业务上下文、设计健壮的架构和抽象，AI 会极大地提升你的生产力

📚 延伸阅读： OpenAI Codex 文章（阅读 5）用大量实例验证了这一理念——OpenAI 工程师不是被 Codex 取代，而是通过 Codex 实现 "一天开会还能合并 4 个 PR" 的生产力飞跃。

2. 核心理念（The Takeaway）

Human-Agent Engineering（人-智能体协同工程）：

• 不是 vibe coding，而是学会管理 AI agent
• 聚焦于那些 AI 系统尚未取代的技能：业务理解、架构设计、成为 Tech Lead
• 如今的"坏代码"不仅是架构上的错误决策，还包括由 LLM 幻觉导致的功能性错误软件

LLMs 的能力取决于你自身的水平：

• 好的上下文（context）→ 好的代码
• 如果你自己都无法理解你的代码库，LLM 也无法理解

📚 延伸阅读： Anthropic 视频（阅读 4）中也强调了这一点——"talking to a model is a lot like talking to a person"。你的沟通能力直接决定了 LLM 的输出质量。OpenAI Codex 文章中维护 AGENTS.md 的实践也是同一逻辑：你对代码库理解越深，提供给 AI 的上下文越好，输出质量越高。

要大量阅读和审查代码：

• 学会辨别好代码和坏代码
• 培养"好品味"（good taste）

积极实验：

• 目前还没有成熟的软件模式，所有人都在摸索
• 工具会过时，找到适合你自己的工作流

3. LLM 工作原理（5 张幻灯片精华版）

基础概念

• LLM（大语言模型）是自回归模型，用于下一个 token 预测
• 处理流程：
  1. Tokenization（分词）：使用固定词表将输入文本分割为 token
  2. Embedding（嵌入）：将 token 转换为固定维度的数值向量（~1-3K 维）
  3. Transformer 层（12-96+ 层）：使用 Self-Attention 机制（Vaswani et al., 2017）学习词与词之间的语法和语义关系
  4. 输出：得到最可能的下一个 token 的概率分布

📚 延伸阅读： Karpathy 视频（阅读 1）用 3.5 小时详细讲解了完整流水线——从 FineWeb 数据集的 12 亿网页爬取、BPE 分词，到 GPT-2 vs LLaMA 3 的规模差异。课堂 5 张幻灯片是精华版，Karpathy 视频是完整版，建议结合观看。

训练流程（三阶段）

阶段	名称	方法	数据规模
Stage 1	自监督预训练	在大量公开数据上学习语言概念	千亿到万亿+ tokens
Stage 2	监督微调（SFT）	用高质量的 prompt-response 对教模型遵循指令	数万到数十万对
Stage 3	偏好调优（RLHF）	对齐模型输出与人类偏好（有用性、正确性、可读性）	数万到数十万对人类标注比较

训练数据来源举例： Common Crawl、Wikipedia、StackExchange、公开 GitHub 仓库等。英文维基百科约 30 亿 tokens，作为参考。

推理模型（Reasoning Models）：

• 使用 Chain-of-Thought 推理训练扩展
• 集成工具使用能力
• 通过强化学习学习如何评估推理过程、回溯等
• 通常模型名称带有 "-think"

📚 延伸阅读： Karpathy（阅读 1）用 AlphaGo "Move 37" 做类比——就像 AlphaGo 通过 RL 发现了超越人类棋手的策略，LLM 也能通过 RL 发展出新颖的推理技术。DeepSeek-R1 的 "aha moment" 就是这类涌现行为的实例。

模型规模参考： GPT-3/Claude 3.5 Sonnet: ~175B 参数；LLaMA 3.1: 405B；GPT-4: ~1.8T（传闻）

实际使用中的优势与局限

优势： 专家级代码补全、代码理解、代码修复

局限：

• 幻觉（Hallucinations）：生成不存在或过时的 API（可通过良好的上下文工程缓解）
• 上下文窗口限制：~100-200K tokens，但存在 primacy/recency bias 和 "lost-in-the-middle" 效应
• 延迟：每个请求数秒到数分钟（需要规划好任务委派，合理进行人类上下文切换）
• 成本：最佳模型输入约 $1-3/百万 tokens，输出 $10+/百万 tokens（但成本每年约下降 10 倍）

📚 延伸阅读： 关于幻觉，Karpathy（阅读 1）从训练层面解释了根本原因——标注者以自信语气回答导致模型也"自信地不知道"；课堂第二讲则从实用层面给出缓解手段（Tool Use、RAG、Self-Consistency）。两者形成完整的"原因→解决方案"链条。

---

第二讲：LLM 强力 Prompting 技术（9/26）

1. Prompting 背景

• Prompt 是与 LLM 沟通的通用语言，也是对 LLM 进行编程的方式
• 在编程语言的演化中，prompting 是下一个阶段
• Prompting 既是艺术也是科学：LLM 的黑箱本质意味着有效的 "LLM whispering" 需要一些技巧，但也存在经过实证验证的技术

📚 延伸阅读： Google Cloud（阅读 2）和 promptingguide.ai（阅读 3）分别从入门和进阶角度系统化了 prompting 技术。Anthropic 视频（阅读 4）则强调了实践层面的哲学——prompt engineering 本质是"与模型沟通"。这三份材料构成了课堂技术讲解的理论背景。

2. 七大核心 Prompting 技术

① Zero-Shot Prompting（零样本提示）

• 直接要求 LLM 完成任务，不给示例、不给支持
• 适合 LLM 已经熟悉的常见任务

💡 实战示例：

# 基础 zero-shot
Write a Python function that validates email addresses using regex.

# 更好的 zero-shot（加入明确约束）
Write a Python function called `validate_email` that:
- Takes a single string parameter
- Returns True if the string is a valid email, False otherwise
- Uses the `re` module
- Handles edge cases like missing @ or domain

📚 阅读关联： Google Cloud（阅读 2）指出 zero-shot 最适合直接、明确的任务。Anthropic 工程师（阅读 4）补充说，即使是 zero-shot，也要像"对一个没有上下文的人说话"一样清晰。

② K-Shot Prompting（少样本提示 / In-Context Learning）

• 给 LLM 提供一些如何完成任务的示例
• 常用 k = 1, 3, 5
• 适用场景： 特定领域的 API、LLM 较少见过的语言、需要特定代码风格/命名规范
• 避免： 通用编码任务、过度约束 LLM

💡 实战示例：

# 场景：让 LLM 遵循团队的 API 响应格式

Convert these API endpoints to match our standard response format.

<example>
Input: GET /users → returns { data: [...] }
Output: GET /users → returns { status: "ok", payload: { users: [...] }, metadata: { count: N } }
</example>

<example>
Input: GET /orders → returns { orders: [...] }
Output: GET /orders → returns { status: "ok", payload: { orders: [...] }, metadata: { count: N } }
</example>

Now convert: POST /products → returns { id: "123", name: "Widget" }

# 场景：特定命名规范的代码生成（课堂原始示例）

Write a for-loop iterating over a list of strings using the naming convention in our repo.
Here are some examples of how we typically format variable names.
<example>var StRaRrAy = ['cat', 'dog', 'wombat']</example>
<example>def func CaPiTaLiZeStR = () => {}</example>

📚 阅读关联： Google Cloud（阅读 2）的 Few-Shot 策略强调"展示期望的风格、语调和详细程度"。OpenAI Codex 文章（阅读 5）中的最佳实践 "Implement this the same way as [module X]" 本质上就是 K-Shot——用已有代码作为示例引导生成。

③ Chain-of-Thought (CoT) Prompting（思维链提示）

• 展示或要求推理步骤
• Multi-Shot CoT： 提供带推理过程的示例
• Zero-Shot CoT： 简单加一句 "Let's think step-by-step"
• 也可要求在 <reasoning> 标签中显式推理
• 适用场景： 需要多步逻辑的编程和数学任务
• 这是很多推理模型的核心技术

💡 实战示例：

# Zero-Shot CoT
This function is supposed to find the longest palindromic substring,
but it returns wrong results for "cbbd". Debug it step by step.

def longestPalindrome(s):
    # ... buggy code ...

Think through the logic step by step:
1. What should the expected output be?
2. Trace through the code with input "cbbd"
3. Where does the logic break?
4. Provide the fix.

# Multi-Shot CoT（提供带推理的示例）
Given a SQL query, analyze its time complexity.

<example>
Query: SELECT * FROM users WHERE id = 5
Reasoning: This is a point lookup on the primary key. With a B-tree index,
this is O(log n). Without index, it's O(n) full table scan.
Complexity: O(log n) with index, O(n) without
</example>

Now analyze: SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE u.country = 'US'

# 使用 XML 标签强制推理（课堂推荐格式）
Review this React component for potential performance issues.
Before giving your answer, show your reasoning in <reasoning> tags.

<reasoning>
[Model will think through the component's render behavior, 
state management, and potential re-render triggers here]
</reasoning>

Then provide your recommendations.

📚 阅读关联： Karpathy（阅读 1）从理论层面解释了 CoT 为何有效——LLM 的推理分布在多个 token 上，每个 token 的计算预算是固定的，因此"让模型多说话"相当于给它更多计算预算。Anthropic（阅读 4）从实践角度补充：要求模型先解释再回答可以显著提高准确率。promptingguide.ai（阅读 3）进一步扩展了 CoT 到 Tree of Thoughts——并行探索多条推理路径。

④ Self-Consistency Prompting（自一致性提示）

• 多次采样输出（通常结合 CoT），取最常见的结果
• 通过对多样化推理路径的模型集成，减少幻觉和错误答案
• 实质是一种**模型集成（ensembling）**方法

💡 实战示例：

# 概念：对同一问题多次采样，取多数答案
# 在实践中，可以手动多次提交相同 prompt 并比较结果

# 也可以在 prompt 中要求模型自行尝试多种方法：
Solve this concurrency bug using three different approaches.
For each approach:
1. Explain the reasoning
2. Provide the fix
3. Note potential tradeoffs

Then recommend which approach is most robust and why.

📚 阅读关联： OpenAI Codex 文章（阅读 5）的 "Best-of-N" 实践就是 Self-Consistency 的工业级应用——同时生成多个响应，选最好的一个或组合多个优点。promptingguide.ai（阅读 3）将其定义为"通过多样化推理路径的多数投票来减少错误"。

⑤ Tool Use（工具使用）

• 允许 LLM 调用外部系统
• 减少幻觉、增强 LLM 自主能力最重要的技术之一

💡 实战示例：

# 课堂原始示例（提供测试工具）
Fix the IndexError in src/parser.py. Ensure the CI tests still pass.
Here are the available tools:
<tools>
pytest -s tests/unit/test_parser.py
pytest -v tests/integration/
python -m mypy src/parser.py
</tools>

# 更复杂的场景（多工具协作）
Investigate why the /api/orders endpoint returns 500 errors intermittently.
<tools>
curl -X GET http://localhost:8080/api/orders     # 测试 endpoint
docker logs app-server --tail 100                 # 查看服务器日志
psql -c "SELECT count(*) FROM orders WHERE created_at > now() - interval '1 hour'"  # 检查数据库
</tools>
Use these tools to diagnose the issue, then propose a fix.

📚 阅读关联： Karpathy（阅读 1）从训练层面解释了 Tool Use 的原理——模型学会在输出中生成特殊 token 来触发工具调用。promptingguide.ai（阅读 3）的 ReAct 框架（Thought → Action → Observation）就是 Tool Use 的结构化实现。OpenAI Codex（阅读 5）的"迭代改进开发环境"实践——设置启动脚本、环境变量——本质上是在为 AI agent 提供更好的工具集。

⑥ Retrieval Augmented Generation (RAG)（检索增强生成）

• 为 LLM 注入上下文数据
• 保持 LLM 信息更新（无需重训练），迭代更快
• 免费获得可解释性和引用
• 减少幻觉
• 在 Cursor/Windsurf 等工具中使用 @context 就是在利用 RAG

💡 实战示例：

# 在 Cursor/Windsurf 中使用 RAG（@context 引用）
@src/auth/middleware.ts @src/auth/types.ts
Add rate limiting to our authentication middleware.
Follow the existing error handling patterns in the codebase.

# 手动模拟 RAG（在 prompt 中嵌入检索到的上下文）
Here is our current database schema:
<context>
CREATE TABLE users (id SERIAL PRIMARY KEY, email VARCHAR UNIQUE, role VARCHAR);
CREATE TABLE orders (id SERIAL PRIMARY KEY, user_id INT REFERENCES users(id), total DECIMAL);
CREATE INDEX idx_orders_user ON orders(user_id);
</context>

Write a query to find users who placed more than 5 orders last month,
optimized for our existing indexes.

📚 阅读关联： 这是所有阅读材料的交叉重点。Karpathy（阅读 1）解释了为什么 RAG 必要——模型的知识在预训练时就固定了，RAG 让模型能获取训练后的新信息。promptingguide.ai（阅读 3）将 RAG 的优势总结为：时效性、可解释性、减少幻觉。OpenAI Codex（阅读 5）的 AGENTS.md 本质上是 RAG 的一种形式——为 AI 提供无法从代码直接推断的业务知识。

⑦ Reflexion（反思）

• 让 LLM 反思自己的输出
• 环境信号的反馈被重新融入上下文
• 多轮 prompting： 第一轮给出初步答案 → 第二轮要求反思和修正
• 这是自主编码 agent 的核心机制，也叫 "self-critique"
• 现代编码 IDE 中实现完全 agentic 行为的关键

💡 实战示例：

# 第一轮：生成初始代码
Write a function to merge two sorted linked lists.

# 第二轮：要求反思（课堂推荐的 Reflexion 模式）
Now critique your solution:
- Does it handle edge cases (empty lists, single element)?
- What is the time and space complexity?
- Is there a more elegant approach?
If you find issues, provide an improved version.

# 在 system prompt 中内置反思机制
<system>
After providing any code solution, always:
1. List potential edge cases you might have missed
2. Rate your confidence (1-10) in the solution's correctness
3. If confidence < 8, revise your solution
</system>

# 多轮对话中的 Reflexion 实战
User: Write a Redis caching layer for our user service.
Assistant: [generates initial implementation]
User: The tests are failing with this error:
      <error>ConnectionResetError: Redis connection pool exhausted</error>
      Reflect on what went wrong and fix it.
Assistant: [analyzes error, identifies missing connection pool config, provides fix]

📚 阅读关联： Anthropic（阅读 4）的"当模型犯错时，问它为什么错了"就是 Reflexion 的手动版本。promptingguide.ai（阅读 3）将 Reflexion 形式化为 Observe → Reflect → Extend Prompt 循环。OpenAI Codex（阅读 5）的 "Ask Mode → Code Mode" 两步流程也体现了 Reflexion 思想——先让 AI 思考计划，再执行代码。

3. 重要术语

术语	定义
System Prompt	提供给 LLM 的第一条消息（通常用户不可见），定义角色、规则、输出风格
User Prompt	用户的实际请求或指令
Assistant	LLM 实际生成的回复

💡 System Prompt 实战示例：

<system>
You are a senior backend engineer specializing in Python and PostgreSQL.
When writing code:
- Always include type hints
- Follow PEP 8 strictly
- Prefer SQLAlchemy ORM over raw SQL
- Include docstrings for all public functions

When reviewing code:
- Focus on security vulnerabilities first
- Then performance, then readability
- Always explain WHY something is an issue, not just WHAT

If you are unsure about something, say "I'm not certain" rather than guessing.
Output format: Use <code> tags for code blocks and <explanation> for reasoning.
</system>

📚 阅读关联： Anthropic（阅读 4）强调 system prompt 中应"积极使用 Role Prompting"，且要像代码一样进行版本控制。OpenAI Codex（阅读 5）的 AGENTS.md 本质上就是一个持久化的 system prompt——提供命名规范、业务逻辑等 AI 需要的背景信息。

4. Best Practices（最佳实践）

1. 使用 prompt improvement 工具（如 Anthropic 的 prompt improver）
2. 清晰提示：把 prompt 给一个没有上下文的人看——如果他们困惑，LLM 也会困惑
3. 积极使用 Role Prompting：通过 system prompt 赋予角色，使输出更强大
4. 结构化格式：使用 XML 标签（如 <log>, <e> 等）组织 prompt 结构
5. 明确指定你想要什么：语言、技术栈、库、约束条件
6. 任务分解（Decompose Tasks）：把大任务拆分成小步骤（后续课程会深入讨论）

💡 Best Practices 综合示例——好的 Prompt vs 坏的 Prompt：

# ❌ 模糊、缺乏上下文的 prompt
Fix my code, it's not working.

# ✅ 清晰、结构化、有上下文的 prompt
<context>
Language: TypeScript
Framework: Express.js + Prisma ORM
Issue: The `createOrder` endpoint returns 400 for valid requests
</context>

<code>
// src/routes/orders.ts
async function createOrder(req: Request, res: Response) {
  const { userId, items } = req.body;
  // ... code here ...
}
</code>

<error>
POST /api/orders with body {"userId": 1, "items": [{"id": 5, "qty": 2}]}
Response: 400 Bad Request - "Invalid items format"
</error>

<task>
1. Identify why valid requests are being rejected
2. Fix the validation logic
3. Add a test case that covers this scenario
</task>

📚 延伸阅读： Anthropic（阅读 4）的六条实践建议，以及 Google Cloud（阅读 2）的六大优化策略，都是对这些 best practices 的更详细展开。OpenAI Codex（阅读 5）的"像写 GitHub Issue 一样写 Prompt"是这些原则在工业环境中的最佳实践体现。

---

📚 第一周推荐阅读

#	材料	与课堂的关系
1	Deep Dive into LLMs (Karpathy)	第一讲 LLM 原理的完整版，详细覆盖训练流水线和 LLM "心理学"
2	Prompt Engineering Overview (Google Cloud)	第二讲 prompting 技术的入门补充，六大优化策略对应课堂 best practices
3	Prompt Engineering Guide	第二讲技术的进阶扩展，覆盖课堂未详述的 ReAct、ToT、Prompt Chaining
4	AI Prompt Engineering: A Deep Dive (Anthropic)	第二讲 best practices 的工程师视角，强调实战中的迭代和沟通
5	How OpenAI Uses Codex	课程核心理念 Human-Agent Engineering 的真实案例集，展示 AI 辅助工程的实际工作流

🛠️ 第一周作业：LLM Prompting Playground

• 仓库：github.com/mihail911/modern-software-dev-assignments/tree/master/week1
• 使用 Ollama 本地运行模型（mistral-nemo:12b, llama3.1:8b）
• 实践多种 prompting 技术
• 设计并迭代 prompt 直到测试通过
• 重在实验和探索，而非"标准答案"

CS146S 第一周阅读材料笔记总结

Stanford University · Fall 2025 · 讲师：Mihail Eric

---

阅读材料一览

#	材料	类型	核心主题	对应课堂内容
1	Deep Dive into LLMs (Andrej Karpathy)	视频 3.5h	LLM 完整训练流水线	第一讲 LLM 原理的完整展开
2	Prompt Engineering Overview (Google Cloud)	文章	Prompt Engineering 概念与策略	第二讲技术的入门补充
3	Prompt Engineering Guide (promptingguide.ai)	指南	高级 Prompting 技术大全	第二讲技术的进阶扩展
4	AI Prompt Engineering: A Deep Dive (Anthropic)	视频 1.5h	Anthropic 工程师的实战经验	第二讲 best practices 的工程师视角
5	How OpenAI Uses Codex	PDF	OpenAI 内部如何使用 Codex	课程核心理念的真实案例集

---

📖 阅读 1：Deep Dive into LLMs like ChatGPT

作者： Andrej Karpathy（前 OpenAI 联合创始人、前 Tesla AI 总监）

🔗 课堂关联： 这篇阅读是第一讲 "LLM 工作原理（5 张幻灯片）" 的完整版本。课堂用 5 张幻灯片概括了三阶段训练，Karpathy 用 3.5 小时详细讲解每个阶段的技术细节和背后的直觉。

第一阶段：预训练（Pre-training）

数据收集与清洗： LLM 从互联网上爬取海量文本数据构建数据集（如 FineWeb，包含超过 12 亿网页）。原始数据充满噪音，需要严格的清洗流程：

• URL 过滤： 去除垃圾、恶意软件和低质量网站
• 语言过滤： 按目标语言筛选（如只保留英文）
• 去重（Deduplication）： 去除互联网上的大量重复内容
• PII 移除： 检测并删除个人身份信息
• 最终数据集如 FineWeb 大约 44TB，经过了激进的过滤

Tokenization（分词）： 文本通过 Byte Pair Encoding (BPE) 等技术转换为 token 序列。现代 LLM（如 GPT-4）使用约 100,000 个 token 的词表。

🔗 课堂关联： 课堂提到 tokenization 使用"固定词表"，Karpathy 这里补充了具体机制——BPE 通过迭代合并最频繁的字节对来构建词表。这也解释了课堂提到的 LLM 局限之一"拼写困难"——因为 token ≠ 字符，模型对字符级操作天然不擅长。

Transformer 神经网络：

• GPT-2（2019）：16 亿参数，1000 亿 tokens 训练，上下文长度 1024 tokens
• LLaMA 3（2024）：4050 亿参数，15 万亿 tokens 训练
• 模型的预测是随机的（stochastic），这既赋予了创造性，也导致了幻觉

训练成本趋势： GPT-2 原始训练成本约 $40,000。Karpathy 用 llm.c 复现 GPT-2 只花了 $672，随着优化可能降到约 $100。

🔗 课堂关联： 课堂提到 LLM 成本每年下降约 10 倍。Karpathy 的 GPT-2 复现数据（$40K → $672 → ~$100）用具体数字印证了这一趋势。

第二阶段：监督微调（Supervised Fine-Tuning / SFT）

• 将基础模型（base model）转变为助手（assistant）
• 预训练可能需要 3 个月，而后训练可能只需 3 小时
• 使用结构化对话数据集（较小规模）
• 近年来越来越多地使用 LLM + 人类编辑器来生成对话数据集
• 如果查询存在于后训练数据集中，助手会模拟人类标注者的行为；如果不存在，响应具有"涌现性"

LLM 的"心理学"：

• 幻觉（Hallucinations）： 训练时标注者以自信的语气回答问题，即使模型"不知道"也会自信作答。解决方案：添加"我不知道"的训练样本
• 工具使用： LLM 学会调用外部工具（搜索、代码解释器）来增强能力
• 知识/工作记忆： 模型的推理分布在输出序列的多个 token 上；每个 token 的计算预算是固定的，复杂任务需分解
• 参差不齐的智能（Jagged Intelligence）： LLM 性能不均匀，可能在简单任务上出现莫名错误
• 拼写困难： Tokenization 导致字符级任务（拼写、计数字母）容易出错

🔗 课堂关联（重要！）： Karpathy 的"心理学"分析直接解释了课堂多个概念的底层原理：

• 幻觉：课堂说"幻觉可通过上下文工程缓解"——Karpathy 解释了为什么：幻觉源于训练数据中标注者的自信语气
• 工具使用：课堂第二讲的 Tool Use 技术——Karpathy 从训练层面解释了模型如何学会调用工具
• 每个 token 计算预算固定：这就是课堂第二讲 CoT 有效的根本原因——让模型多生成 token = 给它更多计算资源
• Jagged Intelligence：这解释了课堂强调的"积极实验"和"培养好品味"——因为 LLM 表现不一致，人类必须能审查输出

第三阶段：强化学习（Reinforcement Learning）

• RLHF： 人类评估者对多个输出进行排名，训练奖励模型来模拟人类判断。需要谨慎管理以防模型利用奖励系统
• 与 AlphaGo 的类比： 就像 AlphaGo 发现了超越人类策略的"Move 37"，LLM 可以通过 RL 发展出新的推理技术
• DeepSeek-R1 的重要性： 其论文公开讨论了 LLM 的 RL 和 FT 过程，展示了模型的"aha moment"——这不是通过数据集训练能显式教会的，而是模型通过 RL 自己发现的
• 优点：推理能力增强；缺点：消耗更多 tokens

🔗 课堂关联： 课堂提到的"推理模型（Reasoning Models）"正是经过 RL 阶段训练的产物。模型名称带 "-think" 的就是这类模型——它们在推理时会消耗更多 token，但准确率更高。

核心要点

LLM 是文本的统计模拟器，不是有意识的生命体。它们是强大的工具，但需要人类监督。用户应始终验证 LLM 生成的信息。

---

📖 阅读 2：Prompt Engineering Overview (Google Cloud)

🔗 课堂关联： 这篇阅读是第二讲 prompting 技术的入门级补充。课堂讲了 7 种核心技术，Google Cloud 从更基础的角度讲解了 prompt 设计的通用原则。特别是它的"六大优化策略"与课堂的 "Best Practices" 高度对应。

什么是 Prompt Engineering？

Prompt Engineering 是设计和优化 prompt 的艺术与科学，用于引导 AI 模型生成期望的响应。就像为 AI 提供路线图，引导它朝特定输出方向前进。

Prompt 的关键要素

• Prompt 格式： 不同模型对不同格式（自然语言问题、直接命令、结构化输入）有不同偏好
• 上下文和示例： 在 prompt 中提供背景和相关示例帮助 AI 理解任务
• 微调与适应： 根据反馈持续调整 prompt
• 多轮对话： 支持连续且上下文感知的交互

Prompt 类型

类型	说明	课堂对应
Zero-Shot	不提供额外上下文或示例的直接指令	第二讲技术 ①
One/Few/Multi-Shot	提供一个或多个输入-输出示例对	第二讲技术 ②
Chain of Thought	鼓励模型将复杂推理分解为中间步骤	第二讲技术 ③
Zero-Shot CoT	结合 CoT 与 Zero-Shot（"Let's think step-by-step"）	第二讲技术 ③

六大 Prompt 优化策略

1. 设定清晰目标 → 对应课堂 Best Practice #5 "明确指定你想要什么"

• 使用动作动词指定期望行为
• 定义输出的长度和格式
• 指定目标受众

💡 示例对比：

# ❌ 模糊目标
Help me with this database.

# ✅ 清晰目标（遵循 Google Cloud 的建议）
Write a PostgreSQL migration script that:
- Adds a `status` enum column to the `orders` table with values ('pending', 'shipped', 'delivered')
- Sets default to 'pending' for existing rows
- Creates an index on the new column
- Output as a reversible migration (include both UP and DOWN)

2. 提供上下文和背景信息 → 对应课堂核心理念 "好的上下文 → 好的代码"

• 包含相关事实和数据
• 引用特定来源或文档
• 定义关键术语

💡 示例：

# 通过提供上下文减少幻觉
Our API uses JWT tokens with RS256 signing. The tokens include custom claims:
- `org_id`: the user's organization
- `permissions`: array of permission strings like "read:orders", "write:users"

<context>
Current auth middleware in src/middleware/auth.ts uses the `jsonwebtoken` library v9.0.
We DO NOT use passport.js or any other auth framework.
</context>

Add organization-level permission checking to the `/api/reports` endpoint.

3. 使用 Few-Shot Prompting → 对应第二讲技术 ② K-Shot

• 提供期望的输入-输出示例
• 展示期望的风格或语调
• 展示期望的详细程度

4. 具体明确 → 对应课堂 Best Practice #4 "结构化格式" + #5

• 使用精确语言，避免歧义
• 尽可能量化请求
• 将复杂任务分解为小步骤

5. 迭代实验 → 对应课堂核心理念 "积极实验"

• 尝试不同措辞和关键词
• 调整详细程度和具体性
• 测试不同的 prompt 长度

6. 利用 Chain of Thought → 对应第二讲技术 ③

• 鼓励逐步推理
• 要求模型解释推理过程
• 引导模型通过逻辑序列思考

Prompt 应用场景

涵盖四大类：语言和文本生成（创意写作、总结、翻译、对话）、问答（开放式、特定、多选、假设性、观点性）、代码生成（补全、翻译、优化、调试）、图像生成（写实、艺术、抽象、编辑）。

---

📖 阅读 3：Prompt Engineering Guide (promptingguide.ai)

🔗 课堂关联： 这篇阅读是第二讲的进阶扩展。课堂讲了 7 种核心技术，promptingguide.ai 在此基础上增加了多种高级技术——特别是 ReAct、Tree of Thoughts、Prompt Chaining——这些在后续课程中讨论自主 agent 时非常重要。

基础技术（课堂已覆盖）

技术	核心思想	课堂对应
Zero-Shot	直接指令，不给示例	技术 ①
Few-Shot	提供 1-5 个输入-输出示例对	技术 ②
Chain-of-Thought (CoT)	展示/要求中间推理步骤	技术 ③
Self-Consistency	多次采样 + 多数投票	技术 ④

进阶技术（课堂未详述，本指南的独特价值）

技术	核心思想	与课堂的联系
Meta Prompting	用提示来生成更好的提示	课堂 Best Practice #1 提到的 "prompt improvement 工具"
Prompt Chaining	将复杂任务分解为一系列子 prompt	课堂 Best Practice #6 "任务分解" 的具体实现方式
Tree of Thoughts (ToT)	探索多个推理路径的树状结构	CoT 的升级版——不是单条链，而是多条路径并行探索
RAG	检索增强生成，为模型注入外部知识	课堂技术 ⑥，本指南提供了更系统的理论框架
ReAct	结合推理和行动的交替循环	Tool Use（技术 ⑤）+ CoT（技术 ③）的结构化融合
Reflexion	让模型反思自身输出并改进	课堂技术 ⑦，本指南将其形式化为 Observe → Reflect → Extend 循环
Automatic Prompt Engineer (APE)	自动化生成和优化 prompt	Meta Prompting 的自动化版本

关键概念深入

Prompt Chaining（提示链）： 将一个大任务拆分成多个子任务，前一步的输出作为后一步的输入。这提高了透明度、可控性和可靠性。

💡 Prompt Chaining 实战示例：

# 步骤 1：分析需求
Analyze this feature request and list the required database changes,
API endpoints, and frontend components:
"Users should be able to export their order history as CSV"

# 步骤 2：基于步骤 1 的输出生成数据库迁移
Based on the analysis above, write the database migration for [列出的数据库变更].

# 步骤 3：基于步骤 1 的输出生成 API
Now implement the API endpoint for [列出的 API 端点].

# 步骤 4：基于步骤 1 的输出生成前端
Finally, create the React component for [列出的前端组件].

🔗 课堂关联： 课堂 Best Practice #6 说"把大任务拆分成小步骤"，Prompt Chaining 就是这一原则的具体实现模式。后续课程讨论 agentic coding 时会大量使用这个概念。

ReAct 框架： 在 Thought → Action → Observation 循环中交替进行。模型先思考下一步该做什么，然后执行动作（如搜索），观察结果，再决定下一步。

💡 ReAct 实战示例：

# ReAct 本质是 Tool Use + CoT 的结合
Debug why the user registration endpoint is returning 500 errors.

Thought: I should first check the server logs to understand the error.
Action: docker logs app --tail 50 | grep "registration"
Observation: [NullPointerException at UserService.java:42]

Thought: The error is at line 42 of UserService. Let me check that code.
Action: cat src/main/java/com/app/UserService.java
Observation: [line 42: user.getProfile().getName()]

Thought: getProfile() might return null for new users without a profile.
Action: Add null check before accessing profile.

🔗 课堂关联： ReAct = 课堂技术 ⑤（Tool Use）+ 技术 ③（CoT）的结构化版本。这正是现代 agentic IDE（如 Cursor Agent Mode）的内部工作方式——模型循环执行 "思考 → 调用工具 → 观察结果 → 思考下一步"。

RAG 的核心优势：

• 保持信息时效性（无需重训练）
• 提供引用来源（可解释性）
• 显著减少幻觉
• 适用于知识密集型任务

---

📖 阅读 4：AI Prompt Engineering: A Deep Dive (Anthropic)

来源： Anthropic 官方视频，由四位 Anthropic 工程师参与讨论——Amanda Askell（微调/对齐）、David Hershey（应用 AI）、Alex Albert（Prompt Engineering）、Zack Witten（Prompt Engineering）

🔗 课堂关联： 这篇阅读是第二讲 "Best Practices" 的工程师实战视角。课堂给了 6 条简洁的最佳实践，Anthropic 工程师从日常工作经验出发，解释了为什么这些实践重要、以及实际操作中的细节和坑。

什么是 Prompt Engineering？

• Prompt Engineering 本质上是与模型沟通——类似与人交流
• 要理解模型的"心理"，用清晰的语言表达需求
• Prompt 就像"代码"一样，是编程模型的方式
• 需要像对待代码一样对待 prompt：版本控制、持续测试

优秀 Prompt 工程师的特质

特质	说明	课堂对应
清晰沟通能力	清楚地表达、理解任务、描述概念	Best Practice #2 "清晰提示"
迭代思维	真正的 prompt 工程师发送数十甚至数百次调整	核心理念 "积极实验"
系统思维	考虑数据来源、延迟权衡、整体集成	核心理念 "Human-Agent Engineering"
仔细阅读输出	分析响应过程，验证推理是否合理	核心理念 "培养好品味"

关键实践建议

1. 当模型犯错时，问它为什么错了

🔗 课堂关联： 这本质是课堂技术 ⑦（Reflexion）的手动应用——让模型反思错误并修正。

💡 示例：

# 模型生成了一个有 bug 的排序函数后
Your merge sort implementation fails on this input: [3, 1, 4, 1, 5].
The output is [1, 1, 3, 5] instead of [1, 1, 3, 4, 5].

1. Analyze why the 4 was dropped
2. Explain what instruction I should have given you to avoid this error
3. Provide the corrected implementation

2. 处理歧义情况：为模型提供明确的 fallback 指令

💡 示例：

Classify the following code changes into categories:
- "bugfix", "feature", "refactor", "docs", "test"

If the change doesn't clearly fit any category,
output <uncertain>category1 or category2</uncertain>
rather than guessing.

<change>
-  const timeout = 5000;
+  const timeout = parseInt(process.env.TIMEOUT) || 5000;
</change>

3. 使用 Chain of Thought：要求模型先解释再回答

🔗 课堂关联： 直接对应课堂技术 ③。Karpathy（阅读 1）解释了底层原理——更多推理 token = 更多计算资源。

4. 让模型"采访"你：当你不确定自己想要什么时

💡 示例：

I need to add caching to our application but I'm not sure about the best approach.

Before proposing a solution, ask me 5 questions about:
- Our current architecture and traffic patterns
- Performance requirements and SLAs
- Data freshness requirements
- Infrastructure constraints
Then use my answers to recommend a caching strategy.

🔗 课堂关联： 这与课堂核心理念 "LLMs 的能力取决于你自身的水平" 形成有趣互补——如果你自己不清楚需求，可以让 LLM 帮你梳理。这也体现了 Human-Agent 协作的双向性。

5. 大量阅读他人的 prompt 和输出

🔗 课堂关联： 与课堂"要大量阅读和审查代码"一脉相承——培养好品味，不仅是审查代码，还要审查 prompt。

6. 集成是关键：不是"写一个 prompt 就完了"

🔗 课堂关联： 对应 OpenAI Codex（阅读 5）中强调的"迭代改进开发环境"——Prompt 只是系统的一部分，还需要考虑工具集成、环境配置、上下文管理。

核心观点

"Clear communicating is the most important thing... talking to a model is a lot like talking to a person." （清晰沟通是最重要的...与模型对话很像与人对话。）

---

📖 阅读 5：How OpenAI Uses Codex

来源： OpenAI 官方 PDF，基于对 OpenAI 工程师的访谈和内部使用数据编写。

🔗 课堂关联： 这是整个第一周最重要的实践材料。它用真实案例展示了课程核心理念 Human-Agent Engineering 在工业环境中的运作方式。课堂说"不是 vibe coding，而是管理 AI agent"——这篇文章展示了 OpenAI 工程师具体是怎么"管理" Codex 的。

Codex 在 OpenAI 的七大使用场景

1. 代码理解（Code Understanding）

• 在不熟悉的代码库中快速上手
• 定位功能核心逻辑，映射服务/模块关系，追踪数据流
• 事故响应时快速定位组件交互和故障传播路径

💡 实战 Prompt 示例：

# 代码探索
Where is the authentication logic implemented in this repo?
Trace the request flow from the /login endpoint through middleware,
service layer, and database calls.

# 事故响应
Our payment processing is failing intermittently.
Map all the services that interact with the PaymentService module
and identify potential points of failure in the data flow.

🔗 课堂关联： 这直接体现了课堂"LLMs 的能力取决于你自身的水平"——工程师需要知道"问什么问题"才能让 Codex 高效探索代码库。同时，这也是 RAG（课堂技术 ⑥）的实际应用——Codex 检索代码库内容作为上下文。

2. 重构和迁移（Refactoring and Migrations）

• 跨多文件/包的一致性修改
• 更新 API、迁移依赖项、用新模式替换旧模式

💡 实战 Prompt 示例：

# 结构化的迁移指令（像 GitHub Issue 一样写 prompt）
Migrate all usages of the deprecated `getUserById()` to the new UserService pattern.

Files affected: src/controllers/*.ts, src/services/*.ts
Current pattern: const user = await getUserById(id)
New pattern: const user = await userService.findOne({ id })

Reference implementation: src/services/OrderService.ts (lines 15-30)
Ensure all existing tests still pass after migration.

🔗 课堂关联： "按照 [模块X] 的方式实现" 本质上就是课堂技术 ② K-Shot Prompting——用已有代码作为示例。

3. 性能优化（Performance Optimization）

• 分析慢速或内存密集的代码路径
• 识别低效循环、冗余操作、昂贵查询
• 发现仍在使用的废弃或高风险模式

💡 实战 Prompt 示例：

Find repeated expensive operations in this request handler
and suggest caching opportunities.

Focus on:
1. Database queries that could be batched or cached
2. Repeated computations with identical inputs
3. N+1 query patterns
4. Any synchronous operations that could be parallelized

4. 提高测试覆盖率（Improving Test Coverage）

• 帮助编写覆盖薄弱区域的测试
• 识别边界条件（空输入、最大长度、异常但有效的状态）

💡 实战 Prompt 示例：

Write comprehensive unit tests for src/utils/parseConfig.ts.
Focus on boundary conditions:
- Empty input, null, undefined
- Malformed JSON strings
- Valid JSON but missing required fields
- Extremely large inputs (>1MB)
- Unicode and special characters in keys/values

Use our existing test patterns in tests/utils/ as reference.
Follow the describe/it/expect structure with clear test names.

🔗 课堂关联： "使用现有测试作为参考" = K-Shot Prompting；"Focus on boundary conditions" = 提供明确上下文。这个 prompt 同时使用了课堂的多种技术。

5. 提升开发速度（Increasing Development Velocity）

• 快速搭建脚手架（文件夹、模块、API stub）
• 处理发布前的小型但关键任务（bug 分类、配置文件、遥测 hook）
• 将产品反馈转化为初始代码
• 工程师反馈： "我一整天都在开会，但仍然合并了 4 个 PR，因为 Codex 在后台工作"

🔗 课堂关联： 这是 Human-Agent Engineering 的最佳诠释——工程师做高层决策（确定需求、审查 PR），Codex 做执行层工作（写代码、跑测试）。

6. 保持心流（Staying in Flow）

• 捕获未完成工作，将笔记转化为原型
• 将想法作为 Codex 任务发出，之后有空再回顾
• 核心理念： 降低暂停和恢复工作的上下文切换成本

7. 探索和构思（Exploration and Ideation）

• 寻找替代解决方案，验证设计决策
• 探索不熟悉的模式，压力测试假设
• 已知 bug 修复后，搜索代码库中可能存在的类似 bug

💡 实战 Prompt 示例：

# 架构探索
How would this work if the system were event-driven instead of request/response?
Show me a proof-of-concept refactor of the OrderService
using an event bus pattern. Include tradeoff analysis.

# 关联 bug 搜索
I just fixed a race condition in UserService.updateProfile()
where concurrent writes could overwrite each other.
Search the codebase for similar patterns where we read-modify-write
without proper locking or optimistic concurrency control.

🔗 课堂关联： 探索和构思体现了课堂"积极实验"理念——工程师不是只用 AI 做确定性任务，还用它来探索可能性和挑战假设。这也是 Reflexion（课堂技术 ⑦）的一种应用——让模型帮你"压力测试"设计方案。

OpenAI 的最佳实践

实践	说明	课堂技术对应
先用 Ask Mode	先请求实现计划，再执行代码	Reflexion（技术 ⑦）——先思考再行动
迭代改进开发环境	设置启动脚本、环境变量、网络访问	Tool Use（技术 ⑤）——给 AI 更好的工具集
像写 GitHub Issue 一样写 Prompt	包含文件路径、组件名、diff、文档	Best Practice #4/#5 结构化 + 明确指定
用任务队列作为 backlog	随时发出任务捕获灵感	Human-Agent Engineering 的工作流实践
维护 AGENTS.md	提供 Codex 无法从代码推断的信息	RAG（技术 ⑥）的一种形式
使用 Best-of-N	同时生成多个响应，选最好的	Self-Consistency（技术 ④）的工业应用

---

🔗 五篇阅读材料的核心交叉主题

1. LLM 的本质

所有材料一致认为：LLM 是统计模型，通过预测下一个 token 生成文本。它们不具备真正的理解能力，但在模式匹配和生成方面极其强大。

完整理解链： Karpathy（阅读 1）从训练原理解释 → 课堂幻灯片精华概括 → 其余阅读从使用角度验证。

2. Prompt = 新的编程方式

从 Karpathy 到 Anthropic 工程师到 Google Cloud，一致的观点是：Prompt 就是与 LLM 沟通的编程语言。清晰沟通是最核心的技能。

完整理解链： 课堂第二讲定义 7 种技术 → Google Cloud（阅读 2）提供入门框架 → promptingguide.ai（阅读 3）扩展到进阶技术 → Anthropic（阅读 4）补充实战哲学。

3. 迭代是关键

没有人一次就能写出完美的 prompt。所有材料都强调反复迭代、测试、改进的重要性。

完整理解链： 课堂"积极实验" → Anthropic（阅读 4）"发送数十甚至数百次调整" → OpenAI Codex（阅读 5）"迭代改进开发环境"。

4. 上下文工程（Context Engineering）= 核心竞争力

无论是 RAG、Few-Shot、还是 AGENTS.md，核心都是：给模型提供正确的上下文。好的上下文 = 好的输出。

完整理解链： 课堂核心理念 "LLMs 的能力取决于你自身的水平" → Karpathy（阅读 1）解释每个 token 计算预算固定 → 课堂技术 ②⑤⑥ 都是注入上下文的不同方式 → OpenAI AGENTS.md（阅读 5）是工业级上下文管理。

5. 幻觉是核心挑战

从 Karpathy 解释幻觉的根本原因（训练过程），到实际使用中的缓解策略（工具使用、RAG、自一致性），幻觉问题贯穿所有材料。

完整理解链： Karpathy（阅读 1）解释原因（标注者自信语气）→ 课堂列出局限性 → 课堂技术 ④⑤⑥ 提供缓解方案 → OpenAI Codex（阅读 5）的 Ask Mode 和 Best-of-N 是工业级应对策略。

6. 人机协作而非替代

OpenAI 的 Codex 使用案例完美诠释了课程的核心理念——Human-Agent Engineering。工程师不是被 AI 替代，而是通过 AI 工具实现了量级飞跃的生产力。

完整理解链： 课堂"你不会被 AI 取代，你会被懂 AI 的工程师取代" → Karpathy（阅读 1）"LLM 需要人类监督" → Anthropic（阅读 4）"系统思维" → OpenAI Codex（阅读 5）"一天开会还能合并 4 个 PR"。