大模型在故障排查中的表现，很大程度取决于你是否把网络环境、设备角色和证据链完整地交给它。它没有实时拓扑感知，也不会主动登录设备采集状态，因此提示词就是它唯一的信息入口。与其问“网络断了怎么办”，不如把模型当作一名需要完整病历的工程师，把拓扑、现象、时间和已做过的操作一并说明。这样模型给出的建议才不会停留在“检查网线、重启路由、查看DNS”这类通用列表上。
一、为什么泛泛的提问无法定位网络故障
网络排障本身是一个逐步缩小范围的过程，但大模型并不具备实时感知能力。你只说一句“网络很卡”，它只能根据训练数据中的常见原因给出建议，比如带宽打满、DNS解析慢、无线干扰或MTU异常。这些答案单独看都没有错，但如果不结合具体拓扑和现象，几乎无法落到可执行的验证动作上。
更麻烦的是，网络故障往往不是单点问题。一个TCP连接间歇性重置，可能涉及接入交换机端口错误、防火墙会话表满载、负载均衡健康检查失败，甚至服务器内核参数不当。只有把已知的接口统计、抓包结果、路由表项、设备日志等证据一并放进提示词，模型才可能把这些信息关联起来，而不是凭空猜测。
下面是一个反例和正例的对比。可以看到，后者把角色、拓扑、现象和证据都写清楚后，模型输出的针对性会明显增强。
反例： 网络很卡，帮我看看怎么回事。 正例： 角色：你是一名有10年企业网络排障经验的工程师。 拓扑：核心交换机SW-Core(10.0.1.1)通过聚合链路连接接入交换机SW-Acc(10.0.1.2)，终端网段为192.168.10.0/24。 现象：该网段内约30台终端间歇性丢包，平均丢包率8%，Ping网关时延从2ms波动到600ms。 已知证据： 1. SW-Acc上联聚合口CRC错误计数持续增长； 2. 核心侧对应端口无错误计数； 3. 终端ARP表项正常，网关MAC与SW-Core一致。 请按“最可能原因 -> 需要补充的命令 -> 验证步骤”格式输出，不要直接建议重启设备。
这个正例的核心并不是词数更多，而是它把网络工程师脑中的隐性判断过程显性化了。模型需要知道你已经排除了哪些可能、当前最可疑的方向在哪里。这样它才不会把时间浪费在重复建议上，而是直接沿着链路层误码这个方向继续深挖。
二、分步排查Prompt的设计方法
网络排障适合分层推进，从物理层、数据链路层、网络层、传输层到应用层。与其让模型一次性给出结论，不如在提示词中要求它按层级逐步排除。每一步都说明依据、列出验证命令，并解释该命令的结果如何帮助缩小范围。这样做的好处是过程透明，人也能随时判断模型是否跑偏。
下面是一个面向TCP连接间歇性重置问题的分步排查提示词模板。它没有让模型直接跳到“重启防火墙”或“重连专线”这类结论，而是要求模型先定位层级，再给出证据链。
请按照以下步骤排查一条从客户端到服务器的TCP连接间歇性重置问题。 背景： 客户端地址为172.16.5.20，应用通过HTTPS访问10.20.0.15的443端口。 路径：客户端 -> 接入交换机 -> 核心交换机 -> 防火墙 -> 负载均衡 -> 服务器。 已确认现象：连接在业务高峰期每小时重置15到20次，非高峰期正常。 任务： 1. 先判断最可能出错的层级，并解释理由。 2. 为每一层列出至少两条可执行的设备命令或抓包过滤条件。 3. 说明每条命令的结果如何帮助你缩小范围。 4. 最后给出一个不超过5步的验证闭环。 约束： - 不要直接给出最终修复动作。 - 不要建议对生产设备执行重启、清空计数或热切换等高影响操作。 - 如果证据不足，明确列出还缺哪一项证据。
这个模板的价值在于，它把“排查动作”和“修复动作”分开。大模型在缺少现场信息时，很容易把合理的诊断建议替换成激进的变更建议。通过在约束中明确禁止高影响操作，可以避免模型输出一个看似合理但风险极高的处理方案。
实际使用中，如果模型跳过了某个层级或者给出的命令与当前厂商不符，可以继续追问：“请补充数据链路层可能的原因，并给出Cisco IOS-XE环境下的对应命令”。这种分步交互往往比一次性生成完整报告更可靠。
三、用约束和证据链降低模型幻觉
大模型在信息不足时容易生成不存在的命令，或者把不同厂商的语法混在一起。例如把华为VRP的命令安到Cisco设备上，或者凭空编造一个并不存在的监控OID。因此，提示词中应当明确设备厂商、型号和软件版本，并要求模型在不确定时标注“不确定”。
一个很实用的做法是要求模型把每条结论都绑定证据。下面这个提示词片段要求模型以JSON格式输出，并且区分支持当前判断的证据、反对当前判断的证据以及仍然缺失的证据。
请以JSON格式输出你的分析结果，不要包含Markdown代码块标记。
{
"most_likely_cause": "上联光纤模块光衰过大",
"evidence_for": ["聚合口CRC错误持续增长", "两端端口状态UP但误码率高"],
"evidence_against": ["核心侧端口无错误计数", "业务非高峰期正常"],
"confidence": "中",
"missing_evidence": ["光模块收发光功率值", "更换备用光纤后的误码变化"],
"next_verification": [
"在接入侧执行 show interface transceiver detail 记录光功率",
"在核心侧查看对应端口 FEC 统计",
"临时切换至备用链路观察10分钟"
]
}
这种输出方式强迫模型把推理过程拆开，而不是只给一句“可能是光模块坏了”。人工复核时，只要看“证据支持”和“证据反对”是否与已知现象一致，就能快速判断模型有没有把事实和猜测混在一起。即使模型最终判断错误，缺失证据那一栏也能帮助你决定下一步先补哪项数据。
还可以在提示词末尾加上一条：“如果某条命令在你的知识范围内并不存在，请明确标注不确定，不要尝试创造命令”。网络设备命令体系庞杂，加这样一句约束，能进一步减少一本正经地生成错误命令的情况。
四、复杂网络故障提示词模板与使用技巧
跨地域专线质量劣化、多厂商混合组网这类问题，涉及的信息更多，适合使用完整模板。粘贴日志之前最好先做脱敏，去掉密码、公网IP、内部域名等敏感内容。日志也不建议整段粘贴，可以按时间段、设备、接口归类后，把异常计数的变化趋势写进提示词。
下面是一个可以直接套用的综合模板，适用于分支机构和总部之间通过双专线互联的场景。
角色：你是企业网络排障专家，熟悉Cisco IOS-XE、华为VRP和FortiGate防火墙命令。 背景： 分支机构和总部之间通过两条专线互联，一条为主用MPLS VPN，一条为备用互联网IPsec VPN。 当前业务从分支机构访问总部ERP系统时，响应明显变慢，页面加载时间从2秒增加到15秒。 拓扑与地址： 分支核心CR-Branch：10.100.0.1 总部核心CR-HQ：10.200.0.1 防火墙FW-HQ：10.200.0.254 ERP服务器：172.30.10.20 已知现象： 1. 从分支Ping总部防火墙延迟稳定在35ms，无丢包； 2. 从分支Ping ERP服务器延迟正常，但TCP三次握手时间偶尔超过3秒； 3. FW-HQ会话表使用率在高峰期达到92%； 4. ERP服务器CPU和内存使用率均低于40%； 5. 抓包显示分支发送SYN后，约2秒后才收到SYN-ACK，且偶尔出现重传。 请完成以下分析： 1. 按概率从高到低列出三个可能原因。 2. 每个原因必须关联上述已知现象编号。 3. 给出每个原因对应的验证命令，并注明在哪台设备执行。 4. 对每个原因给出风险最低的临时处置方案，不能包含重启设备或清空会话表。 5. 输出格式为：可能原因、关联证据、验证命令、临时处置。
使用这类模板时，可以把已知现象编号，这样模型在解释原因时必须引用编号，避免泛泛而谈。比如它如果判断是防火墙会话表瓶颈，就必须指出这与现象3和现象5的关联，而不是只说“可能是防火墙性能问题”。
另外，如果一次排查涉及大量日志，可以分多轮输入。先把拓扑和现象交给模型，让它列出还缺哪些证据；再根据它列的清单去设备上采集命令输出，最后把新增证据回填到提示词中。这样比一次性把所有日志都塞进去更容易得到准确判断。
五、常见误区与提升Prompt效果的实用建议
第一个常见误区是把大模型当作自动修复工具，让它直接输出配置修改命令。网络排障的边界感很重要，提示词中应当写明“只做分析，不直接修改配置，不生成完整配置变更脚本”。尤其在涉及防火墙、核心交换机等生产设备时，错误的一条命令可能造成业务中断。
第二个误区是一次提供过多原始日志而不做摘要。大模型对长文本的注意力有限，如果日志中有大量无关的重复信息，它可能忽略最关键的异常计数变化。更合适的做法是先人工提取每个接口的丢包、错误、光功率、会话表使用率等关键指标，再写入提示词。
第三个误区是每次排障都从零开始写提示词。网络环境虽然会变化，但排障的分析框架是稳定的。可以把“角色、拓扑、现象、证据、输出格式、约束条件”作为固定模板保存下来，每次只替换其中的变量部分。这样既能保证提示词质量稳定，也能沉淀出一个适合自己网络的排障提示词库。
最终，大模型在故障排查中能发挥多大作用，取决于你给它提供了多少可验证的上下文，以及你是否在提示词中建立了严格的证据链约束。把这些做好，它就能从一个只会给通用建议的聊天工具，变成一个真正能陪你一步步定位问题的排障助手。
