
一、引言当 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 脚本检查清单