「产品经理」真是个好词，这个词听起来太体面了，以至于从互联网行业到 AI 行业，产品经理一直是很多喜欢科技的年轻同学意向非常高的岗位。 目前，大把大把想加入 AI 行业找工作的年轻人，都会想从事这个岗位。 但大家对这个岗位的标准还是很模糊。 有的人会用传统产品经理的评价维度，去判断自己是否适合成为一个 AI 产品经理。 有的人则觉得只要 AI 用得好，跟大模型、Agent 们聊得熟，用过很多 AI 产品，就是一个好的 AI 产品经理了。 这两种看法其实都不对。 一个人是不是好的 AI 产品经理，虽然刚刚那两个因素是必要的，但其实还有三个新的技能是你需要学习的，分别就是原型、Benchmark 和 Eva。 1️⃣ 原型 以前由于 AI 写代码还没有 Vibe Coding 这件事情，你要开发一个产品，它的标准流程是：产品经理先出需求文档（PRD），盘点一下为什么要加这个功能，以及具体交互逻辑是什么样的。 拿需求文档和 UI 设计师对设计排期，和研发对开发排期，最后把这些都加到整体项目排期里。 UI 设计师基于需求文档提供高保真原型，最后给到研发，研发根据高保真原型开发前端页面和后端接口。 这条链路很长，每个环节都需要沟通和等待。 一个简单的功能，可能要花两三周才能看到真实效果。 但现在 AI 来了，AI 的写代码能力足够强之后，产品经理与其写个 PRD 再跟这么多岗位沟通，不如直接基于产品的各种组件写一个单独的网页页面。 这个网页页面是可以交互的，产品经理可以直接在上面验证功能的交互逻辑，确认功能是否必须添加，以及具体的展现位置。 接着，产品经理把这个网页原型及背后的代码交付给工程师，工程师再把它融合到原有的产品里。 这样的效率会比从“原型图到低保真，再到高保真，最后到产品”的速度快很多。 很多 AI Native 的公司现在都是这么做的。 这对工程师来说也挺友好，现在很多 AI Native 公司的员工都在用 Cursor 和 Cloud Code 这种 Coding Agent 来写代码。 产品经理出的交互原型里自带了产品的交互逻辑，虽然这段用来做原型的代码，没办法直接用到生产环境， 但是，产品经理在让 AI 把交互逻辑确定好、在自己的原型上实现想要的交互之后，可以顺便让 AI 根据代码反向写一份需求文档。 这份需求文档都不用给人看，是一份完全给 AI 看的 Markdown 格式的文档。 当工程师想实现相应的功能时，直接把这份需求文档作为参考文件给到他们自己的 Coding Agent，AI 就可以很好地理解这个逻辑并快速实现功能。 工程师们只需要再做一些工程上的优化，保证不出问题就行了。 所以 Vibe Coding 算是新时代的 AI 产品经理的基本功了。如果一个 AI 产品经理没有任何 Vibe Coding 的技能，是没办法用这种新的工作方式去配合产研团队工作的。 2️⃣ Benchmark（标准） Benchmark 可以简单地理解成大模型的评价标准，相当于大模型 AI 产品（Agent）输出的评价标准。 举个例子，假设有一家公司做了一款通用医疗健康相关的 Agent 产品，用户的平常使用场景包括： 咨询健康问题，它能给出非常专业且有针对性的建议； 列出健康计划，它能基于用户的身体情况，保证该计划对用户来说是真正有益的； 进行病情检查，这款医疗产品能通过多轮对话的方式获得用户的关键信息，然后给出专业、详细的诊断。 如果做这么一款产品，该如何评价这款医疗健康 Agent 每次的输出是好还是坏？ 这里我们就需要一套标准，这套标准也就是所谓的 Benchmark。 拿健康咨询这个场景来说，Benchmark 可以包含四个评价维度： 1. 专业性（回答是否符合医学常识，有无明显错误） 2. 针对性（是否根据用户具体情况给建议，还是泛泛而谈） 3. 安全性（是否避免过度诊断，有无提示就医边界） 4. 可操作性（建议是否具体可执行，用户能否立即行动）。 每个维度可以打 0-10 分。 病情检查场景的 Benchmark 又是另一套： 1. 信息采集完整度（是否通过多轮对话获取关键症状、病史、用药情况） 2. 诊断逻辑清晰度（推理过程是否可追溯，用户能否理解） 3. 就医引导准确性（是否明确告知需要挂什么科室、做什么检查）、免责边界（是否清楚说明这不是正式诊断，需医生确诊）。 用户说：“肚子疼了两天。”好的回答是依次询问疼痛位置、性质、伴随症状、饮食情况，最后给出可能原因和就医建议。差的回答是直接说“可能是胃炎，吃点胃药”。 可以看到，不同的使用场景需要不同的 Benchmark。这套标准的设计，直接决定了产品后续的迭代方向和开发后续。 3️⃣ Eva（评测） Eva 就是 Eval（评测）的简称。 OpenAI 的首席产品官 Kevin Weil 说过一句话：“Writing evals is the most important thing a PM can do in the AI era.”（在 AI 时代，写 eval 是 PM 能做的最重要的事。） 为什么 Eval 这么重要？因为传统的 PRD 在 AI 产品上失效了。 传统产品开发是一条直线：问题 → 需求文档 → 设计 → 工程 → 上线。写个 spec，按 spec 做，验证 spec。 但 AI 产品不是这么玩的。同一个 prompt 每次跑出来的结果都不一样。 一句“模型应该有帮助且简洁”写在 PRD 里，太模糊没法执行，太含糊没法验证，太静态跟不上模型的变化。 PRD 是为确定性世界设计的。AI 产品的世界是非确定性的。 那 PRD 该被什么取代？答案就是 Eval——结构化、可重复、自动化的产品质量评测。Eval 替代 PRD，成为 AI 产品经理的核心交付物。 Benchmark 定义了“好”的标准，包括评价维度和打分规则。 Eva 是把 Benchmark 落地成可执行、可重复的测试系统。 可以这样理解：Benchmark 是考试大纲，Eva 是具体的试卷和阅卷系统。 Eval 的本质是用代码定义“好”是什么样子。它把 Benchmark 的每个评价维度转化为可测试的信号。 Eval 同时扮演三个角色：它是产品规格（定义目标）、验收标准（衡量通过/失败）、产品路线图（指向下一步该改进什么）。一份 eval 抵三份文档。 假设你在做一个从烹饪视频生成食谱的功能，PRD 写着“要有帮助且准确”。这句话有什么用？什么都没有。 但如果你先定 Benchmark：格式规范性、信息完整性、可读性。再把 Benchmark 拆解成三个可衡量的信号： 格式：食材在前，步骤在后。用 AI 评审员 Agent 按评分标准打分。 食材完整性：视频里提到的食材是不是都包含了。用确定性字符串匹配验证。 步骤简洁度：步骤是不是简短易扫。用 AI 评审员，用好/差示例校准。 三个信号，一座山。 你不再跟工程师说“把它做好”，而是交出一个 eval 说：“把这个数字提上去”。 以及，对于 AI 产品经理来说，写出第一个 eval 并不难。难的是建飞轮。 飞轮有四个阶段： Observe（观察）：记录每一次输入、输出、trace 和失败。你没法改进你看不到的东西。 Analyze（分析）：找模式。什么在坏、在哪坏、为什么坏？观测数据变成产品洞察。 Evaluate（评测）：把发现的失败模式变成新的 eval case。每一个线上故障都是 eval suite 的候选。必要时，还要调整 Benchmark 标准本身。 Improve（改进）：针对更新后的 eval suite 做 hillclimbing，上线，然后重复。 这个循环会自我加速。更多线上数据 → 更好的 eval → 更好的 AI → 更好的产品 → 更多用户 → 更多线上数据。 线上失败不仅变成测试用例，还会反向优化 Benchmark 本身。 那么，这三个技能在实际工作中是如何配合的？ AI 产品的设计和迭代过程中，我们会日常需要高频地解决这么几个问题： 问题 1：如何让用户方便地同步 context 在这里很多产品做了很好的设计。 比如 AI 创作产品 YouMind，它有一个类似于知识库的文件目录。同时它还有一个浏览器插件，能够剪藏你日常在浏览器上阅读的各种内容。 当你想要将一些信息同步给 agent 的时候，可以直接 @ 某篇具体的文档。这样你写过的内容，或者你收藏的、值得大模型参考的内容，就可以非常方便地发给 agent。 这个环节考验的是原型技能，产品经理需要用 Vibe Coding 快速做出可交互的原型，验证 @ 引用、文档目录、浏览器剪藏这些交互方式是否真的方便用户。 问题 2：如何让模型的输出足够好 这个“好与不好”没有绝对标准，它是基于不同类型的 agent 产品，服务不同的人群、解决不同类型的问题来判断的。 有的人让 AI 写一份报告，是希望看到尽可能全面、广度足够广的内容。 有的人则希望得到精简精炼的结论，以及支撑结论的论据。他希望报告字数不要太多，否则看不完。 这两类产品就要设计不同的交互方式和 Benchmark。 问题 3：如何评价产品质量 在产品开发完毕后，怎么判断做得到底好不好？后端搭建的那套大模型相关算法和 agent 工作流输出的内容质量怎么样？ 这就需要用 Eva（评测集） 去测。不同类型产品的评测集是大不相同的。一款给小白创作者的写作产品，和一款面向专业编剧的创作产品，以及同时面向这两类人的通用型 agent 产品，它们的评测集会大不相同。 这三个技能整合到一起，AI 产品经理的每周工作节奏就变成了这样： 周一：观察线上数据，标记 20 个不达标响应，分析用户使用场景和痛点。这是 Eva 飞轮的 Observe 阶段。 周二：基于问题类型，判断是否需要调整 Benchmark 标准。提炼 5 个新 eval case 加入测试集。这一天同时用到了 Benchmark 和 Eva 两个技能。 周三：跑完整 eval suite 对比上周模型和本周候选。必要时用 Vibe Coding 快速做原型验证新交互方案。这一天用到了 Eva 和原型两个技能。 周四：看数据决定发布，确认 Benchmark 各维度得分是否达标。这一天再次用到 Benchmark 和 Eva。 周五：飞轮又转快一圈，三个技能的配合让产品持续进化。 这些都是需要 AI 产品经理基于复杂情况做出复杂判断的，也是比较考验 AI 产品经理职业素养的地方。 如果你还在用传统产品经理的方式做 AI 产品，或者最近在看 AI 产品经理的机会，可以试试从一个功能开始： 用 Vibe Coding 做个原型，为这个功能设计 Benchmark，写出第一个 eval suite。不需要很复杂，甚至可以从一个 spreadsheet 开始——列出 20 个输入 case，手动标记期望输出，跑一遍看通过率。 然后从那里往前走。 每次线上出了一个坏 case，加进 eval suite。每次换模型、改 prompt，跑一遍 suite 看有没有退步。 记得这个过程要多做记录，多留文档。 如果有精力的话，录几个像张咋啦 Zara 那样的视频发出来。 AI 这行还挺缺这种类型的新型 AI 产品经理的，大家招这一类人才都招得挺头疼。 多多让自己被看见，好的机会兴许会直接找上门来。