diff
版本控制中的基础概念，以统一格式呈现两次版本之间的差异，以`-`表示删除行、`+`表示新增行、`@@`标记变更位置，可用于压缩上下文并聚焦评审
核心事实
时间轴 (近 90 天)
要获得有意义的变更视图，通常需要先将法律文本解析为结构化格式（如 XML 或 JSON），再在结构层面做差异比较，而非直接对纯文本执行 diff。
传统代码审查工具只显示 diff（差异），在面对陌生仓库时隐藏大量上下文（如被调用函数行为、模块依赖、历史约定），不足以支持通读整个代码库。
为避免 AI 意外大范围改动，应在提示中明确约束改动范围（如“只改这个函数，不要动其他文件”），并在提交前逐行审查 diff。
若一次提交混合了格式化、重命名与逻辑变更，diff 的噪声会增加，问题生成的针对性会受影响。
对 Sphinx 而言，diff 是生成测验问题最关键的输入，界定了本次改动的范围。
Sphinx 围绕本次提交的 diff 内容生成针对性问题。
该Skill不把diff当作活动范围，而是要求从改动出发在整个代码库中寻找改进机会。
通过剥离输出与元数据、仅传代码单元格diff、超长行用长度+哈希替代等方法，可将每次notebook评审的token消耗从约30k降至1k–1.6k，降幅超过95%。
在notebook场景中，diff粒度通常落在cell级别（因单元格可任意增删、重排、修改），再对cell内部源码行做行级diff。
对LLM而言，diff不仅省token，还能将模型注意力约束在本次改动上，避免全量代码中大量未变逻辑稀释评审焦点。
还有 12 条时间轴事件
全部知识事实 (20)
合并请求（Pull Request / PR）是现代软件协作的核心机制，开发者在独立分支完成开发后向主代码库发起合并申请并经代码审查后合入主干
75%待验证Unix系统中的diff工具由Douglas McIlroy在1974年开发，其核心算法是最长公共子序列（LCS）
85%待验证要获得有意义的变更视图，通常需要先将法律文本解析为结构化格式（如 XML 或 JSON），再在结构层面做差异比较，而非直接对纯文本执行 diff。
50%待验证传统代码审查工具只显示 diff（差异），在面对陌生仓库时隐藏大量上下文（如被调用函数行为、模块依赖、历史约定），不足以支持通读整个代码库。
50%待验证为避免 AI 意外大范围改动，应在提示中明确约束改动范围（如“只改这个函数，不要动其他文件”），并在提交前逐行审查 diff。
50%待验证若一次提交混合了格式化、重命名与逻辑变更，diff 的噪声会增加，问题生成的针对性会受影响。
50%待验证Sphinx 围绕本次提交的 diff 内容生成针对性问题。
50%待验证对 Sphinx 而言，diff 是生成测验问题最关键的输入，界定了本次改动的范围。
50%待验证该Skill不把diff当作活动范围，而是要求从改动出发在整个代码库中寻找改进机会。
50%待验证diff策略仅适用于迭代式评审工作流；首次让模型理解整个项目结构时仍需提供一定量全量上下文，diff不适用。
50%待验证通过剥离输出与元数据、仅传代码单元格diff、超长行用长度+哈希替代等方法，可将每次notebook评审的token消耗从约30k降至1k–1.6k，降幅超过95%。
50%待验证在notebook场景中，diff粒度通常落在cell级别（因单元格可任意增删、重排、修改），再对cell内部源码行做行级diff。
50%待验证对LLM而言，diff不仅省token，还能将模型注意力约束在本次改动上，避免全量代码中大量未变逻辑稀释评审焦点。
50%待验证diff 指一次提交或一个 PR 中相对于基线版本的增删行集合，审查者实际阅读的是 diff 而非完整文件。
50%待验证PDF、Word、Excel等二进制或富格式文件是不透明的字节流，diff工具无法对其做有意义的逐行比较
50%待验证diff比对是版本控制工具的核心功能，逐行对比两个文本文件并高亮新增、删除或修改的部分
50%待验证统一diff（unified diff）由diff -u命令产生，每个文件块以--- a/和+++ b/标注原始路径和目标路径
50%待验证diff（差异对比）是软件开发中用于展示两个版本文件之间具体改动的标准格式，通常以红色标注删除行、绿色标注新增行
50%待验证grep、sed、awk、diff 等经典命令行工具都以文本流为处理对象，可通过管道串联组合
50%待验证裁判通过审阅整体diff能抓住破坏相邻断言的ID启发问题，识别单点单元测试看不见的关联性破坏
50%