上周三下午，Cursor 的风扇毫无征兆地起飞，活动监视器里那个扩展宿主进程一路顶到 100% 单核，紧接着右侧 AI 对话框开始输入延迟、流式输出一卡一卡，回车之后光标要愣两秒才动。标题里这几个关键词——cursor cpu100%、AI 对话框卡顿、Codex、TaoToken、bookmarks 插件——说的就是这一整条故障链：表面上是 AI 聊天卡，实际是 bookmarks 插件在后台把扩展宿主线程占满，AI 对话框只是被殃及的受害者。这篇把我从"怀疑模型服务"到"定位到插件某一行逻辑"的全过程写清楚，包括怎么用 Codex 走 TaoToken 令牌网关把请求侧变成可控变量、怎么做扩展二分、怎么算清楚插件到底吃掉了多少 CPU。适合正在用 Cursor 或同类编辑器、装了十几个扩展、又被 AI 面板卡顿折磨的同学参考，小白也能照着步骤一步步排查。

1. 三个症状同时出现，先别急着怪模型

1.1 把时间线对齐：卡顿到底发生在哪一秒

很多人一看到 AI 对话框卡，第一反应是"模型服务慢了"或者"网络不行"。这个判断在纯聊天场景下没错，但在编辑器里，AI 面板只是整个应用的一个视图层，它和编辑器主界面、扩展宿主、文件监听共享同一台机器的 CPU 和同一套进程间通信通道。我这台机器上出现的三个症状是同时的：风扇转速上来、AI 输入框掉帧、编辑器里滚动代码也有轻微粘滞。三个症状同时出现，基本可以排除"单一服务慢"这个假设，因为网络慢不会让本地滚动掉帧。

真正有价值的动作是记时间线。我当时拿手机掐了个表，记录了几个关键节点：打开项目后约 40 秒 CPU 开始爬升；在编辑器里保存任意一个文件，CPU 会有一个明显尖峰；在 AI 对话框里连续打字，每敲三四个字符卡一次，卡顿周期和 CPU 尖峰周期对得上。这三条记录拼起来，指向的是"某个东西在响应文件变化"，而不是"某个请求在等响应"。

这里有个反直觉的点：AI 对话框的输入框卡顿，往往不是 AI 逻辑本身的问题。你在输入框里打字，字符要先经过渲染进程的输入处理，再经过一层状态同步。如果扩展宿主正在满负荷跑同步任务，主线程调度会被挤压，输入事件的排队时间就会肉眼可见地变长。所以"AI 对话框卡"这个现象，只能说明渲染链路被拖慢，不能说明 AI 请求出了问题。这个区分很关键，它决定了你接下来是去查网络还是查本地进程。

1.2 为什么我第一反应是扩展宿主而不是 AI 服务

判断依据其实很朴素：如果 AI 服务响应慢，症状应该是"发出请求后等待时间长、收到响应后渲染很快"；如果是本地算力被占，症状是"输入卡、滚动卡、菜单弹出卡"。前者是等待型卡顿，后者是算力型卡顿。我这台机器明显是后者——鼠标划过菜单都有延迟，这跟远端服务一点关系都没有。

再补一个佐证：把 AI 面板关掉，只用编辑器，CPU 依然在 90% 上下。这一步基本就把 AI 相关模块从嫌疑人名单里划掉了。剩下能吃掉这么多 CPU 的只有三类东西：文件索引、语言服务、扩展宿主里跑的自定义逻辑。前两类在 Cursor 这类编辑器里通常有配额和节流，不太可能长时间贴着 100%，剩下的嫌疑就集中到扩展上。

顺便说一句，我见过不少人把这类问题归因到"编辑器本身太重"。编辑器确实重，但它重得比较均匀，不会出现"空闲时 5%、打开某类文件突然 100%"这种阶跃式变化。阶跃式变化几乎总是某个具体逻辑被触发了，而触发源通常是文件事件。

1.3 复现环境与观测口径

