用途：把 git 改动切成外科手术式的补丁文件，每个补丁只承载一个连贯改动、影响范围最小，并在导出前至少跑一个反馈信号。它把补丁视为依赖基线的传输产物（上下文敏感的 diff），而非可交换的合并原子，目标是让补丁小、可审查、尽量能干净应用。
主要能力：明确补丁的预期基线（通常为 HEAD）；优先非交互式暂存；提供 scripts/micro_scope.py 辅助比较已暂存与未暂存规模；支持两种输出格式——默认从索引生成 git apply 风格补丁，可选 git am/email 风格（需提交），除非用户明确要求 format-patch，否则走非提交路径。
使用方式：先 git status -sb、git diff 检查，再用 git add <paths...> 或 git restore --staged <paths...> 精确暂存，并用 git diff --cached 核对。导出时选择路径如 patches/0001-<slug>.patch，执行 git diff --cached --binary --no-ext-diff --no-textconv --no-color > <patch-path>，用 test -s 确认非空。验证分两级：快速本地一致性检查 git apply --check --reverse --binary <patch-path>；对外分享时用干净基线检查，先 git worktree add --detach <tmp-dir> HEAD，在临时目录内 git apply --check --binary <patch-path>，再 git worktree remove <tmp-dir>。除非用户要求，保持已暂存改动不变。
适用场景：被要求“拆成微补丁”“只暂存最小改动并生成补丁文件”“保持补丁小且检查通过”时。
限制：git 风格补丁不可交换、不可结合、通常不幂等，必须显式声明基线并保持补丁极小；非交互环境无法做 hunk 级暂存时需用户本地暂存或提供补丁；仓库测试/检查命令不可发现时应询问；导出前需排查密钥，疑似含密则停止并询问；不得擅自扩大范围、覆盖已有补丁文件，或在没有通过信号和至少一次补丁验证前声称完成。补丁身份可用 git patch-id --stable 近似去重，但非密码学保证。