一、引言：当 AI 自信地写下 rm -rf
用一个真实场景开场：让 Claude Code 帮忙写一个日志清理脚本，结果它给出的版本差点把整个目录清空。引出本文的核心观点——AI 写 Shell 脚本效率极高，但 Shell 的破坏力同样极高，必须带着怀疑去用。
- 为什么选择用 Claude Code 写 Shell 脚本
- Shell 脚本的特殊风险：一行命令就能造成不可逆后果
- 本文要回答的问题：AI 到底会在哪些地方翻车，我们该怎么防
二、翻车现场一：路径与通配符的灾难
聚焦最典型的一类事故：变量未加引号、通配符展开失控、相对路径与绝对路径混用。
- 案例：
rm -rf $LOG_DIR/在变量为空时的后果 - 案例：文件名带空格导致
for f in $files直接崩坏 - AI 常见错误：默认路径一定存在、默认文件名不含特殊字符
- 正确写法对比：引号、
${VAR:?}、find -print0与xargs -0
三、翻车现场二：错误处理形同虚设
AI 生成的脚本往往“一路向前”，不检查返回值，也不设置严格模式，导致失败被静默吞掉。
- 案例：
cd失败后继续执行删除操作 - 案例：管道中前一个命令失败，脚本仍然报告成功
- 缺失的
set -euo pipefail与IFS设置 - 如何让 AI 补上
trap清理逻辑与退出码检查
四、翻车现场三：环境假设与可移植性幻觉
AI 常常混用 bash 特性与 POSIX sh 语法，或假设某些命令一定存在。
- 案例：shebang 写
#!/bin/sh却用了[[ ]]和数组 - 案例：依赖 GNU 版
sed -i，在 macOS 上直接报错 - 案例：假设
jq、curl、python3已安装 - 应对策略：明确目标平台、显式检查依赖、提供降级方案
五、翻车现场四：看似正确实则危险的“优化”
AI 有时会主动“优化”脚本，把可读性换成了隐蔽的坑。
- 案例：把多步操作合并成一行管道，出错后无法定位
- 案例：用
eval拼接命令，引入注入风险 - 案例：为“简洁”省略引号与变量校验
- 原则：Shell 脚本优先可读、可审计、可回滚
六、翻车现场五：权限、并发与幂等性
脚本在单机单次运行时没问题，一旦放到生产或定时任务里就暴露问题。
- 案例：未加锁导致 cron 任务重叠执行
- 案例：脚本重复运行造成数据重复写入
- 案例：以 root 身份运行却未做权限收敛
- 改进方向：
flock、幂等设计、最小权限原则
七、复盘：AI 写 Shell 的典型失效模式
把前面的案例归纳成一张表，便于读者快速对照自查。
| 失效模式 | 典型表现 | 风险等级 | 检查手段 |
|---|---|---|---|
| 变量未加引号 | 路径含空格或为空时行为异常 | 高 | shellcheck SC2086 |
| 缺少严格模式 | 错误被静默忽略 | 高 | 检查set -euo pipefail |
| 环境假设 | 换平台即失败 | 中 | 明确 shebang 与依赖检查 |
| 破坏性操作无确认 | 误删、误覆盖 | 极高 | dry-run 与二次确认 |
| 并发不安全 | 定时任务重叠 | 中 | 加锁与幂等校验 |
八、避坑指南：让 Claude Code 写出可用的 Shell 脚本
给出可落地的工作流，把 AI 的产出纳入工程化约束。
- 先约束再生成：在提示词中明确目标平台、shell 类型、是否允许破坏性操作。
- 强制静态检查：把
shellcheck作为验收标准，要求 AI 自行修复告警。 - 先 dry-run 再执行：所有删除、覆盖类操作先输出将要影响的文件列表。
- 小步验证：在临时目录或容器中跑通，再上真实环境。
- 人工复核关键行：重点看
rm、mv、>、eval、sudo出现的位置。 - 版本管理：脚本纳入 Git，改动可追溯、可回滚。
九、总结
Claude Code 在 Shell 脚本上的价值是真实的：它能快速产出结构完整、注释清晰的脚本骨架。但 Shell 的容错空间极小，AI 的“合理推测”恰恰是最危险的部分。把 AI 当作高效的初稿作者，把静态检查、dry-run 和人工复核当作必经关卡，才能真正把效率转化为生产力。
- 核心结论：AI 负责写，人负责守边界
- 下一步建议：建立团队内的 Shell 脚本检查清单
