Zapier CEO 现场给你的 AI PM 技能打分——Wade Foster(Zapier)

▲ 图注：Wade 屏幕共享的 Zapier 评分表博客页（One year later: Raising the AI fluency bar for every Zapier hire），展开的 Product 一节自上而下四档：Unacceptable、Capable、Adaptive、Transformative。

• 这期怎么玩：主持人 Aakash Gupta 介绍，Zapier CEO 兼联合创始人 Wade Foster 发布了他认为是网上第一份 AI 流利度（AI fluency，用 AI 干活的熟练与深入程度）评分表，此后很多公司照着它做，Zapier 自己的想法后来也更新了。这期不只从理论上讲评分表：Aakash 带来几份当天早上现做的 PM 产出物，由 Wade 当场判定「这算变革型，还是不合格」，再聊这些期望怎么随时间变，好让你在自己公司达到、甚至超过这条线。→ 详细
• 四档，从低到高是不合格 → 胜任 → 适应型 → 变革型：Wade 直接把评分表共享到屏幕上——这份 2026 年 3 月 31 日发布的是 Zapier 更新后的 AI 流利度标准线，也就是 V2。屏幕上看得到三档：胜任（capable）、适应型（adaptive）、变革型（transformative）；此外还有一档不合格（unacceptable），「说白了就是我们决定不录用的那条线」。做这张表的用意，是「把那些能让人在 AI 流利度上脱颖而出的技能和行为明确地点出来」。→ 详细
• 按岗位分栏，而且对外版已经旧了：表里不止一栏，这是产品播客，他们就往下拉到产品这一栏。Wade 先声明：这是对外公开的 V2，之后内部又改过其中一些内容，「因为这个领域变化太快了，你确实得不停地调整、打磨你的做法」。他也鼓励各家按自己的状态调：还没走那么远的公司可以定得不一样；比 Zapier 还超前的，可以要求「更多人处在这几档，真正去突破边界」。→ 详细

• 基础用法已经不算本事：Wade 说在 2026 年，用 AI 做简单任务——总结、写作、查信息、生成基础的 PRD（产品需求文档）——「到了现在，对大多数公司来说这些都只是入场门槛（table stakes）」，Zapier 通常要找的是「在明显更高的水平上做事的人」。→ 详细
• PM 岗的门槛已经抬到这里：① 有一套非常结构化的方法来生成 spec（需求规格说明）、原型，并且能在不同项目之间反复复用、持续打磨；② 用 AI 真正去挖用户洞察、做定量分析，在「过去单靠人力做不到的规模上」开展工作；③ 能非常快地生成大量不同的、真正能跑起来的方案。他的原话是，这些「最后就成了这类岗位的入场门槛」——换句话说，「有一套可复用的结构化打法」在 Zapier 已经不是加分项。→ 详细
• 再往前推一把：延伸到别的岗位：Wade 认为 PM 很适合成为组织里「通才型的超级建造者」——数据分析、营销、销售这些技能，PM 本来就懂一点，现在借 AI 能做到八九成的水准，「能在一个项目的整个生命周期里上上下下都顶得上」，价值会大很多。→ 详细
• 越往上越是搭系统，顶格是产品工厂：「你想的不只是这个功能要怎么运作，而是真正在想，我要怎么搭一条 agent 流水线，让它接收客户反馈、生成 spec、做方案原型、交付完整的功能。」他把它类比成大家听说过的「软件工厂」（software factory，用一串 agent 流水线自动产出软件），「这正是 PM 开始变得大有价值的地方」——去想「怎么搭建那个能造出终极系统的系统」。做到让人感叹「我们居然真的在这儿搭起了一座产品工厂，正在从根本上改变产品工作的方式」，就进入了变革型。→ 详细

• 钟形曲线的鼓肚在适应型：Aakash 问 Zapier 想看到什么样的分布。Wade 说产品团队的技能组合「大部分落在」适应型；人人都有短板，每天都冒出新技巧、新打法来不及用，所以肯定有人处在胜任这一档；同时「我们通常希望一个人能拿出一个自己在（变革型）这一档做过的例子」。→ 详细
• 一直待在变革型反而是坏事：「100% 的时间都待在这里可能反而没什么帮助，因为如果真是那样，你其实就没在干活了，你一直在折腾你的系统和工作方式。」Zapier 的 PM 团队大部分时间待在适应型，偶尔做些实验推自己突破边界。Aakash 接话说这个框法很有意思：你其实并不想一直是变革型，因为那样就没时间干活了。→ 详细
• 不给人贴死标签，半年一评：Wade 不会说「你就是这一档」，更像是「大多数时候我在这一档，但有时候我在这儿有些短板，有时候又能在上面这里做出点东西」。Zapier 的绩效评估按半年做一次。→ 详细

• 背景：过完寒假就没人写代码了：Aakash 问某个 PM 达到变革型的那半年是什么样。Wade 回忆去年年底，最新的 Opus、GPT、Gemini 系列接连发布，推理能力比以前强了太多——从「AI 差不多是在跟工程师一起写代码」，一下子变成「过完一个寒假，基本上所有人都在说：我已经不写代码了，我现在很少再亲手写代码了」。→ 详细
• 第二大脑是什么：与此同时，网上和 Zapier 内部都有很多人在搭「第二大脑」。Wade 说最开始的做法很简单：建一堆 markdown 文件，写上「这是我的目标」「这是我希望你配合我工作的方式」，再放一大堆上下文（「这是我正在做的一个项目」）；然后启动一个 coding agent（能读写文件、执行命令的编程型 AI 助手），它就能拿这些上下文去做项目。里面可能放着设计系统、公司战略，也可能放着教练类文件——「帮我在这件事上做得更好」。→ 详细
• 从个人到公司：一位产品负责人说：「第二大脑这个概念挺有意思，但如果这些只是个人层面的 skill（封装好的可复用能力说明），那就有局限了。这应该是一个公司大脑。」他主动把这件事揽下来，搭出公司大脑的 V1，要把「所有能帮到公司里任何人的上下文」都汇集起来；推广先从一大批产品负责人和 PM 开始——「我们要让所有人都用上这个第二大脑，或者说公司大脑，来干活」。→ 详细
• 效果是一次相变：「你能明显感觉到发生了一次相变：不只是他本人，而是 Zapier 的每一个产品人，在他推出这套系统之后，都像是背上了一台喷气背包。」Wade 拿它说明变革型长什么样：模型能力猛地往前蹿了一大步，这位负责人的反应是「有了这些新能力，我也能让我们的工作方式跟着猛地往前蹿一大步」——受益的不只是他自己，而是整个产品团队的干活方式。→ 详细

