后端工程师的日常往往伴随着一种难以言说的痛楚——排查BUG。你一定经历过这样的时刻：夜深人静，咖啡凉透，你盯着屏幕，在日志平台和IDE之间来回切换，手指在键盘上飞舞，只为了从成千上万条日志中捞出那几行关键报错。这种机械、重复且极度消耗精力的流程，不仅让人身心俱疲，geng是在无形中吞噬着我们的创造力。

但Zui近，一种新的解题思路正在悄然改变这一现状。当AI遇上MCP，我们似乎kan到了一种可Neng：将那些繁琐的排查工作交给AI，让工程师回归到geng有价值的逻辑构建中去。这不仅仅是一个工具的升级，geng像是一场工作流的革命。

让我们先直面那个Zui让人头疼的场景。传统的调试流程，说起来简直是一部血泪史：打开日志平台，小心翼翼地输入traceId或者某个模糊的关键词，然后在一堆乱码般的输出中大海捞针。好不容易找到了疑似相关的日志，还得把类名、方法名复制出来切回IDE里全局搜索。结合代码逻辑，你开始在大脑里疯狂推演：到底是哪里出了问题？Ru果一次找不准，还得重来一遍，周而复始。

这种过程，逻辑是固定的，步骤是繁琐的，但偏偏又不需要太多的创造性思维。这简直就是为AI量身定Zuo的“猎场”。

Zui近，一种结合了Claude Code的Skill概念与日志平台MCP服务的新玩法，让不少开发者眼前一亮。它的核心逻辑非常简单粗暴：用「协议 + 规范」把这套固定流程“喂”给AI，让它来接管整个闭环。

想象一下你只需要在命令行里敲下一行指令，比如：

/log-diagnosis T1 feature/your-branch trace_id: "your-trace" 为什么Zui终没有返回数据

然后呢？然后你就Ke以去倒杯水了。接下来的几分钟里AI会自动完成一系列复杂的操作：加载技Neng规范、读取环境配置、检查Token状态、计算时间范围、分页拉取全量日志、检索代码、分析逻辑……Zui后它会给你一份详尽的根因分析报告。

要实现这一切，离不开MCP的加持。你Ke以把它理解为AI和外部工具之间的一座桥梁，或者一种通用的“语言”。

以前，AI虽然聪明，但它被关在一个沙盒里kan不见你的数据库，摸不着你的日志文件。而MCP协议的出现，让Claude这样的模型Neng够直接调用日志平台的Neng力，无需人工干预。通过SSE长连接，AIKe以像人类一样实时地获取数据。

配置起来也并不复杂。比如在Claude Code中，你只需要几行命令就Neng把不同环境的日志服务挂载上去：

# 测试环境
claude mcp add --transport sse dw-log-mcp-t1 https://{your-t1-aigw-domain}/api/v1/mcp/log-mcp/sse
# 预发环境
claude mcp add --transport sse dw-log-mcp-pre https://{your-pre-aigw-domain}/api/v1/mcp/log-mcp/sse
# 生产环境
claude mcp add --transport sse dw-log-mcp-prd https://{your-prj-aigw-domain}/api/v1/mcp/log-mcp/sse

或者，Ru果你geng喜欢Cursor，也Ke以在Settings里手动添加这些URL。一旦连接成功，AI就仿佛长出了“眼睛”和“手脚”，Neng够直接深入到你的系统内部去探查究竟。

光有MCP还不够，这就好比给了士兵一把枪，但他还不知道什么时候该扣动扳机。这时候，“Skill”的概念就应运而生了。

Skill的本质，其实就是给AI写的一份详细的SOP。我们在项目的`.claude/skills`或者`.cursor/skills`目录下放置一系列的Markdown文件，比如`SKILL.md`。这里面详细规定了AI应该怎么执行每一步，有哪些禁忌，有哪些必须遵守的规则。

your-project/
└── .claude/
    └── skills/
        └── log-diagnosis/
            ├── SKILL.md         # 技Neng行为规范
            ├── README.md        # 使用说明
            └── reference.md     # 附录：时间脚本、queryString 示例等

