以前我们担心的是AI把业务代码改坏，现在多了一层——它开始能改自己的配置、自己的规则、自己的权限。同一件事换个方向看，就是它能碰到的东西变多了，其中不少是你从来没打算让它碰的。多数人只在意它写出来的代码对不对，很少回头看它读了什么，而后者才是真正需要提前设防的地方。
AI编程助手的日常不是只写代码。它要读文件才知道项目长什么样，要跑命令才知道改完对不对，要看配置才知道环境怎么连起来。这些动作每一个都是它伸出去的手，而你不可能每次都盯着看。所以设防的关键在它动手之前，而不是出了问题之后。还有一个常被忽略的动作是搜索：它可能会在项目里全文查找某个关键词，用来定位一段逻辑，这时候凡是命中关键词的文件都会被打开看一眼。你以为它只是在改一个接口，它可能已经顺带读过了配置文件里的敏感行。这不是它有意为之，是找代码的自然结果。
它能碰到的，不只是业务代码
先分清它可能读到什么。第一类是存放密钥的文件，最常见的形态是项目根目录下的.env，里面往往躺着数据库密码、第三方接口的密钥、云服务的访问凭据。这类文件本身没有任何问题，问题在于它和源码放在一起，而AI读源码的时候不会自动绕开它。判断一个文件要不要设防，有个简单的办法：假设它明天被完整贴到公开的地方，你会不会紧张。会紧张的就是需要提前排除的。按这个标准过一遍项目，往往能发现几处平时根本没往这个方向想过的地方，比如某个测试用的脚本里，也可能硬编码着一把真实的密钥。
第二类是部署和持续集成的配置，这类文件里通常写着服务器地址、部署密钥、镜像仓库账号，基本都是明文存放。第三类是服务器连接凭据，可能是家目录下的.ssh，也可能是项目里那份写着生产环境连接串的配置。三类东西有个共同点：它们不是代码，改错了不会报错，但被读走一次，损失往往是不可逆的。这三类文件还有一个共同特点：它们往往不在你的日常视线里。写业务代码的时候，你天天打交道的是那几个核心文件；而配置、凭据这类东西，可能几个月都不会打开一次。正因为不常看，它们被改动或者被读取的时候，你也最不容易察觉。
还有一个容易被忽略的细节：它读到的东西会进上下文。上下文是它带到后续任务里的那部分信息，也会留在你和它的对话记录当中。一份被读进来的密钥，影响的不只是这一次操作。所以防护的重点应该是“不让它读”，而不是“提醒它别外传”——前者可以验证，后者只能靠相信。
把它的手按住，从这几点开始
第一道是权限规则。Claude Code官方设置文档里给出的示例，正好就是这一类：在设置文件的permissions下写deny规则，把读取具体文件的动作直接禁掉，官方例子用的就是.env和.env.*。这类规则写在项目里，对所有使用这个项目的人都生效，是最省事也最不容易被忘掉的一层。这类规则的好处是它不依赖你每次都在场。规则写在项目里，谁用这个项目、什么时候用，都会先经过它。坏处是它需要你先知道有哪些文件该被排除，所以真正花时间的不是写规则，是先把项目里的敏感文件梳理一遍，这一步没人能替你做。
第二道是别把权限提示全关掉。工具在动手之前会问你一次，这个提示不是打扰，是最后一道人工检查。很多人嫌它烦，一次性选了“以后不再问”，等于把这道闸门直接拆了。官方文档里，deny和ask两类规则是立即生效的，而allow反而需要先信任目录——这个优先级顺序本身就在提示你，禁止比放行更值得依赖。
第三道是分清“看”和“改”。让它读一份配置帮你排查问题，和让它直接改这份配置，是两件不同的事。前一种你可以先给它一份副本，后一种更稳妥的做法是让它只给建议、由你自己执行。涉及部署脚本和服务器配置的时候，“它说怎么做”和“它替你做”之间的差别，就是出事和没出事的差别。
顺带说一个习惯：把敏感文件在版本控制里排除掉，改用一份只有字段名、没有真实值的样例文件替代它放进仓库。这样一来AI读到的是一份模板，它知道项目有哪些配置项，但拿不到真实凭据。这个做法本来不是为了防AI，它一直是团队协作的常规要求，只是AI读文件这个新场景让它变得更要紧。还有一个值得养成的做法，是把敏感文件放在项目的上层目录，让它根本不在工作目录里。这样即便规则没写全，它也不在这次操作的范围内。多重防护的意义不在于形式，而在于任何一层单独失效的时候，后面的那层还在。
能力升级的代价，是边界的定义得跟上。它越能干，你越要先想清楚哪几个地方不许它碰。这三道锁不是要把AI关起来，而是让它在你能兜住的范围内干活——它改坏一行业务代码，你还能回滚；它读走一份密钥，你可能连它什么时候读的都不会知道。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
