让 AI 助手改一行代码，它报"要替换的字符串在文件里找不到"。你定睛一看，那行明明就在那儿，一个字不差。再试一次，它没报错，但改完发现——动的是另一个地方。
现象
三种表现，都遇到过：
- 匹配失败：报告"要替换的字符串在文件中找不到"，但该内容肉眼可见地存在。
- 匹配错位：没报错，却改到了另一处"长得像"的地方。
- 替换范围过大：选中的片段太长，连带删掉了一行不该动的内容。
这三种表现看起来不同，根子却是同一个：替换是按字符比对的，而人（和模型）是按"看起来的样子"记的。
根因：字符级匹配是精确的，而记忆是模糊的
替换是逐字符精确匹配，不看语义、不忽略空白。于是最经典的一类失败来自缩进：
- 你（或模型）以为这行是顶格的，文件里其实带四个空格缩进；
- 你把制表符写成了空格，或者反过来；
- 换行位置、行尾多余空格对不上。
只要有一个字符不同，匹配就失败——即使显示出来"看起来一模一样"。
第二类失败来自不唯一。比如要替换 return result，而文件里有三个函数都写着这一行。替换工具撞上多处匹配时，要么报错，要么（如果实现允许）改到了第一个，未必是你想改的那个。
第三类失败来自范围太大。为了让匹配"更稳"，把替换目标写得很长，结果把中间一行本来要保持的内容也一起吞掉了——而且这种错误往往不报错，改完就过。
值得注意的是，"匹配失败"反而是好事：它至少提醒你目标写错了。真正危险的是第二、三类——它们静默地"成功"，错误要等到运行时才暴露。
解决：三条纪律
-
替换目标要带上足够上下文，并严格对齐缩进。 别只写那一行，把上面一行（含它的缩进）也带上，让锚点更稳：
想改的 return result 写这样的目标更稳 if not data: return result -
匹配不到时，改用文件里唯一的那一行做锚点。 挑一个在整份文件里只出现一次的标识（唯一的注释、独特的字符串），先替换它旁边的内容，再围绕它改。核心原则是让替换目标唯一。
-
只替换真正变化的最小片段。 一次只改一个逻辑动作，别把一个函数重写和一次变量改名混在一次替换里。
延伸与预防
改完必须看差异。 这是最后一道防线——无论前面多小心，落盘后核对 diff，能立刻发现"改到了别处"和"多删了一行"这两种静默错误。养成"改小步、改完看 diff"的习惯，比一次写个完美的长替换可靠得多。
这个思路同样适用于人手工用的 sed -i 批量替换：先确认模式在文件里唯一，再执行；不确定就先 dry-run 打印一遍。"匹配上了"和"匹配对了"是两回事。
再补一条实践建议：替换前先把要改的那段原文从文件里"复制"出来，而不是凭记忆重写。 记忆里的版本和文件里的版本差一个空格就会失败；而从文件里原样取出的内容，天然和文件一致。这个动作能一次性消除缩进、换行、行尾空格这三类最常见的匹配失败。
另外，如果同一份文件里有多处相似代码，干脆放弃"精确匹配"，改用"定位到行号再改"的方式——行号是唯一的，不受内容重复的影响。
一句话教训
编辑的精度问题，一半靠"选更小的范围"，一半靠"改完看差异"。