AI Agent时代，PM更要搞清楚客户到底要什么丨UserTesting
公众号名称：晚点再听LaterCast
作者名称：Capihom
发布时间：2026-06-25 22:31
我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听晚点再听LaterCast
“能构建，不代表应该构建。”
“人类最好的用途是思考战略，AI 工具最好的用途是战术执行。”
“发现阶段比实际构建阶段重要得多。”
这一期主持人 Mike Mace 找来产品运营和 AI 策略顾问 Katie Robly，聊了一个产品经理现在很容易误判的变化：Agent 和代码生成工具把构建速度推高以后，团队会自然以为“多做一点总没错”。Katie 的判断更冷静。她过去一年帮客户做过法律数据 LLM，把加拿大法律数据训练出的模型迁到英国场景，也亲手搭过 Agent。她看到的情况是：大家已经在用 AI，许多组织仍没学会在 AI 加速后继续做取舍。对 PM、设计师、研究员和产品负责人来说，这期最值得看的部分，正是她把客户发现、评估、Agent 管理和团队责任重新摆回产品流程里。
别把 backlog 全部倒出来
Mike 先抛出一个熟悉场景：工程团队过去有几十年的 backlog，AI 让实现成本下降，很多人会兴奋地想把需求全做出来。Katie 直接踩了刹车。她说，没有 AI 的应用里，平均也有 40% 的代码在任意时刻没有被执行。多交付功能不会自动带来更多使用，反而会制造维护成本、客服成本、文档成本和客户的上下文切换。
“没有 AI 时，任何应用里平均也有 40% 的代码不会被执行。”
**AI 让团队更容易犯快错，产品经理的第一份工作仍然是决定什么不该做。**当新功能像水一样涌出来，用户要重新学习入口，支持团队要解释新行为，产品团队还要处理功能之间的关系。构建成本降下去以后，产品债和认知成本会变得更显眼。Katie 还提醒，文档、培训视频、客服话术、销售演示都要跟着变。一个按钮能被 Agent 很快做出来，后面拖着的是整条运营链路。
产品三角正在重新分工
Katie 看到的另一个现场发生在 product triad，也就是 PM、设计和工程之间。角色边界在一年内变了。过去 PM 写 Jira ticket，工程师评估实现，设计师做流程和体验。现在 Agent 可以起草 ticket，可以读反馈，可以生成原型，也可以写代码。组织没有提前定义新职责，团队只能在项目里临时谈判，结果同一家公司里的不同团队各用一套流程。
“过去可能是 PM 写 Jira tickets，现在可以让 Agent 替我们写。”
问题随之而来：谁来建 Agent，谁维护它，谁写 eval 判断输出是否正确，出错时谁负责修？如果回答只是“这跟代码有关，所以归工程”，AI 又已经让很多非工程角色能写代码，边界就会继续松动。**PM 不一定要变成工程师，但必须能说清楚 Agent 在产品流程里承担哪一段责任。**Katie 看到不少团队跳过了这些责任分配，结果 ticket、原型、研究摘要都能生成，却没人知道生成物达到什么标准才可以进入下一步。
先给 Agent 画边界
Mike 问到公司该怎样让员工成功使用 AI。Katie 没有先讲工具清单，而是讲培训和 guardrails。HR 负责人也许能访问员工个人信息，但能不能把这些信息丢进 LLM？销售团队能不能让 Agent 读取客户资料？产品团队让 AI 总结用户反馈时，哪些数据可以跨团队可见，哪些数据必须隔离？这些问题不先画边界，Agent 很快会进入敏感区域。
“组织需要某种训练计划，确保每个人理解 AI 适合做什么，也理解它不擅长做什么。”
Katie 提到 Meta 的一组故事：公司要求大量使用 AI，并把 token 用量当作绩效信号。一些团队开始把系统游戏化，搭排行榜，员工为了证明自己在用 AI，不断启动 Agent；随后又要启动更多 Agent 去找同事搭出来的 Agent，再启动评估 Agent 检查它们。她提到一个传闻级数字：组织在 30 天内用掉超过 30 万亿 token。**token 消耗变成指标以后，组织可能收获的是 AI 活动量，而不是客户价值。**产品团队要警惕这种热闹，它看起来像 adoption，实际可能只是流程噪音。
她在节目里也给 Agent 下了一个很朴素的定义：它能自主行动，能保留上下文和记忆，能随着时间学习模式并做决定。客服 Agent 可以回答客户体验问题，也可能根据历史互动判断下一步该把客户送到哪里。这样的能力听起来像一组助手，管理方式也像带助手：要告诉它做什么，什么样算好，什么样算坏，为什么要做这件事。
客户资料要先回到桌面
Katie 认为 AI 最该发挥作用的地方，是帮助团队理解客户真正需要什么，而非把 backlog 做完。客户反馈、bug、访谈、工单、使用数据、竞品资料和市场分析，本来散在不同系统里。LLM 和 Agent 可以把大量上下文放到同一个工作台里，帮助团队看到关联，再提出建议。产品经理要把这些输入组织好，不要让 AI 在空白里猜。她提到 market analysis、competitor analysis，也提到客户对话和历史研究都应该进入判断链。
“这些信息都应该帮助你判断该建什么。”
Mike 把它总结成一个画面：把旧研究、近期研究、客户访谈、用户写下来的内容和 analytics 一起喂给一个顾问，让它帮你看趋势。Katie 认可这种用法。**客户发现会从“访谈结束后写一份报告”，变成一个持续聚合证据、对照目标、筛选建设顺序的系统。**AI 越能建，PM 越要把证据链拿回桌面。否则团队只是更快地做出自己想做的东西，并没有更接近客户需要的东西。
在产品会里，这种工作可以很具体：把最近 20 次销售通话、50 条客服工单、一组低评分评论和一次竞品变更放到同一份上下文里，让 Agent 先列出重复出现的痛点，再让 PM 回到原始证据逐条核对。AI 做第一轮归纳，人负责追问证据和取舍。构建开始前，团队已经知道哪些需求来自真实客户压力，哪些只是内部愿望。
Junior PM 要学会验作业
AI 让资深 PM 从繁重执行里解放出来，听起来是好消息。Katie 也认可：人应该更多思考战略，AI 更适合做战术执行。她担心的是另一端。很多今天的产品负责人，过去都经历过读大量反馈、整理 bug、和客户沟通的摩擦。年轻 PM 如果一开始就把这些交给 Agent，可能少掉形成判断力的训练。
“现在 Agent 可以替我们做这些工作，初级产品经理就不会经历同样的摩擦。”
她给出的做法很具体：把一部分摩擦加回来。初级 PM 要独立验证 Agent 的结论，用传统方式抽查客户资料，判断输出哪里对、哪里错，并把反馈写回评估流程。Katie 说这就是 human in the loop：Agent 给出输出，人先定义 good looks like，再指出“你说了 XYZ，正确答案应该是 ABC”。未来的 PM 基本功不会只是写 PRD，还包括定义什么叫好输出，并训练 Agent 朝那个标准靠近。
训练 Agent 像带新人
Katie 把 Agent 的训练比作带新人。公司不会把代码库钥匙交给一个刚入职的初级开发者，然后说“随便改”。团队会从小文件开始，限制权限，检查提交，再逐渐开放范围。但很多组织使用 AI 时，顺序刚好相反：先给访问权，出了事故再发现需要训练。Agent 有记忆、有上下文，还会持续学习，早期喂进去的错误会影响后面的判断。
“你需要人来告诉 Agent：我希望输出长什么样，哪些例子好，哪些例子不好。”
她还提醒，通用 eval 工具只能检查句子是否完整，不能判断内容是否对客户有用。产品团队要提供组织语境、客户案例、正确样本和错误样本。多 Agent 互相学习也一样，最开始仍要有人给它们统一起点。Katie 用一个聊天体验解释风险：LLM 在同一段对话里反复走错路时，人可以关掉窗口重开；Agent 的记忆和上下文会持续存在，错误样本很难干净抽走。产品经理手里的 discovery、验收标准和用户证据，会变成训练 Agent 的原材料。
发现阶段要放在构建前面
Katie 自己搭第一个 Agent 时，本来以为可以像 SaaS 产品那样先从中间开始：前端先探索 UI，后端先 stub endpoint，后面再接起来。Agent 项目让她改了想法。她必须先想清楚最终状态、架构和基础输入，因为 Agent 一旦沿着错误上下文跑下去，回头会非常麻烦。她甚至说，某个点之后，Agent 没法“忘记”已经看过的东西。
“发现阶段比实际构建阶段重要得多。”
这段对产品经理尤其尖锐。传统软件里，发现做得不够好，后面还能靠迭代慢慢修。Agent 继承了错误目标、错误约束或错误样本后，后续修正成本会高很多。**AI 让构建变容易，反而把产品发现变成更重的地基工程。**先问客户、先定目标、先列边界，才不会让 Agent 带着错误理解越跑越远。Katie 在访谈里把组织目标也拉进来：先说清公司到底想达成什么，再看客户需求如何支撑那个目标，随后只构建达成目标所必需的部分。
她用自己搭 Agent 的经历补了一刀：自然语言能让任何有想法的人开始构建，门槛确实降低了；与此同时，描述目标的清晰度会直接决定输出质量。PM 过去写需求文档时留下的含糊地带，到了 Agent 工作流里会被放大。
每个人都该亲手搭一个
Katie 最后给了一个看似工程向、其实很产品的建议：每个人都该亲手搭一个很小的 Agent。她自己不会写代码，也不懂 headless browser，但在让 Agent 从邮件里取 URL 时，她发现系统给出的方案过度复杂。她去看链接格式，发现只要删掉结尾的一段字符就能解决。人类知道任务目的，AI 只是在当前上下文里推演。
“人需要指挥 Agent，人需要指挥 AI 去做人想让它做的事。”
她建议从普通 Claude 聊天开始，直接问：我想搭一个 Agent，工程最佳实践是什么，请一步一步带我做。如果第一步太难，就要求它简化。产品经理亲手搭一个小东西，会更理解工程师为什么需要专注，也会更知道 Agent 在什么地方会过度设计。Katie 还建议害怕单独动手的人加入 builder group，从纯新手小组开始，或者在 LinkedIn 上找同伴一起搭。会搭 Agent 可能会像会用表格和文档一样，成为新的基础生产力。
写在最后
如果你是产品经理，这期最实用的提醒很朴素：别急着把 AI 用在“多做功能”上。先拿它整理客户证据、对照组织目标、检查 Agent 输出，再决定下一步建什么。AI 会让交付速度变快，PM 的判断也会被放大。先把一个小 Agent 带好，再把一个小流程跑顺，团队会更稳。下次打开 backlog 时，先问哪条需求能被客户证据支撑，再让 Agent 开始跑。每周只改一个小环节，也足够让团队学会和 Agent 协作。把访谈、工单、评论和数据放在同一张桌上，判断会更踏实。先慢一拍，后面会少返工，也少折腾。
内容来源：“Why AI agents make customer discovery more important | Ep. 227”丨UserTesting
原视频：https://www.youtube.com/watch?v=GYXSN7ZX5rk
如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣
⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣
内容效果不满意？点此反馈