选中一段代码，按 Cmd-K，输入「把这段抽成一个函数」，弹窗就开始转。20 秒、40 秒、一分钟，没 diff、没报错、也没法提交。再按一次 Cmd-K 要么弹窗叠加、要么没反应。Cmd-K 流程其实比 Composer 和 Agent 都简单——单轮请求让模型回 unified diff——所以它卡住几乎只有这四种原因：模型 API 静默超时；选区加上下文把模型窗口撑爆了；上一次 Cmd-K 留下的 streaming socket 没清；选的模型本身有 bug（一些旧 preview 模型在长输入时不回 diff 格式）。
常见原因
按命中率从高到低。
1. 模型 API 请求静默超时
Cursor 后端给 Cmd-K 的单次预算大约 60 秒。上游模型（Anthropic、OpenAI、自定义）超时没回，响应就根本不来。弹窗一直转，因为 Cursor 没收到任何 error 帧。
怎么判断：在一个小文件里用 Cmd-K 改一行小修改。也卡——就跟你的上下文无关，是请求通道的问题。
2. 选区 + 上下文超出模型窗口
Cursor 会把选区加上周围一窗的代码（有时还有相关文件）一起发。4000 行的文件再开 @codebase，prompt 容易直接撑爆输入上限。有的模型 truncate，有的直接挂。
怎么判断：在 50 行的 scratch 文件里跑同一个编辑。那里能跑、大文件不行——就是上下文大小问题。
3. 上次 Cmd-K 留下的 socket 还半开着
上一次 Cmd-K 中途取消，底层 socket 可能停在半关状态。下一次请求复用了死 socket，永远完不成。
怎么判断：Cmd+Shift+P → 「Developer: Reload Window」。下一次 Cmd-K 能跑，就是它。
4. 选的模型 degrade 了，不回 diff 格式
某些模型版本（早期 Claude Haiku、已弃用的 OpenAI preview）会回散文而不是 Cursor 期望的结构化 diff。Cursor 死等永远不来的 diff。
怎么判断：设置 → Models → 切到已知稳定的，比如 claude-sonnet-4.6 或 gpt-5.5。重新 Cmd-K，能跑——模型的问题。
5. 网络代理或防火墙在 buffer 响应
公司代理会把整个响应攒完再转发，stream 被攥到完成或超时为止，弹窗看起来挂了，其实请求还在飞。
怎么判断：关代理或关 VPN 重试。秒回，就是 proxy 在 buffer。
6. Cursor 账号偷偷撞到 rate limit
会话中途快速请求配额用完了，某些 Cursor 版本会排队但不显示等待。弹窗看起来卡了，其实在排队。
怎么判断：Cursor Settings → Usage。「Fast requests used」到上限了——就是排队。
开始前
- 先保存文件，万一编辑最终落下来，别把别的改动丢了。
- 弄清楚 Cmd-K 选的是哪个模型（可以和 Composer 不一样）。
- 准备一个小 scratch 文件，便于隔离「上下文太大」这条。
需要收集的信息
- Cursor 版本（Help → About）。
- OS。
- Cmd-K 当前选的模型（输入框旁边的下拉）。
- 卡住时的文件大小、选区大小。
- prompt 里有没有用
@codebase或@file。 - 网络环境：VPN、代理、公司防火墙。
~/.cursor/logs/最新日志里匹配cmdk或inline的那条。
一步一步修复
Step 1：取消 + reload 窗口
按 Escape 关弹窗。Cmd+Shift+P → 「Developer: Reload Window」。把残留 socket 清掉。再 Cmd-K 同一段试试。
Step 2：缩小选区、缩短指令
选 10 行别选 200 行，输 3 个词的指令别输一整段。秒回——原请求要么太大要么太含糊，把改动拆成两次 Cmd-K。
Step 3：换 Cmd-K 模型
Cmd-K 弹窗里点模型下拉。原来是别的就换成 claude-sonnet-4.6 或 gpt-5.5。某些 preview 模型对 Cmd-K 特别脆。
Step 4：看状态页
打开 status.cursor.com 和你用的上游 provider 的状态页。任一在 degrade，所有 Cmd-K 都会挂。本地修不了——等或换 provider。
Step 5：临时绕开代理
公司网络的话，切手机热点或关 VPN 重试。5 秒出 diff，就是 proxy 在 buffer。长期方案是让 IT 把 api.cursor.sh 和你的模型 provider 加到 streaming 允许列表。
Step 6：查 fast request 用量
Settings → Usage。超 fast 上限了，等重置、升级套餐、或者把 Cmd-K 模型切到走 slow request 的（能用，只是排队方式不同）。
Step 7：完全重启 Cursor
Cmd+Q 完全退出（关窗口不算，进程还在）。重开、回到同一个文件、再试。新进程能把「Reload Window」清不掉的状态也清掉。
怎么验证修好了
- 在 5 行选区上用 3 个词指令跑一次 Cmd-K，10 秒内回结果。
- 在 100 行选区上跑一次，30 秒内回结果。
- 再试一次最初卡住的 prompt。能回就好；还卡就是 prompt 本身太含糊，重写得更具体。
- 走完一次 Cmd-K 完整流程：preview → accept。
长期预防
- 「Cmd-K model」固定选一个稳定的生产模型，别用 preview。
- 文件超过 2000 行就别用 Cmd-K，用 Composer——Composer 处理长上下文好得多。
- Cmd-K 里别用
@codebase，它是给 Composer 准备的，会让 inline 请求膨胀。 - 长时间用 Cursor 期间定期 reload 一下窗口，socket 会累积。
- 在公司代理后面工作的话，争取 IT 给个允许列表，别天天跟 buffering 斗。
容易踩的坑
- 第一次还在转就按第二次 Cmd-K。两个请求同时在飞，哪个都收不干净。
- 选中整个 3000 行文件做全局重构。Cmd-K 是给小修小补用的，要全局走 Composer。
- 一个 prompt 里塞好几条指令。Cmd-K 一条清晰指令最稳。
- 把 spinner 当进度。它不是——只是个等 HTTP 响应的 UI，响应可能永远不来。
- 不看弹窗里的模型下拉。每次 Cmd-K 默认可能不一样。
常见问答
- Cmd-K 是干嘛的？ 选一段 + 一条短指令，回一个 inline diff，可以不离开编辑器直接 accept 或 reject。
- 跟 Composer 有什么区别？ Cmd-K 是单轮，紧贴选区；Composer 多轮，可以跨文件改，对话里能维持上下文。
- 重试时 prompt 会丢吗？ Escape 后再 Cmd-K，按上箭头能回到上一次的 prompt。
- Cmd-K 算 fast request 配额吗？ 算，每次 Cmd-K 都是一次。
- 有没有快捷键能取消卡住的 Cmd-K？ Escape 只是关弹窗。没有「取消并释放请求」——底层 HTTP 可能还在飞到服务端超时。