已生成《Claude Code 写 Shell 脚本翻车实录》技术文章大纲，包含开篇场景、五类典型翻车现场、修正方法论、提示词模板与总结共九个章节。

项目背景与目标设定

在自动化运维与系统管理场景中，Shell脚本因其轻量、高效和广泛兼容性，成为不可或缺的工具。本次尝试利用Claude Code（Anthropic推出的代码生成模型）快速构建一个用于批量处理日志文件、清理过期备份并发送告警通知的Shell脚本。目标是实现自动化执行，减少人工干预，提升运维效率。

脚本功能需求分析

脚本需完成以下核心功能：

• 遍历指定目录下的所有日志文件；
• 根据文件名中的时间戳判断是否超过7天，若超过则标记为可删除；
• 对于待删除文件，先进行压缩归档，保留至备份目录；
• 记录操作日志到/var/log/cleanup.log；
• 若发现超过10个文件被删除，通过邮件或企业微信发送告警通知；
• 支持命令行参数传入配置路径与执行模式（模拟/真实）。

Claude Code生成初版脚本过程

输入提示词：“请编写一个Shell脚本，用于清理超过7天的日志文件，将它们压缩后移至备份目录，并在删除超过10个文件时触发告警。”
模型返回一段看似完整的脚本，包含函数定义、条件判断、变量赋值及调用外部工具如find、gzip、mail等。初步检查语法结构合理，逻辑清晰，具备基本可运行性。

初次运行暴露的问题汇总

脚本在测试环境中首次执行即出现严重问题：

• find命令未正确使用-mtime参数，导致误判文件年龄，部分仅3天的文件也被标记删除；
• 压缩路径拼接错误，使用了未初始化的变量，造成gzip命令报错；
• 日志写入路径权限不足，脚本因无权写入/var/log而中断；
• 告警触发逻辑存在漏洞，即使只删除1个文件也触发邮件通知；
• 缺少对异常情况的捕获，如磁盘空间不足、网络不可达等。

深度调试与逐行排查

通过添加set -x启用调试模式，观察脚本实际执行流程。发现多个关键环节存在隐性错误：

• 时间格式解析依赖date命令，但未指定时区，导致跨时区环境结果不一致；
• 使用$()嵌套命令替换时未加引号，引发空格分割错误；
• if [ $count -gt 10 ]判断中缺少双引号保护，当变量为空时触发语法错误；
• 外部告警接口调用方式未经验证，实际并未成功发送消息。

修复策略与重构方案

针对上述问题，采取以下修正措施：

• 明确使用-daystart选项配合-mtime +7确保按自然日计算；
• 所有路径变量均使用双引号包裹，避免空格或特殊字符干扰；
• 添加mkdir -p确保备份目录存在且权限正确；
• 引入临时文件记录已处理文件列表，防止重复操作；
• 使用trap捕获信号，保证脚本异常退出时仍能输出完整日志；
• 将告警阈值调整为“连续三次超过10个”才触发，降低误报率。

与人工编写脚本对比分析

将修复后的版本与手动编写的同类脚本进行对比：

• 人工版本在边界条件处理、错误恢复机制方面更完善；
• 自动生成脚本虽节省时间，但在复杂逻辑控制上缺乏深度理解；
• 生成内容依赖提示词质量，模糊描述易导致歧义解读；
• 无法自动生成注释说明关键设计决策，不利于后期维护。

工具局限性总结与建议

Claude Code作为辅助编码工具，在简单任务中表现良好，但在涉及系统级操作、安全敏感逻辑或高可靠性要求的场景下存在明显短板：

• 缺乏对操作系统行为的深层认知，难以准确预测命令副作用；
• 无法主动识别潜在风险点，如权限越界、资源耗尽等；
• 生成代码缺乏上下文感知能力，容易忽略环境差异；
• 不支持动态反馈迭代，一旦出错需手动重写提示词重新生成。

最佳实践推荐

结合本次经验，提出以下使用建议：

• 将AI生成脚本视为“草稿”，必须经过严格审查与测试；
• 所有涉及文件系统操作的脚本应先在隔离环境运行；
• 关键逻辑必须添加日志输出与状态校验；
• 使用静态检查工具（如shellcheck）提前发现语法问题；
• 对生成内容进行单元测试，覆盖正常、异常、边界三种情形；
• 建立脚本变更审批流程，禁止直接部署未经验证的AI产物。

