Figma 产品经理的 AI 工作流：31 个skills、2 个agent、1 个 Jev

Figma 产品经理的 AI 工作流全景

Figma 增长产品经理 Ezra Mechaber 最近参加了播客 How I AI，分享了他每天如何使用 AI 辅助工作：31 个日常 skill、2 个测试和实验 agent、1 个 Jev 写作助手。

Ezra 的日常工作是上线实验，看哪种方案效果更好。做增长最担心浪费流量，如果有流量却没有实验在运行，这段时间就白白浪费了。所以他一直在想，能不能把自己的这份工作也自动化掉，现在这个 agent 已经做出来了，叫 AutoXP。

AutoXP 有自己的 Slack 频道，在频道里发一句“去设置页找一个可以做的实验，放开做”，它就会调用一个数据科学 agent，去看漏斗、找用户在哪一步流失。AutoXP 的第一个实验就发现了一个很大的提升，现在一位工程师在运行它，线上同时有 5 个实验，Ezra 自己还没看过。

AutoXP 之前，他先把自己做得最差、经常忘记做的工作交给 AI，比如发布新功能前通知客服团队、写会议记录。这些工作后来整理成了一个叫 PM OS 的仓库，里面有 31 个 skill，现在 Figma 的每个产品经理都在用。

先补上漏掉的工作

Ezra 几年前加入 Figma 时，以为大家都已经在大量使用 AI。他每天在 Twitter 上看到各种 AI 的新进展，觉得自己已经落后了，进了公司才发现，除了工程团队，几乎没有人用这些工具做真正的工作。

他以前就喜欢用 Zapier 做各种自动化，Claude Code 刚出来时，他发现在终端里能做很多有意思的事，于是先开始自动化自己的工作。

当时 Figma 的 CPO Yuki 给团队提了一个问题，怎样才能让所有产品经理都真正用上 AI。他就和另外两位产品经理 Jinan、Lawrence 一起，把他一个人在电脑上折腾的这套配置，改成了别的产品经理也能拿来用、且能在上面继续搭建的工具。

每个产品经理同时在做很多份工作，总有一些工作做得很差，还有一些干脆没有时间去做。Ezra 每次发布新功能，总会忘了在合适的时间通知客服团队，会议记录也一直写得不好。

PM OS 最早的几个 skill，就是把这些工作交给 AI 来做。AI 不需要做得多好，只要每次都记得做，不让同事因为这些工作没做完而一直等着就够了。

这些 skill 一开始放在 Claude Code 的一个仓库里，在终端里使用。PM OS 的设定是产品经理的“幕僚长”（chief of staff），熟悉这个产品经理手上的所有工作，Ezra 自己很不喜欢这个叫法，只是它说起来最方便。每次开始一个会话，它会先读取这个产品经理是谁、和谁一起工作，再读一份记忆文件。

Figma 现在大约有 2000 人，内部有好几套组织架构工具，彼此没有打通，很难查清谁在做哪个项目、哪段代码归谁负责。

第一个 skill 就是查找同事，它知道每个团队有谁、哪个项目归谁负责。写文档需要找人评审时，产品经理不用再记着写上自己的工程经理是谁，skill 会自动把设计师、工程经理这些相关的人加进去，还记得每个人的隔级上级是谁。

Ezra 用得最多的是一个叫 what's up 的 skill，一天大约运行 6 次。Figma 的 Slack 消息非常多，他一天要归档大约 10 个频道。what's up 会读取指定的几个频道，把每个讨论串从头读完，汇总出和他有关的消息和项目，比如他还需要回复谁、还有哪些决定没有做。他还有一个版本，专门检查自己正在线上运行的所有实验。

共用一个仓库

PM OS 本身是一个很简单的仓库。里面有一份 agents.md，规定它怎么工作；有一批 skill，规定它什么时候触发、触发后做什么；还有几个命令 hook，比如每次启动时检查 PM OS 有没有新版本，这样 Figma 六七十个产品经理用的版本能大致保持一致。

产品经理第一次安装时，基础模板放在一个隐藏的点文件夹里，改不到里面的上下文。PM OS 会复制一份，生成这个产品经理自己的版本。

