夜雨聆风跟着斯坦福 CS146S 学 AI Agent 开发，Week 6 的主题是「AI 安全与测试」——客座嘉宾 Semgrep CEO Isaac Evans。这周学到的最大冲击不是技术细节，而是一个事实：你每天在用的 AI 编程工具，本身就可能是攻击入口。一个藏在代码文件里的隐形指令，就能让 Copilot 接管你的电脑。
上周 Week 5 学的是 Warp CEO 的「编码制度」——怎么让一个团队都用好 AI，见：斯坦福大学现代软件开发课程Week 5：Warp CEO 的编码制度——每个任务必须从 Prompt 开始
Week 6 换了个方向：不是怎么用好 AI，而是用 AI 的时候怎么不被坑。
这周的客座嘉宾 Isaac Evans 是 Semgrep 的 CEO。Semgrep 做的是代码安全扫描工具——专门帮你找代码里的安全漏洞。他来斯坦福讲的核心问题是：当 AI 帮你写了大部分代码之后，谁来保证这些代码是安全的？
答案比我预想的复杂得多。
01丨你的 AI 搭档，可能是黑客的后门
先说一个今年真实发生的安全事件。
安全研究员在 GitHub Copilot 里发现了一个远程代码执行漏洞（CVE-2025-53773）。攻击过程是这样的：
Step 1 攻击者在一个源代码文件里嵌入一段肉眼看不见的隐藏指令（用 Unicode 不可见字符）
Step 2 你用 Copilot 打开这个文件，随便问了个问题
Step 3 Copilot 读到了隐藏指令，偷偷在你的项目配置文件里加了一行："chat.tools.autoApprove": true
Step 4 这行配置让 Copilot 进入了"YOLO 模式"——自动批准所有操作，不再弹确认框
Step 5 攻击者通过 Copilot 在你的电脑上执行任意命令
你的电脑就这样被接管了。 Windows、macOS、Linux 都能中招。
发现这个漏洞的研究员甚至演示了更极端的场景：通过 Copilot 下载恶意软件，把开发者的电脑加入僵尸网络——他管这叫"ZombAI"。
这个漏洞已经修复了。但它暴露的问题没有修复：AI 工具能读文件、能写文件、能执行命令——如果有人在 AI 读到的内容里埋了恶意指令，AI 就可能变成攻击者的提线木偶。
课程 Slides 把 AI 时代的新攻击方式分成了四类：
| Prompt Injection | ||
| Tool Misuse | ||
| Code Attack | ||
| Intent Breaking |
这四种攻击有一个共同点，跟传统网络攻击完全不同：
传统攻击：黑客 → 你的服务器
AI 时代的攻击：黑客 → AI 读到的内容 → AI → 你的电脑
你不是旁观者，你是攻击链的传导者。你打开一个被污染的文件、引用一个被注入的网页——这些日常操作就能触发攻击。
02丨AI 能帮你找安全漏洞吗？能，但别太指望
安全威胁变多了，好消息是检测能力也在变强。
传统的安全检测工具有三种，课上用了一个很直观的分类：
SAST（静态分析）：不运行代码，直接扫描源代码找危险写法。像看设计图纸找隐患。
DAST（动态分析）：把程序跑起来，从外面模拟黑客攻击。像派人去撞门踹窗。
SCA（成分分析）：检查你用的第三方库有没有已知漏洞。像检查食材有没有毒。
这三种方法有一个共同局限：本质上都是模式匹配——拿着一本"通缉犯照片册"去认脸，照片册里没有的就认不出来。
AI 理解代码的"意思"，不只是匹配模式。那 AI 能不能做得更好？
Semgrep 团队做了一个认真的实验：让 Claude Code 和 OpenAI Codex 去扫描 11 个真实的开源项目，找安全漏洞。不是教学用的小玩具，是真正在生产环境跑的、最大超过 25 万行代码的 Python 应用。然后人工审核了全部 445 条发现。
结果：
每找到 1 个真漏洞，AI 同时报出 5-6 个假的。
我第一反应跟你可能一样：误报率这么高，不可用。
但有一个容易忽略的事实：这 67 个真漏洞里，大约 20 个是高危漏洞——越权访问、路径穿越、认证绕过这类一旦被利用就出大事的问题。这些漏洞在项目里存在了好几年，经过了无数次人工代码审查都没被发现。AI 用 114 美元跑了一遍就找到了。
还有一个更极端的案例。安全研究员 Sean Heelan 用 OpenAI 的 o3 模型，找到了 Linux 内核里的一个零日漏洞（CVE-2025-37899）。这是一个并发场景下的 use-after-free 漏洞——需要理解多个线程如何共享和释放内存对象，连很多资深安全工程师都不一定能发现。
但 Heelan 也说了实话：同样的 prompt 跑 100 次，只有 8 次成功。
AI 做安全检测的真实定位：不是银弹，是"便宜但需要人复核的安全实习生"。 用它的规模覆盖能力做第一道筛，人做第二道判断。
做产品经理的都知道一个经典矛盾——精确率和召回率的权衡：检测灵敏度调高了误报也高，调低了又会漏掉真问题。AI 安全检测面临的是一模一样的困境。
03丨学完这周，我做了一件事
Week 6 让我第一次认真想了一个问题：我自己的 AI 工作流安不安全？
我每天用 Cursor 跟 AI 搭档协作，给它配了一套规则体系（Rules 文件），接了 MCP Server 让它能读写文档。课上讲的那些攻击——提示注入、工具滥用——理论上都可能发生在我身上。
学完之后我做了一件事：让 AI 扫描了一遍我自己的 Rules 文件，检查有没有敏感信息泄露。
检查了什么：API Key、密码、数据库连接串、内网地址、个人信息、业务数据样本。
结果：没有发现密钥密码这类高风险项，但发现了一些中风险项——内部系统 URL、文档分享链接带访问参数、一些业务数据样本值。这些东西在本机使用没问题，但如果哪天被推到了公开仓库，就会泄露组织内部信息。
处理很简单：把个人信息做了模糊化，然后在全局 gitignore 里加了一行配置，让这个目录永远不会被意外上传。从扫描到修复，前后不到 5 分钟——但如果不是这周学了安全检测的知识，我根本不会想到要做。
3 个带走的安全常识
第一，人工确认是最后一道硬防线，别关掉。 Copilot 那个漏洞之所以能成功，关键一步是绕过了人工确认。只要"每个危险操作都需要你点确认"这个机制在，攻击链就断了。嫌烦也别关。
第二，AI 读到的外部内容可能被污染。 网页、文档、代码文件——这些内容里都可能被嵌入对 AI 的隐藏指令。不是说不能用，而是别让 AI 在没有你确认的情况下，基于外部内容执行敏感操作。
第三，安全检测的"Shift Left"理念——越早检查越便宜。 在代码写的时候就扫描（SAST），比等程序上线后再被黑客打一遍（DAST）便宜太多。不管你是写代码还是做产品，"早发现早修复"这个原则通用。
下周 Week 7 的主题是「Modern Software Support」——AI 代码审查。客座嘉宾是 Graphite 的 CPO Tomas Reimers。
如果你也在跟这门课，或者对 AI 安全有想法，评论区聊。
点击关注下方账号，学习AI的路上，带你一起进步~
