真正能稳定工作的方案只有「本地服务桥接」，即sublime插件通过urllib发送标准post请求至本地运行的text-generation-webui或llama.cpp提供的openai兼容端点，由后端处理模型加载、流式响应与上下文管理，插件仅作轻量转发。
Sublime Text 本身不支持原生流式响应或异步网络调用，所有所谓“直接集成 ChatGPT”的插件在实际运行中都会卡 UI、丢上下文、报 ImportError: No module named 'aiohttp' 或 URLError: <urlopen error operation timed out></urlopen>。真正能稳定工作的方案，只有「本地服务桥接」这一条路。
为什么 requests 和 urllib 在 Sublime 插件里会卡死
Sublime 的 PluginHost 是单线程阻塞式架构，Python 环境锁定在旧版（如 3.3/3.8），不支持 asyncio；任何同步 HTTP 请求（比如 requests.post()）都会让整个编辑器界面冻结数秒甚至十几秒。这不是配置问题，是底层限制。
- 插件调用
requests.get()→ UI 完全无响应 → 用户误以为崩溃 - 尝试用
sublime.set_timeout包裹urllib→ 只是把阻塞延迟到超时后，依然无法解析data:流式响应 - 所谓“对话历史”靠插件自己维护
messages列表 → 每次请求都是新会话，上下文根本没传给模型
可行方案：用 text-generation-webui 或 llama.cpp 提供 OpenAI 兼容端点
绕过 Sublime 直连 API 的幻想，让它只做「前端」：发送标准 JSON POST 请求到本地 http://localhost:5000/v1/chat/completions，由外部服务完成模型加载、流式响应组装和上下文管理。
- 启动
text-generation-webui时加参数--api --api-openai-endpoint，它会自动暴露符合 OpenAI 格式的/v1/chat/completions -
llama.cpp需启用server模式并指定--port 8080 --api，再用openai-python兼容客户端对接 - Sublime 插件只需用
urllib.request发一次 POST，接收完整 JSON 响应（非流式），避免 UI 卡顿
sublime-nano-bots 的实际配置要点
这个插件不是“调用 AI”，而是严格遵循 JSON-RPC 协议转发请求。它的稳定性来自对协议的克制实现，而非模型能力。
- 必须关闭插件内置的“流式渲染”选项（默认常开），否则会因 Sublime 无法处理
data:分块而崩溃 -
settings.json中的"backend_url"必须指向本地服务的 OpenAI 兼容地址，例如"http://localhost:5000/v1" - 模型名填
"gpt-3.5-turbo"是占位符，真实生效的是后端服务加载的模型（如deepseek-coder:6.7b） - 快捷键绑定建议用
ctrl+shift+i触发 “解释选中文本”，比命令面板更快，且不打断当前输入流
中文注释与上下文识别的现实边界
AI 能否理解你写的中文注释，取决于后端模型本身的能力，Sublime 插件层不做 NLP 处理。目前实测效果如下：
- 本地部署的
deepseek-coder:33b能准确响应“根据下面中文注释生成 Python 函数：计算用户活跃度” - 但若注释夹杂错别字或口语化表达（如“弄个循环把列表搞成大写”），成功率明显下降
- 插件不会自动提取文件中的 import 语句补全上下文——这需要后端服务主动读取项目结构，Sublime 层只负责传原始文本
- 中文变量名支持良好，但类型提示（
def foo(x: str) -> int:）仍比纯中文注释更可靠
真正容易被忽略的点是：所有“智能”都发生在本地服务端，Sublime 只是管道。换模型、调参数、改 prompt，全在后端配置里做；插件更新频率低、逻辑固定，别指望它自己“越用越聪明”。
