把 AI 对话分享给同事，为什么陌生人也能找到？
想象一个很普通的工作场景。
你让 AI 整理会议记录。它读了内部文档，归纳出项目进度、客户诉求和下一轮报价的考虑。结果很好，你顺手说了一句：“发给项目组看看。”
几秒后，AI 给你一条链接，说已经完成。
这条链接究竟只允许项目组成员打开，还是任何拿到链接的人都能打开？它分享的是当前这段摘要，还是整段对话？如果你后来撤回权限，已经生成的副本会一起失效吗？
这些问题，在“分享成功”的提示里，往往没有答案。
上面是一个说明性的假设。但最近关于 AI 对话分享的研究，让这个日常动作值得重新想一遍：我们口中的“发给同事”，和产品实际完成的“创建一个公开链接”，可能相差很远。
发给谁，是交付结果的一部分。
2026 年 10 月 18 日，Claroc 发布关于 Meta Muse 分享功能的研究。研究者报告称，部分分享地址把可读的对话标题放进了域名；通过被动 DNS 数据，他们发现了 6800 多个分享主机名，并打开查看了其中几百个页面。这些是经分享功能生成的页面，不能理解为所有私人聊天都能被直接搜索出来，也不能把主机名数量当成受影响人数。
10 月 20 日的更新援引了 Meta 向 Ars Technica 提供的暂停分享功能回应；研究者复查的 40 条旧分享链接当时均已无法打开，但历史 DNS 数据仍可能保留标题。报告没有提供滥用证据，也不能据此判断每位分享者原本希望谁来看。
这里有两件容易混在一起的事：页面允许谁访问，以及别人能不能发现它的地址。
一个分享页面如果允许任何持有链接的人访问，随机地址确实可以提高被猜中的难度。在一些低风险用途里，这种方式方便而且合理。问题在于，地址还可能经转发、日志、浏览器记录或其他渠道流动。“不好猜”只覆盖其中一种发现路径。
本次研究涉及的标题进入了主机名。即使页面后来关闭，标题也可能在其他记录中留下线索。标题如果包含客户名称、内部项目或谈判对象，单凭标题就可能透露有价值的信息。
搜索引擎规则也解决不了全部问题。Google 的官方说明明确区分了限制抓取与限制访问：robots.txt 主要用于管理爬虫，不能充当保护私有内容的访问控制。
因此，“不出现在普通搜索结果里”和“只有指定同事能打开”，需要由不同的机制实现。企业要求后者，就应当校验访问者的身份和当前权限，而不能只期待地址一直留在小范围内。
原文件的权限，不一定会跟着 AI 生成的内容一起走。
很多人对企业资料的安全感，来自原来的文档系统。
会议记录在公司网盘里，只有项目组能看；离职后账号会失效；负责人也能随时撤销成员。这套权限是具体系统在访问时执行的。
当 AI 读完记录，生成一份摘要，再把摘要存到另一个服务里，新的对象就出现了。原系统能够阻止外部人员打开会议记录，却未必知道外面已经多了一份包含关键结论的摘要。
我们习惯把摘要理解成“原文的简化版”，很容易低估它的敏感程度。可对于商业信息来说，删掉细节并不总是降低价值。
一份很长的谈判记录，真正敏感的可能只有三句话：客户愿意接受的价格、我们能让步的底线，以及对方急着在什么日期前成交。AI 恰好擅长把这些内容提取出来。
有时，部分源材料本来就是公开的，组合后的结论却暴露了内部关系。公开新闻、人员日程和一段内部讨论放在一起，可能让人推断出尚未宣布的合作。判断能否传播，需要考虑这份新内容本身。
这也让“只读接入”有了一个容易被忽视的边界。AI 没有修改原文档，只说明它没有对那个来源执行写入。一旦它把内容发到邮件、聊天群或公开分享页，整次任务已经产生了新的外部结果。
企业需要关心的不只是源文件有没有被改动，还包括内容被带到了哪里，由哪个系统接着管理。
“分享”应当被当作一个完整的业务动作。
在人与人协作时，“发给项目组”看似足够明确，因为大家通常知道用哪个工作群、谁在群里、什么内容不能转发。
AI 面对的选项可能更多。它可以发邮件、贴到聊天频道、创建网盘文件，也可以调用一个最方便的分享接口。每条路径都可能成功返回，却产生不同的可见范围和保存期限。
如果工具只告诉它“这个接口可以创建分享链接”，却没有明确链接的访问模式，模型就可能把“生成了可打开的地址”当成“指定的人已经安全收到”。语言上接近，业务结果并不相同。
产品应当把这种差别表达清楚：分享什么内容，以什么形式交付，哪些人可以访问，权限何时失效。这些信息不应藏在模型必须自行猜测的实现细节里。
低风险的日常协作，可以预设合适的默认值。例如，同一项目空间内生成摘要，继承已有成员范围，并设置符合组织要求的保留期限。只要仍在明确委托内，系统就可以自动完成，无须每次让人重新点一遍同意。
需要停下来确认的，通常是范围发生变化的地方：从项目成员扩展到任何持有链接的人，从内部空间转到外部服务，或者把原本仅供参考的内容变成对外正式材料。
这时，确认页面应当让人看到真正的变化。“是否分享”太宽泛；“将这份含报价信息的摘要创建为任何持有链接者可访问的页面，有效七天”，才足以支持一个具体决定。
如果组织不允许这种传播方式，系统应当直接拒绝。不能因为模型给出了充分的解释，或者用户随口说了“方便点就好”，原来的组织限制就自动失效。
撤回能做什么，也需要说清楚。
一条链接背后，可能同时存在几种东西：原文件、生成的摘要、分享页面、访问权限，以及曾被其他系统记录的标题。
关闭分享页面，可以阻止后续通过这个页面读取内容；撤销成员权限，可以让相应账号失去访问资格。这些措施很有价值，应当尽快执行。
但它们不能自动证明，别人没有下载文件、复制正文、转发截图，或者把标题记进另一个系统。已经分发出去的内容，有些能继续管理，有些只能通过接收方配合处理，还有些根本无法确认去向。
所以，“撤回成功”的回执应当说明究竟撤回了什么。比如，原分享地址已失效、当前成员访问已撤销；对于历史下载或外部记录，未能确认删除。
这会比一句“资料已彻底清除”更有用。负责人需要据此判断后续是否要通知接收方、调整材料，或者启动进一步处理。
分享前也应当考虑这个差别。需要随人员变化持续收回访问权的资料，适合放在能持续校验身份的受控位置；把完整文件直接送到对方设备上，意味着对后续副本的控制会变弱。便利性和控制范围之间，应当有明确选择。
AI 不能只负责把内容发出去，还应当交代它实际完成了什么。
回到开头：“发给项目组看看。”
一个可靠的执行链，需要把“项目组”对应到当前可信的成员或受控空间，而不是仅凭模型生成一个看起来正确的群名。成员范围变动后，谁还能访问，要由持有当前成员与权限信息的服务判断。
如果分享接口只能创建公开链接，AI 就应当说明能力差距，寻找允许的交付方式，或者把选择交回有权决定的人。不能用一个方便的接口，悄悄改写任务的受众。
完成后，它也应该报告可以核实的结果：材料放在哪个受控空间，采用哪种访问模式，有效期是什么，以及哪些条件未能确认。
接口返回成功，能够证明接口接收了请求；指定同事此刻能否访问、无关账号是否被排除，仍要看相关服务实际执行的权限。这两层证据不能混为一谈。
这种交付要求也会反过来改善产品设计。如果一个接口从来不返回访问模式，调用方就很难解释结果；如果所有分享都被包装成同一个动作，负责人就难以设置不同规则。模型之外的接口、默认设置和执行校验，同样决定最终行为。
把责任全部推给员工“不要随便点分享”，无法解决这些设计问题。员工、AI 产品、接入方和业务系统各自掌握不同的控制点，应当在自己的环节把范围表达清楚，并让下一环节能够核对。
这也是我们讨论 A2B 时，特别关心的一类变化。
AI 进入企业，不只是在更多资料上回答问题。它开始代表组织读取、整理和传播信息。一份回答是否正确，与这份回答能否被发送给某个人，是需要分别判断的两件事。
沿着这个思路，读取来源、生成材料、对外分享，应当成为能分别识别和约束的动作。组织可以允许读取，同时限制外发；可以允许给项目组交付，同时禁止创建公开链接。需要扩大范围时，再进入对应的决定流程。
ACC 用来声明能力及其风险、身份和审批意图等治理语义；BailingHub 作为开源中枢，把这些声明与可信的调用上下文、执行控制和回执衔接起来。具体文件或分享服务，仍需在执行时完成自己的权限检查。规范和中枢不能代替接收系统的访问控制，也不能追回已经流向外部的所有副本。
对企业来说，可以从一个很小的检查开始：准备一份不含真实敏感信息的测试材料，让 AI 按日常方式“发给项目组”，再分别用成员账号、无关账号检查访问，最后撤回分享。看它能否解释访问范围、给出实际结果，并在无法控制的部分明确说明限制。
这比只问“我们的 AI 支不支持分享”，更接近真正的使用问题。
当我们对 AI 说“发给项目组”，期待得到的应当是：指定的人，在指定范围内，拿到了指定的内容。那条链接只是实现这件事的一种方式。
