目录它怎么认出崩溃、整理现场实测三段崩溃三份现场不止是命令崩溃写在最后让 AI 跑一遍测试或者把服务启动起来结果程序崩了。这时候最常见的动作是把终端里那一大段报错选中、复制、贴回对话框再问一句「这是怎么回事」。在 WES Code 里这一步可以省掉。AI 跑的命令一崩溃它就会认出来截出崩溃的那一段解析出调用栈存进调试记录。你下一次发消息时这份现场会整理好附在消息里一起交给 AI。它怎么认出崩溃、整理现场它看的是 AI 用 exec 跑出来的输出。退出码为 0 的、太短的输出直接跳过这样不会在 ls、grep 这类普通输出上白跑一遍正则。剩下的按这几种特征去认语言认的是什么Gopanic:或者goroutine 1 [running]:这样的行PythonTraceback (most recent call last):JavaScript / TypeScript一行TypeError:这类报错下一行以at开头JavaException in thread main这样的行Rustthread main panicked atRubyapp.rb:12:in这样「文件名、行号、in」的行认出来以后整理成一份现场。认出是哪种语言以后它会做三件事截出崩溃的那一段从崩溃开始的那一行往下截最多 50 行前面无关的输出不要解析调用栈Go、Python、JS 的输出逐帧解析出函数名、文件和行号最多 20 帧存进调试记录最多保留最近 50 条只放在内存里不写进数据库你下一次发消息时它会取出最近的一份现场整理成一个debug-exception块附在消息里前面是调用栈最多 15 帧后面是原始输出最多 2000 个字符。如果现场来自编辑器的调试器还会带上崩溃点的变量值。这份现场取出来就清掉不会每条消息都重复附一遍。实测三段崩溃三份现场我把 WES Code 里识别和整理崩溃的那几个函数原样复制出来按它处理的顺序写了个测试先认语言再截现场、解析调用栈最后整理成交给 AI 的那个块。三段输出分别模拟 Go 的数组越界、Python 的除零、Node 读取 undefined 的属性// 照 crashDetectHook → HandleCrashReport → GetPendingDebugOverlay 的顺序处理三段崩溃输出funcTestZZCrashDemo(t*testing.T){samples:[]struct{name,outstring}{{Go,Exit code: 2\npanic: runtime error: index out of range [3] with length 3\n\ngoroutine 1 [running]:\nmain.pick(...)\n\t/home/dev/shop/cart.go:42\nmain.main()\n\t/home/dev/shop/main.go:18 0x1d\nexit status 2},{Python,Exit code: 1\nTraceback (most recent call last):\n File \/home/dev/shop/app.py\, line 27, in module\n main()\n File \/home/dev/shop/app.py\, line 21, in main\n total price / qty\nZeroDivisionError: division by zero},{Node,Exit code: 1\nTypeError: Cannot read properties of undefined (reading id)\n at render (/home/dev/shop/src/cart.js:12:18)\n at main (/home/dev/shop/src/index.js:5:3)},}for_,s:rangesamples{lang,ok:DetectCrash(s.out)section:ExtractCrashSection(s.out,lang)ev:DebugEvent{Kind:crash,Source:exec,CrashText:truncateCrash(section,5000),Language:lang,Frames:parseCrashFrames(section,lang)}fmt.Printf( %s识别为崩溃 %v语言 %s解析出 %d 帧调用栈\n%s\n\n,s.name,ok,lang,len(ev.Frames),FormatCrashOverlay(ev))}// 后台服务的日志照 ScanLogErrors 逐行扫log:starting server on :3000\nlisten tcp :3000: bind: address already in use\nWARN cache miss\nSegmentation fault (core dumped)\nError: Cannot find module express\ndial tcp: connection refusedfmt.Println( 服务日志)for_,m:rangeScanLogErrors(log){fmt.Printf([%s] %s: %s\n,m.Level,m.Pattern,m.Line)}}三段崩溃的输出 Go识别为崩溃 true语言 go解析出 2 帧调用栈 debug-exception Stack trace: /home/dev/shop/cart.go:42 — main.pick(...) /home/dev/shop/main.go:18 — main.main() Output: panic: runtime error: index out of range [3] with length 3 goroutine 1 [running]: main.pick(...) /home/dev/shop/cart.go:42 main.main() /home/dev/shop/main.go:18 0x1d exit status 2 /debug-exception Python识别为崩溃 true语言 python解析出 2 帧调用栈 debug-exception Stack trace: /home/dev/shop/app.py:27 — module /home/dev/shop/app.py:21 — main Output: Traceback (most recent call last): File /home/dev/shop/app.py, line 27, in module main() File /home/dev/shop/app.py, line 21, in main total price / qty ZeroDivisionError: division by zero /debug-exception Node识别为崩溃 true语言 javascript解析出 2 帧调用栈 debug-exception Stack trace: /home/dev/shop/src/cart.js:12 — render /home/dev/shop/src/index.js:5 — main Output: TypeError: Cannot read properties of undefined (reading id) at render (/home/dev/shop/src/cart.js:12:18) at main (/home/dev/shop/src/index.js:5:3) /debug-exception三段都认对了语言各解析出 2 帧调用栈。AI 拿到这份现场第一眼就能看到 Go 那段崩在 cart.go 第 42 行的 pick 函数里不用再去一长串输出里找。有了文件和行号AI 的下一步就很明确直接打开 cart.go读 pick 函数看下标为什么会到 3Python 那段就去看 app.py 第 21 行的total price / qty查 qty 是从哪里来的、为什么会是 0。调用栈越清楚AI 越不用靠猜。不止是命令崩溃调试记录还有几个来源最后都走同一条路交给 AI后台服务的日志AI 在后台启动的服务它去查看输出时会逐行按 12 条规则扫一遍日志比如 ERROR、FATAL、段错误、内存不足、端口被占用、模块找不到、连接被拒AI 在终端里启动的服务最近 60 秒内终端里报的错最多 5 条会附在你的下一条消息里测试失败失败的测试名、文件、行号和报错会整理成一个debug-test-failure块编辑器的调试器调试时抛出的异常、命中的断点也会记进调试记录上面那段测试的最后扫了一段模拟的服务日志结果是这样的[error] address_in_use: listen tcp :3000: bind: address already in use [crash] segfault: Segmentation fault (core dumped) [error] error_keyword: Error: Cannot find module express [warning] connection_refused: dial tcp: connection refused普通的WARN cache miss不会被当成异常段错误则被标成了最严重的 crash 级别。需要更多细节时AI 还可以打开 debug 这组工具自己去查最近的调试记录和调用栈。写在最后程序崩溃时最有用的信息往往就在那几十行里崩在哪个文件的哪一行中间经过了哪些函数。这件事 WES Code 替你做了自动把这几十行找出来、整理好在你开口的时候一起交给 AI。你只需要说一句「看看为什么崩了」。文中的崩溃识别是 WES Code 里的功能官网是 weisyn.com。你平时排查崩溃最先看的是调用栈还是日志欢迎评论区聊聊。觉得有用的朋友欢迎点赞、收藏、关注后面会继续分享 AI 编程的实战经验。
