用户会把看到的示例当成能力上限，示例过窄会压低实际使用范围
别名: 示例锚定 · 能力上限错觉 · example-induced constraint
概念解释
用户看见「改短一点 / 更正式 / 翻译成英文」三枚芯片，会把产品理解成润色器，即使模型其实能把段落变成表格、能对图提问、能按角色改写。他们不是没看见别的入口，而是把示例读成了能力上限（examples as capability ceiling）。过窄的示例会主动压低真实使用范围：功能在后端开着，行为上等于没发布。
这和「示例太少所以不知道能干什么」不同。上限效应在示例数量充足、但全部停在同一高度时也会出现——人不是缺样本，是把样本的最大高度当成了天花板。
机制
示例同时是示范和锚。示范告诉人怎么开口；锚告诉人「别超出我看见的」。在不确定的开放输入里，越界的代价是浪费一次生成、显得自己不会用，所以保守策略是停留在示例高度之下。编程教学里也能看到同类约束：给学生看过的解法形状，会把后续尝试锁在该形状里，即使题目允许别的结构。
上限还会自我强化。第一周只做润色的人，留下的历史全是润色，下一周打开产品时历史继续提示润色。窄示例通过行为日志把自己写进习惯，不必一直显示在空状态上。
怎么研究
组间操纵示例的「最大高度」：一组只给句级改写，一组在同样条数里加入一条跨模态或跨结构的示例（「把这段变成表」）。任务说明书不限制范围。因变量：尝试是否越过句级改写、自发使用的最高结构层级、事后问卷里「你认为它不能做什么」。关键对照是能力实际开启、只是没被示例碰到的那些功能的调用率。
不要用满意度当终点。被压低范围的用户往往更满意——他们只做了示例里会成功的事。需要行为指标：未示例功能的发现时延、以及「知道能做却从未做」的知晓—使用差。
边界
当产品策略就是收窄（专用改写器、合规场景只允许固定句式），上限效应是特性，不是缺陷，示例应当诚实地封顶。儿童或高风险领域需要明确天花板，以免试出越权请求。已经从别处（同事、社区、插件）学到更高用法的用户，界面示例压不住他们；上限主要作用在孤立的新用户身上。
怎么落地
- 审查现有芯片的最高结构层级。若全部停在「改语气 / 改长度」，加一条真正换结构的示例，哪怕它不是最高频。
- 把「你可能没想到的用法」和「常见用法」分成两行，避免常见用法把高用法挤出视野。
- 对已经连续多天只使用最低层级的账号，在输入框附近换一条更高层级的提示，而不是重复他们已经会的那句。
- 验证：打开能力开关但从不做芯片的那批功能，看新用户 7 日内的调用率。若接近零，同时满意度很高，就是上限效应而不是功能失败。把该功能做成一条可见示例后再测一次，调用率应上升；若仍为零，问题在能力本身，不在天花板。