你不知道的 AI 运维

TL;DR 我用 Claude Code 管 20 台 homelab 服务器 4 个月，产出了 151 篇运维文档、3 个自动化 Skill、一份从 9603 条交互中蒸馏出来的元规则。但这篇文章不是讲怎么用 AI 敲命令的——我想聊的是我撞出来的那条飞轮：每次运维操作不只解决问题，还让 AI 变得更强。具体路径就四个字：做 → 记 → 抽 → 炼。下面拆开讲。

我为什么开始搞这个

年初的时候我的 homelab 已经有将近 20 台设备了——两台 K8s 集群、一台 TrueNAS、一台 Synology SA6400、Windows 工作站跑 ASR 语音识别、几台 VPS 跑代理和隧道、还有一堆自托管服务。典型的 homelab 爱好者配置，不算大，但足够乱。

乱到什么程度呢？2 月份有一天，我发现 TrueNAS 上的 Docker 全挂了，挂了至少两周我完全不知道。因为我根本不记得上面跑了什么、什么时候跑的、跑的时候改过什么配置。脑子里只有一些碎片印象——「好像装过 Syncthing」「应该有个 Nginx 反代」。就这些。

后来修是修好了，但过程极其痛苦。ssh 上去看进程、翻 cron、查 systemd、读 docker-compose——每一步都像在考古。

我当时就想，这事不能再靠脑子了。我的脑子连昨天中午吃了什么都记不住，你让我记三个月前改过的 iptables 规则？

正好那段时间我开始重度用 Claude Code。就想着能不能让它帮我记住这些东西。

核心路径：一个飞轮

搞了 4 个月下来，我发现这事不是「让 AI 帮我记」那么简单。它其实形成了一个飞轮：

1
2
3
4
5
6
7
8
9

做（人+AI 协作操作）
    ↓
记（/makedoc 结构化沉淀）
    ↓
抽（同类操作 ×N → 识别模式 → 封装 Skill）
    ↓
炼（从错误中蒸馏元规则 → 注入 AI 行为）
    ↓
AI 变得更强 ──→ 回到「做」，质量更高

每转一圈，AI 就更了解我的环境、我的偏好、我的红线。转到现在，同样的巡检任务，4 个月前我要指挥 AI 一步步 ssh 上去敲命令，现在我说一句「巡检」，它自己跑完 20 台主机，出报告，标出哪些是参考数据偏差、哪些是真的故障。

下面我把这四步拆开讲，每一步我都附上真实数字和代码。

第一步：记——把操作变成结构化文档

这是最基础的一步，也是最容易被跳过的一步。

大部分人（包括以前的我）做运维的流程是：出问题 → ssh 上去 → 敲命令 → 修好了 → 完。下次同样的问题来了，继续从头排查。因为上次怎么修的早就忘了。

我 5 月初给 Claude Code 写了一个 /makedoc 命令。内容不复杂，就是一个文档模板：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# <主机名> <服务名> <动作>记录

**操作日期**: YYYY-MM-DD
**目标主机**: <主机名或 IP>

## 背景
<为什么要做这个操作>

## 问题诊断（有故障时必须）
<诊断过程、根因分析>

## 方案选择（有多条路径时必须）
<列出评估过的方案，说明取舍理由>

## 操作内容
### 1. <操作标题>
**原因**：<为什么>
**操作**：`<实际命令>`
**效果**：<结果>

## 验证
<实际验证命令和输出>

## 达成效果
| 项目 | 操作前 | 操作后 |
|------|--------|--------|

## 后续建议
### 1. <建议>（重要/建议/可选）

这个模板里最关键的设计是三段式：原因 → 命令 → 效果。

传统的运维文档只记了中间那栏——命令。但三个月后你回看，你不知道为什么当时跑的是这个命令而不是那个，也不知道跑了之后发生了什么。三段式保住了决策上下文。

效果立竿见影。加 /makedoc 之前，我每个月产 3-5 篇文档。加了之后——5 月单月 113 篇。

113 篇听起来多，但其实不累。因为模板已经把结构定好了，每次只需要填空。就像做菜——备好了料、定好了流程，炒一下很快。

第二步：抽——从重复操作中提炼 Skill

同一类操作记了 3-5 次之后，模式自己就浮出来了。

举个例子。我最开始巡检服务器的时候，流程是这样的：

1
2
3
4
5
6
7

我：ssh 到 99 看一下磁盘
AI：好的（跑 df -h，回报）
我：内存呢？
AI：好的（跑 free -h，回报）
我：Docker 容器都正常吗？
AI：好的（跑 docker ps，回报）
...重复 20 台主机...

搞了大概三次之后我受不了了。我说「你能不能自己把所有主机巡检一遍然后给我一个报告」。然后我发现——不行。因为 AI 不知道我有多少台主机、每台上面跑了什么、怎么判断正常还是异常。

这就是从文档到 Skill 的跃迁点。

我把巡检的经验——跑了哪些命令、怎么判断指标、主机列表、预期的服务——抽成了一个 fleet-health-check Skill。结构是这样的：

1
2
3
4
5
6

.claude/skills/fleet-health-check/
├── SKILL.md          ← 规则：怎么巡检、红线是什么
└── references/
    ├── hosts.md      ← 事实：主机列表和预期服务
    ├── checks.md     ← 事实：标准检查命令
    └── sample-report.md

这里有一个我反复踩坑才悟出来的设计原则：规则和事实分离。

• SKILL.md 里写的是「怎么做」——流程、红线、判断标准。这些长期不变。
• references/ 里放的是「是什么」——主机列表、端口分配、预期服务。这些随时会变。

