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

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

📅 课程安排

第一讲：课程介绍 & 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 视频是完整版，建议结合观看。

训练流程（三阶段）

训练数据来源举例： 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 实战示例：

<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"是这些原则在工业环境中的最佳实践体现。

📚 第一周推荐阅读

🛠️ 第一周作业：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 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 类型

六大 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 时非常重要。

基础技术（课堂已覆盖）

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

关键概念深入

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 工程师的特质

关键实践建议

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 的最佳实践

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

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"。

CS146S 第二周笔记总结：The Anatomy of Coding Agents

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

📅 课程安排

第一讲：从零构建 Coding Agent（9/29）

1. Coding Agent 的核心架构

核心洞见：其实就是这么简单。

Coding Agent 的本质是一个循环：用户通过客户端（Cursor、Windsurf、Claude Code 等）与底层 LLM 交互，LLM 在循环中有时会发出 tool calls，客户端在 LLM 之外执行这些调用，然后将结果返回给 LLM。

用户输入 → LLM 推理 → [需要工具?] → 执行工具 → 返回结果 → LLM 继续推理 → 输出
                ↑                                              |
                └──────────────── 循环 ─────────────────────────┘

📚 延伸阅读： 第一周 Karpathy 视频中解释的 "Tool Use"（LLM 学会生成特殊 token 来触发工具调用）就是这个架构的底层原理。第一周课堂技术 ⑤（Tool Use）和 promptingguide.ai（阅读 3）的 ReAct 框架是同一个概念的不同抽象层。

2. 三种 Prompt 角色

📚 回顾第一周： 这三个角色在第一周第二讲已经介绍过。本周将它们放在 agent 循环的实际代码中使用。

3. 构建步骤

构建一个 coding agent 只需要以下步骤：

步骤 1：读取终端输入，持续追加到对话历史

conversation = []
while True:
    user_input = input("You: ")
    conversation.append({"role": "user", "content": user_input})

步骤 2：告诉 LLM 有哪些工具可用

LLM 会在适当的时机请求使用工具，你在 LLM 之外执行工具并返回响应。

tools = [
    {
        "name": "read_file",
        "description": "Read the contents of a file at the given path",
        "parameters": {"type": "object", "properties": {"path": {"type": "string"}}}
    },
    {
        "name": "list_dir",
        "description": "List files and directories at the given path",
        "parameters": {"type": "object", "properties": {"path": {"type": "string"}}}
    },
    {
        "name": "edit_file",
        "description": "Edit a file by replacing old content with new content",
        "parameters": {
            "type": "object",
            "properties": {
                "path": {"type": "string"},
                "old_content": {"type": "string"},
                "new_content": {"type": "string"}
            }
        }
    }
]

步骤 3：Agent 循环

while True:
    response = llm.chat(conversation, tools=tools)
    
    if response.has_tool_call:
        # LLM 请求调用工具
        tool_name = response.tool_call.name
        tool_args = response.tool_call.arguments
        
        # 在 LLM 外部执行工具
        result = execute_tool(tool_name, tool_args)
        
        # 将结果追加到对话，继续循环
        conversation.append({"role": "tool", "content": result})
    else:
        # LLM 给出最终回复
        print(response.content)
        break

📚 延伸阅读： 这个 while 循环就是 promptingguide.ai（第一周阅读 3）中 ReAct 框架的代码实现——Thought（LLM 推理）→ Action（工具调用）→ Observation（工具结果）→ 循环直到完成。

4. Claude Code 的"秘密武器"

课堂揭示了 Claude Code 在底层做的优化：

① 前置加载上下文 + 精准的微小 prompt

• 不是给一个巨大的 prompt，而是多次用小而精准的 prompt 注入关键上下文

② 系统提醒无处不在

• 在 system prompt、user prompt、tool calls、tool results 中都插入 <system-reminder> 标签
• 目的：防止 LLM 在长对话中"漂移"（drift），忘记初始指令

💡 实战示例：

<!-- 在 tool result 中嵌入系统提醒 -->
<tool_result>
  File content: def calculate_total(items): ...
  <system-reminder>
  Remember: Always follow existing code patterns. 
  Do NOT introduce new dependencies without asking.
  </system-reminder>
</tool_result>

③ 命令前缀提取（Command Prefix Extraction）

• 从用户输入中提取意图，减少歧义

④ 子 Agent 生成（Sub-agents）

• 生成子 agent 来处理子任务
• 避免单个 agent 上下文过载（context overloading）

📚 延伸阅读： 子 agent 的概念与第一周课堂 Best Practice #6 "任务分解" 和 promptingguide.ai 的 "Prompt Chaining" 直接对应——把复杂任务拆分给多个 agent，每个处理一个子任务。OpenAI Codex 文章（第一周阅读 5）中的 "Best-of-N" 也类似——并行生成多个方案。

第二讲：构建自定义 MCP 服务器（10/3）

1. 为什么需要 MCP？

核心问题： LLM 拥有庞大但静态的知识，只有重新训练才能更新。要构建完全自主的系统，需要可靠的方式向模型注入动态数据。

需要动态数据的场景：今天的天气？谁是总统？比特币价格？Nike 最新广告的旁白是谁？

RAG 和 Tool Calling 是目前最好的答案。

📚 回顾第一周： 这正是第一周课堂技术 ⑥（RAG）和技术 ⑤（Tool Use）解决的问题。MCP 是这两个概念的工业级标准化实现。

2. MCP 基础概念

Model Context Protocol（模型上下文协议）：

一句话定义：让系统以跨集成通用的方式向 AI 模型提供上下文的开放协议。更直白地说——给 LLM 暴露工具的标准格式。

历史背景： 在 2024 年 11 月 MCP 推出之前，每个 LLM 应用都需要为每个 API 写自定义的集成代码——就像上节课我们手动写的那个 agent，API 格式比较规范所以还行。但如果 API 文档差、格式不一致、认证复杂，那就是噩梦了。

3. 从 M×N 到 M+N 的飞跃

没有 MCP 的世界：

LLM App 1 ──┬── API 1    想象要为每个 API 写自定义连接器
LLM App 2 ──┼── API 2    M 个 LLM 应用 × N 个 API = M×N 个连接器
LLM App 3 ──┴── API 3    认证、错误处理、速率限制...全部重复实现

有 MCP 的世界：

LLM App 1 ─┐              ┌── MCP Server 1 (→ API 1)
LLM App 2 ─┤── MCP 协议 ──┤── MCP Server 2 (→ API 2)
LLM App 3 ─┘              └── MCP Server 3 (→ API 3)

M + N 个连接器，统一格式（JSON-RPC）

MCP 的核心优势：

• 不需要为每个工具重新实现认证、错误处理、速率限制
• 使用 JSON-RPC 强制统一输出格式
• 从 Language Server Protocol（LSP）扩展而来，但支持主动的 agentic 工作流而不仅是被动的
• 集成工具从 M × N → M + N 个连接器

4. MCP 架构详解

四个核心组件：

完整交互流程：

1. MCP Client → MCP Server：  tools/list（你能做什么？）
2. MCP Server → MCP Client：  返回 JSON 描述每个工具（名称、摘要、JSON Schema）
3. Host 将工具 JSON 注入 LLM 的上下文
4. 用户提问 → LLM 生成结构化的 tool call
5. MCP Client → MCP Server：  tools/call（执行指定工具）
6. MCP Server 执行工具 → 返回结果
7. 对话恢复

💡 实战示例——MCP 交互流程：

用户："帮我总结 Jack 发来的邮件"

1. [用户] → MCP Client：发送查询
2. [MCP Client] → MCP Server：tools/list（获取可用工具）
3. [MCP Server] → 返回：[{name: "search_emails", ...}, {name: "summarize", ...}]
4. [LLM] 决定调用 search_emails(from="Jack")
5. [MCP Client] → MCP Server：tools/call("search_emails", {from: "Jack"})
6. [MCP Server] → 执行 Email API 查询 → 返回邮件内容
7. [LLM] 基于返回的邮件内容生成摘要

传输层： MCP 提供 stdio（本地进程通信）和 SSE（Server-Sent Events，用于远程通信）两种传输方式。

5. MCP 的当前局限

课堂明确提出了三个关键限制：

① Agent 不擅长处理大量工具

• Cursor 对工具数量有硬限制
• 模型在工具过多时，tool calling 准确率显著下降

② API 会快速吃掉上下文窗口

• 每个工具的描述和返回值都消耗 token
• 大型 API 响应（如返回 100 条记录）可能直接撑爆上下文

③ 需要设计 AI-native 的 API，而非照搬传统 API

• 传统 API 是为程序调用设计的
• AI agent 需要的是更灵活、更精简的工具接口

📚 延伸阅读： "APIs don't make good MCP tools"（阅读 6）详细论证了为什么不能简单地把现有 API 转成 MCP 工具——工具太多会降低准确率、JSON 格式浪费 token、传统 API 没有利用 agent 的独特能力。第一周课堂提到的"上下文窗口限制"和"lost-in-the-middle 效应"在 MCP 场景下尤为严重。

🔗 两讲之间的联系

第一讲（构建 Agent）和第二讲（MCP）构成了完整的技术栈：

第一讲：Agent 的核心循环
  User → LLM → Tool Call → Execute → Result → LLM → Response
                   ↓
第二讲：MCP 标准化了这一层
  Tool Call → MCP Client → MCP Server → Tool Execution → Result

关键理解： MCP 没有改变 agent 的工作方式，它只是标准化了 tool call 和 tool execution 之间的通信协议。上节课手写的 read_file、list_dir、edit_file 工具，如果用 MCP 封装，就可以被任何 MCP 兼容的客户端使用。

📚 第二周推荐阅读

🛠️ 第二周作业：First Steps in the AI IDE

• 仓库：github.com/mihail911/modern-software-dev-assignments/tree/master/week2
• 实践在 AI IDE 中使用 coding agent
• 体验 agent 的 tool calling 循环

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

Stanford University · Fall 2025 · 讲师：Mihail Eric

阅读材料一览

📖 阅读 1：MCP Introduction (Stytch)

来源： Stytch 工程博客，作者 Reed McGinley-Stempel

🔗 课堂关联： 这篇阅读是第二讲 MCP 内容的完整技术展开。课堂用 13 张幻灯片概括了 MCP 的核心概念，这篇文章提供了架构细节、代码示例、与其他方案的对比、以及 OAuth 认证——课堂没有时间覆盖的部分。

MCP 是什么？

MCP 是一个开放标准，连接 AI 模型与外部数据和服务，让 LLM 能以结构化、一致、安全的方式进行 API 调用。类比：USB-C 统一了各种设备的连接方式，MCP 统一了 AI 与外部工具的连接方式。

技术上，MCP 基于 JSON-RPC 2.0 协议，定义了 LLM 应用调用外部函数、获取数据、使用预定义 prompt 的标准"语言"。

Client-Server 架构

与课堂 Slide 9 的架构一致：

🔗 课堂关联： 课堂强调了 "Host 将工具 JSON 注入模型上下文" 这个关键步骤。这篇文章补充了具体的 JSON-RPC 请求格式。

五大核心优势

1. 快速工具集成（Rapid Tool Integration）

• 如果某个 MCP Server 已经存在（如 Google Drive、SQL 数据库），任何 MCP 兼容应用可以直接连接使用
• 类似一个"即插即用"的插件库

2. 自主 Agent 能力（Autonomous Agents）

• Agent 不再局限于内置知识，可以主动检索信息、执行操作
• 实现多步骤工作流：从 CRM 获取数据 → 发邮件 → 记录数据库

🔗 课堂关联： 这正是第一讲 Agent 循环的应用场景——MCP 让 Agent 的 tool call 变得标准化，从而支持更复杂的多步骤工作流。

3. 减少摩擦（Reduced Friction）

• 一旦应用支持 MCP，就能通过单一机制连接任意数量的服务

4. 一致性和互操作性（Consistency & Interoperability）

• 统一的 JSON 请求/响应格式
• 即使切换 LLM 供应商，MCP 的工具接口保持不变

5. 双向上下文（Two-Way Context）

• MCP Server 不仅暴露工具（Tools），还可以提供 Prompts（预定义 prompt 模板）和 Resources（数据上下文如文档）
• 支持丰富的交互，不仅仅是一次性查询

MCP vs 其他方案对比

🔗 课堂关联： 课堂的 Slide 4-8 用"从 M×N 到 M+N"来解释 MCP 的价值。这篇文章从更多维度进行了对比，特别是与 ChatGPT Plugins 和 LangChain 的比较，帮助理解 MCP 在生态中的定位。

完整交互流程（代码级）

// 1. 连接 MCP Server
const mcpClient = await connectToServer("localhost:3000");

// 2. 发现可用工具
const tools = await mcpClient.request(
  { method: 'tools/list' },
  ListToolsResultSchema
);
// 返回: [{name: "get_weather", description: "...", schema: {location: "string"}}]

// 3. LLM 选择工具（由 Host 应用的 LLM 决定）
// 用户问："AAPL 现在多少钱？"
// LLM 决定调用 get_current_stock_price(company="AAPL")

// 4. 通过 MCP 执行工具
const result = await mcpClient.request({
  method: 'tools/call',
  params: { name: "get_current_stock_price", arguments: {company: "AAPL"} }
}, CallToolResultSchema);

// 5. 将结果返回给 LLM
// LLM: "AAPL 当前股价为 $173.22"

🔗 课堂关联： 这段代码就是课堂第一讲手写 Agent 循环的 MCP 版本——区别在于 tool 的发现、调用、响应都走 MCP 标准协议。

OAuth 认证（课堂未覆盖）

早期 MCP 没有内置认证机制——Server 必须运行在本地或可信环境中。这是一个重大限制：多用户场景和云端部署无法安全使用 MCP。

2025 年，MCP 采用了 OAuth 2.0 标准：

• 动态客户端注册（DCR）：Client 自动向 OAuth Server 注册，无需手动配置
• 自动端点发现：利用 OAuth 标准化的元数据 URL 自动发现认证端点
• 安全的令牌管理：根据用户权限和访问范围获取精确的 OAuth 令牌
• 多用户支持：天然支持多个并发用户和服务

📖 阅读 2：Sample MCP Server Implementations

来源： github.com/modelcontextprotocol/servers

🔗 课堂关联： 这是第二讲"构建自定义 MCP Server"实操的参考实现库。课堂上从零开始写了 list_files 和 edit_file 工具，这个 repo 提供了大量生产级的 MCP Server 实现。

核心价值

这是 MCP 官方维护的 Server 实现集合，涵盖多种常见服务的集成，包括文件系统、数据库、API 服务等。开发者可以直接使用这些 Server 或作为构建自定义 Server 的模板。

学习路径建议

1. 先看简单的 Server（如 filesystem）理解基本结构
2. 再看复杂的 Server（如 GitHub、Slack）理解真实场景
3. 用这些实现作为参考来完成第二周作业

📖 阅读 3：MCP Server Authentication (Cloudflare)

来源： Cloudflare 开发者文档

🔗 课堂关联： 课堂第二讲聚焦于 MCP 的核心概念和本地构建，没有深入认证。这篇文档补充了远程 MCP Server 的安全认证实践——这在生产环境中至关重要。

核心内容

Cloudflare 提供了构建和部署远程 MCP Server 的平台，核心解决的问题是：如何安全地让 AI Agent 通过互联网访问外部服务？

关键技术点：

• 使用 OAuth 2.0 进行认证
• Cloudflare Workers 作为 MCP Server 的运行环境
• 支持多用户认证和权限管理

🔗 课堂关联： 阅读 1（Stytch）解释了 MCP OAuth 的原理，这篇文档提供了 Cloudflare 平台上的具体实现方式。

📖 阅读 4：MCP Server SDK (TypeScript)

来源： github.com/modelcontextprotocol/typescript-sdk

🔗 课堂关联： 这是构建 MCP Server 的官方 TypeScript SDK，课堂实操可能使用了这个 SDK 或类似的 Python SDK。

核心价值

SDK 封装了 MCP 协议的底层细节（JSON-RPC 消息格式、传输层、会话管理），让开发者可以专注于工具逻辑：

import { Server } from "@modelcontextprotocol/sdk/server";

const server = new Server({
  name: "my-mcp-server",
  version: "1.0.0"
});

// 注册工具
server.tool("search_emails", 
  { from: { type: "string" }, query: { type: "string" } },
  async ({ from, query }) => {
    // 实际的邮件搜索逻辑
    const emails = await emailService.search(from, query);
    return { content: [{ type: "text", text: JSON.stringify(emails) }] };
  }
);

📖 阅读 5：MCP Registry

来源： MCP 官方博客，2025 年 9 月 8 日

🔗 课堂关联： 课堂讲了如何构建 MCP Server，但没有讨论生态系统层面的问题——如何发现和分发 MCP Server？MCP Registry 解决的就是这个问题。

MCP Registry 是什么？

一个开放的目录和 API，用于公开可用的 MCP Server 的发现和分发。类比：

• npm registry 之于 Node.js 包
• Docker Hub 之于容器镜像
• MCP Registry 之于 MCP Server

核心特性

单一真实来源（Single Source of Truth）：

• 官方 URL：registry.modelcontextprotocol.io
• 开源，包含 OpenAPI 规范
• 任何人都可以构建兼容的子注册表

公共和私有子注册表：

• 公共子注册表： 如各 MCP 客户端的"应用市场"（类比 VS Code Extension Marketplace）
• 私有子注册表： 企业内部使用，满足隐私和安全要求

社区驱动的审核机制：

• 社区成员可以举报违规 Server（垃圾、恶意代码、冒充合法服务）
• 维护者可以将其加入黑名单

背景与意义

MCP Registry 始于 2025 年 2 月的草根项目，由 MCP 创建者 David Soria Parra 和 Justin Spahr-Summers 发起，联合了 PulseMCP、Goose、Block、GitHub、Anthropic 等多方力量。初始公告列出了来自至少 9 家公司的 16 位贡献者。

🔗 课堂关联： 课堂 Slide 8 提到 MCP 让工具集成从 M×N 变为 M+N。MCP Registry 进一步简化了这个过程——你甚至不需要知道有哪些 Server 存在，直接从 Registry 搜索即可。这也是第一周 Karpathy 讲的 "LLM 生态系统" 概念的基础设施层面体现。

📖 阅读 6：APIs don't make good MCP tools

作者： Reilly Wood

🔗 课堂关联： 这是本周最具批判性思维的阅读材料。课堂第二讲 Slide 12 列出了 MCP 的三个局限（工具过多、上下文消耗、需要 AI-native 设计），这篇文章从四个维度深入论证了为什么不能简单地把现有 API 转成 MCP 工具。

核心论点：Agent ≠ API 的典型消费者

很多人提出用 OpenAPI 元数据自动将现有 API 转换为 MCP 工具。作者认为这种方法可以工作，但效果不好。

四个原因

① Agent 不擅长处理大量工具

• VS Code 硬限制 128 个工具，但很多模型在远低于这个数字时就开始出错
• 每个工具的描述占用宝贵的上下文窗口空间
• 传统 Web API 设计时不考虑这些约束——一个产品可能有几十个 API 端点
• 为 MCP 从头设计的工具通常更灵活，一个工具可以做多个 API 的工作

🔗 课堂关联： 课堂提到 "Cursor 对工具数量有硬限制"，这篇文章给出了具体数字和学术引用。

② API 响应快速消耗上下文窗口

• 想象一个 API 一次返回 100 条记录，每条有 50 个字段——这会消耗大量 token
• 即使查询只需要几个字段，所有字段都进入上下文
• JSON 格式非常浪费 token

💡 关键示例——JSON vs CSV 的 token 效率：

// JSON: 浪费 token（重复的 key 名称）
[
  {"firstName": "Alice", "lastName": "Johnson", "age": 28},
  {"firstName": "Bob", "lastName": "Smith", "age": 35}
]

// CSV: 节省约 50% 的 token
firstName,lastName,age
Alice,Johnson,28
Bob,Smith,35

作者建议：CSV、TSV 或 YAML（嵌套数据）通常比 JSON 更适合 LLM 消费。

