给 AI 生成的命令加护栏：Android 与 Linux 工程中的安全执行法

让 AI 写一条命令很容易：清理构建缓存、批量替换配置、抓取 Android 日志，或者找出占用磁盘最多的目录。真正危险的部分，是我们常常把“看起来合理”误当成“可以直接执行”。

命令行会放大效率，也会放大错误。一个路径变量为空、一个通配符范围过宽，或者一段只适用于另一种 Shell 的语法，都可能让几秒钟的操作变成半天的恢复工作。

因此，我更愿意把 AI 当成命令的起草者，而不是终端的驾驶员。它负责压缩探索时间，人负责建立执行护栏。

一、先让命令回答三个问题

拿到一段命令后，不要先问“能不能跑”，而要先确认三件事：

1. 它会读取什么？
2. 它会修改什么？
3. 失败后留下什么？

例如，下面这条命令看起来只是在删除旧文件：

find "$CACHE_DIR" -type f -mtime +7 -delete

但在执行前，至少需要确认 CACHE_DIR 是否存在、是否为空，以及它最终指向哪里。更稳妥的写法是先验证边界，再输出候选项：

: "${CACHE_DIR:?CACHE_DIR is required}"
test -d "$CACHE_DIR"
find "$CACHE_DIR" -type f -mtime +7 -print

只有候选列表符合预期，才把最后的 -print 换成 -delete。这不是拖慢效率，而是把检查成本放在损失发生之前。

二、把“预览模式”当成默认模式

批量操作最值得建立的习惯，是先生成计划，再执行计划。很多命令原生支持这种方式：rsync 有 --dry-run，包管理器通常能显示待处理项，Git 也可以先查看 diff。

没有预览参数时，可以自己拆成两步。比如批量修改 Android 工程中的文件名，不要让查找、判断和改名挤在一条难以检查的管道里：

find app/src -type f -name '*OldName*' -print0 |
    while IFS= read -r -d '' file; do
        target=${file//OldName/NewName}
        printf '%q -> %q\n' "$file" "$target"
    done

第一轮只打印映射。确认目录范围、转义和目标名称都正确后，再加入真正的 mv -- "$file" "$target"。

让 AI 生成脚本时，也可以明确要求它同时提供：

预览命令：只输出影响范围
执行命令：实施修改
验证命令：证明结果符合预期
回退方法：说明如何恢复

这样得到的就不再是一条孤立命令，而是一个小型执行方案。

三、Android 调试命令也要限制范围

Android 调试经常依赖 adb。当设备、应用和日志混在一起时，一条宽泛命令很容易抓到错误对象。

先显式选择设备：

adb devices
adb -s "$ANDROID_SERIAL" get-state

再确认应用包名和进程：

adb -s "$ANDROID_SERIAL" shell pm path "$PACKAGE_NAME"
pid=$(adb -s "$ANDROID_SERIAL" shell pidof "$PACKAGE_NAME" | tr -d '\r')
test -n "$pid"

最后才进入日志或诊断步骤：

adb -s "$ANDROID_SERIAL" logcat --pid="$pid"

这几个变量看似增加了输入，其实消除了“默认设备”和“猜测包名”带来的歧义。尤其在同时连接真机、模拟器和远程设备时，显式范围比命令长度更重要。

四、给长任务准备停止条件

AI 很擅长给出循环、监控和重试脚本，但它未必知道你的终端要运行多久。没有停止条件的自动化，常常只是把手工等待变成后台失控。

Linux 下可以用 timeout 给诊断命令设定上限：

timeout 60s adb -s "$ANDROID_SERIAL" logcat --pid="$pid" > app.log

脚本中的重试也应有明确次数：

for attempt in 1 2 3; do
    ./gradlew assembleDebug && break
    printf 'attempt %s failed\n' "$attempt" >&2
done

停止条件不只包括时间和次数，还可以是文件大小、磁盘余量、返回码或某个可观察状态。关键是不要让“继续试试”成为默认行为。

五、保存证据，而不是只保存成功截图

一次命令执行是否可信，取决于之后能否回答：当时在哪个目录、用了哪些参数、返回码是什么、修改了哪些文件。

对于重要操作，我会保留一个很小的证据链：

pwd
git status --short
command_to_run 2>&1 | tee command.log
status=${PIPESTATUS[0]}
printf 'exit=%s\n' "$status"
exit "$status"

在 Git 仓库中，执行前后的 git diff --stat 和 git diff --check 也很有价值。前者告诉你影响范围，后者能发现部分格式问题。对于构建任务，则应保留实际构建命令及其退出状态，而不是用“终端最后几行看起来正常”代替验证。

六、把高风险操作拆出人工确认点

并不是所有命令都值得自动化到底。涉及删除、覆盖、权限、分区、密钥、生产设备和远程主机时，人工确认点本身就是设计的一部分。

可以把任务按风险分成三层：

• 只读：搜索、统计、查看日志，可以快速执行；
• 可回退写入：修改受版本控制的文件，先预览并验证 diff；
• 难回退写入：删除数据、改权限、操作设备，必须单独确认目标和恢复方案。

AI 可以帮助识别命令中的危险参数，也可以解释每个阶段，但最终的确认应该发生在信息最完整的时刻，而不是任务刚开始时笼统地说一句“都同意”。

七、形成自己的命令请求模板

当这套方法稳定后，可以把需求固定成一段简短模板：

环境：Linux Bash / Android 工程
目标：说明期望结果
范围：允许读取和修改的目录
限制：不能联网、不能删除、最长运行时间
输出：预览、执行、验证、回退四组命令
要求：变量为空时退出，路径全部加引号，保留退出码

模板的价值不在于让提示词显得专业，而在于把容易遗忘的工程约束变成默认输入。使用次数越多，它越像一份轻量的操作规范。

结语

AI 让生成命令的成本接近于零，但执行命令的风险并没有一起归零。真正可靠的效率提升，来自预览、边界、停止条件、证据和回退路径。

当每条命令都能说清楚“作用在哪里、什么时候停止、如何证明成功、出错怎么恢复”，AI 才真正进入了工程工作流，而不是成为一个速度更快的复制粘贴来源。