▲ 图注：Aakash 在 ChatGPT 画布里写的第一份 PRD「PRD: Zapier IDE Harness for Claude Code」，Problem 一节列出开发者现状的 8 个步骤。

• 出题方式：Aakash 当天早上专门做了几份 PM 产出物，让 Wade 当场点评——「最后打几分倒没那么重要，重要的是一个 CEO 会怎么看 PM 的工作成果、怎么看 PM 用 AI 这件事」。第一份的点子是：如果 Zapier 给 Claude Code 做一个 IDE harness 会怎样（IDE 是写代码的集成开发环境；harness 指包在模型外面、给它配工具和流程的那层「挽具」）——「谁知道这到底是不是个好主意」，所以他以 PM 的身份写了份 PRD。→ 详细
• 写法：用 ChatGPT 写，给过几轮 prompt、迭代过，「不是我的第一稿」。→ 详细
• PRD 里有什么：概述写的是这对自动化工作流很重要，Zapier 有成千上万个集成、深懂工作流怎么运作，所以有独特优势——把 Claude Code 和 Zapier 自动化平台结合起来；问题是在 Claude Code 里写 prompt、配置应用、再部署，整个过程是割裂的，Claude Code 调 API 时还可能出错；目标用户是软件工程师和创始人，用户故事是「作为一名使用 Claude Code 的开发者，我想搭建和测试 Zapier 自动化，而不用来回切换」；方案是用户和 Claude Code 交互，由 Claude 帮忙把工作流搭出来、再做测试，关键功能里还带 AI slop 检测。→ 详细
• 指标与愿景：附了一个简单的 MVP；北极星指标（团队最该盯的那一个核心指标）定为「通过这个 IDE 成功部署的工作流数量」；风险是开发者可能更愿意直接用 Claude Code，但他判断开发成本不高；愿景一句话——「Claude 来写自动化，Zapier 负责确保它真的能跑通」。然后他问 Wade：「这份东西是我用 AI 写的。你觉得我做得怎么样？」→ 详细

• 先拆成两层评：Wade 说评这份东西其实有两部分——它在 AI 流利度上该打几分，以及它体现出来的整体产品思维该怎么打分。产品思维这层他先给了肯定：「这其实是个挺有意思的点子」，产品直觉「相当有眼光」——意识到出现了一种构建自动化的新方式，把 Zapier 的连接库接到 Claude / Claude Code 上帮忙构建，是有价值的。→ 详细
• 他替 PRD 补的一条价值：有一点他没看到（「也许写了，你翻得太快我没来得及看」）——把这些自动化部署到 Zapier 上运行价值很大，因为 Zapier 能以确定性的方式运行它们（deterministic：同样的输入每次走同样的步骤、得同样的结果，不像大模型每次都可能不一样），这能带来更低的成本、更高的准确率。→ 详细
• 第一个维度：为什么止步于 PRD：一个「彻底 AI 化、信奉 AI 最大化的产品经理」还能往前走，第一步就是把第一版原型做出来——「打开你最顺手的 coding agent，开始看看你能做出什么原型、搭出什么东西」。他特意强调：「这里的重点不是让产品经理去写生产级代码。重点在于眼见为实」，而现在 PM 把想法变成看得见摸得着的东西比以前容易太多；「一图胜千言，那原型差不多就是再乘以 10」。这是他最希望这份东西更强的一处——「一个彻底 AI 化的人大概会在这里拿出点让人眼前一亮的东西」。→ 详细

• 第二个维度：证据在哪：「这背后的客户证据在哪儿？」不管通过什么途径都去找——翻 Zapier 的 Gong 通话录音（Gong 是记录并分析销售通话的工具）和 Zendesk 工单（客服工单系统），去各个 subreddit、LinkedIn、X 上筛一遍：大家在哪儿抱怨这类问题、在哪儿表达过想要这种东西，以此判断「我对这个产品形态的把握对不对」。这事不用 AI 也能做，但 AI 让你能在很短的时间里筛完「堆积如山的数据源」，换作过去做不到。→ 详细
• 证据还要回答凭什么是 Zapier：Aakash 自己在 PRD 里提了「开发者可能更愿意直接用 Claude Code」——那 Zapier 在这之上的独特价值到底在哪？Wade 说把大量这类客户细节筛一遍，就会帮你建立、强化那种直觉：「这里确实有一块是只有 Zapier 能拿下、能在上面创造价值的」。→ 详细
• 两件事都不多花时间，变的是 buy-in 的时点：放在过去，要么是「我不会做原型，所以这事我压根干不了」，要么是「在我花上几周去做之前，我得先争取到一些支持，确认这件事哪怕只是在方向上值得做」；而现在，「争取支持这一步可以往后放很多，你自己就能先往前走得远得多」。等你来找他说「咱们给这件事加把劲吧」时，你已经攒下堆积如山的证据，他说「好，就这么干」的可能性大得多；又或者你自己已经想明白「其实这就是个很糟糕的主意」、怎么也找不到让自己特别兴奋的东西，那就先搁置。「这就是 AI 加持的 PM 身上那些过去没有的超能力。」→ 详细

