一张截图就能摧毁 AI 产品信任

信任常常死于一张截图。

这不是漏洞报告。不是监管机构的来函。也不是那种排版精美、在文末用“learnings（经验教训）”救火的事后复盘。仅仅是一张截图：展示了管理后台里的私人提示词、支持讨论里的客户图片、共享画廊中的生成结果，或是“已删除”但仍可通过 URL 访问的文件。

截图之所以有力量，是因为它把整个隐私承诺压缩成一个一眼可见的矛盾。你说内容是私密的。它就在这里。你说它被删除了。它也在这里。你说支持人员看不到它。它就在这里，像是按时交租一样出现在仪表盘里。

AI 图片产品尤其容易被截图。因为内容是视觉的。证据也是视觉的。用户不需要理解抓包或数据库取证。他们只要指着屏幕说：“为什么我的图片会在那里？”这是一句非常短的话，但影响范围却极其巨大。

风险面通常都很普通：管理后台。客户支持工具。错误追踪器。分析事件。附在错误报告里的浏览器截图。Slack 预览。CDN URL。对象存储控制台。QA 文件夹。内部画廊。产品团队可能不会把这些当作“AI 图片系统”，但组织架构并不能让用户安心。

要想在设计上建立信任，就要减少“可能存在一张致命截图”的位置数量。如果支持不需要图片预览，就不要构建它们。如果错误日志不需要原始提示词，就把它们移除。如果交付后生成结果不需要保存，就不要为了“未来的产品想法”而保留。未来的产品想法，往往就是把隐私承诺变成闹鬼的家具。

当确实需要内容可见时，要让它是有意图、可审计的。有时产品确实需要用户可控的历史记录。有时企业采购方为了合规需要保留。有时安全审查会带来法律义务。可以。就这么说。把它写进产品模型里。不要因为调试方便而无意间创建了同样的东西，然后再假装截图是不公平的。

最强的信任姿态是架构层面的：即使有人想要截图，产品也无法生成它——因为内容已经消失，或从未在那个系统中可用。这比“政策上说员工不应查看”要好。政策当然重要，但“按钮根本不存在”有一种直截了当的优雅。

对于 Unexposed，我们希望用“与内容无关的运营记录”这种语言来避免掉进这个陷阱。服务仍然需要知道工作确实发生了。但它不应该需要保留客户的提示词、源图片、输出结果，或是某个能让仪表盘轻松暴露它们的密钥。

如果你想测试自己的 AI 图片功能，不要从模型开始。先从这个问题开始：什么截图会让我们看起来像是在撒谎？

然后，把屏幕移除。

延伸阅读：Unexposed 数据存储、不保留提示词的私密图片生成，以及如何评估私密的 AI 图片工具。