大多数搜这个问题的人，不只是想知道品牌怎么变了。他们真正想问的是：安装命令是不是变了、旧命令现在还能不能用、哪些文档和自动化需要提前更新，避免等兼容窗口关闭以后再集中踩坑。
这页要帮助用户理解改名本身，把旧名字和新名字对应起来，并找出自己环境里哪些部分需要显式迁移。
很多人还会在搜索结果里先看到 DeepSeek TUI，但上游文档、releases 和安装命令已经改成 CodeWhale。
真正的影响点在安装命令、二进制名和包名是否还和官方当前路线一致。
shell alias、内部文档、CI 说明或 runbook 可能还依赖旧名字，即使 app 本身暂时还能启动。
当你已经知道哪些名字是旧的、哪些是当前正式名字，以及下一步该去安装、更新、排错还是对比栏目时，就可以离开这页了。
先拿可执行例子，再回头做更细的调整。
迁移里最稳的一步，是先把团队共用的安装片段改掉，避免新用户继续学临时 shim 路线。
npm install -g codewhale
codewhale --version
codewhale --model auto随便挑一个 shell alias、一份内部文档和一条自动化说明，查它们是不是还写着 `codewhale` 或 `deepseek-tui`。
# 搜索文档和 shell alias
# 在新安装教学里替换旧命令名先判断你卡在哪一层，再去对应分支，不要把所有问题都混成一个。
这会把迁移债务往后拖。兼容 shim 应该被当成桥梁，而不是继续冻结旧文档的理由。
这样站内会继续看起来互相矛盾。安装、更新、排错和对比页都应该围绕同一条改名叙事对齐。