DeepSeek TUI 改名以后，很多人会在新的 `codewhale` 命令和旧的 deepseek shim 之间来回试。通用的 command-not-found 错误，几乎不意味着应用逻辑本身坏掉。更常见的情况是：安装发生在一个包管理生态里，但你当前 shell 解析命令时走的还是另一条路径，或者还是旧终端配置。
这页要帮助用户区分：包管理器归属、shell 路径可见性，以及旧会话缓存三类问题。
先弄清是 npm、cargo、Homebrew 还是 release binary 理应拥有这个命令。
确认当前 shell 配置里，包含 `codewhale` 的目录是否真的被导出，而且顺序正确。
有些路径修复只有在新 shell 或完全重开终端后才会生效，所以要确认你不是在旧会话里误测。
当你已经知道是谁安装了二进制，以及当前 shell 的问题是通用 PATH 问题还是路线专属问题时，就可以离开这页了。
先拿可执行例子，再回头做更细的调整。
command-not-found 的起点，是同时确认理论拥有者和当前 shell 是否真能看到那条路径。
command -v codewhale || which codewhale
codewhale --version只在当前窗口里成功不够，必须重开终端后再跑最窄的解析检查。
command -v codewhale || which codewhale
# 重开 shell 后再重复先判断你卡在哪一层，再去对应分支，不要把所有问题都混成一个。
这通常不是包没装上，而是 shell 没看到对应路径。
这就是 shell profile 或 PATH 边界问题，先去对比启动文件，不要先重装。