4 posts
一条 110 万阅读的推教你把 Claude Code 的 token 用量砍 90%。四个工具我全上了，然后打开归因面板——马拉松会话确实降了 41 个点，可省出来的额度立刻被 subagent 扇出吃光，涨了 46 个点。这一篇把我账单里的五个大户逐个量了一遍：一条 SSE 链路 19 个文件 8,716 行、一份 209 页的企业接口文档（一次灌进去 35k token）、24 份知识治理语料、单日 52 MB 的业务日志、一个 49,480 字符的 CLAUDE.md——四个工具只治得了其中两个，最肥的两块（大文档灌入）是它们的完全盲区。含全部实测：rtk 装了但一行 token 都没省、真实压缩比 32.2% 不是 88%、codegraph 的 stale 窗口精确到 300 秒、以及大文档该怎么从「硬灌」改成「按需取」。读完 20 分钟，你能打开 /context 和用量归因面板，指着账单说出钱花在哪。
一条周期性的 P99 尖峰，每隔几分钟准时来一次，但 CPU、QPS、错误率全是平的，Agent 代码一行没改。所有人第一反应都是「ES 检索慢了」——查了一圈，ES 全是 async，干净得很。真凶是另一个你绝不会去怀疑的地方：那个用来观测 Agent 的运维看板，自己把 Agent 掐住了。这一篇是那次排查的工程复盘：单线程 event loop 上一个同步调用怎么冻住全员、怎么把尖峰时间戳对齐到看板刷新、两行修复（to_thread + TTL cache）、以及本周能给自己 async 服务装的 10 个 event-loop 探针。读完 20 分钟，你能在自己的服务里抓出同一类「一个同步调用拖垮一整个 loop」的洞。
PPT 上那张退款流程是一条干净的 8 步直线。真做出来，那条直线只占两成——其余八成是在判断「要不要走到退款这一步」。这一篇把一个真实的 L2 退款 workflow 拆开：从线性 8 步到分流树、为什么大部分代码不是退款是不退款、限额为什么必须在一张 DB 表里而不是在 prompt 里、每个外部系统没就绪的叶子为什么默认转人工。读完 25 分钟，你能拿这张骨架图去问供应商「你的退款 workflow 这几道护栏在哪」。
同一条退款话术，本地 curl 出来是新的，线上 curl 出来是 9 天前那句「不如淘宝京东」。源文件和线上之间，隔着一个我一直以为是自动、其实是手动的步骤。这一篇是那次排查的工程复盘：两段叠加的静默失同步根因 + 33 条测试反馈怎么聚成 16 条同根因 + 为什么看板全绿却全错 + 本周能给自己 KB 流水线加的 10 道闸。读完 20 分钟，你能在自己的「源 + 派生索引」系统里找出同一个洞。