前几天 V2EX 上有个帖子挺火，标题是《别说开发了，这把运维真给干没了把》。楼主的意思是：现在弄个定时任务，AI 半夜上线几分钟就搞定，还能 24 小时不歇，运维这活儿怕是快没了。
一天下来六十多条回复、六千多阅读，正反两边吵得不轻。我把两边的话都捋了一遍，最扎人的不是"AI 会不会做"，是"出了事谁背"。
反方最狠的，不是质疑 AI 的能力，是质疑它敢不敢担责。
有人说得很直白：AI 运维要是发现磁盘报警，顺手把 data 目录删了怎么办？底下紧跟着一句——AI 能背锅了？这两句点到了根上。运维这行的分量，一半在把事做对，另一半在出事那一刻有人站出来。它不只是一个执行岗。
也有人从更专业的角度泼了冷水，大意是：把运维理解成"由人在生产环境敲命令"、现在换成 AI 敲，基本能鉴定为没干过有难度的活。这话听着刺耳，但说的没错——运维的重头戏从来不是敲命令本身，是判断该敲什么、权衡代价、对结果负责。
正方的说法里，有一条我觉得最实在。
它反问：为什么默认"AI 运维"就等于 AI 直接操作线上？固定流程的，让 AI 写程序、用程序去跑；不是流程的，把允许的操作封成工具（他提的是 MCP 那一套），AI 只能查、只能在许可范围里改；剩下那百分之一真正危险的操作，出脚本、由人确认再执行。
这个分法我挺认同，因为它把一句很模糊的"AI 能不能干运维"，拆成了三个能落地的圈：
- 能交给它的：读日志、对版本、查配置、把几十台机器的现状汇总成一张表。这些活费人、又不直接改动什么，AI 干得又快又稳。
- 得留个闸的：重启服务、改配置、删文件、动数据库。不是不能自动化，而是每一步都要有人复核——危险操作出脚本、按下确认。
- 只能靠人的：谁决定上线、谁按确认、谁在事后复盘里签字。这个锅，模型背不动。
回到帖子那个问题：AI 会不会把运维干没了？
我的看法是，它先把"执行命令"这一大块狠狠削掉——以前半夜爬起来登机器敲两行的事，现在确实能交给脚本和模型干。但"决定敲什么、敲之前想清楚会不会把 data 删了、出事顶上去"这部分，它现在还接不住，短期也不像接得住。被削掉的是手脚，不是判断和担责。
所以与其焦虑被取代，不如着手把分工划清楚：哪些操作放进"AI 可以随便查"的圈，哪些必须放进"人点头才能动"的圈。这条线画得越早，AI 越像个能用的助手；画不清，它就越像一颗不知道什么时候响的雷——而且到时候没人替它背。
说两个我自己踩过的坑，都指向同一条：把"允许它做什么"提前写死，比事后骂它乱做好使得多。自动化里一句 pkill 把自己也杀了，这种错人写会犯、模型写一样会犯；还有一次，一段纯只读的排查被人当成了安全评估，该拦的没拦、不该拦的拦了一堆。
原帖在这儿：别说开发了，这把运维真给干没了把（V2EX，2026-10-24）。
评论