MiniMax Code CLI 改出来的代码能不能直接信，取决于你有没有把审阅节点放在提交之前。比较稳的接法是：先让它只读、把项目结构摸清楚，再用一个小需求跑通「改—跑—测」闭环，然后逐个文件看 diff，最后决定是部分提交、整体还原，还是先扔到分支上。
判断标准有三条：改动是否落在需求范围内的文件、测试是否真跑过、diff 是否能被逐行读懂。适用场景是本地已有 git 仓库的项目，操作上先隔离工作区，再用 git diff 分文件复核。风险边界是它可能顺带重构无关文件，这类改动先还原、再单独讨论，不要混进同一次提交。
让它先读项目结构再动手
在不了解目录组织的情况下让它动手，最常见的后果是文件放错位置、入口找错、测试跑不起来。所以第一步用只读提示词把它的注意力钉在结构上：
先不要修改任何文件。请完成三件事：
1. 列出仓库根目录和 src/ 下两级目录；
2. 标出入口文件、配置文件、测试目录的位置；
3. 给出你接下来计划读取的文件清单，并逐个说明为什么需要读。
输出完先等我确认，再动手。把 src/ 换成你项目的主源码目录，把测试目录名换成 tests/、__tests__/ 或 spec/。计划读的文件清单如果明显跑偏（比如它盯上构建产物），说明结构提示还不够，先补充说明再放行。
记录它实际读了哪些文件，优先看会话日志或工具调用输出。多数这类 CLI 会打印读取目录、读取文件的调用记录，把标准输出落盘即可：
# 命令名与参数以你本地 `--help` 为准
minimax-code <你的参数> 2>&1 | tee session.log
git status `--short`如果当前版本没有调用日志，可以退一步让它把读过的文件以列表回显，再用 git status `--short` 对照改动范围。要提醒的是，自报的清单只能当线索，不能当证据；真正可信的是日志和仓库状态。
用一个小需求跑完整的改-跑-测循环
选一个几十行以内的需求，例如给某个函数加一个边界判断、给某个接口补一个参数校验。任务描述模板：
目标：为 <模块> 增加 <具体行为>
允许修改：src/<模块>/
不要修改：依赖清单、lock 文件、其他模块
验收：<测试命令> 全部通过
完成后请输出：改动的文件清单 + 每处改动的理由测试命令按语言替换，比如 npm test -- `--run`、pnpm vitest run、pytest -q tests/test_x.py、go test ./...、cargo test。动手之前先跑一次基线并记下结果，否则失败出现时你分不清是它引入的，还是本来就不绿。
测试失败后，把失败断言和堆栈直接贴回去，并加一句约束：
这是刚才的失败输出：
<粘贴失败断言与堆栈>
只修改导致失败的相关文件，不要重写整个模块，
不要修改测试用例来让它变绿。最后这条约束很关键。它顺手改测试来通过验收，是这类工具最容易越界的一种行为，日志截断时保留失败断言和堆栈即可，不必把几千行输出全塞进去。
逐个文件审 diff，标出顺带改动
先用 git status `--short` 看改动范围，再用 git diff `--stat` 看每个文件改了多少行。行数和需求规模明显不匹配的文件，优先打开细看；已经暂存的部分单独看：
git status `--short`
git diff `--stat`
git diff -- src/a.ts
git diff `--cached` -- src/a.ts顺带改动的典型形态：整文件重新格式化、重命名与需求无关的变量、调整依赖版本、删除「看起来没用」的代码、顺手改注释和字符串。判断时问一句：这处改动和需求有因果关系吗？没有因果关系的，保留至少要满足两条——改动小且能读懂、有测试覆盖、能独立成一次提交、你能一句话说清它的收益。不满足就先还原：
git restore -- src/a.ts
# 老版本 git 用：git checkout -- src/a.ts注意 git restore 会丢掉该文件全部未提交改动。如果里面还混着你要保留的部分，先 git add -p 把要留的块暂存，或者用 git stash push -u -m 'review' 存一份再还原。
在提交与丢弃之间做出选择
选择性提交的思路是：只把需求内的文件放进暂存区，工作区剩下的脏文件不参与本次提交。
git add -p # 逐块确认，混改文件用这个
git add src/a.ts src/b.ts # 文件级隔离
l gt;git commit -m 'feat: xxx'整体放弃：git restore .（老版本 git checkout -- .）。这个命令管不到未跟踪的新文件，先 git clean -n 看清楚会删什么，确认后再考虑 git clean -f。还想留个念想的，用 git stash push -u -m 'code-cli 尝试'，之后随时 git stash list 找回来。
分支处理和主分支处理的差别在于回退成本。在分支上试（git switch -c try/xxx），不满意就切回去删分支，不会污染主干历史；直接在主干改，就得提前打点——先把干净状态提交掉，再让 CLI 动手，提交前把顺带改动清出去。团队仓库里更推荐前者，尤其是还摸不准它的改动风格时。
把跑顺的提示词和命令记成清单
把下面几条存成自己的片段（比如仓库里的 docs/code-cli-notes.md），下次同类任务直接复制，不用每次重想：
- 结构摸底：只读提示词 +
tee session.log+git status `--short`，确认它读的文件和理由是否合理。 - 小需求改-跑-测：目标 / 允许修改 / 不要修改 / 验收命令 / 输出要求五段模板，配套
npm test -- `--run`或pytest -q、go test ./...。跑前先记基线。 - 失败回灌：粘贴失败断言与堆栈，附加约束「只改相关文件、不许改测试让它变绿」。
- 分文件审 diff：
git status `--short`→git diff `--stat`→git diff -- <path>→git diff `--cached` -- <path>，逐文件过一遍再决定留哪些。 - 收尾三选一：要留的
git add -p && git commit；顺带改动git restore -- <path>；整体放弃git stash push -u -m 'code-cli 尝试'或切回原分支删掉试错分支。
具体参数名和日志格式建议用本地 `--help` 和一次真实运行确认，不同版本可能不一样；命令与流程本身不依赖具体版本，换工具也能照搬。