• Aakash 预设的分数：Aakash 说大家刚上了一堂「怎么写好 PM 文档」的大师课，核心是「不能只停在 PRD」。他坦白这份文档是刻意设计的：放在 2024 年会被打「胜任」，到了 2026 年就差不多「不合格」了（他原话在这里把档位顺序说得有点乱，只取这层意思），问 Wade 公不公平。→ 详细
• Wade 认同，而且嫌它慢：「如果 2026 年有人拿着这份东西来找我，我会觉得它有点过时了……有不错的产品直觉，也有一些不错的思考，但天哪，你本来可以走得远得多。」他的本能反应是「把文档直接给我，我自己开始去做其中一些事」——「我真的会直接拿你的 PRD 扔进 Cursor（一款 AI 代码编辑器），说『嘿，帮我把这个做出来』，然后看看会发生什么」。→ 详细
• 一条经验法则：你得比 CEO 更懂自己那一行的 AI：「在你自己的专业领域里，你大概应该比你的 CEO 走得更靠前。」Wade 给自己的 AI 流利度打分是「在大多数方面大概是适应型」；但说到在 PM、市场、工程这些岗位上做到 AI 流利，「我应该落在你后面才对」，因为你「每天一睁眼就泡在这些东西里」。所以「如果我发现有些东西对我来说显而易见、对你却不是，我就会想：哦，这让我有点紧张」——接着就会想该怎么把这个问题解决掉。→ 详细
• Aakash 的提炼：AI 流利度和好的产品思维「很难简单地分开」，在这个时代几乎是合在一起的——要做好产品思考，你得去看过 Gong 的通话录音、看过 Reddit 上的评论，而现在 AI 能帮你筛掉其中一半。→ 详细

▲ 图注：Aakash 共享的 LinkedIn 帖子里的 2×2 图：纵轴用不用 AI、横轴判断力好坏，四格为 Slop Cannons、Turbo Brains、Dead Weight、Steady Hands；图底水印 www.danhock.com。

• 全交给 AI 的下场是平庸：Wade 说你完全可以把他刚才说的全让 AI 包了——直接把 PRD 往 coding agent 里一扔、让它出第一版原型——但产出「可能就是相当平庸、毫无亮点」。这正是人真正要紧的地方，「很多人管它叫品味、判断力」：真正理解客户的问题、对怎么解决有直觉，「把这些结合起来，你就能做到卓越。但如果你就放手让 AI 把所有事都干了，你大概只会得到平庸的东西，得到大家所说的 AI slop（AI 糊弄出来的垃圾内容）」。→ 详细
• 一个 2×2 框架：Aakash 抛出 Faire 的 Dan Hockenmaier（按读音与图上水印 danhock.com 推断）提出的说法——判断力不行又用 AI，会变成一门「slop 大炮」（slop cannon）；判断力好又用 AI，能变成一颗「涡轮大脑」（turbo brain）。→ 详细
• 好判断 + AI：像在见证新物种：Wade 觉得这说法「很好笑，也很有画面感」，是个挺合理的框架。他共事过判断力出色又用 AI 的人，「光是看着他们干活，你就会觉得：哇，看这个人干活真是太不可思议了……简直就像在见证一个新物种被发明出来」。→ 详细
• 坏判断 + AI：比不用 AI 的人还难搞：他借社交媒体虚假信息论战里那句老话——「真相还没起床，谎言已经绕着世界跑了两圈」：判断力不行的人用 AI 能生成海量东西，「光是把这些东西一个个拍掉就得花好大力气」，还得一遍遍说「这不是我要的」。所以跟这些人合作，在某些方面反而比四象限左下角（判断力不行、也不用 AI）的人更费劲——「那种人吧，好歹你还挺安静的，对吧？」利弊他说还得再想想，但「乍一看……我有同感」；Aakash 补一句，它能小火一把不是没有原因的。→ 详细

• Zapier 关于 slop 的那句话：「活可以委派出去，责任委派不出去。」→ 详细
• slop 的本质是把判断甩给别人：Aakash 说团队里有人发来可能算 slop 的东西时，等于「自己没动用判断力，把这份责任甩给了我」——「这个可能还行，你帮我判断一下？」这跟想在公司里往上走该做的事正好反着来：你应该给别人经过筛选、有质量的信息。→ 详细
• 职场正在磨合一套新礼仪：Wade 跟很多人聊过「公司内部 slop 越来越多」的问题，Zapier 开始做的一件事是「一上来先坦白说清楚：嘿，这东西到目前为止花了多少功夫？」他自己分享文档时会分档说明。低档是：「这份我用了 AI 帮忙起草，我自己快速扫了一遍」——最明显的烂东西已经删了，还没从头到尾仔细过，但因为「现在速度真的很重要」，先发出来请你看。高档是：「每一个论断我都认，每一句话都经过我一丝不苟的审阅。」分档的目的，是让读的人明白这份东西到底花了多少功夫。→ 详细
• 可以发 slop，但要先定预期：「有时候直接分享一份可能纯属 AI slop 的东西也没问题，但你得先给读的人定好预期」，让他知道该期待什么质量。他承认 Zapier 还没把这件事做到完美；真正让人难受的，是把它包装成很好的东西交上来，读的人却一眼看出「你压根没花一点功夫，现在还要我来替你干活——那你当初还不如直接让我来干这活」。→ 详细
• Aakash 的意外收获：用点 AI 可以；追求速度时有一点 slop 也可以；用 AI 不必每次都做到变革型——「只要你事先说清楚、保持透明就行」。→ 详细
• Wade：标准看场景，判断力是终极能力：这些说到底是工具——给客户的对外产品是一种标准，「又快又糙的小活儿」是另一种；归根结底要看那张四象限图右半边：有没有好的判断力。「判断力在很多方面可以说是终极能力……你得把脑子打开。」脑子开着，多半落在好的那一边；把脑子关了，多半会很吃力。→ 详细

