两者并存优于二选一

概念解释

只要语言框，意图进得来，程度只能靠再写一句去赌。只要参数面板，刻度爬得动，未命名的情景无处安放。混合控制（hybrid NL-parameter control）主张：同一任务表面同时提供两种通道，让意图走语言、已命名的量走控件，比强迫人挑选一种「主交互」的产品更贴任务结构。并存不是把两种入口堆在一起充数，是让一次提交里两种信息都能活着到达生成。

它不规定冲突时谁说了算——那是覆盖规则。它也不规定语言解析后要不要回填。它只争「缺一边就有一类意思永远进不去」。

机制

任务几乎总是异构的：一部分命题（给谁、什么处境、禁止什么），一部分标量（多长、几档、哪种格式）。单一通道会把异构压成同构。语言把标量压成模糊词，控件把命题压成最近的那个枚举。两种扭曲叠在同一条产品决策上：选语言的产品在调节上反复重生成，选控件的产品在意图上经常「差不多但不是那个」。

并存还匹配不同时刻。第一拍需要命题，随后几拍需要沿量爬。二选一会把后半段或前半段变成惩罚。人不是「喜欢聊天」或「喜欢旋钮」的两种人格，是同一任务的两个阶段。

怎么研究

同一批异构任务（必有未命名约束 + 必有目标数值）。三组：仅语言、仅面板、两者都在且一次提交可同时带上。因变量：命题约束命中、数值误差、总轮次、中途是否抱怨「没地方放」。自变量：两种通道的视觉权重（谁是主、谁是辅）、是否允许只填一边。

失败模式要分开记：仅语言组的数值漂，仅面板组的命题丢，混合组的「以为填了但另一边没带上」。最后一类是并存做得假——看起来有两个入口，提交只读其中一个。

边界

极窄工具（只要一个量：音量、温度计）并存是噪音。纯对话、无稳定量的探索，面板是假精确。屏幕极小且通道只能放一个时，应接任务阶段切换，而不是永久二选一。专家宏和 API 用户已经在代码里混合了两种信息，图形上的并存对他们不是新能力。这条在「谁覆盖谁」未声明时仍然主张并存——缺声明会痛，但缺通道会先痛。

怎么落地

• 语言框和关键参数出现在同一次发送的视野里，发送 payload 必须两者都读。不要做「调了滑块却只把文本发出去」。
• 默认不必填满两边：只说一句话可以发，只拨一个量也可以发。空着的那边用当前值，不要清掉。
• 视觉上让人一眼看出这是一次提交的两面，而不是两个互抢的功能。
• 验证：一条请求同时含未命名处境和明确字数。截发送 payload。若处境或字数缺一边，并存是假的。再看纯语言版和纯面板版在同一任务上各自丢了什么——丢掉的那类，就是你若二选一会永久放弃的那类。

延伸

• 同组：L2.04.1 自然语言适合表达意图 · L2.04.2 参数控件适合精确调节 · L2.04.4 自然语言擅长表达目标与约束，参数控件擅长表达程度与数值 · L2.04.5 参数控件提供可回退的确定状态，自然语言不提供 · L2.04.6 两者并存时必须明确谁覆盖谁，否则用户无法预测冲突时的结果 · L2.04.7 把语言解析结果回填到控件上，能让用户看见系统的理解 · L2.04.8 控件的取值范围本身就是一次能力边界的展示
• 相邻：L2.06 控制粒度 · L2.03 示例与模板引导 · L2.01 自然语言指令的开放性及其代价
• 站内检索：hybrid NL-parameter control · dual-channel submission · mixed-initiative control