判断标准不在于「有没有看懂每一行」，而在于能否说清三件事：这次改动动了哪些文件、原有行为是否仍然成立、有没有带来额外的依赖或配置副作用。MiniMax Code 这类 Agent 给出的改动，通常会在完成任务的同时夹带格式化、重命名和顺手重构；因此核对顺序建议按波及面、逐行逻辑、依赖配置、测试结果的顺序向下走，每一层都有命令行证据作为依据，而不是凭感觉判断「看起来没问题」。只扫一眼就合并的最大风险，是那些藏在无关行里的行为变化。
核对到能回答「改了什么范围、原有测试或构建是否仍通过、是否新增依赖与配置项」这三问，就可以合并；只看了 diff 标题和文件列表就提交，属于核对不足。波及面用 git status 与 git diff `--stat` 判断，逐行逻辑用逐文件 git diff 判断，行为用项目原有构建或测试命令判断，副作用用依赖清单与配置文件 diff 判断。任一层出现超范围改动或无法解释的失败，先要求 Agent 还原，再重新核对，不要合并。
先看改动波及了哪些文件
把改动范围与任务描述对齐，是成本最低的一次筛选。建议在仓库根目录先跑下面两条命令，分别看工作区状态和每个文件的增删行数：
git status `--short`
git diff `--stat`
git diff `--stat` `--cached`读 git status `--short` 时重点看三件事：文件是否全都落在预期目录内；有没有出现 dist/、构建产物、日志、临时文件这类不该进提交的内容；有没有未跟踪的新文件（??）被 Agent 顺手创建。读 git diff `--stat` 时，关注新增或删除行数明显偏大的文件——一个「只改提示文案」的任务如果出现某个文件几百行变动，通常是整文件重写、换行符变化或格式化，而非真实逻辑改动。锁文件、压缩产物、二进制文件出现在列表里，建议单独拎出来判断是否必要。
可以先在纸上或备注里写出「预期改动文件清单」，再与命令输出对照。超出清单的文件，进入下一层逐一确认。
逐文件读 diff，揪出顺手改的无关行
确定文件列表后，按文件逐个看，而不是从头滚到尾：
git diff -- path/to/file
git diff -w -- path/to/file
git diff `--word-diff` -- path/to/file-w 会忽略纯空白差异，用来排除缩进调整带来的噪声；`--word-diff` 适合长行或单行改动较多的文件，能把变化定位到词。常见与任务无关的改动特征包括：整文件缩进、引号或分号风格变化；import 或 require 顺序被打乱；变量、函数、文件被重命名但没有逻辑差异；注释被翻译、删除或重写；顺手删掉调试日志时改动了相邻逻辑；行尾符或文件末尾换行变化导致整文件标红。这些改动本身不致命，但会掩盖真实变更，也让后续排查变难。
发现无关改动，可以直接要求 Agent 还原，提示词建议写明范围与判定标准，并要求重跑命令自证：
请只保留与「任务：修复订单金额取整」直接相关的改动。
把格式化、重命名、注释调整、import 排序等无关修改还原到改动前状态。
不要改动未涉及的文件。
还原后重新执行 git diff `--stat` 并贴出输出。还原之后，建议重新执行一次 git diff `--stat`，确认文件数量和行数都回到符合预期的范围。
跑项目原有的构建或测试命令
不要接受 Agent 自拟的验证方式，先找项目里已经存在的命令。查找顺序建议是：package.json 的 scripts 字段；Makefile、justfile 里的目标；pyproject.toml、pytest.ini、tox.ini；Go 项目的 go test ./...；Maven 或 Gradle 的 test 任务；以及 CI 配置文件里实际执行的那几条命令——CI 配置通常最能反映项目认可的验证口径。
npm test
npm run build
python -m pytest -q
go build ./... && go test ./...失败时不要只看最后一条，先从输出里定位第一个失败用例和它对应的 文件:行号，再用 git diff -- 该文件 对照，判断是改动引入还是环境问题。如果项目本身没有可运行的测试，至少跑一次构建、并尝试启动一次服务或运行一次入口脚本，确认没有加载期错误。
确认是 Agent 改动导致失败、需要退回去重来时，建议先在工作区备份或新建分支，再使用以下命令之一：
git stash push -m "agent-change-backup"
git restore -- .
git checkout -- path/to/file
git reset `--hard` HEADgit reset `--hard` 会丢弃未提交改动，执行前务必先 stash 或提交到临时分支。
检查新增依赖与配置文件的变化
这一层最容易被跳过，但副作用往往留在这里。先看依赖清单文件的 diff：
git diff -- package.json package-lock.json
git diff -- go.mod go.sum
git diff -- requirements.txt pyproject.toml
git diff `--stat` -- .env.example Dockerfile .github/锁文件 diff 常常很长，建议先看 `--stat` 判断是否只是版本号联动，再针对可疑包名搜索。判断影响时看三点：新增包是否真的被代码引用；项目里是否已有等价功能的依赖；版本范围是否被放宽。配置项变更要确认默认值是否改变——超时、重试、并发、路径、环境变量名、权限相关设置的调整，会在其他环境里产生不同表现。
需要额外确认的几类改动包括：出现来源不明的间接依赖；postinstall、prepare 之类的生命周期脚本被修改；CI 配置或构建脚本被调整；数据库连接、密钥相关字段被新增。这些改动建议由人明确确认后再合并，不要因为测试通过就默认无害。
把核对结论写进提交信息再合并
核对过程如果只存在于聊天记录里，下次回看就没了依据。建议把结论压成三条写进提交信息：
fix(cart): 修复优惠券叠加时金额取整偏差
范围：src/cart/price.ts、tests/cart.test.ts
验证：npm test 通过；npm run build 通过
遗留：夜间折扣分支未覆盖测试，本次未改动三项内容分别是：改动范围（涉及哪些文件、是否已剔除无关改动）；验证结果（跑了哪条命令、结果如何）；遗留问题（未覆盖的分支、未确认的配置影响、需要后续跟进的事项）。如果验证没跑通而先合并，建议在遗留一项里写明原因和补验证的方式，别留空。
提交信息写完再执行合并。这样即便后续出问题，git log 里也能直接看到当时的判断依据，而不是重新猜一遍 Agent 改了什么。