AI 可以取代运维了吗

本文最后更新于：2026年4月1日上午

可以.

只有一个前提:

贵司不是采用 "防御式运维" 的策略.

📝声明:

古法匠心，纯人工手工写作

本文 100% 由我手工写作而成

本文非 AI 生成

背景

AI + AI IDE/CLI 取代开发的趋势已经很明显了.

作为一个运维，居安思危，我自然开始认真🤔起来这个问题: AI 可以取代运维了吗？

为此，我通过数个实战案例来交给 AI 实施，包括：运维常见的工作:

数据库迁移
应用升级
上线新服务
…

结果是我大大低估了 AI 的能力，实际效果比我预期中最好的情况还要好.

我们来看看吧.

实战

实战一: LobeChat v1 升级到 v2

LobeChat 简介

LobeHub (v1 叫 LobeChat, v2 改名叫 LobeHub 了)，这玩意儿简直就是为我们这种喜欢折腾的人量身定做的。说实话，用 ChatGPT 还得翻来覆去切换窗口，太麻烦了。但 LobeHub 不一样，它让你能组建自己的 AI 团队。

想象一下：你可以创建一个专门写代码的 Agent，一个负责文档整理的 Agent，还有一个帮你做数据分析的 Agent，它们还能互相协作！这感觉就像在玩《星际争霸》一样，只不过你的 "单位" 都是 AI。

最让我心动的是它的自托管能力。一条 Docker 命令就能搞定全套服务，数据完全掌握在自己手里。对于那些担心隐私问题的朋友来说，这简直是福音。

我主要用它的这些功能：各种助理 (喷人的，润色文章的，解析国际局势的，王阳明心学教学，理财…), 还有 RAG 文档资源管理能力。

如果你也厌倦了在各种 AI 工具之间来回切换，或者想要一个完全私有的 AI 工作空间，强烈建议试试 LobeHub。GitHub 上 74.4k 的星星不是白给的，社区活跃度也很高。

一句话总结： LobeHub 让你从 "使用 AI" 变成 "管理 AI 团队"，而且完全私有化，数据自己说了算。

我的升级后的 LobeChat v2 如下图:

我的自托管 LobeChat v2

我的部署方案

LobeChat v1 有 Docker Compose 部署方案，我将其改写为了 K8s Manifests 并部署在我的 Homelab. 具体可以见我之前的配置: homelab2/apps/lobe-chat at 3855a4c141a4c9cd8c503d891be38a032766bb15 · east4ming/homelab2

V2 发生了哪些改变？

📚️参考文档:

Migrate from v1.x Local Database to … · LobeHub

LobeChat v2 发生了巨大的改变，这导致这次迁移的难度我都觉得很大😖:

pgsql 要从 16 升级到 17, 而且不是原生 pgsql, 而是从: pgvector 16 升级到 paradedb 17 😱
数据不能丢
LobeChat 的认证体系发生了巨变：从 next auth 切换到了 better auth.
官方文档 (上面的参考文档) 就一页，只是个描述性的文档，而不是详细的一步到一步步骤文档。而且这个文档不适用于我，因为我不是 docker-compose 部署的…😑

AI 登场

🎉虽然有这么多困难，但是确实在 AI 的帮助下坎坷但最终顺利完成了🎉🎉🎉

我使用的是 Claude Code, 模型是通过 API 对接的 DeepSeek (后面用了其他模型，才知道 Deepseek 当前能力不算第一梯队的，但就是这也完成的很好). 并且使用了 [planning-with-files](OthmanAdi/planning-with-files: Claude Code skill implementing Manus-style persistent markdown planning — the workflow pattern behind the $2B acquisition.) skill:

1
2
3

task_plan.md      → Track phases and progress
findings.md       → Store research and findings
progress.md       → Session log and test results

这里之所以要用 planning-with-files skills. 是因为:

这是个非常有挑战性的运维 - 迁移任务，需要消耗大量 Context
运维工作就是这样，需要做好方案规划.
使用该 skills, 可以确保有需求，有设计规划，最重要的是：迁移进度通过 tasks 实时追踪。不会丢失上下文.

`planning-with-files`

AI 先规划了这 3 个文件:

完整的内容我就不贴了，面得浪费各位读者时间。感兴趣的可以点击👆的链接查看.

findings

Lobe Chat 从 v1 迁移至 v2 生产环境方案总结

核心目标
关键变更与要求
已完成的准备工作
技术决策与风险缓解
后续计划

progress

迁移项目总结报告

项目概述
关键步骤与成果
- 准备与评估 (Phase 1)
- 数据库升级 (Phase 2)
- 认证系统迁移 (Phase 3)
- 部署与验证 (Phase 4)
- 收尾与监控 (Phase 5)
最终状态

task_plan

任务概述
关键进展与完成状态
核心决策与注意事项
环境信息
- 生产域名：west-beta.ts.net
- 网络配置：Tailscale Ingress 与 ExternalServices
- 用户邮箱
总结

小结一下，客观来说，写的比我好多了 (不然我也不可能现在还是个运维😂), 考虑也非常周全.

实施

实施过程就像上面规划的文档一样，一步一步走.

这里我取巧了，先手动关了 argocd 的自动同步功能。然后让 AI 修改 k8s manifests, 修改完之后直接 kubectl 命令部署或执行 pgsql 迁移命令.

不过最终确实顺利完成了. 🎉🎉🎉

总结报告

并且还生成了更多的相关文档:

说实话，1, 4, 5 我也能想到，但是 “用户反馈收集” 和 “用户迁移通知” 属实是我想不到的环节😂.

👍️AI 优点

AI 可以完成 90% 的工作 (剩下 10% 需要在我的介入下完成。我认为原因不在 AI, 而是我的 GitOps repo 缺少某方面的可见性，导致 AI 不了解那些方面的内容，从而导致误判。后面更详细说明)
AI 做了非常详尽的规划
AI 在迁移前，中，后一直保持着文档的实时更新 (我自问我最多只能保证一份 excel todo 清单的实时更新)

👎缺点

虽然我的部署信息基本全在 git 上了，但是还是存在一些漏网之鱼，着导致 AI 可能缺乏实际生产环境的一些关键信息 (如：数据备份机制，secret, PV 内数据等) (这是我的问题)
规划的很好文档中一直强调数据很重要，但是执行过程中还是会随意使用 rm, delete, drop 等命令。所以权限一定要严格把控
这是目前 AI 最大的问题 - 它会欺瞒. AI 对于没有成功的步骤，有时会假装没看到，继续执行后续步骤，文档也会标记为✔️已完成. (比如我的数据库 dump 恢复失败了，它就直接跳过并标记完成了 😂😂😂)
AI 的 128K 上下文多次用完，可能导致关键信息丢失。所以一定要跟 AI 说边实施边做记录.

🫣详细记录在这里:

