鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册
站长：程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
6
3
4

效率翻倍：基于 MCP 协议打造自动化排查 Skills，实现线上 Bug 并行诊断

Liuuuuuuuuu
Liuuuuuuuuu
2026-05-06 00:09
阅读 1682
Liuuuuuuuuu
2026-05-06 00:09
阅读 1682

效率翻倍：基于 MCP 协议打造自动化排查 Skills，实现线上 Bug 并行诊断

痛点

  1. 在面对如多组织升版、项目升版，往往会有一堆禅道bug提给你，打开禅道就是一页bug。一个一个bug的排查解决太慢了，如果使用cc+skill，可以并行解决多个bug。
  2. 或者你在开发一个新功能，测试or产品or实施找到你，让你看线上bug。此时你就可以把线上报错给到cc，让它加载skill去排查，不用打断开发新功能的思路。
  3. 这个 Skill 解决的场景，就是你手上 Bug 很多，或者你手上有其他事，但同时还有 Bug 需要处理的时候。

需要注意的是，如果这个 Bug 很紧急，那么最好是手动去排查，或者采用“手动加 AI”的方式。

因为使用 Claude 去排查错误，速度可能还是会比手动处理稍微慢一点。

什么是 MCP？

MCP（Model Context Protocol，模型上下文协议），你可以把它理解成：

👉 让 AI “接入外部世界”的接口标准

我们平时用 AI，会发现一个问题：

AI 虽然很聪明，但它其实是“瞎的”和“聋的” 它看不到你的日志、访问不了你的数据库、也不知道你系统里发生了什么

这时候就需要 MCP。MCP是真正的工具能力，能让 Claude 访问本地文件、浏览器、外部 API、第三方工具。

什么是 Skill？

如果说 MCP 解决的是“能不能做”，那 Skill 解决的是：

👉 “应该怎么做”

Skill 本质上就是一套固定流程（Workflow）+经验沉淀。

Skills是封装好的提示词 / 标准化工作流，让 Claude 变成特定领域的专业人士，本质是让 AI 更懂怎么干。

举个真实场景

比如你把一段报错直接丢给 AI：

  • 没有 Skill 时：
  • AI 可能直接看代码 → 猜原因 → 给结论（有时不准）
  • 有 Skill 时：
  • AI 会严格按照流程： - 去服务器拉完整日志 - 分析错误上下文 - 再去看相关代码 - 必要时查数据库数据 - 最后输出诊断报告

👉 每一次排查，步骤一致、结果更稳定、更可靠

案例 自定义skill diag 排查错误

如下图，点击选择客户的接口报错。能拿到错误信息，发现是数据库字段不对。一般的排除流程，是去服务器上看具体那个sql查询那个表字段的问题，然后再去数据库比对。

这里我自己定义了一个skill diag，作用就是专门排除线上错误给出诊断报告。

定义了一个流程

  1. 去服务器拉完整日志
  2. 分析错误上下文
  3. 再去看相关代码
  4. 必要时查数据库数据
  5. 最后输出诊断报告

下图也展示了配置了mcp的cc的，能去查看日志和数据库了。

image-20260505182730210.png

image-20260505182849860.png

image-20260505183241208.png

多个bug

这样并行解决多个bug，最后去验收诊断报告就可以了。并且诊断完还可以让cc直接帮你修改。

image-20260505183530864.png

怎么使用与安装

页面接口弹出了报错信息，/diag + 报错信息 就行了。或者直接 /diag 给我查询服务器上最新的错误

配置涉及到的文件都在这个仓库里

Liuuuuuuux/diag-skills

如果后面有空我可能会补充一下一键安装，在github仓库里。

MCP配置

直接将下面这段复制给cc or codex 让它给你配置就好了。请在项目路径下打开cc 再输入下面这段话。请根据项目具体在那个服务器以及数据库来配置，下面的账号信息配置好了，再复制给AI。关于账号看下面MCP账号。

▼
Bash
复制代码
给我安装全局的mcp npm install -g mcp-server-mysql mcp-server-ssh,并配置当前项目的mcp-server-mysql与mcp-server-ssh。参考如下。将下面配置到项目的.mcp.json中
{
  "mcpServers": {
    "mysql": {
      "command": "mcp-server-mysql",
      "args": [],
      "env": {
        "MYSQL_HOST": "<MYSQL_HOST>",
        "MYSQL_PORT": "<MYSQL_PORT>",
        "MYSQL_USER": "<MYSQL_USER>",
        "MYSQL_PASS": "<MYSQL_PASS>",
        "MYSQL_DB": "<MYSQL_DB>"
      }
    },
    "ssh": {
      "command": "mcp-server-ssh",
      "args": [],
      "env": {
        "SSH_HOST": "<SSH_HOST>",
        "SSH_PORT": "<SSH_PORT>",
        "SSH_USER": "<SSH_USER>",
        "SSH_PASS": "<SSH_PASS>"
      }
    }
  }
}

