当AI生成产品愈发普及，「AI垃圾」——那些看起来廉价、体验生硬、令人出戏的自动化界面——正在悄然占据我们的视野。无论是千篇一律的内容推荐，还是一眼就能识别的通用UI，用户在这些AI驱动的产品中感受到的，不再是流畅的体验，而是一种「被敷衍」的疏离。为什么会这样？Ravi Mehta，Tinder前首席产品官、现AI产品顾问，在最近一次公开谈话中直指核心：「最常见的原型开发误区，是只关注功能和提示，而没有从360度的『上下文』视角审视AI产品。结果就是，AI生成的东西总有一股『AI味』，难以实现真正的产品级体验。」
AI原型开发的「AI垃圾」困境
假设你是一名产品经理，计划为自家音乐流媒体产品增加一个新功能：用户可以浏览特定音乐流派的进化史页面。你打开AI原型工具，简单描述一下需求：「请为Down Tempo流派生成一个详情页，包含流派介绍、代表艺术家、按年份排序的重要专辑列表。」AI很快就给出成品，页面结构合理，文案流畅，甚至还自动补充了一些音乐知识。看似省时高效，但当你试图用这个原型与用户沟通时，却发现用户很难真正带入情境，他们总是跳出来讨论「如果有专辑封面就好了」「为什么这个页面看起来很假」之类的问题。你原本希望用原型帮助产品决策，却只收获了一堆与功能无关的质疑。
这正是AI原型开发的典型陷阱：只关注Prompt（提示）和功能，而忽视了更广义上的「上下文」。Mehta将这种现象称为「流水线式思维」的残留——过去我们习惯于把需求拆解成一个个小步骤，交给AI逐一完成，却忽略了AI模型要想生成高质量结果，必须理解并融入产品的多层次上下文。要走出「AI垃圾」困局，就必须转向他提出的「三层上下文」方法论。
什么是Context Engineering？
Mehta提出，「Context Engineering」本质上是为AI模型系统性设计和构建其完成任务所需的正确信息和工具。与传统的Prompt Engineering只关注如何写好「提问」不同，Context Engineering要求我们像搭建一套完整的工作环境那样，提供AI模型所需的所有关键要素，包括功能目标、视觉规范、数据结构等。
他强调：「如果只有spec没有线框图，就像建筑师只写备忘录不画蓝图一样荒唐。」真正高质量的AI产品开发，需要将AI视为团队成员，为其搭建好「上下文舞台」，而非仅仅扔给它一份需求清单就期待魔法发生。
三层上下文框架拆解
Mehta将AI原型开发的上下文，系统性地拆解为三个层次：功能性上下文、视觉上下文和数据上下文。每一层都对应着AI产品实现的关键维度，三者相辅相成，缺一不可。
一、功能性上下文：定义「做什么」的任务目标
最直观的上下文层是功能性上下文。它体现为一个简明的描述，类似「mini spec」，明确告诉AI需要完成什么样的产品任务。
以音乐流媒体产品的流派详情页为例，一个合格的功能性上下文应该包含：
- 目标：生成Down Tempo流派的详情页
- 结构：包含顶部大图（Hero Image）、流派名称、代表艺术家标签、按年份排序的重要专辑列表
- 每个专辑的细节：专辑封面、名称、发行年份、简要说明其在流派中的地位
这一层的关键在于「清晰、具体」，让AI理解你希望它「做成什么样」。Mehta指出，很多原型失败的根本原因，是这个层次的信息缺失或含糊，导致AI只能猜测你的真实意图，最终生成的内容要么过于模板化，要么遗漏关键细节。
但仅有功能性上下文还远远不够。正如他所说：「如果只有spec没有线框图，就像建筑师只写备忘录不画蓝图一样荒唐。」产品的体验远不止功能罗列，视觉和数据同样是决定成败的关键。
二、视觉上下文：塑造「看起来像什么」的真实感
视觉上下文要求你为AI提供产品的视觉规范或实际界面元素。这一层决定了原型成品的「质感」——用户一眼能否把它当成真实产品，而非廉价的AI拼贴。
音乐流媒体案例中，视觉上下文可以包括：
- 设计系统的引用：品牌色、字体、间距、卡片样式等
- 具体的UI组件说明：「专辑列表使用封面+文字组合卡片，卡片间距为16px」
- 示例图片或线框图：上传一组真实的专辑封面图片，或提供Figma线框
Mehta强调，AI生成的内容越强大，「品味」就越重要。「字体、间距、文案，才是区隔AI垃圾和好产品的关键。」过去这些细节由设计师手工把控，现在则需要通过视觉上下文提前固化进AI的工作流程。否则，即使功能正确，成品仍然会让用户一眼识破其「AI出品」的生硬感。
以音乐流派详情页为例，如果只给AI描述「展示专辑列表」，AI很可能返回一长串文字列表，毫无层次；但如果补充「每个专辑用卡片形式展示，卡片中包含专辑封面、标题、艺术家，采用品牌主色调高亮」，且上传几张风格统一的专辑封面，成品的真实感会大幅提升。用户不再关注「这里怎么没有封面」，而是更自然地讨论页面结构与信息层级，这才是原型的真正价值。
三、数据上下文：控制「内容是什么」的可复用性与灵活性
数据上下文是许多团队忽略的一环，却是打造可扩展、可复用AI原型的核心。它指的是产品中实际呈现的数据内容——无论是静态样本数据，还是接口返回结果，都应结构化地提供给AI。
在音乐流媒体原型中，数据上下文可以用JSON、CSV等格式明确列出：
{
"genre": "Down Tempo",
"artists": ["Artist A", "Artist B", "Artist C"],
"albums": [
{
"title": "Dream Scape",
"artist": "Artist A",
"year": 2015,
"cover_url": "https://example.com/dreamscape.jpg",
"description": "A landmark album in the genre's modern era"
},
...
]
}
这样做的最大好处，是你可以随时替换数据集而无需重写Prompt或调整视觉规范。Mehta在实际演示中，将数据文件从「Down Tempo」流派切换到「Psychedelic Rock」，只需替换一份JSON文件，原型工具即可自动生成全新的页面。这种「模块化」的数据上下文，使原型开发从「一次性拼装」转变为「高度复用」，极大提升了团队效率与创新空间。
Mehta形象地总结这一转变：「我们从流水线转变成了爵士乐团。」过去AI产品开发像工厂装配线，按部就班，强调流程和标准化；现在则更像爵士乐队，团队成员（人类和AI）在同一舞台下即兴协作，灵活融合各自的能力，创造出不断变化的新体验。数据上下文正是实现这种灵活协作的基础。
多工具协作与Context分层的实际流程
在理想的Context Engineering流程中，团队会选择不同的工具来分别处理不同层次的上下文。例如，利用Claude等大模型编写功能性Spec，Figma或自家设计系统输出视觉规范，再用Notion、Airtable等管理结构化数据。最后，这三层上下文被有序整合进AI原型工具，由AI按「剧本」和「场景」组装成高保真的产品体验。
这种分层、分工的做法有两个显著好处：
- 极大提升原型的真实感与可用性：产品团队、设计师与AI各司其职，原型成品既能反映真实功能，又能还原视觉细节，还能灵活适配不同数据场景，有效推动决策进程。
- 为AI原生创新提供土壤：通过模块化的上下文管理，团队可以更快试错、探索多种创新方向，无需每次都从头开始搭建新原型。这也符合Mehta的判断：「判断是否真正AI原生工作的标志，是你有没有创造出大量最终没发布的东西。」大量原型的快速产出与废弃，是AI原生创新环境的常态。
AI原生工作方式的本质
从Prompt Engineering到Context Engineering的转变，不只是工具和流程的升级，更是产品开发范式的革命。AI的强大能力让我们可以低成本、大规模试验产品创新，但只有将功能、视觉、数据三层上下文系统性地交付给AI，才能真正释放这种潜力，打造出既有「灵魂」又有「品味」的AI原生产品。
在这个过程中，产品经理和设计师的角色也发生了深刻变化。过去他们像工厂的工头，负责把控每一道工序；现在则更像爵士乐团的指挥，负责搭建舞台、设定基调、调动团队与AI即兴发挥。正如Mehta所说：「AI越厉害，品味越重要。」未来的AI原生产品，决定成败的不再是技术本身，而是团队对上下文的把控力——你能否为AI设计出一个理解力、表现力、数据力高度协同的工作环境。
流水线的时代已经过去，新的「上下文工程」时代正在开启。AI不再是冷冰冰的工具，而是能与人类协作、不断演化的创造伙伴。掌握三层上下文，正是产品团队在AI原生时代保持竞争力的关键。