先记住这个答案
搜索替换依赖旧片段足够完整且匹配位置明确；行号编辑依赖当前文件位置和版本不变；unified diff 用上下文与增删块表达局部变化，便于审查；整文件重写适合新建或较短、结构整体变化的文件，但更容易遗漏原内容和覆盖并发修改。可靠性取决于工具怎样处理重复匹配、过期版本、补丁失败和写入边界，不能只根据格式名称下结论。选择时应考虑文件长度、修改范围、可用定位证据，以及执行端能否拒绝歧义和不完整输入。
- 不同格式依赖不同的定位与版本前提
- 局部修改需要明确匹配，整体重写需要完整内容
- 失败后重新读取证据，避免自动放宽匹配条件
搜索替换与行号编辑怎样失去定位证据
相同的配置行可能在多个对象中出现，搜索替换若默认全部替换，会把一个局部需求扩散到其他模块。更可靠的接口应要求唯一匹配，或明确声明替换次数，并在歧义时拒绝执行，让调用者补充相邻上下文。
行号表达简短，但文件前面新增一段代码后目标位置就会移动。可以同时携带读取版本和预期旧内容，防止只凭过期数字修改错误行。若工具只接受行号，Agent 就更需要在编辑前刷新文件，而不是沿用多轮之前的行位置。
diff 让局部差异可见，但仍可能匹配失败
unified diff 保留文件路径、块位置、上下文与增删行，审查者容易看到变化范围。上下文能帮助应用器定位，但上下文过少、重复区域或文件已有改动都可能导致失败或歧义；不能把 diff 当成理解语法和业务的自动重构器。
补丁应用器对偏移、模糊匹配和部分失败的策略可能不同，需要阅读实际工具契约。失败后优先读取当前目标并重建最小补丁，不应无限删除上下文或扩大替换范围。能应用只说明文本前提满足，仍需编译和行为验证确认修改正确。
什么时候完整重写反而更清楚
新文件、短配置或整体结构重新组织时，完整内容能够减少复杂补丁块并方便审阅最终形态。前提是输入文件完整可见，输出没有截断，且执行端能检查写入前版本。长文件中只改两行时，重新生成所有内容通常增加遗漏和无关格式变化风险。
整文件输出如果包含“其余保持不变”之类说明，执行器不能把它当成真实源码直接覆盖。应明确要求完整内容，并检查差异是否局限于授权范围。无论选择哪种格式，最终都要核对新增、删除和保留部分，保存可恢复证据，而不是仅以写入成功作为完成标准。
容易答错的地方
- diff 天然不会覆盖其他人的修改
- 它仍依赖读取前提和应用器策略，过期上下文可能失败，宽松匹配也可能改到错误位置；并发修改需要版本检查和冲突处理。
- 重写整个文件一定比局部补丁更差
- 短文件整体替换可能更直观。真正风险来自不完整输入、输出遗漏和版本失效，应按修改范围与工具保证选择，而不是机械禁止某种形式。
面试官还会怎么问？
可以让工具自动替换第一个命中吗？
只有契约明确且第一个位置确实可证明为目标时才适合。重复片段中静默选第一个会把歧义隐藏起来，通常应要求更完整上下文。
AST 编辑是否解决所有问题？
它能利用语法结构定位和重构，但仍可能缺少业务含义、类型关系或跨文件版本信息；格式与注释保留也依赖具体实现。
如何评估某种编辑格式更可靠？
在真实修改任务上记录应用成功率、错误位置、无关变更、修复轮次和最终测试结果。只比较输出 Token 数会漏掉最重要的正确性差异。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。