AIGoCode 会保存 Prompt 吗：发送代码前先分清三类记录

发送代码前，先把三类记录分开

准备把一段代码、错误上下文或业务样本交给 AIGoCode 时，只问“会不会保存 Prompt”还不够。更实用的判断方式，是分别确认请求内容的处理、账户与用量记录、主动提交的客服材料。

AIGoCode 隐私政策说明：默认不把完整 prompt、completion、代码片段或生成内容作为长期业务记录保存；同时，为完成请求、提供模型能力、防止滥用、排查错误或履行法律义务，相关内容可能经过传输、处理、短期缓存或第三方 AI/API 服务的临时处理。阅读这两部分时，需要同时保留这些条件。

下面的清单用于决定一次具体请求该放哪些材料。它不替代你所在团队的数据规则，也不把隐私政策扩展为某种企业数据保护承诺。

一、请求正文：缩小到能解决问题的最小片段

假设你要排查一个订单金额计算函数。原始材料可能同时包含计算逻辑、客户姓名、邮箱、真实订单号和生产凭据。建议先把问题缩成函数、输入结构和虚构样本，再确认是否确实需要更多上下文。

可以按下面的顺序准备：

1. 说明任务，例如“解释为什么折扣后金额出现负数”，而不是直接上传整套业务资料。
2. 保留影响判断的结构、分支和类型，用虚构值替换真实客户信息。
3. 删除与问题无关的文件、注释、历史对话和输出，避免顺手带入额外材料。
4. 检查自己是否有权将这段代码或数据交给外部服务处理；权限不明确时先向资料负责人确认。

这些是发送前的人工整理建议。隐私政策并未承诺自动帮你识别或移除所有敏感内容，不能用默认不长期保存完整正文来代替这一步。

二、账户和用量：请求内容之外仍有业务记录

隐私政策列出的“使用与额度元数据”包括功能或模型选择、API Key 标识、请求时间、请求状态、额度消耗、积分变动、订阅权益、限流状态、错误码和服务质量指标。账户、订单、条款同意以及风控和安全日志也在政策说明的数据范围内。

因此，判断资料能否发送时，可以把问题拆成两栏：

政策对不同记录给出的是按合理必要期限保留的原则，并说明账户、订单、发票、条款同意、退款、风控和安全日志可能适用不同期限。不要自行推算一个统一的“几小时后全部删除”或“固定保留多少天”。

三、客服材料：主动提交前再审一遍

一次 API 请求与一次工单附件，是两个需要分别判断的提交动作。政策明确说明：用户主动提交到客服、邮件、工单或反馈渠道的 prompt、completion、截图、文件或请求示例，可以用于支持、排障、风控、争议处理和服务改进。

例如，你先用虚构订单复现错误，随后为了说明问题又上传了完整生产日志。第二次提交扩大了材料范围，应当重新检查，而不是认为前面的请求准备已经覆盖附件。

建议为客服单独准备一份副本：保留必要的错误现象和最小复现，检查截图边缘、请求头、路径、文件名和历史输出，把无关的真实数据去掉。具体日志整理步骤可以继续阅读API 排错日志脱敏流程；凭据本身的保管与泄露处置另见API Key 本地保存指南。

四、第三方处理与数据请求也要单独确认

隐私政策说明，请求需要借助模型、推理、代码处理、代理能力或第三方集成功能完成时，必要信息可能与 AI/API 服务提供商共享。政策还提示第三方服务的隐私做法由其自身政策约束，并说明为提供服务所必要的跨境处理。

如果项目要求特定的数据处理地区、第三方范围或保留期限，建议在发送真实资料前逐项确认。公开政策中的原则描述不能直接当成已经满足这些项目要求的证明。

政策同时说明，依适用法律，用户可能享有访问、更正、删除、导出或限制处理部分个人信息的权利；相关请求可能需要身份验证，也存在法律或安全调查等保留例外。需要确认具体记录时，可以通过政策中的 support@aigocode.com 或客服入口说明请求范围，不宜自行承诺提交后会立即清除所有关联记录。

一次请求的发送前清单

• 这次问题已经缩成最小必要材料，真实样本能替换的已替换。
• 已区分请求正文、账户与调用元数据、客服附件三个范围。
• 对需要保密的代码和数据，已确认外部处理权限。
• 对第三方、跨境处理和保留期限有明确要求的，已先核对适用条件。
• 如果还要发工单，已经单独检查附件，而不是直接转发全部上下文。

完成这份清单后，再按官网当前产品页面与文档选择适用的接入方式。本文对数据处理范围的说明依据上述隐私政策；政策更新后，应以原页面最新内容重新核对。