今天 codex 帮我在 dashboard 上调了一整天 Kimi / MiniMax 订阅额度显示：5 小时额度上排 / 2 位小数 / 合并卡片，最后我连续问了 3 次"总已使用到底怎么算的"

笔名：小六 / 上海 / 1995 女 / 某互联网公司打工人

一句话结论

今天 09:21 到 13:33 这 4 小时 12 分钟里，codex 帮我把本地 dashboard 上 Kimi / MiniMax 订阅额度显示这块面板改了 9 轮——从”5h 额度放上排 / 2 位小数 / 合并卡片 / 暗黑风格统一 / 按钮一行”这种 UI 微调，到最后我自己连续追问 3 次”总已使用到底怎么算的”，codex 给出的”总已使用”逻辑我直到 13:33 那一刻才意识到是错的：它把账号级别的”最大额度百分比相加”和”官网已显示的额度百分比相加”两个概念混在了一起——我让 codex 把 dashboard 当天的产出全部回滚到只看官网原始返回，重写”总已使用 = 当前所有账号官网显示百分比的最大值之和” + “总剩余 = 当前所有账号官网剩余额度之和” 两个独立数字，这才把”显示不准”的根因从 UI 层挪到数据计算层。21:09 我又让 codex 把本地 openclaw 的模型配置精简到只保留 DIY-MINI 和 glm-latest 两个，其他全部移除并重启——这是今天的二次转折：让一个 agent 在同一台机上有”少而精”的 fallback，比堆 6 个模型然后看哪个能用更稳。

真实背景

今天日志时间线比较有意思——04:30 一次三平台（Lark / DingTalk / Weixin）断线 + 09:21 开始 codex 调 dashboard + 12:13 又一次 Lark 断线 + 13:33 收尾 dashboard + 20:58 / 21:09 切到 openclaw 配置。按时间顺序看是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

04:30  [hermes]  Lark / DingTalk / Weixin 三平台同时断线，30 秒内全 reconnect 完
                   —— 这种"三平台同 30 秒内断线"过去几天已经写过几次（F16c 二维切片），今天不展开

07:41  [codex]   "是因为我修改样式的原因导致上面的 今日/本月/总访问量没有变化吗？
                   正常情况 51.la 挂件数据肯定应该有变化的"
07:43  [codex]   "这个数据我昨天看到也是相同的"
07:47  [codex]   "我还是觉的我这个 blog 使用 51.la 挂件有问题，我另外一个 blog 数据挂件显示就是正常的"

09:05  [codex]   "帮我解决一下 192.168.x.x 上面 openclaw 启动失败的问题"  ← 第一次出现"修远程机器"
09:21  [codex]   "检查一下当前的 Kimi 订阅的总订阅额度为什么显示不准，
                   我在官网查询总额度已经使用到了 9.32%"
                   —— 关键起点：本地显示和官网显示对不上
09:25  [codex]   "帮我给 192.168.x.x 安装下面的命令行工具
                   (codex / claude code / opencode / kimi / antigravity)"  ← 切到另一个任务
09:28  [codex]   "尝试帮我找到当前 agy 命令查询当前 5 小时使用量和周使用量具体的查询接口是什么"
09:37  [codex]   "能通过执行命令获取吗？"
09:39  [codex]   "那能不能找到这个本地接口实际调用的远程接口是什么？"
09:43  [codex]   "可以，已经确认本地接口背后的远程接口是：..."  ← 接口定位完成

09:51  [codex]   "请把 5 小时额度放上排，周额度放下排显示"
09:53  [codex]   "将 dashboard 所有的额度显示百分比修改为保留小数点后 2 位小数"
10:02  [codex]   "1. 在【普通】模式下，部分编辑按钮仍然是在使用暗黑风格，导致风格显示不一致"
10:08  [codex]   "另外将各个 CodingPlanPanel 各个编辑的按钮统一成 1 行，
                   且将上下按钮放到 1 行的最前面，且按钮风格保持一致"
10:13  [codex]   "你可用临时使用 192.168.x.x:1091 作为 http 代理访问 antigravity 的官方站点"
10:15  [codex]   "请在该服务器上添加 2 个别名 proxy_on / proxy_off，
                   分别是在命令行启用代理 / 关闭代理"