所以它实际上是两个 Git 仓库，一个是所有人都能下载的父仓库，一个是每个人自己的子仓库，想保存的内容可以只保存在自己的子仓库里，这让从没用过 GitHub 的产品经理也能用上 GitHub。

一开始只有 Ezra、Jinan 和 Lawrence 三个人在一个小 Slack 频道里，尽可能多地提交 PR，skill 一度多到上千个，然后开始逐步删减。

今年春天，Figma 所有产品经理参加了一次线下集中活动，每个人都装上 PM OS，动手使用和修改，一起挑出哪些好、哪些不好，集中“吐槽”了一遍。现在的 31 个 skill，有些就是那次留下来的，随着模型越来越好，Ezra 还在把已经没用的部分拿掉。

团队没有给 PM OS 加使用数据统计，因为 Ezra 不想让大家觉得被监视，也希望它用起来是有趣的，而且这些都是他用 20% 的工作时间做的。反馈主要来自一个公开的 Slack 频道，后来工程经理们也用了起来，还来找他们请教怎么用 AI 做工程团队的知识工作，数据科学家也有一个基于它改出来的版本。

除了 what's up，Ezra 常用的还有几个。build artifact 可以把内容做成一个简单的 HTML 页面，套用他从各处收集来的几套 CSS 模板，再用公司内部的托管工具发布出去，这期节目里演示用的看板就是这样做出来的。

Ezra 几乎每天都在用 Figma 的 MCP。一位产品经理用它做了一个 FigJam 生成器，很快就能做出工作坊用的模板，里面写了很多关于怎样才好看、内容应该怎么组织的判断。和团队自己动手做的 FigJam 比，它做出来的结果已经很接近。

Ezra 最喜欢的另一个 skill 叫 coaching，相当于一位职业教练，在工作上遇到问题时给他建议。Ezra 以前带过团队，现在重新做一线产品经理，他一直希望遇到问题时，先让这个 skill 帮自己梳理一遍，再去找上级或同事求助。

coaching 会根据公司的职级体系、他现在的级别和他收到过的所有反馈，听他讲遇到的问题再给建议。有时候是让他别想太多，继续做手上的工作；有时候会提醒他，上次和某个同事产生过误会，聊开之后才发现是自己理解错了，这次要注意沟通方式。

用了一段时间之后，团队觉得让产品经理继续使用终端，不该是最终的形态。产品经理要写大量的文字，一直读等宽字体很难受。于是团队做了一个在本地运行的网页前端，支持 markdown 格式，手机上也能用，界面里还放了不少 ASCII 字符画。

现在 Ezra 几乎 100% 的时间都在 Codex 里工作，其中一个原因是浏览器操作已经变得很好用。比如 Figma 纽约办公室没有固定工位，他不想每天操心订工位，就让 Codex 按计划自动提前一天订好。

在 Codex 里让 agent 自动测试

bug bash 是上线前团队集中一段时间一起找 bug。Ezra 在 Codex 里有一个一直保留着的对话，专门用来做 bug bash。团队每次准备上线一个实验或者一次改版，都会写一份 FigJam 文件，写明用哪个测试账号、按哪条路径操作、做哪些动作、要检查什么。

Ezra 会准备两个测试账号，一个自己用，一个给 Codex 里的 Astra 用，让它在浏览器里把所有场景按要求做一遍，做完再把测过的内容和发现的问题写到 FigJam 白板上。团队还在调整它在白板上留评论的方式，避免评论太多让人烦。

最近一次测的是 Figma 里申请权限的弹窗，团队想让它更简单直接。改动主要是界面文案，看起来不复杂，背后的逻辑却很复杂。Astra 比 Ezra 自己更严格地按照说明执行，每个场景都会认真做完。

做一个 AutoXP 让 agent 自动做实验

bug bash 负责的是实验上线前的检查，但测什么、怎么测，还要团队先在 FigJam 里写好，agent 只能照着说明执行，也不会自己提出新的实验。

