图片描述：一部智能手机放置在木质桌面上，屏幕显示AI聊天界面，耳机插入其中——这是屏幕阅读器友好型AI提示词设计的视觉标志。

阅读时间：9分钟

过去十八个月间，无障碍社区内部悄然形成了一门新的设计学科，至今尚无定名。一些团队称之为”辅助技术感知提示工程”；另一些称之为”屏幕阅读器适型系统提示”；从语音界面设计领域成长起来的实践者则倾向于称其为”大语言模型的语音输出层”。无论如何命名，这门学科的核心是一致的：编写系统提示词和输出规范规则，使生成式AI助手——ChatGPT、Claude、Gemini、Copilot、Be My AI——对全球约2.53亿依赖屏幕阅读器访问这些产品的用户切实有用。

问题具体而明确，失败方式也十分刺耳。以公开网络数据训练的大语言模型，默认会生成充斥着破折号、嵌套Markdown列表、代码围栏、仅因”答案看起来有结构”而存在的标题，以及装饰性表情符号的文本。这样的输出经由NVDA、JAWS、VoiceOver或TalkBack朗读时，会变成一连串”破折号破折号”的插话、毫无条目边界感的”项目符号项目符号项目符号”枚举、打断句子的”二级标题”播报，以及每隔两句话便出现表情符号名称串（“戴太阳镜的笑脸”）。信息本身是存在的，但用户必须倒回重听三遍才能提取。本文是关于这门学科对模型开发者的要求、各产品目前的进展，以及尚无人攻克的开放式用户体验问题的入门解析。

新学科的内容——它究竟包含什么

屏幕阅读器感知提示设计并非单一规则，而是一组约束条件，共同作用后能产生合成器可清晰发音、屏幕阅读器导航键可流畅穿行的输出。这些约束可归纳为四个维度。

简洁回复与语义结构。默认的大语言模型输出对语音传递而言过于冗长——一篇视力正常用户在浏览器中阅读起来没问题的600字回答，变成了屏幕阅读器用户无法略读的四分钟独白。这门学科要求更短的回答，但更重要的是结构化的更短回答：开篇一句概括性陈述供用户随时停下，随后是屏幕阅读器可通过标题或列表项导航的结构。

避免破折号和其他合成器发音不正确的标点。破折号、连接号、括号表达、用作连接词的斜线、ASCII分隔线——这些符号被朗读时要么是一片沉默、字面上的”破折号”，要么是将语句割裂的令人困惑的停顿。各主流模型正在形成的惯例是：优先使用逗号和句号；在确实有必要的地方用冒号；在面向语音的响应中永远不用破折号；永远不用ASCII分隔线分节。

明确声明列表、标题和代码。合成语音没有视觉层级。标题需要被播报为”标题”，列表需要被播报为”包含N个项目的列表，第一项”，代码需要被播报为”代码”，模型必须输出屏幕阅读器能识别的结构（HTML、渲染表面能转换为ARIA的正确Markdown），或者用语言本身陈述结构（“以下是三个选项。选项一：……”）。

不要堆砌Markdown。当渲染表面将Markdown转换为语义HTML时，Markdown是合适的。当渲染表面直接显示原始星号和下划线时，Markdown是不友好的，因为屏幕阅读器会在每个粗体词前播报”星号星号”。这门学科的要求是检测渲染上下文——带Markdown渲染的聊天界面，还是终端，还是屏幕阅读器驱动的语音界面——并据此调整输出形式。同一个模型需要为同一个答案生成不同的界面表示。

屏幕阅读器真正需要AI提供什么

为了让上述约束更加具体，有必要审视实际支配该领域的四种屏幕阅读器/操作系统组合：Windows上的JAWS、Windows上的NVDA、macOS和iOS上的VoiceOver、Android上的TalkBack。它们并不通用，一个对某个阅读器产生良好输出的提示词，在另一个上可能完全无法阅读。

按标题导航。四款阅读器均提供标题导航键（JAWS和NVDA中为H键，VoiceOver中为转子，TalkBack中为阅读控制切换）。要让一段较长的AI回答可供导航，模型必须输出真实的语义标题——要么通过将Markdown转换为具有正确层级嵌套的<h2>/<h3>的Markdown渲染管道，要么通过聊天界面自身的结构化响应API。将前三个词加粗以”构建结构”的模型，生成的内容视觉上看起来有结构，对屏幕阅读器而言却完全是平铺文本。

