AI 工具界面总在解释自己，哪些文案该删、哪些必须留？
核对 stop-describing-ui 原仓库的删减规则，并以本站二维码源码为例，说明输入条件、失败提示和下载结果各需保留哪些文字；未进行用户效果实验。
怎么判断？
先保留会影响用户下一次操作的文字。stop-describing-ui 要求用具体动作替代功能介绍，也明确保留破坏性操作的后果与容易误试的限制。本站二维码里，空输入提醒和无法识别时的重试办法就不能一并删除；生成成功后还要说明下载文件在哪里。本文对照了仓库规则、WCAG 说明与本站实现，没有测量改字后的任务完成率。
仓库规则保留会造成误操作的条件
截至核对日，仓库 README 用空状态和开关等界面举例，完整规则放在 skills/stop-describing-ui/SKILL.md。规则要求把泛泛的功能介绍改成具体动词，并删掉页面已经表达过的解释。它也有例外：删除数据等不可逆后果必须保留，用户容易误试的权限限制也需说明。
这是一套界面写作建议，不能代替无障碍规范。仓库建议省略后台细节；如果某条说明决定用户是否愿意上传资料，就仍应按实际处理方式交代。是否删掉一句话，应由它帮助用户避免什么错误来决定，不能只计算减少了多少字。
二维码源码能给出具体文案的依据
本站二维码的生成模式先读取输入文字，去掉首尾空白后检查是否为空；读取模式则先检查是否已选择图片。图片选择还会核对文件类型和大小。这里需要保留能让用户继续操作的提醒，不能用一个笼统的失败提示替代所有分支。
下表对照 vendor/file-converters/qr-code.js 与 common.js 中的实际分支，说明现有文字为什么有用。它不是修改前后的用户测试。生成图片和提取二维码内容是两种不同结果，按钮也应继续使用各自的动作名称。
| 实际情况 | 现有提示 | 应保留的信息 |
|---|---|---|
| 只输入空白 | 请填写文字或链接。 | 指出缺少输入，用户可直接补填 |
| 未选择二维码图片 | 请先选择二维码图片。 | 指向选择文件的下一步 |
| 图片中未识别到二维码 | 没有识别到二维码，请上传清晰、完整的二维码图片。 | 区分识别失败与没有选择文件 |
| 二维码生成完成 | 二维码已生成，点击下载保存。 | 说明已经得到图片及保存动作 |
错误和完成状态都要能被读到
WCAG 2.2 的错误识别说明要求，用文字指出自动检测出的输入错误。红色边框或感叹号可以辅助提示，不能代替错误描述。本站在未填文字时给出补填要求，内容过长时提示缩短后再试，这两种情况需要不同的改正办法。
状态消息说明关注不转移焦点时的结果通知。结果区域出现一个二维码，不表示读屏用户已经获知生成结束；实际实现还应让处理完成的消息能通过合适的角色或属性被读到。本文没有做读屏兼容测试，也不据此宣布整页符合 WCAG。
删掉介绍之后仍需检查任务能否完成
可以用一段普通文字检查生成操作，再换成空白输入，确认提示能引导继续填写。随后上传不含二维码的图片，检查页面是否解释未识别到内容，而非把失败写成已完成。这是可重复的检查方案，不是本文已经取得的通过记录。
本次核对了原仓库规则和本站代码中的状态分支，没有安装这个第三方 skill，也没有测量使用耗时或询问用户。若后续比较两版文案，应保持相同输入和操作设备，观察用户是否能找到下载、遇到错误后能否继续，而不是把文字减少直接写成效率提升。
核对来源
以下链接支持文中的项目描述或事件事实。本站判断由编辑撰写，未把来源中的主张当作本站实测结论。