Composer 卡住、只给计划不落盘、或把补丁写到错误路径时，应先按模型是否可用、工作区索引是否完成、.cursorignore 是否过宽、以及 Apply 权限是否被挡这四条线排查，而不是重装整个编辑器。
先分清故障类型，再动手
Composer 的表面症状很像「模型变笨」，真正分流要看它有没有产出文件卡片。窗口里完全没有 diff，多半是上下文没进去或模型请求失败；有卡片但 Apply 失败，才是磁盘权限、只读工作区或合并冲突。把这两类混在一起换模型，只会浪费一轮对话。
还有一种隐蔽情况：你其实开在问答侧栏，而不是可写工作区的 Composer/Agent。问答可以给方案，但不会主动改仓库。确认面板标题和 Apply 按钮是否存在，能少走很多弯路。
建议按这个顺序检查
- 打开 Cursor Settings 里的模型列表，确认当前选择没有欠费、没有被团队策略禁用。模型不可用时，Composer 常常只转圈，错误提示很弱。
- 看窗口底部索引进度。刚 clone 的大仓库若索引未完成，它会漏掉关键符号，表现为「找不到刚才那个函数」。
- 打开
.cursorignore和.gitignore，检查是否把src、packages或生成代码目录整段排除。忽略过宽等于让 Agent 瞎改。 - 用
@Folders点名目录，并在第一句写清包路径。仓库里一旦有同名文件，它很容易在错误模块新建平行实现。 - 若 diff 已出但无法写入：检查文件是否被别的进程占用、是否在只读 SSH/WSL 目录、是否有未保存缓冲与磁盘版本冲突。
- 同一条失败线程不要连续重试。开新会话并贴上刚才真正要改的路径，比在错误上下文里加戏更省时间。
容易误判的两点
回答变短，不一定是 Composer 坏了。你如果只引用了一个二十行的文件，它不会主动去改测试和调用方。另外，大仓库在上下文被截断时，它只能看到部分符号，表现为改接口却漏掉实现。先补目录引用，再考虑换更强的模型。
不要为了「试试看」把整个用户主目录加进工作区。索引会更慢，误改配置文件的风险也更高。工作区保持在仓库根目录即可。隐私模式与能否写文件无关，关掉它解决不了 Apply 失败。
一次真实的卡死该怎么记日志
建议在排查时记下四行信息：当前模型名、工作区根路径、Composer 是否出现过文件卡片、Apply 报错原文。这四行足够判断是网络、索引还是权限。很多人只截一张「转圈」的图去问同事，既看不出模型，也看不出它到底有没有尝试写盘。把这四行贴进新会话的第一句，比连续在旧线程里催「继续」更有效。若你使用 Git，先 git status 看工作区是否已被部分写入，避免在半应用状态下继续让 Agent 叠补丁。
若 Composer 反复在同一文件里做无意义的格式化，先看编辑器是否开了保存时格式化，并且与项目 formatter 冲突。Agent 写入后触发格式化，格式化又改变它刚写的代码，下一轮它会以为自己没改成功。把格式化交给保存钩子，让 Composer 只负责任务相关改动，循环会少很多。
常见问题
Composer 一直聊天，从来不改代码？
先确认当前是可应用补丁的编辑模式，而不是纯问答。若有 Apply 却点了 Ignore，下一次它会以为你要继续讨论方案。明确写下「直接改这些文件」能减少空转。
为什么总把补丁打到别的包？
同名组件在 monorepo 里很常见。需求第一句写 packages/billing 这类路径，再用文件夹引用锁范围，比事后再让它「撤销重来」干净。
索引进度长期停在很低的百分比？
常见原因是杀毒软件锁文件、工作区指到了错误的父目录、或仓库在高延迟网络盘上。把项目拷到本地 SSD、缩小工作区后再重新索引，通常比反复点 Cancel 有效。
