如果模型选错了记忆，或者提交的 patch 本身就改错了意思，代码仍然可以合法应用。那 patch 机制具体能防住哪些错误，剩下的语义错误怎么处理？再调用一次模型核验，它会不会犯同样的理解错误？有没有实际证据说明这一步的收益值得增加的成本，还是只在不确定时才需要？

回复 群友 7739：patch 机制防的是“手滑”，防不了“看错”。 具体分类说： 它确实能防住的：格式非法（字段不存在、类型不对、id 找不到）、越权改动（改别人条目、改被引用的条目）、批量误伤（一次 patch 声称删 20 条，超出阈值即拒绝）、并发覆盖（版本号对不上就失败）、以及“模型想重写整条但只想改一句”这种粒度问题。这些都是结构层面的错，代码一检查就抓住。 它防不住的：模型把“会议定在周四”理解成“会议改到周四”，或者把“我不用 TypeScript”读成“我用 TypeScript”。这类语义错误 patch 合法、字段对、格式对，代码只能照单执行。所以问题不在 patch 机制，而在“模型单方面决定语义”这个前提。 剩下语义错误怎么处理，分三层，别只靠再调一次模型核验： 一是把不可逆变成可逆。删除、覆盖降级成标记失效，原文保留，检索过滤掉。这样绝大多数语义错误不是事故，只是需要回滚的一次改动。这是最有效的一招，成本几乎为零。 二是不让单一的模型判断成最终事实。冲突时不要让它静默合并，保留两条、标冲突、带上来源和时间戳，让上层或用户裁决。用户明确说过的话优先级高于模型推断，这个排序由代码固定，不由模型每次判断。 三是按风险的差别化核验。写“用户偏好、项目约定、会影响后续行为”的条目才需要核验；写琐事就不要。用户明确陈述的事实本来就不需要模型核验，核对的是“模型有没有正确摘录原话”，这个可以靠原文 span 比对、字符串/数字一致性检查来做，属于确定性的，比再调一次模型便宜也可靠得多。 至于再调一次模型会不会犯同样的错：会。同一个模型、同一段上下文，重复判断高度相关，错误是系统性的不是随机的，换样本也未必改。要有用，得换条件：用不同 prompt、只给原文和被改条目而不给模型自己的推理链、或者用小模型做“这条是否忠实于原文”的二分类。但仍然只是降低概率。 有没有证据说收益值钱？老实说没有公开的量化证据，我也不该编。工程上的经验判断是：这一层成本在于延迟和复杂度，不在 token；所以只对高风险条目开，不要全局开。默认路径应该是“可回滚 + 冲突不合并”，这两个几乎零成本，收益是确定的；再调模型核验属于可选项，等你真的出了事故、能统计出坏 case 的分布之后再补。先有 badcase 再谈核验，顺序别反了。