演示时如何看到会议室里的情况？

当您共享屏幕的那一刻，您就无法再看到与您共享屏幕的人了。面孔消失了。聊天消失了。举手——会议室里最需要即时响应的信号——也消失了。

这是各大平台支持论坛中最持久的抱怨之一，人们的描述方式惊人地一致。一位演示者向 Microsoft 请求该功能：“作为演示者，读懂观众至关重要。” 一位教师在 Zoom 论坛上写道：“如果我想与某个特定的学生互动，我根本不知道谁在外面。” 另一位用户描述了他们的损失：“所有那些如果我们面对面就能做到的事情。”

抱怨不在于缺少某个面板。而在于在线演示将您置于一个在现实会议室里没人会接受的位置：对着墙说话，猜测是否有人跟得上。

每种修复都在用一个损失换取另一个损失

这个问题之所以顽固，是因为现有的答案并没有消除问题——它们只是转移了问题。

浮层会遮挡您正在展示的内容。 将参与者画廊置于内容之上，您找回了会议室，代价是遮挡了您正在演示的内容。一位 Zoom 论坛上的主持人：“我能找到的唯一方法是将画廊叠加在 PP 上，但这会遮挡部分图像。” 另一位用户从正反两方面描述了同样的困境：“全屏时它遮挡屏幕，不全屏时它又占据了我认为过多的空间。” 遮挡或不可见——只能选一个。

第二台显示器也不能可靠地解决问题。 这是标准的建议，值得精确说明其局限性。它假设您有第二台显示器，这排除了仅有笔记本电脑和出差的设置。但即使有两台显示器，用户也报告说幻灯片进入全屏的那一刻就丢失了参与者名册：“每次我将 PPT 切换到演示模式，我就看不到参与者画廊了。我的选择是要么在一台显示器上放共享屏幕，另一台放演示仪表板，要么让两台屏幕互相镜像……两者都显示共享屏幕。无论是上课还是开会，这都完全无法接受。”

窗口调度才是人们实际的做法。 现实中的权宜之计是手动编排——缩小、拖拽、重新打开。一位 Teams 用户：“作为变通方法，我打开了 Teams 窗口并移到左边，只能看到参与者列表，同时缩小了我共享的屏幕。”

这些方法都无法解决问题的原因在于结构。会议是一个窗口。您正在演示的内容是一个窗口。在一个屏幕上，窗口相互竞争——争夺空间，也争夺焦点。

最令人头疼的情况：当您正在编辑共享内容时

有一种情况，这种权衡不再关乎舒适度，而是开始阻碍工作本身。

大多数关于屏幕共享的建议都假设您在演示已经完成的内容。一份幻灯片。一个仪表板。一段录制好的流程。但许多工作会议共享的是正在修改的内容——规范文档正在添加新段落，表格正在修正数字，项目看板正在移动大家刚刚达成一致的卡片。正如一位用户在询问如何继续看到参与者时所说：“不仅是 PowerPoint 或 Excel，而是任何东西。”

现在的冲突更尖锐了。要编辑文档，文档需要焦点——它必须是您正在输入的窗口。于是会议退到了后面，随之消失的是有人正在粘贴您应该使用的确切措辞的聊天，以及您用来向众人指示具体哪一行的指针。

让会议保持在前面，您就是在讨论改动而不是在做出改动。做出改动，您就是在盲目工作。工作被推迟到“通话之后”，离开了刚刚达成一致的会议室。

各平台实际记录的内容

厂商记录了三种不同的答案，值得仔细阅读——因为其中一种比其他更接近解决方案，而且它不是人们以为的那种。

Google 记录了 Meet 的画中画模式，说明您可以“使用画中画模式同时演示并找到您的观众”，以及取消固定演示文稿以便您“现在可以在演示时找到更多参与者”（2026 年 8 月核实）。两者都解决了看到参与者的问题；Google 的演示页面没有记录在单屏幕演示时保持聊天可见的方法。

Zoom 记录了双显示器模式，其中“画廊或演讲者视图可以显示在一台显示器上，而另一台显示器显示共享内容”——前提条件包括桌面应用程序以及至少四核的 i5 CPU（2026 年 8 月核实）。这就是第二显示器方案，被写成了功能。

Microsoft 走得最远。Teams 记录了一个“仅对演示者可见”的演示者工具栏，并指出：“选择 Chat 以在演示内容时查看并参与会议聊天的紧凑视图。您的观众不会在您的共享屏幕中看到聊天窗口”（2026 年 8 月核实）。