▲ 图注：第二份 PRD 的可点击原型页（标注 CONCEPT MOCKUP · NOT SHIPPED），大标题「Your agent already has the connections. It just can't reach them.」，左侧终端跑完一遍流程，最后弹出 Slack 发消息的人工审批。

• 先原型：Aakash 特意沿用同一个功能，方便对比；这次预判到该从原型做起，还加了点 Zapier 的品牌元素。pitch 是「你的 agent 手里有这些连接，只是够不着它们」——Zapier 握有 8,000 多个应用的授权访问（他说现在可能还不止），如果 coding agent 真能用上它们，会是什么样子？（提醒：Aakash 不是 Zapier 员工，整份东西是他「以 PM 的身份」扮演出来的演示稿，下面的数字都是道具。）→ 详细
• 原型演示：装上 Zapier、连接一次，就能批准一条 Slack 消息，甚至发出「Jira 删除工单」这类操作，全程快得出奇；它找到 6 个连接、选中其中 3 个，查看了 14 个 Jira 自定义字段，列出哪些工具已预先批准，还给出 payload（要发出去的那包数据）的预览。最关键的设计一闪而过：那个 Jira 删除操作被拒绝了——因为是破坏性操作，被标记了出来。Aakash 说这正是 Zapier 的 harness 能加、普通 Claude Code 可能做不到的东西，因为 Zapier 有很多企业客户；这些操作还能在 Zapier 的历史记录里回放。→ 详细
• PRD 这次是一个 markdown 文件：不再只是聊天窗口里的一段对话。核心是装一次、连一次；有一个策略文件（policy file，写明哪些操作放行、哪些要拦）；想解锁的闭环是：Sentry（线上报错监控工具）出了个 issue，agent 能去读、去改、去 Jira 建单、去 Slack 发消息，全部借助 Zapier 的连接和策略完成；技术强不强的人都能搭起来。→ 详细
• 补上的证据：Gong 上 2 月到 7 月的 47 通通话里，有 34 通客户在没人提起时主动聊到 agent 工具；Zendesk 上 312 张工单打着 MCP 或 AI agent 标签；社区 Discord 里 1,800 多条帖子提到 MCP（Model Context Protocol，让 AI 调用外部工具和数据的开放协议）；9 次设计合作伙伴（design partner，早期共建客户）访谈，对方都自己搭过 MCP server。结论：瓶颈在权限、不在连接；工具太多会让 agent 变差，而且用户已经知道；长尾真实存在。→ 详细
• 试点与请求：一个 6 家设计合作伙伴参与的小试点，假设是「只要闸门设计得好，开发者就愿意让 agent 对生产系统执行写操作」——结果 6 家里有 5 家至少开启了一项预先批准的写操作。再过了其他几个假设、从战略契合度通盘看一遍，结论是做一个 Claude plugin，「本质上是个 harness，不是 connector」，并写了指标和风险。向 Wade 的请求：现在去跑 10 个设计合作伙伴、做一轮 legibility bake-off（可读性比拼）、开始研究安全问题；批准的话，Q4 推出 beta。→ 详细

• 两处批评都补上了：「对照我在上一份里给你的批评，我点出的两件事你基本都做到位了：一是这个应该做成原型，二是证据在哪儿？」所以「一上来这份就强太多了」。→ 详细
• 现场把反馈喂回 agent，是接近变革型的打法：Wade 甚至怀疑 Aakash 是不是把这段实时转写喂进了某个 coding agent、让它现场改好——他在 Zapier 见过有人这么干，「每次都感觉很神奇——你就是把对方正在跟你说的话，原样直接喂回给对方」，对方一看到冒出来就会说「太好了，太厉害了」。不管是现场改的还是提前预判到的，「这正是好的产品判断力的神奇之处」。→ 详细
• 该逼的地方：请求太慢：「为什么要等到 Q4？你都已经走了这么远了，能不能更快一点？」AI 工具让你「从零到拿下设计合作伙伴，可以快得出奇」；Q4 就是 10 月，「好家伙，还有五周呢……这五周我们要干什么？」他会重点追问的，是怎么让迭代周期「转得快得多、再快得多」。→ 详细
• 评级：「给我的感觉是稳稳的『适应型』……就眼下这个阶段来说，如果整个 Zapier 的 PM 工作都能达到这个水准，我会非常满意。」如果 Aakash 真是现场听反馈再喂回去，那「就开始相当接近『变革型』了」——他已经开始看到有人这么做，但还不是被广泛使用的打法，「如果你真是这么做的，那我会说：干得漂亮」。→ 详细
• 露馅的细节：Aakash 说他现场唯一做的，就是把「从 Gong 拿到了什么」写清楚——prompt 是让 AI「假装看过 Gong 的通话录音」。（他还说自己本来是冲着「胜任」去的、没做到——他在节目里似乎把档位高低记反了；按 Wade 的表，适应型比胜任高一档。）Wade 笑说露馅的正是它把 Gong 和 Zendesk 都列了出来，「这不正是我刚才举的那几个工具嘛」，一看就是「AI 在一字不漏地听我说话」——「AI 很多时候就是带着那种过分具体的劲儿」。→ 详细

▲ 图注：第三份产出的架构图「The deep agent setup in Claude Code」：skills、并行子 agent（含唱反调的 skeptic）、直读记录系统、确定性 hooks、以仓库为记忆，共五层。

