术语 · 工程与协作

代码差异

Diff

代码修改前后的差异,是检查 AI 实际改了什么的最直接依据。

改动前后,逐行摆在眼前

汇报会漏,事实不会
每行改动,过目再放行
Diff 把两个版本逐行对比:新增的、删掉的、改过的分别标出来——检查 AI 实际改了什么,看这个最直接。

换个角度想

Diff 像合同的修订模式:新加的条款标出来、删掉的划横线。不看修订直接签字,等于没审。

AI 说「只改了按钮」,事实是吗?

  1. 你对 AI 说

    需求「只把按钮改成蓝色」

    AI「已完成 ✓」

  2. 这一步被跳过——
    「看起来能用就行」

    新旧版本逐行对比

    发现有两个文件被改动

  3. 页面上按钮确实蓝了

    其他改动?没人知道

    改动清单

    button.css+2 行 · 预期内

    login.js−5 行 · 没让它动!

  4. 三天后爆雷用户反馈登录失效,排查半天才想起这次修改没审的改动,迟早找上门
    当场拦下让 AI 恢复 login.js,只保留按钮改动Diff 在手,AI 干了什么心里有数

代码发生了修改

什么时候会遇到它

  1. 检查 AI 的实际改动

    AI 的描述和实际改动可能对不上,Diff 才是事实。

  2. 代码评审

    PR 评审看的就是 Diff,逐行讨论、逐行放行。

  3. 定位意外变化

    功能突然坏了,先 diff 一下最近的改动。

想一想

你让 AI「只把按钮改成蓝色」,diff 里却看到它还动了登录逻辑。接下来该怎么办?

看答案

这正是看 diff 的价值:范围外的改动被抓了现行。让 AI 撤销无关修改,只保留按钮那部分——别因为功能「看起来正常」就照单全收。

最容易踩的坑

不看 Diff 直接接受 AI 的修改,等于没审合同就签字。改动越大越要看,尤其是删除的部分。

⌘K搜索知识库

最近收录

正在载入知识索引…