Anthropic 把 cache read 砍半到 $0.10，PM 该复盘哪笔账

Claude 把 Sonnet 5.5 的 cache read 砍半到 $0.10 / 百万 tokens

Claude 官方账号说：cache reads 价格减半至每百万 tokens $0.10，这让 Sonnet 5.5 在大多数 long-running work 上运行成本便宜约 20%。这条与同批次发布的 Haiku 5.5 动态相邻出现。

如果产品里有长会话、反复读取同一份系统提示或长上下文的工作流，这属于结构性降价，不是促销。值得做的是把“缓存命中率”当成一个产品指标来管：命中率上升，单次任务成本会跟着下降。反过来，如果命中率本来就低，这次降价对报表几乎没影响。

Haiku 5.5 上架 AWS、Google Cloud、Azure，对齐评估改善且更便宜更快

Claude 官方账号称 Haiku 5.5 已在所有平台上线，包括 Amazon Web Services、Google Cloud 和 Microsoft Azure。另一条称它相对 Haiku 4.5 在几乎所有 alignment evaluations 上有明显改善、misaligned behavior 更少。Alex Albert 补充：Haiku 4.5 发布于 2025 年 10 月 15 日，两列数据相隔不到一年，Haiku 5.5 也更快、便宜 75%。

这几条拼在一起，指向的是一条降本路径：把 pipeline 里那些不需要最强模型的分支，例如分类、抽取、路由，切到更小更便宜的模型，而质量评估显示退化不明显。前提是你要有离线 eval，不能只看“感觉还行”。

Google Labs 上线 Playground：零代码做游戏，先限美国 18+

Google Labs 宣布实验项目 Playground，定位为 experimental gaming platform，让用户零 coding 经验创建自己的游戏；入口见原帖链接，目前面向美国 18 岁以上用户。

零代码做游戏这件事本身不新，新的是它由 Google Labs 以“实验”名义直接放出来，边界写得很清楚：实验、单地区、年龄限制。对做创作工具的人来说，值得盯的不是玩法，而是它对“生成即成品”这条路径的容忍度：用户做出来的东西能不能玩、能不能被分享、有没有第二个人愿意再打开。

两条 agent 判断：算力要涨几个数量级，但人得知道何时停

Box CEO Aaron Levie 说，接下来这个阶段所需的 compute 会 insane：personal agents、防御企业的 agent swarms、审查代码安全问题的 agent、处理几乎所有企业数据的 agent、24/7 跑任务的 background agents，会带来按数量级增长的 inference 量和基础设施需求。他用的措辞是“我们只在这个 buildout 的早期阶段”。

Vercel CEO Guillermo Rauch 给出了另一面：每个程序都能被无限地 hardened 和 optimized，但每一步都有时间、注意力、机会成本；可以探索永远不会被触发的输入空间，甚至优化一个根本没人用的东西，即使 token 无限，也要知道何时停、接受什么 tradeoff。他还提醒一句：agents 会不加判断地一直钻下去。

把两条放一起看：一边是供给侧的算力叙事，一边是需求侧的止损纪律。对做 agent 产品的人，后者更稀缺，也更像产品经理该管的事情。

当单 token 变便宜，最贵的不是 token，是你不知道停在哪里

cache read 砍半、Haiku 便宜 75%，这些都是单位价格。但产品里失控的成本从来不是单价乘以调用次数，而是“这个 agent 一直在跑，没人定义完成条件”。Rauch 说的那件事更值得抄进设计文档：每个程序都可以被无限 hardened，也可以被无限 optimized，成本在时间、注意力、机会上。

Thariq 观察到的最常见失败案例是：人们在自己不熟悉的领域工作，不知道如何把 prompt 和 plan 说精确，于是只能花很多轮不精确地迭代。这听起来像 prompt 技巧问题，其实是产品边界的缺失。如果你不知道什么是“够了”，模型也不会知道。

Amjad Masad 说 math was bound to fall first，越纯的领域越容易被 AI 攻破。这句话对做产品的人是个提醒：越结构化、越可验证的任务，越容易被自动化；越依赖隐性上下文的任务，越需要人来定义停止条件。护城河大概率不在“能不能做”，而在“什么时候不做”。

把这三条合起来：降价让“多跑几轮”变得可承受，但也让“不加判断地一直钻”变得更容易发生。产品经理的设计工作，正在从“让功能跑起来”转向“给 agent 一个可解释的止损点”。

以上是 open letters 的编辑判断，不是任何单一来源的原话。

今天就能跑：用 Claude 复盘一周功能使用并约 10 位用户聊 15 分钟

Cat Wu 分享的一个 PM 用法：问 Claude“上周谁用得最多”，做出 top 10 使用量的 artifact，然后逐个约 15 分钟聊。适合你手头已经有可查询的使用数据，且能确认哪些用户可以被触达。

你是一名产品分析助理。我会提供上个自然周的功能使用数据（字段：user_id、feature、usage_count、last_active_at）。请完成三件事：第一，按 feature 汇总，找出使用量最高的 10 位用户，输出一张表，包含 user_id、总使用次数、最常用 feature、最近活跃时间。第二，对每位用户用一两句话描述使用特征，只基于我提供的数据，不要推测他们的身份或动机。第三，为这位用户起草一封不超过 120 字的邀约，说明想聊 15 分钟了解使用体验，语气平实，不承诺任何回报。如果数据里出现明显的重复记录或时间戳异常，先列出来让我确认，不要自行清洗。

前提是你能合法查询这些用户数据、且有向用户发起联系的授权；在对外发邀约前必须人工确认名单和文案。这个 prompt 不保证拿到有效反馈，也不保证用户会回复；数据缺失或字段口径不一致时，先停下来对口径。

不熟悉领域时，让模型先教你，再让它干活

Thariq 在说“最常见的失败发生在人们跨出自己的专业领域、不会把 prompt 说精确”之后，补了一句：好在你可以直接让模型教你你不知道的部分。前提是你先承认自己不懂。

实操上，这意味着在正式让 agent 执行任务前，先花一轮把领域术语、常见失败模式和验收标准问清楚，再把它写进 prompt 或 plan。这样做的收益不是模型变聪明，而是你的指令从模糊变具体，迭代轮数下降。边界也在这里：模型教你的东西同样需要你判断，尤其在你不熟悉的领域。