• 冲变革型：第三份不再是单份 PRD，而是「如果你看到我这样带一个产品团队」的整套打法；Aakash 说从 agent 的标题就看得出他想冲变革型。他用两张图展示自己的 agent 栈，是一个五层架构。→ 详细
• 第一层 · skill 库：一组专门处理团队反复要做的活的 skill——PRD、prep（会前准备）、eval（评估）、recall（回忆检索）、ingest（资料导入）、影响测算、上线检查清单、每周复盘，另外还有 37 个。→ 详细
• 第二层 · 编排层，带一个专职唱反调的：subagent（被主 agent 派出去干分工活的子 agent）在这里并行分头展开——工程、设计、高管、法务、UX、信任与安全，还有一个 skeptic（怀疑派），「它专门主张什么都不该上线，因为我们都知道，我们不想要功能膨胀」。→ 详细
• 第三层 · 工具与 MCP：Zendesk 和 Gong（他说这是听完 Wade 的点评后唯一改动的地方）、Reddit；数据分析和工单他假设用 Amplitude 和 Linear；设计用 Figma（「虽然说不定你们现在都在用 Claude Design 了」），再加 GitHub 和 Chrome。→ 详细
• 第四层 · 确定性强制约束（他认为最重要）：在每次工具调用之后（译者推断对应 Claude Code 的 PostToolUse 这类 hook，即在特定时机自动触发的脚本，存疑），只要证据没有出处，就拒收这份记忆文件——所以放进记忆里的每样东西都有扎实的出处；而且只要大脑还处在「脏」状态（有没整理完的东西），就不让会话结束。这样大脑会一直保持更新。→ 详细
• 第五层 · 记忆层：整个产品团队在产品上学到的东西，出处都记在这里。导入环节里，agent 会自动产出几类内容：从 Zendesk + Gong + Reddit 得出的假设、从 Linear 工单和 GitHub PR 里得出的决策、从 Gong 和 Reddit 找到的研究、会议纪要里各方干系人的说法。→ 详细

▲ 图注：「One loop, running nightly」：原始客户信号进夜间 Triage swarm，经两道橙色人工闸门，产出原型、5 次用户测试和早期 PR；底部三个数字 9d to 2d、38% to 96%、4 to 1（口述是 10 天压到 2 天）。

• 每晚一轮的分诊 swarm：第二部分是围绕 agent 栈搭的自动流水线——原始客户信号进来，一批自动 agent 靠每晚的 cron 定时任务运行，他管它叫分诊 swarm（一群并行跑的 agent）。它们先去重，再按 job（用户想完成的任务）聚类；往 source 文件夹里填内容（「希望大家现在明白这为什么那么重要了」）；给每条内容打上「观察 / 解读 / 假设」的标签；再拿去比对还在待验证的假设，把矛盾标出来。→ 详细
• 一夜的产出和 PM 的四五分钟：比如一夜之间从所有信号里得到九簇洞察，其中两簇是新的（可能是 Reddit 论坛上冒出了什么），甚至有一簇跟三月份下的某个赌注相矛盾——这些都由 swarm 识别出来。接着 PM 借助记忆层介入，判断要不要往上提：有没有相互独立的来源？「如果只是 Reddit 上某一个人说的，我们不在乎；但如果 Reddit 和我们的 Amplitude 数据都显示出来了，那可能就值得关注了。」他花四五分钟过一遍，系统会帮他把假设和决策记录下来。→ 详细
• 自动构建链：每一步都依赖上一层——先快速写一份两页的 PRD，接着过一轮 PRD 评审小组，然后做原型，然后写 eval，再产出代码初稿；最后拿到原型链接、用户测试、草稿 PR 和 Linear 工单。→ 详细
• 两道人工关卡（human gate）：第一道是「这条构建链值不值得我们关心」，第二道是「要不要合并」；不合并也好、跑完也好，结果都放回记忆里。整套东西由一些 hook 驱动，核心想法是把「比如说 10 天的开发流程，压缩到两天」。然后他问 Wade：「如果你看到我这样带一个产品团队，你会给我的产出评什么级？」→ 详细

• 完全不同的工作方式：「这绝对已经开始进入变革型的范畴了。三年前，产品和软件根本不是这么做出来的，差得远了。」它看起来更像一座工厂：你作为 PM、工程师或别的什么角色，工作不再是亲手完成每一项具体任务——agent 已经在处理这些任务，「现在你的工作其实是审查这个系统」：agent 失败了，它为什么在这个任务上失败？→ 详细
• 工厂比喻：别修零件，修机器：「如果工厂生产出一个残次零件，工厂里的人会怎么做？他们会一个个去修这些零件吗？不太会。他们会直接把那一批报废，然后回头去检查机器：为什么这台机器会生产出这些残次品？」以前是人像机器一样把流程里的每一步一件件冲压出来，现在这些被换掉了，人的工作变成审查整个系统、判断它到底行不行——「这是一种非常不同的软件和产品团队运作方式」。→ 详细
• 没人知道这座工厂该怎么跑：「我们所有人都在琢磨的问题是：这座工厂到底该怎么运转才对。」Wade 说他刚才一直在很认真地听 Aakash 的系统是怎么设计的，因为他跟很多在搭这类东西的人聊过，「在『这些循环究竟怎么跑最好』这件事上，目前还没有形成共识」。→ 详细
• 核心设计题：人工关卡放哪、为什么：他一直想弄明白的是「你把这些人工关卡放在哪儿？为什么决定放在这些位置，而不是别的地方？」一种选择是拿掉第一道关卡——对所有事情都直接启动 coding agent，再去审查跑出来的东西；另一种是保留它，因为「很多这类东西在烧大量的 token，我们在可能纯属浪费的事情上花了很多钱」，所以哪怕拖慢整个系统，设一道人工关卡也值得。很多团队正对这个循环的具体设计「挠头琢磨」，坦白说很多人还没走到这一步，但它正变得越来越普遍。结论：「这已经开始迈进变革型那一档了。」→ 详细

