引言：Prompt 工程的终结与 Skill 工程的崛起

2026 年，如果你还在往大模型的 Chat 窗口里死磕那堆动辄几千字的 “你是一个资深的 Java 专家...”、“请严格遵循以下格式...” 的 Prompt 模版，那你不仅在浪费巨额的 Token 钱包，还在挑战大模型的长文本注意力极限（长文本幻觉）。

之前我们聊了 MCP（Model Context Protocol），它解决了大模型“手脚拓展”的问题（如何调 API、读写数据库）。但随之而来的是一个更棘手的问题：有了手脚，怎么保证大模型的“大脑”在复杂的企业级高压场景下不犯浑、不脱轨、且不把 Token 烧干？

答案就是 Agent Skills（智能体技能规范）。

它不再是一段虚无飘渺的空气提示词，而是一个完全工程化、结构化、支持动态渐进式加载（Progressive Disclosure）的本地技能包。今天，我们就来彻底拆解这套颠覆性的高级玩法。

---

一、 核心黑科技：什么是“渐进式加载”？

传统的系统级 Prompt（System Prompt）是静态的。你塞给 AI 一万字，不管今天聊的是“你好”还是“排查线上 OOM”，这一万字都会作为历史上下文（Context Window）在每次对话中反复计费。

而 Skill 规范 引入了类似操作系统内存管理的虚页调度机制：

[ 用户输入 ] -> "线上数据库响应太慢了，帮我查查"
                     |
                     v
[ 技能感知层 ] -> 扫描所有本地 SKILL.md 的 Frontmatter (几百 Token 消耗)
                     |
                     v (命中：postgres-best-practices)
[ 动态加载层 ] -> 瞬间将该 Skill 下的 5000 字规范和本地 Python 脚本注入上下文

只有当用户的意图（Intent）触发表单中的路由规则时，核心技能才会被激活。这直接让企业的 AI 运营成本暴降 80% 以上。

---

二、 工业级实战：手撸一个 Java 线上故障应急 Skill 文件夹

为了让大家直接能在公司落地，我们直接手写一个生产环境的 java-troubleshoot 技能包。请在你的本地（或项目根目录 .claude/skills/java-troubleshoot/）建立如下结构：

Plaintext

java-troubleshoot/
├── SKILL.md                   <-- 技能核心调度器
├── scripts/
│   └── parse_thread_dump.py   <-- 辅助 AI 分析线程死锁的本地高效脚本
└── references/
    └── hikari-pool-limits.md  <-- 团队内部死命令：数据库连接池硬性指标

1. 核心调度器：SKILL.md

注意看顶部的 YAML 头，这是喂给引擎的路由表。

---
name: java-prod-troubleshoot
description: 当用户提到 "OOM"、"服务假死"、"CPU飙升"、"线程阻塞"、"慢SQL" 或上传 `.hprof` / `.txt` 日志时触发。提供工业级 JVM 与微服务故障排查。
disable-model-invocation: false
user-invocable: true
version: 2.1.0
---

# Java 线上故障应急响应规范 (Runbook)

你现在是精通 Linux 内核、JVM 调优、Tomcat 及 HikariCP 线程模型的资深稳定性专家。一旦激活，必须放弃所有客套话，严格执行以下标准化诊断流。

## 🚫 铁律约束
- **严禁盲目猜测：** 未拿到关键日志前，不准下绝对结论。
- **高危命令拦截：** 任何涉及 `kill -9`、`rm -rf` 或线上物理重启的命令，必须单独建一行并标注 `[DANGER]`。

## 🛠 标准执行流 (Standard Operating Procedure)

### 第一阶段：状态止血与现状对齐
检查用户输入，如果没有提供以下三要素，必须以标准表格形式向用户索要：
1. **基础环境：** JDK 版本 (e.g., 17/21) 与 垃圾回收器 (e.g., G1/ZGC)。
2. **监控表象：** 当前机器的 CPU 利用率、Memory 利用率、以及磁盘 I/O。
3. **报错堆栈：** 关键的 Exception 异常日志。

### 第二阶段：场景化下钻分析

#### 场景 A：CPU 飙升至 90%+
不要让用户自己瞎猜，命令大模型指导用户执行以下精准定位魔术组合命令：
1. 找到最耗 CPU 的线程：`top -Hp <pid>`
2. 将线程 PID 转换为 16 进制：`printf "%x\n" <thread_id>`
3. 提示用户使用本技能自带工具或 MCP 抓取 Thread Dump，并用 16 进制字符进行 `grep`。

