1. 日志诊断为什么值得做成一个 Skill后端同学对这套流程应该都不陌生线上告警响了先打开日志平台输入 traceId 或者关键词从几十上百条日志里翻出关键的那几条把类名方法名复制出来切到 IDE 找代码对着逻辑判断哪里出了问题。一次找不准再回去搜日志、再翻代码。整个过程逻辑固定但极其耗时间光在日志平台和 IDE 之间来回切换就能吃掉大半精力。我试过把这套流程拆开看它其实分成两半一半是「取数据」也就是查日志、拉全量、识别上下游另一半是「做判断」也就是结合代码逻辑推断根因。前者是纯机械劳动后者才需要人的经验。而 AI 恰好擅长接管前者甚至在后者的「横向对比」类问题上比人还稳。这篇要讲的就是怎么用 MCP 把日志平台接进 AI 工具再用一个 Skill 把「查日志 → 提取关键信息 → 扫描代码 → 定位问题」串成一条命令。核心检索词先摆出来日志诊断 Skill 是什么、能做什么、适合谁。它是一个跑在 Claude Code 或 Cursor 里的自定义诊断命令输入 traceId 或告警信息AI 自动拉日志、读代码、给根因适合所有需要频繁排查线上问题的后端、测试和运维同学。下面从 MCP 服务端配置骨架讲起再到 TaoToken 统一 Key 接入最后给一套可复现的验证步骤。2. TaoToken 前置统一 Key 与 MCP 接入准备在动手写 Skill 之前得先解决一个现实问题AI 工具要调用模型模型调用需要 Key而团队里每个人各自申请、各自配置管理起来很乱。TaoToken 在这里的作用就是提供一个统一的模型接入入口一个 Key 打通对话、编码、Agent 等多种场景省去到处找 Key、对额度、换配置的麻烦。你需要先拿到一个可用的 API Key。登录 TaoToken 控制台在 API Keys 页面创建一个新 Key复制保存好。这个 Key 后面会同时用在模型对话和 Coding Plan 场景里。TaoToken 的接入地址分两个别搞混用途地址官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基址https://taotoken.net/apiAPI 基址不带任何查询参数直接作为 base_url 使用。如果你用的是 Claude Code 这类支持 Anthropic 协议的工具走的是兼容接口配置时把 base_url 指向 API 地址即可。注意Key 只创建一次就够不要每个环境重复申请。环境差异通过 Skill 里的 config.json 区分而不是通过不同的 Key 区分。拿到 Key 之后先别急着写 Skill用最简单的方式验证一下 Key 能不能通。这一步能帮你排除掉后面 80% 的「连不上」问题。3. 可复制配置MCP 服务端 config.toml 骨架MCP 的本质是一套标准化的工具调用协议AI 工具通过它去调用外部系统的能力。日志平台提供 MCP ServerAI 通过 SSE 长连接和它通信实时拿日志数据。所以配置分两层一层是 MCP Server 的连接配置一层是 Skill 的行为规范。先给 MCP 服务端的 config.toml 骨架。不同工具的配置文件位置不一样Claude Code 用命令行注册Cursor 用 JSON但底层参数是一致的。下面这份 TOML 骨架可以直接改# mcp-config.toml # 日志平台 MCP Server 配置骨架 [[servers]] name dw-log-mcp-t1 transport sse url https://your-t1-aigw-domain/api/v1/mcp/log-mcp/sse enabled true [[servers]] name dw-log-mcp-pre transport sse url https://your-pre-aigw-domain/api/v1/mcp/log-mcp/sse enabled false [[servers]] name dw-log-mcp-prd transport sse url https://your-prd-aigw-domain/api/v1/mcp/log-mcp/sse enabled false [servers.auth] # secretKey 在日志平台后管申请不要写死在仓库里 secret_key_env DW_LOG_SECRET_KEY # accessToken 由 AI 自动获取并刷新无需人工填写 auto_refresh_token true token_ttl_seconds 3600几个关键点解释一下。transport 固定是 sse因为日志平台 MCP 走的是 Server-Sent Events 长连接。enabled 字段用来控制按需启用测试环境常开预发和生产默认关掉避免误查生产日志也避免额外消耗 token。secret_key_env 指向环境变量不要把密钥硬编码进配置文件这是基本的安全习惯。如果你用 Claude Code注册命令更直接# 测试环境 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-prd-aigw-domain/api/v1/mcp/log-mcp/sse注册完重启 Claude Code执行/mcp看连接状态。如果显示 connected说明 MCP 这一层通了。Cursor 用户走设置里的 Tools MCP添加 MCP Server填 URL 即可。对应的 JSON 配置长这样{ mcpServers: { dw-log-mcp-t1: { url: https://your-t1-aigw-domain/api/v1/mcp/log-mcp/sse }, dw-log-mcp-pre: { url: https://your-pre-aigw-domain/api/v1/mcp/log-mcp/sse } } }鉴权流程是这样的secretKey 在日志平台后管申请AI 调用 acquireTokenTool 换取 accessTokenaccessToken 有效期 1 小时最多同时存在 5 个过期后 Skill 会自动刷新。你唯一需要人工填的就是 secretKey其余全部自动。4. Skill 配置与从报错日志到 BUG 定位的验证步骤MCP 通了只是有了「手」还得有「脑子」告诉 AI 每一步怎么做。这就是 Skill 的作用。Skill 是一个 Markdown 文件放在项目的.claude/skills/log-diagnosis/目录下描述 AI 收到命令后应该执行的完整链路。目录结构your-project/ └── .claude/ └── skills/ └── log-diagnosis/ ├── SKILL.md # 技能行为规范核心 ├── README.md # 使用说明 └── reference.md # 附录时间脚本、queryString 示例SKILL.md 里要写清楚执行顺序比如读取 config.json 获取环境配置 → 检查 accessToken 是否过期 → 从 traceId 推算日志时间范围 → 分页拉取全量日志最多 20 页禁止只查第一页就下结论→ 切换代码分支 → 结合日志关键词检索代码 → 综合分析生成诊断报告 → 恢复原始分支。配置.diagnosis/config.json首次运行 Skill 会引导你填 secretKey也可以手动创建{ secretKey: your-secret-key, accessToken: , accessTokenExpireAt: 0, fields: [] }字段说明secretKey 唯一需要人工填accessToken 和 accessTokenExpireAt 由 AI 自动填充fields 调用 logFields 工具自动获取。配置好之后验证流程走一遍。命令格式是/log-diagnosis {环境} {代码分支} {诉求描述}举个真实场景。某搜索接口在测试环境反馈没有返回数据拿到 traceId 后执行/log-diagnosis T1 feature/your-branch trace_id: your-trace 为什么最终没有返回数据接下来 AI 自动接管。它先从 traceId 推算出日志时间范围检查 accessToken 过期后自动刷新调用 MCP 分 2 页拉取完整日志共 73 条。然后从日志里提取请求入参、还原调用链路识别出关键节点resultList is empty判断问题在 DB 层而不是业务逻辑层。继续往下AI 从日志中提取组装后的查询 DTO再读取 ORM 框架打印的实际执行 SQL。这一步是黄金线索因为 SQL 直接反映最终查询条件。AI 发现其他字段都处理了IS NULL和 两种情况唯独customer_tag只判断了IS NULL-- 其他字段正确IS NULL 和 都处理了 AND (a.order_types IS NULL OR a.order_types OR FIND_IN_SET(0, a.order_types) 0) AND (a.delivery_modes IS NULL OR a.delivery_modes OR FIND_IN_SET(某配送方式, a.delivery_modes) 0) -- customer_tag遗漏了 的判断← BUG AND (a.customer_tag IS NULL OR a.customer_tag 1)DB 里customer_tag存的是空字符串按业务语义本应匹配所有请求却因为这个遗漏被全部过滤掉。AI 顺着找到 MyBatis Mapper XML给出修复!-- 问题代码 -- if testcustomerTag ! null and (a.customer_tag IS NULL OR a.customer_tag #{customerTag}) /if !-- 修复后 -- if testcustomerTag ! null and (a.customer_tag IS NULL OR a.customer_tag OR a.customer_tag #{customerTag}) /if这个 BUG 的隐蔽性在于 SQL 语法正确、逻辑看起来也没问题只有横向对比其他字段的写法才能发现差异。人工排查容易忽略AI 反而擅长这种同等审查。验证成功的标志AI 输出一份诊断报告包含根因、涉及代码位置、修复建议。报告可以落到飞书文档或本地 Markdown。5. 本篇常见错排查配置过程中最容易踩的坑集中在几个地方逐个说。MCP 连不上/mcp显示 failed。先确认 URL 里的域名是不是你实际环境的网关域名占位符your-t1-aigw-domain必须替换。再确认 transport 是 sse 不是 stdio。如果域名对、协议对还是连不上检查网络出口是否允许访问该域名。accessToken 一直刷新失败。大概率是 secretKey 填错或过期。去日志平台后管重新生成密钥更新 config.json。注意 accessToken 最多同时存在 5 个如果频繁刷新导致超限等 1 小时旧 token 过期再试。AI 只查了第一页就下结论。这是 Skill 写得不够严。在 SKILL.md 里明确写「必须分页拉完所有日志最多 20 页禁止只查第一页就下结论」。约束越明确执行越稳定。时间范围算错拉不到日志。traceId 第 9-16 位是 16 进制时间戳Skill 要按这个规则推算。如果 traceId 格式不标准手动指定时间范围。注意时间范围只通过 start/end 参数控制不要写进 queryString。queryString 语法写错。操作符只有精确和≈模糊连接符是 AND / OR / NOT。示例trace_id a1b2c3d4e5f6789012345678abcdef01 trace_id xxx AND log_level ERROR endpoint ≈ /api/your-endpoint AND log_level ERROR代码分支切换后没恢复。Skill 执行完要恢复原始分支否则你下次提交代码会带上一堆无关改动。在 SKILL.md 最后一步明确写「恢复原始代码分支」。模型调用报 401 或额度不足。回到 TaoToken 控制台检查 Key 状态和额度确认 base_url 指向https://taotoken.net/api。如果用的是 Coding Plan 场景确认套餐覆盖了当前工具。6. 把固定流程交给 AI把判断留给自己这套方案跑通之后我最大的感受是不是所有工作都适合 AI 接管但凡是「步骤固定、信息来源明确、输出格式可预期」的工作都值得用 Skill MCP 的方式自动化。排查 BUG 是一个典型代码审查、性能分析报告、告警巡检也是同类。Skill 的本质是给 AI 写操作手册不是在训练模型。写得越细、约束越明确执行质量越稳定。这和写给人看的 SOP 是一回事。而 MCP 解决的是数据来源问题让 AI 能实时拿到动态日志而不是只能处理静态上下文。两者缺一不可只有 MCPAI 能查日志但不知道怎么系统分析只有 SkillAI 有流程但没有数据。如果你准备动手建议从测试环境开始先把 MCP 接通、Key 配好再写一个最小可用的 SKILL.md跑通一次完整诊断。等流程稳定了再往预发和生产扩。需要长期做编码和 Agent 场景的同学可以了解下 Coding Plan把模型调用和工具链统一起来想先验证模型效果的直接去模型对话页面试接入和排障相关的细节API Keys 页面和接入文档里有完整说明。把 Key 和配置理顺剩下的交给 Skill 就行。