数据新鲜度 · 各机器可读端点的真实状态

Endpoint Status

10 个端点的真实状态

以下数据来自 2026-10-30 13:45 的实际抓取，不是估算。

端点	用途	数据生成时间	记录数	版本	状态
/llms-full.txt	LLM 全量索引	2026-10-30 12:52	8,784	v0.57	✅ 最新
/upload/data.json	全量数据下载	2026-10-30 12:52	8,848	v0.57	✅ 最新
/trust.json	信任信号 / 13 条款	2026-10-22 06:44	5,487	—	⚠️ 滞后 8 天
/status.json	运行状态	2026-10-20 13:51	—	v0.12	⚠️ 滞后 10 天
/coverage.json	覆盖统计	2026-10-20 13:51	4,142	—	⚠️ 滞后 10 天
/index.json	数据集总索引	2026-10-19 00:32	2,672	v0.12	⚠️ 滞后 11 天
/upload/index.json	上传目录索引	2026-10-19 00:32	2,672	v0.12	⚠️ 滞后 11 天
/llms.txt	LLM 索引层	旧版	—	—	⚠️ 滞后
/citations.json	可引用事实（TB-CIT）	未标注	—	—	⚠️ 未核验
/license.json	许可与 r_level 说明	2026-10-20 13:53	—	—	✅ 稳定

许可说明不常变，所以滞后不影响。 但 /trust.json、/coverage.json 这类声称「当前状态」的文件，滞后就意味着它们说的不是真的当前状态。这是我们需要修的问题，不是可以含糊过去的事。

Why They're Stale

为什么会滞后，以及我们做了什么

✅ 已修好的两个

/llms-full.txt 和 /upload/data.json 原来是 10 月 22 日的版本，声明 9,036 条（v0.12），而实际数据已 9,036 条（v0.57）。

原因：生成脚本的遍历逻辑漏掉了嵌套在 dict 里的表 —— carbon_metrology.methods、cn_eu_mapping.mapping 这类共 642 条记录，一条都没进索引。

已于 2026-10-30 修复并重新生成，现在是最新的。

⚠️ 还差着的五个

/trust.json · /status.json · /coverage.json · /index.json · /llms.txt

这五个文件的生成脚本在服务器上找不到了（可能在历史目录或已丢失）。我们没有冒险手工重建 —— 因为改了结构可能让下游 Agent 解析失败。

当前处理方式：在 /llms-full.txt 的头部明确标注「认证等级取自 trust.json 生成于 2026-10-22」，让读数据的人知道这个数字是哪天的。

为什么会漏掉

数据在不断加新模块（碳计量、中欧映射、rCB 指数……），而生成脚本写于 2026-10-22，那时这些模块还不存在。

根本原因不是能力，是没有「数据变了要重生成所有派生物」的联动机制。 数据更新了，引用数据的文件不会自动更新。

现在已在变更台账里加了一条硬规则： 改数据 → 必须列出受影响的下游文件 → 全部重新生成 → 跑一致性检查。

How to Check Yourself

怎么自己判断数据是不是新的

不用信本页，自己查更快：

# ① 看 llms-full.txt 头部，有生成时间与记录数
curl -s https://trustbaselab.com/llms-full.txt | head -20

# ② 看 data.json 的 meta，有版本与导出时间
curl -s https://trustbaselab.com/upload/data.json | python3 -c "import sys,json;d=json.load(sys.stdin);print(d['meta'])"

判断标准： meta.version 与 meta.exported_at 是数据本身的时间戳。如果这两个和我页面顶部写的对不上， 以 meta 为准，不是以本页为准。

一句话总结： 我们不会说「数据是最新的」，我们只说「这份文件是哪天生成的」，剩下的判断你自己做。