最后一点对于比较选项的人来说很重要：一个供演示者使用的、私有的、不被捕获的聊天面板并不是市场上的空白——Teams 今天就记录了一个。剩下的区别在于演示者的其他窗口在做什么。Meet 和 Teams 的演示者界面是会议应用程序自身窗口的一部分；您正在编辑的文档仍然是一个单独的窗口，与它争夺焦点。

当会议不再是窗口时，会发生什么变化

浏览器中有一个界面不会与页面争夺焦点：浏览器自带的侧边栏。

Chrome 将 Side Panel API 记录为一种让扩展程序“在浏览器侧边栏中托管内容，并与网页的主要内容并排”的方式（2026 年 8 月核实）。相关的属性是结构性的。该面板是浏览器框架的一部分，而不是标签页的一部分。它位于任何活动标签页旁边，切换标签页时它保持原位，在页面中输入内容也不会将其推到任何东西后面——因为它根本不在页面所在的堆栈中。

这有第二个后果，这里我们应该小心区分已记录的内容和我们测量的内容。Chrome 的屏幕捕获文档将标签页捕获描述为捕获标签页的可见区域，而 W3C 屏幕捕获规范将浏览器 UI 实现的确切边界留给实现决定——两者都没有说明侧边栏会发生什么。所以我们测试了它：当共享标签页时，侧边栏不会出现在捕获的流中。参与者看到的是您选择的标签页，而不是它旁边的面板。

该结果是特定于共享模式的，这种区别正是关键所在。共享您的整个屏幕，该屏幕上的所有内容都会被捕获，包括面板。我们依赖的属性适用于标签页共享，这是此工作流使用的模式。

将这两个属性结合在一起，权衡就化解了，而不是被管理了：

• 文档是活动标签页。它拥有焦点。您在其中输入，它占据屏幕的全部宽度——而不是一半，上面也没有任何叠加。
• 会议位于旁边的面板中，处于应用程序的窄布局中：通话、聊天、参与者、指针控件。
• 您的参与者看到的是文档。不是您的通话窗口，不是您正在阅读的聊天——而是您选择的标签页，以及您在上面使用的指针。

这就是我们构建 InterMIND Chrome 扩展程序的原因——现已发布在 Chrome Web Store，请参阅公告。通话在侧边栏中运行；您共享的标签页仍由您编辑。在项目看板的工作会议中，这意味着看板处于全宽且正在被编辑，指针仍然向会议室指示该看哪里，聊天在旁边仍然可读——同时进行，在一个屏幕上，无需第二台显示器，也没有任何东西遮挡内容。

注意这没有声称解决的问题。面板很窄，因此大量面孔的画廊并不适合那里——这解决的是“在工作时保持会议室及其聊天可触达”，而不是“一次向我展示三十个视频画面”。

诚实的局限

有三件事值得明确说明，因为它们能正确设定预期。

共享仍然从常规选择器开始。 您点击共享，Chrome 询问您想要哪个界面，您选择标签页。侧边栏中没有一键“共享我所在的标签页”的功能——Chrome 不允许扩展程序从面板上下文中捕获标签页，且添加该功能的请求已被 Chromium 团队作为 won't-fix 关闭（2026 年 8 月核实）。选择器只需一次点击。它是机制，而不是变通方法。

这是特定于浏览器的。 侧边栏是 Chromium 的功能。这里描述的场景是 Chrome 和 Edge 的场景；在其他浏览器上，您又得回到排列窗口的状态。

它只解决一个问题。 在编辑标签页的同时共享它，而不丢失通话 UI。它不会让小型笔记本电脑屏幕变大，如果您需要共享的是桌面应用程序而不是浏览器标签页，标签页捕获属性对它也不适用。

这在哪里最重要

这种模式出现在产物是实时的而非已完成的所有地方：

• 文档或规范的工作会议——在会议室做出反应时编辑措辞，而不是写下反馈留待以后应用。
• 电子表格和规划模型——更改输入并让所有人观看数字变化，这正是表格出现在屏幕上的全部原因。
• 项目看板和待办事项——我们内部注意到这一点的原因：在规划通话期间移动卡片和编辑工单，同时仍能阅读大家正在输入的关于它们的内容。
• 设计和代码审查——在通话期间进行小修复，同时指针标记正在讨论的内容。

这些情况的共同点是，会议的价值在于对产物的修改，而任何将编辑推迟到“通话之后”的工作流都会将工作移出达成一致的会议。

