参考 Aakash Gupta 的 There’s a New PM Skill. It’s Called Taste at Speed，本文探讨 AI 时代产品经理的核心技能转变。

一个被拒绝的 Pull Request

Boris Cherny 加入 Anthropic 后的第一个 PR 被拒绝了。

不是因为代码质量差，而是因为他用手写的。

他的入职导师告诉他：用 Clyde（Claude Code 的内部前身）。Boris 花了半天时间研究这个工具，然后它一次性生成了一个可用的 PR。

那是 2024 年 9 月。

到了 12 月，Opus 4.5 写了 Boris 100% 的代码。他没有手动编辑过一行代码，甚至卸载了 IDE。

今天，Boris 每天提交 20-30 个 PR，同时运行 5 个并行的 Claude 实例。他的团队用大约 10 天时间构建了 Cowork——一个面向非工程师的完整产品。

没有 PRD。没有 Figma。

与此同时，大多数产品团队仍然花 2 周时间让一个需求文档通过评审——而这个功能本可以在一个下午内完成原型、测试和否决。

这两种现实之间的差距每周都在扩大。

而区分这两种产品经理的技能，我称之为快速品味（Taste at Speed）：快速评估可用软件的能力，否决大部分，只发布幸存者。

为什么快速品味是决定性的 PM 技能

从"抄写员"到"作家"的类比

Boris 分享了一个让人深思的类比：

在 1400 年代，欧洲只有不到 1% 的人口识字。有一类抄写员需要多年培训，他们被国王和领主雇佣——而这些国王和领主自己往往也是文盲。

然后印刷术出现了。印刷材料的成本在接下来的 30-50 年里下降了 100 倍，数量在一个世纪内增加了 10,000 倍。

“如果你想想抄写员发生了什么，他们不再是抄写员，但现在有了作家和作者这一类人。这些人现在存在。而他们存在的原因是文学市场大大扩展了。”

现在，把视角转向产品团队。

软件工程师就是今天的抄写员。产品经理就是雇佣他们的"国王"，往往自己不会写代码。

“我想要什么"和"谁能做出来"之间的脱节是 PRD、设计评审、冲刺计划和每一次对齐会议存在的基本协调问题。

当构建成本趋近于零时，这一协调层被压缩了。

瓶颈从"能不能做"转移到"应不应该做”。

PRD 之所以存在，是因为构建很昂贵，你需要在投入资源前获得批准。当一个原型只需要 45 分钟而不是 6 周时，没人需要一份文档来授权探索。

他们需要的是能够实时看着可用软件说"这个，不是那个"的人。

如果有什么变化的话，需求文档现在是在原型之后。

这就是快速品味。

快速品味的核心框架

1. 过滤功能，而非加速功能

快速品味的80% 否决率是关键。

“我一半的想法都是坏的，你必须尝试。你尝试一件事，给用户，和用户交谈，学习，然后最终可能想到一个好主意。有时你做不到。”

没有品味，速度只是意味着你更快地构建了错误的东西。那只是类固醇上的功能工厂。

2. 五种能力的同时激活

Shreyas Doshi 最近关于产品感知的文章指出：AI 工具将商品化。当每个人都有大致相当的 AI 能力时，唯一的差异化因素是应用于 AI 输出的人类判断。

他将其分解为五种技能：

• 同理心（Empathy）
• 模拟（Simulation）
• 战略思维（Strategic Thinking）
• 品味（Taste）
• 创意执行（Creative Execution）

快速品味同时激活这五种能力。

你盯着可用软件，同时运行：

• 同理心（这解决了真正的问题吗？）
• 模拟（规模化后会出什么错？）
• 战略（这符合我们的方向吗？）
• 品味（这是最好的选择吗？）
• 创意执行（我能看到一个 2 倍更好的版本吗？）

3. 速度创造飞轮

每周评估 15 个原型的 PM 比每月评审一个需求文档的 PM 更快地建立判断力。

6 个月后，这种模式匹配的重复量创造了一个品味差距，而且这个差距每周都在扩大。

经验差距 → 品味差距 → 职业差距

每周都在复合增长。

AI 时代的产品开发流程

传统流程（线性）

想法 → PRD → 设计 → 工程构建 → QA → 发布（8-12 周）

AI 时代流程（循环）

想法 → 5 个原型 → 评估 → 否决 4 个 → 为幸存者写需求 → 发布（1-2 周）

需求文档没有消失。它从第 2 步移到了第 6 步。

它出现在你知道要构建什么之后，而不是之前。

