L2.13.1accept-or-redo trap设计研究
输出若不可编辑，用户只能在接受与重来之间二选一
别名: 接受或重来 · 只读生成物 · all-or-nothing generation
概念解释
一封生成的邮件停在只读气泡里。八成写对了，有一句称呼错了。用户没有改那一句的入口，只能点「用这封」或「再生成一封」。这是接受或重来（accept-or-redo trap）：决策集合被压成两个极端，中间所有「改一个词、删一句、换个数字」都不存在。功能看起来给了控制（可以重试），实际只给了抽奖次数。
它和「只有重试等于没有控制」相邻，但焦点不同：这里崩的是决策结构。人面对的不是连续的修改，是一次对整份产物的判决。
机制
只读输出把生成物当成展示，不当成材料。展示的合法动作是收下或丢掉。丢掉之后的下一次是重新采样整份分布，先前那八成正确没有被当作条件锁住，于是「再来一次」经常把已经对的部分一并抽走。人很快学会：差一点的就将就接受，因为重来的期望值更差。将就会把错误的称呼发出去。
复制到外部编辑器是一条非正式逃逸。逃逸一旦成为主路径，产品内的「重来」按钮就变成承认自己没有中间档。
怎么研究
给一份故意在单点出错、其余正确的产物，界面分为只读+重来 / 可就地改那一点。因变量：接受带错版本的比例、重来次数、是否把文本拷出、任务时延。再测主观「我有没有改过它」——只读组即使重来多次，也往往报告自己没有编辑过，因为他们从未碰到文本。
错误点的可见性要控制。太显眼人人都会重来，测不到将就；藏在称呼、日期、附件名里更接近真实发出前的漏检。
边界
输出是一次性观赏物（一句笑话、一张氛围图）且没有下游使用，二选一够用。输出马上要进入外部权威编辑器（代码进 IDE、文稿进已有文档工具）时，只读是中转，前提是复制完整、格式不丢。高风险发出（对外邮件、正式公告）即使可编辑，仍需要发出前的核对，可编辑不自动等于可发出。
怎么落地
- 默认把生成物放进可键入的表面：文本就是编辑器，幻灯片就是可点的对象，而不是聊天气泡。
- 「用这份」和「再生成」可以留，但必须同时有第三条：在这份上改。第三条要能不离开当前视图完成。
- 将就发出是可观测的：发出物与生成物若完全一致，且生成物带有用户曾停留、却未改动的错误点，记为二选一将就。
- 验证：放一篇只有一处错误的草稿。只读界面下，统计发出带错的比例；改为可键入后，同一错误应能在不重生成的情况下被改掉。若用户仍整篇重来，检查是不是编辑入口藏在菜单里——入口必须落在错误所在的那一行旁边。