AI 基础设施化：效率、评估与网关成为产品经理的新战场

OpenAI 用量修复与效率之年：当模型成为关键基础设施

OpenAI 的 Thibault Sottiaux（Codex & ChatGPT @OpenAI）在 8 月 24 日发帖说：“Good Sunday. Reset has been propagated to accounts and we landed some fixes to usage... You should feel a positive difference. More to come tomorrow and will keep communicating.” 同一天他另一条帖子断言：“2026 is the year companies start seriously caring about model efficiency and reliability as it becomes critical infrastructure”，，模型正成为关键基础设施，效率和可靠性成为企业真正开始关心的事。

产品经理视角：用量波动的修复是表层，底层是模型进入核心业务后，效率和可靠性不再是工程问题，而是商业承诺。如果你还在用“加预算”应对 token 消耗，明年你会被成本结构拖垮。现在就该把每 1000 token 的服务成本作为产品指标，而不是运营数字。

Sol 降价引爆需求：网关成为必然的中间层

Vercel CEO Guillermo Rauch 在 8 月 23 日发帖说：OpenAI Sol 的价格削减和 Vercel AI Gateway 上的折扣让 Sol 成为他们增长最快的前沿模型。他给出两个结论：① 智能的需求弹性很高，，推理成本下降，使用量快速增长；② 如果你不用网关，就错过了这种惊人的价格波动，这能降低你的运营成本、提高利润率。他还说“gateways are inevitable”。

编辑观察：这是“智能通货紧缩”的直接证据。模型调用价格不是缓慢下降，而是剧烈波动。你在架构上是否接了网关层？如果没有，你等于在裸奔，既要付全价，又不能快速切换更便宜的模型。产品经理现在就该做模型路由的单元测试，而不是等成本爆了再救火。

eval 的金发姑娘原则：不要只测最终答案

Meta 的 AI 高级总监 Madhu Guru（曾在 Google 领导 Gemini、Veo、Nano Banana）在 8 月 24 日发帖“How to build great evals - part 7”：构建 eval 时应该测量“各种待完成的工作（jobs to be done）”层面，而非只看最终答案。他举例：金融分析 agent 的最终输出是股票推荐，但之前有多个阶段：理解客户、收集证据、分析数据、给出推荐。每个阶段都可以有独立的 eval，并在推荐错误时给出分解诊断，例如“客户理解：92%，证据提取：92%，数据分析：70%，推荐：75%”。他说：不要过于细，也不要过于粗，刚刚好，，“Make your eval set as granular as you need to diagnose and act.”

编辑观察：这是 eval 设计的“金发姑娘原则”，但真正反直觉的是：你要为中间输出建 eval，而不是只盯着最终结果。产品经理常犯的错误是只看宏大的成功率，现在你应该要求 agent 的每个重要中间步骤都有可衡量的门。没有中间 eval，你定位问题只能靠猜。

agent 与系统记录之争：要么变成 AI 挽具，要么被取代

Y Combinator 总裁兼 CEO Garry Tan 在 8 月 24 日发帖：“Prediction: systems of record will need to become AI harnesses or face replacement by agents”，，系统记录将需要变成 AI 的挽具（harness），否则将面临被 agent 取代的风险。同一天，Vercel CEO Guillermo Rauch 发布关于扩展 fx 的理念：“open protocols: MCP (modelcontextprotocol.io), Skills (agentskills.io), Plugins (agent-plugins.org). And the best one, Unix：① Small programs that do one thing well and compose by calling other programs. ② libfx that enables embeddability into more complex programs. You should be able to build your own CLI, background agent, software factory. Local or cloud.”

编辑观察：Garry Tan 的预测其实指向一个生存危机：如果你的产品只存储数据而没有 AI 接口，agent 会绕过你。Rauch 的 Unix 哲学是解药，，不是做一个大而全的 AI 平台，而是开放协议 + 可嵌入性。产品经理应该问：我的系统能成为 agent 的“挽具”吗？我是否提供了 MCP 或类似协议，让 agent 能调用我的数据？

AI 产品经理的五个新优先事项

从今天的来源看，2026 年下半年 AI 产品经理的注意力应该从“模型能力”转向“系统属性”：效率、可靠性和可诊断性。Thibault 的效率之年、Rauch 的网关必然论、Madhu 的中间eval、Garry Tan 的挽具预测，四者指向同一个方向：模型不再是新奇玩具，而是关键基础设施。

这会让你的产品路线图多出三类工作。一是成本弹性，，利用网关层，设计随价格波动的模型路由策略，而不是绑定单一供应商。二是中间可观测性，，为 agent 的每个重要阶段构建 eval，让失败定位从“猜”变“查”。三是协议开放性，，提供 MCP 或类似的接口，让自己成为 agent 生态的一部分，而不是被绕过。

另一个更具体的数字：Rauch 说 Sol 是增长最快的模型，这反直觉地说明，降价不只是促销，而是一种需求发现机制。你在定价你的 AI 功能时，可以考虑更激进的按量定价，因为需求是高度弹性的。

最后，Garry Tan 的预测对做 SaaShou 的公司是警钟：如果你的系统记录只是被 AI 读取，而不是被 AI 协同使用，你离被取代不远了。挽具不是 API 文档，而是让 agent 能完成完整任务的界面。

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

今天就可执行的中间 eval 诊断清单

适合正在开发 agent 产品（如财务分析、客服、写作助手）的产品经理和技术负责人。前提是：你的 agent 有明确的中间输出（比如收集信息、分析、建议）。这个方法帮你把模糊的失败变成精确的修复。

你是一位资深 AI 产品经理。请针对我的 agent 工作流生成一个中间 eval 诊断清单。工作流分为四个阶段：1) 理解用户需求，2) 收集必要信息，3) 分析并生成候选结论，4) 输出最终答案。对于每个阶段，请定义：一、可测量的中间输出标准（例如：用户需求理解是否包含关键约束；信息收集是否覆盖所有数据源；分析是否考虑变量 X）。二、建议的 eval 指标（如准确率、覆盖率）。三、可能的失败模式（如忽略用户风险偏好、信息来源过时）。要求给出分阶段的 eval 构建步骤，并推荐一个诊断报告格式，能让我在最终答案错误时，快速定位是哪个阶段出了问题。不要泛泛而谈，要具体到指标名称。

此 prompt 不保证全能。你需要根据自己的 agent 调整阶段定义。eval 的指标设计需要测试，通常至少 3-5 轮迭代。该 prompt 基于来源中的 eval 设计原则，但具体指标需你验证。

AI 原生助手 vs 人类助手

Peter Yang 在 8 月 23 日的帖子（来源 S11）说：他与人类助理 Char（来自 Oceans）合作了 6 个月，他认为最好的助理今天必须知道如何与 AI agent 协同工作。Char 使用 Claude Code 和 Codex 帮他做播客后期、写节目笔记、做片段，还复制了他的 AI 技能并定制化工作流。

这条对你有什么实际价值？当你招人时，不要只看传统技能，要考察候选人的“AI 协作能力”。一个能熟练使用 agent 的助理，可以放大你的产出。这也说明：未来的操作员是“人+agent”的混合体，你的产品应该为这种人设计工作流，而不是假设纯自动。