查询批准过了，明天的结果还适合给这些人看吗？

一张周一适合共享的看板，到了周二，可能已经不适合原来那批人看了。查询语句甚至一个字都没改。

也许查询现在包含了刚签约的客户。也许筛选后的汇总只剩一个人，接收人一眼就能认出是谁。也许某个内部状态字段换了含义。共享地址照常打开，图表看起来也很熟悉，当初批准那份结果的人却未必注意到变化。

Anthropic 在 11 月 10 日发布 Claude Data 实时共享后，值得做的实验正是这一项：一条已经批准的计算规则，能否持续产出适合这组接收人的内容？它比“助手有没有数据库权限”更具体，也比把所有结果共享都视为泄露更有判断价值。

本文提出一套使用合成数据的实验。我们没有连接 Claude 账号、创建看板、操作共享控制，也没有观察到数据暴露。下文的公司、记录、数量和预期结果，都是供团队自行搭建的测试设定。这套方法可以发现某个具体配置与共享要求之间的差距，不能据此认定产品存在普遍漏洞，也不能为一次部署颁发安全认证。

先读清楚新共享方式的承诺

Anthropic 在Claude Sheets、Whiteboards 和 Data 的发布说明中表示，Claude Data 已正式开放，认证查询和实时共享仍处于 beta。官方描述的机制是：同事即使没有提供数据的连接器权限，也可以查看发布者已批准查询的最新结果；他们不能借用发布者的访问权限运行其他查询。

这是有意设计的发布边界：接收人得到结果，不等于得到源系统的操作能力。但这段说明没有回答每一条后续新增记录、变更后的定义、缓存响应、导出文件和撤销共享会怎样处理。这些需要放回具体配置中分别确认。

同一页面还说明，Enterprise 默认关闭 Whiteboards 和 Sheets，Claude Data 则会在 11 月 19 日默认开启。管理员应检查自己组织里的实际设置，不能把有日期的默认值当作某个账号今天已经拿到功能的证据。如果实时共享尚不可用，就记录这一限制，先准备测试材料，不要拿另一个产品的行为替代验证。

团队真正要做的选择是：哪些内容可以实时发布，哪些应该冻结为审核过的快照，哪些需要缩小接收范围。助手的能力榜单无法替你完成这种分类。

查询、结果与阅读权限是三件事

查询是一套选取或计算信息的规则。结果是这套规则在某个数据状态下产生的内容。受众则是在特定用途下获准接收这些信息的人。批准其中一项，并不自动解决另外两项。

这种区分在数据产品中并不新鲜。BigQuery 的授权视图文档介绍了通过视图共享选定数据、而不直接开放底层数据集的做法。它证明的是一种设计模式，不能拿来推断 Claude Data 的内部实现，也不能保证两个产品执行完全相同的规则。

例如，一份按行业统计试用账号数量的周报，查询语句可能始终不变，但数据里出现了新行业，“试用”的定义发生了变化，或者某个分类只剩一个账号，接收人结合已有信息就能识别。查询哈希会正确地告诉你：计算规则没有变化。它不会告诉你：这份结果是否仍适合给原来的人看。

因此，实验开始前要分别写清两个承诺：接收人可以看到哪类结果，以及接收人可以对源系统做哪些操作。允许前者、禁止后者，完全可能是合理设计。如果把这种区分本身当作失败，实验就失去了意义。

让团队面对真实的发布选择

设想一家三人小公司 Harbor Desk，正在搭建客户成功周报。创始人希望顾问看到每周的产品采用进展，一名产品同事负责源连接器。顾问可以看已批准的试用活动汇总，但不应看到账号名称、内部支持备注或其他客户的详细信息。

这是一组虚构角色，不是客户案例。如果产品允许，建立三个不同的测试身份：发布者、获邀查看者、未获邀查看者。把源数据访问权限与看板成员资格分开。发布者自己另开一个标签页访问共享地址，不能算作接收人验证。