这份“操作手册”写得越细，AI的表现就越稳定。比如我们Ke以在里面明确规定：“禁止只查第一页日志就下结论，必须分页拉完所有数据”。这种硬性的约束，有效地避免了AI因为“偷懒”而给出的片面结论。

说了这么多理论，我们来kan一个真实的案例。某次一个搜索接口在测试环境突然“哑火”了无论怎么查dou返回空数据。拿到traceId后我们直接把问题抛给了AI。

AI 通过MCP调取了日志，它敏锐地捕捉到了一个关键信息：`resultList is empty`。这意味着问题不在业务逻辑层，而是在数据库查询层。

紧接着，AI从日志中提取了实际执行的SQL语句，并顺藤摸瓜找到了对应的MyBatis Mapper XML文件。接下来就是它的高光时刻了。

在分析SQL时AI展现出了人类难以企及的“横向对比”Neng力。它发现，在查询条件中，大部分字段dou同时处理了`IS NULL`和`= ''`两种情况，唯独`customer_tag`字段例外。

    and 

而在其他字段中，逻辑是这样的：

-- 其他字段：IS NULL 和 '' dou处理了
AND > 0)
AND > 0)

AI一针见血地指出：数据库里现有的数据，`customer_tag`字段存的dou是空字符串。按照业务语义，本应该匹配所有请求，但因为代码里遗漏了对空字符串的判断，这些数据被无情地过滤掉了。

这种BUG的隐蔽性极高。从语法上kan，SQL没有任何错误；从逻辑上kan，它似乎也“说得通”。只有像AI这样，不带任何偏见地逐行对比每一个字段，才Neng发现这种细微的不一致。人类排查时往往因为“这段代码kan起来没问题”的先入为主，而忽略了这种细节。

geng有意思的是这套组合拳的应用场景远不止于开发调试。试想一下当运营同事面对客诉时不再需要焦急地去找开发帮忙查数据。他们只需要对着这个AI Agent说一句：“帮我查一下这个用户为什么订单异常？”

AI就Neng自动通过MCP服务，去ELK、普罗米修斯或者其他监控系统中捞取数据，分析原因，甚至给出处理建议。这不仅解放了研发的双手，geng让运营团队拥有了前所未有的技术赋Neng。

当然要让这套系统跑起来还是需要一些前期的准备工作。除了前面提到的MCP Server配置，还需要在项目根目录下创建一个`.diagnosis/config.json`文件。

{
  "mcpServers": {
    "dw-log-mcp-t1": {
      "url": "https://{your-t1-aigw-domain}/api/v1/mcp/log-mcp/sse"
    },
    "dw-log-mcp-prd": {
      "url": "https://{your-prd-aigw-domain}/api/v1/mcp/log-mcp/sse"
    }
  }
}

这里面的`secretKey`是唯一需要人工介入的地方，你需要去日志管理后台申请一个密钥。不过一旦配置完成，后续的Token管理、刷新等琐碎工作，douKe以交给AI自动处理。比如`accessToken`过期了AI会自动调用`acquireTokenTool`去获取新的，完全不需要你操心。

在Skill的执行流中，我们还Ke以kan到hen多人性化的设计。比如AI会自动从traceId中提取时间戳，计算出精确的日志查询范围；它会自动识别上下游服务，拉取关联日志进行交叉验证；甚至在分析结束后它还会帮你把代码分支切回原来的状态。

这篇文章的本质，其实是一次对重复性工程劳动的自动化宣战。排查BUG、分析日志、定位代码，这些工作曾经是衡量一个工程师“熟练度”的标准，但它们正在迅速贬值。

未来的工程师，核心竞争力不再是谁Nenggeng熟练地翻日志，而是谁Neng把自己的经验和流程，转化成可复用的AINeng力。就像我们今天讨论的`/log-diagnosis`，它只是一个开始。

识别“固定流程”，是自动化的起点。凡是步骤固定、信息来源明确、输出格式可预期的工作——无论是代码审查、性Neng分析，还是告警巡检——dou值得尝试用Skill + MCP的方式去重构。

所以别再纠结于AI会不会写代码了。真正的问题在于，你准备好给AI写第一份“操作手册”了吗？