夜雨聆风这两年，很多人写代码多了一个新动作：
看到一个项目，先 clone 下来，打开 Cursor、Claude Code 或 Codex，让 AI 读一遍，再问它：“这个项目怎么跑？”“报错帮我修一下。”“这个功能补上。”
这件事太自然了。自然到我们经常忘了问一句：AI 读进去的东西，真的是可信的吗？
最近 TrapDoor 这类供应链攻击给了一个很具体的提醒：AI 助手读进去的内容，不一定只是背景资料。它也可能是别人提前塞好的指令。
以前我们怕恶意包，怕 postinstall，怕构建脚本，怕 .env 泄露。现在还要多看一类文件：项目里的“AI 工作说明书”。
比如：
CLAUDE.md.cursorrulesAGENTS.md.github/copilot-instructions.mdMCP 配置文件
这些文件本来是好东西。它们告诉 AI：这个项目怎么组织，代码风格是什么，测试怎么跑，提交前要注意什么。
问题也在这里。
AI 会读它们。只要 AI 会读，它们就不再只是文档。
真正危险的，不只是恶意包
据安全资讯报道，TrapDoor 被描述为一次波及 npm、PyPI 和 Crates.io 的供应链攻击。不同来源对恶意包数量的统计不完全一致，所以这篇不把“到底多少个包”当重点。
对普通开发者来说，更值得注意的是攻击思路。
传统供应链攻击大多是这样：你装了一个包，包里的安装脚本、构建脚本或运行时代码开始偷钱包、SSH key、GitHub token、云凭证、.env 文件。
这个逻辑大家已经比较熟了。npm 的 postinstall、Rust 的 build.rs、Python 包导入时执行代码，都是老攻击面。
TrapDoor 这类事件让人不舒服的地方在于：攻击者不只盯着包本身，还盯上了 AI 助手会读取的项目规则文件。
报道中提到，攻击者尝试写入或提交被污染的 .cursorrules 和 CLAUDE.md。这些文件表面上像项目规范，甚至可能看起来只是普通说明，但里面可以藏人眼不容易注意的内容，比如零宽字符、双向 Unicode 控制字符，或者伪装成“安全扫描”“依赖检查”的操作建议。
人看不出来，AI 可能会照单全收。
这就是变化最大的地方。
以前攻击者要让你的机器做坏事，通常得靠脚本、二进制、安装钩子。现在多了一条路：污染 AI 会读的文字，让 AI 在后续写代码、跑命令、修 bug 的时候，把危险动作包装成正常工作流。
这不等于 AI 助手会无条件自动执行一切。多数工具仍然有权限提示、沙箱和审批机制。
但如果你开了自动模式，或者习惯一路点同意，或者让助手在刚 clone 的陌生项目里自由跑命令，风险就会被放大。
Markdown 为什么会变危险
关键不在 Markdown。
关键是三件事连在了一起。
第一，AI 助手会读项目上下文。
它不是只看你输入的那句 prompt。它会读 README、代码、目录结构，也会读专门给它写的规则文件。CLAUDE.md 和 .cursorrules 的本意，就是给助手提供长期规则。
第二，AI 助手有行动权。
它能改文件，能写脚本，能调用终端，能安装依赖，能读取测试输出。有些工具还能连浏览器、数据库、MCP 服务。
如果它只是聊天，坏指令最多污染回答。可一旦它能行动，坏指令就可能变成真实后果。
第三，人会放松警惕。
我们看到 package.json 的 scripts，会多留个心眼。看到 curl | bash，会觉得危险。看到陌生二进制，会停一下。
但看到 CLAUDE.md 呢？
很多人会下意识觉得：这不就是给 AI 看的说明吗？
这就是攻击者想要的缝。
安全实践里有一个说法很准确：这些 AI 配置文件，要像对待不可信项目里的 Makefile 或安装脚本一样对待。
它们不一定直接执行，但它们会影响一个能执行东西的系统。
普通人最容易踩的三个坑
第一个坑，是把“文档”当成“无害”。
AI 时代，文档和指令之间的边界变薄了。只要某个文件会进入模型上下文，它就可能影响模型后续行为。
尤其是这些文件：
CLAUDE.mdAGENTS.md.cursorrules.cursor/.github/copilot-instructions.md.claude/settings.jsonMCP 配置文件
它们不应该被当成普通说明文档略过。
第二个坑，是在陌生项目里直接开自动模式。
自动模式本身不是问题。对可信项目、低风险任务、隔离环境，它能省很多时间。
但如果你刚 clone 一个陌生仓库，还没看过配置文件、脚本和依赖，就让 AI 自由跑命令，本质上是把方向盘交给一个刚读完陌生说明书的司机。
你不知道那份说明书有没有被改过。
第三个坑，是只查源码，不查“给 AI 的规则”。
很多团队的 code review 还停留在源码、依赖、CI 配置上。现在，.cursorrules、CLAUDE.md、MCP 配置、hook 配置，也应该进入审查范围。
有些攻击不是让代码当场变坏，而是让 AI 以后持续生成坏代码，或者持续建议危险命令。
这更难发现。
因为你看到的是“AI 建议”，不是“恶意脚本执行”。
克隆陌生项目后，先做这四件事
第一，先搜一遍 AI 配置文件。
在项目根目录跑：
find . -maxdepth4 \( -name'CLAUDE.md'-o-name'AGENTS.md'-o-name'.cursorrules'-o-name'copilot-instructions.md'-o-name'mcp.json' \) -print看到这些文件，不代表项目一定危险。它只代表你该先看一眼。
第二，检查隐藏字符和可疑命令。
普通文本编辑器不一定能显示零宽字符和双向控制字符。文件存在时，可以先用：
cat-v CLAUDE.md
cat-v .cursorrules
重点看有没有奇怪的不可见字符、长段乱码、base64、curl、wget、bash -c、eval、/dev/tcp、读取 .env、读取 ~/.ssh、上传文件、请求陌生域名等内容。
第三，先不开自动模式。
第一次让 AI 读陌生项目时，先只问解释类问题：
这个项目结构是什么？
有哪些脚本？
测试怎么跑？
哪些文件会影响 AI 行为？
不要一上来就说“帮我安装依赖并修复所有问题”。
第四，给 AI 的权限分层。
可信项目，可以给高一点权限。
陌生项目，先只读，不写；先不联网；先不碰 .env、SSH、浏览器 cookies、云凭证；需要跑命令时，一条一条确认。
这不是保守。只是把“省事”和“失控”隔开。
什么东西算代码，变了
过去我们有一个直觉：代码危险，文档相对安全。
AI 编程助手把这个直觉打破了。
因为对 AI 来说，很多文档不是给人看的背景，而是会影响下一步行动的输入。
只要它能改变行动，它就应该被当成代码来审。
这才是 TrapDoor 这类事件最值得普通人记住的地方。
以后讨论供应链安全，不能只问：
这个包会不会执行恶意脚本？
还要问：
这个项目里，有没有东西会教我的 AI 助手做错事？
AI 助手越强，说明书越重要。说明书越重要，污染说明书的收益就越高。
所以，别再把 CLAUDE.md、.cursorrules 这类文件当成“项目里的小纸条”。
它们更像门禁卡。
门禁卡不一定自己开门，但它决定谁能进去，进去后能做什么。
从今天开始，克隆陌生项目后，先看门禁卡，再让 AI 进门。
