走进 Figma 的 PM OS：Ezra Mechaber 谈技能库、找 Bug 与自动化实验

Figma 增长产品经理 Ezra Mechaber 希望避免浪费本可用于实验的流量。他介绍了已经发现一次有效改进的自动化增长流程 AutoXP，以及孕育这些实验的产品管理系统。

Claire Vo 介绍 Mechaber 和 Figma 的 PM OS：一组服务日常产品工作的共享技能。两人还讨论了借助浏览器找 Bug，以及使用快速、低成本模型 Jev 的写作助手。

Vo 问这个系统如何诞生。Mechaber 说，加入 Figma 时他以为每个人都在使用 AI，却发现工程部门以外鲜有人用它完成实际工作。于是他开始自动化自己的任务，探索 Claude Code 在终端里能做什么。

Figma 当时的首席产品官提出挑战，希望产品经理都能熟悉 AI。Mechaber 随后与 Jinan、Lawrence 等同事合作，把个人配置变成其他人也能复用的工具。他们想找出产品经理做得不好或根本没做的工作，提高基本水平。

例如，Mechaber 经常忘记在产品发布前及时联系支持运营团队。会议记录也是他的弱项。他希望助手至少能避免这些遗漏拖住同事，同时帮助他在一家约 2,000 人的公司找到相关人员和代码负责人。

早期的一项技能能够结合代码库的实际情况撰写详细规格。Vo 认为总体目标既是提升必要任务的基本质量，也是让团队有能力完成更有雄心的工作；两方面都需要支持。

系统最初只是一个通过 Claude Code 使用的简单代码库。启动时，它读取产品经理及其同事的信息和记忆文件，再提供一组技能。Mechaber 开玩笑说，虽然自己不喜欢“参谋长”这个说法，但它确实很方便。

一项技能把分散在不同组织架构工具中的信息联系起来，回答团队或项目由谁负责。产品经理撰写文档时，系统可以加入相关工程经理、设计师、审核人和其他利益相关者，不必依赖作者记住每个名字。

另一项常用技能叫“What’s up”，它汇集相关 Slack 对话和项目，包括尚未作出的决策以及等待回复的人。Mechaber 每天会运行几次；另一个版本还会整理他正在进行的实验。

这项技能读取指定频道的完整讨论串，并遵循针对公司组织方式编写的指令来查找有用上下文。Vo 指出，寻找利益相关者和相关项目这样的基础工作很容易被忽视，却能让更具战略性的流程成为可能。

Mechaber 说，他曾尝试为系统建立基准测试，但没有成功；他很想把它与如今未经定制的模型比较。他认为，在模型能力尚弱、Figma 的信息架构又不容易导航时，这些指令尤其有帮助。

PM OS 的核心是代码库：一份 agent 指令文件、一组技能、钩子和文件夹结构。启动钩子会检查新版本，让约 60 到 70 名产品经理保持同步。共享的父代码库与私有工作区子代码库分开，使个人工作可以保持私密。

最初，一个小组自由试验并提交了大量拉取请求。随后，整个产品团队在一次线下活动中安装、使用、批评并修改系统。一些技能得以加入，另一些则被移除；随着模型进步，Mechaber 也不断尝试删掉不再需要的指令。

团队选择不追踪使用情况，部分原因是 Mechaber 希望这个利用业余时间开发的项目有趣而不让人觉得受到监视。反馈改由 Slack 收集。工程经理后来也产生了兴趣，数据科学家则创建了自己的分支版本。

他喜欢的一项技能可以生成简单的 HTML 成果，并发布到内部托管工具。他还使用 Figma 的 MCP 集成和 FigJam 构建器快速创建工作坊模板，相关指令中融入了设计偏好。

一项辅导技能会结合职业发展阶梯、反馈、过去的上下文和眼前的问题。Mechaber 用它先行思考自己的成长，例如回顾此前发生的误解，并获得与同事沟通的建议。

界面从终端发展为支持 Markdown 排版和移动端的本地网页。Mechaber 现在主要使用 Codex，原因之一是浏览器操作能力有所提升；他甚至安排 agent 定时预订办公室工位。