Ezra 还一直在想，模型越来越强之后，怎样让团队做实验的节奏更快，AutoXP 就是为这个目标做的。现在的模型在一点工程、一点数据科学、UX 文案上都已经够用，在边界清楚的范围内想点子的能力也在变强，所以整个实验流程可以交给几个 agent 来做。

外面已经有人做过类似的尝试，Figma 内部也终于有了需要的所有工具。AutoXP 由三个 Cursor Automations（Cursor 的自动化任务）组成，由 Slack 里的消息触发。它有自己的 Slack 频道，可以有人在频道里提出一个实验，也可以让它自己循环运行。

比如在频道里发一句“AutoXP，去设置页找一个可以做的实验，放开做”。它会先调用数据科学 agent，去找用户在哪一步流失，看漏斗和用户构成的变化（mix shift）；再调用 UX 文案 agent，给这个位置的文案出几个方案，现在也在往前端设计扩展；最后调用工程 agent，提交 PR 并上线实验。

每一步的进展都发在同一个 Slack 讨论串里，可以从头看到实验进行到了哪一步。

Ezra 给 AutoXP 定了一条规则，人只在实验上线之前检查一次，检查时把数据分析的结论、假设、UX 文案和代码全部审完。实验开始之后，人不再中途调整，等实验结束再看结果是赢还是输，这时它已经开始做下一轮迭代了。

实验结束时，webhook 会通知它分析结果，分析的说明里写着 Ezra 做增长这些年的经验，判断是继续探索新方向，还是集中利用已经验证的结果，这次算赢还是算输。

这样做有两个好处。一是能在平时根本不会花时间和流量的地方做实验，因为从有一个想法到实验上线快了很多；二是分析和下一轮迭代都不用等人。

用 Jev 协助写作

Jev 是一个模型，可以用文字问它很复杂的问题，它返回一个很简单的结果，比如 1 到 10 打几分、对还是错、A B C 里选哪个。它非常快，也非常便宜。Ezra 很喜欢 Figma 画布上的 agent，但它和所有顶级模型一样有延迟，在需要像同事一样及时回应的地方，它慢了，用起来不像一个同事。Jev 正好适合这类需要马上回应的场景。

他做了一个写作助手原型，灵感来自写作应用 Marker。每当停下打字，它就调用一次 Jev，找出文章里留空的地方和需要证据支撑的说法，再去资料库里找内容来补上。

写文章时经常有一段还不确定写什么，就先写个 TK 或者留一对括号；或者写了一个说法，但不确定有没有数据，要等之后再去笔记里查。

比如写下“我在想怎么服务写作者，我觉得 TK”，一停下来，它马上标出这里有一个没写完的想法，同时提示资料库里没有相关的内容。接着写“我们和 X 位写作者聊过，他们说……”，它知道这里需要补全，也从资料库里找出了几段写作者的访谈原话。

Jev 也能用在搜索和文档检索上，所以它不只能判断“这里漏写了内容”，还能实时找出这段文字和资料库里的哪一部分有关。Jev 刚发布的两周里，Ezra 每次开会都要聊它，有的工程师很兴奋，也有的工程师不太感冒。

这个原型也让 Ezra 有过一个担心。他经常面试产品经理，考察产品判断力，以后可能会遇到面试者把自己整个职业经历都录进一个工具里，面试时用语音转文字实时检索自己的例子，他也不确定是不是该录用这样的人。

AI 用得这么多，难免有想对它发火的时候，Ezra 的习惯是不发火。他认为想对 AI 发火的时候，多半是自己给的指令不好，这段对话的上下文已经被污染了。

比如 Codex 现在有一个 bug，本地会话转到远程会话之后，就算开了不用确认的模式，每一步还是要点批准，他在同一段对话里来回绕了很久。这时候发火没有用，最好的办法是开一个新对话，继续往下做。

Ezra 跟 AI 说话，就像对一个把事情搞砸了的好朋友，语气很友好，同时对它抱有很高的期待。比如让 AI 做一个原型时，他会这样鼓励它：“你能做到的事我见过太多了，再努力一点，我们一定能把这个原型做出来，拿去给工程师看。”