把改动交付成可审阅的 diff

Agent 做完修改后，你要接收的是代码状态，不是最后一条回复。尤其当工作区本来就不干净时，“这些文件都变了”并不意味着它们都属于本次任务。

先分清三份差异

git status --short
git diff --stat
git diff
git diff --cached

这些只读命令分别帮助查看状态、未暂存变更概要、未暂存内容和已暂存内容。只看 git diff 会遗漏已经暂存的改动；未跟踪文件也需要单独审阅，不能因为 diff 没列出就忽略。

不要执行 git add . 来“方便查看”，更不要清空工作区来制造一个干净起点。

假设用户之前修改了 globals.css，现在让 AI 重写两篇笔记：

本轮范围：两篇 MDX 的内容与阅读顺序。
已存在：globals.css 的页面样式调整，不属于本轮。
 
交付时：
- 审阅本轮两篇文章与索引的变更；
- 说明构建使用了整个当前工作区；
- 不把旧样式变化算成本轮成果，也不撤销它。

如果必须修改一份已有变更的文件，先读懂重叠部分，保留用户改动。无法安全区分时，指出具体段落再协调，不用“整个文件都是我的改动”概括。

审阅时优先找四类问题：

格式调整不一定错误，但大量无关格式化会遮住实际行为变化。单独处理，或者减少到本次必要范围。

可以先让 AI 起草，不创建外部 PR：

## 背景
说明用户遇到什么问题，以及可复现条件。
 
## 变化
按行为说明改了什么，哪些行为刻意保持不变。
 
## 验证
实际运行的命令、测试结果、页面与视口。
未运行项另列，不写成通过。
 
## 风险
兼容影响、未覆盖场景、回滚注意事项。

上面是模板，不是本次真实验证记录。填写时应来自实际执行证据。

依赖安装、lint、测试、构建和部署是不同阶段。遇到失败后，先保留失败日志与当前代码版本，再运行最窄的相关检查。

例如线上 CI 使用 Node 版本与本地不同，先核对配置；不要直接把某个测试标为跳过。如果确实是测试期待与新业务规则不一致，应引用已确认的需求来修改预期，不能仅因当前实现输出不同就认为测试错了。

本地修完后，重跑原失败检查。CI 是否真正转绿，要看新的 CI 结果，不能拿本地成功代替远程状态。

这样既保留 AI 执行工作的价值，也避免把一次本地任务扩展成影响其他人的操作。