开放输入不提示能力范围

概念解释

工具栏上的「导出 PDF」自己报了名：能做什么、做到哪一类结果，写在控件上。一个只说「有问题尽管问」的输入框什么都没报。能力范围未被提示（unsignaled capability range）指的是：开放文本入口只展示「这里可以打字」，不展示系统实际覆盖的操作集合。用户看见的是语言通道，不是能力地图。

它不是「第一句话只能靠猜」——那是起步动作的问题。这里钉的是入口本身不提供范围信号：即使用户已经决定开口，仍无法从界面读出哪些意图落在系统内、哪些会撞墙。

机制

Gibson 所说的可供性来自可被感知的行动可能性。按钮、菜单、图标把可能性做成可见对象；空白输入框把可能性收成一种语言能力——「你会写字就能用」。人从即时通讯里学来的可供性是「对方能懂人话」，于是把同一外观迁到生成入口上。消息框的对端是会拒绝、会追问、会承认不懂的人；模型对端默认照单全收，再用流畅文本填满任何请求。入口看起来什么都能说，系统却只覆盖训练与工具调用划出的一块。

执行鸿沟因此被入口自己加宽：目标在用户脑子里，合法操作符却不在视野里。人只能用世界知识去填，而世界知识是按「对话」而不是按「这个产品接了哪些工具」组织的。

怎么研究

第一使用、不给教程。在任何人打字之前问「你觉得它能做哪些事」，把回答对照真实能力清单做覆盖与虚构两类编码。自变量：占位文案是否点名领域、入口旁是否有能力分区、是否出现工具图标。因变量：真实能力被点名的比例、虚构能力的条数、第一句请求落在能力内的比例。

不要在开场白里说「这是一个能写代码、能搜网页的助手」——那等于把自变量做掉。更干净的做法是把入口嵌进已有产品的侧栏，让人按日常任务来猜范围。

边界

入口已经用产品名或场景名收窄时（「合同条款助手」「只改这一列」），范围信号来自容器而不是输入框，这条会变弱。语音助手若绑在客厅灯和门锁上，物理环境本身就是范围。从功能发布页点进来的人已经带着一块能力预期，空框不再是唯一线索。这条不处理「功能多到列不完」——那是枚举失败；也不处理用户会不会把失败怪到自己措辞上。

怎么落地

• 在输入框可见范围内放一组以动词起头的能力标签，而不是一句「随便问」。标签必须是系统真能做的，宁少勿假。
• 占位文案点名领域或对象（「描述你要改的表格」），不要用「问我任何问题」把范围撑到无限。
• 能力标签可点：点了不是塞一句套话，而是把该能力的合法对象暴露出来。
• 验证：挡住产品名和导航，只留输入框，问没见过这产品的人「它能干什么」。若回答漂向万能问答而你们实际只有三五类任务，范围仍未被提示。

延伸

• 同组：L2.01.2 用户不知道该怎么说是主要门槛 · L2.01.3 表述差异会导致结果差异 · L2.01.4 空白输入框不传达任何能力边界，用户的第一句话本质上是猜测 · L2.01.5 开放输入把失败的归因引向用户自己说得不好 · L2.01.6 同义表述得到不同结果，用户会误以为存在需要背诵的固定说法 · L2.01.7 开放性使功能无法被枚举，产品的能力清单不再可完整展示 · L2.01.8 开放输入的错误提示难以具体，因为系统并不知道用户原本想做什么
• 相邻：L2.02 可说什么的可发现性 · L2.15 指令的歧义与澄清追问 · L1.02 能力边界的表达
• 站内检索：unsignaled capability range · gulf of execution · natural language affordance