改动前后，手动核对一遍 DIFF：小改动的隐性成本

具体场景

你让 AI 改了配置文件，或者手动动了一个 `if` 分支，点上"保存"的那一刻，以下三件事发生了：

1. 那行确实按预期改了

2. 旁边还有两行你没注意，原来格式有误，现已悄然变化

3. 文件末尾多了一个空行，下一次 diff 时会误报新增

代码通过了，逻辑正确，但下次代码审查时别人问你"这个空行是什么"，你答不上来。**改动前后的 DIFF 核对，就是用来发现这种问题的。**

什么时候用它

- **改动很小**（同一文件或相邻文件，几行到几十行），但涉及共享资源

- **你不确定你的操作系统 / AI 工具会不会顺手修改你没有预期变更的行**（格式规整器、自动换行、BOM 处理）

- **代码即将提交**，你想在他人审查之前自己先验一遍

- **让 AI 改完代码，你说你逐行审查了，但没有用 diff 工具做过最终确认**

- **文件参与了多轮修改**，你终于要合并，但你想确认历史改动都还在

什么时候可以略过

- 你很清楚你在改什么，改动单点明确，不涉及共享状态

- 自动化 CI 已有 diff 阶段且其规则与你的预期完全一致

- 你只改了纯文档 / 注释 / 空行，不影响逻辑

- 文件的修复器 / 格式化器你全程手控，且 CI 没有 diff 拦截

怎么操作（3 步走）

步骤 1：改动前，留一份快照

在动手之前，用一条命令把当前文件的状态固定下来：

cp path/to/file.yaml /tmp/file-before.yaml

步骤 2：改动后，统一 DIFF

改动完成后，跑一次 diff，肉眼过一遍：

diff --unified=3 /tmp/file-before.yaml path/to/file.yaml

重点回答：

- [ ] 新增的行，是我预期要加的吗？

- [ ] 删除的行，是我预期要删的吗？

- [ ] 已变更的行，改动内容是否最小？

- [ ] 有没有我完全没有触碰的行，却出现了改动？（格式、空行、BOM）

- [ ] 文件末尾是否正确结束？（无多余空行 / 需要正确结尾）

步骤 3：按 DIFF 修复，再 DIFF 一次

发现意外改动之后，按预期行的内容修复，保存后，再跑一次 diff。

这一次的目的是：**确认你的最终改动与你的预期改动是一致的，不多不少。**

检查表（提交前过一遍）

- [ ] 我列出了这次改动预期触及的每一行（或每一组行）

- [ ] 实际 diff 里的每一行变化，都在我的预期列表里

- [ ] 没有我完全没触碰的行出现在 diff 里

- [ ] 文件末尾格式正确（无多余空行，BOM 状态与原文件一致）

- [ ] 如果文件有格式化器（或 lint 规则），我没有在提交后被动地格式改变内容

- [ ] 如果这次改动涉及多个文件，我对每个文件都做过同样的 3 步

常见陷阱

| 陷阱 | 表现 | 修复 |

|------|------|------|

| 空行误删 | diff 显示出几行空白变化，你看不出为什么 | 对齐改动前后快照，逐字节核对 |

| BOM 变化 | 某些编辑器 / CI 会添加 / 删除 UTF-8 BOM，hex 才能看出差异 | 用 `xxd path/file \| head -1` 对比改动前后的前 3 字节 |

| 行尾符变化 | LF / CRLF 差异，普通 diff 不会报错 | `file path/file` 检查行结尾类型，确保与原文件一致 |

| 格式化器被动触发 | 保存动作触发了自动格式化，格式变化没出现在你的预期里 | 关闭编辑器自动格式化，或格式化之后再 diff 一次 |

| AI 顺手修改 | AI 改完代码的同时，把注释 / 空行 / 代码顺序也顺了一下 | 明确要求 AI 只改指定行，然后 diff 核对 |

一个例子

# 改动前：/tmp/file-before.yaml
server:
  host: 127.0.0.1
  port: 8080
  # 缓存配置
  cache_enabled: true

# 预期改动：只改 port 为 8081
# 改动后（AI 做的）：
server:
  host: 127.0.0.1
  port: 8081
  cache_enabled: true
deleted_key: something_unused

# diff 结果：
#   @@ -2,5 +2,5 @@
# -    port: 8080
# -    # 缓存配置
# -    cache_enabled: true
# +    port: 8081
# +    cache_enabled: true
# +deleted_key: something_unused

预期改动只有 1 行（port 8080 → 8081），实际 diff 出了 3 处变化：删了注释，加了 `deleted_key`。**如果这个文件进入 CI 的审查者手里，你会被问"这行注释怎么会没的"。**

手动核对一遍，5 分钟修好，比事后在审查里被问强很多。