**可以**.

只有一个前提:

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



> 📝声明:
>
> - 古法匠心, 纯人工手工写作
> - 本文 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](https://developer.qcloudimg.com/http-save/yehe-4067298/d028fef9db8759ed2f817dfc41572459.png)

#### 我的部署方案

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

#### V2 发生了哪些改变?

> 📚️参考文档:
>
> [Migrate from v1.x Local Database to ... · LobeHub](https://lobehub.com/docs/usage/migrate-from-local-database)

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

1. pgsql 要从 16 升级到 17, 而且不是原生 pgsql, 而是从: pgvector 16 升级到 paradedb 17 😱
2. 数据不能丢
3. LobeChat 的认证体系发生了巨变: 从 next auth 切换到了 better auth.
4. 官方文档(上面的参考文档)就一页, 只是个描述性的文档, 而不是详细的一步到一步步骤文档. 而且这个文档不适用于我, 因为我不是 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.](https://github.com/OthmanAdi/planning-with-files)) skill: 

```plaintext
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个文件:

- [homelab2/apps/lobe-chat/docs/migration/v2/findings.md at master · east4ming/homelab2](https://github.com/east4ming/homelab2/blob/master/apps/lobe-chat/docs/migration/v2/findings.md)

- [homelab2/apps/lobe-chat/docs/migration/v2/progress.md at master · east4ming/homelab2](https://github.com/east4ming/homelab2/blob/master/apps/lobe-chat/docs/migration/v2/progress.md)
- [homelab2/apps/lobe-chat/docs/migration/v2/task_plan.md at master · east4ming/homelab2](https://github.com/east4ming/homelab2/blob/master/apps/lobe-chat/docs/migration/v2/task_plan.md)

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

▽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 迁移命令.

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

![总结报告](https://developer.qcloudimg.com/http-save/yehe-4067298/7d2c27ae94c826e9f12a5124e2fbfe18.jpg)

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

- [homelab2/apps/lobe-chat/docs/migration/v2/生产环境监控检查清单.md at master · east4ming/homelab2](https://github.com/east4ming/homelab2/blob/master/apps/lobe-chat/docs/migration/v2/生产环境监控检查清单.md)
- [homelab2/apps/lobe-chat/docs/migration/v2/用户反馈收集模板.md at master · east4ming/homelab2](https://github.com/east4ming/homelab2/blob/master/apps/lobe-chat/docs/migration/v2/用户反馈收集模板.md)
- [homelab2/apps/lobe-chat/docs/migration/v2/用户迁移通知模板.md at master · east4ming/homelab2](https://github.com/east4ming/homelab2/blob/master/apps/lobe-chat/docs/migration/v2/用户迁移通知模板.md)
- [homelab2/apps/lobe-chat/docs/migration/v2/紧急回滚计划.md at master · east4ming/homelab2](https://github.com/east4ming/homelab2/blob/master/apps/lobe-chat/docs/migration/v2/紧急回滚计划.md)
- [homelab2/apps/lobe-chat/docs/migration/v2/迁移总结报告.md at master · east4ming/homelab2](https://github.com/east4ming/homelab2/blob/master/apps/lobe-chat/docs/migration/v2/迁移总结报告.md)

说实话, 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](https://github.com/east4ming/homelab2/commit/ba0d16c2dc674c4db15681da6338d61cf740dcdc)

![Migration PR](https://developer.qcloudimg.com/http-save/yehe-4067298/afad7fe940aa203cf8ff2ce26d863525.jpg)

#### 总结

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

![费用](https://developer.qcloudimg.com/http-save/yehe-4067298/2422052a11cd59e11c800709f2a2e4a3.jpg)

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

相比上面任务, 这次任务相对简单点. 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 可以取代运维**.

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

最后, 放一张囧图活跃下气氛~

![码奸](https://developer.qcloudimg.com/http-save/yehe-4067298/9217c16de2347b111a9be73e802ef52d.jpg)

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

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

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

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

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

与君共勉.

EOF

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

AI 可以取代运维了吗?

人工智能

运维

AI技术已能100%取代传统运维工作，通过实战案例证明AI可高效完成数据库迁移、服务升级等复杂任务。文章展示AI在LobeChat升级和文档网站部署中的出色表现，强调运维需转型为"可见、标准化、自动化"模式。AI不仅能完成90%运维工作，文档规划更优于人工，成本仅需6.5元/天。

数据备份

Kubernetes

数据库

ChatGPT

Docker

GitHub

Agent

2026采购季 | AI焕新·智启新局

tencentdb-catalog

domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI 可以取代运维了吗?-腾讯云开发者社区-腾讯云

AI 可以取代运维了吗?

AI 可以取代运维了吗?

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