彭大帅的AI运维助手——怎么给AI写运维SOP：提示词设计实战

华为VRP专属提示词、安全规则注入、Windows方言规则库

· 一套Agent三种大脑方言，按设备类型自动切换提示词

· 全部规则来自真实交付的提示词与规则库，非理论设计

· 连提示词本身也要写测试：14项验证用例的做法

目 录

[第一章 提示词是 Agent 的运维 SOP](#第一章 提示词是 Agent 的运维 SOP)

[第二章 分流架构：一台设备一套方言](#第二章 分流架构：一台设备一套方言)

[2.1 为什么不能共用一份提示词](#2.1 为什么不能共用一份提示词)

[2.2 分流的边界：工具层还是提示词层](#2.2 分流的边界：工具层还是提示词层)

[第三章 华为VRP：给AI补一门方言课](#第三章 华为VRP：给AI补一门方言课)

[3.1 VRP 与 Linux 的三个世界观差异](#3.1 VRP 与 Linux 的三个世界观差异)

[3.2 方言速查表：十行解决高频错误](#3.2 方言速查表：十行解决高频错误)

[3.3 一条规则一条血泪](#3.3 一条规则一条血泪)

[第四章 Windows方言规则库：二十四条防线](#第四章 Windows方言规则库：二十四条防线)

[4.1 提示词引导 + 代码拦截的双层设计](#4.1 提示词引导 + 代码拦截的双层设计)

[4.2 一条规则长什么样](#4.2 一条规则长什么样)

[第五章 安全规则注入：把红线写进每一轮](#第五章 安全规则注入：把红线写进每一轮)

[5.1 三级风险标注](#5.1 三级风险标注)

[5.2 确认链路的完整性](#5.2 确认链路的完整性)

[5.3 规则的失效模式](#5.3 规则的失效模式)

[第六章 提示词也要写测试](#第六章 提示词也要写测试)

[6.1 一个反直觉的实践](#6.1 一个反直觉的实践)

[6.2 五条提示词设计铁律](#6.2 五条提示词设计铁律)

[6.3 写在最后](#6.3 写在最后)

第一章 提示词是 Agent 的运维 SOP

每个运维团队都有 SOP：哪些命令能敲、哪些要工单、哪家厂商的设备语法特殊、出事先看什么。传统 SOP 的问题是人记不住、执行走样。而 AI 运维 Agent 的系统提示词，本质上就是把 SOP 写给一个「执行力超强但经验为零」的新员工------它 100% 执行你写的规则，也 100% 执行你写的疏漏。

这个视角带来三个直接推论：提示词不是「调优技巧」，是正式的运维资产，要有版本管理和测试；提示词的措辞精度要求和工作手册一样高，模糊表述会被字面执行；SOP 怎么写，提示词就该怎么写。

AI 运维助手项目里，提示词设计经历了从「一份通用提示词打天下」到「按设备类型三分流」的演进。目前有三套专属系统提示词（Linux、Windows、华为 VRP）加一个共享的安全规则注入层，这套结构的得与失就是本文的内容。

第二章 分流架构：一台设备一套方言

2.1 为什么不能共用一份提示词

项目最早只有 Linux 一种目标，提示词里全是 bash 世界观。接入 Windows 和华为交换机后立刻出现荒诞现象：让 AI 去查 Windows 服务，它写出了 systemctl；让它在华为交换机上过滤回显，它写出了 grep。模型没有错，它只是不知道自己连的是谁。

答案是让提示词跟着设备类型走：切换主机时，Agent 按目标的 device_type 选择对应模板（linux / windows / huawei_vrp），把设备方言、能力边界、安全约束一次注入。用户无感，但模型眼中的世界完全不同。

提示词选路（简化）

def _pick_prompt(device_type):

if device_type == "huawei_vrp":

return SYSTEM_PROMPT_NETDEV # 华为VRP专属

if device_type == "windows":

return SYSTEM_PROMPT_WINDOWS # PowerShell方言

return SYSTEM_PROMPT_LINUX # 默认bash世界观

2.2 分流的边界：工具层还是提示词层

有个问题值得单独说：方言差异到底靠提示词解决，还是靠工具层解决？项目的选择是「双管齐下、各管一半」：语法差异（PS 没有、VRP 用 include 不用 grep）靠提示词教模型；执行差异（编码前导、包装方式）靠工具层硬编码。判断标准很简单------模型能理解并遵守的进提示词，模型无法感知的进代码。把该代码做的事塞进提示词，等于把命运交给模型的自觉。

第三章 华为VRP：给AI补一门方言课

3.1 VRP 与 Linux 的三个世界观差异

华为 VRP 对 AI 来说是一门全新方言，差异不是「命令不同」，而是认知框架不同。专属提示词集中处理三件事：

• 没有退出码：bash 世界里 exit 0 就是成功，但 Telnet 通道里的 VRP 根本没有退出码概念，回显里出现 Error: 或 Unrecognized command 才是失败。提示词必须明确告诉模型：成败只能读回显文本判断，收到 exit_code=1 仅代表回显含报错特征。
• 管道语法不同：Linux 的 grep/awk 全部失效，过滤要用 VRP 自带的 include、exclude、section。这是一条高频错误，模型写惯了 bash 会下意识用 grep。
• 视图体系：VRP 是「进视图改配置」的世界，system-view、接口视图层层嵌套。项目的设计是配置下发由 net_config 工具托管视图进出，提示词里明令禁止模型手动发视图切换命令------把易错的状态机交给代码，模型只声明「我要改什么」。

3.2 方言速查表：十行解决高频错误

专属提示词的核心是一张 VRP 与 bash 的对照速查表（节选整理，实际随版本迭代）：

VRP 方言速查（与 Linux 对照）：

• 看接口状态: display ip interface brief （类比 ip addr）

• 看路由表: display ip routing-table （类比 ip route）

• 回显过滤: display xx | include 关键词 （不是 grep！）

• 看配置: display current-configuration

• 保存配置: save（需人工确认，持久化动作）

• 禁用: vi/top/ps/grep/systemctl 等一切 bash 命令

为什么用「对照表」而不是长篇描述？因为模型对「类比已有知识」的遵循度远高于「记忆新条目」。每条对照都点明了模型最可能犯的错（括号里那句「不是 grep！」是实测加上的------光列正错对照还不够，必须点名禁止项）。

3.3 一条规则一条血泪

速查表里「连接后华为设备不主动发数据，需先发回车拉提示符」这类细节，来自真机调试：AI 第一次连上设备后静默等待，看起来像卡死，实际是 VRP 不像 Linux 登录后主动回显横幅。这类「设备性格」只有踩过才知道，而每一条踩过的都进了提示词------这就是「提示词是运维资产」的含义：它是团队经验的容器，人员会走，提示词留下。

第四章 Windows方言规则库：二十四条防线

4.1 提示词引导 + 代码拦截的双层设计

Windows 支持的方言处理比 VRP 更麻烦：PowerShell 语法复杂，且别名体系（rm、del、ri、erase 都是 Remove-Item 的别名）会让黑名单轻易被绕过。项目采用双层设计：

• 提示词层：注入 PowerShell 速查表（查服务用 Get-Service、查硬件用 Get-CimInstance、环境变量用 env: 前缀），并明确「PS 5.1 没有 && 链接符」「先读后写」「不改安全基线」。这层解决「让 AI 说对方言」。
• 规则库层：二十四条双方言危险命令规则硬编码在安全模块里，覆盖递归强删（含全部别名与任意前缀缩写）、格式化磁盘、注册表 HKLM 删除、清安全日志、改执行策略、删磁盘阴影副本等。这层解决「就算 AI 被诱导也出不了手」。

为什么别名也要列全？因为曾实测模型在确认被拒后，换用别名或缩写重试的路径------安全规则必须假设模型（或诱导它的输入）会变着花样绕。同理，多行脚本上线时补了「三遍检测」：原文、按分句归一、按跨行参数归一各查一遍，堵住「把危险命令拆散在多行里绕过单行检测」的口子。

4.2 一条规则长什么样

危险规则（示意）：递归强删覆盖全部别名与缩写

Remove-Item 系： rm / del / ri / erase + 递归或强制参数

rd / del 的 /s 递归开关

格式化与磁盘： format / diskpart / Clear-Disk

系统级： Stop-Computer / shutdown / bcdedit

注册表删除： reg delete + HKLM/HKU 路径

每条规则都是「确认制」而非「拒绝制」：命中后不直接丢弃，而是弹给人工确认，人点头才放行。这符合运维实际------删除操作有时就是需要做的，只是不能让 AI 擅自做。

第五章 安全规则注入：把红线写进每一轮

5.1 三级风险标注

除了拦截型规则，项目还给每条命令结果附加了三级风险标注（只读 / 需确认 / 常规），随工具结果注入给模型。作用是让模型在规划下一步时自带风险意识：对刚执行过的变更命令，模型会主动建议验证与回滚路径；对只读探测则放心批量执行。

这里的保守设计值得借鉴：只读判定仅限「无管道、无分句、无重定向、无命令替换」的单条命令；多行脚本一律不判只读。看似过严，实际是正确的------多行脚本里藏一个写操作的概率不低，宁可让模型多想一秒。

5.2 确认链路的完整性

安全规则只在 CLI 里生效是不够的。项目把确认链路打通到所有入口：CLI 终端里是命令行确认，Web 图形界面里是弹窗确认，VRP 设备的配置下发同样走 SafetyGate 注入。经验教训来自一次实测：Web 端的高危应答路径漏了某个分支，功能声明生效实际不生效------安全链路必须用测试穷举所有入口，一条都不能靠「应该没问题」。

5.3 规则的失效模式

规则库自身的健壮性也有讲究：内置规则在启动时编译，编译失败直接暴露报错而不是静默跳过------宁可程序起不来，不能让安全规则悄悄失效。这是安全代码和普通代码最大的区别：普通模块故障可以降级，安全模块故障必须响亮地坏。

第六章 提示词也要写测试

6.1 一个反直觉的实践

提示词是文本，怎么写测试？项目的做法是：测「分发正确性」而不是「生成质量」。也就是验证给定 device_type 时选中的模板对不对、模板里的关键约束句还在不在、切主机时模板是否正确切换。这类用例写了 14 项，跑在普通回归里。

生成质量（模型是否真的遵守速查表）确实无法离线断言，但可以用真机冒烟覆盖关键路径：连上 eNSP 模拟交换机执行巡检、发一条配置、试一条 format 看是否被硬拒绝。每轮大版本迭代跑一轮，比空谈「提示词调优」实在得多。

6.2 五条提示词设计铁律

|--------------------|----------------------------------------|
| 铁律 | 说明与出处 |
| 方言对照优于长文 | 模型对类比已有知识的遵循度远高于记忆新条目；速查表十行解决高频错误（第三章） |
| 否定式规则要点名 | 光列正错对照不够，必须明写「不是 grep」「禁止手动视图切换」（第三章） |
| 模型能懂的上提示词，模型不懂的下代码 | 语法差异教给模型；编码、包装、状态机硬编码（第二章） |
| 安全规则假设被绕过 | 别名全列、多行三遍检测、编译失败响亮报错（第四章） |
| 提示词是资产要测试化 | 分发正确性离线断言 + 真机冒烟覆盖关键路径（第六章） |

6.3 写在最后

「怎么给 AI 写运维 SOP」这个问题，答案不是某个神奇的提示词模板，而是把提示词当正式工程对象来对待：按设备方言分流、经验逐条沉淀、红线双层注入、改动过测试。当你的提示词库开始像一本持续维护的运维手册时，你的 Agent 才真正从「能跑的 demo」变成「敢交出去的工具」。