夜雨聆风做 IT 的人用 AI，最容易踩的坑，不是 AI 明显答错。
而是：它答得特别像真的。
命令有了，参数有了，原因分析也有了，甚至还会一本正经地告诉你“这是最佳实践”。
问题是——
它可能是错的。
这就是我们经常说的 AI“幻觉”。
对于普通聊天来说，答错一个知识点可能影响不大。
但在 IT 运维和信息安全领域，如果 AI 编造了一条不存在的命令、一个错误的参数，或者一个看起来合理但实际上并不适用于当前环境的方案，你直接执行，后果就完全不一样了。
所以，学会用 AI 之后，下一步一定要学会：
验证 AI。
一、AI最危险的错误，是“逻辑很通顺”
很多人判断 AI 对不对，靠的是一种感觉：
“它解释得挺有道理。”
但这其实并不可靠。
AI 很擅长生成逻辑完整、语言专业的答案。
例如，你问：
某个 Windows 服务异常应该怎么处理？
它可能会告诉你：
停止服务；
删除缓存目录；
修改注册表；
重启服务。
看上去步骤很完整。
但真正需要确认的是：
这个服务名真的存在吗？
这个注册表路径对不对？
这个参数是不是这个 Windows 版本支持的？
删除这个目录会不会导致其他问题？
所以判断 AI 答案时，不要先看“像不像专家”。
而要看：
它有没有证据。
二、我判断AI答案，通常先看四件事
1. 它说的是“事实”，还是“推测”？
这是非常重要的一点。
比如 AI 说：
“这个问题通常是 DNS 导致的。”
这只是一个假设。
但如果它说：
“因为你能 ping 通网关，所以可以确定 DNS 有问题。”
这就值得警惕了。
因为“能 ping 通网关”最多说明本地到网关这一段网络大概率是通的，并不能直接证明 DNS 有问题。
所以我经常会追问 AI：
请把你的回答分成三类：
已知事实
基于现有信息的推测
还需要验证的内容
不要把推测描述成确定结论。
这个 Prompt 非常好用。
它可以强迫 AI 把“我知道什么”和“我猜什么”分开。
2. 它有没有跳过验证步骤？
一个靠谱的排障方案，通常不会直接从：
现象 → 结论
中间应该有：
假设 → 验证 → 证据 → 结论
例如：
用户打不开网页。
AI 如果直接说：
“重置 TCP/IP 协议栈。”
你就应该问：
为什么？
正确的思路应该先验证：
IP 地址是否正常；
DNS 是否正常；
默认网关是否可达；
代理是否异常；
VPN 是否改变了路由；
浏览器是否存在单独问题。
所以你可以对 ChatGPT、Claude 或其他 AI 这样说：
不要直接给修复方案。
对每一个可能原因，请先设计一个不修改系统的验证方法。
只有验证结果支持这个假设时，再给出修复建议。
这句话非常适合 IT 运维场景。
因为它会把 AI 从“答案生成器”变成“排障助手”。
3. 它给出的命令，能不能被独立验证？
看到陌生命令，不要只问 AI：
“这个命令对吗？”
因为它很可能继续告诉你：
“对，这是安全的。”
更好的方法是：
把命令拆开验证。
例如看到一条 PowerShell 命令，可以继续问：
请逐个解释这条命令中的 Cmdlet、参数、变量和管道分别做什么。
哪些部分你不能确定，请明确告诉我，不要猜。
然后你还可以做第二层检查：
把同一条命令交给另一个 AI。
比如：
ChatGPT 生成，Claude 审核；
或者：
Claude 给方案，Gemini 找错误。
Prompt 可以直接写：
下面是一段其他 AI 生成的 PowerShell。
请不要默认它是正确的。
重点检查：
是否存在不存在的 Cmdlet 或参数；
是否有版本兼容问题；
是否可能修改或删除不应该修改的数据；
是否存在更安全的只读验证方法。
这就是一种非常实用的：
AI交叉验证。
三、让AI主动“反驳自己”
这是我很喜欢的一个 AI 使用技巧。
当 AI 给出一个结论后，不要马上接受。
继续问：
假设你刚才的判断是错误的，最可能错在哪里？
或者：
请站在一名高级系统工程师的角度，反驳你刚才的结论，列出至少3个其他可能原因。
你会发现一个很有意思的现象：
AI 经常可以自己发现刚才回答中的漏洞。
这叫做一种简单的：
自我批判式提问。
例如 AI 判断：
“大概率是 DNS。”
你可以继续要求：
请提出三个“不是 DNS”的解释，并告诉我怎么验证。
这会大幅减少你被第一答案带偏的概率。
对于新手尤其重要。
因为经验不足时，我们很容易看到第一个“像答案的答案”，就停止思考。
四、遇到这几种情况，要特别警惕
如果 AI 的回答出现下面这些特征，我通常都会多验证一次。
第一，非常确定，但没有证据。
比如：
“100% 是驱动问题。”
技术排障里，过度确定往往不是好信号。
第二，给出了你从没见过的命令或参数。
不要因为它长得像 PowerShell，就默认它真的是 PowerShell。
第三，没有问环境。
Windows 10、Windows 11、Server 2019、Server 2022，环境不同，方案可能完全不同。
Linux 也是一样。
Ubuntu、RHEL、Debian、不同 systemd 版本，命令和配置方式都可能不同。
第四，一上来就让你做高风险操作。
比如：
重置、删除、强制结束、修改注册表、关闭防火墙、禁用安全软件。
这种答案至少说明：
AI没有优先考虑风险控制。
五、把AI变成“验证助手”，而不是“权威答案”
以后你可以养成一个习惯。
不要只问：
“答案是什么？”
而是多问：
“你有什么证据？”
“这个结论还有哪些替代解释？”
“我怎么验证？”
“如果你错了，最可能错在哪里？”
“哪些部分需要查官方文档确认？”
这几个问题看起来简单，但非常有价值。
因为 AI 真正适合做的，不只是提供答案。
它还可以帮助你：
生成假设、寻找反例、设计测试、解释日志、审查命令、复盘思路。
这些能力，对于桌面运维、系统运维、网络、安全，甚至项目管理，都一样重要。
一个我经常使用的AI验证Prompt
以后遇到陌生技术答案，可以直接复制下面这段：
你是一名谨慎的企业IT高级工程师。
请审查你刚才的答案，不要默认它是正确的。
把内容分成：
可以确认的事实；
基于现有信息的推测；
需要进一步验证的内容；
可能错误或存在风险的部分。
对每一个结论，请给出验证方法。
如果涉及命令、参数、注册表、服务、权限或系统配置，请明确指出哪些内容需要通过官方文档或测试环境再次确认。
最后，请告诉我：如果你的判断错了，最可能错在哪里。
这类 Prompt 的价值，不是让 AI “永远不犯错”。
而是让它的错误：
更容易被你发现。
写在最后
AI 时代，IT 工程师真正需要培养的，不是“相信 AI”的能力。
也不是“拒绝 AI”的能力。
而是：验证 AI 的能力。
真正专业的人，不会因为 AI 说得像专家，就直接相信。
他会继续问：
依据是什么？
怎么证明？
还有没有其他可能？
如果错了，会造成什么后果？
未来真正有竞争力的 IT 工程师，可能不是知道答案最多的人。
而是面对 AI 给出的答案时，依然保持：
证据意识、验证意识和风险意识。
下一篇我们继续聊：
怎么用 AI 帮你分析日志和报错，而不是只把错误代码复制给 AI。