即刻App年轻人的同好社区
下载
置顶我真心建议所有年轻人都看看 AI 早期创业公司的机会。
我身边没有一个人意识到，其实在求职时找找 AI 公司的机会，比任何过往的求职都要容易。
这里说的容易，不代表这些公司门槛低，而是你的求职过程“无需许可，不受限制”。
以前，你想去一家好一点的公司，比如互联网大厂、外企、国央企什么，要么是你得毕业于特别好的院校，要么你得在承受繁重学业的同时怒刷实习，要么你得通过各种费用又高、又对实际工作没什么帮助的考试。
因为你需要获得一层又一层既得利益者的“许可”，才能拿到一张入场券。
而各家 AI 公司，看重的都不是你的实习经历和学历背景，看重的是你的作品。
如果你毕业时并没有找到特别理想的工作，又不想屈尊去平庸的公司；又或者你很想去前沿公司实习，见识真正的商业世界和 AI 的时代级机会，你要做的事情其实很简单：
认真研究一下最近流行的 AI 产品、Agent 产品，并且花 1～2 个月的时间，潜下心来创造，和 AI 一起写作，做出一个或几个让你感到自豪的作品。
这个可以是一个上线的桌面端或移动端产品、一个社交媒体、一份独立研究报告，也可以是一篇文章、一个视频。
在这之后，搜集一些你感兴趣的 AI 创业公司，顺着媒体报导、公司介绍和相关的公众号文章，找到创始人的个人社媒账号（小红书、即刻、Bonjour! 名片），带着你的作品去私聊 ta 即可。
这种求职策略之所以有效，是因为在 AI 公司，我们最看重的是候选人的三个特质：
1️⃣ 对 AI 的理解深度
2️⃣ 应用 AI 的实战能力
3️⃣ 是否有 High Agency（高主动性）
当你在和 AI 一起创造一个令人兴奋的作品时，你会自然而然去搜集和研究各种对你创造更有帮助的资料，在这个过程中，你会自然而然地提高对 AI 的理解深度和应用 AI 的实战能力。
而你愿意潜心打磨一个作品，同时能够带着作品直接去找你想去的公司的创始人， 而不是像一个“乖学生”一样傻傻地投简历、等回复，这也体现了你的 High Agency。
所以你看，这是一个对愿意去创业公司的年轻人最好的时代。
即使你高考时没有考到特别好的院校、没有亮眼的职业经历或实习经历、没有行业经验，
只要你找到一个能够暂时让你不用考虑生计的空间（比如回老家待几天），认真拥抱 AI，认真去创造，成为一个 Builder，在你人生的各个时刻，你都能找到好的职业机会。
Bonjour! 最近在认证探索「招聘」这个方向，Bonjour! 的社区里有很多年轻、AI 实战能力强、有才华、有冲劲的年轻人，也有很多品牌和雇主品牌都很优秀的科技公司。
我们觉得将两边能够对接上来是一件非常有社会价值的事情，所以在推进招聘这个方向。
Bonjour! 诞生之初的愿景，就是希望能够将有才华的年轻人，分发到更好的机会上，所以最近对这个方向的推进，让我们很有成就感。
我本人最近聊了非常多家高潜力、正在高增长的 AI 创业公司，每次聊的时候，我都会问创始人或者招聘负责人一个问题：有没有一些人，虽然简历上没有特别亮眼，但是招进来之后表现超预期？
并且追问，这些人是怎么被你们发现，然后通过面试的？
令我惊讶的是，故事都很趋同，大家的策略基本都和我上面写的是一样的。
如果你觉得自己是个有才华的年轻人，或者身边有这样的年轻人，希望能找到一些 AI 领域高潜力、高增长的创业公司机会，请一定让我认识你。
我很乐意和你聊聊，帮他们找到更好的机会，也帮我喜欢的 AI 公司们，找到更多黑马 Builder。
我身边没有一个人意识到，其实在求职时找找 AI 公司的机会，比任何过往的求职都要容易。
这里说的容易，不代表这些公司门槛低，而是你的求职过程“无需许可，不受限制”。
以前，你想去一家好一点的公司，比如互联网大厂、外企、国央企什么，要么是你得毕业于特别好的院校，要么你得在承受繁重学业的同时怒刷实习，要么你得通过各种费用又高、又对实际工作没什么帮助的考试。
因为你需要获得一层又一层既得利益者的“许可”，才能拿到一张入场券。
而各家 AI 公司，看重的都不是你的实习经历和学历背景，看重的是你的作品。
如果你毕业时并没有找到特别理想的工作，又不想屈尊去平庸的公司；又或者你很想去前沿公司实习，见识真正的商业世界和 AI 的时代级机会，你要做的事情其实很简单：
认真研究一下最近流行的 AI 产品、Agent 产品，并且花 1～2 个月的时间，潜下心来创造，和 AI 一起写作，做出一个或几个让你感到自豪的作品。
这个可以是一个上线的桌面端或移动端产品、一个社交媒体、一份独立研究报告，也可以是一篇文章、一个视频。
在这之后，搜集一些你感兴趣的 AI 创业公司，顺着媒体报导、公司介绍和相关的公众号文章，找到创始人的个人社媒账号（小红书、即刻、Bonjour! 名片），带着你的作品去私聊 ta 即可。
这种求职策略之所以有效，是因为在 AI 公司，我们最看重的是候选人的三个特质：
1️⃣ 对 AI 的理解深度
2️⃣ 应用 AI 的实战能力
3️⃣ 是否有 High Agency（高主动性）
当你在和 AI 一起创造一个令人兴奋的作品时，你会自然而然去搜集和研究各种对你创造更有帮助的资料，在这个过程中，你会自然而然地提高对 AI 的理解深度和应用 AI 的实战能力。
而你愿意潜心打磨一个作品，同时能够带着作品直接去找你想去的公司的创始人， 而不是像一个“乖学生”一样傻傻地投简历、等回复，这也体现了你的 High Agency。
所以你看，这是一个对愿意去创业公司的年轻人最好的时代。
即使你高考时没有考到特别好的院校、没有亮眼的职业经历或实习经历、没有行业经验，
只要你找到一个能够暂时让你不用考虑生计的空间（比如回老家待几天），认真拥抱 AI，认真去创造，成为一个 Builder，在你人生的各个时刻，你都能找到好的职业机会。
Bonjour! 最近在认证探索「招聘」这个方向，Bonjour! 的社区里有很多年轻、AI 实战能力强、有才华、有冲劲的年轻人，也有很多品牌和雇主品牌都很优秀的科技公司。
我们觉得将两边能够对接上来是一件非常有社会价值的事情，所以在推进招聘这个方向。
Bonjour! 诞生之初的愿景，就是希望能够将有才华的年轻人，分发到更好的机会上，所以最近对这个方向的推进，让我们很有成就感。
我本人最近聊了非常多家高潜力、正在高增长的 AI 创业公司，每次聊的时候，我都会问创始人或者招聘负责人一个问题：有没有一些人，虽然简历上没有特别亮眼，但是招进来之后表现超预期？
并且追问，这些人是怎么被你们发现，然后通过面试的？
令我惊讶的是，故事都很趋同，大家的策略基本都和我上面写的是一样的。
如果你觉得自己是个有才华的年轻人，或者身边有这样的年轻人，希望能找到一些 AI 领域高潜力、高增长的创业公司机会，请一定让我认识你。
我很乐意和你聊聊，帮他们找到更好的机会，也帮我喜欢的 AI 公司们，找到更多黑马 Builder。
136 947
6 10
最近沉迷 YouMind，token 消耗量相比之前大了非常多，养成了些新的、能大幅提高效率的工作习惯，分享一下：
1. 如果一个任务要做两次以上，先让 Agent 通过 skill creator 帮我先做成一个 Agent skill。
2. 执行任务时，用这个 skill 去做执行，效果不一定一下子能让人满意，还需要多轮对话去调。
3. 调到差不多满意的时候，会让 Agent 自己总结一下我在对话中提出的要求、指出的 bad case，并且用这些来迭代这个 skill，以此对一开始生成的 skill 做第一轮优化。
4. Agent 最后的产出我通常自己会改一遍，改之前先复制到文档上存一个版本，改完后再存一个版本。
5. 定稿后，直接把修改前和修改后的两个版本发给 Agent，直接让 Agent 自己分析出两个版本有什么不一样，为什么要这样修改，并且总结理由告诉我。
6. 我再用 Typless 语音告诉 Agent 它说得哪里正确、哪里不对，并让它基于这个对一开始做的 skill 做第二轮的优化。
7. 在日常听播客、刷 X & 即刻 & 小红书 & 公众号的过程中，如果看到有什么和这个 skill 背后关联的一系列任务相关的经验贴，会直接发给 Agent，让 Agent 学完之后迭代自己的 skill。
以此作为第三轮迭代。
这个逻辑到不新颖，其实本质和招人、管人、培养人是一样的。
招了个不错的 -1，让 ta 做一个相对复杂的任务前，最好先把自己的思路写个方案，然后和 ta 快速过一遍这个方案。
方案定了之后，ta 去执行，执行完之后，最终产出向你同步一下，你做一些细节修改，讨论后定稿，定稿后和 ta 说明为什么这么改，原理是什么。
日常刷到和任务有关的内容，会分享给 ta，和 ta 讨论基于这篇内容里的经验和知识，我们下次做某个项目时可以怎么做得更好。
不同的是，这个过程和人类进行还挺多磨损的，和 Agent 进行摩擦力几乎为 0。
养成这个习惯后，最近写了大大小小十几个 skill 了，下次有空时，找个机会写点新的内容一一分享一下这些 skill 的用法和背后的思考。
1. 如果一个任务要做两次以上，先让 Agent 通过 skill creator 帮我先做成一个 Agent skill。
2. 执行任务时，用这个 skill 去做执行，效果不一定一下子能让人满意，还需要多轮对话去调。
3. 调到差不多满意的时候，会让 Agent 自己总结一下我在对话中提出的要求、指出的 bad case，并且用这些来迭代这个 skill，以此对一开始生成的 skill 做第一轮优化。
4. Agent 最后的产出我通常自己会改一遍，改之前先复制到文档上存一个版本，改完后再存一个版本。
5. 定稿后，直接把修改前和修改后的两个版本发给 Agent，直接让 Agent 自己分析出两个版本有什么不一样，为什么要这样修改，并且总结理由告诉我。
6. 我再用 Typless 语音告诉 Agent 它说得哪里正确、哪里不对，并让它基于这个对一开始做的 skill 做第二轮的优化。
7. 在日常听播客、刷 X & 即刻 & 小红书 & 公众号的过程中，如果看到有什么和这个 skill 背后关联的一系列任务相关的经验贴，会直接发给 Agent，让 Agent 学完之后迭代自己的 skill。
以此作为第三轮迭代。
这个逻辑到不新颖，其实本质和招人、管人、培养人是一样的。
招了个不错的 -1，让 ta 做一个相对复杂的任务前，最好先把自己的思路写个方案，然后和 ta 快速过一遍这个方案。
方案定了之后，ta 去执行，执行完之后，最终产出向你同步一下，你做一些细节修改，讨论后定稿，定稿后和 ta 说明为什么这么改，原理是什么。
日常刷到和任务有关的内容，会分享给 ta，和 ta 讨论基于这篇内容里的经验和知识，我们下次做某个项目时可以怎么做得更好。
不同的是，这个过程和人类进行还挺多磨损的，和 Agent 进行摩擦力几乎为 0。
养成这个习惯后，最近写了大大小小十几个 skill 了，下次有空时，找个机会写点新的内容一一分享一下这些 skill 的用法和背后的思考。
79 848
「产品经理」真是个好词，这个词听起来太体面了，以至于从互联网行业到 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 产品经理的，大家招这一类人才都招得挺头疼。
多多让自己被看见，好的机会兴许会直接找上门来。
目前，大把大把想加入 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 产品经理的，大家招这一类人才都招得挺头疼。
多多让自己被看见，好的机会兴许会直接找上门来。
33 29
