diff --git a/InBox/吴恩达最新ai课_119讲_AI写的代码_你根本看不过来_Qodo亲授AI代码审查_为什么review质量取决于上下文而_BV1XT3t6hEEH_笔记.md b/InBox/吴恩达最新ai课_119讲_AI写的代码_你根本看不过来_Qodo亲授AI代码审查_为什么review质量取决于上下文而_BV1XT3t6hEEH_笔记.md
new file mode 100644
index 0000000..1c9ed45
--- /dev/null
+++ b/InBox/吴恩达最新ai课_119讲_AI写的代码_你根本看不过来_Qodo亲授AI代码审查_为什么review质量取决于上下文而_BV1XT3t6hEEH_笔记.md
@@ -0,0 +1,114 @@
+# AI 代码审查实战课（Qodo × DeepLearning.AI）
+
+## 核心问题
+
+AI 生成代码的速度已超出人工 review 的极限，导致人类本身成为瓶颈。与此同时，AI 写的代码可能：
+
+- PR（Pull Request）表面看起来完全合理，实际却遗漏了某项关键需求
+- 引入安全漏洞
+
+因此 code review 工作流也需要进化。
+
+## 课程目标
+
+1. 学习如何在实际开发工作流中使用 AI code review agents
+2. 亲手搭建一个 AI code review agent，理解这类系统底层的工作原理（上下文检索、推理方式）
+3. 理解为什么"引导方式"不同会导致不同的审查结果
+
+## 课程内容结构
+
+```
+Part 1  什么是好的 code review，以及 AI code review 如何融入当下开发工作流
+Part 2  让 AI 审查更有效的实战技巧
+        - 开发者打开 PR 之前先做本地审查（local code review）
+        - 提供更丰富的上下文（任务描述、仓库信息）
+        - 按潜在影响对审查发现进行优先级排序（triage）
+Part 3  深入理解：为什么上下文（context）才是审查质量的最大决定因素
+        - 仅使用更强的模型不够——没有正确信息，再强的模型也无效
+Part 4  从零搭建一个 context-aware AI code review 系统
+        - Step 1: 构建 context engine（上下文引擎），用于检索相关代码
+        - Step 2: 引入 specialized agents（专精化 agent），结合不同领域专长
+```
+
+## 关键理念
+
+| 误区 | 正确认知 |
+|---|---|
+| 模型越强，审查质量越高 | 审查质量取决于**上下文**而非模型本身 |
+| AI 写的代码可以直接 review | 需要本地预审 + 上下文增强 + 风险分级 |
+| PR 看着合理 = 代码正确 | 表面合理 ≠ 无安全漏洞或需求遗漏 |
+
+## Part 2 实战技巧详解
+
+### 1. 开发者本地预审（Pre-PR Review）
+在打开 Pull Request 之前，由开发者本人在本地先用 AI 跑一次 review。目的是：
+
+- 在代码还属于"草稿"阶段就发现问题
+- 减少 PR 中的噪音，让 reviewer 聚焦真正的风险
+- 避免 AI 生成的大量代码一股脑涌入 PR
+
+### 2. 提供更丰富的上下文
+AI reviewer 的输出质量取决于输入信息。需要在 prompt 或上下文中提供：
+
+- 本次任务的目标 / 需求描述
+- 所属仓库的整体信息（README、目录结构、依赖等）
+- 相关的已有代码模块
+- 编码规范或安全规范
+
+### 3. 按风险分级的 Triage
+不要把所有 finding 一视同仁。应根据潜在影响排序：
+
+| 优先级 | 类别 | 示例 |
+|---|---|---|
+| 高 | 安全漏洞 | SQL 注入、权限绕过、敏感信息泄露 |
+| 高 | 需求遗漏 | 缺失关键功能、未处理边界条件 |
+| 中 | 性能 / 正确性 | 复杂度高、潜在 bug |
+| 低 | 风格 / 规范 | 命名、注释、格式 |
+
+这样 reviewer 和开发者都能聚焦高风险问题，避免"告警疲劳"。
+
+## Part 4 从零搭建 Context-Aware AI Code Review 系统
+
+### Step 1：构建 Context Engine（上下文引擎）
+
+Context engine 的作用是从仓库中检索出与当前 PR 相关的代码，为 AI reviewer 提供"正确的信息"。
+
+核心流程：
+
+1. **分块（Chunking）**：将仓库中的代码文件切分成可检索的单元（按文件、类、函数或语义块）
+2. **嵌入（Embedding）**：使用 embedding 模型将每个代码块转为向量
+3. **向量检索（Vector Retrieval）**：当审查某个 PR 时，将 PR 的变更内容也转为向量，在向量数据库中检索语义最相关的代码块
+4. **组装上下文**：把检索到的代码块 + PR diff + 任务描述组装成 prompt，输入给 LLM
+
+```
+PR Diff ──┐
+          ├─→ Embedding ──→ Vector Search ──→ Relevant Code Chunks
+仓库代码 ──→ Chunking ──→ Embedding ──→ Vector DB ──┘
+                                                       │
+                       Task Description ──────────────┴──→ Prompt → LLM Reviewer
+```
+
+### Step 2：引入 Specialized Agents（专精化审查 Agent）
+
+单一的通用 reviewer 难以覆盖所有领域。更好的方式是组合多个专精 agent：
+
+| Agent | 关注领域 |
+|---|---|
+| 安全专家（Security Agent） | 检测安全漏洞、注入风险、权限问题 |
+| 规范专家（Style / Spec Agent） | 检查是否符合团队编码规范、合规要求 |
+| 通用审查者（General Reviewer） | 需求覆盖、逻辑正确性、可读性 |
+
+工作方式：
+
+- 每个 agent 独立对 PR 进行 review，输出各自领域的问题清单
+- 最终汇总结果时按风险等级 triage
+- 这种"分而治之"的思路让每个 agent 的 prompt 更聚焦，输出更准确
+
+## 课程制作信息
+
+课程由 DeepLearning.AI 与 Qodo 合作推出，由吴恩达主持。
+
+致谢（来自 DeepLearning.AI 的贡献者）：
+- Ismail Gagari
+- Brenan Brown
+- Nick Lewis
\ No newline at end of file