为了让后面的数字有意义，先把观测口径交代清楚。测试机是一台四核八线程的笔记本，内存 32GB，项目工作区大约 12 万个文件（含依赖目录），其中源码文件约 4000 个。CPU 百分比我统一按"单核占满 = 100%"来记录，这样和进程监视器里的数字能对上；换算到整机占用的话，四核机器上单核 100% 大约是整机 25%，这也就解释了为什么一个进程跑满，整台机器就有明显体感。

扩展清单大约 20 个，其中和本次相关的是一款 bookmarks 扩展（下文统一叫它"书签插件"，扩展 ID 我用xxx.bookmarks这种占位写法，你替换成自己装的就行）。书签数据文件是一个约 3.8MB 的 JSON，里面大概 6000 条记录，每条包含标题、URL、分组路径、创建时间、标签数组。

复现步骤固定为三条，后面所有实验都用这三条：冷启动打开工作区并静置 90 秒；在编辑器里连续保存同一个文件 20 次；在 AI 对话框连续输入 200 个字符。这三条分别对应空闲态、文件事件态、交互态，能覆盖绝大多数场景。

2. 三条链路分开测：渲染、扩展宿主、模型请求

2.1 链路拆解与责任切分

在动手之前，我先在纸上把整条链路拆成三段。第一段是渲染：输入框、代码区、侧边栏，跑在渲染进程里，负责画界面。第二段是扩展宿主：所有第三方扩展跑在这里，负责扫描文件、维护书签索引、提供命令。第三段是模型请求：从编辑器发出请求、经过网关、拿到流式响应、逐段渲染到面板。三段之间靠进程间通信串起来，任何一段堵住，下游都会排队。

拆完就能看出一个关键结论：如果第二段堵了，第一段和第三段都会表现出"卡"，但第三段的"卡"是假象——请求可能早就返回了，只是渲染不出来。这一点决定了排查顺序：先测本地两段，再测远端一段。顺序反了，你会在网络抓包上浪费一整天。

我把这个顺序固化成一个检查清单，每遇到类似问题就照着走一遍，从下往上，不跳步：

这张表的价值在于，它能让你在五分钟内把责任范围从"整台机器"缩到"某一个进程"，再缩到"某一个扩展"。

2.2 进程级采样：三分钟锁定嫌疑进程

进程采样的命令很基础，但很多人只盯着任务管理器看总量，不看分进程。分进程看才有意义。

macOS 和 Linux 上用这条，按 CPU 倒序：

ps -Ao pid,pcpu,pmem,comm -r | head -n 15

Windows 上用 PowerShell：

Get-Process | Sort-Object CPU -Descending | Select-Object -First 15 Id,ProcessName,CPU,WorkingSet

跑出来的结果里，你会看到若干个名字相近的进程，比如主进程、渲染进程、扩展宿主、语言服务。我当时看到的是一条明显的"独苗"：名为扩展宿主的进程，CPU 长期在 95% 到 105% 之间波动，其他进程都在个位数。这一下就把范围收窄到扩展了。

再看一眼前面的链路拆解：扩展宿主跑的是所有第三方扩展，所以下一步就是在这 20 个扩展里找元凶。另外提醒一句，任务管理器里那个"总 CPU"数字经常误导人，因为它是所有核心的平均值，一个进程跑满单核，在八核机器上只显示 12%，看起来"不高"，但体感已经很卡了。看单核占用，别看平均值。

编辑器自己也有观测入口。命令面板里搜 "Developer: Open Process Explorer"，会弹出一个进程树，每个进程占多少 CPU、多少内存一目了然。这个面板的好处是它会带上扩展名，省得你自己去对 PID。另一个入口是 "Extensions: Show Running Extensions"，它会列出每个扩展的激活耗时和当前状态，激活耗时长的那几个往往就是重灾区。

2.3 扩展二分：从全禁用到逐个开启

确认是扩展问题之后，别急着一个个禁用。用二分法，20 个扩展大概三四轮就能定位。

第一步做对照实验，用禁用全部扩展的方式启动一个工作区副本：

cursor --disable-extensions /path/to/project-copy

