2萬行代碼變更，實際只改了47行

GitHub上那個2萬行的拉取請求（Pull Request，代碼合并請求），真實改動只有47行。剩下的20400行，全是格式工具自動生成的噪音——換行、引號、逗號位置。一位開發者盯著屏幕，風扇狂轉，頁面卡頓，花了整個下午才找到真正需要 review 的代碼。

這不是個例。這是每個技術團隊都在默默承受的「噪音稅」。

噪音從何而來

Prettier、ESLint、Black——這些代碼格式化工具本意是統一風格，卻在代碼審查環節制造了新的災難。當有人在提交前對整個倉庫運行格式化工具，diff（代碼差異對比）會爆炸。

GitHub 的「Hide whitespace」開關對此無能為力。因為現代格式化工具做的遠不止空格：它們重排換行、重排導入順序、單雙引號互換。這個開關是為更簡單的時代設計的。

開發者的眼睛被迫成為噪音過濾器。人眼逐行掃描2萬行代碼，尋找其中真正重要的47行——這種工作本該由解析器在幾毫秒內完成。

正方：AST 才是正解

ClearPR 的解決思路很直接：跳過文本對比，直接比較代碼的「語法樹」。

Tree-sitter 將代碼解析為抽象語法樹（Abstract Syntax Tree，AST）——這是 IDE 用來做語法高亮和代碼折疊的同一套數據結構。兩個 AST 結構相同，代碼功能就相同，無論格式如何變化。

Whitespace 差異？同一棵樹。尾隨逗號增減？同一棵樹。單雙引號互換？同一棵樹。導入語句順序重排但集合不變？同一棵樹。

ClearPR 只報告真正改變樹結構的節點。47行就是47行，2萬行的噪音被自動過濾。

部署方式也刻意保持克制：自托管的 GitHub App，Docker 一鍵啟動，代碼只留在自己的服務器和選定的 LLM API，不流向第三方 SaaS。

行為邊界同樣清晰：只發內聯評論，不批準、不阻塞、不請求修改。「因為周五晚上沒人需要 AI 機器人卡著合并按鈕。」

反方：正則更快，為什么不用？

第一版原型確實用了正則。剝離尾隨空格、合并空行、統一引號風格、按字母序排序導入后再做 diff。簡單，快速，能覆蓋80%的無聊場景。

但正則不懂語法。一個剝離尾隨逗號的規則，分不清字符串字面量里的逗號和語法層面的尾隨逗號。一個統一引號的規則，會把 it's 里的撇號當成字符串定界符。

這些「美麗的崩潰」在真實 PR 中幾乎立刻出現。開發者在生產代碼上踩坑后，意識到自己在構建錯誤的東西——用文本層面的啟發式規則，去解決語法層面的問題。

正則的代價是脆弱性。每新增一條規則，就新增一類邊界情況。AST 的代價是前期復雜度，但換來的是對語言語義的真正理解。

判斷：工具設計的邊界意識

ClearPR 的有趣之處不在于技術選型——AST diff 不是新發明，編譯器社區用了幾十年。而在于它對「工具該管到什么程度」的清醒認知。

三個刻意的設計選擇：

第一，只評論，不阻塞。把決策權留給人類，工具只負責降低信息獲取成本。這是對「AI 自動化焦慮」的直接回應——沒人希望周五晚上被機器人卡發布。

第二，自托管優先。代碼不出境，滿足金融、醫療等行業的合規剛性。這不是功能，是準入門檻。

第三，聚焦單一痛點。不做完整的代碼審查，不做安全掃描，不做性能分析——只做「從噪音中提取信號」這一件事。

這個邊界感反過來定義了產品的適用場景：大型代碼庫、多團隊協作、格式化工具強制啟用的組織。在這些場景里，2萬行 diff 不是意外，是日常。ClearPR 把「日?！惯€原成「可處理」。

技術債務的另一種形式，是讓開發者持續為工具鏈的副作用買單。當格式化工具成為基礎設施，過濾其噪音的工具就成為新的基礎設施。這不是過度工程，是分層抽象的自然演進——每一層解決上一層的遺留問題，直到某一層足夠穩定，被收編進平臺本身。

GitHub 會不會內置這個功能？有可能。但在那之前，47行代碼藏在2萬行噪音里的故事，還會反復上演。