E6.05.3specific confirmation copy设计
确认文案需描述具体后果与对象
别名: 确认文案 · named consequence · 删除对象名
概念解释
即使确认用对了场合，问句仍可能是空的。「确定要删除吗？」没有说出删的是哪一个、删完会怎样。具体后果与对象指文案里要出现可识别的名字，以及动作结束后仍为真的那句结果：哪份文档、哪笔款项、对谁可见、能否恢复。按钮上的词也应是动作本身（删除「年度预算」），而不是「确定」。确认框的工作是把将发生的世界摆到眼前，不是再要一次同意的手势。
机制
人点开确认时，工作记忆里装着的是刚才那次点击的意图，不一定装着对象的完整身份——尤其是列表里连续操作、对象名在上一屏。对话框若只重复动词，用户拿意图去匹配问句，匹配成功就点，对象从来没有被核对。具体名字迫使一次识别：这是不是我以为的那一份。后果句迫使一次预测：没有回收站、会通知 30 个成员、钱当天划走。识别和预测是确认还剩的唯一认知工作；拿掉它们，对话框只剩下习惯化要穿过的那张脸。模糊文案还会让两件后果不同的事长得一样，习惯化跨过对象边界扩散。
边界
对象极多时无法在标题里列完（「删除 40 个文件」），要给摘要加可展开的名单，至少露出几个文件名，不能只剩一个数字。对象名过长或含用户看不懂的内部 ID，等于没有名字，应显示人读的标题，ID 留给技术细节。后果取决于服务端、客户端说不准时，写已知的上限（「可能无法恢复」）比假装精确更诚实；但不要用上限当借口写回「确定吗」。多语言里按钮宽度会逼着缩短动词，宁可折行也要把对象留下，不能先牺牲名字。
怎么落地
- 标题或正文出现对象的显示名；按钮写动作加对象，不用「确定 / 取消」当唯一标签。
- 用一句现在时写后果：不可恢复、谁会收到、钱或权限怎么变。不要写「此操作无法撤销」却不说撤销的是什么。
- 批量时给数量和可滚动名单，默认选中的若与用户以为的不一致，要在文案里暴露。
- 验证：截下确认框，遮掉背后的页面，问「删的是什么、删完怎样」。答不出名字或答错后果，文案就是空的。