给大家推荐一下这期访谈，前 Tinder 的 CPO，现在是全职的 AI 产品顾问+“vibe coder”。

他对 AI 原型设计的理解，可能比大多数产品经理都要深。

这期访谈里，他现场演示了如何用三层上下文系统来构建一个音乐流媒体应用的原型，以及为什么你的 AI 原型总是看起来非常AI味？

1

Ravi 提出了一个很关键的概念转变：别再说 prompt engineering 了，应该叫 context engineering，也就是上下文工程。

他的定义是：上下文工程就是设计和构建系统，为 AI 模型提供完成任务所需的正确信息和工具。

你不能再像以前那样，随便写几句话或者一个迷你需求文档，就指望 AI 原型工具能做出和你以前手工设计一样高保真的东西。

Ravi 说他看到最常见的错误就是：大家没有用360度全方位的视角来思考上下文。结果就是，产出的原型质量很低，根本没法用来做决策或者拿给用户测试。

这让我想起自己之前做原型的经历。确实，很多时候就是一句话 prompt 加几张截图，做出来的东西基本都是一次性的。

但 Ravi 的观点是：如果你把上下文设计好了，后续迭代会容易得多，尤其是当你要在现有产品上加新功能的时候。

2

这是整个访谈的核心，Ravi 把上下文分成三层。

第一层：功能上下文

这个最好理解，就是你用文字描述产品要做什么。

比如他演示的音乐应用，他写了一个类似 mini spec 的 prompt：构建一个 down tempo 音乐类型的详情页，包括头图、类型标题、艺术家标签、按时间线排列的专辑列表等等。

这一层其实就是传统的需求描述，但要足够具体。AI 工具会自动扩展你的 prompt，生成待办清单，然后一步步完成。

结果看起来还不错，但总觉得哪里不对劲，比如没有专辑封面，布局也不够精致。

第二层：视觉上下文

这是很多人忽略的一层。Ravi 用了一个特别好的比喻：你永远不会找一个不会画蓝图的建筑师来盖房子，对吧？如果建筑师只给你一份备忘录，告诉你房子有哪些房间、多少平米，你敢直接开工吗？肯定不敢。

软件也是一样的，它是二维的视觉体验。所以你需要线框图（wireframe）来真正理解需求是怎么被渲染成具体体验的。

Ravi 在 Figma 里花了20分钟画了个线框图，然后直接把图片上传给 AI 工具，配上简单的 prompt：用深色主题、圆角按钮、这些颜色。结果出来的原型就明显更符合他的设计意图了，响应式布局也处理得更好。

第三层：数据上下文

这一层是真正的杀手锏，Ravi 的做法是：先在 Claude 里生成一个 JSON 文件，包含音乐类型的描述、代表艺术家、15-20张里程碑专辑的信息（专辑名、发行日期、艺术家、简介、标签）。

他还在 Claude Code 里自己搭建了一个 MCP 服务器，专门用来获取专辑封面的 URL。这样生成的数据不仅结构完整，还有真实的专辑封面图片。把这个 JSON 文件直接粘贴到原型工具里，AI 就能理解数据结构，自动设计出合理的用户界面，包括搜索、排序、标签筛选等功能。

最关键的是，因为数据是独立的文件，你可以随时替换。

想测试 psychedelic rock 而不是 down tempo？直接换个 JSON 文件就行，整个原型立刻变成新的内容。

这种模块化的设计，让原型变得超级灵活。

3

当你把功能上下文、视觉上下文、数据上下文全部整合到一个 prompt 里，奇迹就发生了。

Ravi 用 Markdown 结构化了他的 prompt，清晰地标注了每一部分：功能需求写在前面，附上线框图，指定配色方案，然后粘贴完整的 JSON 数据。

最后生成的原型，既符合他的设计意图，又有真实的数据和精美的专辑封面，看起来就像一个真正的产品，而不是 AI 生成的 demo。

他说这种原型才能拿给用户测试，因为它足够真实，能让用户产生“代入感”。

用户会谈论他们正在做什么，而不是理论上会做什么。

这两者的区别，直接决定了你能获得多高质量的用户反馈。

4

Peter 问了一个很实际的问题：既然 AI 让编码变得这么容易，为什么 PM 还要做原型，而不是直接提交生产代码？

Ravi 的回答很清醒：原型的价值在于灵活性。就像艺术家在正式创作前会画很多草图和习作一样，原型让你可以不受现有系统和数据的束缚，快速探索解决方案空间。

如果你已经很清楚要做什么，并且愿意处理生产代码的复杂性，那当然可以直接写代码。但大多数时候，你需要先探索，而原型就是最好的探索工具。

至于 PRD 是不是过时了？Ravi 说没有，只是顺序变了。

以前必须先写 PRD 再做设计，现在可能先做原型，然后再写 PRD 来解释问题、目标、指标和长期战略。每个文档都有自己的作用，但不再是严格的线性关系。

AI 工具确实降低了原型设计的门槛，但这不意味着你可以偷懒。恰恰相反，你需要更系统地思考上下文，更认真地准备数据和视觉素材。

Ravi 的三层上下文系统，本质上是把传统的产品开发流程（需求、设计、数据）压缩到了10分钟的瀑布流程里。你还是要做这些事，只是速度快了100倍。

另一个启发是：好的原型不是为了炫技，而是为了做决策。如果原型能让用户产生代入感，让团队快速对齐，那它就是成功的。

而要做到这一点，你必须在细节上下功夫，不能让 AI 的懒惰毁了你的作品。