用相同的初始信息比较两种确实可实现的交付方式。快照方式下，发布者审核一份带日期、内容固定的结果，通过受控且受支持的渠道交付。实时方式下，获邀查看者打开产品支持的实时内容。除非界面确实提供原生快照功能，否则不要把导出文件描述成 Claude 的原生快照。

实验不是比较哪种方式更显先进，而是判断哪一种符合团队对接收范围、时效性和审核投入的要求。数据敏感性不断变化时，快照可能更合适；决策依赖最新信息时，它又可能造成误导。实时共享可以减少重复搬运，但也可能要求更强的源数据约束。两种方式都应得到公平的检验。

在第一张图出现前，先设计未来的数据

搭建一个只有十二条记录的合成数据源：八条普通试用记录，按规则允许进入顾问周报；四条内部记录，按团队的发布政策必须排除。每条记录都带一个明显虚构的标记，不要使用真实客户、邮箱、员工、凭据或生产系统标识，也不要刻意模仿它们。

预期结果应由人独立计算，不要让同一个助手既生成结果又定义正确答案。汇总图要写出预期总数、禁止出现的字段与分类；逐行展示则列出允许出现的记录 ID。还要提前约定，这个虚构场景是否接受人数很少的分组。你们选定的最小分组规模只是实验政策，不是普遍有效的隐私保证。

在批准任何内容之前，准备三个数据变更。第一，新增一条允许向顾问展示的试用记录，确保实时结果确实有合理的更新可展示。第二，新增一条表面上像试用记录、但按政策必须排除的内部记录。第三，把原来某条允许向顾问展示的记录改成不应向顾问展示的分类，同时保持查询文本不变。

这三个挑战分别回答：有没有刷新；新数据进入后，排除边界还在不在；原先适合给顾问看的信息改变状态后，是否仍被展示。不要把它们合并为一个“变化行数”。结果可能很新，却不适合接收人；也可能只是陈旧，看起来没有问题；还可能既更新及时，又正确筛选。实验必须能分辨这三种情况。

在四种源数据状态下比较交付方式

先观察原始数据，再分别施加三种变更。每次变更前都恢复初始状态，避免前一个挑战影响后一个。两种交付方式乘以四种源数据状态，共计八次面向获邀查看者的计划观察。在向审核者展示后续变化前，先记录他们对初始内容的批准决定。

快照组保留最初审核过的结果。预期是内容固定、日期明确，源数据后来发生变化，不应悄悄改写这份已保存的内容。如果你选择的渠道实际上会重新读取源数据，它就不是固定快照，应先改正分类，再做比较。

实时组要记录源数据变更时间、查看者下次打开时间、是否点击刷新，以及新数据真正出现在页面上的时间。观察窗口应在实验前按业务需要确定。如果没有文档说明刷新周期，就不要自行编造：记录本次选定的窗口，窗口内没看到更新时，标为尚未解决，不能判定它永远不会出现。

第一轮比较中，保持已批准查询和可见筛选条件不变。如果产品修改或重新生成了查询或筛选，要单独记录这种变化，不能仍把差异全部归因于源数据。这里主动改变的是交付方式，用源数据状态构成受控挑战。编辑查询应留给后续实验。

确认结果究竟以谁的身份生成

看起来相同的看板，可能通过发布者身份、服务账号，也可能通过查看者自己的身份读取数据。不能凭图表外观推断。先查可用文档和管理控制，再记录日志或测试观察究竟能证明到哪一步。

PostgreSQL 的行安全文档说明了身份为什么关键：策略可以限制行，但表所有者通常不受行安全约束，超级用户和带有 BYPASSRLS 属性的角色会绕过这些策略。如果你自己的技术栈使用 PostgreSQL，就应检查这一类源端边界。这不意味着 Claude 使用 PostgreSQL，也不意味着 Claude 绕过了任何策略。

Looker 的 access_filter 文档则介绍了与用户属性关联的数据限制，并提醒每个需要限制的 Explore 都必须配置。这也是一个具体例子：界面上看到熟悉的筛选标签，不等于受众规则已在所有入口统一执行。

