很多团队现在的状况是：有一两个人把 AI 用得很顺，写周报、整理会议、起草 PRD（产品需求文档）都有自己的一套提示词和配置；其他人要么不用，要么每次从零开始问。这套用法留在个人电脑里，人一休假，流程就断了。
这次看的三份材料正好讲到这件事：Figma 一位增长 PM 在播客里介绍的 PM OS，Mercari 一位 PM 实习生写的 PM Agent 设计博客，以及 Anthropic 官方的 Skill 构建指南。Skill 可以理解为一份写给 AI 的操作说明书：什么时候该用、按什么步骤做、不能做什么，AI 在合适的时候自动读取它。
我读完的判断是：要把个人用法变成团队默认，光攒 Skill 不够，还得同时解决三件事——放在一个大家能装、能改、能删的地方；把约束和人工确认点写进去；测它会不会在该用时被用上、用上后结果对不对。下面分开看每份材料说了什么、我同意什么、哪里证据不够。
Figma：先解决“大家怎么用上同一套”
播客节目页介绍，Ezra Mechaber 入职 Figma 时发现，工程以外几乎没人用 AI 做实际工作。他和几位 PM 把他个人在 Claude Code（Anthropic 出的 AI 编程与工作助手）里的配置改造成 PM OS，节目页的说法是“31 个 skill 的共享仓库，Figma 每位 PM 都在用”，副标题写“60+ 位 PM 在用”，要点里又写“一个仓库让 60 到 70 位 PM 保持同步”。节目要点里专门列了一条：为什么 PM OS 是仓库而不是产品。
节目方整理稿给出了仓库里的东西：一份描述助手该怎么做事的 agents.md，关于这位 PM 和协作者的记忆与上下文，写明“何时启用、做什么”的模块化 skill，启动时自动检查新版本的钩子（hook，在特定时机自动执行的动作），以及“共享模板 + 每人一个私有工作区”的双层仓库。整理稿说，这套安排部分是为了让六七十位 PM（包括不熟 GitHub 的人）能用上同一套配置。Ezra 在 LinkedIn 上的自述补充了上手方式：新 PM 克隆仓库后，仓库一步步带着完成设置和 MCP 授权（MCP 是让 AI 连上 Slack、Notion 这类工具的标准接口）；另有一个“完全放开发布”的共享市场，好用的 skill 再被提进主仓库。
单个 skill 写得多具体，可以看 Ezra 自己最常用的“What’s Up”，他说一天大约跑 6 次：汇总相关 Slack 频道、待决事项和自己欠别人的事。指令里写明了哪些频道重要，还要求读完整个讨论串，而不是只看零散消息。后一条很实用，否则 AI 分不清一个请求是新的，还是十条消息之后已经解决了。
我觉得最值得学的是它怎么删减。整理稿记录，PM OS 起初是三位 PM 在一个小 Slack 频道里互相提代码修改，skill 先是一下子冒出很多，然后开始删；春季团建时，PM 们装上、用、改，还被邀请当面吐槽，吐槽结果决定了哪些 skill 留下。模型变强以后，Ezra 也在删掉那些不再必要的指令。
证据的边界也要说清。整理稿明确写了：没有使用量统计，一是 Ezra 不想让人有被监视的感觉，二是这本来是业余做的项目；他尝试做过基准测试，没成功，所以并不知道这套配置比不加载 PM OS、直接用原生 AI 助手好多少。“每位 PM 都在用”来自节目简介，不是统计数字。我也没有拿到播客逐字稿，以上细节来自节目页、节目方整理和当事人帖子。
Mercari：把 Skill 当成一份行为规范来写
Figma 讲的是分发和管理，Mercari 那篇讲的是一个 Skill 内部怎么写才靠得住。作者做的 mercari-pm-agent，在一个会话里串起“发现问题、收集数据、写 PRD、出界面草图”。
文中有三个做法我认为对团队直接有用。
第一，先定评测标准再写提示词。作者先定了四个评分维度：问题理解是否准确、规格是否具体、是否可行、体验是否合理，再拿真实的改进议题当测试集，还专门写了一个给输出打分的评测 skill。
第二，拆文件。起初所有内容写在一个 SKILL.md 里，评测发现文件越长准确率越差；后来主文件只写“做什么、按什么顺序”，PRD 模板、9 项检查清单、数据解读指南等放进 references 目录，作者说仅这一项改动分数就明显提升。
第三，把“不能做什么”写死。数据没确认就标“未提供”或“待验证”，不准编数字和来源；没有 PM 明确确认，不准自动进入下一步。数据源连不上就跳过并在结果里注明。作者的结论是：设计 Skill 接近写行为规范，约束比命令更重要。
需要提醒的是，这是一个实习生的单人项目，文中没有公布评分数值、测试集规模和上线范围。做法可以借鉴，“提升明显”只能当作者的观察。
Anthropic：Skill 得先能被用上
团队 Skill 常见的失败是写好了没人触发，或者在不相干的场景乱触发。Anthropic 指南把这件事放在很前面：每个 Skill 的描述字段要同时写“它做什么”和“什么时候用”，写进用户真实会说的话，因为 AI 是靠这段描述决定要不要加载它。
指南建议动手前先写 2 到 3 个具体用例，每个用例写清触发说法、步骤和结果。测试分三类：触发测试，看明显的说法和换个说法时会不会触发、无关话题会不会误触发；功能测试，看输出、调用、出错处理和边界情况；基线对比，用同一任务比较开和不开 Skill 时的结果、工具调用次数、消耗和出错情况。它给的参考目标是相关请求九成能触发，用 10 到 20 条测试句检验；同一请求跑 3 到 5 次看结果是否一致。但指南自己也说，这些是期望目标、粗略基准，不是严格门槛。
另一条建议对个人转团队很关键：先在一个难任务上反复调到成功，再把做法抽成 Skill。指南还提到，小团队内部用的 Skill 和部署给上千企业用户的 Skill，测试要求不一样，严格程度按可见范围来定。
三份材料合起来，还缺什么
把三份放在一起看，分工很清楚：Figma 回答“大家怎么用上、怎么删”，Mercari 回答“一个 Skill 怎么写才不乱来”，Anthropic 回答“怎么知道它被用对了”。少了任何一块都会出问题：只有共享仓库，没有约束，就是把个人的坏习惯批量复制；只有约束，没有触发测试，规范写得再细也可能没人调用。
三份材料都没有给出能直接采信的效果证据。Figma 没有遥测和基准，Mercari 没公布分数；Anthropic 给了触发率、一致性和基线对比这些粗略的测法，但那是检验方法，不是效率提升的证明。所以现阶段比较诚实的做法是：先把“用上、用对”测住，效率提升别急着下结论。
如果你在广告代理商带产品团队
以下是我的建议，不是来源中的做法，示例句子也都是假设。
- 挑一个人人都做、格式固定的流程起步，比如投放周报或活动复盘。先由用得最顺的人在一个真实任务上调到满意。
- 抽成 Skill 时，描述里写清“做什么 + 什么时候用”。比如：根据投放数据和客户反馈生成周报，当有人提到“写周报”“整理本周投放”时使用。
- 写 10 条左右应触发的说法（如“帮我把这周的数据整理成给客户的周报”）和几条不应触发的说法（如“帮我写一份比稿方案”），每次改完都跑一遍。再拿一个真实周报任务做功能检查：数字和来源对不对，缺的数据有没有标“待确认”，发送前的确认环节有没有生效；同时留一份不用 Skill 的人工版本作对照。
- 把约束写进去：客户数据缺了就标“待确认”，不准估算；对外发出前必须由负责人确认。
- 放进团队共享仓库，个人习惯留在私有区；每月一起过一遍，没人用或常被手动改的就删掉或重写。
先做好一个流程，比一下子建一堆 Skill 更容易落地，也更容易看出哪里不对。
参考来源
- How I AI：How Figma’s PMs actually use AI every day（Ezra Mechaber，2026-11-02，节目页）：https://www.lennysnewsletter.com/p/how-figmas-pms-actually-use-ai-every
- ChatPRD：Inside Figma’s PM OS: 31 AI Skills, Better Bug Bashes, and an Automated Growth Loop（节目整理）：https://www.chatprd.ai/how-i-ai/inside-figma-s-pm-os-31-ai-skills-better-bug-bashes-and-an-automated-growth-loop
- Ezra Mechaber，LinkedIn 帖子：https://www.linkedin.com/posts/ezra-mechaber_we-created-a-harness-for-product-work-at-activity-7480069965463719936-WnME
- Mercari Engineering：mercari-pm-agent Design — Automating the PM Workflow with Claude Code Skills and MCP（2026-04-28）：https://engineering.mercari.com/en/blog/entry/20260427-mercari-pm-agent-design-automating-the-pm-workflow-with-claude-code-skills-and-mcp/
- Anthropic：The complete guide to building Skills for Claude · Planning and design：https://claude.com/resources/guides/the-complete-guide-to-building-skills-for-claude/planning-and-design
- Anthropic：同上 · Testing and iteration：https://claude.com/resources/guides/the-complete-guide-to-building-skills-for-claude/testing-and-iteration