Merge pull request ‘feat (lobe-chat): 实现 v2 迁移准备工作’ (#312) from lobehub-…・east4ming/homelab2@ba0d16c

Migration PR

总结

AI 花了一整天，6 块 5 毛钱。就成功地完成了这次任务.

实战二：上线新服务 - 在线文档网站

相比上面任务，这次任务相对简单点. AI 完成的也更出色. 100% 完成，0 人工介入！

任务概述

这是我在公司的项目，我在公司有个 gitops-monitor repo. 里边就是我负责的运维的全部内容。我想基于该 repo 生成一个使用 mkdocs, 基于我的 repo 里的 markdown 文档，中英双语的在线文档网站.

这次改为使用公司配发的 Kiro IDE

AI 登场

Kiro Specs

Kiro Specs 先生成了 3 份文档:

Requirements -> Design -> Tasks

Requirements: 相当于业务 / 领导提出需求，你给出的细化；
Design: 相当于你的迁移方案；
Tasks: 相当于实际迁移时的 Excel 任务清单.

Requirements

需求文档内容:

简介
术语表
需求
- MkDocs 项目配置
- 中英文双语支持
- Git 分支管理
- Kubernetes 部署清单
- AWS ALB Ingress 配置
- MkDocs 静态文件和部署流程

这里可以看到，它将我模糊的描述细化为具体的明确的需求。并且每个需求都有：用户故事和验收标准.👍️

Degign

技术设计文档

概述
架构 (这里 AI 画了个流程图👍️)
组件设计
- MkDocs 配置 - mkdocs.yml
- Kubernetes 部署清单 - 计划编写个 mkdocs helm chart (包括: deploy, PVC, ConfigMap, Service, Ingress)
- ArgoCD 自动发现 (AI 分析后发现 ArgoCD 是自动发现的，ArgoCD 这块无需额外配置)
- 构建与部署
- i18n 双语实现
- Git 分支策略 (feature 开发，通过 PR 合并到 main 分支部署)
实现任务

Tasks

实施计划

概述
任务清单 (列了 7 个大项任务和更多的小任务，并标明任务间的相互依赖，并在完成后实时更新该文档 - - [x])
备注

实施

写代码阶段反而不用详述，这是 AI 的强项。它写了:

mkdocs.yml
helm chart

出色地，0 人工干预地完成了任务. 🎉🎉🎉

👍️优点

AI 可以完成 100% 的工作，0 人工介入
AI 做了非常详尽的规划
AI 在迁移前，中，后一直保持着文档的实时更新

👎缺点

总结

这次的任务更简单，repo 上信息完整，用的模型也更强. AI 完美地👐完成了任务。毫无缺点.

回答问题

问: AI 可以取代运维了吗？

答: 可以. (不是部分可以，而是完全可以，100% 可以.)

只有一个前提:

贵司不是采用 "防御式运维" 的策略.

“防御式运维” 指的是啥？

任何运维的反模式:

运维代码不可见 (你的运维代码不可见，不在 git repo, 没有 CMDB, 没有变更记录)
配置漂移 (你的运维信息可见，但是和实际生产环境相比不准)
孤岛 (你的运维是个孤岛。是个遗留系统。是上个时代产物。是老古董。是诡异而奇怪的存在.)
架构混乱 (你的运维没有架构，没有设计良好的架构，没有稳定刚性且不可变的架构，没有健壮的架构)
非结构化
非标准化 (只能 UI 点，没有标准 API 接口)
不可被观察
纯手工工匠精神。没有自动化，没有使用 IaC 或 GitOps, 甚至没有 ansible 类的配置管理工具.
没有运维信息真实来源
环境不一致 (开发，测试，uat, 性能和生产不一致)
没有版本控制
运维信息不可读，无法理解
…

总结

我相信，通过👆上面的两个案例。我们已经可以清楚地知道这样一个答案: AI 可以取代运维.

对于复杂的迁移工作. AI 花了一天时间，6.5 元就完成了工作.
对于相对难度中等的新服务上线. AI 100% 圆满地完成了工作，0 人工介入
一个 Coding Plan 月度订阅费大概在 20💵, 就可以替换掉一个 (公司人力成本上万) 的运维同僚
AI 文档写的更好
AI 状态更新更及时
AI 考虑的更全面
AI 向上管理汇报也更漂亮
…

最后，放一张囧图活跃下气氛～

尽管如此，我们运维也不需要焦虑担忧，

我想到刘禹锡那句 “沉舟侧畔千帆过，病树前头万木春”。
技术迭代从来不是淘汰，而是生态的焕新。AI 像那千帆、像那万木，它替代的只是重复的 “操作”，却永远替代不了运维人在无数深夜故障中修炼出的系统直觉、在业务与技术的夹缝中长出的架构智慧，以及面对未知风险时那份 “敢重启、敢背锅”🤨的责任担当。

换个角度看，你过去所积累的故障库、你亲手画过的拓扑图、你在告警洪流中瞬间定位根因的 “第六感”—— 这些都不是数据能完全复刻的经验资产。AI 终将是你的 “超级协作者”，把琐碎交出去，让你更专注于创造与决策。

所以，不妨用另一句诗自勉：“天生我材必有用，千金散尽还复来。”
你的 “材” 从来不只是命令与脚本，而是你在复杂系统里游刃有余的掌控力，是你在技术与人情之间搭建桥梁的软实力。这些，AI 学不会，也拿不走。

运维人的价值，不在工具里，而在每一次化险为夷的镇定里。

与君共勉.

EOF

#AI #运维管理

AI 可以取代运维了吗

https://ewhisper.cn/posts/56951/

作者

东风微鸣

发布于

2026年4月1日

许可协议

家庭网络如何获取到公网 IPv6 下一篇