lsp-copilot 插件不存在，sublime text 无官方或主流支持的该插件；所有相关方案均为误传或已失效项目。
LSP-copilot 插件不存在，Sublime Text 没有官方或主流支持的 LSP-copilot 实现；所有声称“LSP-copilot”的方案都是误传或已失效的非维护项目。
为什么搜不到 LSP-copilot？
截至 2026 年 7 月，Package Control 官方仓库、GitHub 主流 Sublime 插件生态、以及 LSP 协议规范中，均无名为 LSP-copilot 的插件。它既不是 LSP 官方子项目，也不在 sublimelsp 维护列表里。常见混淆来源是：把 LSP-pyright 误写成 LSP-copilot；或把第三方未上架的实验性 fork 当作正式插件。
- 执行
Package Control: Install Package后搜索LSP-copilot，结果为空或仅显示 404 页面 → 说明该包从未发布 - 手动 clone GitHub 上标为 “LSP-copilot” 的仓库，往往发现 last commit 是 2021 年、依赖已过期、且不兼容 Sublime Text 4 的 API
- 试图配置
"command": ["lsp-copilot"]会导致LSP: server not found错误，因为系统根本找不到这个可执行文件
真正能用的 AI 辅助路径只有三条
别在不存在的插件上浪费时间。当前稳定可用的 AI 类补全方案就三个，各自适用场景明确：
-
TabNine：本地模型、离线运行、零配置、响应快；适合行级/变量级补全（如输for i in ra补出range(10)），但不理解函数签名或跨文件上下文 -
LSP-pyright（Python） /LSP-tsserver（TS/JS）：基于类型推导的语义补全；能提示参数名、返回类型、重载签名；需先pip install pyright或npm install -g typescript-language-server -
Pieces OS + pieces-app/plugin_sublime：本地运行的 AI 平台客户端；支持自然语言提问、代码解释、重构建议；需单独下载 Pieces OS 并保持后台运行，Sublime 插件仅作通信桥接
GitHub Copilot 在 Sublime 中的现实约束
所有 Sublime 的 “Copilot” 插件本质是 OpenAI API 封装器，不是 GitHub 官方客户端。它们无法访问 Copilot 的私有模型、跨文件索引或企业上下文，补全质量高度依赖你手动选中的 {selection} 内容是否包含足够约束条件。
- 必须通过终端启动：
subl .（macOS/Linux）或subl.exe（Windows 命令行），否则OPENAI_API_KEY环境变量不可见 - 控制台验证命令：
import os; print(os.environ.get("OPENAI_API_KEY"))→ 输出sk-开头字符串才算生效 - 默认 prompt 容易生成通用代码（如
def foo(): return None），要改成带约束的模板，例如：你是一名 Python 工程师。请基于以下函数签名和已有代码续写逻辑，不加注释，只输出代码：\n\n{selection} - 补全后常带多余空行或 TODO 注释，需关闭
append_newline和strip_trailing_whitespace配置项
真正卡住多数人的不是“怎么装”，而是搞不清 LSP 是协议、语言服务器才是干活的实体，以及误信不存在的插件名。装完 LSP 和 LSP-pyright 后，右下角没出现 LSP: ready，大概率是 pyright 没装进系统 PATH，或者你双击图标启动 Sublime 导致环境变量丢失——这些细节比选哪个“copilot”名字重要得多。
