必须确保tab补全与composer共享上下文：项目索引完成、类型信息穿透、composer改动实时注入ast缓存；验证方式包括观察灰色补全建议、检查import语句、手动触发tab验证业务语义，且建议将trigger mode设为manual。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要在 Cursor 中让 Tab 补全和 Composer 协同工作，必须先确保两者不是孤立调用——Tab 补全负责局部微调，Composer 负责跨文件重构，但它们共享同一套上下文感知能力。如果你在 Composer 里刚生成了一个新 service 类，紧接着在 controller 文件里写到 userService. 就按 Tab，它得立刻补出你刚创建的方法，而不是报错说“找不到定义”。这要求项目结构已索引、类型信息可穿透、且 Composer 的改动已实时注入 AST 缓存。
确认 Tab 补全与 Composer 共享上下文
打开任意 .ts 或 .java 文件，在类定义下方空行处输入 // TODO: 实现用户注销逻辑，然后停顿 1 秒。如果右侧出现灰色补全建议（如 public void logout() { ... }），说明上下文已通；若无反应，【必须先保存当前文件并确保工作区已完整加载】，否则 Composer 新建的文件不会被 Tab 模型识别。
在终端中运行 cursor --status（macOS/Linux）或查看右下角状态栏的「Indexing」提示是否消失。未完成索引时，Tab 补全对 Composer 新增代码的响应延迟可达 8～12 秒。
在 Composer 修改后立即触发精准 Tab 补全
方法一：用 Cmd+I 打开 Composer → 输入“新增 UserAuthController，含 login 和 logout 方法，返回 ResponseEntity” → 等待生成并应用 → 关闭 Composer 面板 → 切换到 UserServiceImpl.java → 在空行输入 authController. → 按 Tab。
方法二：不关闭 Composer 面板，直接将光标切回编辑器 → 在已有调用处（如 userMapper.selectById(id); 下方）敲 authController. → 此时 Tab 补全会优先匹配 Composer 刚生成的类，而非旧项目中同名但未导入的类。
注意：如果补全列出的是 AuthController（首字母大写）而非你实际生成的 UserAuthController，说明 Composer 生成的文件未被自动 import，需手动添加 import com.example.controller.UserAuthController; 后再试一次 Tab。
用 Tab 补全快速验证 Composer 输出的合理性
第一步：用 Composer 生成一段带异常处理的数据库操作代码，例如：“给 getOrder 方法加 try-catch，捕获 SQLException 并转为自定义 ServiceException”。
第二步：生成后，将光标放在 catch 块内的 new ServiceException( 后面，不要补全完括号，直接按 Tab。
第三步：观察补全内容——如果出现 "查询订单失败", e 这类带参数的构造调用，说明 Tab 模型已理解 Composer 刚注入的业务语义；如果只补出空括号 ()，代表上下文未穿透，需检查该 ServiceException 类是否已在 classpath 中声明且被正确索引。
这一步操作起来很简单，直接把光标停在构造函数括号内按 Tab 就行，但它是验证 Composer 改动是否真正“活”起来的关键信号。
禁用干扰性补全以突出 Composer 主导逻辑
进入 Settings → Features → Tab Completion → 将 Trigger Mode 改为 【manual】。
关闭 Automatic 模式，避免在 Composer 正在生成多文件时，编辑器因频繁弹出灰色补全而卡顿或覆盖光标位置。
此时只有主动按 Tab 才会触发补全，既保住了 Composer 的执行节奏，又能在你需要时精准唤出上下文关联建议。