为集中找 Bug，团队会在 FigJam 中准备测试账户、操作路径、执行动作和检查重点。Mechaber 给自己和 agent 各分配一个账户，让后者在浏览器中逐项执行场景，并把结果写回看板。

团队仍在调整 agent 写评论的方式，但它的细致已经发现了他忽略的问题。一个文本框输入一千个表情符号后会出错；另一个问题涉及申请团队席位时英语冠词的选择，只会在某些团队名称下出现。

Vo 问起实验自动化。Mechaber 解释，在增长产品经理看来，没有分配给实验的流量意味着错失机会；产品中有些地方，团队通常不会投入足够时间进行测试。

随着模型在有限范围内的工程、数据分析和用户体验文案能力提升，他借鉴其他人的类似实践，构建了 AutoXP。他说，一位工程师同时运行了五个实验，而第一个实验就取得了显著成果。

AutoXP 使用 Cursor 自动化任务和专属 Slack 频道。人可以提出要测试的产品区域，系统也可以循环运行。数据科学 agent 查找漏斗流失和用户构成变化，文案 agent 提出文字方案，工程 agent 负责代码。

每个阶段都会把结果写回同一条 Slack 讨论串，便于大家跟踪。实验结束后，webhook 会触发分析，依据 Mechaber 积累的增长经验判断结果，并决定进一步探索还是利用现有发现。

设计中的人工检查点设在上线之前：审核者可以一次查看分析、假设、文案和代码。之后系统观察结果并开始下一轮迭代。Mechaber 强调，完整自动化是目标，实际实现还在逐步接近。

Vo 回忆起多年前创立 Experiment Engine 时也在思考类似的问题：如何更好地利用流量，增加实验数量。她很兴奋，因为团队现在可以用现有工具搭建出这一流程的大部分原型。

话题转向 Jev。Mechaber 将它描述为一个快速、便宜的模型，可以回答评分或选项等结构化问题。他思考反复进行低延迟检查能在哪些地方改变工作方式，尤其是在较慢的模型会打断协作节奏时。

他的写作原型会在作者每次停顿时检查文本，寻找占位符、未写完的想法和可能需要证据支持的论断，再查询资料库中的来源。这个想法部分受到写作应用 Marker 的启发。

现场调用起初遇到了内部防火墙问题。随后 Mechaber 展示，系统能把“TK”占位符识别为未完成的想法，也能表示上下文不足、无法补全；另一句话则促使它从资料库中检索相关采访摘录。

Mechaber 对模型既能识别文字模式、又能通过检索实时连接相关材料感到兴奋。他开玩笑说，求职者或许会在产品面试时使用类似助手，接着又表示，能够构建这样的工具本身也可能是录用理由。

Vo 回顾了 31 项技能，包括追踪日常工作、寻找同事、撰写规格和职业辅导，以及找 Bug 和写作流程。她接着问起通过短信交流的主动式 agent Instinct。

Mechaber 说，Instinct 的记忆和主动行为很有用。一个实际例子是报告他骑车带孩子时遇到的路面坑洞：他可以发消息说明地点，让 agent 记住并提交报告。他说自己后来主要转向了 Dots。

谈到 AI 助手表现不佳时的反应，Mechaber 说自己更愿意保持友善。他并不声称这些系统有意识，而是担心长期刻薄会改变自己的行为。Vo 则把自己用大写字母表达挫折与人身攻击区分开来，并拿浪费 token 的成本开玩笑。

Mechaber 补充说，糟糕的指令或被污染的上下文常常导致结果不佳。他描述了在不同环境间转移 Codex 会话时陷入权限确认循环的经历，并认为当对话无法恢复时，重新开始可能比重复相同要求更有用。

Vo 开玩笑地提供了一种育儿式提示：表达对 agent 能力的信心，同时承担起给出更好指示的责任。Mechaber 喜欢设定较高期望，鼓励助手构建可以展示给工程师的原型。

最后，Mechaber 说自己会在线分享工作，也提到 Figma 正在招聘产品经理、工程师和设计师。Vo 感谢他展示了多种利用 AI 辅助产品工作的实际方法。