华为VRP专属提示词、安全规则注入、Windows方言规则库· 一套Agent三种大脑方言按设备类型自动切换提示词· 全部规则来自真实交付的提示词与规则库非理论设计· 连提示词本身也要写测试14项验证用例的做法目 录第一章 提示词是 Agent 的运维 SOP第二章 分流架构一台设备一套方言2.1 为什么不能共用一份提示词2.2 分流的边界工具层还是提示词层第三章 华为VRP给AI补一门方言课3.1 VRP 与 Linux 的三个世界观差异3.2 方言速查表十行解决高频错误3.3 一条规则一条血泪第四章 Windows方言规则库二十四条防线4.1 提示词引导 代码拦截的双层设计4.2 一条规则长什么样第五章 安全规则注入把红线写进每一轮5.1 三级风险标注5.2 确认链路的完整性5.3 规则的失效模式第六章 提示词也要写测试6.1 一个反直觉的实践6.2 五条提示词设计铁律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_code1 仅代表回显含报错特征。管道语法不同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」变成「敢交出去的工具」。 
长河君 · 2026/10/21 11:39:23 · 阅读 1.2k 彭大帅的AI运维助手——怎么给AI写运维SOP：提示词设计实战
华为VRP专属提示词、安全规则注入、Windows方言规则库· 一套Agent三种大脑方言按设备类型自动切换提示词· 全部规则来自真实交付的提示词与规则库非理论设计· 连提示词本身也要写测试14项验证用例的做法目 录第一章 提示词是 Agent 的运维 SOP第二章 分流架构一台设备一套方言2.1 为什么不能共用一份提示词2.2 分流的边界工具层还是提示词层第三章 华为VRP给AI补一门方言课3.1 VRP 与 Linux 的三个世界观差异3.2 方言速查表十行解决高频错误3.3 一条规则一条血泪第四章 Windows方言规则库二十四条防线4.1 提示词引导 代码拦截的双层设计4.2 一条规则长什么样第五章 安全规则注入把红线写进每一轮5.1 三级风险标注5.2 确认链路的完整性5.3 规则的失效模式第六章 提示词也要写测试6.1 一个反直觉的实践6.2 五条提示词设计铁律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_code1 仅代表回显含报错特征。管道语法不同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」变成「敢交出去的工具」。