把 Vim 改造成一个面向 vibecoding 的 TUI 工作台。
核心体验参考 ChatGPT、豆包这类经典 web chat 界面，但交互方式保持 Vim 思路：
- 以消息流为主
- 以 buffer / split / normal mode / insert mode 组织操作
- 保留高频编辑、搜索、复制、跳转、diff 的 Vim 习惯
- 支持和 ACP 协议后端进行流式对话、工具调用、补丁应用
首版只做“能稳定聊天、能看上下文、能接收流式回复、能应用补丁”的主链路。
先不做复杂炫技 UI，优先把下面几件事做实：
- 会话管理
- 聊天输入与输出
- 上下文挂载
- 流式回复
- 工具调用展示
- diff 预览与应用
推荐做成一个主工作区，必要时拆成多个窗格：
- 主区：聊天记录，按消息块展示 user / assistant / tool event
- 侧区：上下文、文件列表、当前任务、会话信息
- 底部：输入区和状态区
- diff 区：补丁预览、逐块确认、应用结果
如果宿主支持更强的 UI 能力，可以增加浮窗预览；但必须保留纯 split 的兼容模式，保证经典 Vim 也能用。
- 输入时像 Vim 的插入模式，浏览时像普通文档
- 对话区可用 normal mode 做导航、搜索、折叠、复制
- 常用动作尽量变成固定命令，不强迫鼠标
- 生成中允许中断、继续、重试、换上下文
- 代码和 diff 以可读、可操作为第一目标
管理这些对象：
- Session：会话
- Turn：一次用户输入到模型输出的完整轮次
- Message：消息实体
- ToolCall / ToolResult：工具调用与返回
- Artifact：文件、diff、补丁、日志等产物
- ContextItem：当前挂载的文件、选区、路径、任务说明
把 ACP 协议抽象成独立 adapter，不让 UI 直接依赖协议细节。
适配层负责：
- 建立连接
- 发送会话与上下文
- 接收流式 token / 事件
- 接收工具调用请求
- 接收补丁或结构化产物
- 处理错误、超时、取消
这样后续如果 ACP 的消息格式、鉴权或流式事件有变化，只改协议层，不动 UI 主体。
负责把结构化事件渲染成可读的 Vim 文本：
- 普通消息
- 代码块
- 工具调用记录
- diff 预览
- 状态提示
- 错误与重试提示
会话、历史、缓存和草稿统一落到本地数据目录。
要求：
- 可恢复
- 可清理
- 不污染用户项目文件
- 支持按会话保存上下文快照
建议用下面这套思路：
normal mode：浏览聊天、切换上下文、跳转到 diff、复制内容insert mode：写 prompt、写 follow-upcommand line：执行会话级命令mapping：把高频动作绑定到固定键位
命令可以先规划为：
- 打开/关闭 vibecoding 面板
- 发送当前输入
- 追加文件到上下文
- 重新生成
- 中断生成
- 打开 diff
- 应用补丁
- 切换会话
搭基础骨架：
- 插件入口
- 会话状态
- 本地存储
- 命令与映射
做聊天 TUI：
- 消息渲染
- 输入区
- 状态区
- 基础导航
接 ACP：
- 流式输出
- tool call 展示
- 错误处理
- 中断与重试
做 vibecoding 核心：
- 文件上下文注入
- diff 预览
- patch 应用
- 结果回写
打磨体验：
- 搜索
- 折叠
- 多会话
- 快捷键整理
- 兼容性修正
优先建议做成“核心逻辑与 UI 分离”的结构。
如果要兼容经典 Vim，核心层优先选 Vimscript 体系，异步通信走 Vim 自带的 job/channel 能力。 如果后续确认只面向 Neovim，再补 Lua 和更强的 UI 组件会更顺手。
- ACP 具体规范如果未明确，协议适配会需要再收敛一次
- Vim / Neovim 的能力差异会影响 UI 上限
- 流式输出、补丁应用、任务中断需要做得足够稳
- 代码改写必须有明确确认步骤，不能直接无脑落盘
- ACP 的准确协议定义、消息格式、鉴权方式
- 目标是只支持 Vim，还是 Vim + Neovim 一起支持
- 后端模型接入方式是固定单服务，还是允许多个 provider
- 是否需要本地/远端会话同步
- 代码修改是否默认走“预览后确认”模式
用户最终在 Vim 里看到的不是“一个聊天插件”，而是一个可以直接围绕代码工作、对话、预览、应用修改的 vibecoding 界面。
你确认这个方向后，我再开始按这个方案写第一版实现。