在 Harbor Desk 场景里，发布者应该指出内部记录究竟在哪里被排除：源视图、角色策略、固定的已批准查询，还是展示层筛选。这些控制面对的失败边界并不相同。如果团队找不到执行点，就继续只用合成数据。某张图碰巧没有显示测试标记，不能回答执行身份的问题。

用记录表保留错误，而不是只留下成功截图

每次观察占一行，失败、阻断和功能不可用的尝试都保留。下表是建议使用的实验工具，不是一份已经执行完毕的报告。

“不符合团队政策”指实际发布内容违背了事先写明的受众承诺。它本身不意味着软件违反了产品文档。要同时保留两层判断：“服务按文档工作”和“这个配置不适合我们的接收人”可以同时成立。

把截图和合成结果标识存放在审核者能对照查看的位置，不要把真实查询凭据或连接字符串写进表格。如果为了观察某一步，需要授予超出实验范围的权限，就停止该分支并记录证据缺口，不要为了测起来方便而临时扩大授权。

图表周围的内容也属于发布结果

图中的总数可能完全正确，旁边的提示框、生成解释、下钻详情或下载表格却可能包含不适合给顾问看的信息。检查查看者实际收到的完整内容，而不是只看绘图区。即使图里不显示账号名，一句文字解释点出了虚构内部账号，也要计入观察。

只操作受支持的查看者功能。有可见详情或导出，就检查；没有，就标记不支持，不要猜测未公开接口会怎样返回。范围只限测试产物，这套实验不是探查其他租户或生产数据的理由。

Anthropic 的交互连接器公告介绍了合作应用在对话旁打开、Claude 直接参与操作的能力；实际开放取决于连接器和新版使用体验。这不意味着所有界面共用一个权限边界。如果流程继续进入合作应用，就把目的地记作另一次发布，单独确认接收范围和更新方式。

未获邀查看者的检查要另算：在基线和选定修复完成后，分别确认这个身份能否打开共享内容或受支持的导出链接。这些检查不计入前面的八次获邀查看者观察。否则，一个陌生人被成功拦住，可能掩盖顾问虽然获邀、却看到了不该看的结果。

分清实时更新与缓存中的旧画面

刷新图标不是很强的证据。在合成源数据里加入无害的版本标记，再确认“允许记录新增”有没有带来预期变化。如果这个阳性对照都没到达页面，那么“排除记录新增后没看到它”也证明不了多少筛选效果：查看者可能只是在看旧结果。

BigQuery 的查询结果缓存文档列出了不使用缓存的条件，也介绍了查询作业中的缓存命中信息。如果你自己的实验使用 BigQuery，并能看到这些信息，它们可以帮助排查。但不能据此断言 Claude Data 的缓存时长或刷新架构。

技术栈能提供哪些时间，就分别记录源数据时间、查询执行时间和显示时间。如果只能看到显示时间，也明确写出来。不要把缺少执行时间戳，变成一个看似精确的时效结论。含义不清的观察可以换一个新的查看者会话复查，但原来的尝试不能删掉。

每次变更还应留下恢复记录：原始数据版本、插入或修改的标记、独立计算的预期结果、恢复后的基线。进入下一个状态前确认恢复完成。否则，上一次挑战遗留的内部记录会污染后续观察，后来的修正也可能被错算成另一项控制的效果。

快照也有时效失败。让审核者判断，日期和固定内容的属性是否足够清楚，能否避免拿旧数据做当前决策。这是一项理解检查，不是我们已经测得的改进效果。技术上确实固定的报告，如果日期不显眼，仍可能不是一个好的产品选择。

每次只改一项发布控制，再重跑挑战

如果实时结果不符合受众承诺，就针对实际控制执行点选择一项修复。团队可能把宽泛的数据源换成专用发布视图，在已批准计算中排除某一类数据，缩小接收范围，删除过细的分组，或为这份报告改用审核后的快照。

