AI 都能写 Python 了，运维还需要学代码吗？

上周有人问我：

“现在 AI 写 Python 脚本这么快，还有必要从头学代码吗？”

这个问题放在运维场景里，确实容易让人犹豫。

以前写一个日志清理脚本，要查 os、pathlib、文件时间、异常处理。现在把需求丢给 AI，几十秒就能拿到一份完整代码，注释写得清楚，甚至还附带使用方法。

看起来，人只要负责复制和运行就行。

但如果这个脚本准备放到生产服务器上，我还是会先停一下。

它清理的是哪个目录？软链接会不会把它带到别的路径？文件正在被进程写入怎么办？权限不足时会怎样？删错以后能不能恢复？磁盘已经写满时，脚本还能不能正常记录日志？

AI 可以很快写出代码，却不知道你们公司的服务器是什么情况，也不会在凌晨两点替你解释为什么业务数据被删了。

所以我的答案是：有必要学。

只是学习代码的目的变了。我们不再需要和 AI 比拼谁能更快写出一百行代码，而要有能力看懂它写了什么，判断它能不能用，以及出问题时从哪里查起。

AI 已经把“写代码”变成了一件容易的事

这一点没有必要否认。

现在用 AI 写运维脚本，效率确实高。生成一个日志分析脚本、批量检查端口、调用云平台 API、处理监控告警，通常只需把需求描述清楚，再修改几轮。

以前半天才能拼出来的小工具，现在可能半小时就能跑起来。

AI 还很适合处理那些“知道怎么做，但记不清具体写法”的事情。比如正则表达式、时间格式转换、YAML 解析、HTTP 请求、并发执行。语法忘了没关系，问一下就有答案。

这对运维人员是好事。

很多人的工作重点本来就不是开发一个大型系统，而是快速处理现场问题。能少查一些文档，少写一些重复代码，当然值得欢迎。

麻烦出在另一件事上：代码生成得太容易，人会误以为运行它也同样容易。

“能运行”是最容易骗人的状态

一段脚本没有报错，只能说明它通过了当前这次执行。

它不代表处理逻辑正确，也不代表换一台服务器还能用，更不代表可以直接进入生产环境。

举个很常见的例子。

你让 AI 写一个磁盘空间清理脚本，要求删除 30 天以前的日志。AI 很快给出代码，在测试目录里运行也没问题。

但到了实际环境，至少还有这些问题：

• • 日志文件是否正在被服务占用；
• • 文件修改时间能不能代表日志的实际保留时间；
• • 目录中有没有软链接；
• • 是否要保留审计日志和故障现场；
• • 删除前要不要压缩、转存或生成清单；
• • 清理失败后如何告警；
• • 脚本被重复执行时会不会产生副作用。

这些并不是 Python 语法问题。AI 也能给出一套看似全面的回答，但它不知道哪条规则适用于你的环境。

生产系统最怕的不是代码写得慢，而是一个未经判断的脚本跑得太快。

懂代码的人看到 os.remove()，会本能地检查路径从哪里来；看到 except Exception: pass，会知道错误被悄悄吃掉了；看到把密码直接写进脚本，会立刻想到凭证泄露。

完全不懂的人看到的往往只有一句：“执行成功。”

运维为什么更不能把判断交给 AI

开发代码通常有相对明确的输入、输出和测试过程。运维面对的环境更杂。

同一个命令，在不同系统版本上可能表现不同；同一个脚本，换一个权限、目录或网络条件，就可能出现完全不同的结果。

更麻烦的是，运维操作经常直接触碰真实资源：

• • 删除文件；
• • 修改配置；
• • 重启服务；
• • 调整防火墙；
• • 创建和回收云资源；
• • 变更数据库或消息队列；
• • 批量操作几十台甚至几百台机器。

AI 不承担这些操作的后果。执行人承担。

如果你不理解循环、条件判断、返回值和异常处理，就很难估计一段脚本的影响范围。出了问题，也只能把错误信息继续贴给 AI，然后在它给出的几个答案之间碰运气。

这在学习环境里问题不大，在生产环境里就有点吓人了。

运维人员学习代码，本质上是在获得对自动化过程的控制权。

现在还需要背语法吗？

不用像以前那样背。

Python 的库很多，参数也多。即使写了几年代码，也不可能记住所有函数。现在有 AI 帮忙，更没有必要把时间花在死记硬背上。

