为什么 Btelo Coding 看起来“不完整”
如果你习惯了传统 IDE 的工作流，你可能会发现 Btelo Coding 缺少一些你以为会有的功能：
- 没有 git 分支创建或合并 UI
- 没有内置文件编辑器
- 没有代码片段或 skill 构建器
- 没有 diff 审阅工具
- 没有合并冲突解决器
这不是疏忽，而是经过深思熟虑的设计决策。
为 AI 原生工程师而设计
vibe-remote 是为新型开发者 — AI 原生工程师 — 构建的。AI 原生工程师不会手动创建分支、逐个字符编辑文件，或点击合并冲突对话框。他们描述意图，让 AI 负责执行。
在 AI 原生工作流中：
| 传统方式 | AI 原生方式 |
|---|---|
| 手动创建 feature 分支 | 告诉 AI：“为登录功能创建一个分支” |
| 打开文件、定位行号、敲代码 | 告诉 AI：“给 auth 端点加上限流” |
| 一行行审查 diff | 告诉 AI：“审查变更并解释修改了什么” |
| 手动解决合并冲突 | 告诉 AI：“解决冲突，保留我们的 auth 逻辑” |
| 编写样板代码、配置、测试 | 告诉 AI：“为新的 handler 添加单元测试” |
在这种模式下，AI 不是助手 — 它是主要执行者。人类提供方向、上下文和判断，剩下的交给 AI。
聊天是你需要的唯一界面
vibe-remote 只提供一个控制面：聊天。所有操作都通过自然语言完成：
You: create a new branch called fix/memory-leak and switch to it
AI: Done. Created and switched to fix/memory-leak.
You: find where the WebSocket connection is leaking and fix it
AI: Found the issue in client.go:142 — the connection wasn't being
closed on context cancellation. Fixed and tested.
You: commit with message "fix: close websocket on context cancel"
AI: Committed. 1 file changed, 3 insertions, 1 deletion.
You: push and create a PR
AI: Pushed to origin/fix/memory-leak. PR #47 created.
做一个分支选择器、文件树、diff 查看器、合并工具只会增加复杂度，并不会给目标用户带来价值。更糟的是，它会鼓励本应被委托出去的手工劳动。
设计哲学
如果 AI 能做，你就不必自己做。
每个我们考虑加入的功能都要经过这套过滤：
- AI 编码工具能可靠地完成它吗？ 如果能，我们不会为它做 UI。
- 用户是否需要实时视觉反馈？ 如果需要（比如流式 AI 输出），我们会做。
- 这是一个需要人类判断的决策吗？ 如果是（比如批准一次部署），我们会清晰地呈现给用户。
这就是为什么 Btelo Coding 拥有丰富的会话管理、实时流式输出、多提供商支持和文件浏览 — 但没有代码编辑器。你需要看到正在发生什么，并指挥 AI。你不需要亲自去做那些机械的工作。
在实际使用中意味着什么
Btelo Coding 擅长的事：
- 从手机启动并管理 AI 编码会话
- 在 AI 工作时实时流式输出结果
- 浏览文件和目录以了解项目状态
- 查看 git 状态和提交历史
- 跨不同项目并行运行多个会话
你应该让 AI 去做的事：
- 创建、切换、合并分支
- 编辑、创建、删除文件
- 编写和运行测试
- 解决冲突
- 生成配置、样板代码和文档
- 提交、推送并创建 pull request
拥抱这种转变
从传统开发到 AI 原生开发的转变，类似于从汇编到高级语言的转变。没有人再手动分配寄存器 — 编译器会处理。同样地，当 AI 可以直接执行意图时，也没有人应该再手动浏览文件树、逐个字符敲代码。
vibe-remote 是你 AI 的遥控器。它有意做得极简，因为 AI 有意做得强大。