Git diff（代码差异对比）每年处理超过100亿次代码提交，却正在把AI编码助手集体带偏。一个为程序员肉眼扫视设计的格式，成了机器理解代码变更的翻译器——结果翻译得稀碎。
问题不是AI不够聪明，是我们给它的说明书写错了。
补丁看起来干净，这是最危险的部分
作者The Atomic Architect最近遇到典型场景：AI助手快速返回了一个修复方案，解释冷静，文件路径正确，甚至触碰到了他预期的问题区域。初看像是那种值得截图发推的"机器终于懂了"时刻。
慢读之后发现，AI修错了方向。它修补了表面症状，却错过了真正变动的核心——逻辑已经迁移，契约已经转移，一条验证规则早已不在diff显示的位置。AI跟着可见的代码变动走，忽略了真正的重心。
这种"优雅的错修"比直接报错更隐蔽。人类审阅者容易被diff的整洁度麻痹，AI则被困在格式本身的设计局限里。
行级对比的结构性盲区
Git diff诞生于2005年，设计目标是让人类快速扫视变更。它按行对比，用"+"和"-"标记增减，默认忽略语义结构。这个格式对程序员肉眼审查足够高效，对AI却是灾难性的信息压缩。
具体缺陷有三层：
第一，行级粒度丢失语义边界。一个函数被拆成5行修改，diff显示为5个独立片段，AI无法识别这是同一逻辑的位移。第二，上下文窗口被浪费。diff把大量无关的邻近代码塞给AI，真正关键的跨文件依赖却被截断。第三，删除与新增的表面等价误导判断。AI看到"删3行、加3行"会假设语义守恒，实际可能是完全替换。
Git的diff算法（Myers算法）优化的是最短编辑脚本，不是语义保真度。换句话说，它回答"怎么改最少"，不回答"改了什么含义"。
行业沉默与替代方案的难产
几乎没人公开讨论这个问题。OpenAI的Codex、Anthropic的Claude Code、GitHub Copilot，底层都依赖git diff或变体格式。产品团队忙于演示生成速度，不愿暴露基础格式的脆弱性。
替代方案存在但未被采纳。Git的--word-diff（词级对比）能减少粒度问题，Tree-sitter等语法解析器能提供AST（抽象语法树）级别的变更描述，Semgrep等工具擅长跨文件追踪。但生态惯性巨大：CI/CD流水线、代码审查界面、开发者肌肉记忆，全部围绕行级diff构建。
更深层的问题是商业优先级。构建语义级diff需要维护多语言解析器，成本远高于调用git命令。AI编码助手的竞争焦点在响应速度和多轮对话，格式精度属于"够用就行"的灰色地带。
一个可能的突围路径
作者提出分层架构设想：保留git diff作为底层存储，但在AI消费层叠加语义解析。具体做法包括用AST diff替代行级diff作为模型输入，引入代码依赖图谱辅助跨文件理解，以及在系统提示词中显式标注"此diff可能掩盖真实变更"。
部分团队已在实验。Cursor的"composer"模式尝试多文件联合生成，Sourcegraph的Cody集成代码智能图谱，Google的内部工具 reportedly 使用自定义变更描述格式。但这些方案尚未形成开源标准，彼此不兼容。
技术债的讽刺在于：我们责怪AI"幻觉"，却给它喂了设计给人类快速浏览的压缩饼干，然后惊讶它营养不良。
下一次AI给出的补丁看起来过于干净时，也许该多问一句——它读懂了代码，还是只读懂了diff？
热门跟贴