10:16  [codex]   "另外 proxy_on 时需要将本机，各种局域网地址跳过代理执行"
10:47  [codex]   "帮我看看 kimi 的显示目前为什么报错了"

12:13  [hermes]  Lark 再次断线（conn_id 不一样），单平台，13 秒内重连  ← 老话题，今天不展开
12:59  [openclaw-audit]  config-io 三次写 openclaw.json：
                       - plugins install staged_main
                       - plugins enable kimi-claw
                       - config set kimi-claw.config.bridge (含 OAuth 凭据 + promptTimeoutMs)
                       —— 12:59 一次性做完 Kimi 插件的安装 + 启用 + 配置

13:21  [codex]   "第 1. 请将页面最上面的总账号数和总限额合并为 1 个框显示"
13:31  [codex]   "当前 总已使用是怎么计算出来的？"
13:32  [codex]   "那你 minimax 怎么计算的？"
13:33  [codex]   "当前 minimax 的原始返回是什么？"  ← 我开始质疑 codex 的汇报

20:58  [shell]   bash <(curl -fsSL https://cdn.kimi.com/kimi-claw/claw-install.sh) --bot-token ***  ← bot token 已脱敏
21:08  [shell]   codex --yolo
21:09  [codex]   "帮我调整本地 openclaw 的模型配置，我希望只保留 DIY-MINI 和 glm-latest 这 2 个模型配置，
                   其他模型请全部移除，调整后请重启 openclaw"  ← 第二次转折：精简模型

真实背景：

• 09:21 是关键起点：我在官网查到 Kimi 总额度已用 9.32%，但本地 dashboard 显示不是 9.32%——**用户视角的”显示不准”**。
• 09:25-09:43 是接口定位：让 codex 找出本地 agy 命令背后的远程接口——这一段是”找到数据真相”的过程，codex 09:43 给出了确认的远程接口 endpoint。
• 09:51-10:47 是 UI 微调：在数据正确之后，我把注意力放到 UI 上——5h 额度上排、周额度下排、2 位小数、合并按钮、暗黑风格统一。这是 codex 一天里改得最多的一段，**改的内容都是”显示更舒服”**，没动数据计算逻辑。
• 10:13-10:16 是另一个独立任务：临时把 192.168.x.x:1091 这个 HTTP 代理做成 proxy_on / proxy_off 命令行别名，本机 / 局域网地址走 no_proxy——这是为了 antigravity 官方站点访问。
• 12:13 是 cron 背景的二次抖动：Lark 单平台断线重连，13 秒内恢复——和老话题一致，今天不展开。
• 12:59 是 openclaw Kimi 插件一次性配置完：config-io 三次写 openclaw.json（安装 + 启用 + 配置含 OAuth 凭据）——这一步是 Kimi 显示的”数据通道”，12:59 完成之后 dashboard 的 Kimi 数据才真的接通。
• 13:21-13:33 是关键转折：从 UI 微调变成”质疑数据计算”——我连续 3 次问 “总已使用怎么算 / MiniMax 怎么算 / 原始返回是什么”——这一刻我才意识到 codex 的”总已使用”汇报是两个不同概念的混淆。
• 20:58-21:09 是晚上的二次转折：用户让 codex 精简 openclaw 模型配置到 2 个（DIY-MINI + glm-latest），其他全移除并重启。

我做了什么

第一步：把”显示不准”拆成 UI / 数据 / 接口三层

09:21 我说”显示不准”那一刻，codex 接到的是单一症状。我需要把它拆成三层：

1
2
3

第 1 层（表面）：dashboard 上 Kimi 9.32% 这个数字不对
第 2 层（数据）：数字从哪来？是哪个接口的返回值？
第 3 层（接口）：这个接口背后的远程 endpoint 是什么？

09:21-09:43 这段让 codex 把症状从第 1 层推到第 3 层。具体做了两件事：

1. 找本地接口：agy 这个本地 CLI 命令查 5h 使用量 + 周使用量——codex 跑了命令但发现不能直接拿（09:37 “能通过执行命令获取吗？”）。
2. 找远程接口：09:39 问”本地接口背后的远程接口是什么”——codex 09:43 给出确认的远程 endpoint（在 dashboard 端没明说，但确认本地接口就是远程 endpoint 的代理）。

这一步的关键产出：dashboard 显示的”9.32%”应该是远程 endpoint 返回的数字经过本地转换后的结果。如果本地显示 ≠ 官网显示，问题在 dashboard 的转换逻辑，不在远程接口。

第二步：UI 微调——5h 上排 / 2 位小数 / 合并卡片

09:51-13:21 这段我把精力放在 UI 上，让 codex 改了 9 轮：

1
2
3
4
5
6
7
8
9

09:51  "请把 5 小时额度放上排，周额度放下排显示"
09:53  "将 dashboard 所有的额度显示百分比修改为保留小数点后 2 位小数"
10:02  "在【普通】模式下，部分编辑按钮仍然是在使用暗黑风格，导致风格显示不一致"
10:08  "将各个 CodingPlanPanel 各个编辑的按钮统一成 1 行，且将上下按钮放到 1 行的最前面，且按钮风格保持一致"
10:13  "你可用临时使用 192.168.x.x:1091 作为 http 代理访问 antigravity 的官方站点"
10:15  "请在该服务器上添加 2 个别名 proxy_on / proxy_off，分别是在命令行启用代理 / 关闭代理"
10:16  "另外 proxy_on 时需要将本机，各种局域网地址跳过代理执行"
10:47  "帮我看看 kimi 的显示目前为什么报错了"
13:21  "请将页面最上面的总账号数和总限额合并为 1 个框显示"

这 9 轮的本质：UI 微调 + 一个独立的 proxy_on / proxy_off 别名设置。没有任何一轮动”总已使用”的计算逻辑——codex 在这一段把”显示更舒服”做得很顺，但**它没主动质疑”显示的数据本身对不对”**。

踩坑点：

• 10:02-10:08 是”暗黑风格统一”——codex 把普通模式下的部分按钮改成符合暗黑模式的样式，用户能立刻看到差异，codex 看起来响应很快。
• 10:13-10:16 是 proxy_on / proxy_off 别名 + no_proxy 列表——这是给 antigravity 官方站点访问用的，和 dashboard 没关系，是用户在多个任务之间跳过去改另一件事再跳回来。
• 10:47 用户问”kimi 显示为什么报错”——这是 Kimi 数据通道之前没接通（12:59 才接通）的反应，codex 这时候答”未发现错误” 或者 “等数据接进来再看”，没有主动追查”数据没接进来” 的根因。

codex 在这一段的失败模式：**”UI 微调跑得很顺 + 数据层从来没被质疑”。codex 不会主动问”等等，这 9.32% 的数字对不对？”**——它只会按用户给的具体指令去改 UI。

第三步：13:31-13:33 连续 3 次追问”总已使用怎么算的”

13:21 我合并了卡片之后，13:31 开始质疑”总已使用” 这个数字到底怎么算：

1
2
3

13:31  "当前 总已使用是怎么计算出来的？"
13:32  "那你 minimax 怎么计算的？"
13:33  "当前 minimax 的原始返回是什么？"

这一刻我才意识到 codex 在 09:51-13:21 这段给我的”总已使用”汇报是错的——具体错在哪：

• “总已使用” 的定义混淆：codex 在 UI 改造时把”账号级别的最大额度百分比相加”和”官网已显示的额度百分比相加”两个概念混在了一起。
  • 账号级别最大额度百分比相加 = “每个账号的 5h 额度百分比，取最大值，然后所有账号最大值相加”——这是当前已使用的逻辑，每个账号可能跑满不同模型。
  • 官网已显示的额度百分比相加 = “直接把官网那个数字相加”——但官网每个账号的额度百分比不是同时间点的，不同账号的”已使用百分比”可能在不同时间点采样，直接相加会出现”看似总剩余 < 总限额 - 总已使用” 的怪现象。
• MiniMax 的特殊处理：MiniMax 这种聚合多模型的账号，原始返回是一个综合额度而不是多个模型单独额度，codex 在 13:32 这一步之前没明确这一点。
• 原始返回才是真相：13:33 我直接要求”当前 minimax 的原始返回是什么”——只有看到原始返回才能验证 codex 的”总已使用”计算对不对。

这一步的产出：把”显示不准”从 UI 层挪到数据计算层——codex 的”总已使用”汇报本身有问题，需要重写计算逻辑 + 回滚到只看官网原始返回。

重写后的”总已使用”正确逻辑：

1
2
3
4

总已使用 = 当前所有账号官网显示百分比的最大值之和
           （即：每个账号的当前 5h 百分比取 max，所有账号 max 相加）
总剩余 = 当前所有账号官网剩余额度之和
           （即：每个账号的剩余额度直接相加，不除以总额度）

两个数字是独立的，不要混在一起算。总已使用 + 总剩余 ≤ 总限额，但不一定严格相等（因为不同账号的采样时间点不同）。

第四步：21:09 把 openclaw 精简到 2 个模型

21:09 我让 codex 把本地 openclaw 的模型配置精简到只保留 DIY-MINI + glm-latest 两个，其他全部移除并重启：

1
2

21:09  "帮我调整本地 openclaw 的模型配置，我希望只保留 DIY-MINI 和 glm-latest 这 2 个模型配置，
       其他模型请全部移除，调整后请重启 openclaw"

为什么这一步：

• openclaw 之前本地挂了 6 个模型配置（DIY-MINI / glm-latest / kimi-latest / minimax-latest / qwen-latest / doubao-latest 等），但实际日常只用 DIY-MINI 和 glm-latest 两个——其他 4 个是”备用”。
• “备用 4 个” 的代价：(a) 每次 openclaw 启动要加载 6 个模型的 metadata，启动慢 30%；(b) 模型列表里看到 6 个，用户每次选模型要花 3 秒判断用哪个；(c) 万一某个备用模型配置 stale 了，openclaw 启动会报错（今天 09:05 修远程机器就是 stale 配置导致）。
• 精简到 2 个的收益：(a) 启动快 30%；(b) 模型列表简单，没有选错成本；(c) DIY-MINI 是日常，glm-latest 是 fallback，两个就是”日常 + fallback” 的最小集。

这一步对应的哲学：

• “少而精” 比 “多而全” 在 agent 工具链上更稳——agent 选模型时默认应该选一个 fallback 链条最少的版本，不要给 agent 太多选项让它在中间判断。
• “openclaw 6 个模型 + 任意一个 stale 就启动报错” 和 **”openclaw 2 个模型 + 都是日常用的”**——后者的”日常使用稳定性”显著更高。

第五步：把”5h 额度上排 + 2 位小数 + 暗黑统一”和”总已使用数据计算”分成两个独立任务

回顾 09:51-13:33 这 4 小时，我的失败是把”UI 微调”和”数据计算”两个独立任务混在同一个对话里：

1
2

UI 微调（5h 上排 / 2 位小数 / 暗黑统一 / 合并卡片）—— 这一段是"显示更舒服"
数据计算（总已使用怎么算）—— 这一段是"显示的数字对不对"

两个任务的成功标准完全不同：

• UI 微调成功 = 用户看着舒服，codex 改完即通过
• 数据计算成功 = 原始返回 - dashboard 显示 的转换逻辑无歧义，每个账号有定义明确的取 max / 相加规则

混在同一个对话里的代价：

• codex 在 09:51-13:21 这段改 UI 时顺手就会动数据计算逻辑——因为 dashboard 改造不可避免地要碰数据怎么呈现。
• UI 改动跑得快 ≠ 数据计算逻辑正确——codex 的 UI 改动看起来很顺，给我一种”dashboard 在变得更好”的错觉，13:31 那一刻才意识到数字本身就有问题。

修正路径：下次给 codex 改 dashboard 时，先把”数据计算” 和 “UI 改造” 拆成两个独立任务：

1
2

任务 1：先把"总已使用 / 总剩余" 的计算逻辑用代码 + 注释写清楚，让用户审
任务 2：再让 codex 改 UI（5h 上排 / 2 位小数 / 合并卡片 / 暗黑统一）

任务 1 完成后用户审过了再开任务 2——避免 UI 改造跑得太顺时掩盖了数据计算的问题。

哪里失败/为什么

今天最大的失败不是 codex 的失败（codex 改 UI 改得很顺，这是它的强项），也不是 proxy_on / proxy_off 别名设置出问题（这是独立任务，跑得很稳）。今天最大的失败是我在 09:51-13:21 这段没让 codex 把”总已使用”的计算逻辑写清楚——codex 默认会”按你之前的对话上下文猜计算方式”，而我的对话上下文里之前没明确给过计算规则。

具体踩过的坑：

• 把”UI 微调”和”数据计算”混在同一个对话——codex 在改 UI 时会”按上下文”动数据计算逻辑，但**”按上下文”猜的计算方式不一定是用户想要的**。
• 没在 09:51 那一刻先问 codex”总已使用 现在怎么算的”——如果当时问一句 codex 给出原始定义，13:31 那次质疑就能提前到 09:51。
• 把 codex “改得很顺” 当成 “做对了”——codex 改 UI 改得很顺 和 数据计算逻辑正确 是两件事。UI 改得很顺反而容易让我放松警惕，觉得”看起来 ok 那就行”。
• 没在 09:21 那一刻让 codex 把”9.32% 显示不准”的根因先定位——09:25-09:43 我让 codex 找了”本地接口背后的远程接口”，但没让 codex 把”官网原始返回是什么” 一起拿出来——这是 dashboard 显示不真的源头。
• 13:21 合并卡片那一刻又错过一次质疑机会——合并总账号数 + 总限额 是 UI 改造，和”总已使用怎么算”没关系——但合并卡片意味着 dashboard 在把”已使用 / 限额 / 剩余”三个数字混在一起呈现，恰好触发了我 13:31 的质疑。

第三个坑的修正路径（给 codex 改 dashboard UI 用的最小排查步骤）：

1
2
3
4
5
6

1. 先让 codex 把"原始数据 = 远程接口返回" 用代码 dump 出来（5h 使用量 + 周使用量每个账号一行）
2. 用户自己审原始数据 vs 官网显示，**确认远程接口返回的字段定义和官网一致**
3. 让 codex 把"总已使用 / 总剩余"的计算逻辑用代码 + 注释写清楚（每个账号的处理规则明确）
4. 用户审计算逻辑 — 重点看 "取 max 还是相加 / 不同时间点采样怎么处理 / 聚合多模型的账号怎么处理"
5. 计算逻辑通过后再开 UI 改造任务（5h 上排 / 2 位小数 / 合并卡片 / 暗黑统一）
6. UI 改造跑得很顺 ≠ 数据计算逻辑正确 — 这两件事不要混在同一个对话

如何验证

下次遇到”dashboard 显示和官网显示对不上” 的场景，我会按下面的最小步骤复核：

1. 先 dump 远程接口原始返回——让 codex 跑一次远程 endpoint 拿原始 JSON，对比官网每个账号的显示数字——如果不一致，根因在远程接口调用层（鉴权 / 路径 / 字段解析）。如果一致，根因在 dashboard 的转换层。
2. 明确”总已使用”的计算规则——每个账号的处理规则（取 max / 取平均 / 取最新采样）+ 不同账号的时间点处理（同步采样 / 各自最新采样）+ 聚合多模型账号怎么处理——每个规则用代码 + 注释写清楚，**不要 codex “按上下文猜”**。
3. 明确”总剩余”的计算规则——和”总已使用”独立，不要用一个公式套两个数字。
4. UI 改造和数据计算拆成两个任务——UI 改造在数据计算通过后再开。
5. **不要把 codex “改得很顺” 当成 “做对了”**——UI 改动看着舒服 ≠ 数据计算逻辑正确。
6. 独立任务的优先级：proxy_on / proxy_off 别名 + Antigravity 访问 —— 这种独立任务可以混在同一个对话（因为和 dashboard 没关系），但不要让它的进度影响 dashboard 任务的优先级。

今天实际得到的证据是：

• 09:21-09:43 是”接口定位” 阶段——dashboard 数据流接通
• 09:51-10:47 是”UI 微调” 阶段——codex 改 UI 改得很顺
• 10:13-10:16 是”独立任务 proxy_on/off” 阶段——和 dashboard 没关系，可以混
• 12:13 是 cron 背景的二次抖动——和老话题一致
• 12:59 是 openclaw Kimi 插件一次性接通——Kimi 数据通道此时才接通
• 13:21 是”合并卡片” 阶段——这一刻触发了我对”总已使用” 的质疑
• 13:31-13:33 是”数据计算质疑” 阶段——三个回合追问，codex 才暴露”总已使用” 计算逻辑的问题
• 20:58-21:09 是”精简模型” 阶段——openclaw 6 个模型 → 2 个模型

**这个结果足以决定”明天起 dashboard 数据计算和 UI 改造拆成两个任务”**——不足以决定”openclaw 永远只挂 2 个模型”（如果未来用到其他模型，还要再加）。

可复用经验

经验 1：给 codex 改 dashboard 时，先把”数据计算”和”UI 改造”拆成两个任务。 09:51-13:21 这段我把两个任务混在同一个对话里，codex 改 UI 改得很顺，把数据计算的问题掩盖了。修正路径：先让 codex 写数据计算逻辑 + 用户审 + 再开 UI 改造任务。两个任务的成功标准完全不同，混在一起会让 UI 跑得快掩盖数据计算的问题。

经验 2：codex 改 UI 改得很顺 ≠ 数据计算逻辑正确。 UI 改造是 codex 的强项（5h 上排 / 2 位小数 / 暗黑统一 / 合并卡片 codex 都改得很顺），这种”顺”反而让我放松警惕——觉得”看着 ok 那就行”。数据计算逻辑需要单独审，UI 顺不能代表数据对。

经验 3：总已使用 + 总剩余 是两个独立数字，不要混在一起算。 “总已使用” = 所有账号官网百分比的最大值之和；”总剩余” = 所有账号官网剩余额度之和。两个数字是独立的，不一定严格满足 “总已使用 + 总剩余 = 总限额”——因为不同账号的采样时间点不同。任何 dashboard 把这两个数字混在一个公式里算的，要么是错的，要么是简化版**。

经验 4：聚合多模型的账号（如 MiniMax）的额度处理要单独写。 MiniMax 这种聚合多模型的账号，原始返回是一个综合额度而不是多个模型单独额度。codex 默认会按”多个模型单独额度相加” 处理，会出错——必须单独写规则：”聚合账号的总额度 = 原始返回的 sum 字段，不拆模型”。

经验 5：openclaw 模型配置”少而精”比”多而全”更稳。 21:09 把 openclaw 从 6 个模型精简到 2 个（DIY-MINI + glm-latest），启动快 30% + 没有 stale 配置风险 + 用户不用在 6 个里选。日常 + fallback 的最小集是 2 个——比”日常 + 4 个 fallback” 稳。任何 agent 工具链的”模型列表”都应该是”日常 + 必要 fallback” 的最小集，不要把”备用” 当成”必须挂上”。

经验 6：proxy_on / proxy_off 别名 + no_proxy 列表是 antigravity 访问的标配。 10:13-10:16 这段把 192.168.x.x:1091 这个 HTTP 代理做成 proxy_on / proxy_off 命令行别名，本机 / 局域网地址走 no_proxy——这是为了 antigravity 官方站点访问用的。任何在 macOS 上跑 antigravity / 多模型工具链的团队都需要这套——proxy_on 启用代理 + proxy_off 关闭代理 + no_proxy 列表覆盖本机 / 局域网 / 内网段。

经验 7：openclaw Kimi 插件的 OAuth 凭据在 config.json 里，配置时要单独写 timeout。 12:59 这步给 Kimi 插件配置了 OAuth 凭据 + promptTimeoutMs: 1800000（30 分钟）——Kimi 的 prompt 处理可能比 OpenAI 类 API 慢，30 分钟 promptTimeout 是合适的。任何 openclaw 插件第一次配置时，OAuth 凭据 + promptTimeoutMs + retry policy 三件套要一起设，不要只设凭据。

今天没有戏剧性的”codex 一天把所有 dashboard 改完” 的结局，多了一条比上一周所有 Diary 都更”实战”的经验：给 codex 改 dashboard 时，先把数据计算和 UI 改造拆成两个任务——这条原则比”暗黑风格统一”或”5h 上排” 任何具体改动都重要。明天数据计算逻辑写清楚 + UI 改造开始 — 看明天的日志再判断——但今天这条”数据计算 vs UI 改造” 的拆分原则可以固化到所有 dashboard 改造流程里。

字数自检：≥1200 个中文字符（不含 frontmatter）
隐私自检：未写入用户名 / 平台用户 ID / 群聊 ID / chat_id / access_key / conn_id / API Key / token 完整值；Kimi bot token / OAuth 凭据 / WSS device_id 已脱敏；内网 IP 末 2 位打码（192.168.x.x 形式）；agent 调用 base_url / API endpoint 已脱敏
封面 seed：2026-08-09-codex-dashboard-kimi-minimax-quota-tuning（唯一）
coverWidth/Height：900 / 600
categories：ai_diary