网上谈 AI 工具的文章大多是"AI 将彻底改变 XX 行业"这种调调，对实际做运维的人用处不大。我想写的是一篇更务实的文章：日常工作里哪些地方用 AI 真的省了时间，哪些地方靠不住，以及怎么用得更有效。
哪些场景真的有用#
1. 写 Shell 脚本#
这是我用 AI 最频繁的场景，原因很简单：Shell 脚本语法细节多，容易写错，而 AI 对这类"有固定模式"的问题非常擅长。
典型需求：写一个脚本，批量检查 K8s 集群里所有 namespace 的 ConfigMap 是否包含某个 key
直接描述需求：
写一个 bash 脚本，遍历当前 kubeconfig 对应集群的所有 namespace，
检查每个 namespace 中是否存在名为 app-config 的 ConfigMap，
如果存在，检查其中是否有 key "database_url"，
输出每个 namespace 的检查结果，
格式：namespace名 | configmap是否存在 | key是否存在
生成的结果通常只需要小幅调整（比如改输出格式），直接可用。比我自己翻 bash 手册查语法快了不少。
另一个高频场景：aws cli 命令组合
用 aws cli 列出所有 region 中状态为 running 的 EC2 实例，
输出：region、instance-id、instance-type、public-ip、private-ip，
用 tab 分隔
# AI 生成的脚本
for region in $(aws ec2 describe-regions --query 'Regions[*].RegionName' --output text); do
aws ec2 describe-instances \
--region "$region" \
--filters Name=instance-state-name,Values=running \
--query 'Reservations[*].Instances[*].[Tags[?Key==`Name`].Value|[0],InstanceId,InstanceType,PublicIpAddress,PrivateIpAddress]' \
--output text | \
awk -v region="$region" '{print region"\t"$0}'
done
2. 解读错误信息#
遇到不熟悉的错误码或堆栈，粘贴给 AI 通常能得到比搜索引擎更快的答案，因为 AI 会直接给出可能原因和排查方向，不需要你自己从多个 Stack Overflow 帖子里拼信息。
例如把这段错误粘进去：
Error from server: etcdserver: request timed out, possibly due to connection lost
直接问：
这个错误是什么意思？在 K8s 中什么情况会出现？如何排查？
得到的回答会涵盖：etcd 连接问题的常见原因（网络分区、etcd 成员宕机、磁盘 IO 过高）、排查命令（etcdctl endpoint health、etcdctl endpoint status），以及常见解决方案。
比搜索"etcdserver request timed out"然后浏览多个结果快得多。
3. 生成 Kubernetes YAML#
K8s 的 YAML 结构繁琐，细节多，写从零开始的 manifest 很费时间：
写一个 K8s Deployment YAML：
- 名称：my-app
- 镜像：my-app:latest
- 副本数：3
- 资源限制：cpu 200m request / 500m limit，memory 256Mi request / 512Mi limit
- 环境变量：DATABASE_URL 来自 Secret my-app-secret 的 key db_url
- 存活探针：HTTP GET /health，初始延迟 15s，间隔 30s
- 就绪探针：HTTP GET /ready，初始延迟 5s，间隔 10s
- 非 root 用户运行（UID 1001）
- 标签：app=my-app，version=v1
生成的 YAML 通常结构完整，拿来改改就能用，比自己从文档拼装快得多。
4. 写 Prometheus 告警规则#
Prometheus 的 PromQL 语法不直观，特别是一些复杂的聚合和 rate 计算：
写一个 Prometheus 告警规则：
- 检查 http_requests_total metric
- 计算过去 5 分钟的错误率（status=~"5.."）
- 阈值：错误率 > 1%
- 持续 5 分钟触发
- 标签：severity=critical，service={{ $labels.service }}
- 注解：包含当前错误率数值和 runbook 链接占位符
# 生成结果（稍作调整）
groups:
- name: http_error_rate
rules:
- alert: HighHttpErrorRate
expr: |
(
sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))
/
sum by (service) (rate(http_requests_total[5m]))
) > 0.01
for: 5m
labels:
severity: critical
service: "{{ $labels.service }}"
annotations:
summary: "{{ $labels.service }} HTTP 错误率过高"
description: "当前错误率: {{ $value | humanizePercentage }}"
runbook: "https://wiki.internal/runbooks/high-error-rate"
5. 解读日志#
把一段日志粘贴进去，问 AI “这里发生了什么”——这招比自己盯着日志一行行读有效，尤其是不熟悉的中间件（比如第一次碰到 Kafka consumer lag 的日志，不确定哪些是正常的）。
# 先把日志格式化粘贴
kubectl logs my-pod -n production --since=10m | head -100
# 然后告诉 AI：
# 这是一个 Python 服务的日志，发版后开始报错，帮我分析根因
哪些场景靠不住#
1. 让 AI 分析你没粘贴的日志#
这是最常见的无效用法：
我的 K8s Pod 一直 CrashLoopBackOff，是什么原因？
AI 只能猜——可能是 OOM，可能是健康检查失败，可能是配置错误，可能是依赖服务不可用……这些都是泛泛的猜测，对实际排查没有帮助。
有效的做法是：先获取信息，再给 AI 分析。
# 先自己获取数据
kubectl describe pod my-pod -n production > /tmp/pod-describe.txt
kubectl logs my-pod -n production --previous > /tmp/pod-logs.txt
# 然后把内容粘给 AI：
# 这是一个 Pod 的 describe 输出和前一次的日志，帮我分析为什么 CrashLoopBackOff
2. 让 AI 猜集群状态#
我的集群节点资源不够了，应该怎么配置 Karpenter？
AI 不知道你的节点规格、工作负载特征、当前 Karpenter 配置，给出的建议只是通用文档，价值有限。
给足上下文才有用：
我的 EKS 集群用 Karpenter，当前 NodePool 配置如下：[粘贴配置]
我的工作负载主要是 CPU 密集型的 Go 服务，peak 时有约 200 个 Pod 需要调度
现在扩容速度太慢，请帮我分析配置哪里可以优化
3. 依赖 AI 做安全决策#
AI 可能给出看起来合理但有安全漏洞的建议。涉及安全策略（IAM 权限、网络策略、RBAC）的配置，生成后必须自己理解每条规则的含义，不要无脑应用。
4. 让 AI 帮你调试它自己不了解的系统#
如果你用的是内部系统（自建平台、定制化的工具），AI 不知道这些系统的实现细节，给出的答案会基于类似的开源系统做猜测，准确率很低。
Prompt 技巧#
给足上下文#
# 差：
怎么优化 Dockerfile？
# 好：
我有一个 Python FastAPI 服务的 Dockerfile，当前构建完镜像 1.2 GB，
构建时间 4 分钟，请帮我优化。当前 Dockerfile 如下：
[粘贴 Dockerfile 内容]
期望：镜像大小 < 200 MB，构建有缓存时 < 1 分钟
指定输出格式#
帮我写一个检查 K8s 集群所有 PVC 使用率的脚本。
要求：
1. bash 脚本
2. 输出格式：namespace | pvc名 | 总容量 | 已用 | 使用率%
3. 按使用率从高到低排序
4. 添加注释说明关键步骤
让它解释，不要只给答案#
帮我解读这段 PromQL 表达式：
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))
请：
1. 解释这个表达式的含义
2. 解释 histogram_quantile 的工作原理
3. 指出这个写法的潜在问题
这样既得到了答案，也学到了背后的原理，下次遇到类似问题自己能处理。
要求它列举假设和不确定性#
帮我分析这个 OOM 问题。
相关信息：
- Java 服务，heap 设置 -Xmx 2G
- 容器 memory limit 2.5 Gi
- OOM 时日志：[粘贴日志]
- GC 日志：[粘贴]
请列出可能的原因（按可能性从高到低），并指出哪些需要更多信息才能确认。
AI 辅助故障排查工作流#
实际操作中，我把 AI 作为"知识库助手"嵌入排查流程，不是替代排查，而是加速信息处理：
Step 1: 收集信息（自己做）
├── kubectl describe / logs
├── Grafana 看板截图
├── 相关服务日志
└── 最近的发版记录
Step 2: 初步判断（AI 辅助）
├── 把收集到的信息粘贴给 AI
├── 问：可能的原因有哪些？按可能性排序
└── 得到排查方向列表
Step 3: 逐一验证（自己做）
├── 按 AI 给的方向逐一排查
└── 排除法缩小范围
Step 4: 碰到不熟悉的命令/配置（AI 辅助）
├── 问：这个命令怎么用？
├── 问：这个配置参数什么意思？
└── 快速获取知识，继续排查
Step 5: 找到根因后（AI 辅助）
└── 问：这类问题的修复方案有哪些？对比优缺点
局限性清单#
用了一段时间后，对 AI 工具的局限性有了比较清醒的认识：
幻觉问题：AI 有时候会自信地给出错误的命令或不存在的参数，这个问题在不熟悉的领域最危险。解决方法：拿到答案后，关键命令一定要查文档验证，不要直接在生产环境跑。
知识截止：AI 的训练数据有截止日期，对很新的工具版本（比如最新的 Kubernetes 功能）可能给出已过时的用法。
不知道你的环境：AI 不知道你的集群配置、网络拓扑、组织规范。给出的方案可能在你的具体环境里行不通。
不能实时操作：AI 给你一条命令，你还是要自己执行并看结果。它不能直接帮你操作系统，信息的往返在你和 AI 之间。
安全性需要自己把关：AI 生成的 IAM policy、RBAC 配置等，可能权限过宽或者有安全风险，不能无脑信任。
工具推荐：各自的适合场景#
| 工具 | 最适合场景 | 不适合场景 |
|---|---|---|
| Claude | 复杂问题分析（长上下文）、解读大段日志/代码、需要详细解释的问题 | 代码自动补全 |
| Cursor | 写脚本/配置文件、代码库级别的修改（理解上下文）、重构 | 无代码库上下文的问答 |
| GitHub Copilot | 编辑器内代码补全、写单个函数/脚本、IDE 集成 | 复杂多步骤问题分析 |
| ChatGPT | 通用问答、文档写作 | 长上下文分析（GPT-4 窗口相对小） |
对于运维工程师，日常使用频率最高的场景：
- 写脚本/YAML → Cursor（有文件上下文）或 Claude（复杂需求描述）
- 解读错误/日志 → Claude（支持长文本粘贴）
- 代码补全 → GitHub Copilot（编辑器内无缝集成）
AI 工具改变了我处理"不熟悉领域"问题的方式：以前遇到不熟悉的技术，要花 30 分钟翻文档和博客找答案；现在可以直接描述问题，5 分钟内得到一个可用的起点，再花时间验证和调整。
但它没有改变排查问题需要收集真实数据、逐步验证假设的核心流程。AI 是工具，不是替代思考的捷径。