#### 场景 B：物理内存溢出 (OOM)
1. 检查是否触发了 Linux 的 `OOM Killer`（检查 `/var/log/messages`）。
2. 分析 MetaSpace 还是 Heap 溢出。若是 Heap 溢出，指示用户调用下述 `scripts/parse_thread_dump.py` 进行静态扫描。

### 第三阶段：输出报告模版
大模型输出的最终结论必须严格采用以下 Markdown 块：
> ### 🛑 诊断报告
> - **【可能根因】**：
> - **【止血方案（临时）】**：
> - **【根治方案（长期）】**：

2. 辅助脚本：scripts/parse_thread_dump.py

有时候大模型处理几万行的文本会丢上下文，这时候 Skill 内部的脚本就派上用场了。这是一个由 Skill 自动调度、帮大模型过滤死锁的 Python 脚本：

Python

import sys
import re

def analyze_dump(file_path):
    with open(file_path, 'r', encoding='utf-8') as f:
        content = f.read()
    
    # 查找经典的 Java 死锁特征
    deadlock_pattern = re.compile(r"Found one Java-level deadlock", re.IGNORECASE)
    if deadlock_pattern.search(content):
        print("[SKILL INTERNAL RESULT] 🚨 检测到明确的 Java 级别死锁！")
        # 提取死锁相关的线程块
        blocks = content.split("\n\n")
        for block in blocks:
            if "waiting to lock" in block or "locked" in block:
                print(block)
    else:
        print("[SKILL INTERNAL RESULT] 未发现明显死锁，请大模型继续分析线程状态分布（如 BLOCKED 数量）。")

if __name__ == "__main__":
    if len(sys.argv) > 1:
        analyze_dump(sys.argv[1])

---

三、 在各大 AI 生态中如何跑起来？

1. Claude / Claude Code (终端环境)

在新一代的 Claude 开发者生态中，Skill 是原生支持的对象。

• 安装技能： 将上述文件夹移至 ~/.claude/skills/java-troubleshoot。

• 热加载感知： 终端键入 claude skills:list，你会直接看到 java-prod-troubleshoot 处于已就绪（Enabled）状态。

• 交互表现：

  当你在终端输入：

  claude "我们线上的微服务突然不响应了，CPU 一直是 100%"

  Claude 会在后台默默加载这个 Skill。你在终端会看到一个优雅的齿轮转动提示：

  [Loaded Skill: java-prod-troubleshoot]。接着，迎面而来的就是严苛的“稳定性专家”问询，没有任何垃圾话。

2. Codex / 现代化大模型编辑器环境

在基于 Codex 体系或现代 IDE AI 插件的世界里，Skill 通常作为项目隔离的生产力规约。

• 部署： 将文件夹放入工程的 .codex/skills/java-troubleshoot/。

• 唤醒： 在右侧聊天面板输入 $ 符号，会弹出当前项目的可用 Skill 菜单。选择 java-prod-troubleshoot，当前对话的系统上下文将瞬间获得该技能的高级注入。

---

四、 王炸联动：大模型的大脑（Skill）与手脚（MCP）合一

单单有 Skill 规范，大模型只是“更听话、更专业”了。但如果你把它和我们上一期讲的 MCP（Model Context Protocol） 结合，那就是真正的科幻现实。

我们在 SKILL.md 中，加入一条自动化联动剧本（Automation Tool Trigger）：

Markdown

## 🤖 自动化工具联动（高级模式）
当用户提到 "帮我看一下这台服务器的当前死锁情况" 时：
1. **严禁** 让用户去敲命令。
2. 检查当前可用的 MCP Tools 中是否包含 `ssh-executor`。
3. 如果包含，自动通过 MCP 异步发送命令 `jstack $(pgrep java)` 并将输出流重定向到本地的临时文件 `dump.txt`。
4. 隐式执行本地脚本 `/scripts/parse_thread_dump.py dump.txt`。
5. 将两者的结果汇总，直接展示最终的【诊断报告】。

这一幕发生时的名场面：

1. 你： “救命，北京机房 10.0.2.14 服务器卡死了，帮我看看。”

2. Claude（大脑激活 Skill）：识别到服务器卡死意图，加载应急 Skill。

3. Claude（手脚伸向 MCP）：Skill 指导它调用绑定的 SSH-MCP 服务，潜入北京机房。

4. Claude（执行本地辅助脚本）：在你的开发机本地后台咔哒咔哒跑了一下 Python 分析脚本。

5. Claude（输出结果）：

   “诊断完成。根本原因：订单服务的 OrderService.java:142 行与库存服务的 StockService.java:89 行发生互斥死锁。止血建议：立刻在下方点击 [一键通过 MCP 降级该服务接口]。”