为什么这个分离重要？因为 reference 总是会过时的。我今天加了一台新机器，如果规则和事实混在一起，就要改 SKILL.md——改来改去就改坏了。分离开之后，加机器只改 hosts.md，Skill 不用动。

还有一个更绝的设计：发现优先，然后对比。

传统的监控思维是「reference 是真相，跟 reference 不一样就是故障」。但实际运维中，reference 本身经常是过时的。所以我让 Skill 的执行流程是：

1. 先探测实际状态（ssh 上去 ps、docker ps、df -h）
2. 再跟 reference 对照
3. 不一致时——不报故障，标为「参考数据偏差」

1
2
3
4
5

Reference 说这是 K8s 节点 → 实际 kubectl 不可用
  → 不报严重，标记为「参考数据偏差」
  → 报告里写：reference 可能需要更新

磁盘 92% → 这才是真的严重，跟 reference 无关

这个设计让巡检报告的可信度高了很多。以前跑巡检，一半的告警都是 reference 没更新导致的假阳性。现在假阳性基本清零。

第三步：炼——从错误中蒸馏元规则

这一步是整个飞轮里最被低估的，但我觉得最有价值。

事情是这样的：5 月底有一天我让 AI 帮我诊断一个服务问题，它在巡检过程中自己决定重启了一个 Docker 容器。我当时就炸了。

我骂了它一顿之后，开始想一个问题：为什么这种错会反复出现？翻了一下聊天记录，发现类似的「AI 在诊断时自作主张做写操作」之前已经发生过至少三次了。每次都骂，每次都改，但换了新会话 AI 又忘了——因为新会话是新的上下文，不记得上次被骂过。

这时候我意识到：我需要一个跨会话的记忆系统。不是让 AI 自己记忆——它在不同会话之间是失忆的——而是把教训写成规则文件，每个新会话自动加载。

花了两天时间，把 486 个 Claude Code 会话、9603 条历史交互全部扫了一遍，提炼出了 14 条执行经验和 10 条行为准则。产出了一份 CLAUDE-LESSONS.md。

这些规则跟普通文档不一样——它们不是「建议」，是分级约束：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

## 硬性红线
1. 诊断/巡检 = 只读。在用户明确授权前，不执行任何会改变系统状态的命令。
2. 不修改 reference 文档。除非用户明确要求更新。
3. 不"顺手"操作。发现可优化项 = 建议，不自动执行。

## 每次操作前自问
- [ ] 这个命令会修改远程主机吗？ → 如果是，先汇报
- [ ] 我有没有在用 `python` 而不是 `uv run python`？
- [ ] 改的范围是不是扩散了？

## 搜索规则
声称"未找到"之前，必须说明搜索范围和方法。
使用 type -a + which + find + grep 四种方法并行。

红线是不可商量的。规则是默认遵守的。自问清单是每次都会检查的。

然后在 CLAUDE.md 里加了一句话：

1

> 请同时阅读 CLAUDE-LESSONS.md，所有会话必须遵守。

就这一句话。每个新会话的 AI 自动加载全部经验，红线不会因为换会话就消失。

这一步把知识库从「记录做了什么」拉到了「记录怎么做得更好」。它是关于如何做文档的文档——元文档。

第四步：做——飞轮闭合

飞轮转完一圈，回到「做」这一步的时候，体验已经完全不同了。

对比一下 2 月和 6 月的同一次巡检：

最关键的变化是信任。2 月份我不可能让 AI 自己去碰我的服务器——它连我有多少台都不知道。现在我可以放心让它巡检，因为它知道红线在哪里、碰到了会先问我。

我得到的不只是一个文档库

4 个月后回头看，这套东西给我带来的不是「文档很多很好看」。是三个实实在在的变化：

第一，记忆外化。 6 月 2 号我的 TrueNAS 存储池 npool 丢了——RAIDZ1，4 块 6TB SAS 盘，上面 10TB 数据。这是一个严重故障。但因为之前有过一份 ops-summary，记录了磁盘布局、HBA 直通配置、NFS 共享列表，两个 Claude Code 会话接力完成了完整诊断和恢复。从发现问题到全部服务恢复，589 行的完整复盘文档也留在仓库里了。下次再出事，不用考古。

第二，AI 变成了真正的搭档。 2 月份的 AI 像刚入职的实习生——能干活但需要每一步指导，而且会犯低级错误。6 月份的 AI 像一个了解我全部环境的工程师——知道红线、知道偏好、知道什么时候该问我什么时候可以自己判断。

第三，飞轮还在加速。 151 篇文档之间形成了 53 处交叉引用。一篇文档里出现的问题，链接到另一篇里记录的根本解决方案。这不是 151 个孤立的知识点，是一张正在生长的知识网络。

最后说两句

我分享这套方法不是因为我觉得自己搞得很牛。恰恰相反——正是因为前面踩了太多坑，被 AI 气到骂人好几次，才逼出了这套东西。

如果你也在用 AI 做运维，或者更广义地说，用 AI 做任何需要长期积累的工作，我觉得值得试试这个飞轮：

1. 做完必记——定一个模板，把操作结构化（原因→命令→效果）
2. 重复三次就抽——同类操作出现 3-5 次，封装成 Skill
3. 被 AI 气到就写规则——每次纠偏都是一条元规则的原材料
4. 让规则自动加载——新会话 = 新 AI 实例，但规则让它们共享经验

这不是让 AI 替代你做运维。是让每次运维都把 AI 变得更强一点。

下一篇打算写：从 9603 条交互数据里，我到底学到了什么关于人机协作的东西。