Claude Code 写 Shell 脚本翻车实录:一份避坑指南

文章目录

[一、引言:当 AI 自信地写下 rm -rf](#一、引言:当 AI 自信地写下 rm -rf)

[二、背景:为什么 Shell 脚本特别容易翻车](#二、背景:为什么 Shell 脚本特别容易翻车)

三、翻车实录一:变量未加引号导致路径被拆散

[四、翻车实录二:set -e 与管道组合的静默失败](#四、翻车实录二:set -e 与管道组合的静默失败)

[五、翻车实录三:通配符与 rm 的危险组合](#五、翻车实录三:通配符与 rm 的危险组合)

六、翻车实录四:跨平台命令不兼容

七、翻车实录五:看似合理的逻辑漏洞

[八、复盘:AI 写 Shell 脚本的常见失效模式](#八、复盘:AI 写 Shell 脚本的常见失效模式)

[九、实践:让 Claude Code 写出更安全脚本的提示词技巧](#九、实践:让 Claude Code 写出更安全脚本的提示词技巧)

十、上线前的检查清单

十一、总结


一、引言:当 AI 自信地写下 rm -rf

用一个真实场景开场:让 Claude Code 帮忙写一个日志清理脚本,结果它给出的命令差点把生产目录清空。点明本文不是否定 AI 编程,而是记录翻车现场并总结可复用的避坑方法。

  • 为什么选择用 Claude Code 写 Shell 脚本
  • 本文的读者对象与阅读收益
  • 全文结构速览

二、背景:为什么 Shell 脚本特别容易翻车

说明 Shell 脚本本身的特性决定了它对 AI 生成内容格外敏感。

  • 命令破坏力强,一条 rm 或 mv 就可能不可逆
  • 缺少类型系统和编译期检查,错误只在运行时暴露
  • 隐式行为多:通配符展开、变量未加引号、set -e 的边界情况
  • 环境差异大:不同发行版的命令参数、路径和权限各不相同

三、翻车实录一:变量未加引号导致路径被拆散

还原现场:脚本处理带空格的目录名时被拆成多个参数,导致误删或误移动。

  • 出问题的原始脚本片段
  • Claude Code 当时的解释与我的误判
  • 问题根因:$var 与 "$var" 的区别
  • 修复后的写法与验证方式

四、翻车实录二:set -e 与管道组合的静默失败

记录一次脚本看似成功、实际中途失败却继续执行的经历。

  • 现象:退出码为 0,但数据没有处理完
  • 根因分析:管道中只有最后一个命令的退出码被检查
  • 相关方案:set -euo pipefail 的作用与局限
  • 如何用日志和断言让失败显性化

五、翻车实录三:通配符与 rm 的危险组合

描述一次因变量为空导致通配符匹配到意外路径的事故。

  • 事故复现的最小示例
  • 为什么 AI 容易忽略空变量保护
  • 防护手段:参数校验、rm --、先 dry-run 再执行
  • 把危险操作改造成可预览的两阶段脚本

六、翻车实录四:跨平台命令不兼容

说明在 macOS 上跑通的脚本到 Linux 服务器上直接报错的过程。

  • 典型差异:sed -i、date、readlink -f
  • Claude Code 默认假设的环境与实际环境的偏差
  • 应对策略:显式声明目标环境、使用兼容写法或做环境探测

七、翻车实录五:看似合理的逻辑漏洞

记录一次业务逻辑层面的错误,命令本身没错,但判断条件写反了。

  • 需求描述模糊导致 AI 自行补全假设
  • 边界条件缺失:空目录、文件不存在、权限不足
  • 如何通过用例清单反向校验脚本逻辑

八、复盘:AI 写 Shell 脚本的常见失效模式

把前面几次翻车归纳成可复用的模式清单。

失效模式 典型表现 防护手段
缺少引号 路径被拆分 统一使用双引号包裹变量
错误处理缺失 失败后继续执行 启用严格模式并检查退出码
破坏性操作无保护 误删误改 dry-run、二次确认、备份
环境假设错误 跨平台报错 显式声明环境并做探测
需求理解偏差 逻辑写反 先对齐需求再生成代码

九、实践:让 Claude Code 写出更安全脚本的提示词技巧

给出可直接复用的提问方式,把安全约束前置到生成阶段。

  • 明确声明运行环境、Shell 版本和权限范围
  • 要求先输出执行计划,确认后再给完整脚本
  • 强制要求参数校验、错误处理和日志输出
  • 要求提供 dry-run 模式和回滚方案
  • 要求逐行解释危险命令的作用

十、上线前的检查清单

整理一份可打印的 Shell 脚本自检清单。

  1. 所有变量是否都加了引号
  2. 是否启用 set -euo pipefail
  3. 破坏性命令是否有前置校验和确认
  4. 是否在测试环境完整跑过一遍
  5. 是否有日志、退出码和失败告警
  6. 是否准备了回滚或备份方案

十一、总结

收束全文:AI 能显著提升写脚本的效率,但 Shell 的高破坏性决定了人必须承担最终审查责任。强调「先理解、再执行、可回滚」三条原则,并鼓励读者分享自己的翻车经历。


  • 📢博客主页:https://lansonli.blog.csdn.net
  • 📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正!
  • 📢本文由 Lansonli 原创,首发于 CSDN博客🙉
  • 📢停下休息的时候不要忘了别人还在奔跑,希望大家抓紧时间学习,全力奔赴更美好的生活✨
相关推荐
IT_陈寒29 分钟前
Vue的这个响应式陷阱,差点让我加班到天亮
前端·人工智能·后端
东离与糖宝1 小时前
Spring AI 大模型容易混淆概念一次性讲透
人工智能
复杂网络与机器学习2 小时前
全双工 160 毫秒一格:李沐让模型不再「一问一答」
人工智能
武子康2 小时前
Qwen-Drive 的 91.4 分,究竟选中了什么?
大数据·人工智能·agent
王中阳Go3 小时前
你把重试加到 2 次那天,200 条里成功还是 181 条,你回看过吗?
人工智能·后端·架构
北杨3 小时前
三键之内的意图:用 AIUI 在 Rokid 眼镜上做一个能玩的 21 点
人工智能
火山引擎开发者社区3 小时前
给企业配一双 AI 的手:火山引擎 OS Agent 替你操作手机和电脑
前端·人工智能
神鹰手哥_起飞版3 小时前
我是怎么管理 Coding Agent 的:把任务交出去,也把结果验回来
人工智能·架构·产品经理
泯泷3 小时前
你的 AI 知识库为什么答非所问?问题出在“切块”这一刀
人工智能