即刻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。
131 945
「产品经理」真是个好词，这个词听起来太体面了，以至于从互联网行业到 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 产品经理的，大家招这一类人才都招得挺头疼。
多多让自己被看见，好的机会兴许会直接找上门来。
31 29
团圆炸串店！超好吃的！我们周末连吃了两天！ //@白日梦想家Vivi: 哪家，感觉好吃
泛函: 看 AI 写的心机文案多了，每次遇到这种有活人感的文字都会微微感动。
6 00
Bonjour! 第一次与别人一起办黑客松，欢迎报名！下周上海见！
夜之城的新传奇正在诞生｜自我进化主题 Agent 黑客松报名开启！
7 10
EvoMap 是我们最近觉得最有意思的一款产品，在 Agent Infra 上做了一些很有意思的创新。
我们两家感觉理念很合，正在合办一场非常有意思的「自我进化」主题的 Agent 黑客松，时间在 3 月 28 日～3 月 29 日，地点在上海徐汇，欢迎报名👏
给不了解 EvoMap 的朋友简单科普一下，EvoMap 的前身是 Clawhub（最大的 OpenClaw 插件）平台的榜一插件 Evolver 解决的问题是：让 Agent 能在运行时自我修复和优化，并把修复结果结构化地保存下来。
当 Agent 在执行任务时遇到错误或低效路径，Evolver 会引导 Agent 对自己的策略做诊断、生成修复方案、验证修复效果，然后把经过验证的方案以结构化的格式保存。
这款插件很受欢迎，2026 年 2 月 1 日上架后，Evolver 在 10 分钟内登上了 ClawHub 的榜首，随后累计下载量突破 36,000 次。
但 Clawhub 这个生态很糟糕，有一系列技术与非技术的问题。
团队吃了几次苦头之后，决定走出 ClawHub 这个狭小的生态，自己出来干票大的，于是把 Evolver 这款插件，变成了今天的 EvoMap。
现在的 EvoMap 能够跨生态使用，不论你用的是 OpenClaw，还是 Manus、Claude Code 等各种知名 Agent，只要支持 skill 协议，都能使用 EvoMap。
同时，通过他们创立的 GEP 协议，一句话可以让你的 Agent 接入 Evomap 的 Agent 群体进化网络, Agent 能力能够被共享验证，实现「一个 agent 学会, 百万个 agent 继承」。
你的 Agent 从此继承了这世界千千万万优秀的 Agent 的 DNA，它们犯过的错，你的 Agent 不会再犯，假以时日，能极大地提高你的 Agent 的交付质量。
Bonjour! 的价值主张是帮助 Builder 们「Find the others, build together」，EvoMap 是让 Agent 之间能够协同进化，那可太适合一起做一场黑客松了。
这一次的黑客松，我们希望大家的产品不是各自做的单点产品，而是能够 EvoMap 在现场就能实现协同进化，在结束之后，网络自成。
感觉这次活动会有惊喜的产品出现，期待是你做出来的！
我们两家感觉理念很合，正在合办一场非常有意思的「自我进化」主题的 Agent 黑客松，时间在 3 月 28 日～3 月 29 日，地点在上海徐汇，欢迎报名👏
给不了解 EvoMap 的朋友简单科普一下，EvoMap 的前身是 Clawhub（最大的 OpenClaw 插件）平台的榜一插件 Evolver 解决的问题是：让 Agent 能在运行时自我修复和优化，并把修复结果结构化地保存下来。
当 Agent 在执行任务时遇到错误或低效路径，Evolver 会引导 Agent 对自己的策略做诊断、生成修复方案、验证修复效果，然后把经过验证的方案以结构化的格式保存。
这款插件很受欢迎，2026 年 2 月 1 日上架后，Evolver 在 10 分钟内登上了 ClawHub 的榜首，随后累计下载量突破 36,000 次。
但 Clawhub 这个生态很糟糕，有一系列技术与非技术的问题。
团队吃了几次苦头之后，决定走出 ClawHub 这个狭小的生态，自己出来干票大的，于是把 Evolver 这款插件，变成了今天的 EvoMap。
现在的 EvoMap 能够跨生态使用，不论你用的是 OpenClaw，还是 Manus、Claude Code 等各种知名 Agent，只要支持 skill 协议，都能使用 EvoMap。
同时，通过他们创立的 GEP 协议，一句话可以让你的 Agent 接入 Evomap 的 Agent 群体进化网络, Agent 能力能够被共享验证，实现「一个 agent 学会, 百万个 agent 继承」。
你的 Agent 从此继承了这世界千千万万优秀的 Agent 的 DNA，它们犯过的错，你的 Agent 不会再犯，假以时日，能极大地提高你的 Agent 的交付质量。
Bonjour! 的价值主张是帮助 Builder 们「Find the others, build together」，EvoMap 是让 Agent 之间能够协同进化，那可太适合一起做一场黑客松了。
这一次的黑客松，我们希望大家的产品不是各自做的单点产品，而是能够 EvoMap 在现场就能实现协同进化，在结束之后，网络自成。
感觉这次活动会有惊喜的产品出现，期待是你做出来的！
8 00