这一步的目的是拿到一个"干净基线"。如果干净基线下 CPU 回落到正常水平，就确认了扩展是主因；如果还是高，那就得怀疑工作区本身有问题，比如某个超大文件被索引了，或者语言服务在反复解析。我这次是干净基线下 CPU 直接掉到 6%，问题定性完成。

第二步才是二分。把 20 个扩展分成两组，先禁一半，看 CPU 是否回落。回落了就说明问题在当前这一半，继续二分；没回落就说明在另一半。这个过程的命令行写法是这样的，可以一次禁多个：

cursor --disable-extension xxx.bookmarks --disable-extension yyy.other /path/to/project-copy

第三轮我就锁定了书签插件。这里有个细节值得说：二进制搜索不要以"功能是否看起来重"为标准分组，要以"是否监听文件"为标准。监听文件的扩展是高危组，包括书签、待办、笔记、代码片段管理这一类；纯展示型的扩展是低危组。按这个标准分组，往往第一轮就命中。

还有一种更省事的办法，如果编辑器支持"按工作区启用扩展"，可以直接在工作区级别把可疑扩展关掉，改settings.json就行。我一般会先做这个，因为它不改全局配置，回滚成本为零。

3. bookmarks 插件吃掉 CPU 的四条路径

3.1 全工作区扫描 × 文件监听放大

定位到插件之后，要回答的问题是"它到底在干什么"。我用了一个比较土但有效的办法：把扩展目录下的源码翻出来，重点看它注册了哪些监听器。答案很典型——它注册了一个覆盖全工作区的文件监听，并且在文件变化时执行一次"书签有效性校验"。

听起来很无害，问题出在放大效应上。工作区有 12 万个文件，监听器本身的开销不大，但每次文件事件都会触发一次回调，回调里要做的事包括：读取书签 JSON、遍历 6000 条记录、对每条记录的 URL 做一次格式校验、比对当前文件路径是否在书签里。单次耗时大约 45 毫秒，听起来也不多。

真正致命的是频率。现代编辑器在保存文件时会触发多次事件（修改、保存、外部变更检测），加上依赖目录里偶尔有文件变动，一天下来事件次数是几千级别。更糟的是这个插件对事件没有做合并，来一次算一次。你连续保存 20 次文件，它就老老实实跑 20 次全量遍历，累计 900 毫秒的主线程占用，全挤在扩展宿主的同一个线程上。

这里可以量化一下放大倍数：单次遍历成本 45ms × 事件频率。如果编辑器每秒产生 2 次事件（在有构建任务的工作区里很常见），那么每秒就有 90ms 被吃掉，也就是单核占用约 9%；如果构建任务密集，事件频率能到每秒 10 次以上，单核直接跑满，这就是我看到的 100%。所以这类问题的本质不是"某个操作很慢"，而是"某操作被高频触发且没有节流"。

3.2 装饰器与每次重绘的隐性成本

第二条路径更隐蔽，和编辑器渲染机制有关。书签插件会在打开书签对应位置时，给那些行加一个装饰标记（行号旁边的书签图标）。实现方式通常是在编辑器上注册装饰类型，然后每次文档变化时重新计算一遍需要加装饰的行号。

这个计算本身不贵，贵在"每次文档变化"。你打字的时候，文档变化事件是逐字符触发的。如果插件没有做防抖，每敲一个字符就重新算一遍 6000 条书签和当前文档的交集，哪怕交集是空集，遍历本身也要时间。我从开发者工具的 Performance 面板里录了一段，输入 200 个字符的过程中，装饰器重算被调用了 200 次左右，累计占用接近 4 秒。

而且在四核机器上，这 4 秒不是均匀摊开的，是集中在你打字的那几十秒里，所以体感就是"打字的时候特别卡，停下来就好了"。这个特征很典型，可以用来和其他类型的问题区分：如果你的卡顿只在输入时出现、停止输入就恢复，那大概率是文档变化事件的处理逻辑没做节流。

