文本 diff 工具到底在展示什么
文本 diff 工具做的事情其实非常具体：拿同一份内容的“旧版本”和“新版本”，按行（或按字符）对比，把“只在一边出现”的部分标出来，让人能快速验证“到底改了哪几处”。它不理解内容的语义，只看文本本身——这正是它最有用的地方：文档、配置片段、给大模型的提示词、营销文案、聊天记录、发布说明，任何能写成文本的东西都能用同一套方式做对比。理解这一点之后，你就知道这件工具适合解决“肉眼漏看”的问题，而不是替你做语义判断。
为什么“两份并排看一眼”往往不够
凭眼睛两两对照在文档很短时确实可行，但一旦超过几十行、或者本次改动包含段落重排、整块删除、空白清理，肉眼就基本守不住了。人眼擅长发现“相邻两行措辞不同”，对“一长段中间偷偷少了一行”几乎免疫。diff 工具把这件事变成机械检查：凡是只出现在一边的行都会被显著标出，让你不再依赖余光与运气，而是按一份明确的清单去走。
基于行的 diff 如何定义“变化”
按行 diff 的核心，是把每一行当作一个不可拆的单元。算法会找出“在两边都按相同相对顺序出现”的最长序列，把这条序列当作“没变的骨架”，剩下的统一标成“新增”或“删除”。这也解释了为什么两份看起来差不多的文件，diff 结果有时差异巨大——只要行的结构稍有变化，被认作“骨架”的子集就会跟着变。
- 在两边对应位置都出现的行：未变化。
- 只在右边（新版）出现的行：新增。
- 只在左边（旧版）出现的行：删除。
- “修改”在算法层面其实是“先删一行、再加一行”紧挨着摆，并没有真正独立的“修改”动作。理解这一点，能避免在分析复杂改动时被表象迷惑。
- 把一段内容从一处搬到另一处，多数情况下会显示为“此处删除 + 彼处新增”，而不是“移动”。判断是不是真正的移动，需要人在两边对比内容才能确认。
一句话原则：diff 告诉你“算法认为按行发生了哪些变化”。变化是不是值得在意，仍然由你来判断——工具不会替你做语义层面的拍板。
如何使用这个工具
- 先在 文本差异对比 中准备一份有代表性的两版纯文本、配置片段、备注或生成结果，不要一开始就处理最大或最敏感的真实内容。
- 执行处理流程并生成展示新增行和删除行的可视化差异结果后，优先检查换行、纯空白变化、段落重排，以及这次差异是否应按纯文本而不是结构化数据审查，再判断结果是否真的可用。
- 只有当结果已经适合用于文案审查、发布说明核对、配置对比、提示词改稿和工单证据整理，并且不再触发这条风险提醒时，才复制或下载输出：如果比较对象是 JSON 等结构化格式，且需要关注字段级变化，应改用对应的结构化 diff 工具。
文本差异对比 示例
这个 文本差异对比 示例使用有代表性的两版纯文本、配置片段、备注或生成结果，展示生成后的展示新增行和删除行的可视化差异结果，便于你先确认换行、纯空白变化、段落重排，以及这次差异是否应按纯文本而不是结构化数据审查，再把同样设置用于真实输入。
示例输入
Before: timeout=30 After: timeout=45
预期输出
- timeout=30
+ timeout=45一次文案改动，以行级 diff 呈现
# 旧版
Welcome to the launch.
Doors open at 6 PM.
Please bring a printed invitation.
Refreshments will be served.
# 新版
Welcome to the product launch.
Doors open at 6:30 PM.
Refreshments and drinks will be served.
# diff
- Welcome to the launch.
+ Welcome to the product launch.
- Doors open at 6 PM.
+ Doors open at 6:30 PM.
- Please bring a printed invitation.
- Refreshments will be served.
+ Refreshments and drinks will be served.注意 “Please bring a printed invitation.” 在新版完全消失，没有任何对应的新增行——而这种“安静的删除”正是人眼最容易漏掉的一类改动，diff 工具的价值在这里最直接。
什么场景下文本 diff 是正确选择
文本 diff 最适合的场景，是内容本身不一定有严格结构，但仍然需要认真核对。下面这些情境里，“粘过来跑一遍 diff”几乎总是能省时间。
- 审查落地页、邮件、新闻稿等“每个字都要算”的文案改动。
- 合并前确认同事在配置文件或环境模板里改了哪几处。
- 对比两条 LLM 提示词的不同版本，定位输出差异的来源。
- 做完一次“查找替换”后核对：替换是不是只命中了想改的地方，没有误伤周围。
- 核对两次会议纪要、对话记录或审计日志之间的差异，搞清楚增删了什么。
让 diff 结果产生误导的几类陷阱
diff 工具的输出，永远只跟“你喂进去的两份输入”一样靠谱。绝大多数“diff 看不懂”的情况，不是算法错了，而是“想对比的”和“真正喂进去对比的”不是同一件事。
- 尾部空白和不可见字符：两行看起来完全一样，却因为多了一个空格或 BOM 而被算作不同。
- 换行符差异：Windows 的 CRLF 与 Unix 的 LF 不一致时，整份文件的每一行都会被算作变化，需要先做归一化。
- 段落自动换行：编辑器把长行折成短行时，按行 diff 会“满屏红绿”，但实际措辞并没有变。这种情况换成按字符或按词级 diff 更合适。
- 编码差异：UTF-8 与带 BOM 的 UTF-8、或重音字母的不同归一化形式，都会导致静默的不一致。
- 片段 vs 全文：不小心把头部多复制或漏复制一段，整份文档的“骨架”就会错位，diff 结果会突然变得完全不可读——这类情况最常见。
文本 diff 与其它对比策略的差别
| 对比策略 | 它理解的是什么 | 最适合的场景 |
|---|---|---|
| 按行文本 diff（本工具） | 某一行是否同时出现在两边。 | 文案、配置、提示词等以“行”为单位的内容。 |
| 按字符或按词 diff | 一行内部具体哪些字或词变了。 | 短标题、单句修订、需要锱铢必较的措辞改动。 |
| JSON diff | 哪些键被增删，哪些值发生了变化。 | 需要按字段判断的接口报文对比。 |
| git diff | 同一类按行 diff，但带提交上下文和历史。 | 在版本控制仓库内审查代码变更。 |
使用注意
- 复用展示新增行和删除行的可视化差异结果前，先检查换行、纯空白变化、段落重排，以及这次差异是否应按纯文本而不是结构化数据审查。
- 如果比较对象是 JSON 等结构化格式，且需要关注字段级变化，应改用对应的结构化 diff 工具。
- 当结果会影响生产工作或客户可见内容时，应保留原始两版纯文本、配置片段、备注或生成结果以便回退和核对。
文本差异对比 参考说明
文本差异对比 的参考说明应始终围绕两版纯文本、配置片段、备注或生成结果、生成的展示新增行和删除行的可视化差异结果，以及用于文案审查、发布说明核对、配置对比、提示词改稿和工单证据整理前必须确认的检查点。
- 输入重点：两版纯文本、配置片段、备注或生成结果。
- 输出重点：展示新增行和删除行的可视化差异结果。
- 复核重点：换行、纯空白变化、段落重排，以及这次差异是否应按纯文本而不是结构化数据审查。
参考资料
常见问题
以下问题围绕 文本差异对比 的实际用途整理，重点说明输入要求、输出结果和常见限制。逐行对比两段文本，标记新增和删除行。
文本差异对比 最适合处理什么样的两版纯文本、配置片段、备注或生成结果？
文本差异对比 的核心用途是逐行比较两段文本。当两版纯文本、配置片段、备注或生成结果需要快速变成展示新增行和删除行的可视化差异结果，并继续用于文案审查、发布说明核对、配置对比、提示词改稿和工单证据整理时，它最有价值。
复用 文本差异对比 生成的展示新增行和删除行的可视化差异结果前，最该检查什么？
应优先检查换行、纯空白变化、段落重排，以及这次差异是否应按纯文本而不是结构化数据审查。这些细节最能直接判断结果是否已经适合继续交给下游流程。
文本差异对比 生成的展示新增行和删除行的可视化差异结果通常会被带到哪里继续使用？
最常见的下一步就是用于文案审查、发布说明核对、配置对比、提示词改稿和工单证据整理。这类输出是按真实交接场景来组织的，不是泛化占位结果。
什么时候不应该直接相信 文本差异对比 的结果，而要人工复核？
如果比较对象是 JSON 等结构化格式，且需要关注字段级变化，应改用对应的结构化 diff 工具。