工程与协作
代码差异Diff
你可能会问
代码差异到底是什么？AI 说「改好了」，我怎么知道它到底动了哪里？
简单来说
代码修改前后的差异，是检查 AI 实际改了什么的最直接依据。
AI 的汇报Diff 的事实汇报会漏，事实不会
照单全收逐行过目每行改动，过目再放行
01 · 先这样理解
把抽象概念放进真实场景
代码修改前后的差异，是检查 AI 实际改了什么的最直接依据。
换个角度想Diff 像合同的修订模式：新加的条款标出来、删掉的划横线。不看修订直接签字，等于没审。
02 · 点击演示
AI 说「只改了按钮」，事实是吗？
突出显示的部分，就是当前概念在整条流程中负责的位置。
- 你对 AI 说
需求「只把按钮改成蓝色」AI「已完成 ✓」 - 这一步被跳过——
「看起来能用就行」新旧版本逐行对比
发现有两个文件被改动
页面上按钮确实蓝了
其他改动？没人知道
改动清单button.css+2 行 · 预期内login.js−5 行 · 没让它动！- 三天后爆雷用户反馈登录失效，排查半天才想起这次修改没审的改动，迟早找上门当场拦下让 AI 恢复 login.js，只保留按钮改动Diff 在手，AI 干了什么心里有数
1 / 4
Change · 代码发生了修改
03 · 放进真实任务
什么时候会遇到它
检查 AI 的实际改动
AI 的描述和实际改动可能对不上，Diff 才是事实。
代码评审
PR 评审看的就是 Diff，逐行讨论、逐行放行。
定位意外变化
功能突然坏了，先 diff 一下最近的改动。
04 · 想一想
用一个问题检查理解
你让 AI「只把按钮改成蓝色」，diff 里却看到它还动了登录逻辑。接下来该怎么办？
查看答案
这正是看 diff 的价值：范围外的改动被抓了现行。让 AI 撤销无关修改，只保留按钮那部分——别因为功能「看起来正常」就照单全收。
最容易踩的坑
不看 Diff 直接接受 AI 的修改，等于没审合同就签字。改动越大越要看，尤其是删除的部分。