提交前的三分钟检查：确认 Claude Code 改动了哪些范围再 commit

周五傍晚，我跟 Claude Code 说了句「帮我把文章里那个按钮的文案改一下就行」。回头一看 git status，改动文件居然有 18 个。说好只改文案，结果商品链接的映射表、相关文章的插入位置、还有它「顺手一起改了」的翻译文件，全都列在那儿。

单看每一处，都是它「好心帮我做了」的改动。可要是当时全部一股脑 commit 进去，连我另一个任务里还没保存的修改都会被卷进来，第二天部署时就会冒出一个找不到原因的报错，半天时间就这么没了。

越聪明的 AI，越容易把你交代的范围悄悄做超出去。它没有恶意。正因为如此，在「确定下来」之前，必须留一个停顿：到这里先停住，让人用眼睛过一遍。

本文要点

• Claude Code 哪怕完全照你说的做，动手的范围也会悄悄变大。提交前的确认，就是专门来抓这种「越界」的。
• 确认走固定的三分钟流程：确认范围 → 看 diff → 验证 → 挑文件 stage，一共四步。
• 交给 AI 的是「执行改动」，由人来判断的是「这次 commit 到底收进哪些」。这两件事别混在一起。
• 文中放了可以直接复制的确认脚本，把 git status 和 diff 摘要凑在一屏里，少漏东西。
• 不要因为 build 通过就放心。上线后的实际显示、翻译的具体内容，还得换一双眼睛去看。

为什么要把确认放在「快要 commit」的那一刻

确认的时机，既不是动手之前，也不是干到一半，而是 commit 的前一刻最管用。道理很简单：AI 实际碰过哪些文件，这张全景图只有在那一瞬间才真正定下来。

开始前你再怎么叮嘱「只动这里」，AI 在干活时还是会对那些它觉得「顺手一起改了更好」的地方下手。中途停下来又没法看，因为活儿还没干完，你都不知道该盯哪儿。等全部做完、就差临门一脚 commit 的时候，你才第一次能把「我交代的」和「实际变了的」摆在一起对照。

我最常翻车的，是跟收入相关的部分。比如商品页的链接错了一个字符，点进去的读者就被甩到「页面不存在」。文章写得再好，链接死了，这单生意也就到此为止了。所以我看 diff 时，第一件事就是确认链接的目标地址有没有被动过。

如果你连 Claude Code 的基本用法都还没摸熟，建议先看 Claude Code 入门指南，把整体脉络理清楚，这套确认流程的意义才会清晰起来。

三分钟跑完的确认顺序

每天坚持不下来就没意义，所以我把步骤压到四步。它不是一份完美的审计，只是一道轻量的安全闸。

1. 把范围说出口。 这次的需求是什么，用一句话重述一遍，比如「改文章按钮的文案」。这句话就是后面所有判断的尺子。
2. 看改动文件清单。 用 git status 确认改了哪些文件。只要有文件超出了那句话划定的范围，就在心里给它贴张便签、做个记号。
3. 读做了记号的文件 diff。 只看范围外的那几个文件的内容。好心的改动就留下，不相干的改动这次就先剔出去——一个一个地拿主意。
4. 只挑需要的文件去 stage。 别用 git add . 全收。只把这次需求真正需要的文件，点名加进去。

关键在第 3 步。不要把 AI 扩大的范围简化成「全部接受」或「全部拒绝」的二选一。每个文件，留还是剔，都由人一个个决定。听着不起眼，可一旦跳过这步，开头那场 18 个文件的事故就会上演。

哪些交给 AI，哪些由人来判断

这条线一旦含糊，确认本身就成了走过场。我是这么分的。

要做的事	谁来做	理由
执行文案或代码的修改	AI	量大，机械性地干就行
修语法错误和明显笔误	AI	规则清楚，容易自动化
决定改动是否收进本次 commit	人	只有人知道需求的真实意图
确认链接目标和上线后的显示	人	build 过了也不保证内容对
删除、生产数据、计费相关的操作	人	不可逆的事故必须人工确认

如果连「要不要收进来」都交给 AI，它会理所当然地把自己改过的东西全收进去。判断权一定留在自己手里——这是减少事故最关键的窍门。

可以直接复制的提示词模板

让 AI 帮忙确认时，诀窍是别让它「自我打分」，而是让它「把事实摆出来」。下面这段模板可以原样贴进去用。

我准备 commit 了。在确定下来之前，请你只报告以下事实，判断由我来做。

1. 用一句话概括这次的需求
2. 用 git status 列出被修改的文件（包括未追踪的）
3. 其中，哪些文件看起来超出了第 1 条那句话的范围，以及理由
4. 如果有改动可能影响链接或上线后的显示，指出具体位置

请不要写「没有问题」。只把判断材料摆出来就行。

最后一句很关键。不加这句，AI 就会舒舒服服地总结成「没什么问题，可以放心提交」，确认的意义当场归零。提示词的具体搭法，我在 提示词工程进阶篇 里写得更细。

可以直接跑的确认脚本