还有一个放大器是可编辑区域。有些插件为了显示书签信息，会在编辑器里插入虚拟文本或行内提示。这类实现如果用的是同步布局计算，每帧都要读一次 DOM 尺寸，就会触发强制同步布局，帧率直接掉到 20 以下。判断方法也简单，在 Performance 面板里看有没有大量紫色的 Layout 块，有就是这个问题。

3.3 大 JSON 同步解析与 IPC 风暴

第三条路径是数据文件本身。3.8MB 的 JSON，用同步方式解析一次大约 30 到 60 毫秒。这个数字单看没问题，但如果解析发生在每次事件回调里，就会被放大到上面说的那个量级。

更麻烦的是进程间通信。插件的结构通常是"扩展宿主进程负责读写数据，渲染进程负责显示"。每加一个书签装饰，就要从宿主进程往渲染进程发一条消息。6000 条书签，如果逐条发，就是 6000 次通信。哪怕单次只要 0.1 毫秒，累计也是 600 毫秒，而且这些消息会在渲染进程的消息队列里排队，导致你在队列清空之前做任何交互都慢半拍。

我实际测到的情况是：打开一个带大量书签的工作区，头 20 秒内渲染进程的消息队列积压了几千条，期间的输入事件全部被排在后面。这就完整解释了为什么"AI 对话框"卡——不是 AI 逻辑慢，而是它的输入事件也在同一个队列里排队。

3.4 成本估算：把玄学变成数字

把上面三条合起来，做一张成本估算表，你就能预测任何配置下的大致 CPU 占用。这张表是我自己推的，用的是实测单次耗时，你可以按自己机器上的数字替换：

四项叠加，单核跑满就完全说得通了。这个表的意义不是精确，而是让你能在改配置之前先估算收益：比如把事件频率从 10 次/秒压到 1 次/秒，第一项就从 45% 降到 4.5%，这一项就足以让 CPU 从 100% 掉到 20% 以下。反过来，如果你只优化 JSON 解析（把它改成异步），第一项和第三项还在，CPU 依然会很高。优化的顺序应该是先降频率，再降单次成本，最后才是隔离。

提示：估算表里的"触发频率"是可以通过配置和节流直接干预的唯一变量，也是收益最高的抓手。先动频率，别一开始就去抠算法。

4. 让 Codex 走 TaoToken，把请求侧变成可控变量

4.1 为什么要单独拉一个令牌网关

排查到这一步，本地两段链路已经清楚了，但还有个问题没回答：AI 对话框卡顿里，到底有没有请求侧的成分？如果不把这个变量单独拎出来，你永远不知道那 20% 的剩余卡顿是本地算力还是远端等待。

TaoToken 在我这里的定位就是一个本地令牌网关：统一管理模型调用的凭证、做请求计量、记录每次调用的耗时分布、顺手做限流和超时控制。它的价值不在于"让请求更快"，而在于"让请求变得可观测"。所有请求都经过同一个出口，日志格式统一，你能清楚地看到每次调用排队多久、首字节多久、总共多久、有没有重试。没有这层网关的时候，这些数字散落在各处，根本对不上账。

把 Codex 指向 TaoToken 之后，我做的第一件事是对照实验：同一段提示词，分别在"书签插件启用"和"书签插件禁用"两种状态下各跑 30 次，比较请求耗时分布。如果两边分布几乎一样，说明请求侧完全没问题，剩下的卡顿 100% 在本地；如果禁用插件后请求耗时明显下降，那说明本地算力不足已经影响到了请求发出和响应处理的时间戳。

4.2 配置落地：环境变量与本地网关

配置分两层。第一层是环境变量，控制网关地址和凭证，注意别把密钥写进仓库：

export TAOTOKEN_BASE_URL="http://127.0.0.1:8787/v1" export TAOTOKEN_API_KEY="tk_local_xxxxxxxxxxxx" export TAOTOKEN_TIMEOUT_MS="60000" export TAOTOKEN_LOG_LEVEL="debug"

