sublime text 无 codeium 官方插件，因其插件生态封闭、api 限制多且用户萎缩；社区方案多失效，硬核代理需手动维护 api 适配，补全质量亦受限于 sublime 本身解析能力。
Sublime Text 本身不原生支持 Codeium，官方也未发布 Sublime Text 版插件 —— 所以直接在 Sublime 中启用 Codeium 行内补全、重构或注释生成，目前不可行。
为什么 Sublime Text 没有 Codeium 官方插件
Codeium 官方仅维护 VS Code、JetBrains 系列（IntelliJ、PyCharm 等）、Vim/Neovim 和 Visual Studio 的插件。Sublime Text 的插件生态封闭、API 限制多，且用户基数持续萎缩，导致 Codeium 团队从未投入资源开发适配版本。
常见错误现象包括：
- 在 Package Control 中搜索
Codeium，结果为空或返回非官方第三方 fork（多数已失效或仅含登录界面） - 手动安装 GitHub 上的社区版插件后，
codeium.auth_token配置成功但无任何补全弹出 - 按下
Ctrl+I或右键调用Codeium Refactor，提示 “command not found”
替代方案：用 VS Code + Remote Development 补齐 Sublime 工作流
如果你日常重度依赖 Sublime Text 的轻量启动、多光标编辑或侧边栏文件操作，但又需要 Codeium 的补全能力，可行路径是「保留 Sublime 做浏览/快速编辑，把写逻辑、补全、重构交给 VS Code」。
实操建议：
- 在 VS Code 中安装
Codeium插件，并完成账号登录与codeium.inlineSuggestionEnabled启用 - 用 VS Code 打开同一项目目录，开启
Remote - SSH或Dev Containers（如需环境隔离） - 将 Sublime 中正在编辑的关键文件（如
utils.py、api.ts）在 VS Code 中同步打开，专注在 VS Code 里写函数体、生成注释、执行Codeium Refactor - 利用 VS Code 的
File: Reveal in Explorer快速定位文件，再右键 →Reveal in Sublime Text（需提前配置系统级命令行工具subl）
硬核折中：通过 Sublime 的 LSP + 自建代理调用 Codeium API
极少数技术爱好者尝试过绕过插件限制，用 Sublime 的 LSP 插件 + 自建中间服务转发请求到 api.codeium.com。但这不是“开箱即用”，而是要自己处理：
- 申请并管理
CODEIUM_API_KEY，注意免费额度每月约 1000 次补全请求 - 编写 Python 脚本解析 Sublime 的
textDocument/completion请求，拼装为 Codeium 的/completionPOST 格式（含context、cursorPosition、language） - 拦截响应，提取
suggestions[0].text并注入 Sublime 编辑器（需调用view.insert和view.end_edit） - 每次升级 Codeium API 协议（比如 2026 年 3 月新增的
model=deepseek-free参数），都得手动改脚本
这不是推荐做法，而是说明：Sublime 用户想用 Codeium，本质是在用工程成本换功能 —— 大部分人最终会发现，不如切换主力编辑器。
真正容易被忽略的一点是：Codeium 的补全质量高度依赖上下文理解，而 Sublime 的语法高亮和符号解析能力弱于 VS Code 或 JetBrains，即使强行接入，getOrdersByUserId 这类方法补全也大概率只返回空泛模板，而非带 Mapper 调用和判空逻辑的真实代码。别在管道上反复拧螺丝，该换工具时就换。