按列表导航。列表在语音输出中之所以有用，正是因为屏幕阅读器会播报数量（“包含七个项目的列表”）并允许用户用列表项导航键（NVDA中为I键，JAWS中为L键）逐项浏览。但这只有在列表是真实的<ul>或<ol>时才有效。通过在每行开头添加项目符号字符而无列表包裹容器产生的”列表”，会被当作普通文本朗读，每行都有一个莫名其妙的”实心圆”或”项目符号”插话。

按节跳读。长篇AI回答——解释、比较、代码加注释、多步骤说明——需要一种方式让屏幕阅读器用户无需听完前言就能跳到感兴趣的部分。这是设计难度最高的单点，因为模型必须生成可导航的结构，聊天界面必须以操作系统能向辅助技术暴露的方式渲染，屏幕阅读器还必须在该界面中配置使用标题导航键。三者在实际中均有失效；通常失效的是中间那个。

发音提示。合成语音在技术术语、大小写混合的缩写词、URL、代码标识符、数学符号和非英文名称上容易出错。针对屏幕阅读器场景的精良设计模型会在首次出现时拼出缩写词（“WCAG，即Web内容无障碍指南”），展开合成器无法发音的首字母缩略词，并避免将原始URL嵌入流动文本中（合成器会把斜线朗读出来）。截至2026年，没有任何主流产品能持续做到这一点。

各产品的应对方式

截至2026年中期，主流生成式AI产品在屏幕阅读器感知输出上采取了明显不同的立场。没有一款做到完美。进展比十二个月前快，但最好与最差之间的差距依然很大。

ChatGPT（OpenAI）。网页客户端现已内置”简洁模式”切换，可缩短默认响应并减少Markdown装饰。2024年引入、2025年大幅升级的语音模式，是目前任何主流产品最接近屏幕阅读器原生界面的体验，因为它完全绕过视觉聊天界面，直接以语音形式提供带停止、重播和”再说一遍”手势的答案。自定义指令字段允许屏幕阅读器用户一次性声明偏好并在会话间持续生效，这是社区已接受的用户端变通方案。尚存差距：GPT模型在未明确指示的情况下仍默认使用破折号密集的文本，且Markdown中输出的标题层级并不总能在聊天界面中干净地映射为ARIA。

Claude（Anthropic）。Claude的系统提示规范在2026年已最接近上述惯例。与GPT系列相比，该模型明显少用破折号，默认回答较短，并能很好地响应诸如”您正在与屏幕阅读器用户交流；不使用破折号，优先使用短段落，需要结构时使用真实标题或编号列表”这样的系统提示指令。Claude.ai聊天界面将Markdown渲染为带正确标题层级的语义HTML，使标题导航键得以正常工作。通过第三方集成的语音输出存在，但不如ChatGPT的第一方语音模式成熟。

Gemini（Google）。与Android上TalkBack的紧密集成是Gemini的结构性优势；该模型能通过Android无障碍服务将输出交接给操作系统级屏幕阅读器，这是iOS和网页竞品无法实现的。在无障碍Android设备上使用”嘿Google，问问Gemini……”流程，对某些用户而言是目前最自然的AI加屏幕阅读器体验。尚存差距：网页界面的响应仍然过度装饰，Gemini网页答案的标题层级不一致，且该模型比竞品更容易生成装饰性表情符号。

Be My AI（Be My Eyes + OpenAI）。这是四款产品中范围最窄的一个——一个使用GPT-4级视觉模型为视盲和低视力用户描述图像和周围环境的视觉描述助手。它也是这份清单中唯一从一开始就以屏幕阅读器用户为主要受众设计的产品。Be My AI的提示设计是该领域对辅助技术感知输出最清晰的示范：描述以用户可随时停下的一句概括开头，仅在被要求时才提供结构化细节，并避免需要视觉场景才能理解的空间语言（“左侧”、“上方”）。截至2026年，该产品仍是该领域最接近参考实现的产品。

横向观察表明，四款产品在容易的部分取得了进展——更短的回答、更少的破折号、自定义指令字段——而在困难的部分几乎尚未起步。困难的部分见下文。

尚无人攻克的开放式用户体验问题

屏幕阅读器感知提示设计文献汇聚于四个尚无正确答案的开放式用户体验问题。这些都不是模型能力问题，而是横跨大语言模型、聊天界面、操作系统与屏幕阅读器之间的交互设计问题。

可中断性。视力正常的用户约两秒钟就能扫完一段大语言模型的响应并判断是否需要阅读。屏幕阅读器用户无法这样做。如果答案有误或偏题，用户必须听到足够多才能意识到这一点，然后再中断。语音模式有停止按钮，文本模式通常没有——响应以流式传输方式进入，屏幕阅读器在新内容到达时便播报，用户没有清晰的方式说”停止生成，这不是我想要的”。Be My AI应用处理得最好，网页聊天客户端处理得最差。

