AI 生成的 Bash 脚本如何避免静默失败

AI 写的部署脚本，最危险的结果未必是报错，而是在错误目录里继续执行，最后还返回成功。作者演示了一个四行脚本：BUILD_DIR 没有设置，cd 失败后，脚本照样打印当前目录、执行模拟部署，并以退出码 0 结束。

加上 set -euo pipefail 后，这次演示在变量展开时就停止了。但这行配置也有边界：条件判断、部分逻辑链中的失败，仍然不会触发退出。读懂这些例外，比记住一行「严格模式」更有用。

为什么目录切换失败，脚本还能返回成功

作者的演示暴露了两个问题：前面的命令失败，脚本未必停止；脚本最后返回成功，也不能证明前面的步骤全部成功。

如果部署依赖先进入构建目录，cd 失败后继续执行，后续命令就会在原来的工作目录运行。作者展示的是模拟部署，没有提供真实部署事故或文件损失的证据，但错误传播的路径已经很清楚：一个没有拦住的目录错误，会改变后续命令操作的位置。

作者给出的修正片段如下，它会在使用未设置的 BUILD_DIR 时停止：

#!/usr/bin/env bash
set -euo pipefail
cd "$BUILD_DIR/out"

关键是第二行。此次演示触发的是 -u：Bash 在展开变量时报告 BUILD_DIR: unbound variable，退出码变为 1，还没执行到 cd。

第三行的双引号也要保留。它让展开后的路径作为一个参数传给 cd，避免路径里的空格等字符造成意外拆分。不过，引号不会验证目录是否存在，也不会判断它是不是正确的部署目录。

三个选项各管一层，-e 还有例外

set -euo pipefail 常被称为 Bash 的严格模式，但它实际组合了三项设置：

• -e 让脚本在命令返回非零状态时退出，但存在语法上下文方面的例外。
• -u 把变量展开时使用未设置变量的行为视为错误。
• -o pipefail 改变管道的返回状态：有命令失败时，取最右侧失败命令的状态；全部成功才返回 0。

管道尤其容易制造「假成功」。原文用 false | true 举例：没有启用 pipefail 时，最后的 true 成功，整条管道就算成功，前面的失败被盖住了。

严格模式能拦住一批错误，但不能替你确认关键步骤成功。

作者援引 GNU Bash 手册指出，以下位置的失败不会直接触发 -e 退出：if 的测试部分、while 或 until 的条件部分、&& 或 || 列表中除最后一个命令之外的位置，以及被 ! 反转状态的命令。

原文演示了 if false; then …; fi 在启用 set -e 后仍然继续执行。这里的失败用于决定走哪个分支，Bash 不把它直接当成终止脚本的信号。

因此，检查 AI 生成脚本时，不能只看开头有没有这一行，还得看关键命令放在哪里。

我的判断

作者的建议适合作为 AI 辅助编写 Bash 脚本的默认要求：启用严格模式、给变量加引号，再人工检查 cd、rm 和部署命令。它成本低，也能提前暴露一部分原本被忽略的错误。

但原文只有一个小型演示，没有团队级对照数据，不能据此推导出它能减少多少部署事故。完整的四行问题脚本也没有贴出，读者无法逐行核对模拟部署的具体行为。

还有一个容易混淆的地方：这次修复实际验证了 -u 对未设置变量的拦截，并没有验证「变量已设置，但指向错误目录」的情况。严格模式也不会理解业务意图，一个命令即使返回 0，仍可能操作了不该操作的对象。

相比只加一行配置，对关键命令显式检查结果，能让失败后的处理更清楚。两者可以配合使用。把严格模式补进旧脚本后也必须测试，因为原先被忽略的非零状态，现在可能让脚本提前结束。

能拿来做什么

• 让 AI 生成 Bash 构建或部署脚本时，明确要求使用 set -euo pipefail，并给变量展开加双引号。
• 用 head -3 检查仓库里的 .sh 文件，找出缺少严格模式的脚本；补上后逐个测试，确认正常流程仍能完成。
• 运行脚本前，人工阅读每一处 cd、rm 和部署命令，核对路径来源，并检查失败后是否仍可能继续执行。
• 对包含管道、if、&& 或 || 的关键步骤，单独检查失败路径，避免把退出码 0 当成整段流程正确的证明。