• 变革型的门票确实是这套系统：Aakash 追问——虽然一开始说过没必要一直待在变革型，但如果经理让你冲一冲，那在 2026 年搭一套像这样运转、而且真正跑得通的系统，就算变革型了？Wade：「对。」→ 详细
• 但要看公司多大：在小公司，比如你是唯一的 PM，「那没错，你大概就得自己搭一套这样的系统，因为还有谁会做呢？」可到了 Zapier 这种有相当多 PM 的规模，「不是每个人的工作都是去琢磨、去搭这套系统」：可能是一个团队说「好，我来搭这个」，或者几个团队做几个变体；其余 PM 的切入点是「帮我想想这套系统该怎么运转」。少数几个人处在「变革」那部分、把东西全部重做一遍；同时也有 PM 还按老一套标准打法做事，偶尔过来当新工作方式的用户测试员——新旧两套并行推进，「这多少要看你的组织是怎么搭建的」。→ 详细
• 一座工厂，而不是 30 个迷你版：「我不需要我所有的 PM 都放下手头的一切去重建这套系统……我记得我们 Zapier 大概有 30 到 40 个 PM——我不需要 30 套这样的循环同时在跑。」他希望只有一种做法，或者因为 Zapier 内部有几类不同的工作而要几种；「目标不是每个人各跑一个自己的迷你版本」，而是会有一个类似 Zapier 产品工厂的东西，承担这里面的很多工作。→ 详细

▲ 图注：Wade 的演示页「My robot executive staff」，五张 agent 卡片依次为 Scout、Scribe、Strategist、Prospector、Dossier。

• 先说清楚这是什么：Aakash 请他秀一点 Zapier 内部的独门秘方，Wade 展示的是「我 Wade 个人的 agent」，不是 Zapier 的生产系统。演示页面是他让 agent 搭的，里面把他的 agent 分成几类：机器人员工（robot staff，真正在帮他运转日常事务的 agent）；CEO CRM（跟前面那种生产级 agent 要接近得多）；一个会跟他唱反调的 AI（「这是个简单的东西，你可以做，而且大概也应该做」，有点像 Aakash 那套产品循环里的 skeptic）；还有一堆处理各种实时助理事务的可执行 skill。先看机器人员工——这是他搭好的五个比较常用的 agent。→ 详细
• 晨间简报：入门首选：把一个 agent 接上日历、收件箱、Slack 之类，跟它说「嘿，我要你每天早上给我整理一份每日简报」——尤其如果你还不习惯搭 agent、不习惯把它接到各种工具上，这个非常容易。他的设在每天早上 6 点跑，而且是放在 Zapier 上跑。→ 详细
• 重点是确定性执行：放在 Zapier 上、而不是交给 Claude Code、Codex 这类工具去跑，方便之处在于 Zapier 会以确定性的方式运行：每天 6 点启动、去拉日历事件——「跑这一步的不是 agent，是代码」。好处是可靠，「每一次都以完全相同的方式运行」；成本也低得多，这些步骤全都不烧 token，只有做总结、真正起草简报那一步才烧；之后发到 Slack，又只是一次直截了当的 API 调用。→ 详细
• 只接日历会不会漏上下文：Aakash 唱反调——它只接了 Google 日历，会不会漏掉上下文？Wade 说代码那一步还会去调他的待办清单；日程上常附着文档，它会点进链接、抓取附件再做总结。日历和待办清单「大概是你最该给它开权限的两样东西」。这种半确定性的 agent 特别强：必要时它还能退回去用更像 agentic loop（agent 自己边想边调工具的循环）、更偏推理的方式——「在你在乎的地方，你拿到确定性；在最需要的地方，你又能用上 agent 边推理边把任务做完的能力」。→ 详细
• 怎么搭出来的：Aakash 说他在 Zapier 身上看到最棒的一点，是可以直接给 AI agent 下 prompt 让它把工作流搭出来，不用自己写代码。Wade 补充，他基本就是跟 Cursor 对话、让它把这些搭出来，再部署到 Zapier 上去跑——「这样一来，我晚上可以合上笔记本，让它确定性地跑着」，不用忍受现在很多 agent 产品逼你做的那些笨拙操作：一切都在本地跑，还要烧掉大量 token。Aakash 的总结：本质上就是一个云端托管的自动化。→ 详细

• 晨间简报其实价值一般：虽然他总跟人说从晨间简报起步，因为它简单好上手，但「我其实觉得它的价值一般」。他最喜欢的是书记员（the scribe），换个角度看就是每日复盘（daily recap）——「每日复盘的价值要大得多」。→ 详细
• 书记员干什么：每天下午 5 点跑（也可以开完会后跑）。它把所有还没处理的邮件过一遍，把 Slack 里标了「稍后处理」（save for later）的消息过一遍；重头戏是把当天所有 Granola（AI 会议记录工具）的会议转录过一遍，提炼出「根据今天的情况，这些是你需要完成的所有事项」，并且先起草好。比如聊天时对方说「Wade，能帮我引荐一下某某吗？」——Granola 捕捉到这句，它就起草一封跟进邮件；待办清单里还没完成的事项，它会问「要不要我先试着帮你写起来？」→ 详细
• 省了多少时间：收工前的清理「以前要花我——天哪，大概每天收工都得花两个小时」，现在「大概只要 15 分钟，而不是两个小时」，「对我来说，这是生活质量的一次大提升」。他说 PM 都懂：一天到晚不停地攒待办，有些真的很重要，有些只是为了做个好队友，以前只能硬着头皮一件件啃，现在书记员帮他啃得快多了。Aakash 笑说，难怪一个 CEO 还跟得上他那些约播客的邮件。→ 详细
• 议程 agent：高管会、董事会都在用：周会的议程怎么定？Wade 自己作为 human in the loop（人工把关）参与，但大体上所有议程条目都是 AI 生成的，高管会和董事会都这么做。它把这一周所有的 Granola 会议记录、Slack、邮件，连同他跟各种 AI 工具的聊天记录全过一遍，列出「仍然悬而未决、你需要拿出来讨论的最重要的事」；他再审一遍，批准或否掉。效果是议程「比过去切题得多」，在「该讨论哪些议题」上它的判断通常也更好。→ 详细
• 专治心头好议题：定每周议程最难的，是大家都带着各自的「心头好议题」来，可它们真的是最重要的事吗？如果让它把上周所有指标过一遍，AI 就会说「你们这块上周的转化率烂透了，你们得讨论一下这个」——「别让大家就这么躲过去、不把这事摆上桌」。前提是对准正确的数据源，并给它一点点名「这些议题必须处理」的能力。之后他提了一句还有个拓客员（prospector），没展开，直接转去秀 CEO CRM。→ 详细

