轻量编辑器用户的 AI 编程助手插件

AI 编程助手生态高度集中在 VS Code 周边的主流 IDE，轻量编辑器用户被排除在外。Continue 的 GitHub issue 里，Neovim 支持请求拿到 245 分 / 38 条评论（"please if possible add neovim support for this awesome project. Many do use that"），Sublime Text 用户也在问 "Is there any plan to support other text editor? Like Sublime Text."。另一面，Rhun 的作者在 Show HN 上直言 "I'm not using even 1/3 of vim/vscode features anymore"——这些开发者要的是轻量、键盘优先的工作流加上现代 AI 能力，而不是被迫迁移到臃肿的 VS Code。痛点真实但强度中等（pain 2-3），属于'不方便'而非'阻塞性'问题。

Sublime Text、Neovim、vim 的存量用户——追求轻量、键盘优先、不喜欢 VS Code 臃肿感的开发者。市场规模定性判断：Neovim 支持请求获得 245 分 / 38 条评论，Sublime 请求 23 分，说明这是一个真实存在但规模有限的少数派群体；Rhun 的 Show HN 帖（51 分 / 30 评论）进一步佐证'反 VS Code 臃肿'的情绪有受众，但并非大众市场。

• Neovim 优先的插件方案：以 Lua 插件形式嵌入 Neovim，而不是让用户换编辑器，顺应其键盘优先的工作流
• 会话面板：在编辑器内直接驱动 Claude Code / Codex 会话，复用用户已有的订阅，插件不自建模型
• 本地 Ollama 后端：为隐私敏感场景提供本地模型选项（Rhun 已验证这一组合的可行性）
• 上下文感知的代码操作：选中代码的解释 / 重构 / 补全，以及 commit message 自动生成
• AI 的角色：全部 AI 能力来自桥接的 agent（Claude Code / Codex / Ollama），产品的工程价值在于深度编辑器集成与交互设计

Claude Code、Codex 等会话式 CLI 编程 agent 已经成熟并开放使用，加上 Ollama 让本地跑模型成为可行选项——Rhun 的发布正是基于这一组合（'commit message drafting via local Ollama or Claude Code/Codex subscriptions'）。这意味着为 Neovim / Sublime 做桥接型插件不再需要自建 AI 能力，工程门槛和成本在近期大幅下降；而 Continue 的两条编辑器支持请求（2024 年 3 月与 6 月）至今仍指向未满足的空档。

做：Neovim 插件（Lua），内嵌 Claude Code / Codex CLI 会话面板、选中代码的编辑与解释、commit message 生成；支持 Ollama 作为隐私友好的本地后端。 不做：Sublime Text 版本（验证期后再说）、自研编辑器（避开与 Rhun/vscode 正面竞争）、自建模型或推理服务（全部复用用户已有的 Claude Code/Codex 订阅或本地 Ollama）、JetBrains 等其他平台。

平台依赖：方案建立在 Claude Code / Codex 的 CLI 接口之上，这些是 Anthropic / OpenAI 的产品，接口随时可能变更或被官方收紧授权，这是最大的结构性风险。 在位者风险：Continue 是活跃的开源项目，Neovim 支持 issue 已在其仓库挂起，一旦官方补齐，第三方插件的空间会迅速消失。 付费能力弱：目标用户来自开源编辑器社区，两条需求信号均无付费意愿，商业化路径不明。 维护负担：Neovim 与 Sublime 的插件 API 差异大，多平台并行会拖垮小团队，必须单点切入。 需求验证不充分：两条 feature request 来自同一家产品的 issue 区，样本集中，245 分热度是否能转化为留存未经验证。