第一次在终端用 MiniMax Code CLI 改代码，稳妥的做法不是直接给它一个「帮我重构一下」的大任务，而是先把「只改一个文件」这条链路跑通：确认命令能被终端找到、进到目标仓库、把改动范围压到一个文件路径上、用 diff 看它到底写了什么、再决定提交还是回滚。工具具体支持哪些子命令以本地 `--help` 输出为准，下面的步骤只做一件事——即使它改得不对，你也只丢一个文件的改动。
适用场景：刚装好 CLI、准备在真实仓库里第一次运行。操作动作：先校验可执行文件在 PATH 且能打印帮助，cd 进项目，把任务限定在单个文件路径上，跑完只看工作区状态和 diff。验证方式：git status `--short` 与 git diff -- 文件路径 的输出，确认没有越界改动。风险边界：工作区不干净时，diff 里会混入无关改动，回滚也会牵连别人，所以第一次运行前先提交一次或新建分支。
确认可执行文件在 PATH 里并能打印帮助
装完不等于终端认识这条命令，先在终端里排除「装好了但 shell 找不到」的情况，再谈改代码。
command -v minimax
minimax `--version`
minimax `--help`这里的 minimax 换成你安装后实际的可执行文件名，子命令形态以本地 `--help` 的输出为准，不要照抄别处的参数表。判断标准比较直白：command -v 有路径输出、`--version` 能打印版本、`--help` 能列出用法，三条都满足，这一步就算过了。
如果 command -v 没有任何输出，通常是安装脚本把可执行文件放进了某个 bin 目录，但没有写进当前 shell 的 PATH。可以先 echo $PATH 看一眼，再检查 ~/.bashrc、~/.zshrc 这类配置里有没有对应的 PATH 追加行；改完重开一个终端，或者 source 一下配置文件再试一次。
进入目标项目并把改动范围压到一个文件
先让仓库处在一个能说清楚的起点，再让工具动手。
cd ~/projects/your-repo
pwd
git status `--short`git status `--short` 没有输出，说明工作区干净；有输出就先把现有改动提交或 stash 掉，否则后面分不清哪些行是工具写的。想留一层额外保护，可以先 git switch -c cli-first-run（较老的 git 用 git checkout -b）。
给任务时用相对仓库根的路径最稳，例如 src/format.js，并把范围写死在提示词里：
只修改 src/format.js 这一个文件。
不要新建文件，不要改动其他文件，不要执行 git add 或 git commit。
改完告诉我改动了哪几行。限定单文件不是限制工具能力，而是给自己一个可检查的边界：跑完只需要看这一个文件的 diff，判断成本最低。
跑一次小改动并在终端看 diff
任务跑完先别提交，用仓库状态和 diff 确认它做了什么、写在哪。
git status `--short`
git diff `--stat`
git diff -- src/format.js观察点可以按这几条过一遍：
- git status `--short` 里应该只有目标文件是已修改状态；如果出现 ?? 开头的行，说明工具新建了文件，哪怕内容看着无关也要先处理掉。
- git diff `--stat` 只应列出一行文件；多出文件就意味着这次任务越界了。
- git diff -- src/format.js 里看新增行和删除行是否落在你预期的逻辑附近，有没有顺带的缩进、换行、格式化改动。
- 如果 diff 是空的而工具回复「已修改」，多半只是描述没有落盘，需要回头确认它写入的路径和文件名是否正确。
改坏了怎么退回改前状态
第一次使用要提前想好退路，未提交和已提交是两种处理方式。
改动还在工作区、没有提交：
git restore src/format.js
git status `--short`旧版本的 git 没有 restore，可以用 git checkout -- src/format.js。如果工具顺带新建了文件，用 rm 删掉，再确认一次 git status `--short`。
如果已经把这次改动提交了，回滚建议用 revert，它保留历史、生成一条反向提交，别人也能看到发生了什么：
git log `--oneline` -3
git revert HEADgit reset `--hard` 也能回到改前状态，但它会直接丢弃内容，第一次使用不建议把它当默认手段。之所以强调下任务前先提交一次，就是为了有一个明确的改前状态：diff 里出现的改动都归工具，回滚对象只有一个 commit，不用靠回忆去猜哪个文件被谁动过。
把这次跑通的步骤固化成固定顺序
跑通一次之后，把顺序固定下来，第二次使用就不用重新试探：进目录、下任务、看 diff、决定提交或回滚。
cd ~/projects/your-repo
git status `--short` # 确认起点干净
# 下只改一个文件的任务
git diff `--stat` # 看动了哪些文件
git diff -- src/format.js # 看具体改了什么
# 结果可用：git add -p && git commit
# 结果不可用：git restore src/format.js这条链路稳定之后再逐步放开范围，比如一次两个文件、一次一个目录。每次放开之前，先保证上一次的 diff 你能完整看懂，这样即使工具出错，回滚成本也始终停在一个可控的量级。