用 AI 写 Shell 脚本很爽,但先看看它埋了什么雷

今天开一个新系列：AI 安全运维。不是聊概念，是从运维人每天都在做的事切入——第一件事就是：用 AI 生成脚本。

先把丑话说完。2026 年了，AI 写脚本的能力确实强，但 USENIX Security 的研究测了 16 款主流代码生成模型、50 万份样本：商业模型平均 5.2% 的包幻觉率（开源模型 21.7%），而且即便推荐真实存在的依赖，近半数带着已知 CVE 或是过时版本。AI 不会实时去 PyPI/npm 查证——它按"历史概率"推荐，会一本正经地推荐一个不存在的包。

这个漏洞有一个专有名词：slopsquatting（幻觉包抢注）——攻击者提前注册 AI 爱编造的那些包名，把恶意代码装进去，等 AI 推荐给下一个人。

更麻烦的是今年 4 月的研究：五款前沿模型（Claude/GPT/Gemini/DeepSeek 系）共同幻觉生成了 127 个相同的假包名，其中 53 个在 PyPI/npm 上至今仍可注册。为什么不同模型会编出同一个名字？它们读过同一批有错的教程。也就是说：一次恶意抢注，可以同时收割多家模型的用户。

而真实攻击已经发生：年初，假包 react-codeshift 借助 AI Agent 生成的代码扩散进了 237 个代码仓库——不是人工复制的，是Agent 自己生成、自己执行、自己提交的。

这篇给你 6 道检查，把雷排掉。命令都可复制。

检查 1：包名必须去仓库核实，别信 AI 的 import

把 AI 生成的每一行 import / npm install 都当成不可信输入。三条硬标准：

# 存在性：这个包在仓库里有吗？curl -s https://pypi.org/pypi/<包名>/json | head -c 200# 注册时间：是不是"最近刚出现"？（幻觉包被抢注后都很年轻）curl -s https://pypi.org/pypi/<包名>/json | grep created# 发布者：有没有长期维护记录？

判断标准就一句：包要存在、注册时间要早于你的项目、发布者要有历史。Socket、Snyk 这类工具能把这个检查自动化进 IDE/CI，预算够就上。

检查 2：脚本先过静态检查，再谈运行

AI 生成的 Shell 大概率语法是对的，但语义和健壮性是另一回事：

# shellcheck：静态扫描，装一次受益终身shellcheck deploy.sh# bash 语法树检查 + 干跑（能用 --dry-run 的工具都用上）bash -n deploy.shansible-playbook site.yml --check --diff   # Ansible 篇讲过的老规矩

AI 特别爱犯的错：没引号的变量、cd 失败后继续往下跑（所以开头必有 set -euo pipefail）、把 --force 当默认答案。shellcheck 会全部指出来。

检查 3：危险命令模式，逐条人审

以下模式出现在 AI 生成的脚本里，必须人工确认再跑——不是不信任 AI，是这些操作不可逆：

检查 4：第一次运行必须在沙箱，且不带任何凭证

Agent 场景最危险的一点：post-install 脚本在一个装满 API key、云凭证、CI token 的环境里执行——这正是 react-codeshift 能扩散的原因。所以：

# 用一次性容器跑首验，不挂任何密钥docker run --rm -it --network none \  -v $(pwd):/work -w /work python:3.12-slim \  bash /work/ai-generated-script.sh

--network none 断网首跑看行为，确认没有奇怪的外连再放开。

检查 5：敏感信息永远不进 AI 上下文

反过来同样成立：你贴给 AI 的内容，也是泄露面。生产 IP、内网拓扑、.env 内容、数据库连接串——脱敏后再问。85% 的企业在用 AI 编码工具，只有 9% 配了对应的安全管控；别让你的粘贴行为成为那 9% 之外的事故源。

检查 6：依赖进 lockfile，安装按 digest 固定

AI 推荐的版本号是"大概率对"，不是"确定对"：

# Python：锁住整棵依赖树pip freeze > requirements.lock# npm：lockfile 进版本库，CI 只从 lockfile 装npm ci   # 而不是 npm install# Docker 镜像：digest 固定（镜像供应链篇讲过的七板斧之一）FROM nginx@sha256:xxxx...

lockfile 一旦确定就别让 AI 再"顺手升级依赖"——很多幻觉包就是借着"帮你更新"混进来的。

为什么 Agent 让这一切更急迫

人写的代码 → 人复查 → 人安装，中间至少有一个人类看一眼包名。AI Agent 把这个检查点删了：生成 → 识别依赖 → 调包管理器 → 提交，全程无人工。一个幻觉包从产生到进主分支，可能只有一个任务周期的间隔。如果你在用 Agent 写代码，上面 6 道检查里有 4 道（1/3/4/6）应该做成 CI 强制门禁，而不是靠自觉。

本期清单

•  团队共识：AI 生成的 import/install 一律视为不可信输入
•  shellcheck + --check 干跑进提交前流程
•  危险命令五模式做成 code review 检查项
•  Agent 环境：CI 强制依赖白名单 + digest 固定
•  脱敏规范进团队 SOP（什么不能贴给 AI）
•  lockfile 入库，CI 用 npm ci / 锁定安装

下一篇预告：【漏洞雷达 #3】——周三 9/30，节前最后一期，当天核实最新情报再写。AI 系列下期预告：《LLM 应用安全自查 10 条：你的 AI 接口是不是别人的免费算力》。

这是 AI 安全系列第 1 期。不会劝你别用 AI——85% 的人在用，问题是 9% 的管控覆盖率。工具越快，检查越不能省。