两者并存时必须明确谁覆盖谁，否则用户无法预测冲突时的结果

概念解释

句子写着「两百字」，滑块停在 80。发送之后得到一篇大约 90 字的东西。人无法知道刚才是滑块赢了、解析器没读那句、还是模型自己折中。覆盖规则（NL-widget override precedence）是并存界面必须公开的那条冲突函数：同一字段两边都赋值时，哪一边是有效输入。没有这条函数，并存把预测性毁掉——每多一个入口，就多一种「我填了但没算数」。

并存主张两边都要在。覆盖主张冲突时世界仍可被预知。缺后者，前者变成陷阱。

机制

两个写入端对着同一内部字段，系统总得挑一个值。常见的隐式策略有：后写覆盖、控件优先（因为好校验）、语言优先（因为更新鲜）、折中、或随机取决于解析是否成功。隐式策略在界面上没有对应物，人只能用试错去拟合一个不存在的心智模型。试错还被采样噪声污染：同一次冲突下次可能换一种赢法，规则本身都显得不稳定。

更糟的是部分冲突。句子管语气、滑块管长度，看起来没撞，但「写短一点、语气正式」里的「短」又会去撞长度。冲突边界比字段边界大，未声明的覆盖会在这些交叉口爆开。

怎么研究

构造明显冲突的提交（字数、格式、语气各一对矛盾赋值），问发送前「你觉得哪边会生效」，再看实际生效和事后归因。自变量：是否在发送前高亮冲突并标明赢家、赢家策略（后写 / 控件 / 语言）、冲突高亮是否可改赢家。因变量：预测准确率、惊讶、是否改其中一边来消解、是否停止使用其中一条通道。

把解析失败（语言那侧根本没赋上值）和真覆盖分开。前者是解析问题，会被人误读成覆盖规则，必须单独编码。

边界

两边从不同步、每次发送前强制对齐成单一来源，冲突被消灭，覆盖规则无用武之地——代价是失去「只改一边」的快。只读回填（语言改控件、控件立即成为唯一来源）把冲突窗口缩到回填之前的那半秒。语音里「后写」很难标时间戳，需要显式确认。这条不要求回填本身，只要求冲突可预测；回填是让理解可见的另一件事。

怎么落地

• 选一条简单规则并写在冲突现场：例如「后改的那边生效」或「控件是长度和格式的权威，语言是禁令的权威」。按字段类型定规则，比全局一句「语言优先」更可预测。
• 发送前若检测到同一字段双写，拦住并让人挑一次，不要静默挑。
• 事后在结果旁留一行「长度用了滑块的 80，忽略了句子里的两百字」，让规则被看见。
• 验证：做一次故意双写。发送前问会生效哪边；发送后对照。若多数人猜错，或猜对但说不出规则，覆盖仍是隐式的。再看他们下一轮是否放弃其中一条通道——放弃就是在用行为投票说规则不可学。

延伸

• 同组：L2.04.1 自然语言适合表达意图 · L2.04.2 参数控件适合精确调节 · L2.04.3 两者并存优于二选一 · L2.04.4 自然语言擅长表达目标与约束，参数控件擅长表达程度与数值 · L2.04.5 参数控件提供可回退的确定状态，自然语言不提供 · L2.04.7 把语言解析结果回填到控件上，能让用户看见系统的理解 · L2.04.8 控件的取值范围本身就是一次能力边界的展示
• 相邻：L2.15 指令的歧义与澄清追问 · L5.01 可解释性的类型 · L2.06 控制粒度
• 站内检索：NL-widget override precedence · dual-write conflict · last-write-wins