🔗 课堂关联： 第一周课堂提到"上下文窗口限制（~100-200K tokens）"和 "lost-in-the-middle 效应"。在 MCP 场景下，这个问题被放大——每次工具调用的返回值都占用上下文。

③ API 没有利用 Agent 的独特能力

API 返回结构化数据给程序消费——但 Agent 还能处理自由文本指令。

MCP 工具可以做到传统 API 做不到的事：

• ask_question 工具可以对文档执行 RAG 查询，返回纯文本
• search_cities 工具可以返回结构化数据加上下一步建议：

city_name,population,country
Tokyo,37194000,Japan
Delhi,32941000,India

建议：要获取更详细信息（天气、景点），请调用 get_city_details 并传入 city_name。

这种分层和工具链设计（tool chaining）在 MCP Server 中非常有效。

🔗 课堂关联： 这与 promptingguide.ai（第一周阅读 3）的 Prompt Chaining 概念一致——工具之间形成链条，上一步的输出引导下一步。

④ 如果 Agent 需要调用 API，它可以自己写代码调用

Claude Code 等 agent 已经非常擅长编写和执行调用 Web API 的脚本。有些人甚至认为 MCP 根本不需要——agent 直接写代码调用 API 就好了。

作者不完全同意，但认为应该"看向冰球将去的方向"——随着 agent 沙箱能力的提升，直接调用 API 可能变得越来越容易。

结论

Agent 与 API 的传统消费者有根本不同。自动将 API 转为 MCP 工具是可能的，但不太可能做得好。Agent 在使用专门为其设计的工具时表现最佳。

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

1. MCP = Tool Use 的标准化

第一周学的是 Tool Use 的概念，第二周学的是 Tool Use 的工业标准。阅读 1（Stytch）提供了最全面的技术解释，课堂 slides 是精华概括。

完整理解链： 第一周技术 ⑤（Tool Use 概念）→ 第二周第一讲（手写 Agent 循环）→ 第二周第二讲（MCP 标准化）→ 阅读 1（完整技术细节）→ 阅读 2/4（SDK 和实现）

2. 生态系统正在快速成熟

从 SDK（阅读 4）到 Registry（阅读 5）到 Authentication（阅读 3），MCP 生态系统的每一层都在快速完善——这与课堂第一周强调的"工具会过时，但原理不变"形成对比：MCP 作为协议可能会持久，但具体工具和实现会不断演进。

完整理解链： 阅读 4（开发层：SDK）→ 阅读 2（示例层：参考实现）→ 阅读 3（安全层：OAuth）→ 阅读 5（生态层：Registry）

3. AI-Native 设计 vs 传统 API 设计

这是本周最重要的概念转变。阅读 6 的核心论点是：为 Agent 设计工具需要不同于传统 API 的思维方式。

完整理解链： 课堂局限性（Slide 12）→ 阅读 6 深入论证 → 关键启示：减少工具数量但增加灵活性、使用 token 效率更高的格式（CSV > JSON）、利用 agent 的文本理解能力

4. 从手动集成到标准化协议

本周的知识脉络是一个清晰的抽象层提升：

第一讲：手动写 tools（read_file, list_dir, edit_file）
         ↓ 标准化
第二讲：用 MCP 协议封装 tools
         ↓ 生态化
阅读材料：SDK + Registry + Auth 构成完整生态系统

🔗 课程脉络： 第一周学"LLM 是什么 + 如何 prompt"，第二周学"Agent 是什么 + 如何标准化工具接口"。下一周（第 3 周）将进入"如何在 AI IDE 中实际使用这些 Agent"——从构建原理走向实际应用。

CS146S 第三周笔记总结：The AI IDE

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

📅 课程安排

第一讲：从第一个 Prompt 到最优 IDE 配置（10/6）

1. 为什么关注 IDE？

IDE（集成开发环境）是软件开发的全能工作空间，包含编辑器、编译器、调试器等。大部分开发工作都在这里完成，因此是 AI 增强的天然入口。

IDE 演化史中有一个核心张力：功能整合 vs 开发者自定义——不断在"统一平台"和"自由选择"之间摇摆。

2. IDE 简史

📚 延伸阅读： 第二周讲 MCP 时提到它"从 LSP 扩展而来"。这里揭示了完整脉络：VS Code 的 LSP（2015）→ MCP（2024）——从帮助编辑器理解代码到帮助 LLM 理解工具。

3. AI IDE 的使用模式

基础模式（Bread-and-butter）：

AI-Native 高级模式：

4. AI IDE 的底层原理

Tab Complete（自动补全）：

1. 当前代码周围的小上下文窗口被加密
2. 发送到服务器，运行 infilling LLM
3. 建议返回并显示在编辑器中

Chat（聊天模式）：

1. 代码片段作为 embeddings 存储在服务器上的语义索引中（文件名被混淆 + 代码内容）
2. 任何查询检索最相关的代码块，作为上下文送入 LLM
3. IDE 定期重新索引代码块并同步 embeddings
4. 使用 Merkle Trees 计算增量差异，实现高效更新

📚 延伸阅读： 语义索引的概念直接对应第一周课堂技术 ⑥（RAG）——IDE 的 Chat 模式本质上就是对你的代码库做 RAG。"How Long Contexts Fail"（阅读 2）解释了为什么不能简单把所有代码扔进上下文，必须用 RAG/索引来选择性地提供上下文。

💡 在 Cursor 中查看索引状态：

Settings > "Indexing & Docs" > "Ignore Files in .cursorignore" > "View included files"

5. Best Practices：Specs Doc（规格文档）

核心洞见： 简单改动不需要精心设计 prompt。但对于复杂任务，你会变成产品经理——需要精心编写 specs doc。

Specs Doc 的八个要素：

📚 延伸阅读： "Specs Are the New Source Code"（阅读 1）深入论证了为什么 Spec 正在成为新的"源代码"。OpenAI Codex 文章（第一周阅读 5）也建议"像 GitHub Issue 一样结构化 prompt"。

6. Best Practices：优化代码库

核心原则： 优化你的代码库，让人类和 agent 都能理解正在发生什么。

LLM 的很多困惑来自于在混乱的代码库中尝试完成任务。混乱的代码库可能表现为：不同的数据库访问模式、不一致的变量命名、多个做同样事情的函数。

应该彻底文档化的内容： Repo 导航指引、文件结构、环境搭建、最佳实践和代码风格、访问模式、API 和契约。

提示：强烈推荐 monorepo 设计——所有代码在一个仓库中，减少 agent 需要跨仓库理解的复杂性。

7. Best Practices：Agent 配置文件

AGENTS.md vs README.md：

• README.md 写给人看：快速入门、项目描述、贡献指南
• AGENTS.md 写给 agent 看：构建步骤、测试命令、约定

⚠️ 注意： Agent 不总是遵循这些指令——它们是指导性的（guidance），不是强制性的。

第二讲：🎤 Silas Alberti 客座讲座 — IDE ❤️ Agents（10/10）

Silas Alberti：Cognition 创始团队 + 研究负责人（Devin 的公司），前 Stanford PhD

1. AI 编程工具的三个时代

关键演变： 从本地同步 → 云端异步，从 1-to-1 → 1-to-Many。

2. 同步 vs 异步

3. 半异步陷阱

"半异步"区间（约 1-5 分钟）是最糟糕的区间：太慢无法保持心流，太短无法切换到其他任务。

两种策略：向左推（让同步工具更快以保持心流）或向右推（投入更多时间换取更高智能）。

4. Devin 的工作流

5. 核心观察与未来展望

管理异步 agent 可以解锁 10× 收益，但大多数人只使用同步 agent。 因为管理和委派本身就是一项难以掌握的技能。

未来最有价值的技能：

• 委派和多线程管理
• 代码阅读能力
• 规划、范围界定、架构设计

📚 课程主线关联： 直接呼应课程核心理念"Human-Agent Engineering"——开发者角色从"写代码的人"变为"管理 agent 的人"。

🔗 两讲的统一主线

两讲共同论证：AI IDE 不只是一个更快的编辑器，它是一种新的工作方式。

• 第一讲（个人层面）： Spec 驱动开发 + Agent 配置文件 + 代码库优化
• 第二讲（团队层面）： 同步/异步混合工作流 + 委派技能 + 10× 杠杆

从第 1 周到第 3 周的知识进阶：

第 1 周：LLM 原理 + Prompt 技术（基础认知）
    ↓
第 2 周：Agent 架构 + MCP 协议（构建工具）
    ↓
第 3 周：AI IDE + Spec 驱动开发 + 同步/异步工作流（实际使用）

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

Stanford University · Fall 2025 · 讲师：Mihail Eric

阅读材料一览

📖 阅读 1：Specs Are the New Source Code

来源： Ravi Mehta (前 Reforge CPO) Substack，2025 年 7 月

🔗 课堂关联： 这是第一讲 Slides 9-10（Specs Doc 八要素）的理论基础和行业论证。课堂说"复杂任务中你要变成产品经理"，这篇文章深度解释了为什么。

核心论点：Spec 正在变成新的"源代码"

Sean Grove（OpenAI）的观点： 我们现在做 AI 开发的方式是倒过来的——我们精心编写 prompt 传达意图给模型，AI 生成代码，然后我们保留代码、丢弃 prompt。这就像"把源代码碎掉，然后精心版本控制二进制文件"。

传统软件开发中，源代码是神圣的——包含注释、结构、文档。二进制文件只是下游产物。但在 AI 时代，我们把关系搞反了。

关键引用： "一个足够健壮的 Spec 可以生成好的 TypeScript、好的 Rust、服务器、客户端、文档、教程、博客文章，甚至播客。"

更重要的是： Spec 做到了代码做不到的事——同时对齐人类和机器的共同目标。

工作流的变革

旧工作流： 模糊想法 → 线框图 → 设计 → 工程师构建 MVP → 用户反馈 → 痛苦的 Spec 修改 → 重建

新工作流： 模糊想法 → 快速原型（v0/Lovable/Replit）→ 用户反馈 → 清晰的 Spec → AI 辅助实现

关键变化： Spec 从输入变成了输出——先用 AI 快速验证想法，然后写 Spec。原型没有杀死 Spec，而是让 Spec 变得更好。

PM 的新角色

Andrew Ng 的观察："我第一次见到有人提议让 PM 数量是工程师的两倍。" 随着 AI 让工程师交付更快，公司需要更多 PM来支持这些高产的工程师。

对课堂的启示： 课堂要求掌握写 Spec 的技能，不是在教"产品管理"，而是在教未来软件工程师的核心技能——因为"在不久的将来，沟通最有效的人就是最有价值的程序员"。

🔗 课堂关联： 课堂 Slides 9-10 给出了 Spec 的八要素（Goal, Definitions, Plan, Source files, Test cases, Edge cases, Out-of-scope, Extensions）。这篇文章解释了为什么这些要素如此重要——它们不只是给 LLM 的指令，更是团队对齐的核心载体。

📖 阅读 2：How Long Contexts Fail

来源： Drew Breunig 博客，2025 年 6 月

🔗 课堂关联： 第一讲 Slide 8 解释了 IDE 的 Chat 模式使用语义索引（RAG）而非直接塞入所有代码。这篇文章解释了为什么必须这样做——长上下文并不等于更好的结果。

核心论点：更长的上下文窗口 ≠ 更好的结果

随着前沿模型支持百万级 token 上下文窗口，很多人兴奋地认为可以"把所有东西扔进 prompt"。但实际上，过载的上下文会导致 agent 以令人意外的方式失败。

四种上下文失败模式

① 上下文中毒（Context Poisoning）

当幻觉或其他错误进入上下文后，会被反复引用。

Gemini 2.5 技术报告中的案例：AI 玩 Pokémon 时，一次幻觉"毒化"了其目标列表，导致 agent 追求不可能达成的目标，需要很长时间才能修复。

🔗 课堂关联： 第二周 Claude Code 的"秘密武器"之一是在 tool results 中嵌入 <system-reminder> 来防止 drift——这正是对抗上下文中毒的策略。

② 上下文分心（Context Distraction）

当上下文过长时，模型过度关注上下文本身，忽略训练中学到的知识。

Gemini 研究发现：当上下文超过约 100K token 后，agent 倾向于重复历史中的动作而非合成新计划。Databricks 研究发现 Llama 3.1 405B 在约 32K token 时准确率开始下降。

🔗 课堂关联： 第一周讲到的"上下文窗口限制"和 "primacy/recency bias"（首位效应/近因效应）在这里得到了实证支持。

③ 上下文混淆（Context Confusion）

上下文中无关内容被模型用来生成低质量回复。

Berkeley 函数调用排行榜证明：每个模型在多工具场景中表现都比单工具差，且所有模型偶尔会调用不相关的工具。量化后的 Llama 3.1 8B 在 46 个工具时失败，但在 19 个工具时成功——尽管上下文远未超出限制。

🔗 课堂关联： 第二周课堂 Slide 12 提到"Agent 不擅长处理大量工具"和"Cursor 对工具数量有硬限制"——这篇文章给出了学术依据。

④ 上下文冲突（Context Clash）

上下文中积累的新信息与旧信息相互矛盾。

Microsoft/Salesforce 研究：将单一 prompt 拆分为多轮对话后，准确率平均下降 39%。o3 的分数从 98.1 降到 64.1。原因：早期轮次中模型的错误尝试留在上下文中，影响最终答案。

🔗 课堂关联： 这直接解释了第二周 Claude Code 为什么要使用子 Agent——每个子 Agent 有独立的上下文，避免主 Agent 的上下文被早期错误"污染"。

对 AI IDE 的启示

这四种失败模式共同解释了为什么 AI IDE 不能简单地"把所有代码塞进上下文"：

• Tab Complete 只发送小上下文窗口
• Chat 模式使用 RAG/语义索引选择性提供上下文
• Agent 配置文件（CLAUDE.md 等）是精心策划的上下文，而非随机的代码堆积

📖 阅读 3：Devin — Coding Agents 101

来源： devin.ai/agents101

🔗 课堂关联： 这是第二讲 Silas Alberti 演讲的产品文档补充。Silas 讲的是高层工作流（Plan→Build→Review），这篇文档提供了 Devin 的技术架构细节。

核心概念

Devin 是一个完全异步的 AI 软件工程师，可以在云端独立工作数小时——包括计划、编码、测试、调试。它拥有自己的隔离工作空间（shell + editor + browser）。

与 Cursor/Windsurf 等同步工具的本质区别：Devin 不需要开发者持续在旁监督，而是接受委派后自主完成，最终交付一个干净的 PR。

📖 阅读 4：Getting AI to Work In Complex Codebases

来源： github.com/humanlayer/advanced-context-engineering-for-coding-agents

🔗 课堂关联： 第一讲 Slides 12-14（优化代码库、Agent 配置文件）的深度展开。课堂给出了高层建议，这篇文章提供了在真实复杂代码库中实施上下文工程的具体方法。

核心概念

"Advanced Context Engineering"——在复杂代码库中，上下文工程（而非简单的 prompt engineering）是让 AI 有效工作的关键。这包括：如何组织代码让 agent 可导航、如何策划上下文让 agent 获得恰好足够的信息、如何避免上下文过载。

与阅读 2（How Long Contexts Fail）互为补充：阅读 2 解释了为什么上下文管理重要，阅读 4 解释了怎么做。

📖 阅读 5：How FAANG Vibe Codes

来源： Twitter/X @rohanpaul_ai

🔗 课堂关联： 行业视角补充——大厂如何在实际产品开发中使用 AI 编程工具。

📖 阅读 6：Writing Effective Tools for Agents (Anthropic)

来源： Anthropic Engineering Blog，2025 年 9 月

🔗 课堂关联： 这篇文章横跨第二周（MCP 工具构建）和第三周（IDE 中使用工具），是从 Anthropic 内部视角总结的工具设计最佳实践。

核心论点：Tools 是确定性系统和非确定性 Agent 之间的新型"契约"

传统软件中，getWeather("NYC") 总是以完全相同的方式获取纽约天气。但当用户问"今天需要带伞吗？"，agent 可能调用天气工具、可能直接从知识回答、也可能先问你在哪个城市——这就是非确定性。

工具设计的五大原则

① 选择正确的工具（不是越多越好）

常见错误：把现有 API 端点一对一映射为 MCP 工具。Agent 的"可供性"（affordances）不同于传统软件。

💡 正确做法——合并功能：

• ❌ 分别实现 list_users + list_events + create_event
• ✅ 实现一个 schedule_event 工具，内部处理查找可用时间和创建事件
• ❌ 实现 read_logs 工具
• ✅ 实现 search_logs 工具，只返回相关日志行及周围上下文

🔗 课堂关联： 第二周 "APIs don't make good MCP tools"（阅读 6）从理论上论证了为什么不能简单转换 API。这篇文章从实践上给出了正确的替代方案。

② 命名空间化工具（Namespacing）

当 agent 接入数十个 MCP Server 和数百个工具时，命名空间帮助 agent 区分工具边界。例如：asana_search vs jira_search，asana_projects_search vs asana_users_search。

③ 返回有意义的上下文

优先返回高信号信息，避免低级技术标识符。

• ❌ 返回 uuid, 256px_image_url, mime_type
• ✅ 返回 name, image_url, file_type

将 UUID 解析为语义化的自然语言显著减少幻觉并提高检索精度。

支持 response_format 参数："concise"（72 token）vs "detailed"（206 token），让 agent 控制返回的详细程度。

④ 优化 Token 效率

实现分页、范围选择、过滤和截断，并设置合理的默认值。Claude Code 默认限制工具响应为 25,000 token。

在截断响应中引导 agent 采取更高效的策略：

Results truncated (showing 50 of 342 matches).
Tip: Use the 'filter' parameter to narrow results,
e.g., filter="status:open AND assignee:jane"

错误响应也要有帮助性——给出具体的修正建议而非不透明的错误码。

⑤ Prompt 工程化工具描述

把工具描述当作给新同事的说明来写——把你隐含的上下文（专用查询格式、术语定义、资源间关系）显式化。

Claude Sonnet 3.5 在 SWE-bench 上通过精确优化工具描述达到了 SOTA——即使是小的描述改进也能产生巨大的效果。

协作流程：用 Agent 优化 Agent 的工具

Anthropic 推荐一个迭代循环：

1. 原型： 快速搭建工具，本地测试
2. 评估： 生成大量评估任务（受真实场景启发），运行评估
3. 协作： 把评估结果交给 Claude Code 分析，让它自动改进工具描述和实现
4. 验证： 用留出的测试集确保没有过拟合

在内部实验中，Claude 优化后的工具超过了人类专家手写的工具的性能。

🔗 课堂关联： 第一周课堂 Best Practice "迭代你的 prompt"在这里扩展为"迭代你的工具"——用同样的评估-改进循环优化工具描述、返回格式、命名空间。

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

1. Spec 驱动开发成为新范式

阅读 1 从产品角度论证 Spec = 新源代码，课堂 Slides 9-10 给出了八要素框架，Silas 在第二讲中展示了 Devin 的 Plan→Build→Review 工作流——Planning（写 Spec）是人类主导的阶段，也是价值最高的阶段。

完整理解链： 第一周 Prompt 技术 → 第三周 Specs Doc 八要素（课堂）→ 阅读 1 理论论证 → Silas 的 Plan→Build→Review 实践

2. 上下文管理是 AI IDE 的核心挑战

阅读 2 系统分类了四种上下文失败模式，阅读 4 提供了在复杂代码库中管理上下文的实践方案，阅读 6（Anthropic）从工具设计角度优化上下文质量。课堂展示了 IDE 的底层方案（RAG + Merkle Tree 增量更新）。

完整理解链： 第一周上下文窗口限制 → 第二周 MCP 工具消耗上下文 → 阅读 2 四种失败模式 → 课堂 IDE 底层方案 → 阅读 4/6 实践对策

3. 人类角色从编码者转变为管理者

Silas 的"三个时代"（10%→20%→6-12×）量化了这个转变。阅读 1 论证了 PM 的新价值。课堂的 Agent 配置文件（CLAUDE.md, AGENTS.md）是这个新角色的基础设施。

完整理解链： 第一周"你不会被 AI 取代，但会被善用 AI 的工程师取代" → 第二周 Agent 循环架构 → 第三周 Silas 的同步/异步框架 → 阅读 1 "沟通最有效的人 = 最有价值的程序员"

