提示日志（Prompt Logs）正在成为一场“迟早会发生”的泄露

提示日志看起来无害，直到你读到它们。

从工程角度来看，记录提示（prompts）很诱人。它有助于调试失败。它有助于复现用户的抱怨。它有助于监控滥用。它有助于改进提示。它还有助于回答那个永恒的问题：“为什么模型会把产品做成像闹鬼的烤面包机一样？”

从隐私角度来看，提示日志是原始意图。它们可能包含客户姓名、活动创意、个人幻想、医疗背景、法律纠纷、产品策略、真实人物的姓名、地点，以及与上传图片相关联的指令。在图像生成中，提示词往往会解释敏感部分，而最终图像只会隐约暗示。

因此，提示日志的泄露可能比输出结果的泄露更糟。输出结果可能含糊不清。提示词通常非常明确。它们展示了用户要什么、他们试图隐藏什么、他们想要改变什么、以及他们在接受可用版本之前尝试过什么。

这也是为什么“我们只记录文本”并不能让人安心。文本可能就是通往图像的地图。一条提示说“从尚未发布的包装效果图中移除竞争对手的标志”，即使没有图像文件泄露，也具有商业敏感性。一条提示说“让我的头像看起来没那么疲惫”，即使从未保存输出结果，也仍然是个人信息。

更安全的做法是把“操作性调试”与“内容保留”分离开来。记录作业 ID、时间信息、模型版本、错误代码、token 或额度使用情况、队列事件，以及不含内容的元数据。当确实需要捕获内容用于滥用或支持时，应当把范围缩小、获得授权、设置时间限制，并在政策中明确可见。

开发者可能会反对说，这会让调试更困难。确实会。隐私往往会让“偷懒式调试”变得更难。这并不是悲剧；这是设计约束。应当为边缘情况建立明确获得用户同意的诊断采集，而不是永远保存每个人的私人提示历史。

安全团队应该像对待敏感客户数据一样对提示日志进行威胁建模。谁可以查询它们？它们会被复制到分析系统中吗？是否会被包含在崩溃报告里？是否会发送给可观测性（observability）供应商？是否会被支持团队检索？保留时间是否比图像本身更长？

如果提示能够重建私人的工作内容，那么它们就不是无害的日志。它们是正在等待日历邀请的泄露材料。

延伸阅读：提示历史是产品数据——不管你怎么称呼它，支持“零提示历史”的理由，以及一个 AI 图像 API 永远不应该存储什么。