L1.02.2pre-attempt boundary disclosure设计研究
边界应在尝试前而非失败后告知
别名: 事前边界 · 失败后告知 · just-in-time too late
概念解释
人把句子发出去，是已经付了表述成本和期望。这时再弹出「本系统不处理这类请求」，信息也许准确，时机已经错了：行动已经发生，信任已经按「它会接」在结算。事前边界（pre-attempt boundary disclosure）要求边界出现在尝试之前——在输入还没被当成一次提交的时候。
失败后的说明是补救，不是披露。补救解释的是刚才为什么不行；披露要阻止那一次提交本身。
机制
提交是承诺点。发出去之前，人还在构造意图，边界可以改写意图（换工具、换问法、不问）。发出去之后，同一句话变成对失败的归因材料，常被读成推诿。期望已按「系统会处理」编码，落空按失望记账，不是按「原来不该问」记账。
即时（just-in-time）帮助在确定流程里常被推崇，因为它出现在需要的那一步。生成界面的「需要」发生在人开始投入之前：一旦开始写一段复杂提示，沉没成本会把人推向提交，即使中途看到灰字警告。所以边界要出现在投入开始处，或在可识别的高后果意图刚被解析出来、尚未执行时——后者已经是最后窗口，不是首选窗口。
怎么研究
比较三种时机：打开即见边界、输入过程中识别到类别再提示、提交失败后说明。任务是一道明确越界的请求（请开药、请把这封投诉发出去）。因变量：是否仍提交、提交前的编辑次数、失败后的责怪对象、是否换通道完成任务。
输入中提示必须测量「看见了但照发」的比例。看见不等于及时——沉没成本已经超过警告的力。
边界
用户已经熟练、边界稳定时，每次打开都读一块「不能」会成噪声，可改成在识别到越界意图时拦。首次使用、高后果、边界刚变过，事前仍是默认。识别器自己会误报：过早拦截伤合法任务，过晚又退回失败后告知。这条不讨论负向清单写什么，只讨论那份信息出现的时刻。
怎么落地
- 空状态和输入框附近放与本产品最容易被误用的两三条边界，在人开始写长提示之前可见。
- 解析到高后果意图时，在发送之前拦住：把「将要做什么」摊开，提供改写或取消，不要先生成再道歉。
- 失败后的说明可以留着当补救，但不得作为唯一边界通道。统计里若大多数边界曝光发生在 4xx/拒答之后，时机是失败的。
- 验证：让新用户去做一道你们明确不做的任务，看他们在第一次提交前有没有机会看见边界。没看见就提交，时机失败，与文案写得多准无关。