日志诊断自动化：Skill+MCP如何重构BUG定位工作流｜技术深度

缘起：后端开发最费时的环节

后端工程师调BUG，核心时间消耗不在分析，而在「上下文切换」。日志平台搜关键词，复制类名方法名，切到IDE找代码，判断问题点，再回去搜日志——这个循环往复的过程，占据了定位时间的60%以上。

去年Q3开始思考这个问题。最早尝试的是Cursor+MCP+代码知识库的组合，但日志查询依赖环境、应用、时间范围，无法静态预置，这个方案存在根本性缺陷。

转折：Skill概念的引入

切换到ClaudeCode后，发现了Skill机制——可以在项目里定义自定义命令，描述AI执行每个步骤的规范。这个设计让思路彻底清晰：日志平台有MCP，ClaudeCode有Skill，两者结合，AI就能自动完成「查日志→找关键信息→扫描代码→定位问题」的完整闭环。

核心问题变成了：如何用「协议+规范」让AI接管这套固定流程？

MCP：突破静态上下文的限制

MCP（ModelContextProtocol）是标准化的工具调用协议。ClaudeCode通过SSE长连接与MCPServer通信，实时获取日志数据。鉴权流程简洁：secretKey申请后，通过acquireTokenTool获取accessToken（1小时有效，最多5个并发），携带token即可调用logsQuery、logSqlQuery、countLogTool等核心工具。

关键价值：AI突破了「只能处理静态上下文」的限制，实现了对动态数据的实时获取。

Skill：给AI写操作手册

log-diagnosis是一个运行在ClaudeCode里的自定义诊断命令。通过.claude/skills/目录定义Skill，以Markdown文件描述行为规范，Claude收到命令时自动加载执行。

执行链路高度工程化：加载SKILL.md→读取环境配置→检查token有效期→从traceId计算时间范围→分页拉取全量日志（最多20页）→切换代码分支检索代码→综合分析根因→生成诊断报告→恢复原始分支。

Skill文件的本质不是「训练模型」，而是给AI一份SOP。约束越明确（如「禁止只查第一页就下结论」），AI执行质量越稳定。

核心能力拆解

Token自动管理解决人工维护痛点；分页全量拉取确保不遗漏关键日志；跨服务分析自动识别上下游日志交叉验证；代码联动让日志中的类名方法名直接定位到源码。

queryString语法支持精确匹配（=）、模糊匹配（≈）及AND/OR/NOT逻辑组合。注意时间范围只通过start/end参数控制，不要写在queryString中。

实战：一个隐蔽SQLBUG的发现路径

某搜索接口测试环境无数据返回。输入traceId，AI自动推算时间范围，检查token状态，分2页拉取73条完整日志。

AI识别关键节点：resultListisempty，SQL查询返回空结果。问题定位在DB层。提取toSearchDTO组装结果后，从ORM日志中还原实际执行的SQL。

发现根因：其他字段都处理了ISNULL和=''两种情况，唯独customer_tag只判断了ISNULL，遗漏空字符串。DB中现有数据的customer_tag字段存的都是空字符串，本应匹配所有请求，却被全部过滤。

AI直接定位到MyBatisMapperXML，对比修复前后逻辑，给出精确的改法。这个BUG的隐蔽性在于SQL语法正确、逻辑「看起来」没问题——只有横向对比其他字段写法才能发现差异。AI没有先入为主的经验偏见，反而擅长这类横向对比审查。

方法论提炼

识别「固定流程」是自动化的起点：步骤固定、信息来源明确、输出格式可预期的工作，都适合用Skill+MCP自动化。排查BUG是典型场景，代码审查、性能分析、告警巡检同理。

AI时代工程师的核心竞争力：把自己的经验和流程转化成可复用的AI能力。log-diagnosis是一次小尝试，但背后的「协议+规范」思路值得在更多场景延伸。