1. Tab 补全不是“按一下就完事”，Composer 也不是“点开就能写”——我在三个真实重构项目里踩出的边界线
大多数人第一次用 Cursor 的多文件编辑功能，是在一个深夜改 Bug 时被同事甩来一句：“你试试 Composer，比 Tab 补全快多了”。我信了。结果在重构一个含 27 个模块、跨 4 层目录结构的微服务网关时，Tab 补全把auth_service.go里的 JWT 解析逻辑补全得严丝合缝，而 Composer 却在api_gateway/router.go里生成了一段根本没调用过auth_service接口的路由注册代码——它“记得”接口定义，却“忘了”调用链路。
这不是模型能力问题。这是两种模式底层机制的根本错位：Tab 补全是“上下文快照+局部推理”，Composer 是“任务意图+全局规划”。前者像老司机闭眼倒车——只看后视镜里那三米；后者像导航系统——先算全程路线，再决定每一步怎么走。但导航会绕远路，也会在信号弱时失联。
我后来在三个不同规模、不同技术栈的项目中反复验证这个判断：
- 一个基于 Go + Gin 的内部工具平台（32 个 .go 文件，无测试覆盖率）
- 一个 Python + FastAPI 的数据清洗服务（含 Jupyter Notebook 嵌入式调试流程）
- 一个 TypeScript + React + Vite 的前端管理后台（组件间存在强依赖与 Context 状态穿透）
结果很反直觉：在第一个项目里，Tab 补全成功率 92%，Composer 仅 63%；在第三个项目里