每次手动敲 git status 再敲 git diff 太烦，所以我放一个把改动全景塞进一屏的脚本。PowerShell 和 bash 两版都备好了。它做的事只有一件：把「改动文件清单」和「每个文件增删了多少行」排在一起。

PowerShell 版（Windows）。

# precommit-check.ps1
# 在 commit 前，把改动文件和改动量凑在一屏里确认

Write-Host "=== 这次动过的文件 ===" -ForegroundColor Cyan
git status --short

Write-Host "`n=== 各文件的改动量（新增 / 删除）===" -ForegroundColor Cyan
git diff --stat HEAD

Write-Host "`n=== 确认清单 ===" -ForegroundColor Yellow
@(
  "能用一句话说清需求",
  "没有范围外的文件混进来",
  "看过了链接目标和上线后的显示",
  "只 stage 这次需要的文件"
) | ForEach-Object { Write-Host "  [ ] $_" }

bash 版（macOS / Linux / Git Bash）。

#!/usr/bin/env bash
# precommit-check.sh
# 在 commit 前，把改动文件和改动量凑在一屏里确认

echo "=== 这次动过的文件 ==="
git status --short

echo ""
echo "=== 各文件的改动量（新增 / 删除）==="
git diff --stat HEAD

echo ""
echo "=== 确认清单 ==="
for item in \
  "能用一句话说清需求" \
  "没有范围外的文件混进来" \
  "看过了链接目标和上线后的显示" \
  "只 stage 这次需要的文件"; do
  echo "  [ ] $item"
done

跑起来就这一句。

bash precommit-check.sh

这个脚本不替你做任何判断。为了守住「判断归人」这条底线，我故意让它「只摆出来给你看」。清单四项全打勾后，再用 git add 文件名 把需要的文件挑进去，然后 commit。

三个实战派得上用场的场景

1. 文章或资料上线前。 一口气发布多语言文章时，有时翻译文件还停在英文原文。build 能过，可内容根本没翻。别光看 diff 里的文件名就满足，要在上线后的页面上把正文语言也核一遍。

2. 重写已有文件。 本想改文案，结果连页面里的链接、商品名都一起被改了。只要事先用一句话把范围定成「改文案」，链接的改动就属于范围外，能让你停下来想一想。

3. 团队导入时。 把 Claude Code 自动走到哪、在哪一步停下来问人，都记录下来。审批规则（哪些操作可以自动推进、哪些必须问人）要是一直含糊地用着，每个成员翻车的方式都不一样，最后根本收不了场。

常见的坑和补救办法

坑 1：用 git add . 把所有东西都收进去。 这会把另一个任务里还没保存的改动也一起卷进来。补救很简单：别用 .，养成点名 stage 文件的习惯。哪怕觉得麻烦，这也是最快的一道保险。

坑 2：build 过了就放心。 build 只看语法，不看链接对不对、翻译有没有把内容真的翻出来。补救办法是把上线后的页面实际打开，用眼睛核对标题、正文、链接目标。机器的合格和人的合格，是两码事。

坑 3：问一句 AI「有问题吗」就完事。 你一问，AI 多半会答「没问题」。补救办法是像前面那个提示词模板那样，要求它「别写判断，只摆事实」。把判断的主语交还给人，确认才开始真正起作用。

想把确认变成稳定习惯，Claude Code 提效技巧 里也有总结。--stat 这类 git 的官方行为，可以在 Git 官方文档 里查证。

常见问题

问：哪有时间每次都花三分钟确认？ 答：改动小的日子，一分钟就完了。要花到三分钟，说明范围外的文件多，而那恰恰就是需要确认的日子。花的时间长短，就当成危险程度的晴雨表。

问：能不能连 stage 都交给 AI？ 答：如果是已经确定安全的小活儿，交给它也行。但「这次收进哪些文件」这个最终判断，建议还是留在人手里。这里最容易成为事故的入口。

问：commit message 该写什么？ 答：两样东西——「改了什么」和「用什么验证的」。比如「修改按钮文案，已在上线后页面确认链接目标」。日后回看时，有没有确认过一眼就能看出来。

问：范围外的那个文件，其实是该改的好改动怎么办？ 答：那也先剔出去。只是拆成另一个 commit，又不是删掉。守住「一个 commit 一个意图」，以后追溯起来才省事。

实际试下来的结果

经历过开头那场 18 个文件的事故后，我把这四步固定塞进了每次 commit 前。试的是文章发布、文件重写、配置修改这三种情况。

最管用的，是第一步「把需求重述成一句话」。光是说出口，范围外的文件就会自己跳进视野。把跑完确认脚本后顺手敲 git add . 的习惯改成点名 stage 文件，卷进别的任务的事故就归零了。

还有件出乎意料的事：把问 AI 的方式从「有问题吗」换成「只摆事实」之后，同一个 AI 突然变成了一个有用的确认搭档。与其去找更聪明的 AI，不如把确认的主语交还给人。这对我来说是最不起眼、却最见效的一招。

如果你想把权限设计和上线前检查落实到整个团队的日常流程里，我在 培训・咨询 里会和你一起把具体方案搭起来。