PM Pilot v2.0.0：基于本地知识库的AI产品管理副驾驶实战指南

1. 项目概述一个为产品经理量身打造的AI副驾驶如果你是一名产品经理或者正在负责产品决策那你一定对这样的场景不陌生面对海量的用户访谈记录需要手动提炼核心痛点为了写一份PRD产品需求文档得反复查阅过往的竞品分析、公司战略每次开完会都要花大量时间整理会议纪要和待办事项。这些工作琐碎、重复却又至关重要它们消耗了你大量的“认知带宽”让你难以聚焦在真正的战略思考和产品创新上。PM Pilot v2.0.0 正是为了解决这个问题而生的。它不是一个普通的AI聊天机器人也不是一个需要复杂配置的SaaS平台。它是一个开源的、基于本地文件的AI技能系统专为像Claude Code、Cursor这类现代AI编程助手设计。你可以把它理解为一个“产品管理知识库”和“自动化工作流”的结合体。它的核心思想很简单让AI在你的工作上下文中学习、成长并基于这些上下文通过简单的“技能”命令帮你完成那些结构化的、重复性的产品管理工作。想象一下你不再需要每次都对AI说“请帮我分析一下竞品A和B的优劣势”而是直接输入/analyze-competitorsAI就能自动调用你之前积累的关于市场、公司目标的所有信息生成一份符合你公司视角的深度分析报告。或者当你拿到一堆零散的用户反馈时输入/triage-feedbackAI就能根据你定义的产品路线图和用户画像自动完成分类、优先级排序甚至建议处理路径。这就是PM Pilot带来的范式转变——从“零散的问答”到“基于上下文的自动化技能执行”。2. 核心设计理念为什么它比“空白AI聊天”更有效市面上的大多数AI工具包括ChatGPT的高级用法本质上还是“一问一答”的模式。你每次开启一个新对话都像面对一张白纸需要重新描述背景、设定角色、提供上下文。这对于探索性、创意性的问题或许有效但对于产品管理这种高度依赖持续积累的上下文公司战略、用户画像、产品现状、竞争格局的工作来说效率极其低下。PM Pilot的设计哲学正是要打破这种模式。2.1 上下文复利构建专属的产品知识图谱PM Pilot最核心的机制是它的“上下文系统”。所有关于你产品的知识都被结构化的存储在本地context/目录下的四个Markdown文件中company.md: 你的公司是谁愿景、使命、当前战略重点、资源约束、技术栈偏好是什么competitors.md: 市场竞争格局如何谁是直接竞品、间接竞品他们的核心优势、劣势、最新动向是什么personas.md: 你的用户是谁有哪些细分画像每个画像的核心目标、痛点、行为模式是什么哪些痛点是经过验证的强信号product.md: 你的产品现状如何核心功能有哪些技术架构有什么特点当前的北极星指标是什么已知的产品短板或技术债有哪些当你第一次运行/onboard命令时系统会引导你初步填充这些文件。关键在于这些文件是“活”的。它们不是你一次性填完就束之高阁的配置文件。每当你使用一个技能比如用/synthesize-interviews处理了5场用户访谈提炼出的新用户洞察和验证的痛点会自动更新到personas.md中并标记信号强度。当你用/analyze-competitors深度剖析了一个新对手分析结果会摘要更新到competitors.md。这样你使用PM Pilot越多这个上下文系统就越丰富、越精准就像一个为你产品量身定制的、不断进化的知识大脑。注意所有上下文文件都位于context/目录并且默认被.gitignore排除在版本控制之外。这意味着你的所有商业机密、用户数据、竞争情报都安全地留在你的本地机器上没有任何数据上传风险。这是选择本地AI助手Claude Code/Cursor搭配PM Pilot架构带来的核心安全优势。2.2 技能驱动而非提示词工程对于普通AI聊天完成一个高质量的任务比如写PRD需要你精心设计一个冗长、复杂的提示词Prompt包含角色设定、任务描述、输出格式要求、参考案例等等。这不仅门槛高而且难以复用和迭代。PM Pilot将这种复杂性封装成了一个个即开即用的“技能”Skill。每个技能如/prd,/prioritize背后都是一个精心设计的、符合产品管理最佳实践的“工作流模板”。你不需要知道这个模板的具体内容只需要触发技能并提供必要的输入比如一个模糊的产品想法、一堆用户反馈AI就会在后台调用相关的上下文并按照预设的逻辑框架生成结构化的输出。例如/prd技能内部可能封装了诸如“目标陈述”、“成功指标”、“用户故事”、“功能需求”、“非功能需求”、“开放问题”等标准模块。AI在生成时会自动从company.md中提取商业目标从personas.md中匹配目标用户及其痛点从product.md中考虑技术约束从而生成一份高度情境化、可直接用于团队评审的PRD草案。2.3 输入极度灵活告别繁琐的数据准备很多工具要求你将数据整理成特定格式才能处理这本身就是一个负担。PM Pilot在设计上极大降低了输入门槛提供了三种无缝的数据输入方式直接粘贴在AI助手的聊天窗口中直接将文本如会议转录稿、用户反馈列表粘贴进去然后输入技能命令。拖放文件路径在Claude Code或Cursor的终端Terminal里直接将文件如~/Downloads/user_interviews.txt拖进去然后输入技能命令AI会自动读取文件内容。引用工作区文件如果你的数据已经存在于项目工作区比如之前生成的某个竞品分析文档你只需在命令中提及它例如“请基于output/competitor_x_analysis.md文件运行/product-teardown”。这种灵活性意味着无论数据是刚从Zoom导出的转录文本还是散落在Slack频道的用户留言截图需OCR提取文字或是你随手记在备忘录里的想法都能被迅速投入PM Pilot的工作流中转化为有价值的产出。3. 从零开始详细安装与初始化指南虽然PM Pilot宣称“无需依赖、无需安装、无需API密钥”但为了能顺畅使用你需要正确设置基础环境。这个过程大约需要15-20分钟。3.1 环境准备选择你的AI助手PM Pilot设计运行在三个环境中Claude Code、Cursor和Codex。它们本质上都是集成了大型语言模型LLM的智能代码编辑器。你需要至少拥有其中一个。Claude Code由Anthropic公司开发深度集成Claude模型。其优势是对长上下文处理能力强逻辑推理严谨非常适合处理需要大量背景知识的文档分析和生成任务。对于产品管理这种文本密集型工作我个人更推荐它。Cursor一个新兴的AI优先的编辑器集成了多种模型包括Claude和GPT。它的交互非常流畅对项目结构的理解能力强在代码辅助方面表现突出。如果你日常工作中涉及大量与工程师的协作和原型技术讨论Cursor是不错的选择。Codex这里可能指的是类似GitHub Copilot或早期OpenAI Codex的环境。其核心优势是代码补全和生成。如果你的PM工作更偏向于技术产品经理TPM需要深度参与技术方案讨论这个环境可能更贴切。实操心得不要纠结先从你已经在用的或者最容易获取的开始。PM Pilot的技能在不同环境下的核心逻辑是一致的。我个人的工作流是使用Claude Code进行深度分析、文档撰写如PRD、竞品分析使用Cursor进行快速原型构思和与技术文档的交叉查阅。两者可以互补。3.2 获取PM Pilot项目打开你选择的AI助手以Claude Code为例找到并打开其内置的终端Terminal。克隆仓库在终端中运行以下命令。这将把PM Pilot的所有技能定义和模板文件下载到你的本地。git clone https://github.com/arezous/pm-pilot.git进入项目目录cd pm-pilot此时你的编辑器工作区应该已经切换到了pm-pilot文件夹。你可以看到项目结构已经展开。3.3 核心初始化运行/onboard命令这是最关键的一步它将引导你建立最初的上下文。在Claude Code或Cursor中你通常有一个专门的“AI聊天”面板或命令输入框。在AI聊天面板中直接输入命令/onboardAI会开始一个交互式的引导流程依次询问你关于公司、竞品、用户和产品的信息。这里有一个非常重要的心态调整不必追求完美和完整。公司写下公司名称、核心业务、短期本季度和长期年度目标、主要的资源或政策限制如必须使用某云服务、合规要求等。竞品列出2-3个最主要的直接竞争对手以及1-2个你欣赏的间接竞争对手或行业标杆。简单描述你为什么关注它们。用户描述1-2个你最核心的用户画像。他们是谁角色、行业他们想通过你的产品完成什么核心任务目标他们在过程中最大的挫折是什么痛点你知道的这些信息来源是什么是猜测还是来自5次用户访谈这决定了“信号强度”产品描述你的产品是什么目前的核心功能有哪些你认为最大的优势是什么以及当前面临的主要挑战或用户抱怨最多的问题是什么。完成引导后PM Pilot会在context/目录下生成四个Markdown文件并填充你刚才输入的内容。你可以随时打开这些文件如context/company.md进行修改和细化。注意事项初次填写时信息粗糙、不完整是完全正常的。上下文系统的威力在于“迭代生长”。比如当你第一次运行/analyze-competitors时可能会发现对某个竞品的理解很肤浅AI生成的报告也会比较空泛。但这没关系你可以把这份初步报告作为起点手动补充一些你的见解然后保存回context/competitors.md。下次再分析时起点就更高了。不要试图在开始前就建立一个完美的知识库而是在使用中逐步完善它。4. 核心技能深度解析与实战应用PM Pilot提供了一系列技能覆盖了产品经理日常工作的核心环节。下面我将挑选几个最常用、最能体现其价值的技能进行深度拆解并分享实战中的技巧和避坑点。4.1/prd从模糊想法到结构化文档写PRD是产品经理的基本功也是耗时大户。/prd技能能将这个过程的效率提升数倍。典型工作流你有一个新功能的想法比如“为我们的SaaS仪表盘增加一个数据导出到PDF的功能”。在AI聊天框中输入/prd。AI会首先询问你这个PRD的核心主题或目标。你输入“为高级用户增加仪表盘数据一键导出为PDF报告的功能”。接着AI可能会追问一些细节比如“这个功能主要服务于哪个用户画像你希望报告包含哪些核心数据视图对报告的设计风格有品牌要求吗” 这些问题都是它根据context/personas.md和context/company.md自动生成的旨在填补上下文中的空白。你逐一回答。AI开始生成。它会自动从上下文中提取信息背景与目标结合company.md中的季度目标如“提升高级用户留存率”。用户与场景关联personas.md中的“数据分析师-李雷”画像描述他每月需要向管理层汇报手动截图拼接数据非常痛苦。成功指标建议如“10%的高级用户每周使用此功能”、“用户生成报告的平均时间减少50%”。功能需求详细描述导出按钮位置、格式选项A4/Letter、包含的图表、自定义标题页等。非功能需求考虑到product.md中提到的“当前服务器负载较高”会特别注明“PDF生成需异步处理避免阻塞主线程”。开放问题提出诸如“是否支持定时自动生成报告并邮件发送”、“导出的PDF是否包含交互式图表链接”等需要团队讨论决策的问题。实操心得与避坑指南不要期待一键生成完美PRDAI生成的是一份高质量、结构化、情境化的草案。它为你搭好了骨架填入了大量基于上下文的合理内容但最终的决策、权衡和细节打磨仍需你这个产品负责人来完成。它的价值在于省去了你从零搭建框架和查找背景信息的时间。善用“追问”环节当AI在生成前向你提问时这是它试图理解你独特需求的机会。你的回答越具体产出越精准。例如当它问“服务于哪个用户画像”时不要只说“高级用户”而应该说“主要服务于personas.md中定义的‘企业管理员-王伟’他需要定期向采购部门提供使用情况审计报告”。生成后的迭代生成的PRD会保存在output/目录。你需要仔细审阅修改不准确的地方补充技术实现细节的讨论。定稿后手动将其移动到context/prd/目录可能需要新建。这样未来当你开发相关功能或进行复盘时这份PRD就成了你产品上下文的一部分可以被其他技能引用。4.2/synthesize-interviews从原始记录到用户洞察处理用户访谈记录是提炼需求的关键但也是信息过载的重灾区。这个技能能将杂乱无章的文本转化为清晰的洞察。操作流程你将过去一周的5场用户访谈转录文本一个巨大的.txt或.md文件拖入终端或者粘贴到聊天窗口。输入命令/synthesize-interviews。AI会开始处理这些文本它的工作通常包括提取关键语录找出用户表达强烈情绪挫折、惊喜、渴望的句子。聚类主题将相似的痛点、需求、建议归类形成如“登录流程繁琐”、“报告自定义能力不足”、“移动端体验差”等主题。量化提及频率统计每个主题被多少不同的用户提及这为优先级判断提供了初步数据支持。关联现有画像尝试将提取出的需求与context/personas.md中的现有画像匹配或提出创建新画像的建议。生成建议针对每个主题提出可能的产品改进方向或待验证的假设。实战技巧预处理你的转录稿如果转录稿质量很差充满“呃”、“嗯”、重复语句可以先用AI简单清理一下。给AI一个提示“请清理以下访谈转录稿去除语气词和重复冗余的句子保持原意。” 然后再将清理后的文本交给PM Pilot处理效果会好很多。关注“信号强度”技能输出中对于“某个痛点被10个用户中的8个提及”这样的洞察要高度重视。你可以手动将这条洞察连同提及的用户数量更新到context/personas.md中对应画像的“已验证痛点”部分并标注为“强信号”。这为后续的/prioritize提供了关键依据。区分“需求”和“解决方案”用户经常混淆两者。AI有时也会混淆。例如用户说“我需要一个更快的按钮”这可能是解决方案其背后的需求可能是“我需要在3秒内完成这个高频操作”。在审阅AI生成的洞察时要有意识地进行这种剥离并将真正的“需求”更新到上下文中。4.3/prioritize在复杂决策中寻找清晰路径优先级排序是产品经理的核心决策。这个技能将你的功能列表与丰富的上下文结合提供一个数据驱动的优先级建议。如何使用你有一个包含10个潜在功能创意的列表可能来自用户反馈、团队头脑风暴或战略规划。输入命令/prioritize。AI会要求你提供这个功能列表。你可以直接粘贴或者提供一个包含列表的文件路径。AI会基于以下维度这些维度隐含在它的算法中并受你的上下文影响对每个功能进行评分商业价值对齐度该功能在多大程度上直接推动company.md中定义的当前目标如“增加营收”、“提升市场份额”用户影响力该功能解决了personas.md中哪个画像的痛点是“强信号”痛点还是“弱信号”痛点影响的用户基数有多大实施成本/复杂度根据product.md中的技术架构现状AI会粗略评估开发该功能可能涉及的工作量前端、后端、数据层变更。这需要你在上下文中对技术栈有基本描述。风险与不确定性该功能所依赖的假设是否经过验证是否涉及未经验证的新技术最终AI会输出一个排序后的功能列表通常附有简单的评分和理由。它可能还会建议采用“性价比矩阵”价值 vs 成本或“RICE评分模型”覆盖范围、影响、信心、努力来可视化这些功能。决策辅助而非决策替代理解模型的局限性AI的评分是基于你提供的上下文和它内置的权重逻辑。它无法量化那些微妙的、政治性的或极其长远的战略因素。例如“修复某个大客户抱怨的一个小bug”可能在商业价值评分上不高但其对客户关系的影响是巨大的。AI的输出是一个强大的参考但最终的排序必须由你结合实际情况拍板。手动调整与反馈你可以对AI的排序提出质疑。例如你可以问“为什么你把‘功能A’排在‘功能B’后面我认为A对我们获取第一批企业用户至关重要。” AI会解释它的推理过程例如“因为根据上下文当前季度目标是提升用户留存而非获客”。这个辩论过程本身极具价值能迫使你澄清自己的战略假设。输出物的使用将最终的优先级排序结果连同简要理由保存到context/下的相关文件中例如更新product.md的“近期路线图”部分。这确保了团队对齐并为下一次优先级讨论提供了历史依据。4.4/triage-feedback自动化处理用户反馈洪流来自应用商店评论、客服工单、用户访谈、社交媒体等渠道的反馈纷繁复杂。这个技能能帮你快速理清头绪。工作流程你将一堆原始反馈例如从Zendesk导出的最近100条工单摘要输入给技能。AI会自动进行多轮处理分类将反馈归入“Bug报告”、“功能请求”、“用户体验问题”、“使用咨询”等类别。去重与聚合识别描述同一问题的不同反馈将其合并并统计受影响用户数。严重性评估对于Bug尝试评估其影响范围是影响所有用户还是特定配置和严重程度是导致数据丢失的崩溃还是界面错位。路由建议建议处理路径。例如“高频出现的功能请求建议加入产品需求池由PM评估”“特定环境的Bug附上详细日志转给后端工程师张三”“使用咨询整理成FAQ转给客服团队”。输出通常是一个结构化的表格包含分类、摘要、出现频率、建议处理方式和负责人。效率提升的关键建立分类标准你可以在context/company.md或一个单独的feedback_categories.md文件中预先定义好你们团队使用的反馈分类和路由规则。这样AI在分类和路由时会更加精准。与现有工具集成虽然PM Pilot是本地工具但其输出一个结构化的CSV或Markdown表格可以很容易地复制粘贴到Jira、Linear、Asana等项目管理工具中快速创建工单或需求卡片。定期运行形成节奏可以设定每周一上午将过去一周收集的所有反馈丢给/triage-feedback处理生成一份报告。这能让你对用户声音保持高频、系统的感知而不是被动地应对最响亮的抱怨。5. 高级技巧与个性化定制当你熟练使用基础技能后可以通过一些高级用法和定制让PM Pilot更贴合你的个人工作流。5.1 技能组合构建自动化工作流PM Pilot的技能可以像乐高积木一样组合使用形成自动化的工作流管道。这需要你手动串联但一旦建立威力巨大。示例从用户访谈到产品待办项Backlog的自动化流水线输入将本周的所有用户访谈录音转录为文本文件interviews_week_24.md。步骤一洞察合成。运行/synthesize-interviews输入该文件。产出一份洞察报告output/interview_synthesis.md其中包含了聚类后的用户痛点和建议。步骤二生成需求创意。你可以手动从洞察报告中提炼出5个潜在的功能改进点形成一个列表potential_features.md。或者更进阶一点你可以直接要求AI从洞察报告中帮你提取“请根据output/interview_synthesis.md中的洞察列出5个最可能提升用户满意度的具体功能改进建议。”步骤三优先级排序。运行/prioritize输入上一步得到的功能列表。产出一个排序后的功能列表output/prioritized_features.md。步骤四生成PRD草案。选择优先级最高的1-2个功能分别运行/prd生成详细的需求文档。步骤五拆解任务。对定稿的PRD运行/break-down将其拆解为工程师可执行的工作项如“API接口设计”、“前端组件开发”、“数据库变更”等。通过这个流程你将原始的、非结构化的用户声音自动转化为了排好序的、可执行的产品开发任务。你只需要在关键节点如从洞察提炼功能点、评审PRD草案进行人工判断和干预。5.2 定制模板与风格PM Pilot的输出模板和风格是可以定制的。项目中的template/目录存放了各种输出格式的模板和风格指南。修改现有模板如果你觉得默认的PRD模板不符合你公司的标准你可以直接修改template/目录下对应的文件。例如你的公司要求所有PRD必须包含“安全与隐私影响评估”章节你就可以把这个章节加到模板里。添加受众特定风格template/styles/目录下可能有executive.md面向高管的简洁风格、slack.md适合在Slack发布的简短格式、notion.md适配Notion数据库的属性格式。你可以根据输出物的阅读对象在命令中指定风格或者创建你自己的风格文件。例如你可以创建一个engineering.md风格要求技术细节更详尽非功能需求更突出。创建自定义技能对于高度重复、且现有技能无法覆盖的特定任务你可以参考claude/skills/目录下的示例创建你自己的技能。这需要一些对AI助手“技能”定义机制的理解但一旦创建就能极大提升你在特定场景下的效率。例如你可以创建一个/generate-usertest-script的技能专门用于为新功能生成用户测试脚本。5.3 上下文文件的精细化管理上下文文件是你的核心资产需要像维护代码一样维护它们。定期回顾与更新设定一个每两周或每月一次的“上下文维护”时间。回顾company.md中的目标是否更新检查competitors.md中竞品是否有重大动作审视personas.md中的用户痛点是否被新产品验证或推翻。版本化备份虽然context/被.gitignore但你可以考虑使用其他方式备份。例如定期将整个context/文件夹压缩加上日期标签存档。或者如果你不介意在去除敏感信息后可以将其纳入一个私有的Git仓库进行版本管理这能让你清晰地看到产品认知的演变历史。分拆大文件当personas.md变得非常庞大时可以考虑按用户细分拆分成多个文件如personas_enterprise.md,personas_individual.md然后在主personas.md文件中通过链接引用。这能让上下文更清晰也减轻AI一次性处理过长上下文的负担。6. 常见问题与故障排查在实际使用中你可能会遇到一些典型问题。以下是一些排查思路和解决方案。问题1AI生成的输出质量不高感觉泛泛而谈。可能原因A上下文太薄弱。检查你的context/文件。如果里面只有一两句空洞的描述如“我们的目标是做出最好的产品”AI自然无法生成具体、情境化的内容。回去运行/onboard或手动丰富这些文件加入具体的数据、案例和细节。可能原因B输入信息太模糊。当你运行/prd时如果只输入“做一个社交功能”AI缺乏足够的约束条件。尝试提供更具体的输入“为我们的健身应用增加一个‘挑战赛’功能用户可创建7天打卡挑战并邀请好友参加旨在提升用户粘性和社交互动。”可能原因C技能理解偏差。尝试在命令后增加更具体的指令。例如/prd --formatone-pager --audienceexecutive如果技能支持此类参数。或者在输入命令后在下一句话中明确要求“请重点突出该功能与当前季度‘提升用户留存’目标的关联并采用面向高管的简洁风格。”问题2AI似乎没有读取我刚刚更新的上下文文件。解决方案大多数AI助手如Claude Code对工作区文件的索引和读取有一定延迟或缓存机制。尝试以下步骤保存并关闭你刚修改的上下文文件。在编辑器中完全关闭再重新打开pm-pilot项目文件夹。或者在AI聊天框中明确引用文件。例如不要说“根据我们的公司目标”而说“请参考context/company.md中第三季度目标来评估这个功能”。问题3/break-down拆解的任务过于技术化或不够详细。可能原因AI对你们团队的技术栈和开发流程了解不足。解决方案在context/company.md或product.md中增加一个“技术栈与开发规范”章节。简要说明你们的前后端主要技术如React, Go常用的架构模式以及任务拆解时通常考虑的维度如“前端组件”、“后端API”、“数据库迁移”、“测试用例”。AI在拆解任务时会参考这些信息。问题4如何将PM Pilot的产出与团队现有工具如Jira, Confluence结合解决方案PM Pilot本身不直接集成但其输出都是标准的Markdown或文本。你可以复制粘贴将生成的PRD、会议纪要等内容直接复制到Confluence页面。导出为文件将output/下的文件稍作格式调整作为附件发送或上传。利用AI助手在Cursor或Claude Code中你可以直接要求AI“将下面这份PRD草案转换成适合导入Jira的Epic和User Story格式列表。” AI可以帮你做格式转换。问题5在团队中推广使用如何保证上下文的一致性挑战如果多个PM共用一套PM Pilot但他们对公司目标、用户画像的理解不一致会导致上下文混乱。建议方案建立核心上下文由产品负责人或首席产品官维护一套“官方”的、共识性的company.md和personas.md核心版本存放在团队共享的某个位置需注意安全。个性化分支每个PM克隆PM Pilot项目后可以基于官方核心上下文在自己的context/中创建针对其负责模块的细化文件如context/personas_my_module.md。定期同步会定期举行产品上下文评审会分享各自从用户反馈、数据分析中获得的新洞察并决定哪些需要更新到“官方”核心上下文中。PM Pilot生成的报告可以作为讨论的基础材料。PM Pilot不是一个“安装即完美”的魔法黑盒而是一个需要你用心“喂养”和“调教”的智能伙伴。它的效果与你投入的上下文质量、你使用技能的熟练度、以及你将其融入工作流的巧妙程度直接相关。从一个技能开始解决一个具体的痛点逐步积累你的上下文你会发现它正在悄然改变你处理产品信息的方式让你从信息的泥潭中挣脱出来更专注于思考、决策和创造。