DeepSeek TUI 已改名为 CodeWhale
这个项目上游已经改名。现在的新安装命令应优先使用 npm install -g codewhale，启动命令也应优先使用 codewhale。
旧的 deepseek / deepseek-tui 目前仍作为兼容 shim 存在，但上游已经说明它们只是过渡方案，并计划在 v0.9.0 移除。
Cargo 安装
如果 Rust 已经是你平时的终端工具链，现在更自然的路线是用 cargo 安装 CodeWhale
如果你是搜 DeepSeek TUI 进来的，先记住当前上游包名已经切到 CodeWhale。cargo 路线最适合本来就长期使用 Rust CLI、也习惯通过 cargo 更新工具的人。
本页是站内详情页用 cargo 安装 CodeWhale（DeepSeek TUI 改名指南）安装
这页能直接回答的问题
- 什么时候 cargo 会降低复杂度，而不是增加复杂度？
- cargo 安装或升级后，最先要核对什么？
- 哪些问题属于 Rust 工具链，而不是 CodeWhale 本身？
做完后该核对什么
- 在新 shell 中验证 `codewhale --version`。
- 检查是不是旧的 npm 或手动二进制挡在 cargo 前面。
- 确认二进制没问题后，立刻进入 provider 和配置设置。
最常见的误区
- 只为了这一款工具装 Rust，却不理解 cargo 二进制路径。
- PATH 里还残留旧的 npm 全局安装。
- 把 cargo 编译成功误解成整套配置也已经完成。
推荐阅读顺序
先按当前问题走，再决定要不要切去相邻详情页或 hub。
先确认 cargo 自己没问题
在进入安装之前先跑 `cargo --version`。如果工具链本身就不完整，后面所有问题都会被放大。
只通过当前活跃工具链安装
尤其在多 toolchain 机器上，安装时要确保 cargo 对应的是你平时真正使用的那套 Rust 环境。
确认最终二进制路径
安装后和重启 shell 后，都确认一下当前 `codewhale` 命令是不是 cargo 那一路。
直接可用的示例
先拿可执行例子，再回头做更细的调整。
先确认 cargo 真是当前拥有者
在排 app 之前，先证明 Rust 工具链和当前解析到的二进制路径是在同一个 shell 里对齐的。
cargo --version
cargo install codewhale-cli --locked
codewhale --version
command -v codewhale || which codewhale检查是不是被旧安装挡住了
如果 cargo 安装成功但行为没变，先看是不是 npm 或手动二进制还在 PATH 前面。
command -v codewhale || which codewhale
codewhale --version
# 对照预期的 cargo bin 路径重开 shell 后再核对 cargo bin
很多 cargo 安装在当前终端看起来没问题，但新 shell 里才会暴露路径没接好的问题。
command -v codewhale || which codewhale
codewhale --version
# 重开 shell 后再重复一次常见失败分支
先判断你卡在哪一层，再去对应分支，不要把所有问题都混成一个。
cargo 完整装完了，但命令还是旧的
这通常说明旧二进制还在优先解析。先查 PATH 归属，不要先动 provider 配置。
`cargo install` 在构建前就失败
先把它当成 Rust 工具链问题处理。cargo 和构建环境没稳定前，不要先怪 CodeWhale。
当前 shell 能用，换个 shell 就找不到
通常不是 provider 问题，而是 cargo bin 没有稳定写进各个 shell 的启动路径。
什么时候该离开这页
当你已经确认当前路线没问题，就不要继续停留在这页。安装线应转去配置，配置线应转去 provider 或排错，MCP 和模式线则应该转回真实工作流页。详情页的价值是把问题缩窄，而不是长期停留在解释层。