常见问题

演示时如何看到参与者？

每个平台都记录了不同的部分答案。Google 记录了画中画和取消固定演示文稿以“在演示时找到更多参与者”。Zoom 记录了双显示器模式，这需要第二台显示器。Microsoft 记录了仅对演示者可见的演示者工具栏（均于 2026 年 8 月核实）。共同局限在于这些界面都位于会议应用程序自身的窗口内，因此它们会与您正在做的其他任何事情竞争——这就是为什么用户报告说，即使有两台显示器，幻灯片进入全屏的那一刻他们仍然丢失了参与者名册。

为什么 PowerPoint 进入演示模式时我会丢失参与者画廊？

因为演示模式接管了它所在的显示器，而会议窗口是一个单独的窗口，被推到了后面。这就是为什么第二台显示器不能自动解决问题的原因：拥有两台显示器的用户报告了同样的损失，因为选择变成了幻灯片占据哪台显示器。人们退而求其次的替代方案是将画廊叠加在内容之上，或者手动调整窗口大小。

在单显示器上共享屏幕时如何看到聊天？

这取决于平台。Microsoft 记录了 Teams 中供演示者使用的紧凑会议聊天视图，指出观众不会在共享屏幕中看到该聊天窗口（2026 年 8 月核实）。Zoom 记录的答案是双显示器模式，这需要第二台显示器（2026 年 8 月核实）。Google 的演示文档涵盖了通过画中画看到参与者，而不是聊天（2026 年 8 月核实）。它们都没有改变的是，演示者界面属于会议应用程序的窗口——因此如果您还需要编辑共享的文档，该文档和会议仍然是两个争夺同一焦点的窗口。

屏幕共享时可以编辑文档吗？

可以——限制不在于编辑，而在于您在编辑时能看到什么。文档必须保持焦点您才能在其中输入，这在单屏幕上会将会议界面推到后面。文档一直处于共享状态；您只是在其中工作时看不到聊天、参与者和指针。

同时演示和工作需要两台显示器吗？

两台显示器是标准答案，也有效。但这不是唯一的答案：浏览器侧边栏在单屏幕上为您提供了第二个界面，因为面板位于浏览器框架中页面旁边，而不是与其争夺焦点。

侧边栏会出现在您的屏幕共享中吗？

当您共享标签页时不会——我们测试过，面板不会出现在捕获的流中。Chrome 的文档和 W3C 屏幕捕获规范都没有说明这方面的行为（规范将浏览器 UI 边界留给实现决定），因此请将此视为测量结果，而不是已记录的保证。如果您改为共享整个屏幕，该屏幕上所有可见的内容都会被捕获，包括面板。

有没有办法一键共享当前标签页，而不使用选择器？

不能从侧边栏。Chrome 不允许扩展程序从面板上下文中捕获标签页，且允许这样做的请求已被 Chromium 团队作为 won't-fix 关闭（2026 年 8 月核实）。共享从标准的 Chrome 选择器开始，您在那里选择标签页。

这在哪些浏览器中有效？

侧边栏是 Chromium 的功能，因此这适用于 Chrome 和 Edge。其他浏览器没有等效的界面，上述窗口权衡在那里照常适用。

这能取代第二台显示器吗？

对于这种特定情况——在编辑浏览器标签页的同时共享它并保持通话 UI 可见——它消除了您需要第二台显示器的原因。它不能取代第二台显示器在所有其他方面的用途。

试试看

• 获取 Chrome 扩展程序——它安装什么，请求什么，以及它不做什么。
• 如何在视频会议中共享您的屏幕——屏幕、窗口或标签页，从手机上，使用激光笔，以及 Meet 和 Teams 的局限。
• 尝试实时演示——在安装任何东西之前，看看翻译通话的表现。
• 了解共享到会议中的文件会发生什么——谁可以阅读它，以何种语言，以及其摘要中的声明是如何被核实的。
• 阅读翻译基准测试——质量数据，包含完整的每对分布及其背后的方法。

来源：Chrome for Developers — chrome.sidePanel API, Chrome for Developers — chrome.tabCapture API, W3C — Screen Capture, Chromium issue 40926394 — chrome.tabCapture from side panel, Google Meet — Present during a video meeting, Zoom — Using dual monitor mode, Microsoft — Present content in Microsoft Teams meetings. 厂商会随时间更改其应用程序和文档；请查看其页面以获取当前状态。所有事实均于 2026 年 8 月核实。