这是一个虚构但很典型的案例：陈姐是一位负责服务器、发布流水线、监控告警和故障处理的运维或 SRE，最近手头在忙“完成两台数据库服务器的磁盘扩容”，同时还要准备“推进日志集中采集”。这次陈姐需要整理一份给技术负责人的变更方案，决定试试 AI 排查程序报错。

背景

对陈姐来说，告警多、脚本杂、变更文档和故障复盘写起来费时，夜间排障时更需要快速理清思路。偏偏这次还遇到一个变数：机房网络计划维护，可能影响夜间批处理任务。变更方案需要尽快交给技术负责人，时间并不宽裕。

第一次尝试：问题出在哪

陈姐一开始只写了一句话：

帮我写一份关于“把发布流程迁移到容器化部署”的变更方案。

结果 AI 给出的内容四平八稳却用不上。复盘下来，主要有两个问题：

  • 只说“程序报错了”
  • 在生产环境直接执行 AI 给的命令。

改进后的提示词

陈姐按照 AI 排错的思路重写了提示词，核心是说明运行环境：语言版本、框架版本、操作系统：

我遇到一个问题，请帮我排查。
- 现象：[描述]
- 完整报错：[粘贴报错和堆栈]
- 环境：[语言/框架/系统版本]
- 最近的改动：[描述]
- 复现步骤：[步骤]
- 预期结果 vs 实际结果：[描述]
请：
1. 解释报错的含义；
2. 列出 3-5 个可能原因，按可能性排序；
3. 对每个原因给出验证方法（我该看什么、运行什么）；
4. 先不要直接给修复代码，等我反馈验证结果。

结果（示意）

下面的效果为虚构演示，用来说明这类改进通常带来的变化：

示例（虚构）：一位开发者的程序在本地正常，部署后报“找不到模块”。AI 列出三个可能原因：依赖未安装、版本不一致、路径大小写问题，并给出对应的检查命令。第三个检查发现文件名大小写在服务器系统上不匹配，问题解决。

拿到结果后，陈姐没有直接转发，而是先检查关键事实和数字，再补上 AI 不知道的背景。

复盘：这次用到的方法

  • 提供相关代码和最近的改动。
  • 描述复现步骤，以及预期行为和实际行为。
  • 让 AI 列出可能原因并按可能性排序，给出验证方法。
  • 提供完整报错、环境、代码和复现步骤，信息越完整定位越快。

之后陈姐发现，同样的方法也适用于另一类场景：部署、配置、环境相关的问题。

复盘时陈姐还想到一个问题：如何避免同样的问题再次出现？答案是：修复后补充测试、完善日志，并把原因和解决方法记录下来。

给运维工程师的提醒

让 AI 写的命令先在测试环境执行，并要求它说明每个参数的作用。涉及删除、重启、改权限的命令，必须先确认影响范围并做好回滚准备，不能照抄执行。另外，对话里不要出现服务器 IP、账号口令、证书私钥和内部拓扑。

一个额外的小技巧：把排查过程记录下来，形成团队的问题知识库。

如果你也是运维工程师

可以先从“处理 2 起磁盘告警和 1 起证书过期隐患”或“清理无主的云资源”这样的小任务开始练习 AI 排错，熟练之后再用到变更方案这类更正式的材料上。每次记录一下哪句提示词最管用，慢慢就有了自己的模板。

相关阅读