读屏用户怎样知道剧情新增了内容，而不反复听整页？

行动后新增一段剧情，可以先给一句简短的完成通知，把完整结果放进有明确标题的正文区域，并让用户决定何时前往阅读。通知回答“刚才的操作有结果了吗”，正文回答“具体发生了什么”，焦点策略回答“接下来从哪里操作”。三者各做一件事，才能避免一次更新引出整页重读。

状态消息可通过角色或属性呈现，无须取得焦点。参见状态消息说明。这一依据不构成整段剧情自动播报的要求。下面的职责表、措辞和交互顺序均为原创教学设计，不是对某个产品实现的描述。

本文只处理“当前页面保留旧剧情，行动后追加结果”的场景。示例中的旧灯塔、守塔人和操作流程全部虚构，不是真实用户案例、实测成果或 DramaFork 已有功能。设计目标也不是承诺某种读屏表现，而是先写出可检查的交付要求。

交付时，把下面这张表随剧情节点一起填写。不要只在需求中写“支持读屏”，因为这句话没有说明新增内容该由谁读、何时读。

状态提示无需复述铜盒里有什么；正文则必须独立完整，即使用户没有听见提示，也能找到并理解结果。入口名称要说明目标，“查看”或“这里”脱离上下文后难以辨认。

焦点是当前操作位置；读屏阅读位置也需要单独检查。验收时不能只看到按钮仍有焦点，就断言用户还能从原句继续听。职责表规定预期，具体实现仍需确认移动端阅读手势、键盘操作和内容更新之间的实际关系。

虚构场景中，旅人站在旧灯塔门口，原文写着：“守塔人把铜盒推到桌边，示意你检查盒底。”用户读完后激活“检查铜盒”。此时操作已提交，但结果尚未就绪，界面应区分等待与完成，不能立刻通知“发现新线索”。

结果准备好后，在旧文后追加以下内容：

检查铜盒的结果

盒底压着一张潮湿的值班单，背面写着“钟响前去北门”。守塔人认出纸上的笔迹，却把解释留到见面之后。你还不知道是谁留下了这句话。

可选行动：询问值班单的笔迹；带着铜盒前往北门。

与此同时，状态提示只写：“检查铜盒已完成；新增结果，可前往阅读。”它确认操作结束，不提前朗读值班单的内容。阅读入口使用表中的完整名称，用户选择后再从新增标题进入正文。

假设用户等待期间正在重读守塔人的上一句话，结果到达不应把他突然带到北门选项。假设用户仍停在原操作附近，他也可以直接找到阅读入口。两条路径最终到达同一段正文，无须为通知另存一份缩短的剧情版本。

读完结果后，后续行动放在本段结尾，用户可以顺序到达。若还提供“返回操作区”，其目的地应事先确定，不能泛泛返回页首。一次完整检查要覆盖提交、等待、收到通知、进入结果、选择下一步，而不只是确认听到了“已完成”。

“留在原位，提供入口”适合用户可能继续查看旧剧情的追加场景，但不必成为所有页面的唯一方案。若操作本来就叫“打开下一章”，进入新章节是用户已经表达的意图，可以另行设计章节切换后的阅读起点。不要把这个规则直接套到普通的“询问守塔人”。

也可以设计由用户主动开启的“结果到达后朗读新增内容”模式。此时应明确朗读范围仅为本次结果，并提供暂停和重新定位的办法。它属于额外的阅读选择，不能因为系统有了状态通知，就推断用户同意自动听完整段落。

对于“铜盒已收起”这类短结果，通知可以包含动作结论，但正文或可回查记录仍应保留该变化。如果新增内容包含悬念、对白或下一步判断所需信息，通知宜保持简短，把解释交给正文。分界依据是用户是否需要按自己的节奏阅读，不能仅按字数机械截断。

如果行动只改变现有记录，没有新增剧情，就说明“铜盒记录已更新”，并指向更新处。不要继续沿用“新增结果”的模板，否则用户会寻找一段不存在的新文。

第一种失败是把整页剧情作为更新通知的内容来源。盒底多出一句话，却连灯塔开场也重新读了一遍。检查时记录被通知的实际文本范围，要求它只表达本次操作状态；完整故事继续由正文入口承担。

第二种失败是通知说“已完成”，正文还没有可读结果。应以结果已经就绪且入口可用作为完成提示的条件。若请求失败，则明确本次没有新增剧情，保留原文并给出重试入口；重试也不能把同一份结果重复追加。

第三种失败是结果刚出现便移动焦点，同时又播报摘要。用户既失去原位置，又可能接连听见两份相似内容。按职责表分别检查通知和跳转：前者随状态变化，后者由明确的阅读动作触发。

第四种失败发生在连续行动中。“已更新”无法说明对应哪一次操作。可给结果使用可辨认的行动名称；若允许同一行动多次提交，还需要区分各次结果，并明确哪些结果尚未阅读。不要仅用视觉上的最新一条代替这种关系。

最后，把上述情境交给实际目标设备上的读屏检查。记录是否重复朗读、是否丢失位置、入口是否到达新增开头，以及错过通知后能否找回正文。这里提供的是检查脚本，不是已通过的测试报告。涉及弹窗、整页导航或限时选择时，应另写交互规则，不能用这张追加结果清单概括所有情况。