你准备把一份带客户信息的文档丢给模型处理，忽然卡住：这段提示词会经过谁的手、存在哪、多久删、能不能删掉？官方文档说得含糊，中转站更是问不出所以然。这篇不给你安慰话，而是把链路拆成几段，每段给一组能直接照问的问题和一张脱敏检查清单，让你在发出去之前先做判断。
你准备把一份带客户信息的文档丢给模型处理，忽然卡住：这段提示词会经过谁的手、存在哪、多久删、能不能删掉？官方文档说得含糊，中转站更是问不出所以然。这篇不给你安慰话，而是把链路拆成几段，每段给一组能直接照问的问题和一张脱敏检查清单，让你在发出去之前先做判断。
核心思路很简单：不要问「这个站安全吗」这种没有答案的问题，而是沿链路逐段问「谁可能看到、留多久、能不能删」。把这三问问清楚，你对数据边界的判断就不再靠感觉，而是靠一份能对得上号的清单。
先想清楚：为什么「发出去」之后你就不再是唯一的知情人
一段提示词的旅程至少经过你的机器、网络与服务端、模型提供方、可能的中转层，以及被调用的工具。每一段都是一个可能落盘的点，任何一个环节留痕，你对这段内容的控制权就少一分。这不是危言耸听，而是链路的基本事实。
- 你的机器：聊天记录、插件缓存、IDE 历史、剪贴板、临时文件，很多「隐私事故」其实发生在自己电脑上
- 传输环节：TLS 只能防中途窃听，不能约束接收方拿到之后怎么处理
- 服务与工具：网关日志、计费记录、异常采样、内容审核队列，往往比对话本身留存更久
- 模型侧：是否用于训练、是否人工抽检、是否做缓存复用，这三件事要分开问，不能混为一谈
风险不只是泄露，也包括合规举证。出事时你要能说清当时发了什么、发给谁、对方怎么答复，说不清本身就是问题。判断标准是：先按「这段内容泄露会不会造成实质损失」排序，再决定发不发，而不是先图方便。完全不适用的情况是：内容本身公开、无个人标识、无商业敏感信息，那就直接发，不必为此拖慢流程。
链路分段图：从你按下回车到日志落盘，一共几个可能留痕的点
| 链路分段 | 可能留痕的东西 | 要问的问题 |
|---|---|---|
| 客户端侧 | 聊天记录、插件缓存、IDE 历史、临时文件 | 本地有没有自动保存，保存位置在哪，能不能关 |
| 传输侧 | 链路元数据，接收方各自的入口日志 | 传输过程是否加密，接收方是否记录来源 |
| 服务侧 | 网关日志、计费记录、异常采样、审核队列 | 请求正文是否落盘，保存多久，谁能看 |
| 工具与下游 | 被调用工具的入参与返回 | 传给第三方的内容是什么，对方怎么留存 |
| 模型侧 | 是否训练、是否抽检、是否缓存复用 | 这三件事分别的开关和默认值是什么 |
这张表不是为了吓人，而是给你一个对账的框架。你每换一个站点或工具，就把这张表重新填一遍，填不出来的格子就是你要去问的问题。客户端侧那几个点最容易被忽略，也最容易自己动手解决。
三级分类：可直接发 / 脱敏后可发 / 一律不发
与其每次纠结，不如提前把要发的内容分成三级，形成肌肉记忆。分级的标准是「泄露后的实质损失」，不是「内容看起来敏不敏感」。下面这张对照表可以直接贴进团队文档。
| 级别 | 典型内容 | 处理方式 |
|---|---|---|
| 可直接发 | 公开资料、自己写的通用代码片段、已对外发布的文案、纯技术问题 | 直接发，不必额外处理 |
| 脱敏后可发 | 含姓名、联系方式、订单号、内部代号、未公开但不敏感的业务描述 | 替换或删除标识字段后再发 |
| 一律不发 | 完整身份证件、密钥与口令、未公开的财务与法务材料、他人隐私数据、受合同约束的客户数据 | 不要发，改用本地手段或换可控路径 |
边界规则是：拿不准时默认降一级。降级的成本是几分钟的替换，降错方向的成本可能是一次事故。什么时候不适用这套分级？当内容完全公开且不涉及任何第三方权益时，直接发，别为了流程而流程。
脱敏检查清单：发送前 60 秒过一遍
- 替换类：人名换占位符、公司名换代号、金额改成相对比例、日期改成偏移量，保持逻辑可读但不可反推
- 删除类：密钥、手机号、邮箱、身份证号、内网地址、工单号、cookie 与 token，一个都别留
- 结构类：把长文档切成只包含必要段落的片段，别整份贴上去，减少连带暴露
- 验证类：发完先回看一遍自己发出去的内容，很多人是在这一步才发现漏了东西
- 兜底类：拿不准的字段，宁可删掉再补一句说明，也别抱着「应该没事」的心态发出去
- 先列字段把你打算发的整段内容拆成字段或段落，逐个标上「公开 / 内部 / 敏感」。
- 再剔敏感敏感字段直接删掉或换成占位符，确认替换后不影响模型理解你的意图。
- 后看结构只保留必要段落，把无关上下文砍掉，减少一次性暴露的信息量。
- 最后回看发送前再扫一遍，确认没有漏掉的标识字段；有条件的话让同事帮你复核一次。
怎么问出留存口径：官方与中转的提问模板
官方侧和中转侧要问的东西不一样。官方直连通常有公开条款，你要问的是四件事：是否用于训练、默认留存多久、能否关闭留存、删除请求走什么入口。这些口径各家整理不完全一样，去 /official-api 核对当时的说明更稳妥。
中转侧要多问一层，因为链路更长。别问「你们安全吗」这种没法回答的问题，直接问：我的请求正文会不会被写入日志、保留多少天、谁有权限看、是否转发给第三方、有没有脱敏或审计策略。对方肯不肯把这些落到书面，本身就是重要信号。
- 是否用于训练
- 区分「用于改进服务」和「用于训练」，两者不是一回事，要对方明确回答
- 默认留存期
- 问默认值，不是问「能不能设置」，默认值才是大多数请求的真实状态
- 删除入口
- 问清楚具体入口和响应时间，只给邮箱不算完整答案
- 访问权限
- 问谁能看到正文，是自动化系统还是人工，人工在什么条件下介入
什么情况下这套提问方式不适用？当对方只肯口头承诺、不肯落到条款或书面答复里，就别再纠结措辞了，直接把这类内容按「一律不发」处理。敏感数据的安全边际，取决于对方愿意承担多少书面责任。
日志与留证：把「说过什么」变成可追溯的记录
审计的另一半是自己留痕。你不需要保存所有原文，但要留一份最小化的发送记录：时间、目标站点、用途、内容分级。这样出事时你能回答「当时发了什么级别的内容给谁」，而不是靠回忆。
- 停止发送发现异常后第一时间停止继续发送，避免扩大暴露面。
- 保留现场保留当时的请求与回复、报错信息、页面截图，别急着清缓存。
- 导出日志把关键日志导出到本地，核对用量记录与请求时间线是否对得上。
- 书面沟通把问题和对方的答复固定在可保存的渠道里，聊天截图不如邮件或工单记录有效。
字段设计可以尽量简单，能回溯就够。用量与日志的常见写法可以在 /usage 找到参考，关键不是字段多，而是每一笔都能对得上人、时间、用途。
什么情况下这套判断要改：中转与官方的差别
官方直连通常有公开条款和明确的删除入口，责任主体清楚，代价是价格与接入门槛。中转多一层，链路更长，留存口径更依赖对方自觉，所以提问要更细、复核要更勤。这不是说中转不能用，而是说你要按数据敏感度选路径。
- 公开内容与低敏感任务：哪条路方便走哪条，重点还是别把敏感字段顺手带进去
- 内部但非核心的数据：优先选条款透明、愿意书面答复留存的路径
- 客户数据与受约束数据：按「一律不发」处理，除非能确认对方不落盘且有书面依据
- 已脱敏但仍可反推的内容：当作次一级敏感处理，别因为「已经脱敏了」就放松
自建或私有部署能减少外部留存，但要自己承担运维与安全责任，不是无风险。做选择时可以对照 /sites 与 /safety 的整理，再按自己的数据敏感度定档。价格和评测这类会变的数字，到 /price-watch、/rankings 与 /tools/speed-test 看当时的呈现，别用旧印象做决定。
把它变成习惯：一次审计之后怎么维持
一次审计做完不算完，关键是让它变成日常动作。把三级分类写进团队规范，附一个脱敏示例，新人照着做就行。换站点、换模型、对方更新条款，都要重新问一遍留存问题，因为口径是会变的。
- 规范落地：把三级分类和脱敏清单放进团队文档，附一个改前改后的示例
- 定期复核：按季度或按变更触发，重问一次留存与删除入口
- 留证习惯：每类任务固定记录时间、站点、用途、分级，不存原文
- 异常处置：按 /safety 的清单执行并记录结果，方便复盘
- 不适用场景：一次性、低敏感度的临时任务不必上全套流程，避免规范被整体绕过
常见问题
提示词到底会不会被存下来？
取决于你走的路。多数服务默认会为排障、计费或安全目的保留一段时间，是否用于训练、能否关闭、留存多久各家口径不同。别猜，直接按文中的提问模板去问，并把答复保留下来；答不清楚的就当成会长期保存来处理。
脱敏到什么程度算够？
标准是「拿掉标识后无法反推到具体个人或具体交易」。姓名、联系方式、账号、订单号、内网地址必须处理；金额和日期可以改成比例与偏移量。如果脱敏后内容已经没法完成你的任务，说明这类数据本来就不该走外部接口。
中转站和官方直连，哪个更安全？
不能一概而论。官方通常有公开条款和明确的责任主体，中转多一层链路，透明度更依赖对方。判断方法不是看名头，而是看谁愿意把留存、权限、删除入口说清楚并落到书面。说不清的那一方，按更严的等级对待。
删除请求一般怎么提？
先确认对方有没有公开的删除入口或联系方式，再用可保存的渠道提交，写清时间范围与标识。提交后留一份回执，隔一段时间跟进确认。没有入口、只能靠聊天口头答应的，直接视为无法删除。
团队里怎么落地这套流程？
把三级分类和脱敏清单写成半页纸的规范，贴在发请求的地方；新站点或新模型上线前走一次提问模板；每季度复核一次条款变化。规范越短越容易被执行，长了就没人看了。