MCP账号

  1. 数据库账号

▼
SQL
复制代码
-- MariaDB 创建用户语法
CREATE USER 'mcp_readonly'@'%' IDENTIFIED BY 'Mcp123456';

-- 授予只读权限
GRANT SELECT ON *.* TO 'mcp_readonly'@'%';

-- 刷新权限
FLUSH PRIVILEGES;

-- 验证用户创建成功
SELECT user, host, plugin FROM mysql.user WHERE user = 'mcp_readonly';

  1. 服务器账号

这个脚本是创建一个只能查看服务器上日志的账号，并通过添加日志地址来授权。没有任何编辑删除的权限。在第二个红框上累加上不同项目的日志地址就好了。

建议将这个文件维护到每个服务器上固定位置，如果有新增权限直接下载下来修改上传上去，或者直接在服务器上修改。

添加过日志地址上以后，按照下面的命令执行一下就好了。

▼
Bash
复制代码
bash create_readonly_user.sh

image.png

配置服务器信息地址

在当前项目下打开的cc。

具体的服务器路径、日志文件叫什么名字，请根据不同项目来进行不同的配置。

▼
SQL
复制代码
将下面的内容配置到当前项目中的.claude/Memory.md中

# 项目 Memory

## 服务器配置

### 开发环境服务器
- **服务器路径**: `放日志的路径`
- **日志文件**:
  - `admin-3603.log`

SKILL安装

直接将下面这段话复制给cc or codex

▼
Plain
复制代码
请给我将下面的 Skill 给我安装到全局


---
name: diag
description: 诊断服务器错误 - 先查服务器日志找到错误，再定位代码和数据库
triggers:
  - 当用户报告服务器错误时
  - 当需要诊断线上问题时
  - 当用户提到"diag"、"服务器报错"、"线上"时
---

先查服务器日志，找到错误后再排查代码和数据库。

<CRITICAL>
必须严格遵守以下步骤顺序，禁止跳过任何步骤。
禁止在没有日志证据的情况下直接搜索代码。
</CRITICAL>

## 执行步骤

### 第一步：连接服务器（必须）

1. **检查现有连接**：调用 `mcp__ssh__ssh_list_connections`
2. **如果没有连接**：
   - 读取当前项目根目录下的 `.mcp.json` 获取 SSH 连接信息
   - 如果当前项目没有 `.mcp.json`，立即询问用户提供服务器连接信息（host、username、password/key）
   - 调用 `mcp__ssh__ssh_connect` 建立连接

### 第二步：查询服务器日志（必须）

读取配置：

- 只读取当前项目根目录下的 `.claude/MEMORY.md` 获取日志目录
- 如果当前项目不存在 `.claude/MEMORY.md`，立即询问用户提供日志目录或相关配置

连接服务器，获取日志中的错误：

```bash
# 直接查看指定日志文件的错误（最常用）
grep -A 30 "ERROR" /日志目录/日志文件.log | tail -n 200

# 查看日志最后 200 行（了解最新状态）
tail -n 200 /日志目录/日志文件.log

# 如果日志路径不确定，先列出目录内容
ls -la /日志目录/
```

有参数时搜索关键词，无参数时搜索最近错误。

**必须展示日志内容**，确认错误发生的具体时间和上下文。没有展示日志前，禁止进入下一步。

### 第三步：定位代码

根据堆栈信息在本地代码中定位文件和行号。

### 第四步：查询数据库（如需要）

使用 `mcp__mysql__mysql_query` 查询相关数据。

### 第五步：输出诊断报告

错误概述、原因、代码位置、修复建议。

## 禁止事项

- 禁止在没有日志证据的情况下直接搜索代码
- 禁止跳过服务器连接检查步骤
- 禁止假设错误原因，必须以日志为准

如果全局的.claude的skills 目录下多了一个diag文件夹并且多了一个SKILL.md格式的文档。就说明已经安装成功了，重启cc就好了。

image-20260505231106255.png

安全

使用这个 Skill，不用担心会误删除数据或服务器上的重要信息。我已经做了一定束缚：

  1. 在服务器上写一个脚本，创建一个“只供 AI 查看日志”的权限角色。
  2. 数据库的 MCP 也是同样的逻辑。尽管该 MCP 已经限制了只能查询，但我给数据库相应角色配置的也是只读权限，没有提供任何其他权限。

