界面控件默认承诺同一操作得到同一结果，生成式功能违背这一承诺

概念解释

「一键摘要」是一个控件。控件的存在本身是一句诺言：有一个被命名的动作，做了就会得到该类结果，而且同样的按法指向同样的变换。控件的确定性契约（control determinism contract）比「界面惯例」更窄——它钉在单个控件的言语行为上，不依赖用户有没有用过别的软件。生成式功能把这个控件接到一个分布上，诺言就破了。

空白对话框没有许下「同一句话永远同一答案」；一个标着「生成周报」的按钮许下了。冲突来自控件，不是来自聊天。

机制

按钮、菜单项、工具栏图标是命令的专名。专名在语言里预设指称稳定：同一名称、同一对象。用户不必先学概率，只要识字，就会把「生成周报」读成一种函数。加载指示还在强化「正在计算那个结果」，而不是「正在抽一个结果」。

产品常把生成塞进已有命令位置：工具栏上原来「导出 PDF」旁边新放一个「智能导出」。位置继承了邻居的契约。邻居是确定性变换，新来者却是采样。人不会因为图标多了星星就改写契约，他们会按邻居那一套去评估对错——第二次不一样，就是这个按钮坏了。

怎么研究

把同一生成能力做成两种外壳：聊天句 vs. 命名按钮，测量人对「再按一次应不应相同」的判断，以及结果变化时的故障归因。自变量：控件类型（按钮/菜单/命令面板）、标签是否含「智能/生成」、是否与确定性邻居并排。因变量：契约预期（相同/不同）、归因为缺陷的比例、是否保存第一次输出。

标签研究要控制长度和具体性。「生成」和「写一份新的」预期不同。眼动可以看人是否拿新按钮与邻钮比较——位置契约是否真的在被读取。

边界

用户把按钮理解为「开始一次创作」而不是「执行一个变换」时，契约方向会翻过来，变化变成功能。那通常需要标签、示例或多结果布局一起把「创作」说清；单靠一个星星图标不够。对只出现一次、结果立刻被下游系统校验的控件（「提取订单号」且校验失败就重抽），契约破裂的可见性很低。这条不讨论撤销语义，也不讨论把再生成画成刷新图标。

怎么落地

• 生成类命令的标签要说出「写一份」「起草」，不要说得像「应用」「计算」「刷新」。
• 不要把生成按钮紧挨导出、排序、格式刷这类确定变换，以免位置借来契约。
• 若必须用按钮，让结果区默认保留上一次，新一次是新增而不是替换；替换需要另一次确认。
• 验证：把按钮截出来，连同左右邻居一起给没见过产品的人看，问「按两次，两次应当一样吗」。答案若是「应当一样」，这个控件还在许诺它给不了的东西。

延伸

• 同组：L1.01.1 同一输入可能得到不同输出 · L1.01.2 界面惯例默认操作可重复且结果稳定 · L1.01.3 用户会把偶发正确误判为稳定能力 · L1.01.5 用户无法通过重试区分是自己表述不当还是系统本身在波动 · L1.01.6 撤销与重做在输出不可复现时语义失效，撤销后回不到原来那次结果 · L1.01.7 把重新生成呈现为「刷新」会暗示上一个结果只是加载失败 · L1.01.8 把可变性显式呈现为多个并列方案，比藏在单一结果背后更诚实
• 相邻：L2.04 参数化控制与自然语言的互补 · E1.06 按钮文案 · L3.01 多方案生成
• 站内检索：control determinism contract · named command · speech act of buttons