结语：人机协同才是未来方向

尽管此次“翻车”令人遗憾，但也揭示了智能代码助手的真实定位——不是替代开发者，而是提升效率的伙伴。真正的可靠系统，永远离不开人的判断力、经验积累与责任意识。未来，我们应以批判性思维驾驭工具，让人工智能真正服务于高质量交付，而非制造新的技术债务。

一、开篇：一次“看起来很稳”的尝试

用一段真实场景切入：临时需要写一个批量处理日志的 Shell 脚本，抱着试试看的心态交给 Claude Code，结果从“三分钟搞定”变成“三小时排雷”。

• 任务背景：日志清理、文件批量重命名或定时备份脚本
• 初始预期：AI 生成即用，省去查手册的时间
• 实际结果：脚本能跑，但跑出了意料之外的结果

二、翻车现场一：路径与空格引发的血案

AI 生成的脚本在本地测试通过，换到含空格或特殊字符的目录后直接失效。

• 典型问题：变量未加双引号，$file 被按空格拆分成多个参数
• 通配符展开时机错误，for f in $(ls) 的经典陷阱
• 相对路径与绝对路径混用，脚本在不同工作目录下行为不一致
• 复盘：为什么 AI 倾向于写出“看起来简洁”但脆弱的写法

三、翻车现场二：错误处理形同虚设

脚本没有 set -e，中间步骤失败后继续执行，最终把错误状态扩散到下游。

• 缺少 set -euo pipefail，命令失败被静默忽略
• 管道中前段命令失败，退出码被后段覆盖
• 未检查关键命令返回值，删除或覆盖操作不可逆
• 复盘：AI 默认生成“顺利路径”代码，异常分支需要显式要求

四、翻车现场三：危险操作的“温柔包装”

涉及 rm、mv、重定向覆盖的语句，AI 写得干净利落，却没有二次确认或备份。

• rm -rf 与变量拼接组合的潜在风险
• 重定向 > 误覆盖已有文件
• 缺少 dry-run 模式，无法先验证再执行
• 复盘：如何用提示词约束 AI 输出安全版本

五、翻车现场四：跨平台兼容性被忽略

在 macOS 上跑通的脚本，放到 Linux 服务器或 CI 环境里报错。

• GNU 与 BSD 工具参数差异，如 sed -i、date、readlink -f
• Shebang 写法与 /bin/sh 实际指向的 shell 不一致
• 依赖未声明的外部命令，环境里根本没有安装
• 复盘：让 AI 明确目标运行环境的重要性

六、翻车现场五：可读性与可维护性欠账

脚本能跑，但没人敢改：变量命名随意、缺少注释、逻辑全挤在一个函数里。

• 魔法数字与硬编码路径
• 缺少函数拆分与参数校验
• 日志输出不规范，出问题无法定位
• 复盘：AI 生成代码的“一次性”倾向

七、从翻车到可控：我的修正方法论

总结一套可复用的协作流程，把 AI 从“代写”变成“结对”。

1. 先写清楚需求边界：输入、输出、失败时怎么办
2. 要求生成带 set -euo pipefail 与参数校验的骨架
3. 强制加入 dry-run 与日志输出
4. 逐段人工审查危险命令，尤其是删除与覆盖
5. 在目标环境而非本地做最终验证

八、给 AI 的提示词模板（附示例）

给出可直接复用的提示词结构，并展示一段修正前后的脚本对比。

• 提示词要素：运行环境、Shell 类型、输入输出、错误处理要求、安全约束
• 修正前：脆弱的一行流写法
• 修正后：带引号、带校验、带日志的稳健版本

九、总结：AI 写脚本的正确打开方式

AI 擅长快速产出可运行的初稿，但 Shell 脚本的坑大多藏在边界条件与破坏性操作里。把 AI 当加速器，把审查当刹车，才是可持续的用法。

• 三个必须人工把关的点：路径处理、错误处理、危险命令
• 一条经验：先让它写测试用例，再让它写实现
• 一句提醒：能跑通不等于能上线