在很多企业里，写脚本常常是一件“看似简单，却容易踩坑”的事。比如：

• 运维同事写了个定时清理日志的 Shell，结果少写了参数检查，一次误删把当天的业务日志也清掉了。
• 数据团队写了个 Python 脚本，每天从 API 拉取数据，没考虑网络波动，某天卡住了 3 个小时，导致整个数据链路延迟。
• 开发测试用 AI 生成了一个批量导入工具，但没有 dry-run 功能，结果一次导入错误直接覆盖了生产数据。

这些问题其实不是 AI 的错，而是我们没有给 AI 明确的“生成规范”。要想真正用好 AI，得掌握一套可落地的方法。

明确边界：先写好脚本契约
脚本能不能用，取决于一开始有没有说清楚边界。比如“每天凌晨 3 点，把 7 天前的日志压缩后上传 OSS，本地只保留 7 天”。这样写，AI 才知道目标是什么、时间限制是什么、风险在哪里。

反过来，如果只说“帮我写个日志清理脚本”，AI 大概率会给你一个“能跑”的版本，但可能没日志、没回滚、没错误处理，结果放到生产里就是隐患。

输入输出必须结构化
举个例子：

• 如果你让脚本“自己去找路径”，员工 A 配的路径和员工 B 配的路径可能完全不同，结果同一个脚本在不同机器上表现不一样。
• 但如果所有输入都显式写成参数，比如 --src /var/log/app --days 7 --bucket oss://archive，那就没有歧义了。

同样，输出也不能随便乱放。比如把归档文件固定写到 /data/archive/，并生成一份 JSON 摘要，既方便人查，也方便后续自动化接管。

给 AI 明确提示，不要“随便写个脚本”
比如，你可以这样要求：

• 必须有 --dry-run 参数，先演示要干什么，再执行。
• 出错要有日志，不能静默失败。
• 外部命令缺失时要给出清晰报错，而不是直接退出。

如果你不写清楚，AI 往往会默认生成最“省事”的代码，这就是为什么很多人觉得“AI 写的脚本不稳”。

硬规则要落实
经验告诉我们，一些规则必须在每个脚本里强制落地：

• 参数检查：比如清理日志前，必须确认目录存在且不为空。
• dry-run 模式：比如批量删除文件时，先打印“将删除哪些文件”，确认无误后再执行。
• 超时与重试：比如调用外部 API 时，必须考虑网络抖动，自动重试而不是无限挂起。
• 幂等性：比如压缩归档，第二次执行时不能重复打包同一份文件。

这些看似繁琐，但一旦做成规范，AI 每次都能照着补齐，成本反而更低。

验证和迭代
举个实际例子：某团队让 AI 写了个“批量导入用户数据”的脚本。第一版能跑，但有两个问题：

1. 导入失败时没报错，后台悄悄丢掉了几百条记录。
2. 再次执行时重复导入，导致用户数据重复。

后来他们加了验证清单：必须有错误日志、必须支持幂等执行、必须能 dry-run。每次发现缺陷，就反馈给 AI。经过三轮迭代，脚本终于从“能跑”变成“敢用”。

结语
AI 辅助写脚本，不是让你少考虑，而是让你把规范和边界前置，把“经验”固化成规则交给 AI。只要学会写契约、定输入输出、明确提示、落实硬规则，再加上小步迭代，AI 写的 Shell/Python 脚本不仅能跑，还能跑得稳。