场景
你需要在一份 Markdown 文件里做批量替换——把英文直引号 " 换成中文弯引号 ""。文件不长，几十处替换。
你用 AI 编辑工具（就是那种可以帮你查找替换文件内容的工具），告诉它：把所有直引号替换成弯引号。
工具报告：替换完成。
问题
打开文件，肉眼看起来「好像对了」。但网页渲染出来后，页面上赫然显示着：
\u201c你好\u201d不是一个弯引号，是 \u201c 这六个字符。反斜杠、字母 u、数字 2、0、1、c。
编辑工具在执行替换时，没有把 \u201c 转换成真正的 Unicode 字符 "，而是把这六个字符当作普通文本写进了文件。
排查路径
这个问题排查起来比想象中麻烦，因为「看到 \u201c」这件事本身就需要一步验证。
第一步：确认文件里到底是什么。
不能只看渲染结果。如果是远程编辑，你需要要求工具展示文件的原始内容——不是渲染后的预览，是文件本身。
第二步：用十六进制查看确认。
xxd filename.md | head -20一个真正的左弯引号 "（U+201C）在 UTF-8 中是三个字节：E2 80 9C。
如果你看到的是 \u201c 这六个字符，在 xxd 里会显示为六个 ASCII 字节：5c 75 32 30 31 63。
这两种情况在普通的文本编辑器里看起来一模一样。区别只在字节层面。
解决方案
既然编辑工具本身会转义 Unicode，就绕过它，用脚本做替换。
方案：Python 脚本
写一个脚本，把文件里的直引号统一替换成真正的弯引号：
import re
with open('filename.md', 'r', encoding='utf-8') as f:
content = f.read()
# 简单的成对替换逻辑
content = re.sub(r'"([^"]*)"', r'\u201c\1\u201d', content)
with open('filename.md', 'w', encoding='utf-8') as f:
f.write(content)Python 的 \u201c 在字符串里会被正确解释为 Unicode 字符，写入文件时自动转换为 E2 80 9C 三个字节。
关键一点：脚本本身也要通过命令行执行，不能通过编辑工具来写和运行——否则脚本里的 Unicode 字符也可能被转义，问题原地复现。
执行后验证
用 xxd 检查前几个替换位置：
xxd filename.md | grep 'e280 9c'确认看到的是 e280 9c（三个字节），而不是 5c75 3230 3163（六个字节）。
备选方案：全文重写
如果只有几处修改，可以让编辑工具直接输出修改后的完整文件内容。工具在「生成内容」时通常能正确处理 Unicode，问题只出在「编辑替换」这个操作路径上。
但这只适合小范围修改。几十处替换的场景下，全文重写的成本太高。
一条原则
经过这次踩坑，我给自己定了一条规则：
凡涉及非 ASCII 字符的批量替换（中文标点、特殊符号、Emoji），一律用脚本处理，不信任编辑工具的查找替换。
理由很简单：编辑工具的「查找替换」和「生成内容」走的是不同的代码路径。生成内容时，Unicode 通常没问题；执行替换时，底层实现可能把字符当转义序列处理。
这不是 AI 的问题，是工具链某一层的 Unicode 处理不一致。提前知道这个行为边界，能省掉很多排查时间。
三条检查清单：
- 非 ASCII 字符的批量替换用脚本，不用编辑工具的替换功能。
- 替换后立刻检查源文件内容，不要只看渲染结果。 问题出在文件层，不在展示层。
- 遇到 Unicode 相关问题，先跑 xxd。 字节层面的事实比肉眼观察可靠得多。