运行 AI 生成脚本前，先限定操作边界

AI 花十二秒写出的 Bash 脚本，可能注释齐全、带进度提示，最后还打印一句「Done!」。但看起来专业，不代表它只会改动你允许改动的东西。作者给出的核心建议是：执行前，先把任务范围、执行权限和预期影响讲清楚，再检查代码。

这篇文章值得程序员花几分钟读，因为它把「检查 AI 代码」落到了具体动作上：先生成只读版本，用测试文件核对结果，再单独设计修改步骤。语法检查有用，但它回答不了「这是不是你原本想操作的环境」。

先看它能改什么，再看语法对不对

「清理一下服务器」不是可以直接执行的需求。作者把它收窄为：在指定实验目录中，列出超过 14 天的普通 .log 文件，不删除、不上传、不改所有者，也不进入符号链接目录，候选结果交给人检查。

这里明确了目录、时间、文件类型和允许的动作。审查时才有依据判断脚本有没有越界。

作者建议先检查四件事：

• 目标是否正确，包括路径最终指向哪里、远程主机和账号是否匹配。
• 权限有多大，包括执行用户能否写入其他目录、读取密钥或调用特权命令。
• 输入是否可控，包括文件名、环境变量和外部文本会不会改变命令含义。
• 影响有哪些，包括删除、安装、改权限、发数据、停服务和修改数据库。

语法正确，只能说明命令符合语法，不能说明它符合你的意图。

命令执行失败后顺手加上 sudo，也不只是排障。它扩大了脚本能够造成的影响。

先列候选文件，把删除留到下一步

作者给出的脚本只负责检查，假设运行环境是使用 GNU find 的 Linux 实验机器。它把目标路径和候选文件打印出来，便于人工核对：

#!/usr/bin/env bash
set -euo pipefail

TARGET=${1:?Usage: inspect-logs.sh /path/to/lab-logs}

if [[ ! -d "$TARGET" || -L "$TARGET" ]]; then
  printf '%s\n' 'Choose an existing, non-symlink lab directory.' >&2
  exit 1
fi

TARGET=$(realpath -- "$TARGET")

if [[ "$TARGET" == / ]]; then
  printf '%s\n' 'The filesystem root is not an acceptable target.' >&2
  exit 1
fi

printf 'Inspection only. Target: %q\n' "$TARGET"
find -P "$TARGET" -xdev -type f -name '*.log' -mtime +14 -print0 |
  while IFS= read -r -d '' candidate; do
    printf 'Candidate: %q\n' "$candidate"
  done

重点看 find 那一行：-P 不跟随符号链接，-xdev 避免进入其他挂载的文件系统，-type f 和 -name '*.log' 限定文件类型与名称；-print0 配合 read -r -d ''，避免按空格或换行错误拆分文件名。

但这些检查有边界。作者明确说，这只是审查练习，不是隔离机制。检查期间文件系统仍可能变化，路径验证无法单独防住竞态，也就是「检查时成立，实际操作时已经变了」。

-mtime +14 也不能草率理解为业务上的「超过 14 天」。GNU find 的时间判断存在取整规则，保留策略若依赖精确时间，就要先定义清楚口径。脚本结尾没有删除操作，后续若确实需要删除，应另行设计。

检查工具和提示词，各自只能管一部分

接下来才是语法检查和常见错误扫描：

bash -n inspect-logs.sh
shellcheck inspect-logs.sh

注意第一行的 -n：它检查 Bash 语法，但不执行脚本。ShellCheck 则能发现许多常见 Shell 问题。两者都无法证明目标目录正确、权限合适，或者操作符合业务需求。

作者还建议准备一个可丢弃的测试目录，放入普通文件、带空格的文件名、异常名称、符号链接，以及不该被匹配的文件。运行前先写出预期候选列表，再比较实际输出，测试才有判定标准。

执行环境同样要设限。AI 读取的日志、网页和文档，可能夹带并非用户发出的指令，也就是提示词注入。仅在提示词中要求「不要越权」不够，限制应落实到受限凭证、工具范围，以及重要操作的明确审批上。

模型提出操作，外围系统决定它能不能执行。

我的判断

我认同这套顺序：先限定任务，再检查权限与影响，最后使用检查工具。它适合日常 AI 编程中那些「看着不长，顺手就运行了」的脚本。

不过，原文提供的是流程建议和示例，没有给出事故减少比例，也没有与其他审查方式做对照。其效果属于经验判断，不能当作经过量化验证的结论。

验证状态也要讲完整：作者称示例在草稿准备阶段通过了 Bash 语法检查和一次可丢弃文件测试；ShellCheck 与作者环境相关的审查仍未完成。不能把文章中的建议误读成全部已经验证。

与直接让 AI 生成「完整清理脚本」相比，先检查、后修改更容易审查，但也多了一步。对于会删除文件、改权限或操作服务的脚本，这一步有明确价值。只读输出正确，仍不足以证明未来加入的删除步骤安全。

能拿来做什么

• 让 AI 编写日志清理脚本时，把目录、文件类型、时间口径和允许动作写进需求，第一版只列出候选文件。
• 执行陌生 Bash 脚本前，用自己的话解释它做什么，并逐项找出写入和网络操作；解释不清，就要求拆成更小的脚本。
• 用可丢弃目录验证匹配结果，提前列出哪些文件应该出现、哪些不该出现，再运行 bash -n 和 ShellCheck。
• 给能够执行命令的 AI 工具配置受限凭证和明确的工具范围，遇到权限错误先查原因，不直接追加 sudo。