包括如果说你们写其他的 Skill 的时候，也一定要注意。尽管现在cc权限控制做得已经很好了，当然，比如说当你设置完全权限的话，通常情况下只有删除文件才会触发拦截，但是也有可能会出现误结算或误处理文件的情况。

为了预防这种情况，你必须先预先去制止它、去约束它，确保它使用的是没有多余权限的账号。

此外如果是在生产环境在向 AI 传输日志时，建议预先在脚本层面脱敏处理，避免泄露银行账号、金额或客户敏感身份信息。

我的 Skill 设计想法

我首先来分享一下，我是怎么想到写一个排查报错的 Skill 的。

因为我日常经常会直接将服务器上的报错交给 AI，让它告诉我哪个类、哪个服务、第几行代码出了问题，因为我比较懒得自己去看日志、去翻代码。

因为我经常这么操作，所以我就想，能不能直接让 AI 帮我全自动排查错误出现的根源，并直接分析代码。

其实线上的很多错误主要归纳为几种情况：

  1. 数据不一致：

  2. 代码逻辑与数据的综合分析

    AI 可以结合数据库里的实际数据和你的代码逻辑，通过关联分析找出错误原因。

通过这种方式，AI 生成的诊断报告通常是比较准确的。当然，偶尔也会出现不准确的情况（比如它获取的信息不全），这时你可以手动补充一些背景信息。基本上，AI 出具的诊断报告 90% 以上都是正确的。

以上就是我如何使用 AI，并发现 AI 可以自动排查错误的一个想法。其实写一个 Skill，重要的是想法。即便你完全不懂 Skill 该怎么写（比如应该放在哪个目录、用什么 Markdown 格式来输出会比较好），其实都没关系。

只要你有了想法，就可以先创建一个 Skill。如果发现哪里不对，你可以让 Claude 去慢慢迭代、优化；发现逻辑不通了，就让它去修改。包括你最初创建这个 Skill 的时候，也可以直接把想法告诉它。比如跟它说：“我要在一个场景中干什么干什么，为了实现这个目标，我需要你做什么，最后给我一份什么样的结果。”

你只需要把这些想法和背景都灌输给 AI，让 AI 去帮你写出一个 Skill。

其实从头到尾这个 Skill 也都是我让 Claude 帮我写的。这个skill也是，让 Claude 不断去给我优化完成。

包括我们现在写的这个 Skill，其实很多时候是给 AI 一个约束，让他分步骤执行。比如：

  1. 第一步干什么
  2. 第二步干什么
  3. 第三步干什么

并且让他不能直接给我猜想和结论，其实很大一部分工作就是约束 AI。

这篇文章只是分析一下，我是如何使用skills的。不过现在似乎也有现成的skill集成了类似的功能，例如我搜到的这个，虽然我没用过生产事件调试器 - Claude 代码技能。而且这个文章大概3月份就写得七七八八了，现在五一才改了发出来，虽然感觉也还不完善，但是感觉不能再拖了。给大家一个参考，平时工作中可以怎么写skills。欢迎大家多多交流，平时如何使用AI的。

Java
GitHub
AI
6
4
分享
操作
评论
相关内容
0个评论
全部评论
点击登录，快来和大家讨论吧～
表情
图片

目录

