📌 一句话摘要

GitHub CPO 在 Code with Claude 2026 上分享了 AI 编程平台规模化后的核心挑战：缓存命中率、评测体系、模型组合策略和工作流设计，而非单纯比拼模型能力。

📝 详细摘要

本文基于 GitHub CPO Mario Rodriguez 和 Anthropic 产品负责人 Brad Abrams 在 Code with Claude 2026 上的分享，深入剖析了 AI 编程平台在规模化运营中面临的实际工程挑战。文章指出，当 Copilot 每天处理数十亿次请求时，核心难点已从「模型会不会写代码」转向「平台能否以可控成本、稳定延迟和可信评测支撑开发者持续工作」。关键内容包括：缓存命中率需维持在 94%-96% 以上，任何微小波动都会带来数百万美元的成本差异；通过 advisor strategy 让 Haiku 作为执行模型、Opus 作为顾问，实现智能与成本的平衡；Rubber Duck 机制在计划、实现和测试前插入 critique 点，将审查前移；以及用 survival rate 替代代码接受率来衡量真实产出。文章还分享了 GitHub 踩过的具体坑，如 UUID 打穿缓存、工具列表动态加载破坏缓存等，为 AI 产品团队提供了极具实操价值的经验。

💡 主要观点

1. AI 编程平台规模化后，核心挑战从模型能力转向工程基础设施。 当请求量达到数十亿级时，缓存命中率、延迟控制、成本优化和评测体系成为决定产品成败的关键，而非单纯比拼模型智能水平。
2. 缓存命中率是规模化 AI 产品的核心经济指标，需维持在 94% 以上。 缓存输入成本仅为正常输入的 10%，1% 的效率提升对应数百万美元差异。GitHub 通过保持 system prompt 稳定、避免动态内容（如 UUID）和工具列表来维持高缓存命中率。
3. Advisor strategy 通过模型组合实现智能与成本的平衡。 让 Haiku 作为执行模型处理大部分任务，仅在遇到复杂问题时调用 Opus 作为顾问，以极小的成本和延迟增加换取接近顶级模型的能力。
4. Rubber Duck 机制将代码审查点前移至 agent loop 中。 在计划完成、复杂实现后、测试运行前插入 critique 环节，让模型互相审查，提前发现方向偏差，减少返工成本。
5. 用 survival rate 替代代码接受率衡量 AI 编程的真实产出。 代码被接受但很快被删除不算有效产出，应关注最终留存下来的代码比例，避免优化活动量而非结果。

💬 文章金句

• 1% 的效率，对我们来说就是几百万美元。
• 要在规模上运行服务，缓存命中率通常要在 94%、95%、96% 以上。
• 如果我们在 70% 运行，通常说明我们有 bug。
• 你要让 system prompt 尽可能稳定。不要在里面放动态内容。
• 你从线上评测和发布后的线上实验里学到的，往往比离线评测更多。

📊 文章信息

阅读完整文章