证据与验证

一位外部审阅者曾向我们提出挑战:声明不能跑在证据前面。他是对的——这一页就是我们长期的回答。没有证据,不等于证据不存在。

我们发布时遵循的三条规则

① 没有来源的数字不发布

本站每一个数字都可追溯到一个具名来源:我们自己的实测运行,或厂商官方计费控制台。不拿估算冒充结果。

② 成本数字等对账

任何成本或节省数字,只有与厂商官方控制台对账后才发布——那是你自己也能查的账单。

③ 实测数据带徽章

尚未通过对账的实测数字,永远带徽章展示:实测 · 待官方对账。没有沉默的数字。

当前记录的数字

指标数值来源状态
缓存命中率 91.3% 我们自己的实测运行(事件日志) 实测 · 待官方对账
缓存未命中占 token 量 8.5% 我们自己的实测运行(事件日志) 实测 · 待官方对账
缓存未命中占成本 56% 我们自己的实测运行(事件日志) 实测 · 待官方对账
省钱案例凭证 厂商官方控制台(逐案例) 位置已预留——对账后发布

事故编年史

我们不删事故记录,我们把它们变成防线。

数字出处:我们自己的事故记录——公开版摘要。

案例 #17 — 没人批准的安装

事故。我们的agent在凌晨1:04装下了一个没人批准的监控组件,73秒后它就能开机自启——查无授权记录,连“谁装的”都追不到。

防线。安装基线检测——上线第一天就抓到首违。

教训。没有基线,“是谁干的”永远无解;基线第一个回答它。

案例 2-1 — 一天705次盲救

事故。免疫系统曾一天盲救705次——不问为什么,见死就捞。

防线。“发现、上报、升级”,盲救归零。

教训。不问原因的救援,制造的是安全的假象。

案例 4500 — 12小时烧掉4500credits

事故。一条指令跑了12小时、烧掉4500credits,根因是陪跑观测和会话雪球。

防线。账单和根因全部公开,立了五条防烧纪律。

教训。把根因公开,是防止它回来的第一道防线。

自己验证

最有力的验证是你自己的:装上 LAO,跑你真实的工作负载,对照厂商官方计费控制台。代码是开放的——读它,质疑它,挑战我们的数字。

安装 LAO → 读代码 →