PM技能拿offer

▲ 嘉宾 Aparna Dhinakaran——Arize AI 联合创始人兼 CPO，公司累计融资 1.31 亿美元；本期自愿当「小白鼠」现场全程演示。

▲ 主持人 Aakash Gupta——承诺替观众追问 Aparna 可能跳过的每一步，逼她把闭环拆开讲清楚。

• 主讲人 Aparna Dhinakaran 是 Arize AI 联合创始人兼 CPO（首席产品官），公司累计融资 1.31 亿美元（$131 million）；Aakash 背书「我认识的最聪明的那批 AI 团队，evals 几乎都搭在它上面」。全片核心论点用开场白点明：在 AI 原生团队里，PM 和工程师的界线已经「indistinguishable（分不出来）」；任何用过 observability、会去看自己 traces 与 evals 的产品人，「你大概率已经是 PM 里的前 1% 了」——同时引出全片要答的两问：「PM 这角色还剩什么？」「PM 是不是得变成工程师了？」 → 详细
• 本期定位特别：Aakash 此前分别做过「一大堆 Claude Code」「一大堆 AI agents」「单独几期 evals」，本期把这些全串成一个迭代闭环，「差不多就是把 AI 产品的整个产品开发周期一口气走完」。Aparna 自愿当「小白鼠（guinea pig）」现场演示，Aakash 承诺替观众追问她可能跳过的步骤。 → 详细

• Aparna 最常被问的第一问就是「我到底该从什么时候开始做 evals？」——很多人甚至纠结「是不是在还没搭 agent 之前就该想」。她的答案朴素：大多数团队就是先动手搭，「你得先有个真正的产品，然后才谈得上在上面跑 evals」。所以每当被问 evals 时机，她永远指向同一个方向——先把数据拿到、把所有东西 trace 下来、把 observability 搭好；evals 是「之后帮你把 agent 带到下一个层次的东西」，不是起点。 → 详细
• 收尾时她把这个错说得更直白：PM 做 evals 最大的错就是「不先从真实 trace 数据起步（not starting with actual trace data）」；若只凭你自以为的问题出发会非常难。连他们今天用的那个 skill 之所以强，正是因为它「真的去看了全部 trace 数据」来建议该写哪些 eval。 → 详细

• 立论根基是一句反直觉的话：「代码现在生成成本极低，这意味着今天真正的 alpha 是产品品味（product taste is really the alpha today）。」面对满天飞的「PM 要消亡（the death of PMs）」炒作，她直接用招聘数据反驳：「我们现在招的 PM 比以往任何时候都多，招的工程师也比以往任何时候都多。」真正脱颖而出的人，是「对该做什么有自己的观点、有自己品味的人」；本期那个「说得有点俏皮」的目标就是「能不能试着把品味造出来（can we try to create taste）」，让看节目的 PM 拿到打造品味的「先手优势（upper hand）」。 → 详细
• 品味从哪来？去看市面上最好的产品，它们在做的事其实是「吸收海量的反馈（taking in a ton of feedback）」。她引用 **YC（Y Combinator）**对每届 cohort 都说的同一句口诀：「去跟用户聊，然后去搭东西（talk to users and go build）。」 → 详细

• 要养出品味，得「从一大堆不同的来源去收集反馈」：团队存问题的地方、GitHub discussions、现实讨论、Slack、Discord，以及那些会主动找你聊的社区。进阶玩法是把这些反馈搭成一张「context graph（上下文图谱，把分散各处的反馈/数据连成一张能喂给 agent 的网）」：从每次客户聊完的 Gong 转录（录通话并自动转写的工具），到产品分析工具 Posthog、Amplitude、Pendo、FullStory，甚至一直到 Twitter 上用户发的推。 → 详细
• 关键的范式转变就在这一句：「与其只让一个人去消化这些反馈，你完全可以让你的 agent 去消化（instead of having just a human consume it, you can have your agent consume that feedback）。」这正是后面动手搭「产品品味 agent」的全部动机——把「读反馈」这件原本靠人肉的事交给 agent。 → 详细

• 目标产物是一个「产品品味 agent（product taste agent）」：你是 PM，工作是想清楚该做什么、用户在要什么，而「每天它都会告诉你：你现在最大的痛点是什么、最该优先做的是什么，并给你的产品路线图提建议（what your biggest pains are, what your biggest priority should be, and suggest where your product road map needs to go）」。 → 详细
• 演示开刀的产品是 Arize 自家开源产品 Arize Phoenix——「目前最主流的开源 observability 和 evals 平台」，可完全开源跑、自托管。她特意提醒：「你完全可以挑一个对你自己有意义的产品」，前提是「挑一个你掌握全部上下文的产品（pick a product that you have all the context of）」。起步只接一个来源就够：今天就只「从超简单的开始（start super simple）」、只从 GitHub 的 issue 和 discussions 入手；等规模做大，再把 Gong 转录、产品分析、Slack、Discord「什么都能塞进去」。 → 详细

• 整条闭环被讲成五步：① 用 Claude Code 把 PM agent 先建出来 → ② 把所有东西 trace 下来（她反复强调「我们接下来用来做改进的核心魔法，其实就是 tracing」）→ ③ 去跑 evals → ④ 改进 agent → ⑤ 把改进后的 agent 放回去再跑。起步前置条件由主持人逐项确认：建一个新 GitHub repo、给它你的 Anthropic API key（建 repo 得先登录 GitHub）；Aparna 当场表示「很乐意发给大家一个示例 repo」。她预判产品同学的心理门槛：进终端可能「有点吓人（intimidating）」，但她保证那种掌控感和迭代速度「绝对值回你一开始那一点点学习的阵痛」。 → 详细

▲ 全程不开 IDE，只在终端里给 Claude Code 一句起步 prompt，并把 Phoenix 仓库 URL 直接贴进去，让它拿到「要搭什么」的确切上下文。

• 给 Claude 一个起步 prompt：让它「给我搭一个针对 Arize AI Phoenix 产品的 PM agent」，并把那个完整 repo 的 URL 贴进去，「这样它就能拿到我让它搭什么的确切上下文」。让它拉的上下文：把最近的 GitHub discussions、所有 release、再看 GitHub issues 全拉下来；接着明确要求给这些 issue 和 discussion 按优先级打分，要它权衡的维度逐项列出：bug 还是 feature、大家给的 reaction（表情点赞）、评论数、以及时效性（recency）。 → 详细
• 调模型可以很具体，「可以说调用 Claude Opus，或者我想要的任何模型」；省钱技巧是让它做 prompt caching（提示词缓存，把不变的大段 issue 缓存起来），「这样它不用每次跑闭环都重新把 issue 全拉一遍」（为了一开始简单她先跳过）。输出要求写一份 markdown 格式的 PM 报告，含「top 痛点、feature 诉求和各种主题，按 P0 到 P3 优先级排好序」，最后补「用我的 GitHub token 和我的 Anthropic API key」。给计划可精可粗：她个人偏好「认真想清楚我给 agent 的那份计划，让它不是凭空乱跑」，但「也有些时候你就直接让它先跑、先搭点东西，再一轮轮反馈，那样也完全 OK」。 → 详细

• agent 实际拉取规模：「它已经拉了 40 条 discussion、60 个 issue、8 个 release」；给每项打分后产出报告——含执行摘要、top 痛点、feature requests、主题、已经上线了什么（what shipped），外加一份「可以当起点用的 game plan」。她提醒：跑的过程中 agent「会打断、问一大堆问题」是正常的。最点题的是她那句感叹：「我真的没打开任何 IDE，什么都没开（I didn't open any IDE, I didn't open anything）」——只是给了 Claude Code 一个好 prompt、再让它用 skill 接上 Arize，「砰，现在我就对我的 agent 有了可见性」。她坦言「我几乎可以打包票它不会完美」，但重点正在于此——「把这当作一个起点：那我该怎么改进这个 agent？」 → 详细

▲ 同一块终端串起两步：上半是 agent 念出的完整 game plan（拉数据→打分→Opus 出报告），下半只用一句话就把它挂成 loop skill，往后每有新 issue 就自动重跑。

• 理想状态不是手动跑一次，而是「你想让它一直在跑」——每次有人新提 bug、新加 issue 它就一直做。做法极简：对 Claude 说「能不能让它跑成一个 loop」，并指明用 Claude 的 loop skill。机制：Claude 本质上会「起一个 cron job」（她给外行解释 cron job——「就是你让 Claude 把某种你每天都要做的工作流跑成一个循环」）；节奏可每天、每小时，「你要愿意甚至可以设成每 5 分钟」，于是「每个小时你都有一份最新报告，告诉你该给 agent 优先做什么」。 → 详细

• 一条 trace 就是「这个 agent 实际做了什么的、一步一步的回放」；本例步骤是 agent 先拉 GitHub discussions → 再拉 issues → 搞清最近发了哪些 release → 然后一条条过每个 issue、给每个算出一个「有多重要」的分。span 则是「一个 trace 里的单个步骤」（生成整份报告是一条 trace，其中要看的某一个 issue 就是一个 span）。tracing 为什么是「核心魔法」？因为「Claude 会同时分出一堆不同的事来跑、还是在一个 loop 里跑」，很难调试；不管它返回的是「一坨垃圾（slop）」还是好结果，tracing 都让你看清「它当时到底怎么做出来的、该怎么改」。 → 详细

▲ 一句「can you help me instrument this agent?」后，skill 自己读代码库判明语言/LLM 提供方/该用哪个库，把每一类 LLM 与 tool 调用都接好往 Arize 发——PM 不必再去喊工程搭档配 tracing。

• 痛点：tracing 以前很难，「你基本得去找你的工程搭档，让人家帮你把 tracing 配起来」；但「有了 AI，做这件事大概从没像现在这么简单过」。Arize 的解法是发布一系列 skills，安装就一行 NPX skills add，「你可以直接把它丢给你的 coding agent」。其中的 instrumentation skill 本质上「就是用英文写明 Claude Code 该怎么把 trace 数据发送到 Arize」，人人都能读懂。用法就一句「你能帮我给这个 agent 做埋点吗」：skill 自动判断出代码是 Python、LLM 提供方是 Anthropic、该用哪个库，最后回「一切都已接好，正在往 Arize 发送」。跑完即见效：「这就是过去 15 分钟里所有的内容」——traces 流式灌进平台，看得到一个个 LLM 调用、tool 调用、去 GitHub 拉东西、打分，最后产出那份报告。 → 详细

• Alex 是「一个就坐在我们产品内部的 agent」：你可问它「帮我找出现在反复出现的常见问题类型」，它跑一遍数据，「从我的 traces 里浮现出用户提问中常见的问题类型」。价值是让 evals「从一个真正去看自己的 traces、看自己的错误的地方起步」。她举了个所有 PM 共鸣的痛点：「多少次有团队里的人跟你说某件事超级重要、超级优先，可换成你自己根本不会给它那么高的排名」——这正是需要 eval 去校准的地方；可以让 Claude Code 帮你搭一个「基线 eval（baseline eval）」，「用它不断迭代，这样你就不是完全从零开始」。 → 详细

▲ PM 真正想要的颗粒度不在「成品报告」层，而在这里：把每一个 issue 单独拎出来，看 agent 给它算出的 composite_score 到底合不合理——这正是 priority accuracy evaluator 要逐条评判的对象。

• 一句「你能给我的 agent 推荐一个好的 eval 吗」会调用 evaluator skill，它看一遍 traces、跨数据给三个候选：① report groundedness（报告事实依据）——最终那份报告里的引述、issue 是不是真有喂进去的实际数据作依据；② priority alignment（优先级一致性）——报告里的 P0、P1 是不是和你期望的、得分最高的 issue 对得上；③ report actionability（报告可执行性）。 → 详细
• 但她当场指出这三个都属于「站在终点、看成品」的视角，而作为 PM 她想要的更细——「我想在最开始就更颗粒化一点，去理解每一个 issue 它打的分到底对不对（for every single issue, did it give it a right score）」。她翻着报告举例：「这个给了优先级三；这个给了零、说这个集成没那么重要；它给了这个隐私问题一个三——所以这一堆优先级它基本上是自己编出来的（kind of making up these priorities）。」于是她回到 Claude Code，让它建一个评估「每个 issue 的优先级是不是被准确地打了分」的 eval。她特别说明这种来回反复、让 Claude 重说一遍、把需求说得特别具体「非常正常」；当 Claude 误以为她要第二个选项时，她纠正：我要的更微妙——「不只是排名靠前的那些 issue，而是每一个单独的 issue 是不是真的被赋予了它应得的权重」。最终生成的是一个 priority accuracy evaluator（优先级准确度评估器），行级/issue 级跑在真实 traces 上。 → 详细

• skill 贴心提示：「它现在跑的是比较旧的数据，你要不要直接拿今天刚抓下来的那些新 issue 来跑」，于是在更新的 span 上跑：进来的每一个 GitHub issue 先打一个「有多重要」的分，再去评估它给的那个分到底是不是一个合适的评估结果。跑完可在平台里直接筛：「把所有标签其实不准确的地方都给我看一下」——也就是 Claude Code 认为优先级打错了的地方，并附上它为什么错的原因。 → 详细

• 主持人复述传统 evals 套路：去 trace 仪表盘看优先级、说「这个是零、其实该是四」，「拣出大概 50 个错误，归个组，说『这就是它会犯的 10 类错误』」——然后点破本期在做的事：「我们是不是想复刻这个，只不过让 Claude Code 自己来做？」Aparna：「正是，正是。」她分享「秘方（secret sauce）」：底层「所有这些 skill 其实都在调 API」；而它们倾向调 CLI——「我们发现这些编码 agent 特别擅长跟命令行、跟 CLI 接口打交道」，所以 skill 底层「基本就是去调用并把所有 traces 拉下来」。她致敬了 evals 方法论代表 Hamel 和 Shreya（全文一处口语化为 Trey/Treya，指同一人）的经典做法——「一行一行地过，看哪些单独的 trace 失败了」、做自由文本标注；但表明自己偏好「让 Claude Code 帮我省点这种时间、浮现一些洞见」。 → 详细

• 首尾呼应的金句（Aakash 抛、Aparna 接）：「好的 eval 是这样的——你既能挑出健康比例的『对』，也能挑出健康比例的『错』，这样你才能取得进展（healthy percentage right, but also healthy wrong）。」Aparna「百分之百同意」并加一层心态：「我看到 evals 出错的时候反而会很兴奋，因为这正好告诉我：这里有可以改进的地方。」反向信号：若所有东西都被判成错，就该警惕——「也许我不该太信这个来自 Claude 的 eval」，回头审 eval 本身。由此引出做 evals 的人会一直听到的灵魂拷问：「是我的 eval 错了，还是我的 agent 错了？」 → 详细

• 她对「凭感觉评估」的判断很直接：「vibe eval 会很快、很快就撑不住了」，因为它「没有任何根基——没有立足于任何真正参与、为你的 agent 提炼品味的人」，「信噪比会非常非常低」。但「永远从正经标注起步」也有痛点：现实中「你最终总会用到 Claude」。所以她认为「一开始就让 Claude 来建议一个好 eval 大概该长什么样，这完全 OK，这些模型已经强到不行了」；作为初跑让它看一遍你的答案、建议「这条你大概该标记出来看一看」——「我会信它的（I would trust it）」。 → 详细
• 主持人最爱的工作流：「永远先让 Claude 生成，然后你对它狂提批评、毫不留情（always start Claude generating it, but then you give it ruthless criticism）」——他甚至「直接打开听写模式（dictation mode）」对着念：「这条你判错了，原因是这个。」而这正是「你带来的那点品味 alpha 能重新发挥作用的地方」。还有一条铁律：即便你逐条人工标注、拼出一个「无比完美的 ground truth 数据集（人工确认过的"标准答案"）」，「随着你看到越来越多的数据，你的 eval 也会随时间逐渐失准」，所以「非常重要的一点是定期把这些 eval 跟你在一线、在用户那边真正看到的数据对齐」。 → 详细

• 她现场发现一类失准：用新打分系统、「被归到第四类（category four）的 bug 类目项也经常不准确」——bug 没被正确归类、或没拿到她想给的准确分数。这时她注入一条非常具体的人类品味原则：「在我的世界里，我希望 bug 永远是超高优先级的，因为如果是个 bug、客户撞上了它，那对产品就是非常糟糕的体验」，所以「我会把 bug 排在新功能之前（prioritize bugs over even new feature work）」——这就是「人类品味怎么注入 eval」的一个具体、可操作的例子。 → 详细
• 她直接追问 Alex「当我的优先级准确度不准时，常见的问题或原因是什么」，Alex 浮现出一整批问题类别：feature request 打分、legacy（遗留的）打分系统、bug 优先级打分、低优先级打分、数据抓取（data fetch），并给出「一大堆 spans 让你去看、去 debug」——好让你搞懂这个品味 agent 在排优先级时到底有哪些实际问题。 → 详细

• 她把「怎么快速进入那个循环」浓缩成一句四步配方：「把数据弄进来 → 把 eval 搭起来 → 给它批评 → 让它在循环里跑起来（get data in, get an eval set up, give it criticism, and let it go run on a loop）。」关键升级在于：有了 eval 之后，再创建「一个全新的 skill」——它的职责是「每天都去跑一遍，把所有不准确的、被错误排优先级的东西抓出来，去修、去改进我的 agent」，并基于刚跑的 eval 提出改进建议。主持人点睛：「所以你把『改进』本身也变成了循环，而不只是 agent（you loop the improvement too, not just the agent）」，由此「进入了一个自我改进的世界」。 → 详细
• 大愿景一句话讲透：「我们收集的全部数据、eval 和可观测性，就是自我改进型 agent 的地基（the foundation for self-improving agents）」——「我们所有人都在奔向的方向」。她给了个修 bug 的具体闭环：发现「原来是我给 bug 排优先级的方式不太对」→ 回到 PM agent 说「嘿，去把这个问题修了」→ 它去修、发布一个新版 agent → 再从这个 agent 的下一个版本里收集 traces——整个改进 loop 都「可以作为一个 loop skill 跑在 Claude Code 里面」。 → 详细

• 内部辅助 agent 可激进自改进，但产品里的 Alex 不行——主持人点出风险：「你不会每天都把自我改进直接推给 Alex，因为它可能就跑偏到某个奇怪的方向去了」，所以「仍然有 code review，仍然有一个人去看自我改进循环提交的每一个 PR」。Alex 内部已在跑的流程：用户对某个回复「点了踩（thumbs down）」→ Alex 立即「起一套 debug 工作流，用 eval、用 trace 去定位出错原因」；接下来分两种——若 eval 错了就精修那个 eval；若 agent 错了就进去做个改进、说「嘿去把这个修了」。 → 详细
• 必须放「人在循环里（human in the loop）」的三处，她逐条列出：① 每次 eval 变更——「这是非常重要的一步，要让人去真正提炼『什么是好、什么是不好』的那种品味」；② 每次 agent 变更——仍要 code review；③ 那个改进 skill 本身要由人来设计——人得想清楚「这个改进 skill 该长什么样、它需要拿到哪些上下文才能知道改进到底是什么」。她举例：本例它「可能没拿到全部上下文，因为我给它的只是 GitHub issue」，但若再叠加产品分析 metrics、叠加完整的全部 traces，它就能用这些为自己构建出「哪里出了错、我该怎么修」的上下文——这些本质上就是「改进循环的 context」。愿景是让自我改进「在数百万用户身上实时、自动地进行」，更偏生产时就「用真正的 cron job，每天或按任意节奏跑」。 → 详细

• 主持人问起跟 Uber、DoorDash 等顶尖公司合作看到的「最前沿状态（state-of-the-art）」。Aparna：「最好的团队已经在做这件事了」，只是在一个「他们今天觉得舒服的『半径』」内做，但「那个半径会越来越大」——最初改进围绕的是较简单的改动，「更多是关于 prompt、关于工具」，之后扩展到「赋予 agent 它原本没权限去做的整套工作流」。前提铁律重申：那个循环「离不开非常好的数据，加上非常好的 eval」。她用网球比喻把逻辑讲活：像 Nadal、Federer、Novak（Djokovic） 那样的顶尖选手在做什么？「他们在回看自己的打法、看自己以前的比赛、研究自己当时的行为」；自我改进型 agent /「harness（执行框架，包在模型外面驱动它干活的那套代码）」也得这样「研究自己的打法」——这正是 evals 和 observability 之所以是「foundational layer（地基层）」的原因。 → 详细

• Aakash 把 Arize 客户分成三桶：① AI 原生（AI natives），如 Handshake；② 数字优先（digital-first），如 Uber、Reddit、Roblox；③ 有技术臂膀的传统公司，如 Pepsi、Condé Nast。Aparna 的总判断：「PM 这个角色在过去一年彻底变了（completely changed in the last year）」——PM 几乎就是「这个产品的 tastemaker（品味定义者）」；尤其那些「产品本身就是 agent」的 AI PM，「你就得花多得多的时间去理解 agent 的产出结果」。 → 详细
• AI 原生 PM「在某些方面已经几乎跟工程师没什么区别了，因为他们很习惯泡在 Claude Code 里（comfortable living in Claude Code）」；她引用 Arize 内部常说的一句名言：「如果你今年做事的方式还跟去年一模一样，那说明你还没跟上（if you're doing things the same way you were doing things last year, then you haven't caught up yet）。」 → 详细

• 老办法是「还盯着自己那块老看板，写着我的优先级一二三，然后人工一条条扫」；现在不一样，因为「你不再受限于自己一个人能亲自听几场会、几通 Gong 通话」。新玩法：让 Claude Code「把所有这些客户通话——那些你自己一辈子也听不完的——全部过一遍」，再帮你「浮现出那一两通超级关键、必须亲自盯的」——因为「正是那一两通能帮你拿下下一个十个、十五个客户」。 → 详细
• 真正的「10x PM（10 倍 PM）」长这样：能从「这是痛点 → 这是我认为非常惊艳的体验」一路走到方案，「几乎能自己把这个东西要怎么搭的方案都拼出来（almost put together a plan for what that build needs to look like）」，而不再是「嘿，我把它交接给工程师」。 → 详细

• 问到「想在一家融了 1.31 亿美元的 AI 原生公司拿下 AI PM 岗位该培养哪些技能」，第一答案是：「好奇心是——对我来说这是头号最重要的信号（curiosity is the number one most important signal）」——这人在「尝试所有新工具，在不断探索自己能做什么、不能做什么的边界」。为什么是好奇心而非培训？她讲因果：过去「会有培训，有人手把手教你怎么用一个工具」；可如果这工具是 Claude Code、而它「在大概 30 天里发了 90 个功能（shipped 90 features in like 30 days）」呢？「根本不存在什么老办法能给一个迭代这么快的产品做每日培训」，所以「跟上节奏的责任现在落到了个人头上（the onus of keeping up has become on the individual now）」。 → 详细
• 衡量标准很具体：能识别出某工具让「这件事以前要花我一个小时，现在十分钟就能搞定（used to take me an hour and now it can take me 10 minutes）」并把它为我所用——「能识别出这些工具并为我所用，在现阶段深深地是建立在好奇心之上的」。 → 详细

• 第二个大点依然是经典却没过时的「真正在乎、真正理解用户——对用户和客户的同理心（user and customer empathy）」：最好的品味定义者，被问「这个客户是怎么用产品的？他们最大的痛点是什么？」时能「一口气全给你报出来（rattle them off）」。现在能挖得更深、交付更快：客户提了需求，「这事在过去可能要花一周、两周去搭，现在当天就能交付」。她下判断：能跟客户贴得更近、交付得更快，「已经不再只是个白日梦了，这就是现在 AI 原生公司里最好的产品真实的发版方式」。 → 详细
• 主持人替「99% 不在 AI 原生公司、不信这套」的人逐字确认：是否真有「问题来了 → PM 判断够重要 → PM 或工程师做出原型并打磨到可上生产 → 当天就发出去」这种事？Aparna 一字一句答：「是的，这就是真实在发生的事，各位（Yes. That is actually what's happening, guys）。」 → 详细

• 回到开篇「PM 是不是得变成工程师了」，她答：在 AI 原生团队，「PM 和工程师之间的差距已经分不清了，因为当写代码变得容易这么多以后（indistinguishable because code has become so much easier to produce）」——逻辑又绕回那句「今天的 alpha 就是产品品味」。她给出「triple threat（三料全能，原指既能演又能唱又能跳的全才）」PM 的画像：能说「这是痛点 → 这是我认为非常惊艳的体验 → 我今天大概就能把它搭出来，去跟 Claude Code 聊聊该搭什么」。她断言这种人在当下环境里速度会「快得离谱（insane velocity）」。 → 详细

• 大企业（如 Pepsi）离那状态「还差得远」，但她不愿说「那里完全没有创新」——所有这些团队都在用编码 agent、在日常工作流里「感受到了这些工具带来的解锁」。她观察大企业冒出两类产品：① 用 AI 让体验真正有用的惊艳产品；② 跨数据孤岛的解决方案（大公司「会有一个个数据孤岛，有些人能拿到某些信息、别的团队却拿不到」）。context graph 再次出现并给了出处：这是 Jaya Gupta 几周前发的一篇「已经传疯了（gone super viral）」的文章（她推荐在 Twitter 关注她）。核心定义：「agent 的好坏完全取决于它实际拥有多少 context（agents are only as good as how much context they actually have）」，再加搭在它上面那层 harness 能访问到这些 context。她预判：「搞清楚 agent 怎么在一个组织内部消费 context，很可能是今年最大的挑战和解锁点之一。」 → 详细

• 被问「接下来 12 到 24 个月该一步步实施怎样的路线图」，她第一条建议是别只刷热点：「你会在 AI Twitter 上读到一大堆东西，每个人都在分享每一个最新模型、最新工具」；而她「特别想强烈建议任何一个 PM：先从动手搭开始，从搭非常简单的东西开始，就像我们今天做的这个例子」；甚至「它都不需要是一个对外发布的 agent，就当个你自己用的内部小工具，今天就拿下一个大解锁」。你会学到两件事：① Claude Code「容易得离谱（insanely easy）」；② 但「要真正把它做好需要多少工作」——要超越最初那个「vibe code」，「evals 和 observability 非常非常重要」。 → 详细
• 她还设想下一步：「我能不能让一个 agent 真的去帮其中一个痛点提一个草稿 PR？再让另一个 agent 去 review 那个 PR？」于是「从识别出一个要解决的痛点、到把它发布出去，这整个流程在过去可能要花好几个月，现在可以缩短到一天之内」。她特意点出一个「别遇挫就放弃」的心理陷阱：「你有多少次是这样——你觉得『它不工作，那我就把这个想法划掉、先搁着』」；这正是 Arize 这样的数据层/observability 能帮上忙的地方——因为「你可能根本不知道为什么你的 agent 给了你一个糟糕的回答、或者它当时到底在干什么」。 → 详细

• 再次回到网球比喻并升华：顶尖选手怎么「去看自己的每一拍、搞清楚哪里出了错，又怎么做到每天都比昨天好 1%（do that 1% better every single day）」？她迁移到个人成长——「如果你能让自己每天的产出都 n+1（if you could n plus one your output every single day）」。全片主题在此被一句话点破：「这个故事不再只是关于 observability、关于看你的数据了，这个故事是关于自我提升——既是作为 PM 提升你自己，也是提升你正在搭的那些产品（the story's about self-improvement—improvement of yourself as a PM, but also improvement for the products you are building）。」 → 详细

• Arize Phoenix（开源）：就是今天用来拉 GitHub issues 的那个版本，「如果你没法把数据发到外部平台，它是一个非常棒的选择」；现实约束是「对大多数企业、大多数搭任何带 PII（个人身份信息）数据 agent 的团队来说，他们想自托管一套初步的 observability」。license「极其宽松（super permissive）」，演示里「几乎所有东西都开箱即用」，那些 Claude Code skills 在 Phoenix 上也都有（她引旁证：「连 Hamel 都发推说过，他最喜欢的 observability 开源工具就是 Arize Phoenix」）。何时转付费/企业版：「显然是在数据量开始往上涨的时候」；她把数据涨看成好事——「说明这些 agent 开始找到 product market fit 了」，有团队发来「几乎是 TB 级别（terabytes）」的数据，这时上一个「更能横向扩展的」平台就很合理。底层支撑：Arize 搭了自己的数据存储 ADB——「一个从第一天起就为 AI 工作负载设计的数据存储」。 → 详细

• 独立于框架（framework-agnostic）：「我们其实不在乎你用什么框架」；客户从 LangChain、Claude Agents SDK 到「不用任何框架自己搭的」都有。数据独立/开放：「我们采集的所有 trace 数据都以开放格式存储」，可用 ADB data fabric 把数据「直接发回你自己的数据仓库」——因为「你不会想让你的 agent trace 数据被锁死在一个专有平台里」，好把它当 context graph 的一部分用。埋点独立 + 创新最快：Arize 是「OpenInference 的发明者」，「我们的竞争对手，你提到的每一家，全都在用我们的埋点，而且在自家文档里都链接到了它」。她列了一串「第一」：LLM-as-a-judge（用 LLM 当评判）是 Arize 第一个做出来的（「2023 年 Phoenix 的 repo 就有」）；第一个发布 OpenInference；第一个把 agent（Alex）内建进产品；那些 skills 也是「我们第一个做出来并发布的」（开源负责人 Mikio 还跟 Hamel 做过一期访谈聊这个）。结论：「我们大概是这个领域里当下迭代创新最快的玩家。」 → 详细

• 周末 2 小时做什么，她给最落地的一条：「就照着我们刚刚做的这一套——给自己搭一个 agent」。挑什么？「挑一个你每周都做、要花上几小时的重复工作流」；她举接地气的例子——「这不只给做产品的人，比如你是做产品营销、每周都要写 release notes（发布说明）的，那就让 agent 去帮你写」。 → 详细
• PM 做 evals 的最大误区（首尾呼应、再强调）：「最大的就是不先从真实 trace 数据起步（not starting with actual trace data）」；「如果你只凭你自以为的问题出发，那会非常难」。主持人收成一句金句：「evals 不是凭空变出来的，是从你的 trace 里来的（evals don't just come out of magic, they come out of your traces）」。主持人收尾建议：「我强烈建议每一位 AI PM 都把 AI eval 这项技能练到家，而 Arize 是最省事的入门方式之一。」 → 详细

本期为「访谈 + 现场实操演示」格式，无独立 lightning round。收尾的核心行动号召与金句如下：

• 周末 2 小时行动：挑一个你每周重复花几小时的工作流（哪怕只是产品营销每周写 release notes），用 Claude Code 搭成 agent；先亲身体会上手有多容易（「insanely easy」），再用 evals + observability 把它从「vibe code」打磨到「真正好用」。 → 详细

• 本期最强金句：「任何用过 observability、会去看自己 traces 与 evals 的产品人，你大概率已经是全世界 PM 里的前 1% 了。」 → 详细

• evals 的本质：「evals 不是凭空变出来的，是从你的 trace 里来的」；好 eval 要「健康比例判对 + 健康比例判错」，全错就是该回头审 eval 的信号。 → 详细

• 快速进闭环的四步配方：把数据弄进来 → 把 eval 搭起来 → 给它狠提批评 → 让它在 loop 里跑起来；再把「改进」本身也做成第二个 loop skill，就走向了自我改进型 agent。 → 详细

• 主持人收尾资源：放出 Arize 定价页；想免费拿 12 个月 Arize 团队版（Pro）可走 Aakash 的 bundle（bundle.akashg.com），或先用免费的 Phoenix 上手；强烈建议每位 AI PM 把 AI eval 技能练到家。 → 详细

• 嘉宾：Aparna Dhinakaran — Arize AI 联合创始人兼 CPO（公司累计融资 1.31 亿美元）。

• 主持人/频道：Aakash Gupta（YouTube 频道 Aakash Gupta）。

• 产品/资源：Arize AI（付费/企业版，底层数据存储 ADB + ADB data fabric）、Arize Phoenix（开源 observability + evals 平台）、Arize skills（NPX skills add，含 instrumentation 埋点 / evaluator 写 eval 等）、Alex（产品内嵌 agent）、OpenInference（Arize 发明的开放埋点标准）；想免费拿 Arize 团队版见 bundle.akashg.com。

• 个人社交账号：原视频未直接给出 Aparna 的个人联系方式（无）。提及可关注/致敬的人：Jaya Gupta（Twitter，context graph 一文作者）、Hamel Husain（evals 方法论，曾发推力荐 Phoenix）、Shreya（evals 方法论，全文一处口语化为 Trey/Treya）、Mikio（Arize 开源负责人，与 Hamel 做过一期 skills 访谈）。

• observability（可观测性）：能看见 agent 内部每一步在干什么的监控能力。

• trace（轨迹）：agent 一次完整运行的逐步回放（拉数据→打分→出报告这一整串）。

• span：一条 trace 里的单个步骤（如要看的某一个 issue）。

• eval（evaluation，评估）：对 agent 输出好坏的自动化打分。

• instrument（埋点）：往代码里塞监控探针，让 agent 的每步往 observability 平台发数据。

• vibe code / vibe eval：凭感觉随手搭出来、未经真实数据校准的东西。

• alpha：超额收益、护城河（本片指「产品品味」）。

• AI native（AI 原生）：核心产品本身就是 AI agent 的团队/公司。

• context graph（上下文图谱）：把分散各处的反馈/数据连成一张能喂给 agent 的网。

• ground truth：人工确认过的"标准答案"数据集。

• harness（执行框架）：包在模型外面、驱动它干活的那套代码。

• cron job：让程序按固定节奏（每天/每小时/每 5 分钟）自动重跑的定时任务。

• prompt caching（提示词缓存）：把不变的大段输入缓存起来，省去每次重拉的开销。

• LLM-as-a-judge：用一个 LLM 去当评判，给另一个 agent 的输出打分。

• OpenInference：Arize 发明的开放埋点标准（竞品也在用并在文档里链接它）。