第二层是 Codex 侧的提供方配置，让它把请求发到上面这个地址，而不是默认出口。不同工具的配置文件格式不一样，下面这份是示意，字段名按你实际用的产品文档来：

[model_provider.taotoken] base_url = "http://127.0.0.1:8787/v1" api_key_env = "TAOTOKEN_API_KEY" timeout_ms = 60000 max_retries = 1 stream = true [profile.taotoken] model_provider = "taotoken"

两个参数值得单独说。超时时间我设成 60 秒而不是默认的 30 秒，原因是排查期间我不想让超时重试干扰耗时统计——重试会让日志里出现两条记录，容易误判成"请求变慢了"。重试次数设成 1 而不是 0，是为了区分"网络抖动"和"服务不可用"：如果日志里偶尔出现一条重试后成功的记录，说明链路本身是通的；如果全部失败，那是配置问题。

配置完成后先做连通性验证，不要直接上去跑业务请求：

curl -sS -X POST "$TAOTOKEN_BASE_URL/chat/completions" \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"default","messages":[{"role":"user","content":"ping"}],"max_tokens":8}'

能拿到正常响应，再回到编辑器里让 Codex 发真实请求。

4.3 日志里该盯哪几个字段

网关日志字段很多，排查卡顿时真正有用的就五个。第一个是queue_wait_ms，请求在网关内部排队的时间；第二个是ttft_ms，从发出到收到第一个流式片段的时间；第三个是total_ms，全流程耗时；第四个是retry_count；第五个是token_in和token_out，用来判断是不是上下文太长导致的慢。

判读规则我总结成三条。queue_wait_ms高而ttft_ms低，说明瓶颈在本地网关的并发处理上，跟模型无关。ttft_ms高而queue_wait_ms低，说明远端响应慢，这时候再去看网络和模型负载。total_ms远大于ttft_ms，说明慢在流式输出的后半段，通常是输出 token 太多，这时候要考虑的是精简提示词或者换更快的模型，而不是怀疑本地算力。

我这轮实验的结果是：插件启用和禁用两种状态下，ttft_ms的中位数差异在 5% 以内，queue_wait_ms都接近 0。这就排除了请求侧，把注意力完全拉回本地。如果没有这层网关，我大概率会在网络上多折腾半天。

4.4 对照实验结果怎么读

实验数据我整理成了下面这张表，用的是 30 次调用的中位数和 P95：

最后一行是重点。请求耗时的差异都在噪声范围内，但输入延迟差了 7 倍。这组数据把结论钉死了：卡顿来自本地渲染链路，而不是模型请求。到这一步，排查方向就完全确定了，剩下的工作全在本地优化上。

注意：做对照实验时一定要控制变量。两次实验之间不要改模型、不要改提示词长度、不要换网络环境，否则数据没有可比性。

5. 修复方案：止血、减负、隔离三步走

5.1 配置层止血：十分钟内让 CPU 降下来

第一步永远是止血，先让机器能用，再谈根治。书签插件这类工具的配置项通常有这几个方向：关闭自动扫描、限制扫描范围、限制单个文件大小、调整刷新频率。下面是按常见命名习惯写的配置示例，具体键名以插件文档为准，不确定的先在设置界面里搜关键词：

{ "bookmarks.autoScan": false, "bookmarks.scanOnSave": false, "bookmarks.refreshDelay": 500, "bookmarks.maxFileSize": 2097152, "bookmarks.exclude": [ "**/node_modules/**", "**/.git/**", "**/dist/**", "**/build/**", "**/*.min.js", "**/*.map" ] }

配套要把编辑器的文件监听也收一收，这一项收益往往比插件自身配置还大，因为它从源头减少了事件数量：

{ "files.watcherExclude": { "**/node_modules/**": true, "**/.git/objects/**": true, "**/.git/subtree-cache/**": true, "**/dist/**": true, "**/build/**": true, "**/coverage/**": true }, "search.followSymlinks": false, "files.watcherInclude": [] }

