L1.02.1negative capability disclosure设计研究
系统不能做什么与能做什么同样需要说明
别名: 能力负空间 · 不能做什么 · known non-capabilities
概念解释
产品页写「可以写邮件、改代码、读表格」，很少写「不能出庭作证、不能当班值班医生、不能保证引文真实」。人用肯定清单去外推，空白处会被填成「大概也行」。负向能力披露（negative capability disclosure）是把系统明确做不到的事说出来，与正向清单同一层级，而不是附录里的免责声明。
能做的清单在卖点里已经有人写。这条管的是没人愿意写的那一半。
机制
肯定描述会被读成能力的下界，不是上界。「能总结合同」在语言里并不排除「能给出法律意见」，除非法律意见被单独点名为不能。范畴归纳会把相邻任务一并收进来：会写邮件就被当成会处理投诉升级，会读表就被当成会做账。
空状态和示例又只展示成功路径，负空间没有视觉位置。人不是忽略了边界，是界面从未把边界当成一种信息对象。等失败来教，成本已经付在一次错误行动上。
怎么研究
给两份能力说明：只有正向清单，vs. 正向加三条明确的不能。然后让人判断一组未提及的相邻任务「这个系统会不会做」，并选择是否把该任务交出去。自变量：负向条目的具体性（「不提供法律意见」vs.「结果可能不准确」）、负向条目与测试任务的语义距离。因变量：外推范围、错误交托、说明阅读时间。
「结果可能不准确」这类万能句不应算负向披露。它不指向任何任务，不能缩小外推。
边界
开放域对话助手的不能清单写不完，只能按后果分层：高后果类别（医疗、法律、金融操作）必须点名，低后果的长尾可以靠失败时的局部说明。儿童和弱势用户对负向句的理解弱于对正向示例的理解，负向披露不能替代拦截。这条只论证「不能」需要被当作信息来写，不规定必须在第一次打开时全部读完，也不处理版本漂移。
怎么落地
- 在能力说明、空状态和首次引导里，给「不做」单独一块，与「能做」并列，不要塞进条款第十七款。
- 负向条目要落到任务类别：不诊断、不提交对外邮件、不修改生产数据。禁止只用「可能出错」。
- 用户一旦走进被点名的不能区，拦截并回指那条负向说明，而不是生成一个听起来像能做的答案。
- 验证：拿说明书去问没见过产品的人「它会不会帮你向银行投诉」。若正向清单里没有投诉、负向也没写，而答案是「会」，负空间在被默许填满。