用女娲蒸馏 Mark Russinovich 排障思维：打造 Windows 桌面运维专家 Skill

🔥 个人主页： 杨利杰YJlio
❄️ 个人专栏： 《Sysinternals实战教程》《Windows PowerShell 实战》《WINDOWS教程》《IOS教程》
《微信助手》《锤子助手》《Python》《Kali Linux》
《那些年未解决的Windows疑难杂症》
🌟 让复杂的事情更简单，让重复的工作自动化

用女娲蒸馏 Mark Russinovich 排障思维：打造 Windows 桌面运维专家 Skill

[1. 为什么我要蒸馏 Mark Russinovich 的排障思维？](#1. 为什么我要蒸馏 Mark Russinovich 的排障思维？)
[2. 这次蒸馏出来的核心内容是什么？](#2. 这次蒸馏出来的核心内容是什么？)
[3. 女娲 Skill 的使用方法记录](#3. 女娲 Skill 的使用方法记录)
- [3.1 环境准备](#3.1 环境准备)
- [3.2 安装女娲 Skill](#3.2 安装女娲 Skill)
- [3.3 本地 Skill 目录在哪里？](#3.3 本地 Skill 目录在哪里？)
[4. 蒸馏 Mark Russinovich Skill 的过程](#4. 蒸馏 Mark Russinovich Skill 的过程)
- [4.1 明确蒸馏目标](#4.1 明确蒸馏目标)
- [4.2 输入核心素材](#4.2 输入核心素材)
- [4.3 生成出的 Skill 结构](#4.3 生成出的 Skill 结构)
- [4.4 排障工作流设计](#4.4 排障工作流设计)
[5. 工具选择决策树：从症状派遣工具](#5. 工具选择决策树：从症状派遣工具)
- [5.1 进程挂起 / 无响应](#5.1 进程挂起 / 无响应)
- [5.2 应用崩溃 / 报错](#5.2 应用崩溃 / 报错)
- [5.3 权限拒绝 / ACCESS DENIED](#5.3 权限拒绝 / ACCESS DENIED)
- [5.4 蓝屏 BSOD](#5.4 蓝屏 BSOD)
- [5.5 启动慢 / 登录慢](#5.5 启动慢 / 登录慢)
[6. Russinovich 式排障工作流如何落地？](#6. Russinovich 式排障工作流如何落地？)
- [6.1 第一步：问题分类](#6.1 第一步：问题分类)
- [6.2 第二步：工具选择](#6.2 第二步：工具选择)
- [6.3 第三步：数据采集](#6.3 第三步：数据采集)
- [6.4 第四步：分析与验证](#6.4 第四步：分析与验证)
- [6.5 第五步：修复与总结](#6.5 第五步：修复与总结)
[7. Sysinternals 工具速查卡](#7. Sysinternals 工具速查卡)
[8. 生成后的 Skill 应该怎么使用？](#8. 生成后的 Skill 应该怎么使用？)
- [8.1 直接触发方式](#8.1 直接触发方式)
- [8.2 适合输入的信息](#8.2 适合输入的信息)
- [8.3 期望它输出什么？](#8.3 期望它输出什么？)
[9. 我的实战理解：这类 Skill 真正的价值是什么？](#9. 我的实战理解：这类 Skill 真正的价值是什么？)
- [9.1 用于现场排障](#9.1 用于现场排障)
- [9.2 用于工单复盘](#9.2 用于工单复盘)
- [9.3 用于 SOP 编写](#9.3 用于 SOP 编写)
- [9.4 用于 CSDN 博客写作](#9.4 用于 CSDN 博客写作)
[10. 常见问题与踩坑记录](#10. 常见问题与踩坑记录)
- [10.1 GitHub 克隆超时怎么办？](#10.1 GitHub 克隆超时怎么办？)
- [10.2 提示 spawn git ENOENT 怎么办？](#10.2 提示 spawn git ENOENT 怎么办？)
- [10.3 npm.ps1 被执行策略拦截怎么办？](#10.3 npm.ps1 被执行策略拦截怎么办？)
- [10.4 Claude Code 无法连接 Anthropic 服务怎么办？](#10.4 Claude Code 无法连接 Anthropic 服务怎么办？)
- [10.5 Claude 桌面版和 Claude Code Skill 是一回事吗？](#10.5 Claude 桌面版和 Claude Code Skill 是一回事吗？)
[11. 总结：不要蒸馏"人设"，要蒸馏"工作流"](#11. 总结：不要蒸馏“人设”，要蒸馏“工作流”)

1. 为什么我要蒸馏 Mark Russinovich 的排障思维？

在企业级 Windows 桌面运维中，很多问题表面看起来很普通：

用户说电脑越来越慢；
应用启动报错；
Explorer 无响应；
登录后桌面异常；
Office、Outlook、OneDrive、Teams 出现莫名问题；
蓝屏代码一换再换；
权限拒绝但不知道具体拒绝在哪里。

但真正做过一线桌面支持的人都知道，这些问题最难的地方不是"修一下"，而是知道到底该从哪里开始查。

如果没有证据链，很多排障最后都会变成"猜原因、试方法、重装系统"。

而 Mark Russinovich 最值得学习的地方，正是他面对 Windows 问题时的底层思路：

不靠猜，靠证据；不看表象，看系统对象；不只恢复现象，还要定位根因。

这次我使用"女娲 Skill 造人术"的思路，尝试将 Mark Russinovich 的 Windows Internals、Sysinternals、Case of the Unexplained 排障方法，蒸馏成一个可以在 Claude / Claude Code 中使用的 Windows 排障专家 Skill。

这张图适合作为本文的开篇总览：它把 Mark Russinovich 的身份、代表工具、核心语录和关键时间线放在一起。

对于 Windows 运维人员来说，重点不是记住他的履历，而是理解这句话：

When in doubt, run Process Monitor.

也就是：当你不知道问题在哪里时，先让系统自己把真相说出来。

2. 这次蒸馏出来的核心内容是什么？

这次生成的 Skill 名称是：

yaml 复制代码

name: russinovich-perspective

它的定位是：

text 复制代码

Mark Russinovich 的 Windows 桌面运维排障思维框架。
基于 Sysinternals 工具集、Case of the Unexplained 系列演讲、
Pushing the Limits of Windows 博客系列、《Windows Internals》、
《Troubleshooting with the Windows Sysinternals Tools》
及 Sony Rootkit 调查等资料，提炼 Windows 内核级排障方法。

这不是简单写一段"模仿 Mark 的提示词"，而是把他的排障方式拆成几个可复用模块：

核心心智模型
工具选择决策树
排障工作流
表达风格
触发规则
适用边界
工具速查卡

简单说，就是把一个专家的"排障脑回路"整理成可以调用的 Skill。

这张图对应的是 Skill 中最重要的部分：5 个核心心智模型。

我认为其中最适合桌面运维落地的是这几个：

核心模型	对桌面运维的价值
证据优先，假设靠后	不凭经验拍结论，先采集日志、转储、调用栈
系统调用层是真相所在	UI 报错只是表象，文件/注册表/进程操作才是底层事实
资源 / 权限 / 驱动三维检查	大部分 Windows 奇怪问题都能先从这三类收敛
Good vs Bad 对比法	问题机和正常机对比，比单机死磕效率高
安全边界是真相边界	第三方安全软件、EDR、DLP、驱动注入不能只信厂商描述

这里有一个关键点：Skill 的价值不是"让 AI 装成 Mark"，而是让 AI 回答问题时强制走证据链。

3. 女娲 Skill 的使用方法记录

3.1 环境准备

这次我是在 Windows 环境下测试 Claude Code + Skills 工具链。

先检查 Node.js、npm 和 Claude Code 是否可用：

powershell 复制代码

node -v
npm -v
claude --version

我当前环境中检查结果类似：

text 复制代码

v24.15.0
11.12.1
2.1.126 (Claude Code)

如果 node 或 npm 无法识别，说明 Node.js 没有安装或者 PATH 没有生效。

如果 claude 无法识别，说明 Claude Code 没有安装成功，或者安装后没有重新打开 PowerShell。

建议安装完 Node.js、Git、Claude Code 后，关闭当前 PowerShell 窗口，重新打开一个新的管理员 PowerShell 再测试。

3.2 安装女娲 Skill

由于 GitHub 拉取有时会超时，我这次采用的是本地下载方式：

先从 GitHub 下载项目 ZIP；
解压到本地目录；
使用 skills add 从本地目录安装。

我的本地路径是：

text 复制代码

D:\Code\nvwa-main

执行命令：

powershell 复制代码

cd $HOME
npx.cmd --yes skills add "D:\Code\nvwa-main" -a claude-code -g

安装成功后，输出中可以看到类似内容：

text 复制代码

Found 1 skill
Skill: huashu-nuwa
Installation complete
Installed 1 skill
✓ huashu-nuwa
→ ~\.claude\skills\huashu-nuwa

这说明女娲 Skill 已经安装到 Claude Code 的 Skill 目录中。

3.3 本地 Skill 目录在哪里？

安装成功后，Skill 通常会出现在：

powershell 复制代码

$HOME\.claude\skills

也可以直接打开目录：

powershell 复制代码

explorer "$HOME\.claude\skills"

正常情况下可以看到：

text 复制代码

huashu-nuwa
find-skills

其中：

huashu-nuwa 是女娲造人 Skill；
find-skills 是辅助 Claude 发现 Skill 的工具。

Claude Code 的 Skill 和 Claude 桌面版 / 网页版的 Skill 并不是完全同一个入口。如果要在桌面版使用，通常还需要把 Skill 文件夹打包成 ZIP 后上传。

4. 蒸馏 Mark Russinovich Skill 的过程

4.1 明确蒸馏目标

这一步非常关键。

不要一上来就说：

text 复制代码

帮我造一个 Mark Russinovich Skill

这种指令太泛，容易生成传记式内容。

我真正想要的是：

text 复制代码

蒸馏一个 Mark Russinovich 视角的 Windows 桌面运维排障专家 Skill。
重点用于 Windows Internals、Sysinternals、企业桌面支持、蓝屏、挂起、性能、权限、驱动、Explorer、用户配置文件等问题分析。

也就是说，我不是要一个"名人介绍 Skill"，而是要一个工作型 Skill。

好的 Skill 应该服务于具体场景，而不是堆人物资料。

4.2 输入核心素材

我给 Skill 的内容里包含以下方向：

Mark Russinovich 的 Sysinternals 工具体系；
Process Monitor / Process Explorer / Autoruns / ProcDump / PsExec 等工具；
Case of the Unexplained 系列排障风格；
Windows Internals 的系统机制视角；
Sony Rootkit 调查体现出的"系统视图差异"方法；
企业桌面运维中的实际问题场景；
进程挂起、应用崩溃、蓝屏、权限拒绝、系统变慢、启动慢、恶意软件、Shell 异常等排障入口。

这一步的核心是：让女娲知道我要蒸馏的是"可运行的排障方法论"，不是人物百科。

4.3 生成出的 Skill 结构

最后生成的 Skill 大致包含这些模块：

text 复制代码

russinovich-perspective
├── description
├── 使用说明
├── 角色扮演规则
├── 回答工作流
├── 工具选择决策树
├── 身份卡
├── 核心心智模型
├── 决策启发式
├── 表达 DNA
├── 工具速查卡
├── 人物时间线
├── 价值观与反模式
├── 诚实边界
└── 调研来源

其中最实用的不是身份卡，而是：

回答工作流
工具选择决策树
核心心智模型
工具速查卡
反模式

因为这些内容可以直接迁移到日常桌面支持工作中。

4.4 排障工作流设计

生成后的 Skill 中，最核心的工作流是：
收到问题描述
问题类型判断
需要实时数据
已有日志或转储
系统机制问题
批量故障问题
指定工具采集证据
分析已有数据
解释机制并给验证动作
Good vs Bad 对比法
提出根因假设
验证假设
修复操作
复盘沉淀为 SOP / 工单 / 博客

这个流程很适合企业桌面支持，因为它不是直接跳到"解决方案"，而是先问：

这是单机问题还是批量问题？
是当前状态问题还是历史遗留问题？
有没有事件日志、Procmon、Dump、截图？
能不能找到一台正常机器对比？
这是 workaround，还是 root cause fix？

排障最怕的是直接给方案，但没有证据支撑。

5. 工具选择决策树：从症状派遣工具

Skill 里最适合桌面工程师使用的部分，是这个工具选择决策树。

这张图可以作为日常排障时的"第一张速查图"。

比如：

5.1 进程挂起 / 无响应

优先使用：

text 复制代码

Process Explorer

重点看：

Threads；
Wait Reason；
Call Stack；
是否卡在某个 DLL、驱动、同步对象或网络等待上。

如果需要进一步分析，可以用 ProcDump 抓取转储：

cmd 复制代码

procdump -ma -h processname.exe C:\Temp\process_hang.dmp

5.2 应用崩溃 / 报错

优先使用：

text 复制代码

Process Monitor

推荐过滤条件：

text 复制代码

Process Name is 目标进程
Result is not SUCCESS

重点不是从第一行看到最后一行，而是：

从最后一次 FAILED 操作开始，往前倒推。

这比盲扫日志效率高得多。

5.3 权限拒绝 / ACCESS DENIED

优先使用：

text 复制代码

Process Monitor + AccessChk

Process Monitor 先定位：

哪个进程；
哪个路径；
哪个注册表键；
请求了什么权限；
返回了什么拒绝结果。

然后用 AccessChk 验证 ACL：

cmd 复制代码

accesschk.exe -d "C:\目标路径"
accesschk.exe -k "HKLM\Software\目标注册表路径"

不要一看到权限问题就直接"管理员运行"。这只是绕过问题，不是解释问题。

5.4 蓝屏 BSOD

优先使用：

text 复制代码

WinDbg

核心命令：

text 复制代码

!analyze -v
lmv

分析重点：

BugCheck Code；
Probably caused by；
Loaded Module List；
第三方驱动；
驱动时间戳；
是否为安全软件、网卡驱动、存储驱动、显卡驱动相关。

5.5 启动慢 / 登录慢

优先使用：

text 复制代码

Autoruns

重点检查：

Logon；
Services；
Scheduled Tasks；
Drivers；
Explorer；
AppInit；
Winlogon；
Office / OneDrive / Teams 相关启动项。

企业环境中，登录慢经常不是 Windows 本身慢，而是启动项、脚本、GPO、代理、安全软件、网络资源访问共同造成的。

6. Russinovich 式排障工作流如何落地？

这张图把整个排障过程压缩成 5 步：

问题分类；
工具选择；
数据采集；
分析与验证；
修复与总结。

我认为这套流程对桌面支持最有价值的地方是：它把"排障"从经验行为变成了标准动作。

6.1 第一步：问题分类

不要一上来就问"怎么修"。

先判断问题属于哪类：

类型	典型表现	第一动作
实时状态问题	当前卡死、当前慢、当前无法打开	采集当前证据
已有数据问题	有 dmp、日志、截图、错误码	先分析已有证据
系统机制问题	问原理、机制、为什么	解释机制 + 给验证方法
批量问题	多台机器同样异常	找正常机对比

6.2 第二步：工具选择

工具不是越多越好，而是要精准。

Procmon、ProcExp、Autoruns、WinDbg 不是"万能四件套"，而是分别对应不同层级的问题。

例如：

文件/注册表访问异常 → Procmon；
进程、线程、句柄、DLL → Process Explorer；
启动项污染 → Autoruns；
蓝屏和崩溃转储 → WinDbg；
崩溃前抓取现场 → ProcDump。

6.3 第三步：数据采集

建议每次重大排障都保留证据：

text 复制代码

C:\Temp\Troubleshooting\
├── screenshots
├── eventlogs
├── procmon
├── dumps
├── systeminfo
└── notes

可以用 PowerShell 快速创建目录：

powershell 复制代码

$Root = "C:\Temp\Troubleshooting"
New-Item -ItemType Directory -Force -Path `
"$Root\screenshots", `
"$Root\eventlogs", `
"$Root\procmon", `
"$Root\dumps", `
"$Root\systeminfo", `
"$Root\notes"

6.4 第四步：分析与验证

分析时不要直接写结论，而是写成：

text 复制代码

现象：
证据：
假设：
验证动作：
验证结果：
结论：

例如：

text 复制代码

现象：用户反馈登录后桌面图标加载缓慢。
证据：Procmon 显示 explorer.exe 反复访问网络路径超时。
假设：桌面路径或快捷方式指向不可达网络资源。
验证动作：新建本地用户测试；断开网络路径；清理无效快捷方式。
验证结果：清理后登录时间恢复正常。
结论：根因不是 Explorer 本身损坏，而是桌面资源解析超时。

6.5 第五步：修复与总结

修复要区分三种层级：

层级	说明
临时恢复	先让用户能继续办公
根因修复	找到具体对象并修复
预防复发	写入 SOP、脚本、镜像标准或培训材料

真正有价值的桌面支持，不只是"修好了"，而是"下次不用再猜了"。

7. Sysinternals 工具速查卡

这张图适合作为文章后半部分的总结图，也适合后续放到《Sysinternals 实战教程》专栏中反复引用。

下面是我整理后的工具定位：

工具	核心用途	适合场景
Process Monitor	文件、注册表、进程、网络调用监控	安装失败、权限拒绝、应用异常
Process Explorer	进程、线程、DLL、句柄、资源查看	卡死、高 CPU、高内存、句柄泄漏
Autoruns	自启动入口审查	登录慢、启动慢、恶意启动项
WinDbg	转储与蓝屏分析	BSOD、应用崩溃、内核调试
ProcDump	自动抓取转储	崩溃、挂起、异常退出
PsExec	远程执行命令	批量处理、远程排障
TCPView	进程端口映射	网络连接异常
VMMap	虚拟内存分析	内存占用异常
PoolMon	内核池泄漏分析	非分页池增长
AccessChk	权限检查	文件、注册表、服务 ACL 验证

工具不是目的，理解才是。工具只是帮我们看清系统在说什么。

8. 生成后的 Skill 应该怎么使用？

8.1 直接触发方式

在 Claude / Claude Code 中，可以这样触发：

text 复制代码

用 Russinovich 的思路帮我分析这个蓝屏问题。

或者：

text 复制代码

Mark 会怎么排查这个 ACCESS DENIED？

或者：

text 复制代码

用 Sysinternals 思路帮我分析这个进程为什么挂起。

也可以更贴近桌面支持场景：

text 复制代码

用户反馈登录后桌面很慢，用 Russinovich 的证据链排障方式帮我分析。

8.2 适合输入的信息

为了让 Skill 输出更准确，建议提供以下信息：

text 复制代码

1. 问题现象：
2. 触发条件：
3. 影响范围：
4. 系统版本：
5. 最近变更：
6. 已尝试动作：
7. 现有证据：
8. 希望输出格式：

例如：

text 复制代码

问题现象：用户电脑登录后 Explorer 无响应 2 分钟。
触发条件：每次域账号登录都会出现。
影响范围：目前只发现 1 台。
系统版本：Windows 11 23H2。
最近变更：安装过 DLP 客户端。
已有证据：事件查看器有 Application Hang，Procmon 还没抓。
请用 Russinovich 思路给我排查路径。

8.3 期望它输出什么？

一个好的 Russinovich 风格回答，不应该只有：

text 复制代码

可能是系统异常，建议重启或重装。

而应该输出：

text 复制代码

1. 当前现象判断
2. 需要采集哪些证据
3. 用哪个工具采集
4. 怎么过滤
5. 看到什么结果代表哪个方向
6. 如何验证根因
7. 临时恢复方案
8. 根因修复方案
9. 如何写入工单或 SOP

如果 Skill 给出的回答没有证据链，那说明这个 Skill 还没有调好。

9. 我的实战理解：这类 Skill 真正的价值是什么？

这次蒸馏让我有一个很明显的感受：

AI Skill 不是简单"角色扮演"，而是把一套稳定的专家工作流固化下来。

如果只是让 AI 模仿某个人说话，价值很有限。

真正有用的是让 AI 形成固定的判断路径：
用户描述问题
翻译成系统对象
选择合适工具
采集证据
提出假设
设计验证动作
修复与沉淀

在 Windows 桌面支持场景中，这种 Skill 可以帮助我做几件事：

9.1 用于现场排障

比如遇到：

蓝屏；
应用卡死；
Explorer 异常；
Office 报错；
OneDrive 同步异常；
域账号登录慢；
权限拒绝；
驱动冲突。

它可以帮我先搭好排查框架。

9.2 用于工单复盘

处理完问题后，可以让它帮我整理成：

text 复制代码

问题现象：
影响范围：
排查过程：
关键证据：
处理动作：
验证结果：
后续建议：

这样工单就不会只写一句：

text 复制代码

已处理，恢复正常。

而是能沉淀成可复用经验。

9.3 用于 SOP 编写

如果某类问题重复出现，就可以进一步整理成 SOP：

text 复制代码

适用场景
前置条件
排查步骤
判断标准
修复动作
回退方案
注意事项

这才是桌面支持从"救火"走向"标准化"的关键。

9.4 用于 CSDN 博客写作

对于技术博客来说，这类 Skill 也很有价值。

因为它能帮文章避免只写：

text 复制代码

第一步打开工具，第二步点击按钮，第三步完成。

而是写成：

text 复制代码

为什么要用这个工具？
它观察的是系统哪一层？
从结果中怎么看出异常？
这个问题如何复盘成通用排障方法？

这会让博客从普通教程变成真正有技术深度的经验文章。

10. 常见问题与踩坑记录

10.1 GitHub 克隆超时怎么办？

如果执行：

powershell 复制代码

npx.cmd --yes skills add YJlio/nvwa -a claude-code -g

出现：

text 复制代码

Clone timed out after 300s

可以改用本地下载 ZIP 的方式。

操作流程：

text 复制代码

GitHub 下载 ZIP
↓
解压到 D:\Code\nvwa-main
↓
执行本地安装命令

命令：

powershell 复制代码

npx.cmd --yes skills add "D:\Code\nvwa-main" -a claude-code -g

10.2 提示 spawn git ENOENT 怎么办？

这个错误表示当前环境找不到 Git。

先检查：

powershell 复制代码

git --version
where.exe git

如果没有输出，需要安装 Git for Windows。

如果已经安装但仍然报错，重新打开 PowerShell，或者检查 PATH 是否包含：

text 复制代码

C:\Program Files\Git\cmd

10.3 npm.ps1 被执行策略拦截怎么办？

如果出现：

text 复制代码

无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本

可以临时使用：

powershell 复制代码

npm.cmd -v
npx.cmd --version

也可以调整当前用户执行策略：

powershell 复制代码

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

企业环境中执行策略可能由组策略控制，修改前要注意合规要求。

10.4 Claude Code 无法连接 Anthropic 服务怎么办？

如果出现：

text 复制代码

Unable to connect to Anthropic services
Failed to connect to api.anthropic.com

说明本地 CLI 已安装，但服务连接不可用。

这种情况下可以区分两件事：

项目	状态
Claude Code 是否安装成功	看 `claude --version`
Skill 是否安装成功	看 `$HOME\.claude\skills`
Claude 服务是否可用	看是否能正常登录和连接
Skill 是否能实际运行	取决于 Claude Code 是否能连接服务

也就是说，Skill 安装成功不等于 Claude Code 一定能联网运行。

10.5 Claude 桌面版和 Claude Code Skill 是一回事吗？

不是完全一回事。

项目	用途	Skill 使用方式
Claude Code	命令行 Agent、本地项目操作	`%USERPROFILE%\.claude\skills`
Claude 桌面版 / 网页版	聊天、写作、上传文件	通常需要在 Customize → Skills 上传 ZIP
本地下载的 Skill	可安装到 Claude Code	桌面版可能需要单独打包上传

如果想把本地 Skill 上传到 Claude 桌面版，可以打包：

powershell 复制代码

Compress-Archive -Path "$HOME\.claude\skills\huashu-nuwa" -DestinationPath "$HOME\Desktop\huashu-nuwa.zip" -Force

然后在 Claude 客户端中：

text 复制代码

Customize → Skills → Upload skill

11. 总结：不要蒸馏"人设"，要蒸馏"工作流"

这次使用女娲蒸馏 Mark Russinovich Skill，我最大的收获是：

真正有价值的 Skill，不是让 AI 像某个人说话，而是让 AI 按某个专家的稳定方法做事。

对于 Mark Russinovich 这个方向来说，最值得保留的不是"微软 Azure CTO"这个头衔，而是他对 Windows 问题的一套稳定排障逻辑：

把用户描述翻译成系统对象；
固定问题边界；
选择合适的 Sysinternals 工具；
收集可观测证据；
从第一个异常点逆向分析；
区分 workaround 和 root cause；
把结果沉淀成工单、SOP 和博客。

用一句话总结：

Windows 没有玄学，只有还没被看见的数据。

对桌面支持工程师来说，这类 Skill 的意义不是替代你排障，而是帮你避免在没有证据的情况下乱猜。

如果一个问题没有证据链，再像专家的回答也只是包装过的猜测。

🔝 返回顶部

点击回到顶部

复制代码