refreshDelay设成 500 毫秒是关键一步。按前面的估算，事件频率从 10 次/秒降到 2 次/秒，第一项成本就从 45% 掉到 9%，再叠加排除目录带来的事件削减，实际能压到个位数。改完立刻复测，我这边 CPU 从 100% 掉到 12%，输入延迟从 320ms 掉到 60ms 左右，基本可用了。

改配置的时候有个坑要提醒：files.watcherExclude是全局生效的，如果你有依赖外部变更的工作流（比如同时跑构建），排除了构建目录可能导致编辑器看不到新产物。稳妥的做法是先在当前工作区的.vscode/settings.json里改，观察一周没问题再考虑提到全局。

5.2 数据层减负：书签文件瘦身与分片

配置止血只是降频，单次成本还在。3.8MB 的 JSON 里我翻了一下，有大量冗余：同一个 URL 存了多个标题变体、标签数组里有空字符串、时间戳用完整 ISO 字符串存而不是数字。清理之后文件降到 1.9MB，解析耗时从 40ms 降到 18ms。

清理脚本很简单，用 Python 跑一遍就行，跑之前务必备份原文件：

import json, shutil, os src = "bookmarks.json" shutil.copy(src, src + ".bak") with open(src, "r", encoding="utf-8") as f: data = json.load(f) items = data.get("items", data if isinstance(data, list) else []) seen, cleaned = set(), [] for it in items: url = (it.get("url") or "").strip() if not url or url in seen: continue seen.add(url) tags = [t for t in (it.get("tags") or []) if t] cleaned.append({ "u": url, "t": (it.get("title") or url)[:200], "g": it.get("group", ""), "c": int(it.get("created", 0)), "g2": tags, }) with open("bookmarks.slim.json", "w", encoding="utf-8") as f: json.dump({"items": cleaned}, f, ensure_ascii=False, separators=(",", ":")) print("before:", os.path.getsize(src), "after:", os.path.getsize("bookmarks.slim.json"))

字段名缩短是有意为之：JSON 的键名重复 6000 次，光键名就能占几百 KB。缩短之后文件体积能再降三成。这个做法有个代价——可读性变差，人工排查时不直观，所以我一般只在确认插件能正常读之后才替换，并且保留.bak备份。

进一步的做法是分片：按分组把书签拆成多个文件，插件只加载当前打开的分组。这一步需要插件支持，不支持的话就只能自己写个轻量替代。我这次没走到这一步，因为清理之后单次成本已经降到 18ms，配合 500ms 节流，占用可以忽略。

5.3 进程与调度层隔离

如果前两步做完 CPU 还是偏高，说明你需要做隔离，把重活挪出主链路。编辑器一般提供几个层级的隔离手段，从轻到重排列。

最轻的是工作区级别启用扩展，让某些扩展只在特定项目里生效。这个改的是工作区配置，不影响其他项目。中等的是把语言服务和文件监听放到独立进程，很多编辑器默认就是这么做的，但有些插件会强行在主线程跑逻辑，这时候只能联系插件作者或者换实现。最重的是把整个开发环境拆到容器或者远程开发里，本地只跑界面。

我实际采用的是中间路线：把书签插件只保留在"资料整理"那一个工作区，写代码的主工作区直接不启用它。这个决策很朴素——书签管理和写代码本来就不是同一件事，没必要让它们共享同一份资源预算。切换成本很低，打开工作区时勾选一下就行，但收益很大，主工作区的 CPU 基线从 12% 降到了 4%。

隔离的另一个维度是时间。如果你的工作流里有"批量整理书签"这种操作，把它放到不写代码的时段，避免和编译、AI 长对话撞在一起。我现在的习惯是每天下班前花十分钟整理书签，那时候机器闲着，插件爱怎么跑怎么跑，不影响正常工作。

5.4 替换或降级的判断标准

什么时候该换插件，什么时候该留着调配置，我有一套自己的判断标准。看三个维度：是否还在维护、是否提供节流配置、数据是否可导出。