快速品味的实战方法

Boris 的工作流程

5 个终端标签页。每个都是仓库的并行检出。他在每个标签页中以 plan 模式启动 Claude Code，在它们之间轮询。

在计划上来回直到正确。然后用 Opus 4.6，实现几乎每次都能一次性完成。

他还每天早上在到办公桌前用手机启动智能体。他可能有三分之一的代码来自 iOS 应用。

关于 plan 模式，他很坦诚：

“Plan 模式可能有有限的寿命。也许一个月后，不再需要 plan 模式。”

这从他嘴里说出来很疯狂。但这符合他的核心理念：不要为今天的模型构建。为 6 个月后的模型构建。

“Claude Code 的所有部分都被一遍又一遍地重写。6 个月前存在的 Claude Code 没有任何部分。”

数据说话

背景：Boris 曾在 Meta 负责代码质量。那里 2% 的生产力提升是"数百人一年的工作"。

如何建立快速品味

阶段 1：工具熟练（第 1-2 周）

目标：让 AI 编码工具成为本能

• 选择一个工具（Claude Code、Cursor、Copilot）
• 每天使用它完成一个真实任务
• 学习提示词工程基础
• 建立个人工作流

阶段 2：原型速度（第 3-4 周）

目标：能在 1 小时内完成可用原型

• 练习"想法到原型"的完整流程
• 学习快速评估技巧
• 建立个人原型库
• 开始记录评估标准

阶段 3：品味训练（第 5-8 周）

目标：建立个人评估框架

• 每周完成 10+ 个原型
• 强制自己否决 80%
• 记录否决原因
• 复盘幸存者特征

阶段 4：模式识别（第 9-12 周）

目标：形成直觉判断

• 建立个人模式库
• 能快速识别"好"vs"坏"
• 能预测用户反应
• 能提出改进版本

PRD 的新位置

什么时候还需要 PRD？

仍然需要：

• 跨团队对齐（>3 个团队）
• 合规/安全审查
• 复杂依赖关系
• 长期项目（>3 个月）

可以简化：

• 单一团队功能
• 快速实验
• 内部工具
• 原型验证后

原型优先的 PRD 模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 功能名称

## 原型链接
[原型演示/截图]

## 用户故事
作为 [用户类型]，我想要 [功能]，以便 [价值]

## 原型评估
- [ ] 解决真正的问题？
- [ ] 技术可行？
- [ ] 符合战略？
- [ ] 比替代方案好？

## 发布标准
- [ ] 功能完成
- [ ] 测试通过
- [ ] 文档更新
- [ ] 监控就绪

## 后续迭代
- V2 想法：...

快速品味的评估框架

原型评估打分卡

决策规则：

• ≥4.0：继续推进
• 3.0-3.9：迭代改进
• <3.0：否决

快速否决检查清单

立即否决：

• 解决的是假问题
• 技术不可行
• 与战略冲突
• 明显劣于现有方案

需要改进：

• 用户价值不明确
• 实现复杂度高
• 与长期方向不完全一致
• 差异化不明显

继续推进：

• 解决真实痛点
• 技术路径清晰
• 符合战略方向
• 比替代方案好 10 倍

给 PM 的建议

DO（推荐）

• ✅ 每周完成 10+ 个原型
• ✅ 强制 80% 否决率
• ✅ 记录否决原因
• ✅ 建立个人模式库
• ✅ 学习 AI 工具
• ✅ 与工程师结对
• ✅ 用户测试每个原型

DON’T（避免）

• ❌ 等待完美需求文档
• ❌ 跳过用户验证
• ❌ 追求 100% 成功率
• ❌ 忽视技术约束
• ❌ 放弃战略思考
• ❌ 成为功能工厂

结语

快速品味不是关于更快地做更多事情。它是关于在正确的事情上更快地失败。

Boris 的故事告诉我们：

当构建成本趋近于零时，产品经理的价值从"协调资源"转变为"做出正确选择"。

这个转变已经在发生。

每周，使用 AI 工具的产品经理和坚持使用传统流程的产品经理之间的差距都在扩大。

6 个月后，这个品味差距将成为职业差距。

问题是：你站在哪一边？

参考资源

• 原文：There’s a New PM Skill. It’s Called Taste at Speed - Aakash Gupta
• Boris 访谈：YouTube
• Claude Code：Anthropic 官方
• 产品感知：Shreyas Doshi
• AI 原型：AI Prototyping Tutorial

本文基于 Aakash Gupta 的文章整理，感谢开源社区的分享。