同样改三行代码，整文件替换和补丁为什么会得到不同结果？
上一课找到了应修改的规则。现在让文件在你读完之后发生一点变化：你读到 RETRIES = 3、TIMEOUT = 30，同事随后把超时改成 60。你的任务只是把重试次数改成 5。本课不比较代码模型排行榜，而是看编辑工具如何把一个意图落到当前文件上。
意图相同，作用范围不相同
最朴素的做法是发送完整的新文件：RETRIES = 5、TIMEOUT = 30。它看起来只有两行，格式也完全正确。可是写入时会把同事的新超时 60 覆盖回 30。错误不在重试次数，而在工具把整份旧快照当成当前真相。文件越长，重复发送的无关内容越多，遗漏一段或恢复旧值的机会也越多。
第二种做法是搜索替换：寻找完整文本 RETRIES = 3，只把它换为 RETRIES = 5。如果这段文本只出现一次，超时行不受影响。如果文件里生产配置与测试示例各有一次相同文本，工具就需要明确的匹配策略：报歧义、替换第一次还是全部替换？这不是无关的实现细节，而是会改变最终程序的行为。
补丁为什么需要上下文？
补丁把变化和附近不变的行同时交给工具。变化行说明把什么改成什么，上下文行帮助确定位置。如果你看的是旧文件，而当前位置已经变了，匹配可能失败。失败本身可以是有价值的反馈：它阻止你把建立在旧假设上的修改静默落到新状态。
但是补丁并不天然免疫冲突。上下文太少可能匹配到错误位置；上下文太多可能因无关改动而失配；某些应用器允许偏移或模糊匹配。不能因为输出写了“patch applied”，就跳过差异检查。它只说明编辑工具按自己的规则应用了文本操作，不保证业务意图正确，也不保证保护了所有并发变化。
用一个并发改动做实验
教学文件只有两行，因而可以逐字检查结果。先把当前超时固定为 60，然后分别重放三种操作。这里模拟工具匹配规则，不是在后台写你的真实文件。重要的是观察最终两行，而不是给某个格式贴上“先进”标签。
把同事的改动留住
比较三种编辑结果，尤其检查没有要求修改的 TIMEOUT。
教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。
当前文件：RETRIES=3，TIMEOUT=60；需求仅改重试为5
- 1. 读取旧快照
模型记住的超时仍是30。
- 2. 整文件写回
写入RETRIES=5与TIMEOUT=30。
- 3. 核对差异
目标变化正确，但无关超时60被还原为30。
模型记住的超时仍是30。
先预测，再核对结果与原因
覆盖了无关修改。整文件写入的边界大于任务边界。
看到冲突之后，不要扩大破坏半径
假设补丁报告目标片段找不到。一个危险的应对是立刻改用整文件重写，只为了让工具不再报错。这样可能把正常的冲突提醒转化为用户改动丢失。更合理的顺序是重新读取相关范围，判断是自己的片段写错、目标已被移动，还是文件确实发生了新的业务变化；然后用当前状态重新构造最小改动。
再改变一个条件：文件里有两个 RETRIES = 3，分别属于 production 和 example。如果需求只针对生产配置，定位信息就应包含所属节、函数或相邻键。单靠一个常量文本不足以描述目标。若工具支持语法树编辑，可以用语法节点缩小目标，但节点解析、格式保留和语言支持也有各自边界，不能把它视为通用正确性证明。
编辑完成后至少回答三件事。第一，目标规则是否改成了要求的值；第二，差异里有没有与任务无关的删除、格式重排或旧内容恢复；第三，受影响行为的测试是否通过。差异检查与行为检查互补：测试可能漏掉同事改过的超时，差异能发现它被还原；差异看起来小，也可能把一个条件符号改反，测试更容易抓住。
因此，选择编辑工具的依据是文件大小、匹配歧义、并发修改与验证条件。新建一个两行配置可以整文件写入；维护长文件更适合可核对的局部编辑。不存在“永远使用某一种格式”就不再需要观察的捷径。
自己检查一次编辑
完整新文件语法正确，为什么仍可能是错误修改？
语法检查不比较当前文件与旧快照的差异。TIMEOUT从60回到30在语法上完全合法，却覆盖了本任务之外的变更。必须检查实际差异和需求边界。
搜索文本出现两次，最可靠的下一步是什么？
补充可以区分目标的上下文，或使用能唯一定位的语法节点；不能在没有依据时默认替换全部。目标唯一性是执行前应核对的条件。
补丁失败为何可能比“强制成功”更安全？
失败暴露了当前文件与预期不一致。重新观察可以保护并发变化；强制覆盖只是绕过检查，并未修复旧假设。失败也可能只是格式问题，所以需要定位原因而非盲目重试。
编辑工具决定改动怎样落地，测试决定落地后的行为是否满足要求。下一课继续追问：新增测试通过了，是否已经足够宣布修复成功？