AI助手看不到什么，以及为什么这是硬性限制

任何添加AI功能的软件都应该给用户一个明确的答复：模型究竟能看到什么。

对大多数应用来说，诚实的回答是“看到很多”。因为内容以可读形式保存在服务器上，将数据发送给模型只是一项配置修改，而不是复杂的工程项目。

我们的情况有所不同，而这与克制无关。

硬性限制

问题、回答、消息和通话都在设备端使用本地生成的密钥进行加密，该密钥绝不会发送到我们的服务器。

这意味着，即使我们决定这么做，也无法将情侣之间的对话发送给模型。我们没有保存任何可读形式的数据。没有任何人能读取它，包括我们自己，也包括未来可能改变想法的我们。

这就是政策与约束的区别。政策只是一句承诺。约束则是当有人试图违反时所面临的物理阻碍。

我们不是在承诺不把你的对话发送给模型。我们是在告诉你，我们根本就没有这些对话。

可选功能能看到什么

仅限于你在提交那一刻，为了特定目的而明确提交的文本。

那是一个明确且可见的操作。你选择一段文本，并要求对它进行处理。后台不会收集任何内容，任何你未主动提交的信息都不会被包含在内。

如果你从不使用这些功能，你的任何数据都不会接触到模型。

为什么我们没有开发更多功能

有一个显而易见的产品方案摆在面前，但我们没有采用，有必要解释一下原因。

如果这个软件能读取所有内容，它可以做到很多事：发现数月来的规律，指出你们其中一人已经十一次提到同一个顾虑，总结这一年的历程，或者根据你们一直在规避的话题给出沟通建议。

其中一些功能确实很有价值。但所有这些功能，都建立在一家公司保存着两人之间最私密事务的可读记录这一前提之上。

我们认为这种妥协不可接受。我们在开发早期就做出了这一决定，因此系统架构直接强制执行这一点，而不依赖于我们是否继续保持共识。

模型训练

我们不会使用用户内容来训练模型。从根本上说我们也无法做到，因为我们手头没有这些数据。

对于可选功能，提交的文本仅用于生成结果，不会用于任何训练。在涉及第三方模型提供商的情况下，这是合同约束事项，我们也严格按此处理：协议明确排除了对提交内容进行训练的可能性。

我们更愿意强调架构而非合同，因为架构不需要依赖任何人恪守承诺。

这给产品带来了什么代价

真实的代价。

跨对话没有记忆。没有功能能注意到你在三月份说过类似的话。

我们服务端无法对你的历史记录进行搜索。

无法根据你们两人实际撰写的内容给出主动建议，而这恰恰是用户最常要求的功能。

这些功能不在路线图上。它们根本无法实现，而这正是重点所在。

如何评估任何声称保护隐私的软件

询问模型能看到什么。询问这一答案是由架构强制保证的，还是仅仅靠政策约束。再询问这家公司需要重构什么才能改变这一答案。

如果对最后一个问题的回答是“不需要重构，更新一份文档即可”，那么你就明白是怎么回事了。