顺稿待处理事项

更新时间：2026-06-02

已完成章节

当前草稿目录已有 0-12 章分章文件：

01-opening.md
02-what-cache-caches.md
03-claude-cache.md
04-ttl.md
05-mid-conversation-system-messages.md
06-openai-cache.md
07-deepseek-cache.md
08-claude-code-cache-changes.md
09-agent-framework-cache-problems.md
10-proxy-cache-accounting.md
11-how-to-detect-cache-issues.md
12-model-choice-engineering-advice.md
13-conclusion.md

统一顺稿重点

删除章节之间的重复说明
- system prompt、tool schema、项目规则、工具结果等概念前面已经解释过，后文只承接，不重复枚举。
- cache write / cache read / hit / miss 字段名只在机制章节详细出现，后面尽量用“缓存写入 / 缓存读取 / 普通输入 / 缓存输入”这类类别表达。
删除协作口吻
- 正文不能出现“这里不展开”“后面统一处理”“这一节先不写测试方案”等写给协作者看的话。
- 所有段落都要面向公众号读者。
控制总结味
- 每章末尾不要强行总分总总结。
- 章节之间要自然承接，避免每章都像独立小文章。
减少参数清单
- 技术字段只用于证明机制和可检查性，不做堆砌。
- 示例参数每处保留 2-4 个即可。
禁用表达检查
- 全文检查并删除“不是……而是……”结构。
- 避免怪比喻、标题冒号、AI 味排比、泛词、元话语。

需要回填的技术点

Claude Code 5 分钟缓存保活

用户在后台请求记录里观察到：Claude Code 可能为了维持 5 分钟缓存，定期发送很小的保活请求。

当前验证状态：

本机 Claude Code 版本：2.1.160。
本机包里能看到 usage 类型支持 ephemeral_1h_input_tokens / ephemeral_5m_input_tokens。
还没有从本机二进制 strings 中找到可直接引用的“定时发 1 token 刷新 prompt cache”的实现证据。
因此正文不能写成确定事实，只能写成“如果后台请求记录里能看到这类保活请求，需要把它计入成本”。

粗算逻辑：

5m cache read 按 0.1x。
如果一小时 12 次保活，每次读取一次缓存前缀，读缓存成本约 0.1 × 12 = 1.2x。
加上第一次 5m cache write 的 1.25x，总计约 2.45x。
这比直接写 1h cache 的 2x 更高。
但实际还要看保活请求是否真的读取完整缓存前缀、是否产生输出、是否被中转站按原价计费。

建议放置位置：

优先回填到 04-ttl.md，作为 5m TTL 和 1h TTL 成本比较的现实边界。
也可以在 08-claude-code-cache-changes.md 中作为 Claude Code 观察项提一下，但不要写成确定实现。

章节级待改

10-proxy-cache-accounting.md

末尾当前仍有“所以这一节先不写测试方案”这类协作口吻，顺稿时要删掉或改成读者可读的自然承接。
中转站章节只保留和缓存直接相关的三件事：usage 抹平、路由打散、请求改写。
不再写模型替换 / 降智，避免偏离缓存主线。

11-how-to-detect-cache-issues.md

当前有保活请求预留段，顺稿时要移走。
检查是否仍重复前文已经讲过的字段名和机制。
“判断方法”要写成可操作但不误导，不假设用户能直连官方。

12-model-choice-engineering-advice.md

重点保留 50% 命中 3 折 vs 95% 命中 6 折的例子。
减少对 Claude / OpenAI / DeepSeek 前文机制的重复，只保留选型判断。

13-conclusion.md

保留普通聊天 vs Coding/Agent 输入输出结构差异。
不写没有证据的精确比例，如 95:5 / 20:80。
避免重复列 system prompt、工具定义、项目规则等细节。