DeepSeek TUI 已改名为 CodeWhale
这个项目上游已经改名。现在的新安装命令应优先使用 npm install -g codewhale，启动命令也应优先使用 codewhale。
旧的 deepseek / deepseek-tui 目前仍作为兼容 shim 存在，但上游已经说明它们只是过渡方案，并计划在 v0.9.0 移除。
Windows 安装
在 Windows 上安装 CodeWhale，先看你每天真正工作的 shell，再决定安装路径
如果你是搜 DeepSeek TUI 进来的，先记住当前项目名已经切到 CodeWhale。Windows 安装最容易混乱，不是因为命令难，而是因为 shell、PATH 规则和终端习惯比 macOS、Linux 更分裂。
本页是站内详情页在 Windows 上安装 CodeWhale（DeepSeek TUI 改名指南）安装
这页能直接回答的问题
- 到底哪个 Windows shell 才是你真实的 CLI 工作环境？
- 什么时候 Windows 上该优先选 npm、cargo 或 WSL？
- 除了某个终端里一次跑通，还要怎么确认安装真的完成了？
做完后该核对什么
- 在你真正要工作的那个 shell 里跑 `codewhale --version`。
- 确认 PATH 变化是不是只存在于某一个终端 profile。
- 如果二进制存在但请求失败，下一步应转去 provider 设置。
最常见的误区
- 在 PowerShell 里测试，但真实工作都在 Git Bash 或 WSL。
- 安装路径和主力 shell 平时完全不搭。
- 只因为某一次运行成功，就以为所有终端 profile 都修好了。
推荐阅读顺序
先按当前问题走，再决定要不要切去相邻详情页或 hub。
先识别真实 shell
不要从安装命令开始想，而是先确认你真实工作到底在 PowerShell、Git Bash 还是 WSL。
让工具生态去匹配 shell
选择那条在该 shell 里本来就最自然的安装路径，而不是强行引入不熟的工具链。
重开终端再验证
Windows 的 PATH 问题常常只在新 shell 里出现，所以一定要重开后再查一次。
直接可用的示例
先拿可执行例子，再回头做更细的调整。
一定在你真实工作的 shell 里测试
Windows 安装是否成功，只在你日常真正工作的 shell 里才算数，不是某个安装窗口里跑通一次就结束。
codewhale --version
where codewhale先把不同 Windows shell 的路径边界分开
如果 PowerShell、Git Bash、WSL 结果不一致，先比二进制路径，不要先换包管理器。
where codewhale
# 在你真正要使用的 shell profile 里重复执行重开终端后同时看版本和路径
在 Windows 上，只看一次版本成功不够，还要在新开的同一终端 profile 里再对照路径。
codewhale --version
where codewhale
# 新开 PowerShell、Git Bash 或 WSL 后再重复常见失败分支
先判断你卡在哪一层，再去对应分支，不要把所有问题都混成一个。
PowerShell 正常，但 Git Bash 或 WSL 不正常
先把它当成 shell 边界或 PATH 边界问题，不要立刻判断包管理器坏了。
命令只在安装那个 shell 里存在
通常是 PATH 传播或 terminal profile 范围没打通。重开目标 shell，再查当前实际解析的路径。
路径看起来对，但只有某个 shell 请求失败
这往往不是安装层，而是不同 shell 的认证或环境变量导出不一致。下一步去看 env 和 provider。
什么时候该离开这页
当你已经确认当前路线没问题，就不要继续停留在这页。安装线应转去配置，配置线应转去 provider 或排错，MCP 和模式线则应该转回真实工作流页。详情页的价值是把问题缩窄，而不是长期停留在解释层。