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万行噪音里的故事，还会反复上演。