面向 Agent 时间边界构建

Build For Agent Time Horizon Growth · build-for-agent-time-horizon-growth--benjamin-mann

解决什么问题

在AI能力快速指数增长的阶段,产品团队该按"今天模型能做到什么"来设计产品,还是该按"未来6-12个月模型能做到什么"来设计?这决定了产品会不会一上线就显得落后。

核心内容

Benjamin Mann 讲述了他领导 Anthropic "Labs"团队(后改名"Frontiers",孵化出了 Claude Code 和 Model Context Protocol/MCP)时的核心方法论——"往冰球将要去的地方滑(skate to where the puck is going)":

参照依据是METR机构(CEO为Beth Barnes)做的研究:该研究衡量"AI能可靠完成的软件工程任务的时间跨度(time horizon)"是如何随时间演进的,并绘制出明确的增长曲线。
具体的产品设计原则:不要为"今天能做的事"做产品,要为"6个月后能做的事""1年后能做的事"做产品。当下"只有20%成功率、看起来还不稳定"的能力,要提前假设它会在不久后变成接近100%成功率。
这条原则如何具体转化成Claude Code的产品决策:团队提前判断,人们不会永远被锁在IDE里做autocomplete式的辅助编程,而是会逐渐把"软件工程师需要做的所有事"都交给agent去做。基于这个判断,团队选择把**终端(terminal)**作为核心载体,而不是IDE插件——因为终端可以存在于非常多的地方(本地机器、GitHub Actions、你集群里的远程机器),这种"随处可部署"的杠杆点,恰恰是为一年后的能力水平设计出来的选择,而不是为了适配"今天"的使用习惯。

Mann 把这套方法总结为团队内部的一个自检问题:"我们是不是'AGI-pilled'(足够相信/内化AGI即将到来这件事)得够彻底?"——用来提醒团队不要被当下能力的局限捆住想象力,持续用"往前看几步"的假设去校准产品方向。

适用边界

这套方法的前提是"能力的确会持续指数级增长"这个判断本身是对的;如果某项具体能力的增长曲线提前触顶或放缓,提前构建的产品设计可能会显得超前而不实用;
METR的"时间跨度"研究衡量的是软件工程任务,把这个方法论套用到其他领域(如法律、医疗)时,需要该领域是否有类似的可量化能力增长曲线作为依据,不能直接照搬结论。

关键引述 · 原话

"不要为今天去构建,要为六个月后构建,要为一年后构建。那些现在只有20%成功率的东西,很快就会变成100%成功率。"——Benjamin Mann

— Benjamin Mann

关联卡片

与"build-for-next-model-not-current-limits"(logan-kilpatrick)是同一类"面向未来模型能力做产品设计"的方法论,本卡提供了更具体的量化依据(METR时间跨度研究)和真实产品案例(Claude Code选择terminal而非IDE插件的决策逻辑)。

出处：Benjamin Mann (Anthropic 联合创始人, 产品工程技术负责人) · 03-podcasts/benjamin-mann.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2