4. 工具设计需要"为 Agent 而非为人类"重新思考

阅读 6（Anthropic）系统化了工具设计原则，与第二周阅读 6（APIs don't make good MCP tools）形成完整的论证链：不要照搬传统 API，要从 agent 的视角重新设计工具。

🔗 课程脉络： 第 1 周学"prompt"，第 2 周学"tool"，第 3 周学"spec + context + workflow"。下一周（第 4 周）将深入"如何管理 agent 的自主性"——从工具层上升到协作模式层。

CS146S 第四周笔记总结：Coding Agent Patterns

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

📅 课程安排

第一讲：How to be an Agent Manager（10/13）

1. 开发团队的演化史

2. 终极目标

每个开发者都将成为一个技术主管（Tech Lead），指挥自己的 agent 军团。

这些 agent 按以下维度专业化：

• 任务类型：PR 审查、质量保证等
• 语言/框架：React、FastAPI Python、Svelte 等
• 角色职责：数据工程师、ML 工程师、DevOps 等

最终，甚至一个中等技术水平的 PM 也能做到同样的事情。

3. 软件任务分工

📚 课程关联： 这个分工表直接对应第三周 Silas 的三阶段工作流（Planning → Coding → Testing），但更加细化——7 个步骤中只有前 1.5 个需要人类深度参与。

4. 指导 Agent 的四种技术

① Agent 行为文件（第三周已介绍）

CLAUDE.md / .cursorrules / AGENTS.md —— 定义 agent 的基础行为锚点。

② Hooks（钩子）

定义： 在预定义事件类型上运行的确定性脚本。

关键洞见： Hooks 是确定性的（不是 LLM 生成的），这保证了关键操作的可靠性和可审计性。

📚 课程关联： Hooks 解决了第三周阅读 2（"How Long Contexts Fail"）提到的 Context Drift 问题——通过在关键节点强制执行确定性逻辑来防止 agent 偏离。

③ Commands（命令）

定义： 将常用 prompt 存储为文件，agent 可以执行这些命令。

Commands 存储在 .claude/commands/ 文件夹中，支持 $ARGUMENTS 参数传递。

📚 延伸阅读： Claude Code Best Practices（阅读 2）详细展示了 slash commands 的实现，包括自动修复 GitHub issue 的完整命令模板。

④ Subagents（子 Agent）

定义： 运行时委托，将任务分派给具有独立上下文窗口的专门 agent。

核心特性：

• 为不同类型的工作创建独立的开发者人格（前端、后端等）
• 每个子 agent 拥有定制的 system prompt、工具和独立的上下文窗口
• 实现Agent 管理 Agent 的架构

💡 实战示例：

主 Agent（Tech Lead 角色）
├── Frontend Sub-agent（React 专家，只能访问 src/components/）
├── Backend Sub-agent（Python 专家，只能访问 api/）
├── Test Sub-agent（QA 角色，运行测试套件）
└── Docs Sub-agent（技术写作，更新 README/CHANGELOG）

📚 课程关联： 子 agent 直接解决了第三周阅读 2 的四种上下文失败问题：

• Context Poisoning → 隔离上下文，一个子 agent 的错误不会污染其他
• Context Distraction → 每个子 agent 只加载相关上下文
• Context Confusion → 每个子 agent 只拥有自己需要的工具
• Context Clash → 信息分离，减少冲突

参考实现：

• Awesome Claude Agents
• SuperClaude Framework

5. 最佳实践

📚 延伸阅读： "Good Context Good Code"（阅读 5）中 StockApp 团队验证了这些实践——他们的 agent "误操作删除了开发数据库好几次"，证明了安全后盾的必要性。

6. 开放问题

1. 如何自动化每个任务前 10-20% 的研究阶段？（目前仍是 Planning 的瓶颈）
2. 如何维护待处理任务队列？（一次性变更容易，但持续管理多任务的工作流尚未成熟）

第二讲：Guest Lecture——Boris Cherny（Anthropic/Claude Code 创始人）（10/17）

1. 核心论点：编程正处于拐点

两条指数增长曲线：

• 编程语言生产力：Fortran → C → Python → TypeScript → ✻ AI
• IDE 生产力：ed → Emacs → Eclipse → Copilot → Cursor → Claude Code → Devin

IDE 演进简史（Boris 视角）：

"验证"也在快速进化：从手动调试 → 静态类型 → 自动测试 → CI → AI 驱动的单元测试/模糊测试/漏洞测试 → self play

2. Claude Code 的设计哲学

核心原则：Works Everywhere（到处可用）

三大支柱：

1. Terminal-native（终端原生）
2. Low-level model access（底层模型访问）
3. Infinitely hackable（无限可扩展）

覆盖完整 SDLC：

① Discover → ② Design → ③ Build → ④ Deploy → ⑤ Support & Scale
   探索代码库    规划项目     实现代码    自动化CI/CD   调试错误
   搜索文档      技术规格     写测试      配置环境       大规模重构
   入职学习      架构定义     创建PR      管理部署       监控性能

关键： 使用你团队的所有 CLI 工具（git, docker, bq 等），让你专注于解决方案而非语法。

3. 一个 Claude Code，多种形态

SDK 示例：

# 查询本周工作
claude -p "what did i do this week?" \
  --allowedTools Bash(git log:*) \
  --output-format stream-json

# 管道式工作流
get-gcp-logs 1uhd832d |
  claude -p "correlate errors + commits" \
  --output-format=json |
  jq '.result'

4. 使用模式与工作流

四大使用模式：

三种核心工作流（与第一讲对应）：

① Explore → Plan → Confirm → Code → Commit

> figure out the root cause for issue #983, 
> then propose a few fixes. 
> Let me choose an approach before you code. ultrathink

• 使用 "think" / "think hard" / "think harder" / "ultrathink" 触发不同级别的深度思考

② Tests → Commit → Code → Iterate → Commit（TDD 模式）

