工作流
审 AI 改动时，让助手交齐三份 Git 证据
工作区、暂存区和未跟踪文件，要用不同入口检查。
资料核验2026.11.12 · Git · 已有版本历史的项目
助手说只改了两个文件，你跑一遍 git diff，终端却什么都没打印。先别下结论。改动可能已经进了暂存区，也可能是两个新文件，还没被 Git 跟踪。
交给编码助手的任务
给助手一个故意混放三种状态的测试仓库：已暂存配置、未暂存组件、新增测试数据。要求它列出三组路径和每组的核对命令，再解释哪几处会进入下一次提交。
让三条命令各回答一个问题
先用 git status --short 看有哪些文件和新路径。再用 git diff 看还没暂存的修改，用 git diff --cached 看即将提交的内容。未跟踪文件要另行打开。对新建的配置、测试数据和截图尤其要这样做，它们往往最容易漏审。
如果任务开始前已有你的改动，动手前记录一次状态。看同一文件时，直接核对本次目标涉及的片段，避免把自己的半成品算到这次交付里。
审查输出最好写成能复查的结论，比如「新增两份测试数据，暂存区未改，主逻辑只有一处差异」。
先准备一个对照样例
在临时仓库暂存 app.config.js，改动但不暂存 Header.tsx，再新建 sample.json。让助手分别列出文件及差异来源。漏掉任意一组时，先补状态读取和具体比较命令，再讨论代码质量。
用这些结果验收
- 工作区差异能看到组件。
- 暂存区差异能看到配置。
- 状态能找到新测试文件，并额外打开文件检查内容。
审查时容易漏掉什么
遇到「git diff 没输出」时追问它看的是哪个比较范围。对原来就存在的修改，记录任务开始前的状态并把它和本次改动分开审阅。不要为了得到干净状态而替用户恢复或删除文件。
看已暂存和未暂存内容时，用同一个文件制造两次不同编辑也值得试一次。要求助手明确说哪一段会进入提交、哪一段还留在工作区。如果结论来自 git diff HEAD，再用分开的两个 diff 区分它们，否则容易误交未完成的工作。
让助手把状态中标记为未跟踪的文件另列出来，再打开确认。后两条命令不会把这些文件的正文带进差异。
git status --short
git diff
git diff --cached
