写作API任务记录：按请求条件整理日志与排错信息

写作API出现输出不完整、响应超时或结果难以复现时，应先检查请求内容和任务状态，不要仅凭报错判断原因。记录要能说明当时提交了什么、系统返回了什么，以及之后如何处理。不同服务的接口字段和日志能力并不相同，以下是自有系统可采用的整理方法，不是通用参数清单。 每次任务可记录内部任务编号、提交时间、调用环节和输入内容摘要。摘要可用于辨认任务，不一定要保存完整原文；

写作API出现输出不完整、响应超时或结果难以复现时，应先检查请求内容和任务状态，不要仅凭报错判断原因。记录要能说明当时提交了什么、系统返回了什么，以及之后如何处理。不同服务的接口字段和日志能力并不相同，以下是自有系统可采用的整理方法，不是通用参数清单。

每次任务可记录内部任务编号、提交时间、调用环节和输入内容摘要。摘要可用于辨认任务，不一定要保存完整原文；如确需保留，应按业务需要限制访问权限和保存范围。还可记录实际发送的请求配置，例如所选模型标识、输入格式和应用设置。模型名称或配置变化时，应分别记录，避免把不同条件下的结果当成同一次测试。

响应侧可记录服务返回的状态信息、可见错误内容、响应是否完整，以及本地处理结果，例如解析或入库是否成功。如果系统提供请求标识或用量信息，也可一并保存；没有提供的字段不要自行补造。密钥、认证头和含密钥的完整请求不能写入网页、正文或普通日志，应保存在服务端或受保护的本机配置中。展示日志前，也要检查其中是否泄露密钥。

排查时，先用任务编号查找已有响应和入库状态，再判断是否需要重试。超时不能直接证明请求未处理或未计费。重试前应核对是否已有可用结果；自有系统可用任务编号和内容摘要防止重复入库，但这不代表所有接口都支持幂等处理。若需复现问题，可在权限允许且注意隐私的前提下，使用相同输入和配置重新测试，并注明这是新请求。

模型生成内容不等于事实核验结果。需要准确资料时，应另行对照可信材料，并记录核验状态，不能仅凭日志证明内容正确。整理这些信息是为了缩小排查范围，区分请求问题与本地处理问题。具体能记录哪些响应字段，仍取决于实际接口返回和自身的数据保护要求。