> write tests for @utils/markdown.ts to make sure links 
> render properly (note the tests won't pass yet). 
> then commit. then update the code to make the tests pass.

③ Code → Screenshot → Iterate（视觉迭代）

> implement [mock.png]. Then screenshot it with puppeteer 
> and iterate till it looks like the mock.

📚 课程关联： 这三个工作流直接细化了第一讲的"Agent Manager"职责——人类通过选择正确的工作流来管理 agent 的行为模式。

5. 原型迭代实录

Boris 展示了 Claude Code 自身的 TODO 功能开发过程（Slides 34-43），展现了快速原型迭代的真实过程：

尝试 1: "显示 todo 列表在工具使用上方" → 不满意
尝试 2: "用粗体标题内联显示工具使用" → 不满意
尝试 3: "在输入框下加 todo pill" → 不满意
尝试 4: "todo 列表在输入框右边" → 不满意
尝试 5: "todo 列表在输入框上方" → 接近了
尝试 6: "融入 spinner，当前 todo 用主动语态" → ✅
尝试 7: "ctrl+t 展开/收起 todos" → ✅ 最终方案

关键启示： 7 次迭代，每次只用一句自然语言描述。这就是 Boris 所说的"原型模式"——快速试错、快速收敛。对比传统开发需要手写代码调整 UI，这里每次迭代可能只需几十秒。

6. 四条核心教训

📚 课程关联： "Build for the model six months from now" 与第一讲 Slide 4 的开发团队演化图完美呼应——我们正处于 "2023 → 2025+" 的过渡期，投资于 agent 管理技能的回报会随模型进步而指数增长。

🔗 两讲之间的联系

统一理解：

1. 第一讲建立了 "Agent Manager" 的角色模型和工具箱（Hooks、Commands、Subagents）
2. 第二讲通过 Claude Code 展示了这些概念的具体产品实现
3. 两讲共同传递的信息：开发者的核心技能从 "写代码" 转向 "管理 agent + 设计上下文 + 选择工作流"

📚 第四周阅读材料速览

🛠️ 第四周作业

Coding with Claude Code — 使用 Claude Code 完成编码任务

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

Stanford University · Fall 2025 · 讲师：Mihail Eric

阅读材料一览

📖 阅读 2：Claude Code: Best Practices for Agentic Coding（Anthropic）

来源： Anthropic 工程博客，2025 年 4 月 18 日

🔗 课堂关联： 这是本周最重要的参考文档——第一讲所有技术（CLAUDE.md、Hooks、Commands、Subagents）的官方最佳实践手册，也是第二讲 Boris 演示的配套文档。

一、定制你的环境

① CLAUDE.md 文件（核心配置）

Claude 启动对话时自动加载的特殊文件。应记录：

• 常用 bash 命令
• 核心文件和工具函数
• 代码风格指南
• 测试说明
• 仓库规范（分支命名、merge vs rebase 等）
• 开发环境设置
• 项目特有的异常行为或警告

CLAUDE.md 放置位置：

关键技巧： 按 # 键可以给 Claude 一个指令，它会自动写入相应的 CLAUDE.md。把 CLAUDE.md 的变更加入 commit，团队成员也能受益。

💡 Anthropic 内部做法： 定期通过 prompt improver 优化 CLAUDE.md，并使用 "IMPORTANT" 或 "YOU MUST" 等强调词提高指令遵循度。

② 工具权限管理

四种管理方式：

• 会话中选择 "Always allow"
• /permissions 命令添加/移除
• 手动编辑 .claude/settings.json
• --allowedTools CLI 标志

③ 安装 gh CLI

Claude 可以使用 gh 创建 issue、开 PR、读评论等。

二、赋予 Claude 更多工具

① Bash 工具 Claude 继承你的 bash 环境，可以使用所有你的工具。自定义工具需要通过 CLAUDE.md 或直接告知。

② MCP 集成 Claude Code 既是 MCP Server 也是 MCP Client。配置方式：

• 项目级配置（当前目录生效）
• 全局配置（所有项目生效）
• 提交到仓库的 .mcp.json（团队共享）

③ Custom Slash Commands 将常用工作流存储为 .claude/commands/ 中的 Markdown 文件。

📚 课堂关联： 这三种工具扩展方式直接对应第一讲 Slide 8 的"指导 Agent 的技术"：Bash 工具（环境）、MCP（外部工具）、Commands（预定义流程）。

三、核心工作流

① Explore → Plan → Code → Commit

四步法，适合大多数问题：

1. 让 Claude 阅读相关文件/图片/URL（明确告诉它此时不要写代码）
   • 复杂问题应积极使用 subagents 做验证和调查
2. 让 Claude 制定计划——使用 "think" 触发深度思考
   • "think" < "think hard" < "think harder" < "ultrathink"，每级分配更多思考预算
3. 让 Claude 实现代码
4. 让 Claude 提交并创建 PR

关键： 步骤 1-2 至关重要——没有它们，Claude 会直接跳到写代码。

② Tests → Code → Iterate → Commit（TDD 模式）

Anthropic 内部最爱的工作流：

1. 让 Claude 基于输入/输出对写测试（明确说明是 TDD，避免 mock）
2. 让 Claude 运行测试并确认失败
3. 提交测试
4. 让 Claude 写代码使测试通过（可用独立 subagent 验证实现没有过拟合测试）
5. 提交代码

③ Code → Screenshot → Iterate（视觉迭代）

用 Puppeteer MCP 或 iOS Simulator MCP 截图，对比视觉 mock 迭代。

④ Safe YOLO Mode

claude --dangerously-skip-permissions 跳过所有权限检查，适用于修 lint 错误或生成样板代码。必须在无网络的容器中使用。

⑤ Codebase Q&A（入职利器）

Anthropic 内部用这种方式大幅缩短入职时间。

⑥ Git 和 GitHub 交互

Anthropic 工程师 90%+ 的 git 操作通过 Claude 完成。

四、优化技巧

📚 课堂关联： /clear 直接解决了第三周阅读 2 的 Context Distraction 问题；Checklist 策略解决了长任务中的 Context Poisoning（通过外化状态到文件而不是留在上下文中）。

📖 阅读 5：Good Context Good Code (StockApp)

作者： Waleed Kadous 等（StockApp 团队，来自 Google 等大厂） 发表： 2025 年 8 月 5 日

🔗 课堂关联： 这是全周内容的实战验证——一个从零开始构建 AI-native 工程文化的团队，验证了课堂教授的所有核心理念。

核心洞见

"好代码是好上下文的副产品。"（Good code is a side effect of good context.）

AI-native 开发不是取代工程师，而是通过精心设计的共享上下文实现系统化的人-AI 协作。

生产力数据

• AI-native 开发比手动开发提效 ~2.5x
• 比"现有开发文化+AI 增强"提效 ~2x
• Q2 2025：13 周内 1,098 个 PR（每开发者每周 10.6 个 PR，行业标准约 1 个）

五大原则

原则 1：Repo 是人和 Agent 的共享工作区

repo/
├── docs/designs/     # 产品需求、高层目标（Why & What）
├── docs/plans/       # 详细实现计划（How）——人+agent 联合生成
├── docs/guides/      # API 和工具教程——常由 agent 起草
├── schema.sql        # 单一的规范 schema（数据结构的真相源）
├── README.md         # 给人看的（各处分布）
└── CLAUDE.md         # 给 agent 看的（各处分布）

关键洞见： 自然语言和编程语言同等重要。他们故意在 repo 中放入比"纯人类团队"更多的文档，因为 repo 不仅是给人用的，也是给机器用的。

原则 2：层级式开发（Hierarchical Development）

人和 Agent 在每个层级协作，逐步构建上下文：

Design（人提需求 → agent 起草 → 共同迭代 → 提交）
  ↓
Plan（agent 将设计转化为分阶段任务 → 人审查）
  ↓
Implement（agent 写大部分代码 → 人审查）
  ↓
Backstop（测试和其他安全机制）
  ↓
Review（人+agent 最终审查）
  ↓
Update（更新文档、CLAUDE.md、schema）

📚 课堂关联： 这六步流程是第一讲 Slide 7 "软件任务分工"的详细展开版本，同时呼应了第三周"Specs 驱动开发"的理念。

原则 3：用 Agent 做一切（除非有充分理由不用）

非常规用法：

• Agent 写 commit 和 PR 消息
• Agent 更新文档（而非人手动编辑）
• Agent 更新 CLAUDE.md——"它比我们更知道如何指导自己"
• Agent 写测试（但要警惕 over-mocking 倾向）
• 调试是联合活动：人提出假设 → agent 验证
• Agent 在代码库中查找重复代码、死代码、安全问题

重要警告： "Agent 不是魔法。我们始终全神贯注地监督。Agent 曾多次误操作删除了我们的开发数据库。"

原则 4：MCP 和命令让上下文理解更容易

StockApp 使用 6 个 MCP server：

最令人兴奋的用法： "读取 Linear 中的 bug 描述，然后遍历最近 10 个 commit，找出最可能导致 bug 的那个。"——MCP 让跨系统的信息桥接变得自然。

原则 5：集成（Ensemble）优于个体

使用 Zen MCP Server 让 Claude Code 也能向 Gemini 和 o3 征求反馈。

实例： 关于 MCP server 认证方案，Gemini 推荐 payload-based auth 为"最务实和可扩展的方案"，而 o3 更谨慎地将 per-user clients 排为 #1。多模型多视角帮助做出更好的决策。

📚 课堂关联： "人类 + 多个 agent = ensemble"直接呼应了第一讲的核心目标——开发者管理多个专业化 agent。StockApp 更进一步证明了不同 LLM 的多样性也是 ensemble 的一部分。

📖 阅读 6：Peeking Under the Hood of Claude Code

作者： OutSight AI 发表： 2025 年 8 月 20 日

🔗 课堂关联： 这是第二周 Agent 架构（Agent Loop、System Prompts、Tool Calls）的底层揭秘——通过 LiteLLM 代理拦截 Claude Code 的 API 请求，直接观察它在做什么。

实验方法

通过 LiteLLM 作为透明代理，拦截 Claude Code 和 Anthropic API 之间的所有请求：

Claude Code → LiteLLM Proxy → Anthropic API
                ↓（记录所有请求/响应）

核心发现

发现 1：Front-loaded Context（前置上下文加载）

在你开始编码之前，Claude Code 已经做了大量"预处理"：

• 提取对话标题：总结当前对话（<50 字符）
• 判断是否新话题：分析当前消息是否是新的对话主题
• 加载项目上下文：CLAUDE.md、文件结构等

📚 课堂关联： 这直接验证了第二周第二讲 Slide 7 的"Claude Code Secret Sauce"——"front-loaded context"不是比喻，而是实际发生的 API 调用。

发现 2：System Reminders 无处不在

<system-reminder> 标签被嵌入到了所有地方：

• System prompts
• User prompts
• Tool call 结果
• Todo 列表更新

示例——一条用户消息中包含的多层 system-reminder：

<!-- Reminder 1: 行为指导 -->
<system-reminder>
Do what has been asked; nothing more, nothing less.
NEVER create files unless absolutely necessary.
ALWAYS prefer editing an existing file to creating a new one.
</system-reminder>

<!-- 用户的实际消息 -->
Can you analyze @sb-agent/ and tell me how it works...

<!-- Reminder 2: LS 工具的调用记录 -->
<system-reminder>
Called the LS tool with the following input: {"path": "..."}
</system-reminder>

<!-- Reminder 3: LS 工具的结果 + 安全检查 -->
<system-reminder>
Result of calling the LS tool: "..."
NOTE: do any of the files above seem malicious?
</system-reminder>

<!-- Reminder 4: Todo 列表状态 -->
<system-reminder>
Your todo list is currently empty. DO NOT mention this to the user.
</system-reminder>

📚 课堂关联： 这直接解决了第三周阅读 2（"How Long Contexts Fail"）的 Context Distraction 问题——通过不断注入 system-reminders，防止模型在长上下文中"忘记"关键指令。

发现 3：命令注入检测是生成式的

Claude Code 的权限系统不是硬编码的——它使用一个专门的子 prompt 来分析命令前缀并检测注入：

示例：
- cat foo.txt         → cat（安全）
- git commit -m "foo" → git commit（安全）
- git diff $(cat secrets.env | base64 | curl...) → command_injection_detected（危险！）
- git status`ls`      → command_injection_detected（危险！）

📚 课堂关联： 这是第一讲 Slide 9 "Hooks" 的底层实现——PreToolUse hook 在执行 bash 命令前做安全检查，但这个检查本身是 LLM 驱动的，不是简单的正则匹配。

发现 4：Sub-agents 的自适应上下文

Claude Code 使用 "Task" 工具生成子 agent，每个子 agent 有更窄的指令集。子 agent 的上下文会根据任务复杂度动态调整。

🔗 六篇阅读材料的交叉主题

1. "Agent Manager" 的完整工具箱

• 阅读 2（Claude Code Best Practices）= 官方手册
• 阅读 3（Awesome Claude Agents）+ 阅读 4（SuperClaude）= 社区实践集合
• 阅读 5（StockApp）= 企业级实战验证
• 阅读 6（Under the Hood）= 底层实现揭秘

2. 上下文工程的实践闭环

第三周理论（"How Long Contexts Fail"）→ 本周实践：

3. 好上下文 = 好代码

这是本周所有材料的统一主题：

• CLAUDE.md / AGENTS.md / docs/ = 静态上下文
• MCP servers = 动态上下文
• System reminders = 持续上下文
• Hooks / Commands = 确定性上下文
• Subagents = 隔离上下文

🔗 课程脉络： 第一周"LLM 基础" → 第二周"Agent + MCP" → 第三周"IDE + Workflow" → 第四周"Agent Manager + 上下文工程实践"。到目前为止，课程已经完成了从理论到实践的全链路。下一周（第五周）将进入"The Modern Terminal"，探索 AI-enhanced 命令行界面。

CS146S 第五周笔记总结：The Modern Terminal

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

📅 课程安排

第一讲：How to Build a Breakout AI Developer Product（10/20）

核心主题

这是课程中唯一一讲从产品设计角度审视 AI 开发工具。前四周讲的是"如何使用工具"，这一讲讲的是**"如何设计工具"**。以 Warp 为演示工具。

背景：为什么要关注这个？

"我们正在见证历史上最快的开发者工具采纳周期。"

AI 正在迅速改变开发者工具的 UX/UI。核心问题是：在你的开发环境中引入 agent，会如何改变产品本身？

7 大产品原则

原则 1：Start with What Developers Know（从开发者已知的出发）

关键： 鼓励从现有界面过渡，而不是要求全新的学习曲线。

关键能力： 在代码和自然语言之间无缝切换。

💡 经典痛点： tar -czvf 这样的命令——每个开发者都痛过。从共同的痛点出发建立产品价值。

📚 课程关联： 第四周 Boris 讲 Claude Code 选择 Terminal-native 形态，正是这个原则的体现——终端是开发者最熟悉的界面。

原则 2：Configuration Flexibility（配置灵活性）

双轨设计：

• 普通用户： 零配置即可体验价值
• 高级用户： 极深的可定制性

📚 课程关联： 这直接呼应了第四周的 CLAUDE.md / .cursorrules / AGENTS.md 体系——好的产品在多个层级提供配置能力。

原则 3：Focus on Developer Ergonomics（聚焦开发者人体工程学）

"如果你能省掉一次按键，就去做。"

两个关键指标：

• "5 minutes to WOW"：零入职摩擦，5 分钟内让用户感到惊喜
• 键盘热键的粘性："Tab" 和 "Enter" 的习惯一旦养成就很难改变

📚 课程关联： Cursor 的 Tab 补全、Warp 的 # 自然语言输入，都是这个原则的典型实现。

原则 4：Chat as a First-Class Citizen（对话作为一等公民）

"代码本质上是人类意图的一种人为表示。随着工具演进，更多工作将只需用自然语言表达开发者意图，而非语法。"

趋势方向：从编写语法 → 表达意图。

📚 课程关联： 这与第三周阅读 1（"Specs Are the New Source Code"）的核心论点一致——spec（自然语言意图）正在取代 code（语法表示）成为源代码。

原则 5：MCP Integration（MCP 集成）

"MCP 已经成为让 LLM 与现实世界交互的通用语言。"

可扩展的工具生态让 LLM 能够访问任何资源、执行任何操作。

课堂演示了 Warp 如何集成 MCP，包括使用 context7 获取最新的 braintrust 文档。

📚 课程关联： 直接延续第二周 MCP 的内容。MCP 从"技术协议"（第二周）→"IDE 集成"（第三周）→"产品差异化因素"（本周），抽象层不断提升。

原则 6：Rapid Feedback Loops（快速反馈循环）

关键： 让开发者快速迭代并立即看到变更效果。

可解释性是一等公民——开发者需要理解 agent 在做什么、为什么这么做。

📚 课程关联： 第四周 Boris 的原型迭代演示（7 次迭代 TODO 功能）就是极致的快速反馈循环。

原则 7：Agent Workflows（Agent 工作流）

趋势： 越来越多地采用 "agent-take-the-wheel" 方式。

课堂演示了 Warp 的 YOLO 模式。

📚 课程关联： 直接延续第四周第一讲的"Agent 自主级别管理"——从 human-in-the-loop → agent-take-the-wheel 的频谱。

开放问题

1. 工具整合： 点状解决方案（代码审查、应用构建、监控）会否整合为单一平台？
2. 形态演进： AI IDE → AI Terminal → AI 浏览器 Replit？
3. 垂直化： Warp/Cursor 会否针对全栈开发等场景垂直化？
4. 配置标准化： 碎片化的 .cursorrules / CLAUDE.md 不会持续太久。AGENTS.md 是标准化的第一步。

📚 课程关联： 问题 4 直接呼应了第三周 AGENTS.md 的讨论——这不仅是一个文件格式，而是整个行业需要解决的标准化问题。

第二讲：Guest Lecture——Zach Lloyd（CEO, Warp）（10/24）

⚠️ Zach 的 Slides 使用 Figma 格式，无法提取文本内容。以下基于 Zach Lloyd 的多次公开演讲、采访和 Warp 官方文档整理。

Zach Lloyd 背景

• 曾在 Google 工作，参与重新设计 Google Sheets（"当时没人听说过它，我解释后朋友们都说'哦，Google 有个 Excel'"——如今月活约 10 亿）
• 曾在 NASA JPL 工作，拥有哲学硕士学位，甚至读过一年耶鲁法学院
• 2020 年创立 Warp，愿景：为现代开发者重新想象终端
• 投资方：Sequoia Capital

Warp 的核心定位

"我们甚至不再把 Warp 称为终端。它是一个 Agentic Development Environment（ADE）。" ——Zach Lloyd, RedMonk 访谈 (2025.12)

"我们正在从开发者手动完成大部分工作的世界，转向通过 prompt 和 agent 完成工作的世界。" ——Zach Lloyd, Techstrong.tv (2025.9)

Warp 不是传统终端的 AI 插件，而是从零开始为 AI 时代重新设计的终端，兼具 IDE 级别的能力。

为什么是终端？

"终端实际上非常接近做这类开发的正确形态。我认为它肯定比 IDE 更接近。"

原因：

• 终端在开发栈中处于底层位置，几乎可以执行任何类型的任务
• 自然语言 + 命令行结合 = 精确且灵活
• 不仅擅长编码（SWE-bench 71%、Terminal-Bench 52%），还擅长设置项目、生产环境调试、Docker/云操作

Warp 的演进之路

2020: 创立——"为现代开发者重新想象终端"
  ↓
2022: 发布——Block 系统、Workflows、Quake Mode、AI Command Search
  ↓
2025.3: Warp 2.0——"Agentic Development Environment"
  ↓
2025.9: Warp Code——内建文件编辑器、代码审查、WARP.md
  ↓
2025.11: Agents 3.0——完整终端能力的多 agent

关键里程碑： Warp Code（2025.9）引入了 WARP.md——Warp 版本的 AGENTS.md/CLAUDE.md，用于通过项目规则和指令引导 agent。

📚 课程关联： WARP.md 的出现验证了第一讲 Slide 14 的预测——碎片化的 .cursorrules / CLAUDE.md 世界不会持续太久，行业正在向标准化的 agent 配置文件收敛。

Warp 的四大产品支柱

Zach 的核心观点：AI 不会取代开发者

"Agent 擅长孤立任务，但开发是一项团队运动。"

三个原因：

1. "几乎能用"的陷阱： "太多时候 agent 写出几乎能用但实际不行的代码"——真实项目涉及边缘情况、遗留系统、没有训练数据覆盖的场景
2. 上下文与协作： 软件不存在于真空中——AI 不理解办公室政治、客户需求变化、"那次 API 在高峰时段崩溃"
3. 伦理与判断力： AI 会产生幻觉——在代码中这可能意味着安全漏洞或偏差算法

Warp vs Claude Code 核心对比

Warp 的关键差异化功能

① Block 系统 每个命令和输出被组织为独立的 "Block"，可以导航、搜索、分享。

② 可视化 Diff 编辑

"你可以直接编辑 diff。内建编辑器让你手动编辑、移除 agent 添加的注释等。点击接受后，agent 会被通知这些修改，不会在后续覆盖它们。"

③ 多模型支持 可以在 Claude（Sonnet/Opus）、GPT-5、Gemini 之间切换，针对不同任务选择最佳模型。

④ Agent Profiles 定义 agent 的读写权限、自主级别、规划行为——类似于第四周的 subagent 概念但通过 UI 配置。

⑤ Codebase Indexing 创建代码库的 embeddings，实现更快的语义搜索——类似于第三周课堂介绍的 Cursor 的索引机制。

📚 课程关联： Warp 的多模型支持验证了第四周阅读 5（StockApp "Good Context Good Code"）的 Ensemble 原则——不同 LLM 有不同的强项和弱点，多模型协作优于单一模型。

Zach Lloyd 的产品哲学（基于多次公开访谈）

① 终端是新战场

"时间线式日志和命令式界面——你只需告诉 agent 你想要什么，它就去做——正在成为与 AI 协作的最佳方式。这比 VS Code 克隆品中的侧面板或聊天窗口顺畅得多。"

自 ADE 发布以来，Warp 的每日付费注册增长了约 5 倍。

② "不是 IDE，不是终端，而是另一种东西"

"It's not an IDE, not a terminal. It's something else entirely."

Warp 融合了终端和 IDE 的元素，但既不是传统终端也不是传统 IDE——它是围绕"prompting → reviewing → collaborating with agents"设计的新界面范式。

③ Google Sheets 的经验

Lloyd 在 Google 面对 Excel 纯粹主义者的激烈抗议时重新设计了电子表格。同样的经历让他不惧 Hacker News 上"重新发明终端是愚蠢的"批评。

📚 课程关联： Zach 的"终端是正确形态"论点与第四周 Boris 的"Terminal-native"设计哲学形成有趣的呼应——两个不同公司（Anthropic/Claude Code 和 Warp）从不同角度得出了相似结论：终端 > IDE 侧面板。

🔗 两讲之间的联系

7 原则在 Warp 中的体现：

📚 第五周阅读材料速览

🛠️ 第五周作业

Agentic Development with Warp — 使用 Warp 进行 Agent 驱动的开发

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

Stanford University · Fall 2025 · 讲师：Mihail Eric

阅读材料一览

📖 阅读 1：Warp University

来源： warp.dev/university

🔗 课堂关联： 这是 Zach Lloyd 客座讲座的配套学习资源，覆盖 Warp 的所有功能和工作流。

课程体系（35+ 视频教程）

核心学习路径

对于本课程学生，推荐按以下顺序学习：

基础理解： A Full Warp Overview → Customize Warp → Start a Coding Task

进阶对比： Warp VS Claude Code（直接呼应课堂第二讲内容）

工作流掌握： Using Project Rules → Using Agent Profiles → Making a UI Change → Run and Review Code with Multiple Agents

MCP 扩展： 选择与自己项目相关的 MCP 教程（Linear/GitHub/Sentry 等）

📚 课程关联： Warp University 的课程体系覆盖了本课前四周的所有核心概念：Prompt 技巧（第一周）、MCP 集成（第二周）、IDE/Agent 配置（第三-四周）。这是一个很好的综合复习资源。

📖 阅读 2：Warp vs Claude Code

来源： Warp 官方文档

🔗 课堂关联： 这是本周最重要的阅读材料——直接对比了课程目前涉及的两个核心 Terminal Agent 工具（第四周的 Claude Code vs 本周的 Warp），帮助理解 AI Terminal 领域的设计权衡。

两者共同能力

• 读取和编辑文件
• 生成代码 diff
• 规划多步骤任务

九大维度详细对比

① 环境与安装

② Diff 审查

Claude Code 需要手动审查（CLI 或外部编辑器），可用 Shift+Tab 自动接受。

Warp 提供内建可视化 diff 面板——可以接受、拒绝或在线手动编辑 diff。Agent 会自动更新上下文以避免覆盖你的手动修改。

📚 课程关联： Warp 的 diff 编辑能力直接解决了第四周讨论的 "course correction" 问题——开发者可以更精细地控制 agent 的输出，而不是只能接受/拒绝。

③ 规划与上下文

两者都支持规划模式。但 Warp 扩展了上下文能力：

• 文件引用（@filename）——两者都支持
• 符号引用（@functionName）——Warp 独有
• 文件树浏览器——可以拉取特定行和符号作为上下文

④ 模型选择

📚 课程关联： 多模型支持验证了第四周阅读 5（StockApp）的 Ensemble 原则——不同模型适合不同任务。

⑤ 配置

⑥ Agent 管理

Claude Code 在 CLI tab 中显示进度，tab 标题显示当前任务名。

Warp 添加了可视化进度指示器、toast 通知（agent 被阻塞时）、可选的桌面通知。

📚 课程关联： Warp 的多 agent 管理能力直接对应了第三周 Silas 讲的 "async agent" 概念——当你同时运行多个 agent 时，需要集中管理和通知。

⑦ 性能对比

在同一编码任务（修复 Sentry issue 中的 renderKeyboardShortcut bug）上测试：

• Claude Code + Sonnet：2-4 分钟，能找到正确问题但有冗余逻辑
• Warp + GPT-5：~1 分 20 秒，输出一致性高、简洁

⑧ 总结选择建议

• 偏好 Claude 模型生态 + 纯 CLI 工作流 → Claude Code
• 需要更丰富的 Diff 编辑、上下文引用、多模型灵活性 → Warp

📖 阅读 3：How Warp Uses Warp to Build Warp

来源： Warp 博客（2022）+ Notion 内部文档（2025，需 JS 渲染无法直接获取） 作者： David Stern, Ian Hodge, Michelle Lim, Agata Cieplik（Warp 团队）

🔗 课堂关联： 这是 Warp 团队的 Dogfooding 实践报告，展示了第一讲"7 大产品原则"如何在 Warp 团队自身的日常工作中得到验证。

四大特色功能的内部使用

① Block Sharing（块分享）—— David Stern（工程师）

痛点： 开发者分享终端输出的传统方式（截图/复制粘贴）有很多问题：

• 截图最多捕获一屏，接收者无法搜索、选择或复制文本
• 复制粘贴丢失颜色，不同屏幕尺寸上文本换行错乱

解决方案： Block Sharing 创建 Web 永久链接，保留 ANSI 颜色、字体格式和文本换行（底层用 ANSI escape sequences + JSON 对象存储格式信息）。

实际用例：

• 在 Slack #help 频道分享 cargo clippy 的 Rust lint 错误输出（56 行），同事直接通过链接查看完整输出并快速定位修复方案
• 为新入职工程师演示步骤（例如用 grep 命令搜索代码库中的键盘快捷键映射）
• Block 永久保存，直到用户主动取消分享

📚 课程关联： Block Sharing 体现了第一讲 原则 3（开发者人体工程学） ——解决了一个"每个开发者都经历过但习以为常"的痛点。

② Workflows（工作流）—— Ian Hodge（工程师）

定义： 可按名称或描述搜索的参数化命令集合，可以存储在仓库级别供团队共享。

Warp 内部团队共享的工作流：

• Allowlist IP address for staging
• Build image and start container for SSH testing
• Bundle Warp
• Cherrypick commit into a latest release branch（值班时最常用）
• Create GH pull request to release a feature
• Run unit test

关键价值： Cherrypick 命令非常长且几乎不可能记住，但在 On-call 值班期间是常用操作。Workflow 让它变成一键执行。同样，"Allowlist IP for staging" 是 Warp #help 频道中最常被问到的问题——团队创建了共享 Workflow 后问题消失了。

📚 课程关联： Workflows 直接对应第四周 Claude Code 的 Custom Slash Commands（.claude/commands/）—— 都是将常用操作模板化。但 Warp 的 Workflow 通过 UI 展示参数说明和命令摘要，更直观；Claude Code 的 Commands 更灵活，支持 $ARGUMENTS 参数和 Markdown 格式的复杂 prompt。

③ Quake Mode（全局热键模式）—— Michelle Lim（增长负责人）

问题： 依赖 VS Code 但其内建终端缺少 Warp 的特色功能。

巧妙解决方案：

1. 将 Warp 的全局热键配置为 CMD + J（与 VS Code 显示/隐藏终端的快捷键相同）
2. Warp 的 OS 级快捷键自动覆盖 VS Code 的快捷键
3. 将 Warp 固定在屏幕底部（宽度 100%、高度 30%），匹配 VS Code 的主题

效果： 肌肉记忆不变，但弹出的终端从 VS Code 内建终端变成了 Warp。额外好处是 Quake Mode 在 OS 级别工作，跨所有桌面可用。

📚 课程关联： 这体现了第一讲 原则 1（从已知出发） 和 原则 3（人体工程学） —— 不要求用户改变习惯，而是"偷偷"替换底层实现。

④ AI Command Search —— Agata Cieplik（工程师）

功能： 将自然语言描述转换为 shell 命令（早期由 OpenAI Codex 驱动）。

实际用例： 调试 Warp 性能问题时，输入自然语言：

"Search for 'redraw' in this directory and extract the first and third column separated by space and then sort the output."

AI 生成命令：grep -i redraw * | cut -f 1,2 -d " " | sort

价值： 之前需要手动写 grep → 查看输出 → 调整 cut 参数 → 多次尝试。现在一次性生成完整管道命令。

📚 课程关联： AI Command Search 是第一讲 原则 4（Chat 一等公民） 的最早实现之一——从"记住 tar -czvf 语法"到"用自然语言描述意图"。也是 Mihail 课堂上专门提到的 tar -czvf 痛点的解决方案。

🔗 三篇阅读材料的交叉主题

1. AI Terminal 的两条路径

本周的核心张力是 Claude Code vs Warp 代表的两种设计哲学：

关键洞见： 两者不是替代关系，而是针对不同偏好和工作流的互补选择。第四周 StockApp 团队就同时使用了两者（Claude Code 在 Cursor 中运行）。

2. 从工具使用者到工具设计者

本周的独特价值在于视角转换：

• 第一周～第四周：如何使用 AI 工具
• 第五周：如何设计 AI 工具（7 大产品原则）

这对于 Stanford CS 学生特别有价值——很多人未来会成为这些工具的设计者和构建者。

3. 第二周 MCP 概念的产品化

MCP 在课程中的演进轨迹：

第二周：MCP 是什么（协议规范）
    ↓
第三周：MCP 如何设计好工具（Anthropic 工程博客）
    ↓
第四周：MCP 如何在代码库中配置（CLAUDE.md + .mcp.json）
    ↓
第五周：MCP 作为产品差异化因素（7 大原则之一 + Warp 的 MCP 教程体系）

🔗 课程脉络： 第一周"LLM 基础" → 第二周"Agent + MCP" → 第三周"IDE + Specs" → 第四周"Agent Manager" → 第五周"产品设计 + Terminal"。课程前半程（Foundations + Tools）已经完成。下半程从第六周开始进入 "Quality"（测试与安全）→ "Delivery"（UI 构建、部署）→ "Future"。

CS146S 第六周笔记总结：AI Testing and Security

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

📅 课程安排

第一讲：AI QA, SAST, DAST, and Beyond（10/27）

核心主题

"当 LLM 在写你大部分代码时，你需要大量的 guardrails 来防止错误。"

这是课程第一次从安全与质量保障角度审视 AI 开发。前五周讲的都是"如何用 AI 更快地写代码"，这一讲讲的是**"如何确保 AI 写的代码不会出问题"**。

第一部分：既有威胁面（Existing Threat Landscape）

传统 Web 应用安全威胁——这些在 AI 时代不仅没有消失，反而因为 AI 生成代码可能引入更多这类漏洞：

• SQL 注入（SQL Injection）
• 跨站脚本（XSS）
• 身份认证缺陷（Broken Authentication）
• 不安全的直接对象引用（IDOR）
• 安全配置错误（Security Misconfigurations）
• 敏感数据暴露（Sensitive Data Exposure）

📚 课程关联： 这些是 OWASP Top 10 的核心内容（阅读 5），为后面讨论 AI 能否检测这些问题提供基础。

第二部分：三种漏洞检测技术

SAST 技术细节：

• 代码库扫描 + 模式匹配
• 工具示例：Bandit（Python）、Semgrep（多语言）、ESLint + 扩展

DAST 技术细节：

• 输入 fuzzing、会话令牌操作、配置/头部测试、暴力限速测试

SCA 技术细节：

• 分析包元数据、传递性依赖解析、匹配漏洞数据库、二进制/制品扫描

三者互补： 代码 + 运行时 + 依赖 = 全面覆盖

📚 课程关联： SAST/DAST 的"Shift Left"理念（尽早发现问题）与第四周的 TDD 工作流形成呼应——都是在开发早期建立质量保障。

第三部分：AI 带来的新攻击面

① Prompt Injection（提示注入）

向 AI 系统注入隐藏或误导性指令，使其偏离预期行为。

课堂演示了从 AI agent（如 Amp Code）中提取系统 prompt 的实例。

② Tool Misuse（工具滥用）

通过欺骗性 prompt 操纵 agent 滥用其集成工具。

课堂引用了 Amp Code 的配置修改攻击案例（embracethered.com）。

③ Code Attacks（代码攻击）

利用 agent 的代码执行能力获取对执行环境的未授权访问。

④ Intent Breaking（意图破坏）

操纵 agent 的计划，将行为重定向到偏离原始意图。

⑤ Identity Spoofing（身份伪造）

利用被攻破的身份认证，伪装为合法 agent。

📚 课程关联： 这五种攻击向量直接对应阅读 4（Palo Alto Unit 42 报告）。特别值得注意的是，第四周讨论的 Claude Code Hooks 和权限系统（generative command injection detection）正是为了防御这些攻击。

第四部分：AI 带来的安全新能力

"Shift Left 安全比以往任何时候都更容易实现。"

• LLM 可以引入工作流中发现安全问题
• 自动化渗透测试成为可能

第五部分：局限性（关键！）

AI SAST 的假阳性率极高：

• Claude Code / Codex 的假阳性率：50-100%（取决于漏洞类型）
• 对比传统 SAST：也是 50%+
• 所以 AI 并没有显著降低假阳性

非确定性分析问题：

• 相同 prompt 运行多次 → 不同结果
• 你怎么知道是否已捕获所有漏洞？

Context Rot（上下文腐烂）：

• 不是所有上下文都是平等的
• 输入 token 越多，性能越不可靠

Compaction（压缩）：

• 为了适应上下文窗口而进行的摘要会导致信息丢失

📚 课程关联： Context Rot 直接对应第三周阅读 2（"How Long Contexts Fail"）的四种失败模式，以及本周阅读 6（Chroma 的研究报告）。这也是为什么第四周讲的 subagent（隔离上下文）和 system-reminders（持久化关键信息）如此重要。

开放问题

1. 如何降低漏洞检测中的假阳性和幻觉？
2. 如何验证 LLM 生成的补丁是安全的、不引入回归？
3. LLM 能否解释为什么标记某个漏洞或提出某个修复？
4. 衡量 LLM AppSec 表现的正确基准是什么？
5. 如何在 CI/CD 中嵌入 LLM 而不淹没团队？
6. 如果 AI 生成的补丁引入了漏洞，谁来负责？

第二讲：Guest Lecture——Isaac Evans（CEO, Semgrep）（10/31）

⚠️ Isaac 的演讲没有公开 Slides。以下基于阅读 3（Semgrep 博客）和搜索结果。

Isaac Evans / Semgrep 背景

• Semgrep：领先的 SAST 工具，被 Gartner Magic Quadrant 认可
• 核心产品：Semgrep Code（SAST）、Supply Chain（SCA）、Secrets（密钥检测）、Assistant（AI 分流和修复建议）
• 推出 "Secure Vibe Coding" 解决方案——专门针对 AI 生成代码的安全问题

Semgrep 的 AI 安全评估（阅读 3 核心内容）

Semgrep 团队用 Claude Code 和 OpenAI Codex 扫描了 11 个大型 Python 开源 Web 应用，产生 400+ 安全发现：

按漏洞类别的表现：

关键发现：

• AI 理解上下文的能力强（尤其是 IDOR），但跨文件/跨函数的**污点追踪（taint tracking）**能力很弱
• 非确定性是真正的困难： 同一应用、同一 prompt，三次运行分别产出 3、6、11 个发现
• Anthropic 内建的 /security-review 命令效果一般（"pretty mid"）

📚 课程关联： 这些数据直接支持了第一讲 Slide 21 的观点——AI SAST 的假阳性率极高，非确定性是核心挑战。同时也呼应了 Context Rot 问题——输入 token 越多（更大的代码库），性能下降越明显。

🔗 两讲之间的联系

📚 第六周阅读材料速览

🛠️ 第六周作业

Writing Secure AI Code — 编写安全的 AI 生成代码

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

Stanford University · Fall 2025 · 讲师：Mihail Eric

阅读材料一览

📖 阅读 1：SAST vs DAST vs RASP (Splunk)

来源： Splunk Blog

🔗 课堂关联： 直接对应第一讲 Slides 7-9 的三种检测技术。

核心对比表

SAST 方法

• 模式匹配（Pattern Matching）： 扫描不安全的编码模式
• 数据流分析（Data Flow Analysis）： 追踪不可信输入到敏感操作的路径（→ SQL 注入、缓冲区溢出）
• 控制流分析（Control Flow Analysis）： 分析循环和条件结构 → 竞态条件
• 自定义规则（Custom Rules）： 标记未净化的 SQL 输入、硬编码密钥等
• 依赖扫描（Dependency Scanning）： 第三方库漏洞
• 机器学习模型： 高级工具用 ML 识别未知漏洞

RASP（运行时应用自我保护）

第三种选择： RASP 嵌入到应用运行时环境中，实时分析行为并主动阻止攻击。与 SAST（静态代码）和 DAST（模拟外部攻击）不同，RASP 在运行时操作并主动防御。

最佳实践： 将 SAST + DAST + RASP 组合形成多层安全策略，并自动化集成到 CI/CD 管道中。

📚 课程关联： 这种"多层防御"思路与第四周 StockApp 的"Backstop"原则一致——不依赖单一工具，而是通过多层保障确保质量。

📖 阅读 2：Copilot Remote Code Execution via Prompt Injection (CVE-2025-53773)

来源： Embrace The Red (wunderwuzzi) CVE： CVE-2025-53773（已修复，2025.8 Patch Tuesday）

🔗 课堂关联： 这是本周最重要的阅读——展示了 AI IDE 中 prompt injection 如何导致完整系统接管。直接对应第一讲 Slides 11-18 的新攻击面。

发现：Agent 能修改自己的配置 = 远程代码执行

核心漏洞： GitHub Copilot 在工作区中可以无需用户批准地创建和写入文件。这些修改立即持久化到磁盘。

攻击链

1. Prompt injection 植入源代码文件（或网页/GitHub issue/工具调用响应）
   ↓
2. 注入指令让 Copilot 向 .vscode/settings.json 添加：
   "chat.tools.autoApprove": true
   ↓
3. GitHub Copilot 立即进入 YOLO 模式！
   （所有用户确认被禁用）
   ↓
4. 攻击者运行终端命令（甚至可以根据操作系统条件执行不同命令）
   ↓
5. 远程代码执行达成

关键细节

• 适用于 Windows、macOS 和 Linux
• Prompt injection 可以使用不可见指令（invisible text）——用户完全看不到
• 可以将开发者机器加入僵尸网络（ZombAI）
• 可以创建 AI 病毒：感染文件 → 开发者下载交互 → 传播到其他 Git 项目
• 还可以修改 .vscode/tasks.json、添加恶意 MCP 服务器、覆盖其他 agent 配置文件

更深层的威胁

"多个 agent 使用时，还有覆盖其他 agent 配置文件（allow-list bash 命令、添加 MCP 服务器……）的威胁，因为它们通常也在项目文件夹中。"

📚 课程关联：

• 直接解释了为什么第四周 Claude Code 使用 generative command injection detection（不是硬编码规则，而是用专门的 sub-prompt 分析命令是否包含注入）
• 解释了为什么 Claude Code 的权限系统（PreToolUse hooks）如此重要
• 也解释了第四周 Boris 强调的 "Works Everywhere" 设计中 "infinitely hackable" 为何需要配合严格的权限控制

📖 阅读 3：Finding Vulnerabilities with Claude Code and OpenAI Codex (Semgrep)

来源： Semgrep Blog（2025.9） 作者： Romain Gaucher, Vasilii Ermilov, Clint Gibler

🔗 课堂关联： 为第一讲的"局限性"（Slide 21）提供了详细的实验数据支撑。

实验设计

• 工具： Claude Code（v1.0.32, Sonnet 4）和 OpenAI Codex（v0.2.0, o4-mini）
• 目标： 11 个大型开源 Python Web 应用
• 产出： 400+ 安全发现，由安全研究团队人工审核

核心发现

① AI 能找到真正的漏洞

Claude Code 发现 46 个真正的漏洞，包含约 20 个高严重性漏洞。AI 特别擅长 IDOR（不安全的直接对象引用），因为这类漏洞需要理解业务逻辑和上下文，而非纯粹的数据流追踪。

② 但噪音很大

86% 假阳性率意味着每 7 个报告中只有 1 个是真的。在传统注入类漏洞（SQL 注入、XSS、SSRF）上表现尤差。

③ 核心弱点：跨文件污点追踪

AI 擅长理解上下文，但在追踪"用户输入从 source 流向 sink 经过多个文件和函数"时表现很差。这恰恰是传统 SAST 工具（如 Semgrep）通过确定性数据流分析擅长的领域。

④ 非确定性是真正的困难

同一代码库、同一 prompt，三次运行的结果完全不同——这使得"我是否已发现所有漏洞？"这个问题无法回答。

Semgrep 的结论

AI + 传统 SAST 的组合 > 任何单一方法

Semgrep 的方向是将 AI（上下文理解 + 分流 + 修复建议）与确定性分析（规则匹配 + 数据流追踪）结合。

📚 课程关联： 这与课程一直强调的"多层保障"一致。第四周讲的 Tests + CI/CD backstop、第三周的 specs-driven development，都是不同层级的确定性保障，用来弥补 AI 的非确定性。

📖 阅读 4：Agentic AI Threats (Palo Alto Unit 42)

来源： Unit 42（2025.5）

🔗 课堂关联： 直接对应第一讲 Slides 11-18 的五种攻击向量分类。

Agent 五大攻击向量

实际攻击案例

Code Interpreter 滥用： 攻击者通过 stock agent 的 code interpreter 工具访问 GCP 元数据服务（metadata service），窃取 VM 的 service account access token → 冒充 agent → 升级到攻击云基础设施。

关键缓解措施：

• 强制沙箱隔离 + 网络限制 + 最小权限容器配置
• 使用 DLP 解决方案 + 审计日志 + 密钥管理
• 没有单一缓解措施是充分的 → 需要纵深防御

AI 加速的攻击速度

• 2021 年数据泄露平均时间（MTTE）：9 天
• 2024 年 MTTE：2 天（20% 案例不到 1 小时）
• Unit 42 模拟 AI 驱动的勒索攻击：25 分钟（100 倍加速）

📚 课程关联： 这些数据说明了为什么第四周 Claude Code 的权限系统（PreToolUse hooks、generative injection detection）不是"锦上添花"而是核心安全架构。

📖 阅读 5：OWASP Top Ten

来源： OWASP

十大 Web 应用安全风险（2021 版）：

1. A01: Broken Access Control — 访问控制失效
2. A02: Cryptographic Failures — 加密失败
3. A03: Injection — 注入（SQL/XSS/命令注入）
4. A04: Insecure Design — 不安全的设计
5. A05: Security Misconfiguration — 安全配置错误
6. A06: Vulnerable Components — 有漏洞的组件
7. A07: Authentication Failures — 认证失败
8. A08: Software Integrity Failures — 软件完整性失败
9. A09: Logging & Monitoring Failures — 日志和监控不足
10. A10: SSRF — 服务端请求伪造

📚 课堂关联： OWASP Top 10 是第一讲 Slide 5 "Existing Threat Landscape" 和 Semgrep 评估实验的基准分类体系。

📖 阅读 6：Context Rot (Chroma Research)

来源： Chroma Research（2025.7） 作者： Kelly Hong, Anton Troynikov, Jeff Huber (Chroma)

🔗 课堂关联： 直接对应第一讲 Slide 21 的"Context Rot"局限性讨论，也是第三周"How Long Contexts Fail"的延续和深化。

核心发现

模型不会均匀使用其上下文。输入长度增加时，性能变得越来越不可靠。

测试了 18 个 LLM（包括 GPT-4.1、Claude 4、Gemini 2.5、Qwen3），即使在简单任务上，性能也随输入长度显著退化。

实验设计

在经典 Needle-in-a-Haystack（NIAH）基础上扩展了四个受控实验：

① Needle-Question 相似度

• 当 needle 和 question 的语义相似度降低时，性能随输入长度退化更快
• 短输入时模型对所有相似度级别都表现良好 → 退化不是因为任务难度，而是因为输入长度

② 干扰项的影响

• 干扰项对性能的非均匀影响随输入长度增长而放大
• 不同模型家族对干扰项的反应模式不同

③ Needle-Haystack 相似度

• Haystack 内容本身对性能有影响（之前被认为无关）

④ Haystack 结构

• 打乱 haystack 中文本的逻辑顺序会影响模型性能
• 说明模型对上下文的结构/流畅性有依赖

关键洞见

"现实应用通常涉及更大的复杂性，意味着输入长度的影响在实践中可能更加显著。"

NIAH 基准测试已经"基本解决"的说法是误导性的——它只测试了简单的词汇检索（lexical retrieval），而真实任务需要语义理解、消歧和跨上下文推理。

📚 课程关联：

• 第三周"How Long Contexts Fail"提出了 4 种失败模式（Poisoning/Distraction/Confusion/Clash）
• Context Rot 从实验角度验证了这些理论——性能退化是真实的、可量化的、跨模型的
• 这直接解释了为什么第四周 Claude Code 使用 /clear（清空上下文）、subagent（隔离上下文）、system-reminders（在关键位置重新注入指令）等技术

📖 阅读 7：O3 Finds CVE-2025-37899 (Sean Heelan)

来源： Sean Heelan's Blog（2025.5）+ GitHub Repo

🔗 课堂关联： 展示了 AI 漏洞发现能力的最佳案例——LLM 首次公开发现 Linux 内核 0-day。

背景

Sean Heelan 在审计 Linux ksmbd（内核态 SMB3 协议实现）时，用 o3 API 作为基准测试工具。结果 o3 发现了一个他自己没发现的 0-day 漏洞。

CVE-2025-37899 详情

类型： Use-after-free 位置： SMB2 LOGOFF 命令处理器 根因： 并发连接共享同一 session 时，一个线程释放 sess->user，另一个线程仍在访问它

关键： 理解这个漏洞需要推理并发连接如何共享对象——o3 成功做到了这一点。

实验数据

模型对比： o3 在 100 次中发现 8 次 vs Claude Sonnet 3.7 发现 3 次 vs Claude 3.5 发现 0 次

成本： 100 次运行（~100k token 版本）约 $116

假阳性： 约 28/100 次报告了不存在的漏洞（但 TP:FP ≈ 1:4.5，可接受）

关键洞见

"随着 o3 的出现，LLM 在代码推理能力上实现了质的飞跃。如果你从事漏洞研究，应该开始密切关注。"

同时也揭示了"双刃剑"效应：如果防御者能用 AI 发现漏洞，攻击者也能。

📚 课程关联： 这与第一讲的"What has changed — Good"（AI 增强 SAST/DAST）和"What has changed — Bad"（新攻击面）形成完美呼应——同一个技术既是防御工具也是攻击工具。

🔗 七篇阅读材料的交叉主题

主题 1：AI 安全的"双刃剑"

主题 2：确定性 vs 非确定性

最佳策略： 两者结合——用确定性方法覆盖已知模式，用 AI 发现需要推理的新漏洞。

主题 3：Context 持续是核心挑战

第三周：How Long Contexts Fail（4 种失败模式）
    ↓
第四周：Claude Code 的 system-reminders + subagents（工程解决方案）
    ↓
第六周：Context Rot（实验验证） + 非确定性 SAST（安全后果）

🔗 课程脉络： 第一周 LLM 基础 → 第二周 Agent + MCP → 第三周 IDE + Specs → 第四周 Agent Manager → 第五周 产品设计 + Terminal → 第六周 安全与测试。课程从"如何用 AI 开发"转向"如何确保 AI 开发的质量与安全"——从 Building 阶段进入 Quality Assurance 阶段。

CS146S 第七周笔记总结：Modern Software Support

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

📅 课程安排

第一讲：AI Code Review（11/3）

核心定位

"软件代码审查是你能做的最高杠杆活动之一，既能让自己成为更好的工程师，又能提升团队整体代码质量。"

这一讲从传统代码审查的价值出发，过渡到 AI 如何增强这一流程，最后讨论 AI 审查的局限性。

第一部分：为什么代码审查如此重要

统计数据（来源：Coding Horror / Code Complete）：

• 代码审查的错误检测率：55-60%
• 对比：单元测试 25%、功能测试 35%、集成测试 45%
• 引入审查前后：程序错误率从 4.5/100 行 降至 0.82/100 行（减少 80%+）
• AT&T 研究：引入审查后生产力提升 14%，缺陷减少 90%

📚 课程关联： 这些数据与第六周的 SAST/DAST 形成互补——SAST 检测代码模式漏洞，而代码审查检测逻辑和设计问题。两者组合是多层质量保障的核心。

第二部分：代码审查应该捕获什么

五大审查维度：

第三部分：什么是好的代码审查

反面：

"This won't work"

正面：

"I see your new method matches the existing style in this file, taking [X] parameters. Having that many parameters hurts readability and implies the function is doing too much. What do you think about refactoring this method and the existing ones in a later pull request to reduce how many parameters they take?"

好的审查标准：

• 提供具体细节
• 引用具体代码或问题
• 建议解决方案
• 引用证据或解释

代码审查的五大价值（来源：Blake Smith）：

1. 帮助团队成员随系统变化更新心智模型
2. 确保变更正确解决问题
3. 开启设计优劣的讨论
4. 在 Bug 到达生产环境前捕获
5. 保持代码风格和组织的一致性

第四部分：AI 代码审查工具

当前工具生态：

• Graphite（本周客座嘉宾）— AI 驱动的 PR 审查平台
• Greptile — AI 代码审查
• CodeRabbit — AI PR 审查
• Claude Code / Codex — 通用 AI 编程助手

第五部分：AI 改变了什么

第六部分：局限性（关键！）

"代码审查在 AI 编码时代比以往任何时候都更重要。你拥有被合并和发布的代码，不能怪 AI。"

📚 课程关联：

• "假阳性"问题直接延续第六周的核心发现（Semgrep 实验 86% 假阳性率）
• "安全变更需格外谨慎"呼应第六周 Copilot RCE 漏洞——AI 审查工具本身也可能忽略安全问题
• "你拥有被合并的代码"与第四周 Claude Code 的 Human-in-the-Loop 设计一致——AI 是助手，不是决策者

第二讲：Guest Lecture——Tomas Reimers（CPO, Graphite）（11/7）

Graphite 背景

• 定位： AI 代码审查平台，专注于 GitHub PR 工作流增强
• 核心产品： Graphite Agent（AI 审查器）、Stacked PRs（分层 PR）、Merge Queue
• 重要动态： Graphite 正在加入 Cursor，共同重塑软件开发的未来
• AI 审查引擎内部称为 Diamond

Graphite Agent 核心能力

• 上下文感知审查： 理解整个代码仓库的上下文，而非孤立分析代码变更
• RAG 机制： 利用过去的 PR 历史进行检索增强生成，学习项目编码模式
• 即时反馈： 每个 PR 自动获得 AI 审查，无需等待人类审查者
• 自定义规则： 团队可用自然语言定义编码标准，AI 自动执行

Graphite 的质量评估体系

基于用户真实行为的三个核心指标：

Stacked PRs 理念

将大型变更拆分为更小、有序的 PR 序列 → 加速审查、保持团队流动。这与 Blake Smith 的"手术刀开发"（scalpel-driven development）理念一致——"宁愿用手术刀做许多小而精确的切口，也不要用砍刀一刀切"。

AI 代码审查工具准确率

Graphite 指南提到：AI 代码审查工具在常见问题（语法错误、风格违规、基本安全漏洞）上准确率为 70-90%，但准确率因问题复杂性和具体工具而异。

📚 课程关联：

• Graphite 加入 Cursor = 第三周（AI IDE）+ 第七周（AI Code Review）的融合——审查能力直接嵌入 IDE
• Stacked PRs 与第四周 Claude Code 的 subagent（隔离任务）思路一致——小的、可管理的变更单元
• Acceptance/Upvote/Downvote 指标体系是第六周"如何评估 AI 安全工具"问题的回答

🔗 两讲之间的联系

📚 第七周阅读材料速览

🛠️ 第七周作业

Code Review Reps — 代码审查练习

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

Stanford University · Fall 2025 · 讲师：Mihail Eric

阅读材料一览

📖 阅读 1：Code Reviews: Just Do It (Jeff Atwood / Coding Horror, 2006)

来源： Coding Horror

🔗 课堂关联： 第一讲 Slide 6 直接引用了此文的统计数据。

核心论点

"Peer code reviews are the single biggest thing you can do to improve your code."

Jeff Atwood 引用 McConnell 的《Code Complete》数据：

• 软件测试本身效果有限——单元测试平均检测率仅 25%，功能测试 35%，集成测试 45%
• 设计和代码审查的平均有效率：55-60%

关键案例

📚 课程关联： 这篇 2006 年的文章今天读来依然重要——因为 AI 时代代码审查不是要被取代，而是要被增强。第一讲 Slide 24 的核心观点"代码审查比以往更重要"正是建立在这些数据基础上。

📖 阅读 2：How to Review Code Effectively (Sarah Vessels, GitHub Staff Engineer)

来源： GitHub Blog（2024）

作者背景

Sarah Vessels，GitHub Staff Engineer，8 年审查了 7,000+ PR。

核心哲学

"当同事有 PR 等待审查时，我更愿意放下自己正在做的分支去审查他们的代码——毕竟他们的 PR 已经通过了 CI，比我进行中的工作更接近可发布状态。"

关键实践

① 自我审查优先（Self-Review）

• 在请别人审查前，先自己审查一遍
• 在非明显的变更上内联留言
• 自我审查也能帮助判断 PR 是否太大、需要拆分

② PR 作为对话的开始

• 一个 PR 是作者说："我认为这改善了我们现有的东西"
• 审查者的工作：通过提问、质疑假设、作为第二双眼睛来改进代码

③ 即使已合并也欢迎审查

• 如果 PR 在别人审查前就合并了，仍然欢迎审查
• 如果出了问题，PR 上的评论留下了面包屑式的调查线索

📚 课程关联： "自我审查"在 AI 时代尤为关键——当 AI 生成代码时，开发者的第一道防线就是自己的审查能力。这与第一讲 Slide 24 "你拥有合并和发布的代码"形成完美呼应。

📖 阅读 3：AI-Assisted Assessment of Coding Practices in Modern Code Review (Google)

来源： arXiv 2405.13565（2024, AIware '24 会议） 作者： Manushree Vijayvergiya 等 13 人（Google）

AutoCommenter 系统

Google 开发的 LLM 驱动的自动代码审查系统，自动学习和执行编码最佳实践。

覆盖语言： C++、Java、Python、Go

核心问题

代码审查中，一些最佳实践可以自动验证（如格式规则），但另一些需要人类判断：

• 可自动化： 格式规则、lint 规则
• 部分可自动化： 命名约定（有例外情况，如遗留代码中的合理偏离）
• 无法用精确规则捕获： 代码注释的清晰度和具体性 → 依赖人类判断和集体知识

AutoCommenter 的定位

端到端的"学习并执行编码最佳实践"系统是可行的，并对开发者工作流产生积极影响。

在 Google 的大规模工业环境中评估后证实可行性。

📚 课程关联：

• 验证了第一讲 Slide 20 的六大改变（效率、一致性、知识共享等）在工业级规模下成立
• AutoCommenter 处理"可自动化"和"部分可自动化"的规则，而复杂业务逻辑和架构决策仍留给人类——与 Slide 24 的局限性完全一致
• Google 的规模（数千工程师、数百万行代码）为 AI 代码审查的可扩展性提供了有力证据

📖 阅读 4：AI Code Review Implementation Best Practices (Graphite)

来源： Graphite

AI 代码审查的六大收益

1. 效率 — 自动化减少审查时间
2. 一致性 — 所有审查统一标准
3. 知识共享 — 通过 AI 建议学习
4. 降低认知负荷 — AI 处理常规检查
5. 持续改进 — 系统随时间改进
6. 全面理解 — 上下文分析和模式识别

这六大收益与第一讲 Slide 20 完全对应——Mihail 直接将 Graphite 的框架用作教学内容。

工具选型考量

实施最佳实践

① 持续改进循环

• 追踪哪些 AI 建议被接受 vs 被拒绝
• 定期审查假阳性和假阴性
• 根据发现更新审查配置
• 跨团队共享洞见

② 安全优先

• 验证 AI 建议不引入新漏洞
• 对处理以下内容的 AI 生成代码格外谨慎：用户输入、认证、文件操作、网络请求

③ 准确率

• 常见问题（语法、风格、基本安全）：70-90%
• 复杂问题：准确率显著下降

📚 课程关联： "安全优先"原则直接连接第六周——CVE-2025-53773（Copilot RCE）就是 AI 引入安全漏洞的真实案例。70-90% 准确率与第六周 Semgrep 评估的 14-18% 真阳性率形成有趣对比——代码审查（格式/风格/简单逻辑）比安全漏洞发现（跨文件污点追踪）容易得多。

📖 阅读 5：Code Review Essentials for Software Teams (Blake Smith, 2015)

来源： Blake Smith

🔗 课堂关联： 第一讲 Slide 17 直接引用了此文。

核心观点：心智模型对齐

"代码审查最重要的功能是保持团队的集体心智模型良好对齐。"

当 Bob 提交会计子系统的 PR 时，Amy 在审查过程中更新了她对该系统的心智模型。一个月后 Amy 需要修改这个子系统时，她的心智模型已经是最新的——花更少时间阅读代码，更多时间思考高层抽象和设计。

代码审查的层级价值

1. 方向对齐 — 保持每个团队成员朝正确方向前进（最重要）
2. 正确性验证 — 确保变更正确解决问题
3. 设计讨论 — 开启优劣势讨论
4. Bug 预防 — 在到达生产环境前捕获
5. 风格一致 — 保持代码风格和组织一致

手术刀开发法（Scalpel-Driven Development）

"宁愿用手术刀做许多小而精确的切口，也不要用砍刀一刀切。砍刀留给删除大块死代码的时候。"

实操建议：

• 提交前问自己："这是正确的工作优先级吗？"和"团队已经同意这个变更方向了吗？"
• 考虑如何将工作拆分为小块并测试每一块
• 写好组织良好的 PR 描述——不要让队友做多余的心智劳动

好 vs 差的 PR 描述

差：

Title: Fix uninitialized memory bug Description: This is the bug Bob and I talked about earlier. I had trouble with the compiler but managed to make this work.

好： 解释为什么做了这些变更、如何做的、以及审查者需要知道的任何仅从代码本身看不出来的信息。

📚 课程关联：

• "手术刀开发"与 Graphite 的 Stacked PRs 理念完美对齐——小的、有序的变更序列
• "心智模型对齐"与第四周 CLAUDE.md/AGENTS.md 的理念相通——都是为了让协作者（无论是人还是 AI）理解项目上下文

📖 阅读 6：Lessons from Millions of AI Code Reviews (Graphite YouTube)

来源： YouTube（视频资源）

🔗 课堂关联： 第一讲 Slide 22 直接引用了此视频。

基于 Graphite 从百万级 AI 代码审查中获得的经验教训，在课堂上进行了现场演示（Slide 23: "Let's See AI Code Review in Action"）。

🔗 六篇阅读材料的交叉主题

主题 1：代码审查是团队能力，不仅仅是质量检查

Coding Horror (2006): "Peer code review is the single biggest thing"
    ↓
Blake Smith (2015): "最重要的是心智模型对齐"
    ↓
Sarah Vessels (2024): "PR 是对话的开始"
    ↓
Mihail (2025): "代码审查比以往任何时候都更重要"

从 2006 到 2025，核心观点一脉相承：代码审查的价值不仅在于捕获 bug，更在于团队学习、知识传递和心智模型同步。AI 时代放大了这一点——当 AI 生成大量代码时，人类审查者的理解和判断能力比以往更关键。

主题 2：AI 审查的"甜蜜区"

结论： AI 处理"常规检查"（routine checks），人类专注"复杂判断"（complex logic）——分工而非替代。

主题 3：从个人实践到工业规模

Blake Smith: 团队级最佳实践（手术刀开发、好的 PR 描述）
    ↓
Sarah Vessels: 个人级哲学（7000+ PR、自我审查优先）
    ↓
Google AutoCommenter: 公司级自动化（C++/Java/Python/Go, 数千工程师）
    ↓
Graphite: 产品级 AI 审查（百万级 PR、RAG + 自定义规则）

🔗 课程脉络： 第一周 LLM 基础 → 第二周 Agent + MCP → 第三周 IDE + Specs → 第四周 Agent Manager → 第五周 产品设计 + Terminal → 第六周 安全与测试 → 第七周 代码审查

课程从"构建"（W1-5）→ "防护"（W6）→ "审查"（W7）的三段式进程。第七周是质量保障链的最后一环——在代码合并前的最后一道人类防线。

关键连接：

• 第三周 Cursor 的 AI IDE → 第七周 Graphite 加入 Cursor = AI 编写 + AI 审查的闭环
• 第四周 CLAUDE.md 定义项目规则 → 第七周 Graphite 自定义规则 = 同一理念的不同实现
• 第六周 SAST 检测安全漏洞 → 第七周 AI 审查检测逻辑/设计问题 = 多层质量保障体系

CS146S 第八周笔记总结：Automated UI and App Building

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

📅 课程安排

本周特点： 没有阅读材料，重点是实操演示和工具体验。

第一讲：End-to-End Apps with a Single Prompt（11/10）

开场定位

Slide 3: "This is not the 'vibe coding' class — Because I'm a software development purist" Slide 4: "…except today"

Mihail 一直强调专业软件开发，但今天是例外——因为 AI app builder 已经成为不可忽视的现实。

第一部分：Web 开发的演化史

为什么这个话题重要？ 现代 SaaS 开发以 Web 应用为中心已经超过 20 年（Salesforce 1999 年常被视为第一个 SaaS 平台）。

传统技术栈演化：

传统三层架构： client-side → server-side → database（Slide 7, MERN 为例）

第二部分：第一次尝试——Visual Low-code/No-code

• Wix — 拖拽式网站构建
• Squarespace — 设计师友好的模板
• Webflow — 可视化 Web 开发

这些是"Take #1"，降低了门槛但仍有显著局限。

第三部分：The New AI World

Slide 11: 新一代 AI 工具

第四部分：What Has Changed

Slide 12 三大变革：

1. Prompt your way to a fully fledged app — 用自然语言直接生成完整应用
2. Engineers are becoming more cross-functional — 工程师开始跨越设计和产品管理的边界
3. Anyone can build an app now — 比第一代 no-code 平台（Webflow, Wix, Squarespace）更用户友好

第五部分：现场演示——Let's Make An App Right Now

Slide 13: Bolt 演示——"Make salsa partner finder"

演示流程：

1. 用 Bolt 生成一个带前端和后端的 salsa 舞伴查找应用
2. 初始生成后进行迭代修改：
   • 更新色彩方案（#EF8354, #660000, #EFCA08）
   • 图标
   • 字体排版

第六部分：App Builder 架构

Slide 14: WebContainer

核心架构：WebContainer 运行任意生成的代码。

WebContainer 是什么？ 由 StackBlitz 开发的浏览器内 Node.js 运行时——不需要任何本地安装，代码在浏览器沙箱中运行。

第七部分：App Builder System Prompt

Slide 15: Bolt 的系统提示词

关键设计原则：

• 明确要求只使用成熟、知名的技术/框架 — 避免幻觉出不存在的库
• 使用 boltartifact / boltaction 标签来指定 WebContainer 中的操作（文件创建、文件运行等）
• 参考链接：Bolt Agent System Prompt（GitHub Gist + PromptHub）

📚 课程关联： 这与第四周的 CLAUDE.md 和第二周的 System Prompt 设计完全一致——通过精心设计的系统提示来控制 AI 行为。App Builder 的 system prompt 本质上就是一个高度专用化的 agent 指令。

第八部分：Limitations（关键！）

Slide 16: 五大局限性

📚 课程关联：

• "一旦出错回到原点" 呼应第三周 Cursor 的 "Sync Agent" 局限——AI 无法替代工程师的调试能力
• "安全问题" 直接连接第六周——Lovable 的 CVE-2025-48757（RLS 配置错误导致 170+ 应用数据泄露）是 AI 安全双刃剑的又一案例
• "Prompts are just suggestions" 呼应第一周 Prompt Engineering 的核心教训

第二讲：Guest Lecture——Gaspar Garcia（Head of AI Research, Vercel）（11/14）

嘉宾背景

Gaspar Garcia：

• Head of AI Research, Vercel
• Tech Lead, v0
• 职责：Data Pipelines, Training + Finetuning, Agent Development, Web Infrastructure
• Stanford Class 2016（BS Computer Science Theory, MS Computer Science AI）

第一部分：v0 的定位

Slide 4: "Free for students → https://v0.app/students" Slide 6: "Most likely its not"（暗示你的第一个想法大概率不对） Slide 7: "Fail fast, fail often — Accelerate the learning moments of product development"

v0 的核心价值不是"一次做对"，而是加速试错循环——快速失败、快速学习。

第二部分：From Idea to Production in Minutes

Slide 8: 四步流程

Natural Language Input → AI Processing → Live Preview → One-Click Deploy
描述 UI 愿景         → 模型生成代码    → 即时预览     → 一键部署

第三部分：The Developer Landscape is Shifting

Slide 10-11:

v0 的快速采用反映了前端开发方式的根本性变化——不仅是速度，更是技术能力的民主化。

打破团队壁垒（Breaking Down Silos）——四种角色都能使用：

📚 课程关联： 这与第五周 Warp 的理念完全一致——Zach Lloyd 说"Terminal 不应该只给 10x engineer"，Gaspar 说"App building 不应该只给工程师"。工具民主化是 W5-W8 的共同主题。

第四部分：Inside v0's Engine（核心技术内容！）

Slide 13: v0 引擎的五步流程

📚 课程关联：

• 步骤 2 "Context Assembly" = 第四周的 Context Engineering
• 步骤 5 "Human-in-the-Loop" = 第四周 Claude Code 的 permission system + 第七周 code review
• 整个流程 = 第二周 Agent 架构（感知 → 推理 → 行动）的具体实现

第五部分：Agents are Workflows

Slide 14: "Agents are Workflows" Slide 16: "But they're still probabilistic systems" Slide 17: "Give them Frameworks"

关键洞见：

• Agent 本质上是工作流——不是魔法，而是精心设计的步骤序列
• 但它们仍然是概率系统——输出不确定
• 解决方案：给它们框架来约束行为

引用了 Vercel AI SDK：https://ai-sdk.dev/docs/agents/overview

📚 课程关联： "Agents are Workflows" 是第二周内容的精炼总结。"But they're still probabilistic systems" 是第六周非确定性 SAST 问题在更广泛层面的表述。

第六部分：Corrections and Fine-Tuning（深度技术！）

Slide 20: Key Limitations

两个核心限制：

1. 模型知识很快过时 — 对于变化快的话题（如 Next.js 16 的最新 API）
2. 前沿模型实验室不会为你定制流水线 — OpenAI/Anthropic 不会专门为 "生成正确的 Next.js 16 代码" 创建训练管道

Stream Manipulation（Slide 21-23）

"Sometimes, just adjusting the prompt isn't enough."

解决方案：Stream Manipulation

Vercel 创建了一个子系统，可以在 LLM 输出流到达用户之前监听和捕获它。

这意味着：

• LLM 生成的代码可以被实时修正
• 不需要改变模型本身
• 类似于编译器的中间层——在 AI 输出和用户之间插入一个"修正层"

📚 课程关联： 这是极其重要的工程洞见——当 prompt engineering 不够时，你需要在模型输出层做工程。这与第四周 Claude Code 的 "generative command injection detection"（不是硬编码规则，而是分析命令的子 prompt）是同一类思路——在 AI 输出的管道中插入额外的处理层。

Training + Fine-Tuning（Slide 24-25）

v0 使用 composite model family（复合模型族）——不是依赖单一模型，而是针对不同任务微调了专门的模型。

参考：https://vercel.com/blog/v0-composite-model-family

📚 课程关联： 第四周 Claude Code 的 subagent（不同 agent 处理不同任务），在 v0 这里是不同模型处理不同任务——同样的"分而治之"思路。

第七部分：The Broader AI Tooling Landscape

Slide 26: "A Cambrian Explosion of AI Dev Tools"

v0 存在于专业化 AI 开发工具的生态系统中：

关键差异化因素：处理整个功能的端到端工作流，而不仅仅是自动补全建议。

第八部分：Real-World Impact

Slide 27: 三种采用模式

🔗 两讲之间的联系

🔒 安全焦点：Lovable CVE-2025-48757

第一讲 Slide 16 直接引用了 Lovable 的安全漏洞，这是第八周与第六周安全主题的关键桥梁。

CVE-2025-48757 核心：

• 漏洞类型： Supabase RLS（行级安全）配置缺失/错误
• 影响： 1,645 个项目中 303 个端点跨 170 个应用存在漏洞（约 10.3%）
• 后果： 未认证攻击者可读写数据库——用户数据、API 密钥、财务记录全部暴露
• 发现时间线： 2025.3.20 发现 → 2025.4.14 Palantir 工程师独立发现并公开 → 2025.4.24 Lovable 2.0 发布"安全扫描"（不够用）→ 2025.5.29 CVE 正式发布

根因分析：

• Lovable 的架构是客户端驱动的，安全责任被推给了应用构建者
• 但使用 Lovable 的很多人恰恰是没有安全知识的非开发者
• Lovable 的"安全扫描器"只检查 RLS 策略是否存在，而不检查是否正确——提供虚假的安全感

📚 课程关联：

• 第六周 Copilot RCE（CVE-2025-53773）： AI IDE 的安全漏洞——AI 修改自身配置实现 RCE
• 第八周 Lovable CVE-2025-48757： AI app builder 的安全漏洞——AI 生成不安全的默认配置
• 共同主题： AI 工具降低开发门槛的同时，也降低了安全门槛。当"Anyone can build an app"时，安全不能依赖用户自己配置——必须 secure by default。
• 这也验证了第七周的核心观点："Code review is more important now than ever — You own the code that is merged and shipped, no blaming of the AI"

📚 第 1-8 周课程脉络

W1: LLM + Prompt Engineering（基础能力）
 ↓
W2: Agent + MCP Protocol（自主能力）
 ↓
W3: AI IDE + Specs-Driven（开发环境）
 ↓
W4: Agent Manager + Context Engineering（管理架构）
 ↓
W5: Product Design + Terminal ADE（产品思维）
 ↓
W6: Security + Testing（防护体系）
 ↓
W7: Code Review（质量保障）
 ↓
W8: Automated UI + App Building（极致应用）

第八周的独特位置： 这是课程中最"激进"的一讲——从"AI 辅助开发"跳跃到"AI 替代开发"。但 Mihail 开场就说"this is not the vibe coding class"，并在 Slide 16 用五大局限性拉回现实。

核心张力：

• W1-W7 构建的全部知识（prompt engineering、agent 架构、security、code review）——在 AI app builder 面前，这些还重要吗？
• 答案是Yes：Lovable 漏洞证明安全仍然重要（W6）、"出错回到原点"证明工程能力仍然重要（W3-W4）、同质化设计证明产品思维仍然重要（W5）
• Gaspar 的技术深潜（Stream Manipulation、Composite Model Family）证明：即使是构建"让非开发者也能开发"的工具，背后仍然需要极深的工程能力

🛠️ 第八周作业

Multi-stack Web App Builds — 多技术栈 Web 应用构建

本周暂无阅读材料笔记。

CS146S 第九周笔记总结：Agents Post-Deployment

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

📅 课程安排

嘉宾背景：

• Mayank Agarwal： Resolve AI CTO，OpenTelemetry 共同创建者，DeepMind Staff MLE
• Milind Ganjoo： Resolve AI Member of Technical Staff

第一讲：AI DevOps — Incident Response（Mon 11/17，19 slides）

开场定位（Slides 3-4）

Slide 3: "AI DevOps"

为什么这个话题重要（Slide 4 "Why"）：

• 编码仅占工程时间的 30%
• 更难的 70% 是在生产环境中运行代码——复杂性、工具孤岛、知识差距、相互依赖在这里碰撞
• 管理生产通常需要由 SRE 进行繁琐的软件分诊

📚 课程关联： "编码只占 30%"直接呼应 Resolve AI 博客的核心论点——"Software engineering has embraced code generation, but the real bottleneck is production." W1-W8 关注如何用 AI 写代码，W9 关注代码写完之后怎么办。

第一部分：The Old World — 传统 SRE（Slide 6）

SRE 的传统职责：

• 运营监控（on-call、故障排查、基础设施管理和安全）
• 事故解决需要从多个不同来源和团队拼凑信息
• 维护经常过时的 Runbook
• 向云原生架构（容器化 + Kubernetes）迁移引入了更多数据、依赖和跨系统复杂性
• SRE 经常因 on-call 轮班而倦怠

关键数据： 停机和服务降级每年给 Global 2000 造成约 $400 billion 损失。

📚 课程关联： Resolve AI 创始人 Spiros 的亲身经历——"当我领导 Splunk 的 Observability 业务时，90% 的 SRE 团队在六个月内因 on-call 职责的倦怠而辞职。"

第二部分：Principles of Infrastructure and DevOps（Slide 7）

监控的四大黄金信号（Four Golden Signals）

追踪的关键指标（Slide 11）

第三部分：现场互动——凌晨 3:12 的告警（Slides 8-9，核心！）

场景： 凌晨 3:12，你收到 PagerDuty 的 ping，发现数据库查询出现 500 错误激增。怎么办？

Mihail 先让同学们讨论（"Ask for thoughts from the audience"），再展示完整 Playbook：

事故响应 Playbook（8 步）

Step 1: Acknowledge & Assess（确认和评估）

• 在 PagerDuty 中确认
• 确认严重性：检查应用和数据库仪表盘
• 识别影响：部分中断 or 完全中断

Step 2: Check the Golden Signals — DB First（检查黄金信号）

• Connections：是否达到上限？卡住？突然下降？
• Latency：P95 是否飙升？慢查询？
• Errors：超时？拒绝连接？中止的事务？
• Saturation：CPU、IOPS、锁、内存、复制延迟

Step 3: Look for What Changed（查找变更）

• 最近的部署？数据库迁移？配置/功能标志变更？自动扩展事件？
• → 如果与变更相关，立即回滚/恢复

Step 4: Localize the Failure（定位故障）

• 所有查询还是特定查询？读 vs 写？
• 主库 vs 副本？单个分片还是全部？
• 应用端（连接池/超时）vs 数据库端（负载/锁）？

Step 5: Apply Fast Mitigations（快速缓解）

• 连接问题：重启应用 Pod，降低并发
• 数据库饱和：禁用重量级 Job，限流，将读请求路由到副本
• 坏/慢查询：禁用功能/端点，启用缓存/降级模式
• 副本延迟：将读请求路由到主库，重启副本
• 不健康节点：只重启副本；主库问题需要升级处理

Step 6: Stabilize & Monitor（稳定和监控）

• 观察 500 率、数据库延迟和流量恢复正常
• 确保没有重试风暴或级联故障
• 验证应用健康检查恢复

Step 7: Communicate（沟通）

• 简报更新：问题 → 行动 → 当前状态
• 活跃事故期间每 10-15 分钟更新一次

Step 8: Close Out（收尾）

• 记录时间线，确定根因驱动因素
• 记录后续行动：查询修复、索引优化、扩展、重试调优、容量评审

📚 课程关联： 这个 8 步 Playbook 本质上是一个手动的 Agent 工作流——感知（Step 1-2）→ 推理（Step 3-4）→ 行动（Step 5-6）→ 沟通（Step 7-8）。第二周讲的 Agent 架构（Perception → Reasoning → Action）在这里有了最具体的人工版对照。AI SRE 的目标就是自动化这 8 步。

第四部分：The New AI World（Slides 12-15）

新一代 AI 运维工具（Slide 12）

AI SRE 的四大特征（Slide 13，核心！）

📚 课程关联： "Explainability & Auditability"是本课程首次明确提出的要求——在编码领域（W1-W8）我们关注 AI 是否生成了正确的代码；在运维领域（W9），由于事关生产安全，我们还必须理解 AI 为什么做出这个判断。这与第六周安全课的精神一致——信任必须可验证。

What Has Changed（Slides 15-16）

Slide 15（关键转变）：

• AI 承诺扩展组织和服务级知识
• 信息不再被局限于"唯一知道未记录依赖关系、脆弱遗留服务和只在高风险事故期间才浮现的问题"的少数工程师

Slide 16（AI 代码审查的延续——呼应 W7）：

• 自动化减少审查时间，更早发现问题
• 开发者通过 AI 建议学习最佳实践
• AI 在所有代码审查中应用相同标准
• AI 处理常规检查，让人类专注复杂逻辑
• AI 系统随着更多数据持续改进
• 现代 AI 代码审查工具提供更深入的上下文分析和模式识别

第五部分：AI SRE in Action（Slide 17）

Slide 17: "Let's See AI SRE in Action"

Mihail 现场演示 AI SRE 工具，指出四个关键能力：

• Observability + Working theories（工作假设）
• Span information（跨度信息）
• Heavily evidence-based（大量证据支撑）
• Chat for more dynamic querying of information（聊天式动态查询）

第六部分：Limitations（Slide 18，核心！）

📚 课程关联：

• "安全可能成为新攻击向量"= 第六周 Copilot RCE（CVE-2025-53773）在运维领域的翻版——AI 工具在解决问题的同时可能引入新风险
• "Good RCA requires good monitoring gardening"= 经典的 GIGO（Garbage In, Garbage Out），与第四周 Context Engineering 的核心洞见一致——AI 的输出质量取决于输入的上下文质量
• "代码修复能力有限"= 当前 AI SRE 的核心瓶颈——从"发现问题"到"修复问题"还有巨大鸿沟

第二讲：Guest — Resolve AI: AI Agents for Production Systems（Fri 11/21）

演讲者： Mayank Agarwal (CTO) & Milind Ganjoo (Technical Staff) 演示文件： [RESOLVE AI] Stanford CS146S AI Agents for Production Systems.pdf

以下内容综合 Resolve AI 演讲和全部四篇配套阅读材料

第一部分：Resolve AI 公司背景

创始团队：

• Spiros Xanthos（CEO）： OpenTelemetry 共同创建者，前 Splunk Observability 业务 SVP/GM，创建了 Log Insight（被 VMware 收购）和 Omnition（被 Splunk 收购）
• Mayank Agarwal（CTO）： 与 Spiros 20 年前在 UIUC 研究生院相识，自 2012 年起合作，DeepMind Staff MLE

融资： $35M Seed 轮，Greylock 领投，天使投资人包括来自 AWS、Google、GitHub、Replit、OpenAI、Snowflake、Stanford 的技术先驱（Jeff Dean、Reid Hoffman、Fei-Fei Li 等）

客户： Coinbase、Zscaler、Toast、DoorDash、Blueground 等

核心指标： MTTR 减少 70%+，on-call 生产力提升 75%，每位工程师每周节省 20 小时

第二部分：核心问题 — 生产环境的瓶颈

关键论点： "Software engineering has embraced code generation, but the real bottleneck is production."

Spiros 的亲身经历（from Splunk）：

• 90% 的 SRE 团队在六个月内因 on-call 倦怠辞职
• 大多数客户升级是因为可靠性问题
• 有时生产环境被冻结数月以避免宕机——创新完全停滞

核心矛盾： AI 编码助手在加速功能开发，但这也会让运维复杂性更糟——代码写得越快，部署到生产的变更越多，出问题的机会也越多。

"We can't go faster until we solve these operational bottlenecks."

第三部分：AI Production Engineer 产品架构

3.1 Knowledge Graph（知识图谱）

从集成 Resolve AI 的那一刻起，它开始全面映射你的环境：

• 构建一个动态知识图谱——覆盖整个系统和工具
• 实时更新： 新部署、系统事件、配置变更、代码变更时持续更新
• 使 Agent 能够快速遍历所有依赖关系、Pod 和部署

3.2 告警触发时的工作流

告警触发
  → AI 像值班工程师一样立即开始调查
  → 自主创建和执行即时 runbook（just-in-time）
  → 审查：metrics, dashboards, code changes, deployments, logs
  → 不到一分钟 → 根因理论 + 修复建议

3.3 集成生态

使用 APIs、Webhooks 和 MCP（Model Context Protocol） 连接和编排这些系统。

📚 课程关联： 第二周学的 MCP 协议在这里以生产级应用出现——Resolve AI 用 MCP 连接可观测性工具，正如 Claude Code 用 MCP 连接开发工具。

第四部分："Vibe Debugging"（氛围调试）

Resolve AI 提出的新概念： 用 AI Agent 调查任何软件问题的过程——从理解代码到排查日常生产事故。

与传统调试的核心区别：

真实案例：svc-entity-graph 内存问题

工程师说："Investigate the memory issue in svc-entity-graph." AI Agent 的行为：

1. 自我定位： 识别正确的资源（svc-entity-graph 作为 prod 中的 kube_deployment），设定调查时间范围
2. 并行调查——同时查询完全不同的系统：
   • 查询 Git 仓库找到时间窗口内的 1 个最近提交
   • 搜索 Grafana，从数百个仪表盘中找到正确的那个，分析 13 个不同图表，定位出与内存问题最相关的 2 个
   • 拉取上游服务（svc-entity-graph-ingest）的网络流量遥测数据
   • 交叉验证 Kubernetes API 的 Pod 配置以排除基础设施错误
3. 确认理论： 通过 CI/CD 管道中同一变更的回滚来确认整个理论，并将其与系统的恢复时间对齐

真实案例：svc-analysis 部署失败

1. AI 分析遥测数据（logs），综合结果，定位 node-canvas 错误为根因
2. 当问"how to fix"→ 分析上下文，建议安装系统依赖
3. 当问"where"→ 分析代码库，指向精确文件（.github/src/base/node-prod/Dockerfile）和行号

📚 课程关联：

• "Vibe Debugging" 与 W8 "Vibe Coding"（Karpathy）形成平行对照：自然语言→代码 vs 自然语言→调查结论
• 并行假设探索 = 第四周 Claude Code subagent 的生产环境版本——Claude Code 用多个 subagent 并行处理编码子任务，Resolve AI 用多个 Agent 并行调查不同假设

第五部分：AI-Assisted vs AI-Native Engineering

"AI-Native Engineering is where engineers primarily interface with AI to orchestrate their work."

第六部分：为什么需要 Multi-Agent Systems

核心论点： 单一 LLM 或单一 Agent 在复杂生产环境中会失败。

原因：

• 生产环境涉及多个异构系统（observability, infra, code, CI/CD, communication）
• 不同类型的问题需要不同的专业知识
• 需要同时从多个角度并行调查

Resolve AI 的多 Agent 架构：

• 一个 Agent 专注系统日志
• 另一个 Agent 关注应用指标
• 第三个 Agent 审查代码变更
• 第四个 Agent 检查基础设施配置
• 它们协作得出综合结论

📚 课程关联： Multi-Agent 模式贯穿整个课程：

场景	Multi-Agent 实现
W4 Claude Code	Main agent + subagents（不同编码任务）
W7 Graphite	AI reviewer（不同检查维度）
W8 v0	Composite model family（不同生成任务）
W9 Resolve AI	多个 investigation agents（日志/指标/代码/K8s）

第七部分：Agentic AI On-call 的五大收益

"Agentic AI isn't just the next step in automation—it's a paradigm shift in incident management."

🔗 两讲融合：交叉分析

主题 1：手动 Playbook → AI 自动化的映射

Mihail 的 8 步 Playbook 与 Resolve AI 的自动化形成精确对应：

关键观察： Mihail 的手动 Playbook 用了 8 步、可能需要数小时。Resolve AI 将同样的流程压缩到不到一分钟。但 Slide 18 的局限性提醒我们：复杂事故仍然需要人类判断。

主题 2：可观测性是一切的基础

Google SRE Book → 定义 SRE 原则和 Error Budget
         ↓
Last9 (Traces & Spans) → 提供可观测性的技术基础
         ↓
Mihail 的 Four Golden Signals → 定义监控什么
         ↓
Resolve AI → 在此基础上构建 AI Agent

关键洞见（Slide 18）： "Good root cause analysis requires good monitoring gardening." 没有良好的可观测性，AI 运维就是空中楼阁。

主题 3：Vibe Coding（W8）→ Vibe Debugging（W9）

主题 4：知识保留——组织的核心挑战

Slide 15 的核心洞见："AI promises to scale out organizational and service level knowledge — Information is not siloed to the only engineers who know the undocumented dependencies, brittle legacy services, and quirks that only surface during high-stakes incidents."

主题 5：安全——贯穿课程的隐忧

每当 AI 获得更多系统权限（从编写代码→构建应用→运维生产），安全风险也在同步升级。AI SRE 拥有对整个生产环境的访问权限——这既是其强大之处，也是潜在的最大风险。

📖 阅读材料总览

阅读材料 1：Google SRE Book — Introduction

SRE 定义： "当你让软件工程师来设计运维功能时，就会产生 SRE。"

Error Budget 框架： 将开发速度 vs 系统稳定性的冲突量化——99.99% 可用性 = 允许每季度 13 分钟宕机。预算用完→停止发布；预算有余→加速发布。

Postmortem 文化： 无指责→目标是暴露缺陷并用工程手段修复。没有触发 Page 的 Postmortem 更有价值——指向监控盲区。

阅读材料 2：Last9 — Traces & Spans

Traces = 请求在分布式系统中的完整旅程。Spans = 构建块（每个代表一个工作单元）。

采样策略： Head-based（请求开始时决定）、Tail-based（完成后决定，更适合捕获错误）、Priority（重要操作总是追踪）。

M.E.L.T.： Metrics（系统趋势）+ Events + Logs（调试）+ Traces（请求路径）。OpenTelemetry = 标准框架。

阅读材料 3-6：Resolve AI 四篇博客

K8s 排查： Always-On Expertise → Correlate Across Cluster → Automated Investigations → Provide Resolutions

Product Deep Dive： Knowledge Graph（实时映射）+ 即时 Runbook（<1 分钟）+ 集成生态（Datadog/Grafana/AWS/GitHub/Slack）

Multi-Agent Systems： AI-Assisted（加速步骤）vs AI-Native（AI 成为主界面）。单一 Agent 不够，需要多 Agent 协作。

On-call 五大收益： 即时调查、持续学习、一致性、多 Agent 协作、从被动到主动。

📚 第 1-9 周课程脉络

W1: LLM + Prompt Engineering（基础能力）
 ↓
W2: Agent + MCP Protocol（自主能力）
 ↓
W3: AI IDE + Specs-Driven（开发环境）
 ↓
W4: Agent Manager + Context Engineering（管理架构）
 ↓
W5: Product Design + Terminal ADE（产品思维）
 ↓
W6: Security + Testing（防护体系）
 ↓
W7: Code Review（质量保障——合并前的最后检查点）
 ↓
W8: Automated UI + App Building（极致应用——AI 替代开发）
 ↓
W9: Agents Post-Deployment（部署后——AI 运维、监控、事件响应）

第九周完成了 AI 软件开发的完整生命周期：

下一周（W10）：展望未来——Software Development in 10 Years + a16z Martin Casado 客座讲座。

⚡ 第九周核心金句

Mihail: "Coding represents just 30 percent of engineering time. The harder 70 percent is running that code in production."

Mihail Slide 18: "Good root cause analysis requires good monitoring gardening."

Mihail Slide 18: "Security could be a new attack vector."

Resolve AI: "Software engineering has embraced code generation, but the real bottleneck is production."

Resolve AI: "AI-Native Engineering is where engineers primarily interface with AI to orchestrate their work."

Resolve AI: "Agentic AI isn't just the next step in automation—it's a paradigm shift in incident management."

Spiros (Resolve AI CEO): "We can't go faster until we solve these operational bottlenecks."

Spiros: "Agents will perform all the engineering tasks like coding and debugging systems. Humans will operate at a higher level of abstraction overseeing the AI."

CS146S 第九周阅读材料笔记：Agents Post-Deployment

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

📖 阅读材料总览

阅读材料 1：Introduction to Site Reliability Engineering

来源： Google SRE Book, Chapter 1（Ben Treynor Sloss，Google SRE 创始人）

核心内容

SRE 的定义： "当你让软件工程师来设计运维功能时，就会产生 SRE。" Ben Treynor Sloss 是 Google 负责技术运营的高级副总裁，也是 SRE 一词的创造者。

SRE 团队构成：

• 50-60% 是标准 Google 软件工程师
• 40-50% 是接近 Google SWE 标准（85-99% 的技能），但额外拥有 UNIX 系统内核和网络（L1-L3）专业知识
• 两个轨道的工程师在实际表现上没有实际差异——多元背景反而产生更高质量的系统

核心原则：Error Budget（错误预算）

SRE 的关键创新是将开发速度 vs 系统稳定性的隐性冲突变成一个可量化的框架：

• 产品开发团队想要快速发布新功能
• 运维团队想要系统永远不出问题
• SRE 的解决方案：设定一个错误预算（比如 99.99% 可用性 = 允许每季度 13 分钟宕机）
• 如果错误预算用完了→停止发布新功能，直到下一个周期
• 如果错误预算还有余量→可以加速发布

Postmortem 文化：

• 所有重大事故都应写 Postmortem，无论是否触发了 Page
• 没有触发 Page 的 Postmortem 更有价值——因为它们指向监控盲区
• Google 实行无指责文化——目标是暴露缺陷并用工程手段修复，而非追究个人责任

📚 课程关联： SRE 的"无指责 Postmortem"与第七周 code review 的核心理念一致——Blake Smith 说 code review 最重要的功能是"保持团队心智模型对齐"，Postmortem 最重要的功能是"暴露系统缺陷"。两者都是团队学习机制，而非惩罚机制。

阅读材料 2：Traces & Spans: Observability Basics You Should Know

来源： Last9 Blog

核心概念

Traces（追踪）： 捕获一个请求在分布式系统中从头到尾的完整旅程。

Spans（跨度）： Traces 的构建块。每个 Span 代表旅程中的一个工作单元——如数据库查询、API 调用、函数执行。

Trace
├── Span (API Gateway)
│   ├── Span (Auth Service)
│   └── Span (User Service)
│       └── Span (Database Query)
└── Span (Response Formatting)

Span 包含的数据：

• 时间戳（开始和结束）
• Status（成功、错误等）
• Attributes（自定义键值对，如 user_id, cart_size）
• 父子关系（嵌套结构）

采样策略（Sampling）——追踪所有请求会产生海量数据：

• Head-based sampling： 在请求开始时决定是否采样
• Tail-based sampling： 在请求完成后决定（更适合捕获错误）
• Priority sampling： 总是追踪重要操作，对常规操作采样

可观测性三大支柱（M.E.L.T.）：

• Metrics： 系统级趋势（请求率、错误率、平均延迟）——"每分钟有多少 checkout 请求失败？"
• Logs： 详细的文本记录——用于调试
• Traces： 个别请求的完整路径——"这个请求经过了哪些服务，每步花了多长时间？"

OpenTelemetry 已成为实现 traces 和 spans 的标准框架——开源、厂商中立、跨语言。

最佳实践：

• 有意义的 span 命名（如 service_name/operation）
• 正确的粒度（为重要操作创建 span，而非每个函数）
• 正确的 context propagation（确保追踪上下文在所有通信通道中流转）
• 有用的 attributes（添加有助于排查的属性，如 user_id, feature_flag）

常见错误：

• Over-instrumentation：创建太多 span 导致性能问题
• Missing context：未能跨服务传播上下文
• Inconsistent naming：不同的命名标准导致追踪难以解读

📚 课程关联： 可观测性是第六周安全/测试的"运行时"对应——第六周关注"代码中有什么漏洞"（SAST/DAST），第九周关注"运行中发生了什么"（Traces/Metrics/Logs）。

阅读材料 3：Kubernetes Troubleshooting with AI

来源： Resolve AI Blog

核心问题

Kubernetes 虽然自动化了很多运维，但其动态和临时性的本质带来新挑战：

1. Noisy Alerts That Cry Wolf： K8s 控制平面不断调整工作负载以匹配期望状态，期间产生大量虚假告警
2. Noisy Neighbors： 相邻 Pod 资源竞争
3. Misbehaving Add-ons： 插件行为异常
4. Resource Starvation： 资源匮乏
5. Subtle Memory Leaks： 细微的内存泄漏——"潜伏在表面之下"

Resolve AI 的 K8s 排查方式

传统排查： 凌晨 2 点收到告警 → kubectl → 发现问题"神秘自愈" → 但根因仍在

AI 排查（Agentic AI）：

1. Always-On Expertise： AI 不需要睡觉——告警触发时立即进入集群，在你打开电脑之前就提供可操作的洞见
2. Correlates Issues Across Cluster： 利用知识图谱检查 Pod、Node、Namespace 之间的类似异常
3. Runs Automated Investigations： 自动测试假设（"是 OOM 错误吗？" "Pod 失败是因为启动命令配置错误吗？"）——自动执行 runbook
4. Provides Resolutions： 如果找到解决方案就建议执行，否则列出明确的下一步

📚 课程关联： "Correlates Issues Across Cluster" = 第二周的 Agent 跨工具协调能力。传统工程师需要在多个仪表盘之间手动关联信号，AI Agent 可以自动完成这个过程——这正是 Agent 架构的核心价值。

阅读材料 4：Your New Autonomous Teammate（Product Deep Dive）

来源： Resolve AI Blog

AI Production Engineer 产品架构

Knowledge Graph（知识图谱）：

• 从集成 Resolve AI 的那一刻起，它开始全面映射你的环境
• 构建一个动态知识图谱——覆盖整个系统和工具
• 实时更新：新部署、系统事件、配置变更、代码变更时持续更新
• 使 Resolve AI 能够快速遍历所有依赖关系、Pod 和部署

告警触发时的工作流：

1. 像值班工程师一样立即开始调查
2. 自主创建和执行即时 runbook
3. 审查：metrics、dashboards、code changes、deployments、logs
4. 不到一分钟就已定位根因理论并建议修复步骤

"Vibe Debugging"（氛围调试）：

• Resolve AI 提出的新概念
• 工程师用自然语言描述问题 → AI Agent 自动执行整个调查循环
• AI 不是一次追踪一个假设，而是并行探索所有相关假设
• 同时从多个系统收集证据：Git 仓库、Grafana 仪表盘、K8s API、CI/CD 管道

真实案例： 调查 svc-entity-graph 服务的内存问题

• Agent 自动查询 Git 仓库找到时间窗口内的 1 个最近提交
• 同时搜索 Grafana，从数百个仪表盘中找到正确的那个，分析 13 个不同图表，定位出与内存问题最相关的 2 个
• 同时从上游服务拉取网络流量遥测数据
• 交叉验证 K8s API 的 Pod 配置以排除基础设施错误
• 最后通过 CI/CD 管道中同一变更的回滚来确认整个理论

公司背景：

• $35M Seed 轮，Greylock 领投
• 创始人 Spiros 共同创建了 OpenTelemetry（可观测性标准）
• 客户：Coinbase, Zscaler, Toast 等
• 客户反馈：MTTR 减少 70%+，on-call 生产力提升 75%，每位工程师每周节省 20 小时

📚 课程关联：

• "Vibe Debugging" 与第八周 "Vibe Coding" 形成平行对照——Karpathy 提出 Vibe Coding（用自然语言描述代码），Resolve AI 提出 Vibe Debugging（用自然语言描述问题）
• Knowledge Graph = 第四周 Context Engineering 的生产环境版本——CLAUDE.md 给 Agent 提供项目上下文，Knowledge Graph 给 Agent 提供整个生产系统的上下文

阅读材料 5：Role of Multi Agent Systems in Making Software Engineers AI-native

来源： Resolve AI Blog（基于 Stanford 研究生 AI 课程的演讲）

AI-Assisted vs AI-Native

为什么单一 Agent 不够？

复杂的生产环境需要多 Agent 系统：

• 单一 LLM 或单一 Agent 在复杂生产环境中失败
• 需要不同 Agent 专注不同领域：一个检查系统日志，另一个关注应用指标，第三个审查代码变更
• 多 Agent 协作能够处理常规和新颖问题

从 AI-Assisted 到 AI-Native 的转变：

• AI-Assisted：工程师用 AI 加速编码（Copilot, Cursor）
• AI-Native：AI 成为工程师操作生产系统的主要界面
• 目标：工程师在更高抽象层次运作，监督运行生产系统的 AI

📚 课程关联：

• "AI-Assisted vs AI-Native" 完美对应课程从第一周到第九周的演进：W1-W3 是 AI-Assisted（LLM 辅助编码），W4-W8 越来越接近 AI-Native（Agent 管理整个开发流程）
• "Multi Agent Systems" = 第四周 Claude Code 的 subagent 架构在生产环境的扩展——Claude Code 用多个 subagent 处理不同编码任务，Resolve AI 用多个 Agent 处理不同运维任务
• 第二周的 MCP 协议在这里再次出现：Resolve AI 使用 MCP 来连接和编排不同系统

阅读材料 6：Top 5 Benefits of Agentic AI in On-call Engineering

来源： Resolve AI Blog

五大收益

关键转变

"Agentic AI isn't just the next step in automation—it's a paradigm shift in incident management."

传统自动化：预定义脚本 → 触发条件 → 执行固定步骤 Agentic AI：理解上下文 → 生成假设 → 并行调查 → 自主决策 → 持续学习

📚 课程关联：

• "持续学习"对应第七周 Graphite 的 acceptance rate/upvote rate——两者都是通过反馈循环持续改进
• "从被动到主动"呼应第五周产品设计原则——工具应该让人专注高价值工作（设计/架构），而非低价值重复性工作（排查/调试）

🔗 六篇阅读材料的交叉主题

主题 1：可观测性是 AI 运维的基础

Google SRE Book（阅读材料 1）定义了运维的基本原则 → Last9（阅读材料 2）提供了可观测性的技术基础（Traces/Spans/Metrics） → Resolve AI（阅读材料 3-6）在此基础上构建 AI Agent。

关键洞见：没有良好的可观测性，AI 运维就是空中楼阁。 AI Agent 的"智能"完全依赖于它能获取的数据质量。

主题 2：从手动 → 自动化 → Agentic

手动运维（传统 SRE）
  → 收到告警 → 打开仪表盘 → 手动检查日志 → 生成假设 → 逐一验证
  
自动化（Runbook/脚本）
  → 收到告警 → 执行预定义脚本 → 如果匹配已知模式则修复
  
Agentic AI（Resolve AI）
  → 收到告警 → AI 自动理解上下文 → 并行生成多个假设 → 跨系统收集证据 → 自主判断 → 建议或执行修复

这个演进链条与课程从 W1 到 W9 的脉络完全一致：

• W1-W3：手动编码 → AI 辅助编码
• W4-W8：AI 辅助 → AI 驱动
• W9：AI 驱动 → AI 自主（在生产运维领域）

主题 3：知识保留 vs 知识流失

这与第七周 Blake Smith 的"心智模型对齐"深度相关——code review 让团队的心智模型保持同步，Knowledge Graph 让整个组织的运维知识保持同步。

主题 4：Vibe Coding → Vibe Debugging（课程新对称性）

主题 5：Multi-Agent 无处不在

共同架构模式： 将复杂任务分解为专业化子任务，每个子任务由专门的 Agent/Model 处理。

📚 第 1-9 周课程脉络

W1: LLM + Prompt Engineering（基础能力）
 ↓
W2: Agent + MCP Protocol（自主能力）
 ↓
W3: AI IDE + Specs-Driven（开发环境）
 ↓
W4: Agent Manager + Context Engineering（管理架构）
 ↓
W5: Product Design + Terminal ADE（产品思维）
 ↓
W6: Security + Testing（防护体系）
 ↓
W7: Code Review（质量保障——合并前的最后检查点）
 ↓
W8: Automated UI + App Building（极致应用——从"AI 辅助开发"到"AI 替代开发"）
 ↓
W9: Agents Post-Deployment（部署后——AI 运维、监控、事件响应）

第九周完成了 AI 软件开发的完整生命周期：

• W1-W5：Build（从想法到代码）
• W6-W7：Verify（测试和审查）
• W8：Deploy（生成和部署应用）
• W9：Operate（监控和维护生产系统）

下一周（W10）将是展望未来——软件开发的下一个十年。

⚠️ 注意

本周 Slides 尚未获取（Monday 11/17 Mihail 讲座 + Friday 11/21 Resolve AI 嘉宾讲座）。获取 Slides 后将补充完整的讲座笔记。

CS146S 第十周笔记总结：What's Next for AI Software Engineering

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

📅 课程安排

本周无阅读材料，无公开 Slides

嘉宾背景：Martin Casado

Martin Casado 是 Andreessen Horowitz (a16z) 的 General Partner，领导该公司 $12.5 亿的基础设施投资实践。

为什么这位嘉宾是课程的完美收尾：

• Stanford CS PhD → 学术视角
• Nicira 创始人 → 创业者视角
• VMware SVP → 大公司视角
• a16z GP → 投资人视角
• Cursor 董事会 → 直接连接到第三周 AI IDE 主题

第一讲：Software Development in 10 Years（Mon 12/1）

注：本讲无公开 Slides。以下基于课程主题、讲师视角和课程脉络进行综合分析。

课程大纲主题

1. Future of software development roles（软件开发角色的未来）
2. Emerging AI coding paradigms（新兴 AI 编码范式）
3. Industry trends and predictions（行业趋势和预测）

基于 W1-W9 课程脉络的回顾与展望

十周课程描绘的完整画面

W1: LLM + Prompt Engineering         → AI 作为"工具"
W2: Agent + MCP Protocol              → AI 作为"助手"
W3: AI IDE (Cursor)                   → AI 作为"搭档"
W4: Agent Manager + Context Eng.      → AI 作为"团队成员"
W5: Product Design + Terminal ADE     → AI 改变"谁能参与"
W6: Security + Testing                → AI 引入新风险
W7: Code Review                       → AI 保障质量
W8: Automated UI (v0, Bolt, Lovable)  → AI 作为"替代者"？
W9: Post-Deployment (Resolve AI)      → AI 管理"全生命周期"
W10: What's Next                      → AI 改变整个行业？

角色演变的五个阶段（课程暗含的框架）

📚 关键问题： 第五阶段会不会到来？什么时候到来？这正是 W10 要讨论的。

第二讲：Guest — Martin Casado, a16z（Fri 12/5）

以下基于 Casado 在 2025 年多次公开演讲、播客和文章中的核心观点，结合 CS146S 课程主题进行综合。

Casado 的核心观点体系

观点 1："This feels like 1996"——我们仍处于极早期

Casado 认为我们处于 AI 周期的极早期阶段——类比互联网的 1996 年，而非 2000 年泡沫期。

核心论据：

• AI 影响的市场规模是前所未有的——AI 编码本身就可能是一个数万亿美元的市场
• 每一波技术浪潮（云计算、移动、SaaS）都花了 10-15 年才完全展开
• AI 的基础设施层（compute, storage, networking）正在增加第四支柱——AI 本身

📚 课程关联： 这解释了为什么 CS146S 存在——如果我们在 1996 年，那么现在学习"现代软件开发者"的新范式就相当于 1996 年学习 Web 开发。

观点 2：AI 编码工具没有显著加速产品发布——但解决了两个问题

Casado 的意外判断：

"Every company I work with uses Cursor. Has that increased the velocity of the products coming out? I don't think that much."

AI 编码工具实际解决的两个问题：

1. 代码质量： "More robust, maintainable code bases with less bugs"——更健壮、更可维护、更少 Bug 的代码
2. 工程师士气： "It's almost like it's brought coding back. These old systems programmers, vibe coding at night just because it's become pleasant again."——让编程重新变得愉快

📚 课程关联： 这是对 W8 "Vibe Coding" 最深层的诠释——Vibe Coding 的核心价值不是"更快"，而是"更愉快"。这与 W5 Warp 的"terminal for the modern developer"理念一致——工具应该让工作变得enjoyable。

观点 3：市场碎片化——专业化胜过通用化

Casado 观察到 AI 工具市场正在碎片化——每个垂直领域都在产生专业化赢家：

关键区分： Cursor 就像"junior developer assisting senior engineers"（辅助高级工程师的初级开发者），而 Bolt/Lovable 服务的是"less technical users"（技术程度更低的用户）。

📚 课程关联： 完美映射 W3（Cursor = 专业开发者工具）vs W8（v0/Bolt/Lovable = 非技术用户工具）的区分。Casado 作为 Cursor 的董事会成员，亲身验证了这一市场定位。

观点 4：对 Agents "关闭控制循环"持怀疑态度

"I don't see a lot of evidence that we can close the control loop on these things."

Casado 对 Agent 自主性的担忧：

• "Close the control loop" = 让 Agent 自行启动任务、自主执行、自我评估、自我修正
• 目前的 Agent 在这个循环中仍然不够可靠
• AI 在预测过去方面很好，但在预测未来方面不行——不应被用于战略决策

📚 课程关联： 这与课程中反复出现的主题形成张力：

• W2 Agent 架构看起来很强大
• W4 Agent 管理可以给 Agent 框架约束
• W8 Mihail 说"once things break we're back to square 1"
• W9 Resolve AI 的 Slide 18："Complexity of incidents that can be resolved"——仍有局限
• Casado 作为投资人给出了更审慎的判断：Agent 很有潜力，但"关闭控制循环"尚需时日

观点 5：AI 是基础设施的"第四支柱"

传统基础设施三大支柱： Compute（计算）+ Storage（存储）+ Networking（网络）

Casado 的论点： AI 正在成为第四支柱——不是替代前三者，而是在其上叠加：

"Infrastructure doesn't go away — it layers."

这意味着：

• AI 不会"取代"软件——它会成为软件的新基础层
• 就像云计算没有取代服务器，只是改变了我们使用服务器的方式
• 我们需要从"空白纸"开始思考如何编程这些系统

📚 课程关联： 这为 W2 的 MCP 协议提供了更宏大的框架——MCP 不仅是 Agent 的工具协议，更可能是 AI 基础设施层的标准化接口，正如 HTTP 是网络层的标准化接口。

观点 6：AI 正在颠覆 SaaS 定价模式

传统 SaaS 时代： 价值按用户数衡量（per-seat pricing）

AI 时代： 价值按输出量衡量——从"有多少人使用系统"转向"系统代你完成了多少工作"

"In the AI era, value shifts to the work the software performs on your behalf."

📚 课程关联： 这与 W8 的 v0（"One-Click Deploy"）和 W9 的 Resolve AI（"不到一分钟定位根因"）的价值主张一致——产品的价值不在于你花多少时间使用它，而在于它替你完成了多少工作。

观点 7："Software is being disrupted"

"Software was always the disruptor. One of the most exciting things about the AI wave is software is being disrupted — we're being disrupted."

Casado 认为这是他一生中见过的最大变化：

• 之前每一波技术浪潮（互联网、移动、云）都是软件颠覆其他行业
• 这一次，AI 在颠覆软件本身
• 这就是为什么 Cursor 收购了 Graphite（W7 的 AI code review 工具）——整个软件开发工具链都在重组

Casado 观点与课程 W1-W9 的全景对照

🔗 课程完整回顾：W1-W10 的十周脉络

完整课程地图

     ┌─────────────────────────────────────────────────────────┐
     │                CS146S: The Modern Software Developer      │
     │                Stanford University · Fall 2025            │
     ├─────────────────────────────────────────────────────────┤
     │                                                           │
     │  ┌── BUILD ──────────────────────────────────┐           │
     │  │ W1: LLM + Prompt Engineering (基础)        │           │
     │  │ W2: Agent + MCP Protocol (自主)            │           │
     │  │ W3: AI IDE + Specs-Driven (环境)           │           │
     │  │ W4: Agent Manager + Context Eng. (管理)    │           │
     │  │ W5: Product Design + Terminal ADE (产品)   │           │
     │  └────────────────────────────────────────────┘           │
     │                                                           │
     │  ┌── VERIFY ─────────────────────────────────┐           │
     │  │ W6: Security + Testing (安全)              │           │
     │  │ W7: Code Review (质量)                     │           │
     │  └────────────────────────────────────────────┘           │
     │                                                           │
     │  ┌── DEPLOY ─────────────────────────────────┐           │
     │  │ W8: Automated UI + App Building (部署)     │           │
     │  └────────────────────────────────────────────┘           │
     │                                                           │
     │  ┌── OPERATE ────────────────────────────────┐           │
     │  │ W9: Agents Post-Deployment (运维)          │           │
     │  └────────────────────────────────────────────┘           │
     │                                                           │
     │  ┌── FUTURE ─────────────────────────────────┐           │
     │  │ W10: What's Next (未来)                    │           │
     │  └────────────────────────────────────────────┘           │
     │                                                           │
     └─────────────────────────────────────────────────────────┘

十周课程的核心张力

整个课程围绕一个核心张力展开：

AI 正在让软件开发变得更容易、更民主化——但同时也在引入新的复杂性、安全风险和不确定性。

贯穿课程的六大反复出现的主题

主题 1：Context 是一切（Context is Everything）

• W1: Prompt 工程的核心是提供正确的上下文
• W4: CLAUDE.md / AGENTS.md = 给 Agent 提供项目上下文
• W8: Bolt 系统提示词 = 约束生成行为的上下文
• W9: Knowledge Graph = 给 AI SRE 提供生产环境的上下文
• W10: Casado 说"good monitoring gardening"= 上下文质量

主题 2：Multi-Agent 架构无处不在

• W4: Claude Code main agent + subagents
• W7: Graphite AI reviewer（多维度检查）
• W8: v0 composite model family（多模型协作）
• W9: Resolve AI 多 Agent 并行调查

主题 3：民主化 vs 专业化的永恒张力

• W5: Warp "terminal for everyone" vs 需要 10x 工程才能构建
• W8: "Anyone can build an app" vs Lovable CVE 证明安全需要专业知识
• W10: Cursor（专业开发者）vs Bolt/Lovable（非技术用户）

主题 4：安全是被低估的隐忧

• W6: Copilot RCE（CVE-2025-53773）
• W8: Lovable RLS 漏洞（CVE-2025-48757）+ 账户接管
• W9: "Security could be a new attack vector"
• 每当 AI 获得更多系统权限，安全风险同步升级

主题 5：从 AI-Assisted 到 AI-Native 的演进

• W1-W3: AI 作为助手
• W4-W7: AI 作为团队成员
• W8-W9: AI 作为自主执行者
• W10: 这个演进会走多远？（Casado 持审慎态度）

主题 6：人类工程师的不可替代性

• W7: "AI 检测率 55-60%"——还有一半错误需要人类发现
• W8: "Once things break"——需要人类修复
• W9: "Complexity of incidents"——复杂事故需要人类判断
• W10: Casado "agent 控制循环未关闭"——人类监督仍然必要

课程嘉宾阵容回顾

嘉宾设计逻辑：

• W5: 开发工具创始人（产品思维）
• W7-W8: 技术负责人（工程深度）
• W9: CTO + 研究员（技术 + 学术）
• W10: 顶级投资人（行业全景）

从创始人 → 工程师 → CTO → 投资人，视角从微观走向宏观。

⚡ 第十周核心金句

Martin Casado: "This feels like 1996."

Casado: "Every company I work with uses Cursor. Has that increased the velocity of the products coming out? I don't think that much."

Casado: "It's almost like it's brought coding back. These old systems programmers, vibe coding at night just because it's become pleasant again."

Casado: "I don't see a lot of evidence that we can close the control loop on these things."

Casado: "Infrastructure doesn't go away — it layers."

Casado: "Software was always the disruptor. One of the most exciting things about the AI wave is software is being disrupted — we're being disrupted."

Casado: "In the AI era, value shifts to the work the software performs on your behalf."

📚 CS146S 全课程总结

一句话总结每周

课程的终极问题

十年后，"软件工程师"这个角色还存在吗？

课程给出的答案： 存在，但会发生根本性变化。

最终洞见： 未来的软件工程师不是"写代码的人"——而是定义问题、设计系统、监督 AI、确保质量的人。这正是 CS146S 的副标题——"The Modern Software Developer"——真正的含义。

本周暂无阅读材料笔记。