开放性使功能无法被枚举，产品的能力清单不再可完整展示

概念解释

设置页可以列出二十个开关，因为开关是事先造好的对象。开放生成一旦接上「用语言调用任意组合」，产品就失去一份可穷尽的功能表：能力不可枚举（non-enumerable capability）。不是清单做得不够长，是合法请求的集合按组合爆炸，任何有限列表都会同时犯两种错——漏掉真实能做的，以及暗示列表之外不存在。

入口不提示范围，是单个空框的可供性失败。这里是产品级的目录问题：营销页、定价档位、权限矩阵、无障碍声明，凡是曾经靠「功能列表」运转的表面，都失去了闭合的外延。

机制

传统软件的功能是开发时绑定的过程：有代码路径才有菜单项，菜单项就是外延。语言模型把过程延迟到推理时，外延变成「训练分布与工具接口的可及闭包」，这个闭包对产品团队自己也不可视。于是出现双重无知：用户不知道能问什么，团队也不知道该承诺什么。

清单一旦写出，就获得规范力量。写出的会被当成服务等级，没写出的会被当成缺陷。开放系统若强行列清单，等于用一份过时的有限集去约束一个无限集，然后在边界上不断赔礼。不列清单则定价、采购、合规审计失去抓手——买方问「你们到底有哪些功能」，卖方只能回答「取决于你怎么问」。

怎么研究

分别向新用户、采购决策者、客服三组人出示：一份传统功能列表、一份「示例任务」页、一份完全开放的描述。让他们画出能力边界，并决定是否采购/是否把任务交进来。自变量：清单形态（穷尽表 / 任务样例 / 无清单）、清单是否标注「未列出不等于不能做」。因变量：边界准确度、过度承诺（把做不到的画进来）、漏承诺、决策信心与事后后悔。

对照物是真实工具调用图和评测集覆盖，不是模型卡片上的广告句。团队内部也可做一次「闭着眼列出我们能做的一百件事」，再拿生产日志里的长尾请求打脸——长尾长度本身就是不可枚举的证据。

边界

单域产品（只改合同某类条款、只画折线图）把生成关在封闭任务上，枚举又变得可能，开放只是表面语法。企业版若用策略关掉工具，能力集合被重新变成有限集，清单可以回来。相反，接入插件市场或任意 URL 工具之后，枚举彻底破产，连「示例」都会过时。这条不处理空框看上去像什么，只处理「完整能力清单」这个体裁本身失效。

怎么落地

• 放弃「功能大全」页，改成按任务族分组的样例，并写明样例是切片不是全集。定价和权限按任务族或工具开关走，不要按一份假装穷尽的菜单走。
• 给内部和买方各一份「明确不做」清单。负向枚举比正向枚举稳：做不到的集合增长更慢，也更适合合规。
• 生产日志里的新任务族要有回流：样例页按真实使用更新，而不是按发布说明更新。
• 验证：让没接触过产品的人根据官网能力描述列出「它能做 / 它不能做」各五条，对照当前真实工具与拒答策略。若「能做」里混进你们明确拒绝的，或「不能做」里全是你们日志里的高频成功任务，清单体裁已经在说谎。

延伸

• 同组：L2.01.1 开放输入不提示能力范围 · L2.01.2 用户不知道该怎么说是主要门槛 · L2.01.3 表述差异会导致结果差异 · L2.01.4 空白输入框不传达任何能力边界，用户的第一句话本质上是猜测 · L2.01.5 开放输入把失败的归因引向用户自己说得不好 · L2.01.6 同义表述得到不同结果，用户会误以为存在需要背诵的固定说法 · L2.01.8 开放输入的错误提示难以具体，因为系统并不知道用户原本想做什么
• 相邻：L1.02 能力边界的表达 · L2.02 可说什么的可发现性 · L4.06 代理的权限边界
• 站内检索：non-enumerable capability · open-ended feature inventory · negative capability list