把排查任务交给 AI：让它自己查缓存、查数据库、查日志、看代码
上篇文章说到，我最近用 stdio 的本地 mcp 方式实现了各种基建与 AI 之间的连接，例如查数据库、调接口等等。
这篇文章分享一下出现问题(如接口报错等)时让 AI 直接来排查原因的实践。我可以很明确地说，现在 AI 的能力已经非常强大，这条路是完全走得通的，而且效果很好，超出预期。
出现的问题
线上遇到了一个问题，很快定位到一个缓存的内容与数据库存在不一致。
这个问题并非必现，甚至出现概率非常小。但因为在测试这里三天就出现了两次，因此有必要排查清楚并修复。
接下来其实是有比较清晰的排查思路的：
- 哪里的删缓存时机有问题？
- 有没有并发问题？
- 有没有读写竞争？
- 主从数据库延迟？
但是这种偶现的问题查起来还是比较费时，而且我们是微服务架构，这块逻辑也稍微有点复杂。
人工是怎么排查问题的
一个线上问题出现时，标准的排查链路大概是这样的：
- 收到告警或者用户反馈，知道某个接口报错了或者某个功能表现异常
- 先复现一下，拿到错误码和请求参数
- 去查日志，按 traceId 拉出一长串日志，一行行看
- 怀疑是数据问题，去查数据库，拼 SQL，对数据
- 怀疑是缓存问题，连上 Redis 看 key 的值，比对 TTL
- 去代码里找相关逻辑，看有没有特殊分支、有没有条件遗漏
- 把所有线索拼起来，得出一个推测，再验证
现在我相当于已经完成了第1步，但后面的步骤非常费时。
同样的排查路径，一个复杂问题可能要在五个不同的系统之间来回切换，翻几十个日志记录，读几十段代码。最后定位到根因时，往往发现真正的原因并不复杂，但找到它的路径很长。
为什么让 AI 自己排查是自然的方向
仔细想一下，上面这个排查过程中，人做的绝大部分工作本质上是信息收集和关联：
- 日志里有没有某条报错？
- 数据库里这条记录的状态对不对？
- 缓存里这个 key 的值是什么时候写入的？
- 这段代码在什么条件下会走哪个分支？
这些问题的共同点是：需要知道去哪里找信息，以及找到之后如何拼起来。
而今天的 AI 在这两件事上都已经足够强了：
- 它能准确判断要查什么、从哪里查
- 它拿到数据后能迅速理解含义、发现异常、建立关联
- 它不会疲劳，不会漏看，不会被海量日志淹没
所以一个自然而然的想法就出现了：与其人逐层去查再喂给 AI 分析，为什么不直接让 AI 自己去查？
具体怎么做
非常简单：给 AI 一系列能力，让它像我人工操作一样自主排查。
把现象交给 AI
我直接描述问题：
“我遇到了xxx的问题，C端现象是xxx，我目前初步排查到xxx缓存与数据库内容不一致，你可以看一下日志和代码，帮我查一下是什么原因导致的。相关信息：xxx”
剩下的，AI 自己去完成。
AI 会做什么
AI 接收我的问题后，开始搜索代码，查找相关服务名，然后查找了我给出的缓存内容，搜索了数据库中的数据，还根据我提供的信息自主搜索了日志。
期间，它又与我进行了多轮对话，问了我一些业务信息，我也继续向它提出一些我的猜测。
最后 AI 多次读代码，看具体逻辑在哪个环节出现了偏差，给出了代码级别的分析，并给出了多套解决方案。
整个过程其实和我人工的排查路径是一样的，包括我中途提出一些新的猜测告诉 AI，AI 尝试根据日志和代码验证猜测，如果是我人工做的话也是一样的。但 AI 不需要在数个系统之间手动切换，它每一步都在迅速地调用工具、获取信息、更新判断。
我只需要等它给出结果。
人在这个过程中做什么
如此，人做的事情被压缩到了三个：
- 描述问题。 告诉 AI 现象是什么，或者把报错信息给它。
- 确认结论。 AI 排查完了会告诉我根因是什么、影响了什么、建议怎么处理。我需要做的是审核判断。
- 必要时介入。 如果 AI 遇到了需要人工授权的操作（比如修改数据、发布代码），我要来审批和执行。(在本文的例子中没有遇到)
但最耗时的排查过程本身，AI 已经替我走完了。
实际体验如何
效果比我预期的好不少。
速度上，AI 查日志和查数据库的速度远超人工。人拉一个日志要选时间范围、输过滤条件、一页页翻，AI 调用工具拿到的就是过滤好的数据。多条线索可以并行查，不需要排队等。
准确性上，AI 不会因为疲劳而漏掉关键信息。现在 AI 的上下文长度非常宽裕，它不会因为日志太多就跳过某个看起来"应该没问题"的片段。每一条线索它都会过，而且能把日志、数据、缓存、代码四方面的信息放在一起交叉验证。
最让我印象深刻的一点是，AI 的排查路径并不死板。它会像有经验的工程师一样做有方向的推理——根据上一步的发现来决定下一步查什么，而不是机械地按固定流程把所有东西查一遍。
这种灵活度，是我之前有些高估的难度，而现实比我想象的更好。重要的是，我并没有安装或者自己编写任何相关的 skill，只是提供了查询各种基建的方式(mcp)，完全靠它的基础能力就能够做到这种程度。如果做一些 skill 上的优化，效果应该会更好。
一些注意事项
这条路已经验证了非常可行，但是有一些也许要注意的事项。
信息接口需要可用。 AI 要能查到日志、连上数据库、看到缓存、读到代码仓库。这不是说给它一个生产数据库的 root 权限，而是需要提供封装好的查询接口或只读权限。
权限控制要做好。 AI 的能力边界要清楚——它能查什么、不能改什么、哪些操作需要人审批，这些是工程前提。
复杂问题仍然需要人把关。 对于一些涉及多个系统联动的深层架构问题，AI 给出的结论需要人来理解、审核和最终决策。但即便如此，AI 已经把排查的工作量从"几个小时的手动排查"压缩到了"几分钟的自动分析加几分钟的人工确认"。
写在最后
我想表达的核心观点其实很简单：
现在的 AI 已经有能力独立承担相当一部分排查工作。
你不需要把问题拆碎了喂给它，不需要一步步告诉它先查什么后查什么。你只需要把现象描述清楚，或者把接口结果甩给它，然后等它给你结论。
这条路是走得通的，而且效果很好。像我上一篇文章说的：
AI 解放了一部分“不得不使用的人类智能”
很多团队还在用人工排查的老流程，不是因为流程本身更好，而是还没有真正尝试过把这件事交给 AI。
如果你还没试过，建议认真考虑一下。在当下，我认为一定要：
- 对 AI 祛魅：不要觉得所谓“平台化”、“工程化”才是好的方案，土用法有土用法的优势，更何况，“平台化”不过是“土用法”套了个平台壳，仅此而已。
- 相信 AI 的能力：在很多事情上，相信 AI 的能力吧，现在的 AI 真的已经足够强了，日常工作中多试几次，多让 AI 干点活。