晚上十一点，站点打不开，浏览器转了半天圈，最后甩出一个502。你打开服务器上的错误日志，一屏一屏往上翻，翻到眼睛发涩也没看出个所以然。这时候想起手里还有个AI助手，于是把日志整段选中、复制、粘贴过去，问它：这是什么问题。
多数情况下，你会得到一段正确但没什么用的回答。它把日志里的报错翻译了一遍，复述了几种可能的原因，最后建议你检查一下服务器配置。话没说错，可也没解决任何事。于是有人得出一个结论：AI排查服务器故障不靠谱。这个结论下早了，问题往往出在喂给它的东西上。同一个模型、同一份日志，换个喂法，结果能差出很远。
日志是给按时间线做事的人看的，不是给模型抓重点用的。整段贴过去，上下文里九成是噪音，真正有用的那几行被淹在几千行里。模型不是看不出问题，是它面前的信息太杂，找不着那根线头。位置换了，效果就完全是另一回事。
换个角度想就明白了。你带一个新人上故障现场，不会把服务器丢给他让他自己翻，而是一边看一边告诉他：什么时候开始的、报错原文是什么、这块配置上周改过、环境是哪个版本。让AI帮忙排查，靠的也是这一套。它缺的从来不是聪明，而是现场。
第一类是时间点。故障什么时候开始的，是持续的还是间歇的，有没有规律，比如每天固定时段出现、或者只在某个操作之后出现。这些决定了排查方向：间歇性的多半和并发、资源占用或上游服务有关，持续性的往往是一次配置变更或者服务挂掉的直接结果，两者的查法完全不同。
翻日志的时候，顺手把级别也认一下。以nginx为例，官方文档写得很清楚：error_log默认写到logs/error.log，默认级别是error，意思是从error往上的crit、alert、emerg才会被记下来。如果你连warn级别的线索都想要，得临时把级别调低再复现一次。搞不清这一点，很容易误判成日志里什么都没有，其实是被级别挡在了外面。
第二类是错误原文，而且必须是原封不动的那几行。别自己转述成它报了个502——不同措辞指向完全不同的环节：是上游连接被拒，还是请求超时，还是返回了非法响应头，处理路径差得很远。原文里的每个词都是线索，转述一次就丢掉一点。
第三类是和出错点相关的配置。哪个站点块、上游地址填的是谁、超时设了多少、有没有做重定向。日志说的是结果，配置说的是条件，只看结果不看条件，等于只拿到一半信息。把出错那段server块连同日志一起给AI，它能把两边串起来的可能性会大得多。
第四类是环境加上最近一次变更。系统版本、服务版本、运行时版本，还有最重要的——你最后一次动过什么。经验上，八成故障是最后一次变更引起的，但AI不知道你昨天调过参数、上周换过依赖，你不说，它只能往通用方向猜，猜出来的建议自然泛。
这几类凑齐了，提问方式也可以换个模板。与其问这是什么问题，不如把话说明白：环境是某版本，故障从某时间点开始且间歇出现，日志原文如下，相关配置如下，最近一次变更是改了某个参数，请列出排查步骤，并说明每一步该看什么输出。重点是让它给路径，而不是给结论。
有个坏习惯要改掉：把访问日志整段贴过去。访问日志是按请求一条条记的，几万个请求就是几万行，你要找的那一条藏在里面，人和模型都累。要么先按时间窗和状态码筛出几十行再给，要么干脆不给，只提供错误日志，把范围收窄了再说。
还有一点务必守住：让AI先给排查路径，别让它直接改生产配置。你可以让它列出先查A、再看B、每一步关注什么现象，然后自己照着一步步执行。反过来，把生产环境的改动权直接交出去，出了事没人能替你兜着。改动这件事由人来做决定，AI只当参谋。它给出的命令，先在测试环境跑一遍，确认没问题再考虑往生产上放。
给出去的东西也要先过一遍。日志里可能有真实IP、用户标识、接口路径，配置里可能有密钥和账号。这些在贴给任何外部服务之前都该先替换掉。故障要紧，但把内部信息裸着送出去，代价可能比故障本身还大，事后想收都收不回来。脱敏这事花不了两分钟，省下的麻烦却可能很大。
最后说个习惯，和AI关系不大但特别值：故障发生的那一刻，就把这几类信息抄进一个文件，时间、原文、配置、变更各占一块。哪怕最后没用上AI，写复盘、开工单、给同事交接都用得上。等事后再回忆当时报了什么，十有八九记不全，白丢一次经验。
所以下次服务器出问题，别急着把日志一贴了事。按顺序做四件事：记下故障时间线，截下错误原文，找出相关配置，确认最近变更。这四样摆齐了再交给AI，它才能从一个什么都能聊两句的助手，变成真能帮你缩小范围的帮手。至于提示词写得漂不漂亮，那是在这之后才轮得到考虑的事。
A5创业网 版权所有