看不见的指令：.cursorrules 文件如何偷偷控制你的 AI 编程助手

一份看起来再普通不过的项目规则文件，可能正在悄悄指挥你的 AI 编程助手做你没授权的事。这不是科幻情节，而是 AI 配置扫描工具 Exepal 在实际检测中发现的问题。

当规则文件成为攻击面

Cursor 等 AI 编程工具允许开发者通过 .cursorrules 文件定义 AI 代理的行为——比如代码风格、技术栈偏好、禁止修改的目录。这个机制本身设计合理，但 Exepal 的扫描工具揭示了一种被忽视的风险：配置文件中的内容并不总是肉眼所见的内容。

据该工具展示的示例，一个看似正常的项目规则文件，扫描后暴露出 11 个问题，其中 10 个被标记为高危，并且文件中藏有 185 个隐藏字符。

扫描器不仅读取 .cursorrules，还覆盖 clawed .md 文件以及 MCP（Model Context Protocol）配置文件。这些文件共同构成了 AI 代理的"行为说明书"，也因此成为潜在的攻击载体。

MCP（Model Context Protocol）是 Anthropic 提出的一种开放协议，用于让 AI 应用以标准化方式连接外部数据源与工具。它采用客户端—服务器架构：AI 应用作为客户端，通过 JSON-RPC 与 MCP 服务器通信，服务器则暴露资源（resources）、工具（tools）和提示模板（prompts）。MCP 配置文件通常声明要启动哪些服务器、使用什么命令和参数，因此它不只是数据，而是能决定 AI 代理可调用哪些外部能力的控制面。一旦这类配置被篡改，攻击者就可能借机让代理连接恶意服务器或执行非预期工具调用，这也是文章将其与 .cursorrules 并列视为攻击载体的原因。

不可见 Unicode：藏在眼皮底下的指令

这个案例最值得警惕的地方在于攻击手法的隐蔽性。文件中植入了不可见 Unicode 字符，这些字符在编辑器里不显示，却能被 AI 代理读取并执行。

注入的指令内容很具体：要求代理在每一个页面上添加追踪脚本，并且明确要求代理不要提及这件事。换句话说，攻击者利用配置文件的解析机制，把一个隐蔽的数据采集行为伪装成了一条普通的规则指令。

这种手法之所以危险，在于它绕过了人工审查这一最常见的防线。开发者审阅规则文件时看到的是正常的配置项，但 AI 代理执行的是另一套被隐藏的指令。

从攻击面来看，此类风险不只来自自己编写的配置文件。开源项目模板、团队共享的配置、第三方提供的 MCP 配置，任何一个环节被植入隐藏字符，都可能把恶意指令带进你的开发流程。

不可见 Unicode 字符是指那些在文本渲染中不产生可见字形的码位，常见的有零宽空格（U+200B）、零宽非连接符（U+200C）、零宽连接符（U+200D）、字节顺序标记（U+FEFF）以及双向控制字符（如 U+202A–U+202E）。这些字符在多数编辑器和终端中不会显示，但它们依然作为文本流的一部分被程序读取。攻击者可将恶意指令编码进这些不可见码位，或利用它们打乱可见文本的顺序、伪装关键词，从而绕过基于肉眼的人工审查。由于 Unicode 标准本身需要这些字符来支持多语言排版，简单的禁用并不可行，更现实的做法是在 CI 或提交钩子中检测并剥离可疑码位，同时对配置文件做规范化处理。

配置文件的信任边界需要重新审视

AI 编程工具的普及速度很快，但围绕配置文件的审阅习惯和安全工具还没有跟上。开发者通常会审查代码依赖、检查 npm 包来源，却很少逐字节检查一个 .cursorrules 文件里有没有零宽字符。

Exepal 提供的扫描服务免费且不存储扫描内容，这类工具的出现说明市场已经开始意识到这个缺口。不过单靠扫描工具并不构成完整防护——更根本的问题在于，AI 代理对配置文件的执行权限过大，而配置文件的来源往往缺乏验证。

对使用 Cursor 或类似工具的团队来说，几个务实的做法值得考虑：把规则文件和 MCP 配置纳入代码评审流程；对来自外部的配置文件保持警惕；在引入第三方配置前先做扫描。这些措施成本不高，但能挡住最直接的一类风险。

AI 代理越能干，它能读取和执行的内容就越需要被当作代码一样对待。规则文件不是文档，它是可执行的行为指令，这个认知转变可能是眼下最需要的。