Anthropic's first technical PM on token maxing, the jagged edge, and living in the future
来源：Lenny's Podcast（2026-07-26，约 1h 34min），Dianne Penn（Anthropic Head of Product for AI Research & Labs，2023 年作为第一个 technical PM 加入时产品团队仅 5 名工程师）访谈。证据定级 medium：Anthropic 是产品供应方，Penn 对 Claude 编码能力的赞美需打折；但 eval-driven 工作流、PM 角色重构、Labs 孵化机制属可独立验证的方法论一手材料。
编译摘要
1. 浓缩
- 核心结论1：Anthropic 产品团队的核心实践是 "evals are the new PRDs"——evals 既是模型评估也是产品定义工具，承担传统 PRD 的需求描述功能；building evals 是 PM 与工程师共同的核心能力
- 关键证据: 完整机制链：用户反馈"claude is not good at following instructions" → 追问到具体轨迹 → 发现 80% 指 JSON schema 失败 → 生成 30-40 个失败样例 → 成为 eval set（prompt + response + golden answer）→ 每版模型运行检查 → 收敛到 99.9%。"you don't need hundreds, just 10 great evals"；PRD 未死，但功能收窄为"让大群人朝同一方向划船的 source of truth"与模糊问题的 product vision 载体。
- 核心结论2：Opus 3 → Opus 4.5 的两次转折揭示"frontier 产品才能释放 frontier 模型"——Opus 3 训练 long-form code（非 autocomplete）是差异化起点；Opus 4.5 的 magic 在于模型与 Claude Code 互为放大器（"wouldn't have had that moment without each other"）
- 关键证据: product overhang / user overhang 概念——当前模型已有大量未被产品化的能力等待发现；emergent capabilities 是不连续跳跃（scaling law 论文中的阶梯图），没有 evals 系统就无法探测跳跃何时发生。
- 核心结论3：TPM 角色定义 = first principles thinking（非 pattern matching）+ 全栈工程师背景 + 产品 taste；管理者必须 hands-on shipping，onboarding 计划对资深 PM 与新人完全相同
- 关键证据: "almost all PMs have either been engineers or ship code here on Claude Code"；designers 都有 frontend engineering 背景（team-level trust + speed multiplier）；hiring 偏好"engineers with great product taste"而非更多 PMs 以减少 shipping overhead；"sweat the tokens as much as you sweat the pixels"；Labs 孵化模式：strong opinion on theme, weakly held on prototype，一个工程师可启动一个 bet，失败 bet 一至两代模型后 revisit。
2. 质疑
- 关于"结论1"的质疑: "evals are the new PRDs" 成立的前提是产品质量可归约为可评测的行为维度；对 UX 质感、品牌、情感共鸣等不可评测维度，evals 无法替代 PRD 的 vision 功能——Penn 自己也承认 PRD 在模糊问题上仍有价值，口号的适用域比表述窄。
- 关于"结论2"的质疑: "模型×产品互放大"是事后归因叙事——Opus 4.5 的成功中模型能力增量、发布时机（冬季假期）、竞品状态都是混杂变量；product overhang 概念有价值但不可证伪（总能声称"还有未发现的能力"）。
- 关于"结论3"的质疑: "PMs 都曾是工程师或在此用 Claude Code ship code" 是 Anthropic 特殊生态的招聘结果，其可迁移性取决于"taste 能否与工程背景解耦"——Penn 视 taste 为 "very rare skill"，恰恰说明该模式难以规模化复制。
- 数据可靠性: 访谈含大量第一手组织细节（5 工程师 → 30-40 PMs、五大 PM 团队分工、GoldenGate Claude 24 小时上线），可信度高；成效性主张需打折。
3. 对标
- 与 Palantir evals 文的 Why/How 配对: Palantir AIP Evals 提供平台基础设施视角（test bench/evaluator/iteration 循环），本集提供 PM 工作流视角（用户反馈 → 失败轨迹 → eval set）。两者共同确立 Evals-as-PRD 命题：evals 同时是工程资产与需求定义载体。
- Model-Introspection 的 PM 应用: Penn 的"读 transcripts 理解失败轨迹——是幻觉？过度自信？tool use 失败？search synthesis 失败？alignment 问题？"是模型自省在用户反馈归因中的系统应用：自省不止用于单次 debugging，而是把模糊抱怨（"claude hallucinated"）转译为研究者可行动的失败分类。
- Token-Maxing 的正面对撞: Garry Tan"愿年花
$100Ktokens = 活在 2028"是 token maxing 的正面表述；Penn 重构框架——token 是 input 不是 ROI 代理，output 是 experimentation，"围绕 experimentation 设目标可能有不同的达成路径"。与库中 Token-Maxing 的成本失控叙事构成 framing 冲突，应并列记录。 - Mechanical-Sympathy-for-LLMs 的管理层版本: Penn"管理者必须 hands-on shipping 一部分时间"与 Martin Fowler 的 LLM 机械同理心同源——对模型能力边界的 theory of mind 只能通过亲手使用获得，不能通过汇报获得。
- 约束分析（3c）: 硬约束——emergent capabilities 的不连续跳跃不可预测，只能被 evals 探测（scaling law 结构）；软约束——PM/engineer 比例、Labs 编制、hiring 标准（组织选择）；自设约束——"PRD 是产品开发的必要环节"被 evals-as-PRD 部分证伪（在可评测维度上）。