AI应用的日志设计：什么值得记，什么必须入库

console.log在生产环境不是日志——而是可观测性缺口

在AI应用的开发初期，console.log几乎是所有人的第一选择——快速、直观、无需额外配置。这个习惯在本地调试环境完全可行，但一旦进入生产，它代表的是一个系统性的可观测性缺口。

console.log 不是生产日志

在Vercel、AWS Lambda等Serverless环境中，console.log的输出存在于进程的标准输出，通常只保留24至72小时，且无法进行结构化查询与跨时段聚合。当以下情况发生时，你需要的是数据库记录：

• 用户报告某次对话回答出错，但你无法还原当时的输入与输出
• 费用账单本月异常飙升，但无法定位到哪个功能或哪个用户群体
• API在特定时段反复超时，但不知道发生频率与时间规律

必须入库的最低字段

时区标准化是常被忽略的细节

若部分字段以UTC存储、部分以本地时间存储，跨时段的查询结果将出现难以察觉的偏差。建议在数据库层面统一使用+8时区存储所有时间戳，避免报表计算出错。

有意义的告警依赖结构化日志

• 单一用户24小时累计费用超过阈值 → 告警至管理员
• 过去5分钟429错误比例超过设定阈值 → 触发速率限制告警
• P95响应时间持续超过N秒 → 效能降级告警

常见的记录遗漏

失败请求往往比成功请求更值得分析，却是最常被遗漏的记录对象。另一个常见问题是费用字段在调用时未即时计算，而是依赖事后从API账单反推——这导致实时费用控制能力缺失。更多AI生产可观测性问题，可参阅AI应用的静默失败：每个错误都必须留下记录。

小结

AI应用的日志是运营可观测性的基础设施，其设计应在第一版API调用结构确定时同步完成。事后补加字段的成本远高于设计之初做对。Token费用、模型行为与错误模式的可观测性，直接决定了当问题出现时你能否作出有效诊断，而不是只能盲目猜测。