AI 写的小脚本，运行前应该检查什么？

人工智能生成的小脚本，应先检查它会读取、修改和发送哪些内容，再用独立样本验证。代码看起来短、解释写得完整，都不能证明运行结果符合预期。对于整理博客图片、修改配置或批量更新文章的任务，最重要的是控制范围和保留恢复办法。

先写清输入与预期结果

把任务说成可以观察的变化，例如“列出文章中不存在的本地图片”，而不是笼统要求“修好图片”。前者只需要检查，后者可能让工具猜测替换方式。说明允许读取哪个目录、是否可以写入，以及什么情况应停止并报告。

给出少量具有代表性的样本：正常文件、不存在的文件、带中文或空格的名称。要求说明每种输入应该产生什么结果。这样在阅读代码时，可以将每段处理与实际需求对应，而不是只判断语法像不像正确。

重点看副作用

检查有没有删除、覆盖、移动、批量替换、安装依赖或发送网络请求。特别留意路径如何组成，是否可能越过指定目录；输出文件与输入文件是否同名；遇到错误后是否继续修改其他文件。不要只看最后一行打印的“成功”。

若代码读取环境变量、配置或日志，确认是否包含密钥、订阅地址或账户信息。排查连接问题的小脚本通常不需要把整份配置上传到陌生地址。工具建议的下载来源和依赖名称，也应回到正式项目资料核对。

先在副本里验证

建立独立测试目录，只放入必要的样本，保留原始文件。先运行只报告结果的检查方式；确实需要写入时，让输出进入另一目录，再比较前后差异。若脚本没有预览或报告能力，可以先要求补充这一步，再考虑批量执行。

例如，批量调整博客图片引用时，检查一篇文章的普通路径、中文名称和外部图片是否分别按预期处理。不能因为第一个简单样本成功，就直接应用到全部文章；也不要在没有备份的情况下用原文件验证删除逻辑。

把验证记录留在实际结果上

1. 确认使用的运行环境与脚本要求相符，不忽略版本和权限错误。
2. 运行样本，保存退出状态与必要输出，但去除敏感信息。
3. 查看真实文件差异，确认只改变了允许的内容。
4. 对原本的问题再次检查，并观察是否引入了新的缺失或重复。

工具回复“测试通过”，应能对应一条确实执行的命令和结果。如果没有运行环境，就只能说代码经过阅读或解释，不能将推测描述成实测。自动检查通过后，也要人工查看一两个典型输出，确认内容仍然有意义。

看不懂的修改先缩小

要求工具按文件说明改动目的，并解释路径、匹配条件和错误处理。一次解决一个明确问题，比把格式重写、依赖升级和逻辑调整混成一批更容易核对。如果仍无法理解影响范围，先保留原版本，不急着用于真实资料。

正式使用前，确认备份能够恢复，并记录使用了哪一版脚本。执行后检查结果，保留必要的修改摘要。人工智能可以帮助写出初稿和解释思路，但是否运行、是否发布，以及结果是否满足任务，仍需要由实际使用者根据证据决定。

继续阅读：怎样把任务和材料写成清楚的 AI 提示词？；AI 工具怎么选：写作、检索与编程场景