• 自己打自己的脸：网上一直在争「你到底该不该 vibe code（凭感觉让 AI 生成代码、自己不细看代码）一个自己的 CRM」，Wade 说他「非常坚定地站在『别 vibe code 你的 CRM』这一边。可结果呢，我自己却 vibe code 了一个 CRM」。→ 详细
• 它其实是个 agent，不是个界面：「这东西超级基础」，跟 HubSpot、Salesforce 那类开箱即用的差得远；本质是一个专门处理他个人在乎的一组具体工作流的 agent。他一开始把它当成拿来看的 CRM 去搭，现在主要作为 agent 在跑、平时很少看界面——展示 UI 只是因为「不给你们看点东西的话，agent 很难演示」。它能访问所有企业客户和每个客户身上的 ARR（年度经常性收入），根据一大堆信号标出哪些要关注：快续约了吗？用量在下滑吗？点进去能看到客户在用哪些应用、基本情况、对接的人。→ 详细
• 每周六夜里跑一次：所有这些上下文最终指向一件事——「我想多跟这些客户聊聊」：该跟谁聊、为什么聊。它每周六晚上跑，等他早上醒来，收件箱里已经起草好 10 到 20 封邮件，发给他想保持联系的企业客户，并附上理由：快续约了；用量下降了，或者在很多方面上涨了；以及该聊些什么。草稿就放在他真实的邮箱里，他看一眼、说「嗯，这个人我确实想去聊聊」，一口气发出去，有时快速改几笔——一个本来每周都相当繁琐的工作流就这么办完了。→ 详细
• 为什么要 CEO 亲自发：以前这类维系由客户成功经理（CSM）团队做，「我们的客户成功经理都很棒，但大家真正喜欢的，是收到 CEO 本人的消息」。现在他能跟其中一些最重要的客户建立起牢固得多的私人关系，这在以前很难做到。→ 详细
• 最难的是文风，不是逻辑：Aakash 指出邮件是 Wade 的口吻、通篇小写，写法就跟他本人一样——结合前面聊的 slop，想让 agent 帮忙起草，就得反复打磨配置、确保写出来的东西拿捏到位。Wade：「说来好笑，这恰恰是整个东西里最难的部分。搭 CRM、把整套 agentic 逻辑弄好，这些跟『硬掰着这些 agent 像人一样写东西』比起来，简直太容易了。」到现在它也只是做得还行。他还有一个没放进演示的 agent 专门做效果分析：看出哪种写法、哪类邮件标题效果更好，就多用那种。→ 详细
• 他真正兴奋的点：做产品的人想做的事有一百万件——多陪客户、把邮件写得更好——「可你一个人就是没法把它们都做得足够好」。「你脑子里可以有一个标准——嗯，优秀就该是这个样子。那我怎么用这些工具，让我即便只是个凡人，也能做到优秀？毕竟……我就是不可能时时刻刻都那么优秀。」→ 详细

• CEO 的自评：Aakash 问他是不是只给自己打了适应型。Wade：「说实话，我觉得我在很多方面是适应型」，自己在这些事上就是个「超级通才」，团队里有人在很多方面都比他强得多——「我往变革型推进的时候，说实话，就是在偷师他们」：去看他们在做什么、怎么琢磨明白的，再把打法套到自己的工作流上。而在公司和团队层面，有些人比他琢磨明白的多得多，「不只是自己怎么用，还有怎么搭出能服务我们所有客户、全体员工的系统」。他的结论是自己「有时候是胜任，有时候是适应型」，能算变革型的地方「真没多少」。→ 详细
• 变革型 = 第一个吃螃蟹的人：Aakash 说他原本以为大概 20%、30% 的人能落到变革型，看来不是，这一档门槛应该定得非常高。Wade：「在这件事上，世界上真正称得上变革型的人没那么多……变革型真的就意味着你是 n of one（独一份，n=1）：你是第一个做这件新事的人，而且正在把它摸索出来。」所以这个门槛「极其高」。→ 详细
• 落到分布上：Aakash 追问：如果我是产品负责人，在一个 30 到 40 人的 PM 团队里，是不是每半年大概只该给出一个变革型评级？Wade：「也许吧？是的……这个比例应该挺低的。」（这个「半年一个」的具体说法是 Aakash 提的，Wade 只是认可「比例很低」。）→ 详细

