用 AI 写运维值班手册：实用方法

凌晨两点十七分，告警短信把值班的人叫醒：某台机器磁盘使用率 92%。他知道要处理，但不确定这台机器上跑的是谁的业务、清哪些目录是安全的、清错了要不要叫人。值班最难过的时刻不是故障本身，而是站在故障面前不知道下一步做什么。手册就是为这种时刻写的，而 AI 恰好擅长把散落的经验整理成条目——前提是用对方式。

告警响的时候，缺的往往不是技术

值班手册的价值不在教人修故障，在于把「该找谁、先看什么、什么情况下叫人」固定下来。这三件事平时没人记，出事时最耽误时间。有手册的团队，同类故障的处置时间短一截；没手册的团队，每次都由不同的人从头摸一遍，摸完还不一定留下记录。

写手册真正的难点是「写全」。熟悉系统的人写的时候会自动跳过自己觉得显然的步骤，新人拿到手仍然看不懂；不熟悉的人写，又容易写成教科书。AI 在这个环节的作用是把「显然」逼出来：它不知道你的系统，所以会追问那些你觉得不用问的问题。

五步，从架构描述到能执行的条目

把写手册的过程拆开，实际是五个动作，每个动作有产出物，也有对应的坑：

第三行和第四行是分水岭。排查顺序决定新人能不能独立走完第一步，处置动作决定他敢不敢动手。这两行写得含糊，手册就退化成一份「出了事请找老张」的名单。

每一步都得是动作，不是状态

「确认服务状态」不是动作，「执行 systemctl status 服务名，看到 active (running) 就往下走，看到 failed 就跳到第三节」才是。区别在于后者给了判断条件：看到什么算正常，看到什么算异常，异常往哪走。手册里每一行都该有这三样，缺一样，执行的人就要现场做一次判断，而现场判断正是手册想省掉的东西。

让模型改写时的提示方式很关键。把「帮我优化这段手册」换成「这段话里哪些词是状态描述，请改成可执行动作，并补上判断条件和异常分支」，输出会具体得多，提示词的结构在这里决定了它给你改措辞还是改结构。

升级路径写不清，等于没写

升级这件事有三个要素：条件、对象、方式。条件要写成可观测的，比如「同一告警十分钟内重复三次」「核心接口错误率超过 5%」「涉及资金或用户数据」；对象要写到岗位而不是名字，因为人会调岗；方式要包含备用路径，电话打不通时找谁、群里 @ 谁、多久没响应就升级到上一层。

值班的人最怕的不是不会处理，是不知道该不该叫人。叫早了怕被说大惊小怪，叫晚了怕担责任。手册要把这条线画死：满足哪一条就必须叫，不需要自己权衡。这条写清楚，值班的心理负担会轻很多，处置反而更快。

手册是故障喂出来的

第一版手册一定不全，这很正常。真正让它变有用的是每次故障后的十分钟：把当时怎么发现的、卡在哪一步、哪个命令不对，补进对应条目。这个过程可以让 AI 代劳——把聊天记录和操作日志丢给它，让它整理成「现象、排查、处置、遗留问题」四段，人只负责核对和删改。

积累到几十条之后，手册会开始反向起作用：新故障出现时先在里面搜一遍，多数情况能找到相似条目，照着改两处就能用。到这一步它才真正省时间，之前都只是在还债。

命令、环境与版本，是模型最容易出错的地方

边界很明确：模型不知道你的操作系统版本、不知道你的服务名、不知道你们内部封装过哪些脚本。它给出的命令语法通常对，参数和路径经常不对；更麻烦的是它会给出「看起来很像」的命令，比如把不同发行版的包管理命令混着写，或者用一个早就不推荐的参数。生产环境执行前必须逐条核对，能先在测试机跑一遍就不要直接上。

它也不知道你的监控覆盖了什么。手册里写「查看某指标」，实际你们根本没采集这个指标，这条就等于空话。凡是涉及「看哪里」的步骤，都要对着监控面板核一遍，确认那个面板真的存在、那个指标真的在跳。模型编造细节在命令和配置项上格外难发现，因为它编得很像真的，连报错信息都能一起编出来。

架构图先脱敏，再喂给工具

系统架构、内网地址、账号命名规则、业务量级，这几样拼起来就是一张攻击地图。用公开的在线工具处理这类内容，等于把它们上传到不受你控制的地方。可行做法是先脱敏：组件名换成通用叫法，IP 换成占位符，业务名换成 A、B、C，只保留结构关系。手册定稿后再把真实信息填回去。

需要模型理解内部文档时，更稳的路径是把手册放进自己的知识库做检索，检索增强的做法让回答基于你给的原文，比让它凭记忆补要可靠得多。涉及生产的操作权限仍然要走审批和审计，这一条不能因为「AI 说这么改」而省略。

速查：手册的五条底线

• 每条步骤写清「执行什么、看到什么算正常、异常去哪」
• 升级条件用可观测指标写，不用「感觉严重」
• 命令逐条在测试环境验过再进手册
• 架构与地址先脱敏，再交给外部工具
• 每次故障后十分钟内补条目，别攒到月底