夜雨聆风我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听晚点再听LaterCast
"1% 的效率，对我们来说就是几百万美元。"
"要在规模上运行服务，缓存命中率通常要在 94%、95%、96% 以上。"
"要衡量结果，不要只衡量活动。"
在 Code with Claude 2026 技术分享里，GitHub 首席产品官 Mario Rodriguez 和 Anthropic Claude Platform 产品负责人 Brad Abrams，讲了一件很容易被普通用户忽略的事：当 Copilot 每天处理海量请求，AI 编程的难点已经从“模型会不会写代码”，推进到“平台能不能用可控成本、稳定延迟和可信评测支撑开发者持续工作”。官方会议页把这场定义为 GitHub 如何在聊天、CLI、coding agent、代码审查等表面，把 Claude 送到数百万开发者手里。整场没有产品口号，更多是 GitHub 在真实规模里踩过的坑。
GitHub 先把开发者留在流里
Mario 开场给出 GitHub 给 Copilot 定下的几个产品结果：让开发者保持在 flow 里，让团队获得更高速度，让公司用现有人手完成更多事，并且在规模化时保持效率和信任。Copilot 面对的是 VS Code、CLI、云端 coding agent、IntelliJ、移动端等多个入口，背后还要处理数十亿级消息。当请求量到这个级别，产品经理每天讨论的已经不只是功能列表，而是每一次模型调用会不会打断开发者、拖高成本、破坏信任。
"他们想让员工保持在工作流里，让团队获得速度，让团队用已有的人完成更多事。"
这也是他后面所有技术选择的底层约束。模型要更聪明，但调用它的方式也要足够稳。用户在编辑器里等答案时，平台背后每一次 prompt 组装、工具暴露、上下文压缩和模型路由，都会变成真实体验的一部分。Mario 把这些选择和产品目标绑在一起：如果一个优化只让后台指标好看，却让开发者多等几秒、频繁离开编辑器，它就没有完成 Copilot 的产品目标。
缓存命中率先上桌
Mario 把第一件事放在 prompt caching 上。Copilot 这种量级的产品，哪怕只提升 1% 效率，都可能对应几百万美元成本差异。他把这件事类比成高频交易：百分之一很小，可是乘上数十亿次调用，就会改变整套服务的经济性。AI 产品走到大规模使用后，缓存命中率会从后台指标变成产品能力。
"如果没有 prompt caching，我们会花掉的金额会非常惊人。1% 的效率，对我们来说就是几百万美元。"
他展示的仪表盘会看模型之间的 delta，比如 Opus 4.6 到 4.7 的变化。GitHub 会在模型发布前跑 benchmark，发布后继续盯数据，通常 30 天内完成主要优化，有时更快。缓存命中率如果长期只有 70%，在他们眼里往往已经指向系统 bug。
他还提醒现场听众，所谓 best practices 在这个领域变化太快，很多做法每周都可能被新模型、新 API 或新产品表面改写。GitHub 沉淀下来的是底层学习：先把数据看清楚，再决定该改 prompt、改工具接口、改默认模型，还是改整个 harness。
94% 不是漂亮数字
GitHub 的目标区间很明确：服务要在规模上运行，缓存命中率通常需要在 94%、95%、96% 以上。Mario 还补了一句成本账：缓存输入的价格只有正常输入的大约 10%。如果缓存被不断打穿，同样的输入会变成 10 倍成本。对个人开发者，几次缓存失效可能没有感觉；对 Copilot 这种平台，它会立刻出现在成本表和延迟曲线上。
"如果我们在 70% 运行，通常说明我们有 bug。我们调用模型、组装 prompt、做端到端流程的方式出了问题。"
他提到 4.6 和 4.7 之间 1.3% 的差异也要认真看，因为 GitHub 每天会发出大量调用。这个数字会直接影响默认模型能不能切换、用户等待时间会不会增加、账单会不会失控。缓存输入只有正常输入约 10% 的成本，任何破坏缓存的改动，都会在账单里被放大。
Mario 的讲法很有产品现场感：当 dashboard 上一片红色时，团队没有捷径。50% 到 70% 也许还能靠低垂果实，70% 到 80%、80% 到 90%、90% 以上，就要靠大量工程细节一点点磨。AI 产品进入规模化后，“省钱”不再是财务部门的事，它会决定功能是否能默认开启。
他还把模型默认值和缓存差异放在同一张表里看。默认模型一换，质量、延迟、缓存、成本会一起变化。GitHub 的决策会先看新模型在真实入口里能不能维持开发者的节奏，再决定是否全量。这个过程像发布基础设施，而不是换一个聊天机器人。
UUID 曾经打穿整条缓存
Mario 讲了三个 GitHub 自己踩过的坑。第一，system prompt 的 prefix 里不要放动态内容。他们曾经把 UUID 放进系统提示，每次请求都会变化，缓存被整段重置。第二，工具列表也要稳定。工具如果动态加载，tools prefix 一变，整段对话又会失去缓存。第三，多模型产品要维护 cache affinity：用户可能先调用 Opus，再转到 GPT 模型，又去 OSS 模型，最后回到 Opus，最后一次 Opus 调用仍然要尽量命中同一套缓存上下文。
"你要让 system prompt 尽可能稳定。不要在里面放动态内容。"
这段对正在做 AI 产品的人特别直接。很多团队会把“多给模型一点上下文”当成保险，却没意识到每一段变化都会改变缓存结构。当 agent 能调用更多工具，工具治理、提示组装和回归测试会一起进入核心工程栈。
工具层还有一个常被低估的动作：按 surface 调整工具包。VS Code、CLI、云端 agent、移动端用户需要的工具组合并不一样。工具越多，模型越容易分心，调用链也越难稳定。GitHub 会为具体场景调工具，而不是把一大包能力一次性塞给模型。每个入口都要单独验收，回归测试也要跟上，更稳妥些。
长上下文未必更贵
Mario 还拆掉了一个常见误解：长上下文不一定更贵。他们做过模拟，保持同一个模型和上下文窗口，只改变压缩频率。小窗口会带来更多 compaction，平均压缩次数可能上升三倍。每次压缩又会产生几千个输出 token，输出 token 通常更贵，还会影响缓存命中。
"长上下文窗口并不代表你花得更多。你要理解的是 compaction 怎么发生。"
这给了一个很实用的判断：AI 产品的成本优化不能只盯单次 prompt 长度。上下文窗口、压缩策略、输出 token、缓存命中率，放在一起才是成本曲线。一个看起来“省上下文”的设计，可能因为频繁压缩而花得更多。
开发者使用 agent 时也会碰到同样的账。会话一长，系统开始频繁总结、改写、塞回上下文，原本以为在省 token，最后可能多花了输出 token，还丢掉了细节。Mario 这里给出的经验是按场景管理 compaction，让产品清楚何时该保留长上下文，何时该压缩，何时该开启新任务。上下文策略会直接进入产品体验。
Haiku 旁边坐着 Opus 顾问
第二段由 Anthropic 的 Brad Abrams 接上。他说 Copilot 团队给过一个很朴素的反馈：他们想要 Opus 级别的智能，同时希望价格接近 Haiku。Anthropic 给出的思路是 advisor strategy：让 Haiku 作为 executor 处理大部分任务，遇到自己解决不了的形状、推理或知识点，再调用 Opus 做顾问。Brad 用初级工程师和高级工程师的关系来比喻：高级工程师不需要全程接手，只在关键处看一眼，就能让初级工程师做得更好。
"你可以让 Haiku 这样的执行模型访问 Opus，并且非常保守地使用那些 Opus token。"
现场 demo 里，左边是只用 Haiku 的 GitHub Copilot，右边是 Haiku 加 advisor。面对同一个小谜题，左边还在不断尝试，右边先向 advisor 咨询，Opus 返回一个提示后，Haiku 带着这点上下文完成任务。Brad 的判断很清楚：很小的成本和延迟增加，可以换来接近 Opus 的能力。
这套机制对 Copilot 这样的产品很关键。用户不希望每次都为最高级模型买单，也不希望便宜模型在难题上原地打转。Advisor 把“聪明”拆成可路由资源：简单任务交给执行模型，疑难处短暂借用强模型，再回到低成本执行路径。模型组合开始像团队分工，而不是单模型竞赛。
Rubber Duck 插进三个时刻
GitHub 还在做另一种模型协作，名字叫 Rubber Duck。Advisor 更像顾问，Rubber Duck 更像批评者。Mario 说，他们会把 critique 插进三个位置：写完 plan 之后、完成复杂实现之后、写完测试但还没运行之前。模型先请另一个模型挑刺，再修改计划或实现，最后继续执行。
"我们把 critique 插在三个地方：计划之后、复杂实现之后、写完测试但运行之前。"
这个设计很像把资深 code reviewer 提前放进 agent loop。计划阶段拦一次，复杂实现后拦一次，测试启动前再拦一次。CI 很慢的团队会更在意这件事，因为提前发现方向偏差，比等完整测试跑完再返工便宜得多。AI 编程越自动化，审查点越要前移。
Mario 说 Rubber Duck 已经在 Copilot CLI 的实验功能里。用户可以让它创建计划，并要求它咨询 Rubber Duck。对工程团队而言，这相当于把“先请同事看一眼”的动作产品化：审查动作不必等到 PR 打开；模型刚写完计划时，系统就可以拦住潜在偏差。
新模型上线要跑两套评测
第三部分回到 GitHub 自己的模型上线流程。一个新模型进入 Copilot API 后，团队会改 harness 和 prompt，检查工具接口，调整 agent loop，把更多精力放到上下文管理、compaction 和缓存命中率上。随后他们会跑公开 benchmark、内部 benchmark，也会让 Microsoft 和 GitHub 的开发者做 dogfooding。离线评测给方向，线上实验给细节。Mario 说，模型上线后通常还要花几天甚至几周做 A/B testing 和调参，并且每周向 Anthropic 和内部团队汇报。
"你从线上评测和发布后的线上实验里学到的，往往比离线评测更多。"
最后一个指标也很有产品味：不要只看代码接受率。Mario 更看重 survival rate，也就是用户接受后最终留下来的代码比例。代码当下被接受，却很快被删掉，并没有完成结果。AI 产品如果只优化活动量，很容易把用户带向看似忙碌、实际返工的流程。
这也解释了为什么 AI 时代的产品岗位会变得更重。一个 PM 不能只说“接受率上升了”，还要问：这些代码有没有活过下一轮修改？用户有没有更快完成任务？模型有没有把等待时间、CI 时间、代码审查时间一起降下来？Mario 明确说，AI 时代的产品管理要优化 outcome，而不是单个 row 或单个动作。
这套方法也会改变团队和模型公司的合作方式。GitHub 会把发现写成详细文档，和 Anthropic 一起循环修改 API、checkpoint 或模型行为。新模型发布不再是一键替换，像一次持续数周的联合上线：先接入，再 dogfood，再看线上指标，再把红色的地方一点点调绿。
写在最后
这场分享最利他的地方，是把 AI 编程从“选哪个模型”拉回到工程常识：缓存、评测、工具、上下文、审查点、结果指标。个人开发者可以先记住一个动作：下次让 agent 写代码前，别只问它能不能做，先让它暴露计划、接受 critique，并把成功标准写成最后会留下来的结果。
内容来源："Caching, harnesses, and advisors: Building on Claude at GitHub scale"丨Code with Claude 2026
原视频：https://www.youtube.com/watch?v=y5TmF_6o6xk
如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣
⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣
