我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听
"会用观测和评估看 trace 的产品经理，已经站进前 1%。"
"代码越来越便宜后，产品品味成了团队里最稀缺的东西。"
"看到评估结果出错，反而是改进产品的入口。"
Arize AI 的联合创始人兼 CPO Aparna Dhinakaran，带来了一期很适合产品经理看的实操对话。她没有把 AI PM 讲成一个抽象岗位，而是现场用 Claude Code、GitHub issue、Arize Phoenix 和 evals 跑了一条完整链路：从用户反馈里发现痛点，让 agent 生成优先级报告，再用 trace 和评估结果判断这个 agent 有没有胡来。
产品经理先从反馈现场出发
Aparna 先把“产品品味”拆回一个很朴素的动作：收集足够多的用户反馈。她列出的来源不止客服工单，还包括 GitHub discussions、Slack、Discord、Gong 通话记录、PostHog、Amplitude、Pendo、FullStory，甚至用户在 Twitter 上的吐槽。AI PM 的第一步，要从空白 PRD 前移到反馈现场，把这些碎片接成可被 agent 使用的上下文图。
"每一天，这个 product taste agent 都会告诉你最大的痛点在哪里，下一步路线图该排什么。"
这套做法对产品经理的启发很直接：过去 PM 靠访谈和直觉整理需求，现在要把反馈管道变成系统能力。用户说了什么、产品里发生了什么、社区里抱怨什么，都要成为 agent 能检索、能评分、能复查的材料。 会搭上下文图的人，会比只会写需求列表的人更早拿到判断力。
Claude Code 先搭出一个产品助理
她选择 Arize Phoenix 作为演示产品，让 Claude Code 根据 GitHub issue 建一个 PM agent。这个 agent 的目标很清楚：读取 issue，归纳用户痛点，给出优先级，再提出路线图建议。Aparna 甚至没有打开 IDE，只给了提示词、GitHub token 和 Anthropic API key，让 Claude Code 自己搭项目。
"我没有打开任何 IDE，只是让 Claude Code 帮我建一个 agent。"
这段演示里，PM 的工作像一次任务编排。提示词里要写清楚产品、数据源、输出格式和判断标准；agent 生成之后，PM 再把它接到 Arize，查看每一步 LLM call、tool call 和最终报告。 AI 时代的 PM 不一定每天写业务代码，但要能把任务讲到机器能执行。
trace 让黑盒变成工作台
Aparna 很快把 agent 的运行 trace 拉到 Arize 里。页面上可以看到最近 15 分钟的调用：它何时去 GitHub 抓 issue，何时给单个调用打分，何时汇总成 executive summary。这个过程把“agent 给了一个报告”拆成一串可检查步骤。
"你可以看到每个 LLM call、每个 tool call，以及它最后怎样回到那份报告。"
PM 以前看的是页面和数据面板，现在还要看 agent 的行为记录。一个 agent 如果建议改路线图，团队不能只看结果顺眼不顺眼，还要追问它读了哪些 issue、漏了哪些上下文、哪一步判断跳太快。trace 不只是工程师排障工具，也会变成 PM 校准产品品味的证据。
评估结果出错才有改进空间
演示里有一个细节很重要：Claude 自己给一些结果判了“不准确”。主持人问这是不是很奇怪，Aparna 的回答反而很兴奋。她认为好的 eval 不该全对，也不该全错；它应该露出一部分判断失误，让团队知道 agent 还有哪里能调。
"当我看到 evals 出错，我会兴奋，因为它告诉我还有哪里能改。"
这段判断很适合产品团队记下来。很多人把 eval 当验收表，期待它给一个通过或失败。Aparna 的视角更像产品迭代：eval 是反馈回路。错误的 eval 让人检查标准，错误的 agent 输出让人检查上下文，二者共同推动系统变好。 不会看 eval 的 PM，很难管理 AI 产品的质量。
PM 和工程师的边界被压薄
对话里主持人问到一个尖锐点：PM 是否需要变成工程师。Aparna 的回答是，在 AI native 团队里，PM 和工程师的差距正在变得很小。代码生成门槛下降后，PM 可以更早参与原型、评估和改进，不必等到工程排期后才第一次看到结果。
"在 AI native team 里，我看到 PM 和工程师之间的差距正在变得难以区分。"
这对 PM 的要求反而更高。过去不会写代码还能靠文档和会议推动需求；现在如果 PM 不能读 trace、不能理解 eval、不能把反馈变成 agent 可执行任务，就会被卡在流程外。产品判断仍然重要，只是判断要落到可运行系统里。
同一天响应客户，靠的不是催进度
Aparna 提到，AI native 团队有时能在同一天响应客户请求。客户提出一个需求，PM 或工程师可以先做原型，再快速推进到可上线状态。这个速度不是喊出来的，它来自前面那套反馈、agent、trace、eval 的闭环。
"客户要的东西，以前可能要一周或两周，现在可以更快交付。"
如果没有 trace，团队不敢相信 agent；如果没有 eval，团队不知道改动有没有伤到体验；如果没有清晰的数据源，agent 也不知道该服务哪个痛点。速度来自系统，不来自加班。 PM 要学会把客户声音变成可验证的改动，减少靠会议催进度的消耗。
周末两小时可以做什么
主持人最后追问：如果只有周末两小时，PM 应该做什么。Aparna 的答案很具体：照着演示做一遍，选一个自己的产品，抓一批真实反馈，让 Claude Code 建一个简单 agent，再接入观测和 eval。
"如果你有两个小时，就照我们刚才做的，真的跑一遍。"
这条建议很接地气。不要从“公司要不要全面 AI 化”开始，也不要等数据平台搭好。先从一个 GitHub issue 列表、一个客服表格、一个 Slack 频道开始，让 agent 生成痛点报告，再检查它的 trace 和错误。两小时足够建立第一条回路。
开放格式会变成长期资产
Aparna 还强调，trace 数据不能被锁在某个专有平台里。Arize 收集的数据使用开放格式，可以回流到数据仓库，也可以成为未来 agent 的上下文图。PM 今天积累的是一套持续变厚的产品记忆，远比一次性报告更耐用。
"agent trace 数据太有价值了，不应该被锁在专有平台里。"
这点经常被忽略。AI 产品越跑越久，长期沉淀下来的，是用户反馈、agent 行为、评估记录和上线结果之间的关系。谁能把这些关系存好、用好，谁就能让团队的产品品味持续复利。
如果把这套流程放进日常工作，PM 的早会材料会发生变化。以前是把用户反馈整理成几条 bullet，团队再围绕优先级争论半小时；现在可以让 agent 先把 GitHub issue、客服记录和产品数据跑一遍，PM 带着 trace 和评分进入讨论。会议不再从“我感觉”开始，而是从可复查的证据开始。
Aparna 反复强调，人仍然要参与 taste 的校准。eval 标准怎么改、agent 的改进 skill 怎么写、哪些数据源应该进入上下文，这些环节不能完全交给模型。PM 的价值转到更前面：定义什么算好，定义什么数据可信，定义系统在哪些场景下不能越界。
这也解释了为什么“会看 trace”会成为 PM 的新门槛。trace 里能看到 agent 是否只读了少数 issue，是否在没有产品数据时强行给结论，是否把工具调用失败当成了用户没有需求。PM 不需要读每一行代码，但要能从运行轨迹里看出判断有没有站住。
对团队负责人来说，这条链路还会改变招聘标准。一个 AI PM 候选人如果能现场把反馈源、agent 任务、评估指标和发布验证讲清楚，比只会说“我懂用户”更有说服力。产品品味会继续重要，只是它需要通过系统化动作被证明。
文章开头那句“top 1%”并不夸张。大多数 PM 还停在写提示词和试工具阶段，少数人已经开始把 observability、evals、warehouse 和用户反馈接到一起。差距会落在产品学习速度上：谁能把它做成机器持续运行的回路，谁就先进入下一阶段。
如果你所在团队没有 Arize，也可以先用更轻的方式开始：用一个表格整理用户原话、链接到对应页面或工单，再让 agent 输出痛点和证据引用。重点在于让每个判断都能回到原始反馈，平台选择可以随后再定。先跑通小闭环，再考虑更完整的观测系统。
这期适合 PM、产品负责人和创业者反复看。它把“AI 会改变产品经理”落到了一个下午能动手的流程里：抓反馈、写任务、跑 agent、看 trace、改 eval、再回到路线图。听起来像工程实践，做起来其实是产品工作的升级版。
再往深一层看，Aparna 给 PM 提供了一套“先看证据再下判断”的操作习惯。agent 输出痛点报告后，PM 不该急着拿去开会，而要点进 trace，看它引用了哪些 issue、跳过了哪些用户群、有没有把少数高声量反馈误判成主流需求。这样的检查，会让产品会议从观点竞争变成证据校准。
她演示里的 Arize Phoenix 也有象征意义：一个开源 observability 与 evals 产品，拿自己的 GitHub issue 来训练一个产品助理，再用自家工具观察这个助理。这个闭环很小，却足够完整。团队不需要等到所有系统完美，先把一条真实反馈链路接起来，才能知道哪里缺数据、哪里缺标准。
如果把这套方法放到招聘里，一个候选 PM 可以被要求现场做三件事：选一个反馈源，写出 agent 任务，定义两三个 eval 指标。面试官不只看表达能力，还能看到候选人怎样拆上下文、怎样判断输出可信度、怎样把用户声音转成产品动作。
对已经在做 AI 产品的团队，Aparna 的演示还有一个隐含提醒：不要等到模型输出失控后才补评估。哪怕第一版 agent 很粗糙，也要从第一天开始记录输入、工具调用、判断依据和最终结果。记录越早，后面越容易比较版本差异。
PM 还可以把这套方法用于路线图复盘。某个需求上线后，把当初 agent 引用的反馈、trace、eval 和上线数据放在一起看，团队就能知道当时的判断哪里准确、哪里过度乐观。产品品味不再只靠个人经验累积，也能靠一轮轮证据复盘训练。
这会让 PM 的工作更接近“产品学习系统”的管理员。谁能让用户反馈被持续吸收，让 agent 的判断被持续检查，让改进结果被持续记录，谁就能在更短周期里形成更稳定的判断。
对于个人成长，最小动作也很明确。下次接到一批用户反馈，不要急着写结论，先让 agent 按原话、场景、影响范围、可验证指标四列整理出来。再挑一个痛点做原型，接上 trace 和 eval。完成这一轮，PM 会立刻知道自己缺哪种数据、哪种标准和哪种工程支持。
如果团队已经有数据仓库，还可以把客服、产品事件和 trace 放进同一张分析表。PM 每周固定看一次 agent 判断和真实上线结果的偏差，几轮下来，路线图会少很多拍脑袋。
这件事越早开始，团队越早拥有自己的产品学习资产。
先做。
写在最后
这期对话最值得带走的，核心收获落在一条工作线：反馈进入系统，agent 生成判断，trace 暴露过程，eval 推动改进。产品经理不需要把自己伪装成工程师，但要能站在这条线上工作。下一次写需求前，先问一句：这些用户声音，机器能读懂吗？
内容来源："The AI PM Skill That Gets You Instant Job Offers | Aparna, Arize AI"丨Aakash Gupta / Sub Club Podcast
原视频：https://www.youtube.com/watch?v=DL-pUGcfrf4
