线上有一台Linux机器突然进程卡死、CPU打满你第一时间会做什么大部分人就是top看负载然后赶紧抓调用栈。调用栈这东西抓是一回事读是另一回事——几十个线程的栈堆在终端里互相嵌套锁的持有关系要人肉理清稍微复杂一点就得盯半天。我前阵子把Claude Code引入了这个流程做了个叫pstack-claude的实践项目让AI编码助手直接吃栈输出、给诊断结论效率和准确率都提升了一大截。这篇文章就把这套工作流的完整玩法、工具选型、提示词设计和踩过的坑全盘写出来适合做后端、SRE、平台开发的读者也适合那些想用Claude Code提升日常排查效率但对AI工具还不太熟的人。1. pstack-claude到底是做什么的把“读调用栈”这件事交给AI编码助手1.1 一个经常发生在凌晨的诊断场景先说个我在项目里反复遇到的场景凌晨两点监控弹出来说某个服务请求延迟飙升CPU倒是正常。我ssh上去之后top看到20个线程里有几个状态是D或者S但看不出问题。传统做法是先ps -L -p PID拿到所有线程号然后手动挑几个可疑线程用gdb附加去看bt。运气好的话一眼就能看到某个线程卡在锁上运气不好十几个线程全在锁上等待就得画图理清谁持有谁、谁等谁。这个梳理过程非常耗时因为调用栈的文本其实信息密度很高但不直观。一次线上问题从抓栈到定位根因花20到40分钟是常态其中一多半时间不是在“找”问题而是在“翻译”栈帧。pstack-claude的出发点很简单把“翻译栈帧模式识别”这一步交给Claude Code人来负责判断和验证。1.2 为什么“AI读栈”是真的能落地而不是噱头我一开始也怀疑过AI读代码写代码是一回事读调用栈是另一回事。但实际用下来发现调用栈反而是AI特别擅长处理的输入。原因有三点调用栈是文本而且结构非常规律每一帧的函数名、偏移、文件行号都在AI不需要理解线上环境就能做模式识别。死锁、锁顺序反转、线程池耗尽、阻塞IO这几类经典问题在栈上都有非常固定的“形态”。比如两个线程互相等待栈上必然出现双向的锁等待关系这种模式人眼要扫半天AI几秒钟就能列出来。Claude Code跑在终端里可以直接读取我采集好的栈文件也可以直接跑命令重新抓一次整个对话过程比把文本复制到Web聊天框要顺滑得多。说白了pstack-claude不是一个多高深的算法项目它是一套“人机协作的故障诊断工作流”。人要做的三件事采集栈、给背景、复验结论。剩下大量体力活交给AI。1.3 这套工作流适合谁、不适合谁如果你的日常工作涉及Linux进程异常排查比如服务卡死、线程阻塞、内存异常、性能热点分析那这套工作流几乎可以直接照搬。但要注意它对基础能力有最低要求至少得看得懂top和ps的输出知道线程号和进程号的区别否则AI给你的诊断结论你也无从验证。反过来如果你是刚接触Linux的新手我建议先别急着上AI。先把gdb的基本操作、线程栈的阅读方法练出来再用Claude Code做辅助。原因很简单AI的结论需要人复核你如果连栈都读不利索就失去了最后一道防线。pstack-claude是放大你的排查能力不是替代你的排查能力。2. 先把Claude Code装进终端安装、VSCode与WSL环境适配2.1 Claude Code的安装路径选择装了这么多次我推荐的路径就两种。第一种是npm全局安装适合已经用Node生态的开发者npm install -g anthropic-ai/claude-code claude --version装完直接在你想要分析的项目目录下执行claude就能启动一个交互式终端。之所以推荐npm方式是因为后续升级方便claude自身支持在线更新你不需要手动管版本。第二种是官方提供的curl管道脚本安装适合不想装Node的机器。但我要提醒一点curl管道脚本对目录权限要求更敏感装完很容易遇到我后面要讲的npm prefix权限报错所以我自己在开发机上一直用npm方式只有在一次性容器或临时环境里才用脚本方式。容器场景也可以直接拉官方镜像anthropic/claude-code进去就是现成环境适合做CI集成但不适合日常调试因为容器里通常没有对应服务的完整运行环境。2.2 在VSCode和WSL里跑起来的关键设置我日常是在Windows上写代码、在WSL里跑Linux服务所以Claude Code的安装要落在WSL的Linux一侧而不是Windows侧。操作上没什么玄机在WSL终端里执行npm安装然后确认claude命令在PATH里。真正容易忽略的是Windows Terminal默认打开的是Windows侧的PATH如果你在WSL里装完发现claude找不到先检查你打开的终端是不是WSL会话而不是PowerShell。VSCode场景我建议装官方的Claude Code扩展然后在集成终端里启动claude。这样做的最大好处是Claude Code能直接感知你当前打开的项目结构你让它“看看worker.c的第42行”它能直接定位文件并读出来上下文是连续的。我的经验是不要在VSCode的GUI输入框里跟它长篇对话而是把集成终端当作主交互界面用命令行方式处理响应更干净也方便保留历史。另外提一句Windows上的一个环境依赖部分Claude桌面组件在Windows上运行需要开启“虚拟机平台”功能出现相关提示时去“启用或关闭Windows功能”里勾上虚拟机平台和适用于Linux的Windows子系统重启就好。这个跟WSL的底层虚拟化是同一套依赖开发环境建议提前确认好状态别等装完再折腾。2.3 最常见的安装后报错npm prefix权限问题装完Claude Code以后我最常被问到的问题是更新时报错Auto-update failed: no write permission to npm prefix这个错的意思是npm的全局安装目录对当前用户没有写权限Claude Code想在线更新自己结果写不进去。排查链路非常简单npm config get prefix如果输出的路径在/usr/local或者系统目录下面基本就是root创建的目录。最简单的办法是切换到nvm管理Nodenvm会把prefix指向用户目录之后重装Claude Code就不会有这个问题。如果你不想动Node管理方式也可以直接把当前用户变成npm全局目录的属主sudo chown -R $(whoami) $(npm config get prefix)/lib/node_modules不过这个操作只建议在单用户开发机上做多用户机器上还是用nvm隔离更干净。这里多说一句这个报错不是Claude Code的bug而是npm全局安装的通用权限问题你装任何全局CLI工具都可能碰到所以排查思路可以复用。3. 栈从哪来pstack命令的现状和更可靠的采集工具链3.1 传统pstack命令正在被替代既然项目叫pstack-claude很多人以为我会靠传统pstack命令抓栈。实际用过就知道传统pstack在这套工作流里是可有可无的。它的原理是调用gdb底层能力打印指定进程的栈信息但在很多现代Linux发行版里并没有预装需要自己装gdb后才能用。而且它对Java进程、Python进程的支持很差对高并发多线程进程的栈输出也经常缺线程信息抓一次还可能让被附加的进程短暂停顿。所以我现在的态度是pstack适合“快速瞄一眼”不适合“完整诊断”。真要让我拿一份稳定的栈文件去喂AI我宁可优先用下面几个工具它们的输出更规整、符号解析更完整AI读起来也不容易误判。3.2 用一张表选对抓栈工具工具适用场景优点常见坑pstack快速查看单个进程粗略栈命令简单免gdb语法部分发行版未预装线程支持弱输出不全gdbC/C/Go等多线程程序完整栈功能最强可批量打所有线程栈附加进程有短暂停顿生产环境低峰期用eu-stack轻量抓栈依赖少来自elfutils输出干净适合批量对某些动态库符号解析弱需要符号文件py-spyPython进程无侵入抓栈不用改代码不需要重启服务有权限要求D状态进程可能抓不到实际选择上我会先判断进程类型。C/C服务优先gdb -p PID -batch -ex thread apply all btPython服务优先py-spy dump --pid PID如果是混着用的服务就两种都抓让Claude Code对着两份栈对比着看。不要一上来就用pstack它的输出拿到AI面前经常因为缺符号而让AI瞎猜。3.3 我日常使用的采集脚本为了让整套流程可复现我写了一个简单的采集脚本放在项目目录的tools/下。它会按PID抓取所有线程栈并保存带时间戳的文件避免现场被覆盖#!/usr/bin/env bash PID$1 OUT_DIR${2:-/tmp/stack_dump} mkdir -p $OUT_DIR TS$(date %Y%m%d_%H%M%S) # 通用多线程栈 gdb -p $PID -batch -ex thread apply all bt $OUT_DIR/${TS}_gdb.txt 21 # Python进程附加分析 if command -v py-spy /dev/null py-spy top --pid $PID /dev/null 21; then py-spy dump --pid $PID $OUT_DIR/${TS}_pyspy.txt 21 fi ls -lh $OUT_DIR/${TS}_*用的时候直接bash tools/stack_dump.sh PID。这里有两个心得第一抓之前先top -H -p PID看哪个线程CPU最高把这个线程号记下来后面在栈文件里按线程号定位效率能翻倍第二生产环境抓栈尽量放在低峰期因为gdb附加会让进程短暂停顿千万不要在用