关于本文
本文使用利用生成式 AI 的自动化流程创建。本文旨在作为一项实际检查，供人类在前提是确认 Linux 最小权限及各命令官方手册的基础上，对 AI 生成的命令进行验证。
验证状态：已设计安全确认流程・未进行危险命令的执行验证
AI 生成的命令即使看起来很自然，也可能会弄错目标路径、权限或 shell 展开。sudo 在附加之前，分 5 个阶段进行阅读。
1. 是读取还是更改
ls 或 cat 这样的确认操作，还是删除、覆盖、权限更改，首先要对其进行分类。如果是更改类操作，请在进入下一步之前缩小目标范围。
2. 考虑展开后的目标路径
*、变量、相对路径、~ 指代的是什么。在传递给 AI 的示例中，不要使用实际存在的内部路径或机密信息，而是替换为 /tmp/papanda-demo 这样的测试区域。
3. 是否真的需要 sudo
如果使用普通权限可以确认，就去掉 sudo。不要因为出现“Permission denied”就直接用 sudo，而是要确认该操作需要管理员权限的原因。
4. 查看破坏性选项
--force、recursive、overwrite 等包含在内时，请在官方手册中确认该选项会扩大什么范围。不要在生产路径中尝试危险的示例。
5. 决定 dry-run、backup、rollback
如果对应命令有 dry-run，请先使用；如果没有，则将其分解为测试目录或只读确认。如果是无法还原的操作，请先决定备份方法。
同时修改一处提示词
不仅要求 AI“给出命令”，还要加上以下内容。
実行コマンドの前に、変更対象、必要権限、破壊的オプション、dry-runまたは安全な確認方法、元に戻す方法を分けて示してください。不明な点は推測せず不明と書いてください。
在相同的请求中对比是否存在该条件，观察验证材料是否会增加。
如果在工作中应用
在服务器维护、AI 生成的 PowerShell、SQL、云 CLI 中，“首先阅读更改范围和权限”这一思路是相通的。
总结
AI 的输出并非执行许可。应由人类按照读取/更改（read/change）→ 范围（scope）→ 权限（privilege）→ 破坏性选项（destructive option）→ 回滚（rollback）的顺序进行确认。