可选粒度的重复上一个答案。如果答案很短，让屏幕阅读器重读上一次响应很简单。如果答案有六段，用户只想再听一遍第三段，则完全无法操作。社区所期望的交互是”重复上一个列表项”、“重复上一个标题节”、“重复上一个代码块”——这要求聊天界面将结构以屏幕阅读器自身重读命令可寻址的方式暴露给屏幕阅读器。截至2026年，没有任何主流产品能做到这一点；用户只能使用屏幕阅读器自身的逐行导航，十分费力。

语音输出中的按节导航。语音模式没有标题导航键。用户线性地聆听一段四分钟的回答，无法从”概述”部分跳到”细节”部分，只能按时间倒回。正在原型化的交互设计——用户可用方向键导航的语音”节列表”、“跳到第三节”语音命令、“只给我标题”模式——还处于早期阶段。Be My AI应用中的”告诉我更多颜色细节”追问是已发布产品中最接近这一交互的实现。

辅助技术交接问题——AI何时开口，何时让内容被朗读？这是最深层的设计问题。如果屏幕阅读器用户在网页上打开AI助手，谁在说话——AI自己的语音（TTS层），还是用户已安装的屏幕阅读器朗读AI的文本输出？两套语音的设置不同、语速不同、发音提示不同、停止和重播手势不同。两个系统试图同时朗读相同内容会产生完全无法使用的效果。正在形成的惯例是：语音模式交互使用AI自身的TTS并明确抑制屏幕阅读器；文本模式交互输出语义HTML并由屏幕阅读器负责朗读。但两种模式之间的边界并不总是清晰——图像描述、代码生成、数学符号和多模态答案都尴尬地处于语音与文本之间——而那个边界正是大多数现实用户体验问题所在之处。

未来走向

这门学科大致处于网络无障碍约在2002年所处的阶段——越过了”这是真实问题吗”阶段，越过了”谁来负责”阶段，进入了”实际规则是什么”阶段。2026至2027年可能发生三件事。

其一，模型开发者将整理其内部屏幕阅读器提示并予以公开，就像Anthropic在VPAT式无障碍声明中发布Claude系统提示、OpenAI开始记录GPT行为默认值那样。社区正在要求模型卡的等效物——一张”屏幕阅读器输出卡”，列明给定模型经过训练或系统提示遵循的惯例。

其二，聊天界面——网页客户端、移动应用、IDE集成——将获得完善的语义HTML渲染管道，以及聊天历史的完善ARIA暴露，导航键映射到操作系统级屏幕阅读器。这是不起眼的工作，却是对日常用户影响最大的工作。

其三，屏幕阅读器厂商本身——Vispero（JAWS）、NV Access（NVDA）、Apple（VoiceOver）、Google（TalkBack）——将开始发布AI感知功能：在AI聊天界面内原生的标题导航、标准化的”停止生成”手势、了解大语言模型响应结构的更智能重读命令。NVDA的开源插件生态系统已在产出这些功能的早期版本。专有阅读器的进展较慢，但方向相同。

更深层的观察是：屏幕阅读器感知提示设计已不再是少数视盲开发者的小众议题，而已成为每个希望在受监管市场发布产品的AI产品团队的基准期望。《欧洲无障碍法》适用于”交互式自助服务终端”和”具有交互式计算能力的消费者终端设备”——这一类别几乎肯定涵盖手机上的主流AI助手。辅助技术感知输出层不再是功能，而是采购约束。现在就弄清楚规则的团队，将发布在2025年6月28日及此后存活的产品。将其视为事后考量的团队，将成为下一批EAA执法案例。

结语

这门学科规模不大，关乎重大，规则仍在书写中。如果您在使用大语言模型构建产品，却尚未与屏幕阅读器用户就产品的实际听觉体验进行过交流，那就是下一件要做的事。2026年AI对屏幕阅读器用户体验不佳的大多数问题，并非模型能力问题，而是任何产品团队只要下定决心，在一个冲刺周期内即可解决的提示词和界面设计问题。

这个社区在时间、测试和耐心上一直慷慨大方。但它失去耐心的速度也在加快，因为这些产品如今已是主流，“我们还在摸索中”的借口已经站不住脚。这门学科已经存在，惯例正在收敛。接下来的十八个月将区分出那些倾听过的团队和那些没有的团队。