• Aakash 的尖锐问题：他说 Zapier 和 Airtable 在 2021 年估值都很高——他记得 Zapier 那个 50 亿美元的估值其实来自某种卖给 Sequoia 之类的老股转让（secondary，老股东把股份卖给新投资人，公司本身不拿钱）——而 Airtable 现在好像连当年那个数的 10% 都不到（均为 Aakash 的说法）。Zapier 2012 年起步，2021 年到了高点，现在业务处在什么位置？是不是只剩当年价值的 10%？→ 详细
• Wade 的回答：「我们 2021 年以来是有增长的。」Zapier 特别的一点是「从 2012 年以后基本就没再做过新股融资（primary capital，公司增发新股、钱进公司账上）」，所以估值对他们没那么重要——「估值其实只在一个时间点上真正有意义，就是发生交易的那一刻」。目标一直是给客户做出特别棒的自动化产品，其余的让它顺其自然；过去几年的核心驱动力是「怎么用好这些厉害的 AI 工具，让大家用这种新方式搭建和运行自动化变得容易得多」。他没有给出营收或最新估值的具体数字。→ 详细

• 无代码末日：Aakash 说大家都管现在叫「无代码末日」，而 Zapier 是这个领域的领头羊——一边在增长、一边是末日，是做了什么适应，还是末日被夸大了？→ 详细
• 新的无代码就是代码：Wade 说他们逐渐形成的信念是「新的无代码，就是代码」——刚才演示的每日简报就是底层代码在跑。无代码产品得重新思考底层架构：Zapier 在很多地方把自己的能力——触发器基础设施、动作基础设施、运行时环境、治理层——开放给 coding agent，让它们替客户去搭。因为现在太多非工程师在用这些工具写代码，却从来不看代码：「我其实并不知道我那个每日简报底下的代码到底在干什么……我自己从来没真正看过，也不太在乎，因为这个每日简报对我来说好用就行。」→ 详细
• 无头化（headless）才是 SaaS 的价值：SaaS 老牌玩家要想明白的是怎么把能力开放给这些工具，好让人在上面创造价值。他举 Benioff 讲 Salesforce：「Salesforce 现在已经无头化了」（headless：不依赖人登录界面操作，直接通过接口被调用），价值「不是你登录进去的那个 UI」，而是底层的 API、MCP server 这一整套把能力开放给 coding agent。→ 详细
• 你的软件的用户现在就是 agent：Aakash 提到大约一年半前请过 Zapier 的 CTO 兼联合创始人 Bryan 聊 Zapier MCP，问所有 SaaS 是不是都该无头化、都该做 MCP。Wade：「我觉得是的。」没有人想上班后登录你的 SaaS、坐那儿录数据；过去十年的 SaaS 干活的仍然是人。Zapier 一直是替你干活的工作流自动化工具，唯一还得人来干的就是把自动化搭出来——登录、点一大堆东西，甚至得先想清楚要自动化什么（「在有些场景下，想清楚要自动化什么，其实比搭建还难」）。现在如果能把上下文、智能和搭建工具都开放出来，「你的软件的用户现在就是 agent」，人被解放去做真正属于人的事——需要判断的部分，比如琢磨「这到底对不对」。→ 详细
• B2B 先想反了就逆水：还把软件想成「有一个人类用户会来用」，「至少在 B2B 是这样」有点想反了（B2C 的消费者行为会有些不同）；在工作中，「我想要的是把这些事委派给别人，让对方替我去用」，而这个「别人」越来越多是 coding agent——「如果你的软件不是无头的，或者没法以无头方式运行，我觉得你会发现自己有点像是在逆着水流游泳」。Aakash 自嘲：看来他那份 PRD 跟 Zapier 的战略没对齐，因为它是围绕人类用户、而不是 agent 用户写的。→ 详细

• Aakash 点名的对手：Lindy 的 CEO 上节目时说 Cowork 给他们的业务带来了相当大的负面冲击，不得不重新打造自己；n8n 的 CEO Jan（Aakash 也在跟他录节目）那边 ARR（年度经常性收入）从 700 万到 4,000 万、又从 4,000 万到 1 亿美元，刚以相当高的估值融了一轮。问 Wade 怎么针对 Lindy、Cowork、n8n 做反定位（counter-positioning，选一个对手因自身包袱难以跟进的打法）。→ 详细
• 好消息坏消息：Zapier 做了 15 年，大部分时间赛道不拥挤，「差不多是独此一家」，这让他们搭起「一个至今没人比得上的集成库」——接入了 9,000 多个工具，「大家一直说写集成代码越来越容易了，可还是没人追上我们」。好消息是对自动化的需求「高到天上去了，从来没这么高过」，市场比创立后头十年大得多；坏消息是市场一大，新思路、新做法和竞争对手也多了很多。这逼着你「拿出产品思维」做战略选择：到底专注什么、要在什么上做到出色。→ 详细
• OpenAI 与 Anthropic 的例子：OpenAI 算是这场竞赛里最早领跑的，各种方向都在追；Anthropic 则说「我们就专门做代码，我们要在代码上做到最好」——这让它脱颖而出，也反过来逼 OpenAI 在「我们为谁服务、要在哪里赢」上清晰了很多。市场这么大、很多玩家都能成功时，每家（Zapier、Lindy、n8n 都一样）都得回答：独特的价值主张是什么、围绕哪一类客户去做。→ 详细
• Zapier 的答案：帮你运行这些自动化，而且以确定性的方式运行——不用一直烧 token，也不用一直开着笔记本；同时依然有 agent 的能力来搭建和管理它们，所以搭起来非常容易；而当它们出故障、以意想不到的方式失败时，agent 也能帮你恢复。「我们一直在增长的地方，就是帮大家获得这类能力。」→ 详细

• 正片：没有给出嘉宾的联系方式或账号。
• 视频简介列出的 Wade Foster 账号：LinkedIn：https://www.linkedin.com/in/wadefoster · X：https://x.com/wadefoster
• 片中提到的资源：Zapier 对外公开的 AI 流利度评分表 V2（2026 年 3 月 31 日发布，按岗位分栏；Wade 说内部版在那之后又改过一些内容）。→ 详细