生成式 AI 应用怎样记录提示词版本与输出关联

生成式 AI 应用一旦改过系统提示词、工具定义或输出格式，单看最终答案就很难解释“这次结果到底来自哪套规则”。实用做法是把提示词当成不可变版本，把每次模型调用当成一条事件：事件保存 prompt_version 和 request_id，输出再用同一个 request_id 回指。原始用户内容不必复制进普通日志，改用脱敏摘要、指纹或受控存储引用。

先固定提示词版本，再记录每次请求

版本不是简单的 v1、v2 标签。一次可复现的提示词包至少包括模板正文、变量规则、工具 schema、输出格式约束和模型参数默认值。任何一项改变，都应生成新的版本标识；同一版本的内容发布后不要原地覆盖。

可以用内容哈希加人工别名组合成版本键，例如 support-reply-2026-11-a1c9。别名方便排查，哈希用于发现“文件名没变但内容变了”。图中的分叉关系表达的是：一版提示词可以产生多次请求，但一条请求只应指向一个确定版本。

请求事件应该记录哪些字段

在调用模型前生成 request_id，把它贯穿重试、流式片段和最终落库。下面是应用层事件的最小形状，字段名可以按自己的日志系统调整：

{
  "request_id": "req_01J...",
  "prompt_version": "support-reply-2026-11-a1c9",
  "model": "provider-model-name",
  "input_fingerprint": "sha256:...",
  "parameters": {"temperature": 0.2},
  "status": "completed",
  "output_ref": "out_01J..."
}

严格 JSON 不适合插入注释，因此字段含义直接说明：input_fingerprint 只用于判断输入是否变化，不代表可以从哈希还原原文；output_ref 是输出表或受控对象存储的引用；status 应区分成功、超时、被拒绝和重试中。模型名、参数摘要和时间戳用于解释差异，但不要把完整业务输入塞进每条普通日志。

输出关联要能追溯，但日志不能复制敏感数据

输出事件可用同一个 request_id 关联，并补充首字节时间、总耗时、输入输出 token 统计和错误分类。对于流式响应，先写“开始”事件，再写片段计数或最终结果引用；不要为每个片段复制完整提示词。

用一次回放检查版本切换和重试边界

上线前不必追求“日志看起来很全”，先拿一条脱敏样例检查四件事：版本号能否定位到不可变配置；重试是否生成新的 request_id 但保留父请求引用；失败请求是否有明确状态；查询输出时是否无需读取普通日志里的原始敏感内容。

如果采用供应商提供的可版本化 Prompt 或会话对象，也应在自己的事件中保存稳定的版本引用。官方文档中的对象生命周期和字段会变化，应用层的 prompt_version、request_id、output_ref 仍应由自己定义，避免把排查能力绑定到某一家 API 的响应格式。

常见问题

提示词正文需要每次都写入日志吗？

不需要。生产日志通常保留版本键和内容哈希；正文放在受控配置仓库或加密存储，并按权限查询。

重试要不要复用原来的 request_id？

建议为每次实际调用生成新的请求 ID，再用 parent_request_id 表示它们属于同一次业务尝试，便于区分耗时、模型返回和失败原因。

只保存输入哈希能复现模型输出吗？

不能。哈希只能证明输入是否相同；若需要回放，还要按策略保存脱敏输入、版本配置、模型标识和关键参数。

输出关联和合规留存是一回事吗？

不是。关联键解决可追踪性，留存期限、访问权限和原文处理仍需由业务的隐私与合规策略决定。