DeepSeek 更改了 CSV 导出格式（2026 年 8 月）

DeepSeek 改了用量导出格式

如果你从 DeepSeek 平台导出用量或账单数据，最近可能会发现一些不同：amount 和 cost 两个 CSV 文件不再包含你熟悉的 utc_date 列，取而代之的是 ISO 时间戳——连文件名本身也变了。

这可不是表面改动。任何硬编码旧列名的工具或脚本，都会在新导出文件上直接报错。下面我们逐条说明：到底改了哪些列、如何阅读新格式、以及如何让你的用量分析继续正常工作。

• 日期列 utc_date 被 start_time_iso 和 end_time_iso 取代。
• user_id 和（cost 文件中的）wallet_type 现在必带。
• 文件名从 amount-2026-8.csv 变成日期区间式，如 amount-2026-08-01_2026-08-17.csv。

amount CSV — 逐列拆解

• utc_date → 由 start_time_iso / end_time_iso（ISO 8601 时间戳）取代。
• user_id — 现在必带（此前可选）。
• model、api_key_name、api_key、type、price、amount — 保持不变。

示例数据行（Key 已脱敏）：

cost CSV — 逐列拆解

• utc_date → 由 start_time_iso / end_time_iso 取代。
• wallet_type — 现在必带（如 Paid），此前可选。
• cost 与 currency — 保持不变。

注意：cost 文件仍然没有按 Key 拆分——它只按日期和模型聚合，所以把费用归因到各个 API Key，仍需要按 token 占比分摊。

哪些保持不变

• 四种 type 值不变：request_count、output_tokens、input_cache_hit_tokens、input_cache_miss_tokens。
• request_count 行的 price 仍为空。
• cost 语义不变（负数仍表示扣费）。
• price 与 amount 的单位不变（每 token 的人民币单价、token/请求数量）。

日期语义 — 务必看仔细

每行的 start_time_iso 都是北京时间当天零点，例如 2026-08-02T00:00:00+08:00，而 end_time_iso 是次日零点。账单日就是取 start_time_iso 的日期部分——即 2026-08-02。

按天分桶时，不要把这些时间戳转成 UTC。2026-08-02T00:00:00+08:00 转 UTC 后是 2026-08-01T16:00:00Z，会让每天整体错位一天。因为时间戳本身已经是 +08:00 时区，直接取 start_time_iso 的前 10 个字符，就能得到正确的北京时间账单日。

文件名也变了

• 旧式：amount-2026-8.csv / cost-2026-8.csv（按月）。
• 新式：amount-2026-08-01_2026-08-17.csv / cost-2026-08-01_2026-08-17.csv（按日期区间）。

如果你要合并多个月的导出，只匹配 amount-{年}-{月}.csv 的配对逻辑会静默忽略新文件名——请更新文件名匹配规则，同时接受日期区间式，并从起始日期推导出所属月份。

对既有工具的影响

凡是读取 raw['utc_date'] 的脚本，在新导出文件上都会抛出缺少列错误。一个快速兼容方案是：优先读 start_time_iso，若不存在再回退到 utc_date，这样新旧文件都能继续处理。

同时检查任何从时间戳里截取日期的逻辑——如果它先做了 UTC 转换，那么每天的汇总都会整体错位一天。

我们的仪表盘已经适配

免费 DeepSeek API 费用追踪器 的 v0.8.0 已开箱支持新导出格式：从 start_time_iso 派生账单日、按日期区间文件名配对月份，同时完整兼容旧的 utc_date 导出。把平台下载的 ZIP 直接拖进页面即可——全部在浏览器本地完成，不上传、不注册。

完整的 v0.8.0 说明见更新日志。

总结

DeepSeek 的导出格式变更容易被忽略，却很容易踩坑：日期列变成了 ISO 时间戳，文件名也改成了日期区间式。把 start_time_iso 的日期部分当作账单日、继续兼容旧 utc_date 导出、并更新文件名配对逻辑即可。如果你不想操心这些，我们的仪表盘已经替你处理好了两种格式。