在这次之前，我对"运维"两个字几乎没有概念——网页是怎么跑起来的、请求是怎么从浏览器走到服务器又走回来的，我说不清楚。这次要解决的问题偏偏还不简单：把一个桌面客户端搬到网页上跑，结果打开慢，一堆功能起不来。整个排查过程，与其说是我在查问题，不如说是 AI 牵着我的手，一步步带我认识这些从没接触过的东西。

从零开始

一开始我完全不知道从哪下手。AI 给我的第一课很简单：遇到"打开慢"，先看网络请求。 它教我打开浏览器的开发者工具，找到 Network 面板，然后一步步告诉我该看哪一列——哪个请求卡在了 pending，哪个直接标红显示超时。

对我来说，这是第一次直观地"看见"一个网页背后到底在跟谁说话。以前网页对我而言就是打开就能用的黑箱，这一刻我才第一次意识到，一个页面加载的过程，其实是无数个请求在后台悄悄跑，任何一个卡住了都会拖累整体。

跟着这份日志看下去，能看到两类请求：一类是加载页面本身和静态资源的，都正常；另一类是访问后端服务的，反复超时。这一步没有直接给我答案，但 AI 告诉我这已经是进展——范围从"某个功能坏了"缩小到了"启动阶段，和后端通信的这一批请求不对劲"。 对一个完全没有运维经验的人来说，这种"把问题从模糊变清晰"的过程，本身就是一堂课。

深入

浏览器里能看到的东西是有限的，只知道"卡住了"，不知道"为什么卡住"。AI 接下来带我往更深的地方走——命令行。

它教我用 curl 直接对着后端接口发一次同样的请求，看看单独发这一次会不会也超时；又教我在前端和后端分别挂上抓包工具，让两边同时记录同一次请求各自看到了什么：

# 单独复现一次请求，观察是否超时
curl -v -m 10 https://internal-api.example.com/mcp/status

# 前后端各挂一份抓包，对照同一次请求
tcpdump -i lo -A 'port 8787' -w capture.pcap

这一段对我来说是真正的"深渊"——命令行、抓包、端口，每一个词我都要现学。但正是把前后端的日志摆在一起对照，才第一次让我明白："网络问题"经常不是网络本身的问题，而是某一端根本没把正确的东西发出去。我们发现，前端确实发出了请求，但请求里带的一个参数，在网页环境下解析出来居然是空的——而这个参数在桌面客户端里，本来是一个写死的本地路径。

接触

顺着这条线索，AI 带我第一次真正打开了源代码去看。说实话，在这之前我从没自己读过别人的项目代码，更别说去改。它带我找到了资源加载相关的那部分逻辑，指给我看问题出在哪一行：

- const iconPath = "/Users/dev/app/assets/icon.png";
+ const iconPath = new URL("./assets/icon.png", import.meta.url).pathname;

它解释给我听：桌面客户端可以假设自己独占一整台电脑、路径永远长这样；但网页环境完全不能这么假设，尤其我们这套服务还部署在一层子路径的反向代理后面，任何写死的绝对路径到了这里都会直接失效。

对我来说，这是整个排查里最有成就感的一刻——不是因为这行代码本身有多难，而是我第一次真正从"看日志"走到了"读代码、理解代码为什么会这样写"。这种带着我一层层往下走的过程，比单纯告诉我答案要有价值得多。

暂时结束

问题修完之后，AI 也很坦诚地告诉我：不是所有的兼容性问题都能修平。桌面客户端能直接碰本地文件系统、能调系统级的通知和剪贴板，这些在浏览器的安全规则下要么根本不存在，要么需要用户额外点一下授权，没办法做到和桌面端一模一样。这部分它没有硬修，而是找了个够用的绕行方案。

回头看这整个过程，我学到的其实不只是怎么修好这一个 bug。是从完全不懂"网页怎么跑起来"，到能看懂网络日志、会用命令行控制变量、甚至能读一点点源代码——这条路是 AI 一步一步带我走完的。对一个运维小白来说，这大概是这次经历里最珍贵的部分。