写作API任务记录：区分适用范围与例外

整理写作API任务时，记录不必写成复杂报告，关键是能判断请求针对什么内容、结果是否可复用，以及出现问题后从哪里排查。先说明任务范围：记录任务编号、提交时间、用途、输入内容摘要和预期输出类型。摘要应足以辨认任务，不必复制敏感原文。API密钥只保存在服务端或受保护的本机配置中，不要写进请求记录、网页正文或日志。 再记录调用结果和处理状态，例如是否收到响应、返回

整理写作API任务时，记录不必写成复杂报告，关键是能判断请求针对什么内容、结果是否可复用，以及出现问题后从哪里排查。先说明任务范围：记录任务编号、提交时间、用途、输入内容摘要和预期输出类型。摘要应足以辨认任务，不必复制敏感原文。API密钥只保存在服务端或受保护的本机配置中，不要写进请求记录、网页正文或日志。

再记录调用结果和处理状态，例如是否收到响应、返回内容是否完整，以及是否出现错误或超时。只写实际观察到的情况，不要把推测当成事实。请求超时只能说明客户端未在预期时间内得到结果，不能据此认定服务端没有处理请求，也不能认定请求没有计费。应先按任务编号核对已有结果，再决定是否重试，以免重复提交或重复入库。

适用范围要写成明确条件：这条记录对应什么业务用途、输入类型和预期交付形式。只有条件相符时，既有处理方式才可作为参考。例外则记录可能改变判断的情况，例如输入缺失、内容格式不同、结果不完整，或任务状态尚未核实。将适用条件与不能直接套用的情况分开记录，比笼统标注成功或失败更便于排查。

模型生成的文字不等于事实核验。内容涉及事实时，应另行检查依据，不要只因输出流畅就标记为已确认。自有系统可以用任务编号和内容摘要辅助防止重复入库，但摘要不能替代对原任务和结果的核对。具体记录字段应按实际系统能力调整；不能假定所有API都提供相同的状态、编号或错误信息。