如果插件半年没更新、配置项里找不到任何和刷新频率相关的东西、数据格式是私有二进制，那基本可以考虑换了，因为这三个特征加起来意味着你无法通过配置降低它的开销，只能被动承受。反之，如果它提供刷新间隔配置、数据是标准 JSON、还在持续更新，那调配置的收益通常比换插件高，因为迁移成本低。

换插件的时候有个细节容易被忽略：先导出再卸载。我见过有人直接把插件删了，书签数据跟着没了，因为数据存在插件自己的全局存储目录里。稳妥顺序是导出 JSON、确认新插件能导入、验证数量对得上、最后再卸载。这个顺序虽然啰嗦，但能省掉一次重建数据的痛苦。

降级也是一个选项。有些插件的新版本为了做"智能分类"之类的功能，引入了额外的索引和监听，开销比旧版本大不少。如果旧版本能满足需求，退回旧版本是完全合理的工程决策，不要把"用最新版"当成原则。

6. 排查速查表与几条踩坑记录

6.1 症状—原因—动作对照表

把这一轮的经验整理成表，下次遇到类似问题直接对号入座：

这张表的用法是从上往下匹配，先匹配症状，再看原因，最后执行动作。不要跳着看，因为多个症状可能同时存在，比如"空闲态高"和"打字卡"同时出现，那就是两个问题叠加，要分别处理。

另外补一条经验：改完配置一定要做回归验证，而且要用同一套动作复现。我一般固定跑"连续保存 20 次 + 输入 200 字符"这两组动作，记录 CPU 峰值和输入延迟，前后对比。没有基线数据，你根本不知道改的是变好了还是变坏了。

6.2 几个我踩过的坑

第一个坑：只改插件配置，没改文件监听排除。当时我把插件的自动扫描关了，CPU 是降了一些，但保存文件时还是有尖峰。后来才发现是编辑器的文件监听还在遍历依赖目录，事件还是照发，插件只是不处理了，但监听本身的开销还在。这两个要一起改。

第二个坑：把节流时间设得太长。我一开始图省事，把刷新延迟设成 3000 毫秒，CPU 是彻底安静了，但书签状态更新变得很迟钝，改完书签要等三秒才看到结果，体验很差。最后定在 500 毫秒，这个值是在"CPU 可接受"和"响应及时"之间的平衡点，实测下来两边都还行。

第三个坑：以为关掉面板就关掉了 AI 模块。实际上关掉面板只是不渲染，后台的连接和状态管理还在。判断有没有影响，要看关掉面板后 CPU 有没有变化，而不是看面板还在不在。我那次关了面板 CPU 纹丝不动，才确认跟 AI 无关。

第四个坑：对照实验里变量没控制住。第一次跑实验的时候，我在两次测试之间顺手改了提示词长度，结果total_ms差了 40%，差点误判成"插件影响请求速度"。后来重新跑，严格控制提示词、模型、网络三个变量，数据才可信。做对照实验最忌讳的就是"顺手改一下"，改了就白做。

第五个坑：忘了看进程树里的子进程。有些编辑器会把扩展宿主拆成多个子进程，你在顶层看只看到一个进程占 30%，展开子进程才发现某个子进程单独占了 100%。所以看进程要展开看，别只看第一层。

提示：每改一项配置就复测一次，一次只改一个变量。同时改三项，你永远不知道是哪一项起了作用，下次遇到同样问题也没法复用经验。

最后分享一点我在实际操作中的体会。这类"CPU 打满 + AI 面板卡顿"的问题，看起来是 AI 的事，实际上九成是本地某个高频事件处理器在空转。判断的关键不是去看模型返回了什么，而是去看"空闲的时候 CPU 在干什么"。只要你能把空闲态和交互态分开测，把本地链路和远端链路分开测，问题的轮廓就会自己浮出来。至于 Codex 走 TaoToken 这一步，它的作用不是修 bug，而是给你一个可信的对照组——有了对照组，你才敢说"这不是网络问题"，也才敢把精力全部投到本地优化上。工具本身不解决问题，但它能让你的判断有据可依，这在我看来的价值比省下来的那点排查时间大得多。