# AI 改了一行，你審的卻是整份檔案？Cursor 官方沒說出口的真相：預設 diff 正在騙你 這是 Tech Insider 2026 年 10 月 … · @swordBluesy · TwKit

@swordBluesy

# AI 改了一行，你審的卻是整份檔案？Cursor 官方沒說出口的真相：預設 diff 正在騙你 這是 Tech Insider 2026 年 10 月 29 日發的實作教程，標題直譯是《Cursor 程式碼編輯器：審查 diff，13 步，45 分鐘》。先把結論放在前面，因為它反常識： **你以為自己在審「改了什麼」，其實很多時候你只是在審 Git 預設演算法「怎麼呈現改了什麼」——同一份改動換個演算法看，1 行補丁和整檔重寫的差別才會現形。** 先說清詞。**diff（差異比對）**，是把改動前後的檔案逐行對照、標出刪了什麼、加了什麼的結果；**Myers 演算法（Myers algorithm）**，是 Git 預設的比對演算法，追求最短的編輯路徑；**histogram 演算法（histogram algorithm）**，是另一種比對演算法，更看重程式碼的結構，寧可多顯示幾行，也要把「整塊搬動」講清楚；**hunk（差異區塊）**，是 diff 裡連續的一組改動行；**churn（變動率）**，是改動行數佔原檔行數的比例。 一個真實例子：39 行的 http://orders.py 只加了一行折扣，diff 是乾淨的 1 行；同一功能若由 AI 整檔重寫交回來，就變成 7 個區塊、23 行新增、18 行刪除。兩份在編輯器裡看起來都「很正常」，只有一份值得你花全力去審。 他們還點名了一種「眼熟的流程」：先叫 AI 改，再憑感覺掃一遍 diff，覺得紅綠不多就合併。問題是，AI 交回檔案有兩種方式：一種是精準的搜尋取代補丁（patch），只動該動的地方；一種是整檔覆寫（rewrite），順手把引號、縮排、型別標註、函式順序全換一遍。你問它「加個折扣」，它交回來的可能是「順便重構了半個檔案」。 先把話說全：這套審查法不是要禁絕重寫。符合下面任何一條，重寫就是合理的： - 本來就是新檔案，或機械式遷移； - 本來就是刻意重構，而且提交訊息寫明了； - 你已經逐行看過重寫內容，確認沒有夾帶行為改變。 但除此之外的重寫，都不該以「看起來像一行小修」的樣子溜進歷史。 ## 一、預設 diff 的三種翻車方式 - **交錯區塊藏搬動**：兩個函式只是換了位置，Myers 卻把它顯示成兩個函式的條件和本體都被改過，審查者會以為是邏輯改動，甚至誤報一個不存在的 bug。 - **格式噪音淹沒真改動**：引號、換行、尾端空白、到處補上的 docstring（文件字串，寫在函式開頭說明用途的文字），全和真正的改動混成同一種紅綠。 - **行數少等於好審**：Myers 在換位例子裡只顯示 12 行改動，histogram 顯示 16 行，但後者一眼就能看出「一個函式整塊搬走了」——行數少，反而更難審。 ## 二、替代方案：用四種演算法＋一個評分器看同一份改動 不要只信一種呈現。教程的做法是：同一份改動，用 Myers、minimal（最小編輯演算法）、patience（耐心演算法）、histogram 四種演算法各跑一次，再加一次忽略空白的 histogram 對照。補丁類改動四種演算法結果一致；搬動類改動立刻分叉——patience 和 histogram 都是 2 個區塊、8 加 8 減，講的是「一個函式搬走了」；Myers 是 4 個區塊、6 加 6 減，講的是「兩處被改壞了」。 再補兩招閱讀技巧：看總量時用 `-w`（忽略空白差異）先把尾端空白的噪音濾掉，但做門禁判斷時絕不能用 `-w`——在 Python、YAML、Makefile 裡空白本身就有語意；再用 `--color-moved=dimmed-zebra`（移動行淡色顯示）讓搬動的區塊以淡色出現，真正的新增刪除保持標準紅綠，眼睛立刻知道該跳過哪裡、盯住哪裡。 ## 三、目標形態：一份改動交回來，先有數字再談感覺 目標不是「審得更用力」，而是「先有數字，再決定用多少力」。教程建了一個叫 aidiff-review 的練習專案，內含兩份樣本檔 http://orders.py、cart.js，四條模擬 AI 改動分支：精準補丁、整檔重寫、換位加空白噪音、函式互換，外加一個純標準函式庫寫成的評分器 tools/aidiff.py。評分器對每份改動輸出：各演算法的區塊數與增刪行數、移動行對數、總變動率、淨變動率（扣掉移動行之後真正的新文字比例）、移動佔比，以及一句判決：patch-like（補丁型）、move-heavy（搬動型）或 rewrite-like（重寫型）。預設規則是：淨變動率達到 0.5 判重寫型，移動佔比達到 0.3 判搬動型，其餘判補丁型。 ## 四、遷移步驟：45 分鐘照著做 ### 第一步：建專案與四條分支（約 10 分鐘） 先確認 git 與 python3 可用，建立 aidiff-review/tools 目錄，寫入 39 行的 http://orders.py 與 cart.js，提交為 main 基準，再用示範腳本生成 ai-patch、ai-rewrite、ai-reorder、ai-swap 四條分支，每條分支恰好一個提交，保證每次比對都乾淨。 ### 第二步：親手對照四種演算法（約 10 分鐘） 對 ai-swap 分支先後執行 `git diff --diff-algorithm=myers main ai-swap -- cart.js` 與 histogram 版，親眼看一次「交錯」與「整塊搬動」的差別；再用 `git diff --shortstat` 與 `git diff --shortstat -w` 對照 ai-reorder 分支，看 10 加 9 減如何變成 8 加 7 減——消失的 4 行就是純空白噪音。 ### 第三步：寫評分器並跑四條分支（約 15 分鐘） 把 tools/aidiff.py 存好，對四條分支各跑一次，例如 `python3 tools/aidiff.py --base main --head ai-patch`。先看補丁分支的低變動率，再看重寫分支的高淨變動率，確認判決與你的直覺一致。 ### 第四步：把評分接進工作流程（約 10 分鐘） 在 Cursor 內建終端機設定 Git 預設：histogram 演算法加移動行淡色顯示；每次交給 Agent 任務前先做一個檢查點提交（checkpoint commit），任務完成後先跑評分器再接受改動；最後加一道 pre-commit hook（提交前掛鉤，提交前自動執行的檢查程式），重寫型改動除非你刻意覆寫，否則不准提交。 ## 五、團隊怎麼共建同一套審查標準 規則先行、評分後行：先用 Cursor 規則把 AI 推向「小補丁」風格，再用評分器當檢測——規則是預防，評分是驗收，兩者缺一不可。團隊共用同一份閾值（淨變動率 0.5、移動佔比 0.3）與同一份判決詞，審查時不再各憑感覺說「這份改動有點大」；門禁只攔「沒被認真看過的重寫」，不攔「寫明原因的重寫」，否則團隊很快就會繞過門禁，標準等於作廢。 ## 六、官方工具包 這篇教程本身就是工具包：四條分支的示範腳本、四種演算法的對照表、tools/aidiff.py 評分器（含 --json、--summary、--fail-on-rewrite 選項）、Git 預設設定與 pre-commit 門禁。全部只依賴 Git 與 Python 標準函式庫，不需要模型呼叫、API 金鑰或付費方案，免費版 Cursor 也能跑。注意教程作者坦承：截至 2026 年 10 月 29 日，他找不到 Cursor 官方文件提供「每次編輯是補丁還是重寫」這類遙測數據，所以這套方法檢驗的是落在工作目錄裡的結果，而不是模型內部的請求——這也正是它不挑工具的原因，Cursor、命令列 Agent、同事貼上的程式碼一律適用。 ## 結尾：原則比架構重要 審查的原則只有一句：**先讓改動的真面目現形，再決定要不要信任它**。行數不是證據，區塊結構才是；感覺不是標準，變動率與判決才是。可重複的動作規則是：每次 Agent 交回改動，先跑評分器看判決，再決定是快速放行、重點看搬動處，還是打回重寫——三種判決，三種力道，絕不每次都用同一種力道審所有改動。 原文連結：https://tech-insider.org/cursor-code-editor-git-diff-algorithms-review-ai-rewrites-2026/ 原文：Tech Insider（由 S1哥 編譯） ## S1哥觀點 這篇最狠的地方，是它把矛頭對準了所有人都以為中立的東西：diff 本身。大家吵模型強不強、吵規則寫得好不好，卻沒人懷疑「我看到的改動」是不是改動的真相——預設演算法把搬動講成交錯，你審的根本不是同一件事。 我認為真正的信號是：AI 時代的審查，拼的不是眼力，是儀表。以前人寫的程式碼，改動小就是真的改動小；現在 AI 交檔案，改動小可能只是呈現方式幫它藏起了重寫。沒有評分器的團隊，正在用肉眼為整檔重寫背書而不自知。這和開車不看儀表板只憑感覺踩油門，是一個道理。 所以站隊問題來了：你上一次合併的 AI 改動，到底是補丁還是重寫，你敢不敢拿評分器跑一遍再回答？評論區報一下：你審 AI 改動時，有沒有被整檔重寫騙過？

曝光 111 · 评论 1 · 点赞 0 · 书签 0