不要把所有修复一次叠上去，然后声称实验找到了有效控制。只改一项，重跑受影响的挑战，同时重跑允许记录新增的阳性对照。否则，一个阻止了全部更新的改法，很容易被误认为精准保护了敏感信息。

OWASP 的授权指南建议采用最小权限、默认拒绝，并在每次请求时检查权限，静态资源也在范围内。如果你正在搭建自己的发布服务，可以用这些原则指导设计。使用托管产品时，应索取它支持哪些控制的证据，不能声称已经检查过内部执行逻辑。

另外，通过产品支持的共享控制移除获邀查看者，再把“重新打开”与“页面原本已打开”分别记录。已经下载或截取的信息，不能假设会被收回。断开连接器、移除共享、删除下载文件是三种不同操作。团队应描述真正观察到的有限结果，不能用一句“撤销通过”覆盖所有副本。

发布决定不能用平均分掩盖一次越界

按交付方式与源数据状态报告八次计划观察，再单列复查次数。分别统计不符合受众政策、刷新尚未确认、不支持的状态以及符合预期的结果。样本这么少，通过比例只能概括覆盖情况，不能估计生产环境中的信息暴露概率。

实际决定可以分成四种。允许向这组人实时发布：预期更新和排除规则都有效，没有尚未查清的重要输出入口。向这组人发布快照：审核内容适合、时效标记清楚，并接受手工审核的负担。需要缩小发布范围：不论快照还是实时，目前都应先调整数据或接收人。实验未完成：功能访问、刷新或控制证据仍有缺口。

按本文建议的政策，只要出现一项禁止向这组接收人展示的合成细节，就先阻断真实数据上线；重要边界尚未查清，也应如此。这是团队为本次实验选择的保守门禁，不是我们替 Anthropic 宣布的规则。判断时还要一起记录审核耗时：技术上符合要求、却需要持续人工盯守的实时报告，未必带来了预期的运营收益。

最后可能采用混合方式。Harbor Desk 可以实时发布稳定的汇总数据，逐账号更新则审核后注明日期发送，内部支持内容不进入任何一种报告。实验帮助团队划定产品边界，而不是把所有结果硬塞进同一种共享方式。

这套实验仍然回答不了什么

八次观察不能证明系统能抵抗恶意提示、跨租户访问缺陷、罕见竞态、未来产品变化或全部导出路径。合成记录不能证明真实汇总已经匿名。最小分组规模也不能阻止所有推断，而批准一条查询，更不是对数据处理或披露作出的法律判断。

Claude 本次发布的综合说明介绍了组织控制、连接器限制与 Enterprise 隔离。这些是厂商说明，不是本实验的执行结果。这里验证的是既定工作流下，发布内容是否适合接收人；安全审查和供应商评估仍然需要分别完成。

查询定义、源数据结构、执行身份、分类规则、接收人组、合作应用目的地或产品行为发生变化时，都应重跑相关观察。保留旧决定，让团队知道哪些原有假设已经不再成立。另一个账号测试成功，可以作为参考，但不能代替你这份发布内容自己的证据。

今天就能改的一件小事是：批准实时看板之前，先准备一条允许向顾问展示的未来记录、一条必须排除的未来记录，以及一条重新分类的记录。如果团队说不清刷新之后每项结果应该给谁看，那么批准的只是眼前这张图，实际发出去的却是一份持续更新的数据报告。

参考来源

1. Anthropic：Introducing Claude Whiteboards, Claude Sheets, and Claude Data，2026 年 11 月 10 日。
2. Anthropic：More ways to work with Claude，2026 年 11 月 10 日。
3. Anthropic：Your apps can now open in Claude，2026 年 11 月 10 日。
4. Google Cloud：BigQuery 授权视图。
5. Google Cloud：使用缓存的查询结果。
6. Google Cloud：Looker access_filter。
7. PostgreSQL：行安全策略。
8. OWASP：授权检查指南。