但有些基础还是要懂。

你至少应该知道变量里放了什么，循环会执行多少次，条件判断在什么情况下成立，函数接收什么参数、返回什么结果。还要能看懂列表、字典、文件读写和异常处理。

对运维来说，下面这些内容很实用：

1. 1. 文件与目录处理包括路径拼接、遍历、权限、时间和软链接。
2. 2. 命令执行知道怎样安全调用系统命令，怎样读取退出码、标准输出和错误输出。
3. 3. 网络请求与 API能处理认证、超时、重试、分页和限流。
4. 4. 配置与数据格式会读写 JSON、YAML、CSV，了解编码和格式校验。
5. 5. 日志与异常出错时留下足够的信息，而不是用一个 pass 把问题藏起来。
6. 6. 幂等和回滚同一段自动化执行两次，不应该把环境越改越乱。涉及变更时，要提前想好失败后怎么恢复。

这些东西不花哨，却决定一段代码能不能在真实环境里活下去。

AI 最适合做副驾驶

我现在更愿意把 AI 当成一个写代码很快、知识面很广，但不了解现场的同事。

它可以帮我：

• • 搭出脚本骨架；
• • 解释陌生代码；
• • 补充单元测试；
• • 检查明显错误；
• • 把 Bash 改成 Python；
• • 根据报错提供排查方向；
• • 整理注释和文档。

但拿到代码以后，我还会自己做几件事。

先确认输入。参数、环境变量、配置文件和用户输入是否可信。

再看危险操作。删除、覆盖、重启、批量修改和远程执行，都需要单独检查。

然后缩小范围测试。先用临时目录、测试账号或一台机器验证，不要第一次就把目标写成整个集群。

最后补上可观察性。脚本做了什么、跳过了什么、哪里失败了，都应该能从日志和告警中看出来。

如果一段代码无法解释，也无法测试，我不会因为它是 AI 写的就更放心。恰恰相反，生成速度越快，检查时越需要慢一点。

不会写完整程序，也要能读懂关键部分

很多运维同学一听“学代码”，脑子里出现的是算法题、设计模式和大型项目。

其实没必要从这些地方开始。

你可以先挑工作里最重复的一件事：批量检查证书过期时间、整理告警、核对备份、统计服务器信息，或者调用监控平台接口生成日报。

先让 AI 给出第一版代码，然后不要马上运行。逐行问：

“这个变量从哪里来？”

“如果请求超时会怎样？”

“为什么这里要循环？”

“这条命令失败以后，脚本还会继续吗？”

“怎样改成只处理一台测试机器？”

当你能够回答这些问题时，代码就不再是一块只能复制的黑盒。

这种学习方式比从第一页开始背教材更适合现在。你一边解决真实问题，一边补齐基础。AI 负责加速，你负责理解和验收。

哪些人最容易被 AI 取代？

我不太认同“AI 会取代所有写代码的人”这种说法。

更容易受到影响的，是只负责把明确需求翻译成固定代码，却不理解业务、环境和风险的人。因为这一段工作正是 AI 最擅长的。

运维领域也是如此。

如果工作只是复制命令、照着手册操作、看到告警就重启服务，AI 和自动化平台会逐渐接走不少任务。

但线上故障很少完全照着手册发生。

监控显示数据库延迟升高，原因可能是慢查询、锁等待、磁盘抖动、网络丢包，也可能是上游突然改变了请求方式。工具可以列出可能性，最后仍需要有人结合变更记录、指标和业务现象缩小范围。

这个人不一定要手写所有代码，但必须知道系统是怎么运转的，代码又对它做了什么。

写在最后

AI 会写代码以后，学习代码仍有必要。

只是目标不该再是“所有代码都由我从零写出来”。那既慢，也没有必要。

对运维人员来说，更实际的目标是：

看得懂，改得动，敢在测试环境验证，知道什么不能直接上生产。出了问题，能沿着日志、返回值和执行路径往回查。

如果你还没有开始学 Python，可以从工作里的一个小任务入手。让 AI 帮你写第一版，但别停在复制和运行。

把每一处你看不懂的地方问清楚，把危险操作换成测试数据，把脚本的执行结果记录下来。

第一次可能很慢。第二次会快一点。

等你真的把一个每天重复的操作变成了稳定脚本，就会明白：AI 省下的是敲键盘的时间，代码能力让你知道这件事到底做对了没有。