1. 项目概述：当AI助手遇上产品大师的智慧
如果你是一名产品经理、创业者，或者任何需要与产品打交道的人，最近可能已经感受到了AI助手带来的效率革命。无论是用Claude Code写代码，还是用ChatGPT梳理思路，这些工具正在成为我们工作流中不可或缺的一部分。但你是否也遇到过这样的困境：当你向AI助手提出一个复杂的、需要专业判断的产品问题时，得到的回答往往流于表面，缺乏深度和实战性？比如，你问“如何评估一个产品经理候选人”，它可能会给你一个标准的面试问题清单，却无法告诉你，Shreyas Doshi在面试中真正看重的、能区分顶尖PM和普通PM的那几个关键行为信号是什么。
这正是“Lenny's Product Skills for Claude Code”这个开源项目试图解决的问题。它不是一个简单的提示词合集，而是一个将全球顶尖产品领导者的实战智慧，系统性地“注入”到AI助手（特别是Claude Code）中的知识库。项目从Lenny Rachitsky（前Airbnb增长负责人，现知名产品播客主理人）的100多期播客中，提炼了Shreyas Doshi、Marty Cagan、Elena Verna等90多位产品大咖反复强调的86项核心产品技能，并将它们封装成一个个可被AI直接理解和调用的“技能”（Skill）。简单来说，它让Claude从一个“通才”助手，变成了一个拥有资深产品总监经验和思维框架的“专家”助手。
这个项目的核心价值在于“场景化赋能”。当你安装这些技能后，Claude Code就能在你处理特定任务时，自动调用相关的专业框架。例如，你在写PRD（产品需求文档）时，它会提醒你采用“逆向工作法”（Working Backwards），先从新闻稿和FAQ写起；当你在做竞品分析时，它会引导你超越功能对比，去思考竞争格局和护城河。这相当于为你配备了一位24小时在线、融合了数十位顶尖产品人智慧的个人教练。无论是产品新人希望快速建立体系，还是资深人士想要查漏补缺、获得新的视角，这个工具集都能提供极具针对性的帮助。
2. 核心设计思路：如何将经验转化为可执行的AI技能
2.1 从播客到技能：知识提炼的工程化方法
这个项目最精妙的设计在于其“知识工程化”的过程。它没有简单地将播客文字稿丢给AI去总结，而是走了一条更结构化、更注重可操作性的路径。每一期Lenny的播客都像是一座金矿，嘉宾们在轻松对谈中分享的洞察、踩过的坑、总结的框架，都是未经雕琢的宝石。项目的创建者Refound AI团队扮演了“采矿工”和“宝石切割师”的角色。
他们的工作流程大致可以拆解为三步：首先是“识别模式”，即从海量的对话中识别出那些被多位嘉宾反复提及、具有普适性的核心挑战或任务，比如“设定OKR”、“进行艰难对话”、“定义产品愿景”。其次是“提取框架”，将嘉宾们解决这些问题的具体方法、步骤、检查清单和背后的原理（即“为什么这么做”）清晰地剥离出来。最后是“结构化封装”，将这些框架转化为一个标准的Markdown文件（即SKILL.md），并遵循特定的格式，使其既能被人阅读理解，也能被Claude Code这样的AI助手精准解析和调用。
这种做法的优势显而易见。它避免了知识以模糊的“经验之谈”形式存在，而是变成了可检索、可组合、可执行的“乐高积木”。例如，writing-prds这个技能，很可能融合了Marty Cagan关于“产品三要素”（可行性、可用性、价值性）的论述，以及Shreyas Doshi关于“PRD是沟通工具而非命令文档”的见解，最终形成一个指导用户分步撰写高质量PRD的实操指南。
2.2 技能架构：模块化与场景触发机制
项目的技能架构设计充分考虑了灵活性和实用性。86项技能被组织成多个逻辑类别，如“招聘与团队建设”、“用户研究与发现”、“战略与规划”等，这方便用户按图索骥。但更关键的是其“场景触发”机制。
当你安装这些技能后，它们会以文件形式存放在你项目目录的.claude/skills/文件夹下。Claude Code在运行时，会持续“监听”你的对话上下文。一旦它识别出你正在讨论或尝试完成某个与技能描述相匹配的任务，它就会自动激活相应的技能文件，将其中的知识框架和提问引导融入它的回复中。这就像给你的对话加上了一个智能的“背景知识库”。
例如，你在终端里对Claude Code说：“我们下周要开一个项目复盘会，但我担心会变成互相指责的批斗会。” Claude Code在解析这句话时，可能会匹配到post-mortems-retrospectives（事后分析与复盘）和having-difficult-conversations（进行艰难对话）这两个技能。它接下来的回复，就不会是泛泛而谈的“要营造开放氛围”，而是会引用技能中具体的框架，比如：“根据Elena Verna的建议，有效的复盘会应该聚焦于‘系统’而非‘个人’。我们可以按照‘事实回顾 -> 根本原因分析（用5个为什么法）-> 制定行动项’的流程来设计议程。这里有几个引导性问题可以帮助转向建设性讨论：1. 当时我们掌握的所有信息是什么？2. 基于这些信息，我们做出的最好决策是什么？3. 从今天的视角看，系统或流程上可以如何改进以避免类似问题？”
这种设计极大地提升了AI助手的“专业深度”和“情境智能”。用户无需记住每个技能的名称或手动调用，AI就能在正确的时机提供正确的指导。
注意：技能的触发依赖于Claude Code对自然语言意图的理解。有时它可能无法精准匹配，或者同时匹配多个技能。这时，你可以使用“/技能名”的指令格式（如
/writing-prds）来直接调用特定技能，确保获得最相关的指导。
3. 深度解析核心技能：产品实战的“瑞士军刀”
86项技能覆盖了产品工作的方方面面，我们不可能一一详述，但可以深入剖析几个最具代表性、最能体现项目价值的技能，看看它们是如何将顶级智慧转化为实操工具的。
3.1writing-prds：超越模板，撰写有灵魂的产品需求文档
几乎所有产品经理都写过PRD，但大多数PRD都沦为无人问津的形式文件。writing-prds技能的核心，是扭转这种局面，让PRD真正成为对齐团队、驱动决策的核心工具。它不会给你一个冰冷的模板让你填空，而是引导你思考一系列关键问题。
首先，它强调“从为什么开始”。在动笔写任何功能描述之前，技能会引导你明确：我们要解决用户的什么核心痛点？这个痛点的严重程度和普遍性如何？现有的解决方案为什么不够好？这背后可能融入了Marty Cagan“产品三要素”中“价值性”的拷问，确保团队不是在为做功能而做功能。
其次，它推崇“逆向工作法”（Working Backwards）。这是从亚马逊流传出来的经典方法。技能会建议你，在写具体的需求之前，先尝试撰写一份未来的“新闻稿”和“常见问题解答（FAQ）”。写新闻稿迫使你用最简单、最吸引人的语言向外界（包括用户、媒体、投资人）描述这个产品是什么、为什么重要。写FAQ则逼迫你提前思考所有关键的细节、质疑和边界情况。这个过程能极大地澄清思路，并让所有相关方在项目启动前就对最终成果达成共识。
再者，它关注“可衡量性”。技能会引导你定义清晰的成功指标（Metrics）和验收标准（Acceptance Criteria）。这不是简单的“功能上线”，而是“上线后一周内，目标用户群中XX%的人完成了核心操作A，且用户满意度调查中关于‘易用性’的评分提升Y分”。这种精确性来自数据驱动产品文化的影响。
最后，它重视“PRD作为一个活文档”。技能会提醒你，PRD不是一次性写完就锁进抽屉的。它应该在开发过程中持续更新，记录重要的决策、变更和待办事项。它应该是团队唯一的信息源，链接到设计稿、用户反馈、数据看板等所有相关资源。
实操心得：我使用这个技能撰写PRD时，最大的改变是“写作顺序”。以前是从功能列表开始，现在是从“用户故事”和“成功指标”开始。这迫使我在设计解决方案前，花更多时间定义问题。另一个技巧是，在PRD开头增加一个“非目标”（Non-goals）部分，明确列出本次迭代不打算做的事情。这能有效管理各方预期，避免范围蔓延。
3.2evaluating-candidates：识别顶尖产品经理的“信号”
招聘是产品领导者的核心杠杆，但面试产品经理尤其困难，因为其能力很大程度上是隐性的、情境化的。evaluating-candidates技能提炼了顶尖产品领导者在面试中真正寻找的东西。
它首先区分了“经验”与“能力”。一个有五年大厂经验的PM，未必比一个只有两年创业公司经验的PM更优秀。技能引导面试官超越简历上的公司和项目名称，去深挖候选人在具体情境下的思考过程、决策依据和实际影响。例如，不问“你负责过什么功能？”，而是问“请描述一个你发起并推动的、最初不被看好的功能。你是如何发现这个机会的？如何争取资源？如何衡量其成功？过程中遇到的最大挑战是什么，如何克服的？”
其次，它提供了结构化的评估框架。技能可能将PM能力拆解为几个核心维度，如：用户洞察深度、商业敏锐度、技术理解力、执行推动力、战略思维和领导力。针对每个维度，都有一组行为面试问题（Behavioral Questions）和评估标准。例如，评估“执行推动力”时，会关注候选人如何管理项目风险、如何与工程师/设计师协作解决冲突、如何在资源受限时做出取舍。
第三，它强调“模拟工作”。最有效的面试是模拟真实的工作场景。技能会建议设计一个小的产品演练（Product Exercise），比如给候选人一些模糊的用户反馈和数据，让其在有限时间内提出分析思路和行动建议。观察其如何定义问题、提出假设、寻找数据、构思方案，比听其讲述过去的成功故事更能反映真实能力。
最后，它关注“团队适配性”与“成长潜力”。技能会引导面试官思考：这个候选人的工作风格和价值观是否与团队匹配？他/她是否有清晰的自我认知和学习意愿？在高压或模糊情境下，他/她倾向于如何应对？这些软性因素往往决定了一个PM能否在组织中长期成功。
注意事项：使用这个技能时，要警惕“光环效应”和“相似性偏见”。不要因为候选人来自知名公司或背景与你相似就放松标准。严格按照技能提供的框架和问题清单进行提问和记录，并在面试后与面试小组进行校准讨论，对比各自的观察和评分，以确保评估的客观性。
3.3prioritizing-roadmap：在无限需求与有限资源间做决策
优先级排序是产品经理的日常，也是最容易引发团队摩擦和战略失误的环节。prioritizing-roadmap技能将各种流行的优先级框架（如RICE、价值vs复杂度矩阵、Kano模型）与顶尖产品人的决策逻辑相结合。
它的核心是建立“决策坐标系”。技能会引导你首先明确当前阶段的“唯一重要的目标”（One Metric That Matters, OMTM）或“北极星指标”。所有的需求都必须与这个目标对齐。然后，你需要为每个潜在项目定义一套一致的评估维度，例如：
- 预期影响力：对核心指标的提升估计（尽可能量化）。
- 置信度：你对上述影响力估计的信心有多大？（高/中/低）
- 所需投入：需要多少工程师/设计师/分析师的工作量？
- 战略重要性：是否符合长期产品愿景？是否在构建护城河？
- 用户痛苦程度：解决的是用户的“痛点”还是“痒点”？
其次，它引入“成本延迟”和“机会成本”的概念。技能会提醒你，排序不仅是选做什么，更是决定不做什么以及晚做什么。一个需要6个月的大项目，其“成本”不仅是资源投入，还包括这6个月里你无法去做其他可能更有价值的事情（机会成本）。有时，将大项目拆解成能快速验证价值的小实验，是更优的策略。
第三，它强调“数据与直觉的平衡”。完全依赖数据会错失创新机会，完全依赖直觉则风险巨大。技能会建议采用“分级决策”机制：对于高风险、高投入的战略性项目，需要更严谨的数据分析和用户研究来支撑；对于低风险、快速的优化实验，则可以更多依赖团队的经验和直觉进行快速尝试。
最后，它关注“流程的透明与共识”。优先级决策不应该是一个黑箱。技能会提供如何向团队、向管理层透明化展示排序逻辑和依据的方法。例如，使用“优先级矩阵图”进行可视化，并附上每个项目的评估摘要。这个过程本身就能促进讨论、达成共识，并让团队理解背后的战略思考。
常见问题：一个常见的陷阱是“紧急”压倒“重要”。销售团队的一个紧急需求或某个大客户的特殊要求，常常会打乱整个产品路线图。技能会建议设立明确的决策规则和授权机制。例如，规定任何需要调整已定季度路线图的需求，必须由产品、技术、业务负责人三方共同评审，并评估其对核心目标的冲击。这能有效保护团队的注意力资源，聚焦在真正重要的事情上。
4. 实战部署与应用指南：将技能集成到你的工作流
了解了这些技能的价值后，如何将它们真正用起来，变成你日常产品工作的助力？以下是详细的部署和深度应用指南。
4.1 环境准备与技能安装
项目提供了多种安装方式，以适应不同的使用习惯和项目结构。最推荐的是使用npx skills这个官方CLI工具，它能实现最便捷的管理。
步骤一：检查环境确保你的系统已经安装了Node.js（版本12或以上）和npm。这是运行npx命令的前提。你可以在终端输入node --version和npm --version来确认。
步骤二：一键安装全部技能在你的项目根目录下，打开终端，执行以下命令：
npx skills add RefoundAI/lenny-skills这条命令会自动完成几件事：
- 从GitHub拉取
lenny-skills仓库。 - 将其中的所有技能（
skills/目录下的所有文件夹）复制到你当前项目目录下的.claude/skills/文件夹中。如果该文件夹不存在，CLI工具会为你创建。 - 完成安装，你可以立即开始使用。
步骤三：验证安装安装完成后，你可以进入.claude/skills/目录查看。你应该能看到大量以技能名命名的文件夹（如writing-prds/、evaluating-candidates/等），每个文件夹里都有一个SKILL.md文件。这就是技能的“知识本体”。
其他安装方式解析：
- 克隆并复制：适合需要完全控制文件位置，或网络环境无法使用
npx的情况。你需要手动管理更新。 - Git子模块：适合将技能库作为你大型项目的一部分进行版本管理，能方便地同步上游更新。但对于只想个人使用的场景来说，稍显复杂。
- Fork并定制：这是高级用法。如果你所在的公司或团队有自己独特的产品方法论、工作流程或术语，你可以Fork这个仓库，在原有技能的基础上进行修改和增补，创建你们自己的“定制版技能库”。例如，你可以把公司内部常用的“产品评审会 checklist”加入到
running-design-reviews技能中。
4.2 与Claude Code的深度集成与使用技巧
安装完成后，Claude Code（通常作为IDE插件或CLI工具运行）会自动识别.claude/skills/目录下的内容。以下是如何高效利用它的几种方式：
方式一：自然对话触发（最常用）就像平时和Claude聊天一样，直接描述你的任务或问题。例如：
- “帮我起草一份关于‘用户个性化推荐系统’的产品需求文档大纲。”
- “我们正在规划下个季度的OKR，对于一款工具类SaaS产品，有哪些设定目标的好方法？”
- “我明天要和一个表现不佳的团队成员进行艰难对话，该如何准备？” Claude Code会在后台匹配相关技能，并将其框架融入回答中。你会发现它的回答更具结构性，会抛出一些引导性问题，并提供具体的步骤和注意事项。
方式二：直接指令调用（最精准）当你明确知道自己需要哪项技能时，可以使用“/技能名”的格式直接调用。例如：
/prioritizing-roadmap然后描述你手头的一堆需求。/stakeholder-alignment然后说明你即将进行的汇报和需要争取支持的决策。 这种方式能确保Claude Code激活最相关的技能，避免其他技能的干扰，回复会非常聚焦。
方式三：技能组合使用（解决复杂问题）很多复杂的现实问题需要多项技能的综合应用。你可以通过对话引导Claude进行组合。例如，你可以说：“我们计划推出一个全新的AI功能（涉及ai-product-strategy），需要先进行用户调研来验证需求（涉及conducting-user-interviews），然后撰写PRD（涉及writing-prds），最后还需要规划发布后的增长策略（涉及designing-growth-loops）。请帮我一步步梳理这个全过程。” Claude Code有能力根据上下文，串联起不同技能的知识点，为你提供一个端到端的指导方案。
方式四：作为学习与参考手册即使不直接向Claude提问，你也可以直接阅读.claude/skills/目录下的SKILL.md文件。它们本身就是结构清晰、内容丰富的迷你指南。当你需要静下心来研究某个特定领域（比如“定价策略”）时，直接打开pricing-strategy技能文件阅读，效率可能比在网上零散搜索更高。
4.3 自定义与扩展：打造属于你团队的知识库
这是将该项目价值最大化的关键一步。开源项目的魅力在于你可以基于它进行二次创作。
如何定制现有技能？找到你想修改的技能文件夹，直接编辑其中的SKILL.md文件。你可以：
- 补充本地化案例：将技能中提到的通用框架，替换成你公司或行业内的真实案例。这能让建议更具针对性。
- 集成内部工具：在技能中增加你们公司内部使用的特定工具链接、模板或流程说明。例如，在
shipping-products技能中加入你们团队在Jira中的工作流配置图。 - 调整措辞：使语言风格更符合你们团队的文化。
如何创建全新的技能？如果你发现某个对团队至关重要的领域未被覆盖（比如“如何进行跨国跨时区的产品协作”），你可以参照现有技能的格式创建新技能。
- 在
skills/目录下创建一个新的文件夹，用kebab-case命名（如cross-timezone-collaboration）。 - 在该文件夹内创建
SKILL.md文件。 - 文件内容通常包括：
- Frontmatter：用YAML格式定义技能名称、描述、触发关键词等元数据。
- 概述：简要说明这项技能解决什么问题。
- 核心框架/步骤：分步骤或分模块详细阐述方法论。
- 关键问题：提供一组引导用户思考的提问清单。
- 常见陷阱与建议：分享实践中容易出错的地方和应对技巧。
- 参考资料：可以链接到相关的内部文档、书籍或文章。
- 将新技能的信息更新到项目的总览表格中（如果你维护的是自己的分叉版本）。
通过这种方式，你可以逐步构建一个沉淀了你们团队独家智慧和经验的“活体知识库”，并让AI助手成为这个知识库最便捷的交互界面。
5. 常见问题、局限性与进阶思考
5.1 使用中可能遇到的问题与解决方案
尽管这个工具非常强大，但在实际使用中你可能会遇到一些挑战。以下是一些常见问题及应对思路：
问题一：技能触发不准确或没有触发。
- 表现：你提出了一个明显属于“产品策略”范畴的问题，但Claude的回答很普通，没有引用
ai-product-strategy或defining-product-vision等技能的深度内容。 - 可能原因与解决：
- 描述过于宽泛：AI可能无法从“我们该怎么做？”这样模糊的问题中匹配到具体技能。尝试更具体地描述场景和约束条件，例如：“作为一款B端数据工具，我们想引入AI辅助分析功能。在制定这个AI功能的产品策略时，应该重点考虑哪些方面来避免做成华而不实的‘玩具’？”
- 技能未正确安装：检查
.claude/skills/目录下是否存在相关技能的文件夹。确保安装路径正确（应在你启动Claude Code的项目根目录或家目录下）。 - 直接指令调用：当自然触发不灵时，直接使用
/技能名指令是最可靠的。
问题二：技能建议与公司实际情况冲突。
- 表现：技能基于最佳实践建议“A方案”，但你公司的流程、资源或文化强制要求“B方案”。
- 解决思路：不要将技能视为必须遵守的“圣经”，而应视为一位资深顾问的“建议”。你可以向Claude说明约束条件。例如：“技能里提到应该做多轮用户访谈，但我们目前只有一周时间且没有用研支持。在这种强约束下，有什么折中或替代的快速验证方法吗？” Claude可以结合技能中的原则（如“快速验证假设”），为你生成一个适配当前限制的具体行动计划。
问题三：对技能中的概念或框架不熟悉。
- 表现：技能中提到了“RICE评分模型”、“Kano模型”、“逆向工作法”等术语，你不太理解。
- 解决思路：直接向Claude提问！这是绝佳的学习机会。你可以问：“请详细解释一下‘逆向工作法’（Working Backwards）的具体步骤，并给我一个简单的例子。” Claude会利用其通用知识为你解释。这相当于在专家指导下学习新框架。
问题四：技能库的更新与维护。
- 问题：产品领域知识在不断更新，如何确保技能库的内容不过时？
- 解决方案：如果你使用
npx skills安装，可以定期运行npx skills update来检查并获取上游仓库的更新。如果你是Fork后自定义，则需要手动合并上游的更新。更积极的做法是，关注Lenny的播客和Refound AI的项目动态，对于重要的新见解，可以自己动手更新或创建新的技能，并向原项目提交Pull Request，贡献社区。
5.2 理解项目的局限性：AI不是替代品
在热情拥抱这个工具的同时，我们必须清醒地认识到它的边界。
局限性一：缺乏真正的“情境判断”。AI技能提供的是基于普遍经验的框架和问题，但它无法理解你所在公司独特的政治氛围、团队间微妙的人际关系、或是某个历史决策背后的隐情。例如，stakeholder-alignment技能可以教你如何准备沟通材料，但它无法告诉你，那位沉默寡言的CTO真正在意的是什么，或者销售副总裁和营销总监之间的历史矛盾该如何规避。最终的判断和决策，必须由你——了解具体情境的人——来做出。
局限性二：可能助长“思维惰性”。如果过度依赖技能提供的现成框架和问题，可能会削弱你独立、深入思考的能力。技能是很好的“脚手架”和“检查清单”，但不能代替你亲自与用户交流、分析数据、进行痛苦的权衡思考。它应该用于辅助和启发，而非取代你的批判性思维。
局限性三：知识的“滞后性”与“普适性”。技能库提炼自过去的播客内容，它代表的是截至某个时间点的“最佳实践”。而产品管理是一个快速发展的领域，新的方法论、工具和挑战不断涌现。同时，这些来自硅谷顶尖公司的经验，在应用到不同规模、不同行业、不同文化的公司时，可能需要重大的调整和适配。
5.3 进阶应用：从个人工具到团队知识引擎
对于团队领导者或创业者而言，这个项目的潜力远不止于个人效率提升。
设想一：团队入职与培训标准化。你可以将onboarding-new-hires、writing-prds、running-effective-1-1s等核心技能作为新员工入职培训的必读材料。让新PM在与AI的互动中，快速学习团队认可的工作方法和沟通语言，加速其融入和产出。
设想二：统一团队决策语言。在项目评审、需求讨论会前，要求大家先使用prioritizing-roadmap或evaluating-trade-offs技能来准备自己的论据。这能确保所有人都在同一套逻辑框架下讨论，减少因思维模式不同导致的无效争论，让讨论聚焦于事实和推理。
设想三：构建可传承的组织智慧。如前所述，通过Fork和定制，你可以将团队在成功或失败项目中获得的独特经验、总结的本地化框架，不断沉淀到自定义技能中。久而久之，这将形成一个极具价值的组织知识资产。即使有成员离职，他/她的经验也能通过技能库的形式部分保留下来，供后来者学习。
这个项目本质上是一个“知识即代码”（Knowledge as Code）的精彩实践。它将难以言传的隐性经验，编码成了可存储、可执行、可组合的显性模块。对于每一位产品从业者来说，它不仅仅是一个提升Claude Code能力的工具，更是一扇通往全球产品精英思维世界的窗口，以及一个构建自身和团队系统性产品能力的强大杠杆。真正的价值不在于你安装了多少个技能文件，而在于你如何将这些凝结的智慧，内化为自己的思考习惯，并创造性地应用于你所面临的独特挑战之中。