🔥 热门文章
1
手把手教你设计一个成熟的 Agent Harness
2510
2
我用 REA 逆向了付费颜色 APP，结果很意外！
570
3
离谱，DeepSeek 崩了 5 小时，大家却喊：梁圣恩情还不完？？
420
4
DeepSeek 全新模型发布，性价比最高的一集！
380
5
B 站上 DeepSeek 闹鱼灾了，我发起《大肥鱼清除计划》！
370
6
自己学习ai，直接买cursor 的套餐，还是买gpt 或者claude 的套餐?
360
7
又一个国产版 Codex 神器，也来卷办公了！
330
8
day3-如何写出一个高质量的 Skill（组内分享） 高质量 Skill 不是“一个调得很顺的巨型 Prompt”，而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”，再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子，但方法是通用的。 --- 一、先想清楚：Skill 到底是什么 一个 Skill 至少包含四部分： 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做，每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办，而不是硬编一个看似合理的结果 高质量 Skill 的共同点：职责单一、接口清晰、规则可定位、输出可验证。 反例：把几十条经验全塞进一个主 Prompt，改一条规则要重调整个 Prompt，评估时也不知道是哪条规则退化。 --- 二、核心方法：先建评估，再写 Skill 不要先写转换器再补测试。正确顺序是： 1. 定义输出契约：什么算合法、什么算合格； 2. 建金标准集：一小批人工认可“可放行”的样本； 3. 先写评估 Skill：让它在金标准集上跑出基线； 4. 再迭代生成 Skill：每次修改跑同一套评估，无退化且目标维度提升才算正向。 这就是评估驱动开发：评估是 Skill 的单元测试，金标准集是回归锚点。 --- 三、评估 Skill：三层门禁，逐层递进 前一层不过，后一层不跑。每层留可追溯证据。 第 1 层：确定性硬门禁 用解析器、Schema、校验器完成，不消耗模型成本。 · 输出可解析； · 必填字段齐全，类型/枚举合法； · 引用目标存在，无悬空引用、无不可达节点； · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层：语义断言 用脚本 + 结构遍历检查“逻辑对不对”，仍然保持确定性。 通用检查项： · 覆盖率：源材料里的关键步骤、分支、条件，输出里是否都有对应？ · 完整性：每个判断节点是否都有明确出口？有没有死胡同？ · 可达性：每条路径是否都能到达预期终点？有没有无出口循环？ · 顺序与依赖：有先后依赖的操作，是否保留了顺序？有没有被拍平成无序列表？ 例子：故障诊断转换中，检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层：LLM-as-Judge 只处理解析器表达不了的维度：忠实度、完整性、可执行性。 但 Judge 会漂移，不能单独放行，必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化，换模型必须用金标准集重新校准。 通用 Judge 维度： 维度 问什么 忠实度 输出是否忠实源材料意图？有没有自行发明内容？ 完整性 关键步骤、条件、证据是否保留？隐式知识有没有被压成空话？ 收敛性 输出是否仍指向原目标，而不是发散？ 可执行性 下游不依赖源材料能否直接使用？ --- 四、金标准集：回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子，扩到 15～30 份，覆盖失败模式而非随机抽样： · 完整正例：典型流程； · 边界/异常分支：异常路径、循环、前置失败回退； · 已知易错模式：实际踩过的坑； · 留出集：不参与调优，只用于最终验收，防过拟合。 金标准不需要完美，只需要当前标准下认可可放行。 回归指标：关键路径用 pass^k（k 次全过），稳定性用 pass@k。 --- 五、工程约束：让批量产出可重放 · 幂等：同输入 + 同 Skill 版本 + 同规则 → 输出一致，否则无法判断变好是 Skill 改了还是随机波动； · 隔离不阻断：单份失败进隔离队列，记录失败层和原因，不阻塞其余； · 版本绑定：规则、rubric、金标准集进 Git；每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”； · 抽样人工复核：Judge 临界样本 + 易错模式，人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅，写清：输入约定、输出契约、分步流程、硬规则、降级策略； · 经验规则放 references/ 或 rules/，按失败模式分类，不要全塞进主 Prompt； · 不确定时标 needs_review: true，不要硬编看似合理的结果； · 迭代由评估报告驱动：报告告诉你哪层挂了、哪类失败模式，你改对应规则文件，而不是漫无目的调 Prompt。 --- 七、落地顺序（不要反过来） 1. 固化输出契约：Schema + 结构约束； 2. 建金标准集：从已认可的 + 最易出错的样本开始； 3. 先写评估 Skill：跑出基线报告； 4. 再迭代生成 Skill：每次修改对比逐项通过率，无退化且目标提升才算正向； 5. 批量运行 + 隔离回放：失败进队列，结束后人工抽检； 6. 评估 Skill 自身版本化：换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”：每次修改必须附评估报告对比，逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数：前两层挂了，Judge 分数没有意义。 3. 不许把规则堆进主 Prompt：规则按失败模式分文件，评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”，评估 Skill 决定“敢不敢用”。 先让评估体系站稳，再让生成器迭代。这样交付的不是一堆“看起来还行”的产出，而是一套可证明、可回归、可交接的 Skill 质量体系。
310
9
AI 越强，被它拒绝的代价就越大 我有时候会想：AI 越来越厉害之后，有些事情，会不会反而越来越难做？ 这个想法看起来有点矛盾。AI 明明在降低门槛，让不会写代码的人做出软件，让不会画画的人生成图片，让一个人完成过去需要整支团队才能完成的工作。但今天用 Codex 的时候，AI 拒绝帮我编写 SQL 注入的请求体，而那还是我有源码、在本地跑测试的情况。那么，往后是否只会更难？ 我们假设某一天，AI 说：「这个请求违规，我不能帮助你。」到那个时候，你还有多少能力，能绕过它，把事情做完？ 这里的「违规」需要打个引号。平台的规则、模型的判断、法律的要求，以及一件事实际有没有造成伤害，彼此之间并不总是画得上等号。一个请求可能确实危险，也可能只是缺少上下文被误判，或者恰好落在某家公司的限制范围里。 无论是哪种情况，随着我们越来越依赖 AI，这句拒绝都可能变得越来越贵。 今天，一个程序员让 AI 帮忙写代码，AI 拒绝了，他大概率还有别的办法：查文档、找开源项目、问同行，或者自己写。麻烦一点，慢一点，但路还在。 可如果十年之后，大部分程序都由 AI 完成，情况就不一样了。 很多人从接触编程的第一天起，就习惯了描述需求、等待生成、运行结果、继续迭代。他们能做出相当复杂的产品，却未必经历过独立处理底层问题的训练。平时，这种能力结构完全够用，效率甚至更高。只有 AI 拒绝的时候，他们才会发现：平常被省掉的那段学习过程，恰好是此刻最需要的东西。 到那时，一次拒绝的成本，可能就从「今晚多花两个小时」，变成「先花半年学会这门技术」。 拿 SQL 注入举个稍显极端的例子：往后，连真正理解这类攻击如何发生、能够独立构造测试的人，会不会也越来越少？ 这里也包括那些有正当需求的人。一个开发者想检查自己的旧系统，一个经过授权的安全研究员想复现漏洞，假如 AI 识别到危险模式就拒绝，而使用者又只熟悉「让 AI 帮我检查」，这项原本可以独立完成的工作，就这样卡住了。 但是安全专家不会因此消失，但这类技能可能越来越集中在少数人手里。你仍然可以找专家，只是要付出更多的钱、更多的时间，以及更高的沟通成本。 类似的困境，未必只发生在网络安全领域。 你想从一个停止维护的软件里取回自己的数据，需要解析它的旧文件格式。AI 判断这涉及规避保护措施，拒绝继续。你拥有这些数据，却没有能力把它们读出来。 你买了一台设备，厂商停止提供服务。你想修改程序让它继续运转，过程中需要处理某种访问限制。AI 不愿协助，而你所掌握的维修方式，早已只剩下「把报错发给 AI」。 你想给常用的网站写一个辅助工具，减少重复操作。平台将此归入自动化限制，AI 也据此拒绝。过去会写脚本的人可以自己判断、自己处理；未来的使用者，可能连从哪里开始都不知道。 这些例子有一个共同点：当工具同时承担了「执行工作」和「传授知识」的角色，它的拒绝就不只是挡住了一次任务，也挡住了获得这种能力的机会。 更麻烦的是，这种依赖往往是我们主动选择的，而且每一步都很合理。 既然 AI 几秒钟就能做好，为什么还要花几个月学习？既然公司可以采购成熟的 AI 服务，为什么还要养一支负责基础工作的团队？既然市场上已经很少有人手写这些东西，学校为什么还要花大量时间教？ 对个人、公司和学校来说，这些选择都有现实依据。但叠加起来，整个社会保留的独立能力就可能越来越少。等到某项能力突然受到限制，我们才发现，备用方案早已在追求效率的过程中被一点点削掉了。 所以，「AI 越强，做事越便宜」可能只描述了未来的一半。 另一半是：被允许的事情越来越便宜，被拒绝的事情依然需要人工完成，却要面对更少的人才、更高的报价，以及越来越难获得的知识。两边的成本差距，会越拉越大。 有人会说，可以换一个模型，或者用本地模型。这确实是重要的选项。只要工具之间还有充分竞争，开放模型还足够可用，限制就未必能形成真正的门槛。 但备用方案也需要维护。它需要硬件、知识、软件生态，以及一群仍然理解这些系统的人。如果大多数人已经习惯了最方便的商业服务，那么「理论上还有别的办法」和「普通人实际用得起、用得明白」，之间仍然可能隔着很远。 我担心的，正是这段距离。 我不指望 AI 对任何请求都照单全收。对明显会伤害他人的行为设置限制，有充分的理由。但我们也需要关心：限制由谁定义，误判有没有申诉渠道，用户能不能换工具，以及脱离这个工具之后，还剩下多少独立行动的能力。 保留这些能力，平时看起来甚至有点低效，明明可以自动生成，还要理解原理；明明可以一键完成，还要知道手动怎么做。 但这些看似多余的知识，会在工具拒绝、失效、涨价或改变规则的那一刻，成为真正的选择权。 AI 越强，我们可能越需要留意它说「不」的那一刻。 因为那句话的分量，最终取决于：它拒绝之后，我们还能做什么。
310
10
什么是LLM
300
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
墨得问题墨得问题