IDE内嵌AI产品副驾驶：用对话式工作流实现文档即代码

1. 项目概述在IDE里嵌入一个产品经理副驾驶如果你和我一样既是开发者又时不时要客串产品经理的角色那你肯定对下面这个场景不陌生脑子里蹦出一个绝妙的产品点子兴奋地打开代码编辑器准备大干一场结果在“先写代码”还是“先写文档”之间反复横跳。直接写代码吧写着写着就发现功能越加越多最初的简单想法变得面目全非停下来写文档吧又觉得打断了心流而且那些传统的文档工具Confluence、Notion离你的开发环境太远切换起来极其割裂。pm-workflow-copilot-ide这个项目就是为了解决这个痛点而生的。它不是一个独立的应用而是一个专门为Cursor和Cline这类AI驱动的现代IDE设计的“规则包”。它的核心思想是将一套轻量级、强引导的产品管理流程直接嵌入到你每天都在用的编辑器聊天框里。让你在跟AI助手讨论代码的同时就能被它引导着一步步把一个模糊的想法结构化地梳理成清晰的产品文档比如产品章程、机会简报、MVP范围文档和PRD。简单来说它让你的AI编程助手同时兼任你的产品管理副驾驶。你不用离开编码环境就能完成从想法探索到需求定义的全过程而且所有产出的文档Markdown格式就放在你的项目代码旁边实现真正的“文档即代码”。2. 核心设计理念与工作原理解析2.1 为什么是“IDE内嵌式”工作流传统的产品管理工具和开发环境是分离的。这种分离导致了几个问题上下文切换成本高开发者需要从IDE跳到浏览器打开另一个工具心智模式完全被打断。文档与代码脱节产品文档更新了但代码可能没同步功能实现了文档却忘了补。两者版本不同步是常态。流程僵化阻碍创新重型流程工具为了满足大团队的复杂协作往往设计得极其繁琐对于小团队或独立开发者来说光是填完那些表单就足以扼杀创作热情。pm-workflow-copilot-ide的设计反其道而行之。它认为对于追求速度的初创团队或个人项目流程应该服务于创作而非束缚创作。因此它选择了最轻的载体——IDE的AI助手规则。通过预定义一套对话流程和文档模板AI助手能在你聊天的过程中适时地提出关键问题“目标用户是谁”“要解决的核心痛点是什么”并基于你的回答自动生成结构化的Markdown文档。这样做的好处是显而易见的无感集成你不需要安装新软件只需在现有IDE中加载这个规则包。对话式引导流程推进是自然聊天的一部分符合人类思考习惯减少了面对空白文档的恐惧。资产即代码所有文档都是项目根目录下的.md文件可以用git进行版本管理评审时可以直接提PR修改文档实现了流程的民主化和透明化。2.2 核心组件拆解规则、记忆与产出物这个规则包的结构清晰地体现了它的运作机制。理解这三个部分你就能明白它到底是怎么“思考”的。1. 规则AI的行为剧本规则文件 (rules/01-rules/01-pm_workflow_assistant.md) 是整个副驾驶的“大脑”。它本质上是一份给AI助手的详细指令集规定了工作流阶段明确将产品管理过程分为“战略对齐”、“问题发现”、“方案定义”、“可行性评估”和“需求定义”五个阶段。每个阶段的行动在特定阶段AI应该问什么问题提供什么选项根据用户的回答触发什么动作。文档生成逻辑定义了每种产出物如product_charter.md,mvp_scope.md的文件名、存储路径和基本内容结构。状态跟踪指示AI如何创建和更新pm-progress.json文件以记录项目当前进展到哪个阶段。你可以把这份规则文件看作一个高度定制化的“提示词工程”成果它把零散的、需要你主动提问的AI交互变成了一套有章可循的引导式对话。2. 记忆副驾驶的知识库memory_starters/目录下的文件会在规则包激活时被加载到AI的短期记忆中。这相当于给副驾驶配备了“上岗培训手册”。product_management_workflow_startup.md这是工作流的详细说明书比规则文件更具体包含了每个阶段的定义、目标、核心问题清单和最佳实践。AI在需要深入理解某个概念时会参考它。pm-progress-template.json定义了进度跟踪文件的JSON结构确保AI生成的文件格式统一。examples/内置的示例想法如天气应用、待办列表让用户能快速体验工作流也作为AI学习“如何开始一个项目对话”的范例。3. 产出物结构化的项目资产当副驾驶开始工作时它会在你的项目根目录创建pm_project_docs/[项目名称]/文件夹。所有生成的Markdown文档都会放在这里。这种设计坚持了“文档即代码”的理念版本可控所有文档和代码一起受git管理变更历史清晰可查。评审友好技术评审时可以直接对文档提修改意见流程更顺畅。上下文完整产品决策和业务逻辑就放在实现它们的代码旁边任何接手项目的人都能快速理解“为什么这么写”。2.3 与Rulebook-AI生态的关系需要特别注意的是这个项目目前处于“实验性”状态。它本质上是一个概念验证验证了在IDE内通过AI规则实现产品工作流的可行性。其长期目标是融入一个更宏大的生态——Rulebook-AI。Rulebook-AI 是一个跨IDE的AI助手规则与记忆管理工具包。你可以把它想象成一个“规则应用商店”或“AI技能包管理器”。pm-workflow-copilot-ide项目探索的功能最终计划是作为Rulebook-AI生态中的一个官方“产品管理技能包”来提供。这意味着未来你可能不再需要单独克隆这个仓库而是通过Rulebook-AI的CLI工具一键安装这个“产品副驾驶”技能包到你的Cursor或Cline中。注意由于项目处于实验阶段依赖的Rulebook-AI工具链可能快速迭代。在按照安装指南操作时如果遇到问题第一排查点应是检查Rulebook-AI仓库的最新README和Issues看是否有接口变更。3. 从零开始实操安装与初体验了解了原理我们来看看如何亲手把它用起来。这里我会提供两种方法推荐的CLI自动安装和手动配置。我会以在CursorIDE 中操作为例因为目前它的用户基数更大但流程对Cline同样适用。3.1 环境准备与前置依赖在开始之前你需要确保本地环境满足以下条件Python 3.8Rulebook-AI的CLI工具基于Python。打开终端输入python3 --version检查。Git用于克隆仓库。一个AI驱动的IDECursor(推荐) 或Cline。确保你已经安装并能正常使用其AI聊天功能。包管理工具 uv (推荐)Rulebook-AI推荐使用uv进行Python包管理它比传统的pip更快、更现代。如果你没有可以通过curl -LsSf https://astral.sh/uv/install.sh | sh一键安装。3.2 方法一使用Rulebook-AI CLI安装推荐这是最标准、未来兼容性最好的方式。整个过程就像安装一个IDE插件。步骤1安装Rulebook-AI CLI首先我们需要把Rulebook-AI这个“应用商店”装到本地。# 克隆Rulebook-AI的主仓库 git clone https://github.com/botingw/rulebook-ai.git cd rulebook-ai # 使用uv以可编辑模式安装方便后续更新 uv run pip install -e . cd ..安装成功后在终端输入rulebook-ai --help应该能看到命令列表证明CLI工具已就绪。步骤2获取并添加pm-workflow-copilot规则包接下来我们需要把这个“产品副驾驶技能包”添加到Rulebook-AI的管理列表中。# 克隆本规则包的仓库 git clone https://github.com/botingw/pm-workflow-copilot-ide.git cd pm-workflow-copilot-ide # 将此包添加到rulebook-ai的包管理中 rulebook-ai packs add pm-workflow-copilot # 将此包同步到你当前的项目或全局环境 rulebook-ai project sync --pack pm-workflow-copilotrulebook-ai packs add命令会读取包内的manifest.yaml文件注册这个包。project sync命令则是将这个包的规则和记忆文件链接或复制到你的IDE助手能读取的位置。步骤3在Cursor中验证与启动打开或重启你的Cursor。新建或打开一个任意项目比如一个空的代码目录。打开Cursor的AI聊天面板通常是Cmd/Ctrl K。现在尝试输入触发语。根据规则包的设定你可以直接说“我们来做一个天气应用吧。”或者“我想开始一个新的产品想法关于一个帮助自由职业者追踪计费时间的工具。”如果一切配置正确你应该会立刻收到AI助手的回复它不再只是泛泛地回应而是会开始引导你“好的让我们从战略对齐开始。这个工具的主要用户是谁我们打算解决他们的什么痛点”同时你应该能在项目根目录下看到新生成了一个pm_project_docs/weather_app/或你项目名对应的文件夹里面可能已经有一个初始的pm-progress.json文件。3.3 方法二手动配置IDE规则备用方案如果CLI安装遇到问题或者你想更深入地理解背后机制可以尝试手动配置。以Cursor为例其AI助手的规则通常可以通过在项目根目录创建特定的配置文件来加载。步骤1定位规则文件在克隆的pm-workflow-copilot-ide仓库中核心规则文件是pm-workflow-copilot-pack/rules/01-rules/01-pm_workflow_assistant.md。记忆文件在memory_starters/docs/下。步骤2为Cursor创建配置文件在你自己的工作项目根目录下创建一个名为.cursor/rules/的文件夹如果不存在的话。然后将上述核心规则文件01-pm_workflow_assistant.md复制到.cursor/rules/目录下。你可以考虑重命名为更直观的名字如product_copilot.md。步骤3提供记忆上下文关键步骤仅仅有规则还不够AI助手需要工作流的详细知识。你需要手动将这些知识提供给AI。打开Cursor的AI聊天面板。在开始对话前使用Cursor的“附加文件”或“提供上下文”功能具体名称因版本而异将memory_starters/docs/product_management_workflow_startup.md文件作为上下文附加给AI。同样地你也可以附加pm-progress-template.json作为参考。步骤4开始对话现在你可以像之前一样在聊天框中输入“让我们开始做一个待办列表应用”。由于AI已经拥有了规则和详细的工作流知识它应该能做出类似的引导性回应。实操心得手动配置虽然直观但每次新开项目或对话都需要重新附加记忆文件非常繁琐且容易遗漏。它只适合临时体验或调试。对于长期使用强烈推荐克服初期困难采用CLI安装方式一劳永逸。4. 深度使用指南驾驭你的产品副驾驶安装成功只是第一步真正发挥其威力在于日常使用。下面我以一个虚拟项目“个人知识库闪光点捕捉工具”为例带你走一遍完整流程并分享一些高阶技巧。4.1 完整工作流阶段演练假设我们想做一个工具帮助用户在阅读文章或浏览网页时快速捕捉并结构化保存那些“灵光一现”的想法。阶段一战略对齐 - 生成product_charter.md你“我想做一个帮助用户捕捉阅读时闪光点想法的工具。”副驾驶“很好的起点让我们先明确战略。这个产品的核心愿景是什么它主要为哪类用户服务解决了他们什么关键问题”经过几轮问答AI会总结并提议“基于我们的对话我将为您生成《产品章程》。它将包含愿景陈述、目标用户画像、核心问题与价值主张。确认生成吗”生成物在pm_project_docs/knowledge_spark/下你会得到product_charter.md内容已经填充了你们讨论的要点。阶段二问题发现 - 生成opportunity_brief.md副驾驶“接下来我们需要深入理解用户和问题。我可以为您起草一份机会简报包括用户场景、痛点分析和市场机会。是否需要我基于现有信息生成一个草案供您完善”你“好的请生成草案并为我列出5个可以用于用户访谈的验证性问题。”生成物opportunity_brief.md文件生成末尾附带了5个调研问题如“你通常用什么工具记录突然的想法不满意的地方是什么”阶段三方案定义 - 生成mvp_scope.md你“根据简报我们来定义一下MVP的范围吧。”副驾驶“收到。我将围绕‘浏览器插件快速捕获’和‘简单的标签分类’这两个核心功能起草MVP范围文档。我会列出核心用户故事、成功指标如‘一周内回访率’并明确说明首版不做‘跨设备同步’和‘复杂关系图谱’。这样可以吗”生成物mvp_scope.md生成清晰地划定了做什么和不做什么这是控制项目范围蔓延的关键。阶段四可行性评估 - 生成technical_feasibility.md和business_viability.md副驾驶“进入可行性阶段。技术层面我们需要评估浏览器插件开发、后端数据存储的选型。商业层面需要考虑简单的变现可能性。我先帮您起草技术可行性评估如何”你“先做技术评估。另外商业方面我们可以先考虑免费增值模式。”生成物先后生成两个文件分别从技术实现难度、依赖项、风险评估以及潜在收入、成本、增长策略角度进行分析。阶段五需求定义 - 生成prd.md你“现在信息差不多了生成最终的产品需求文档吧。”副驾驶“我将综合之前所有文档生成一份结构化的PRD包含功能需求、非功能需求性能、可用性、发布计划和验收标准。正在创建prd.md。”至此一个从点子到清晰需求的产品管理循环就在与AI的对话中轻松完成了。所有思考过程被自然记录产出物井然有序。4.2 高效交互技巧与命令除了跟随引导你还可以主动“驾驶”你的副驾驶查询进度任何时候输入“我的‘知识闪光点’项目进展到哪了”AI会读取pm-progress.json并告诉你当前阶段和下一步建议。跳转阶段如果你觉得某个阶段已经思考成熟可以直接命令“请直接为当前项目生成MVP范围文档”AI会基于已有上下文尝试生成如果信息不足它会向你提问。修订文档对生成的文档不满意直接说“我觉得产品章程里的价值主张不够有力请结合‘帮助用户建立第二大脑’这个比喻重写一下”。AI会修改对应的Markdown文件。多项目管理副驾驶通过不同的项目文件夹来区分上下文。你可以同时进行“项目A”和“项目B”的对话只要在聊天中明确提及项目名称它就能正确切换上下文和操作对应的pm_project_docs/[project_name]目录。4.3 与开发流程的集成实践“文档即代码”的威力在协同工作中才能真正体现。以下是两种实践模式模式一Git工作流集成为每个产品功能或史诗Epic创建一个新的Git分支例如feat/spark-capture。在该分支上使用副驾驶生成或更新相关的产品文档如prd.md中关于“快速捕获”的详细需求。在实现代码之前先发起一个“文档PR”。邀请团队成员开发者、设计师、其他PM评审pm_project_docs/下的相关Markdown文件。评审通过后合并文档分支。然后基于这份已达成共识的文档再开始编码。这样代码PR的目标就非常明确。模式二在代码评审中关联文档在提交代码PR时在描述中可以直接引用相关的产品文档## 功能描述 实现 prd.md 中定义的“浏览器插件一键捕获”功能章节3.1。 ## 变更内容 - 新增了 background.js 监听快捷键... - 修改了 popup.html 增加标签选择... **相关文档**pm_project_docs/knowledge_spark/prd.md评审者可以轻松点击链接查看原始需求确保实现与设计初衷一致。注意事项虽然副驾驶能生成结构良好的文档初稿但它不能替代深度的用户研究和战略思考。它更像一个“思考的记录员和框架的提醒者”。最终的产品决策、对用户痛点的深刻洞察仍然需要你——产品的负责人——来把握和输入。切勿陷入“AI生成即真理”的陷阱所有生成内容都必须经过你的严格审视和修正。5. 常见问题、故障排查与进阶配置在实际使用中你可能会遇到一些问题。这里我整理了一份从入门到进阶的排错指南。5.1 安装与基础使用问题问题现象可能原因解决方案运行rulebook-ai命令提示“未找到命令”1.uv run pip install -e .安装失败或未生效。2. 终端会话未更新PATH。1. 确保在rulebook-ai目录下执行安装命令并注意看有无报错。2. 关闭当前终端重新打开一个再试。或尝试使用python3 -m rulebook_ai.cli代替rulebook-ai。rulebook-ai packs add失败提示包无效1. 未在规则包根目录执行。2.manifest.yaml文件格式错误或丢失。1. 确保当前目录包含pm-workflow-copilot-pack文件夹和manifest.yaml。2. 检查manifest.yaml文件确保其是有效的YAML格式且包含name: pm-workflow-copilot等关键字段。在Cursor中聊天AI无引导反应1. 规则包未正确同步到IDE。2. Cursor的AI模型未加载项目上下文。3. 触发短语不匹配。1. 确认rulebook-ai project sync执行成功且无报错。可尝试重启Cursor。2. 检查Cursor设置中是否启用了“使用项目上下文”或类似选项。3. 尝试使用更明确的短语如“让我们按照产品工作流开始规划一个天气应用项目。”生成的文档路径不对或内容混乱AI助手混淆了项目上下文。可能同时打开了多个项目或工作区。1. 在Cursor中确保聊天面板是针对当前单一项目窗口的。2. 在对话开始时明确项目名称如“针对‘项目Alpha’我们来制定产品章程。”3. 检查项目根目录是否正确。5.2 规则与工作流定制默认的工作流可能不完全符合你的团队习惯。好消息是这个规则包是高度可定制的。1. 修改工作流阶段打开pm-workflow-copilot-pack/rules/01-rules/01-pm_workflow_assistant.md你可以找到定义阶段的章节。例如如果你的团队在“方案定义”后增加一个“原型测试”阶段你可以在规则文件中相应位置添加新阶段的描述、目标和输出文档如prototype_feedback.md。在memory_starters/docs/product_management_workflow_startup.md中补充该阶段的详细说明。更新pm-progress-template.json中的阶段枚举。2. 自定义文档模板如果你觉得生成的prd.md格式不符合公司规范可以直接修改规则文件中关于生成PRD的部分。例如你可以要求AI必须包含“数据指标定义”、“A/B测试方案”等固定章节。规则文件本质是Markdown你可以用清晰的指令描述你想要的任何结构。3. 集成团队知识库将你们团队独有的产品设计规范、用户画像模板、竞品分析框架等文档放入memory_starters/docs/目录下。当规则包加载时这些知识也会被注入AI的上下文使得它生成的建议和文档更贴合你们的实际情况。5.3 性能与上下文管理优化AI助手的上下文长度是有限的。当你的项目文档越来越多聊天历史越来越长时可能会遇到AI“遗忘”规则或之前讨论内容的情况。策略一主动管理聊天会话针对一个具体的任务如评审MVP范围开启一个新的聊天会话。在新的会话中AI会重新加载项目根目录下的规则确保规则指令清晰。策略二关键信息摘要在对话复杂时可以主动要求AI“请将我们目前关于目标用户和核心功能的共识总结成三段话。”然后将这个总结在后续对话中必要时贴回以刷新上下文。策略三规则包的精简如果memory_starters中的文档非常庞大可以考虑只保留最核心的product_management_workflow_startup.md将其他参考文档移至外部链接需要时再附加。6. 局限、展望与替代方案探讨没有任何工具是银弹pm-workflow-copilot-ide也不例外。清醒地认识它的边界能帮助你更好地利用它。6.1 当前局限性强依赖IDE生态目前深度绑定Cursor/Cline。如果你使用VS Code with Continue、JetBrains AI Assistant等其他AI编码工具需要等待Rulebook-AI生态扩展支持或自行移植规则。AI的不确定性生成文档的质量受限于底层大语言模型的能力和当前对话的上下文。有时它可能遗漏重点或产生需要你反复纠正的“车轱辘话”。复杂协作支持有限它擅长引导个人或小团队梳理思路。但对于需要复杂权限管理、多人在线实时编辑、复杂工作流审批的大型企业级产品管理场景它无法替代Jira、Productboard等专业工具。实验性状态正如项目自身声明它可能被重构、合并或API发生变化不适合用于极其稳定、长期的核心生产流程。6.2 生态展望与替代工具该项目指向了一个未来趋势AI原生的工作流工具将深度嵌入到我们的生产环境中成为无形的“副驾驶”。Rulebook-AI的愿景正是管理无数个这样的“技能包”。如果你喜欢这个理念但需要更成熟或不同形态的工具可以考虑Claude for Desktop / ChatGPT with Advanced Data Analysis你可以手动上传一套产品管理框架提示词和模板在聊天中类似地引导它们生成文档。缺点是需要手动管理上下文和文件。Windsurf / Bloop这些是另一类AI优先的代码编辑器它们通常有强大的代码库理解和操作能力未来也可能发展出类似的内置工作流功能。传统工具的AI插件许多现有的产品管理工具如Notion、Coda正在积极集成AI功能用于辅助生成用户故事、整理反馈等但它们可能不具备这种从零开始的、对话式的全流程引导能力。6.3 我的使用体会与建议经过一段时间的深度使用我个人最大的体会是这个工具最大的价值不在于“自动化生成文档”而在于“结构化思考过程”。在以前当我有一个新想法时思维是发散的很容易跳过关键问题直接陷入细节。而这个副驾驶就像一个耐心的教练每次对话都强制我按顺序回答“用户是谁”“痛点是什么”“怎么做才算成功”。这个过程本身比最后产出的那几份Markdown文件更有价值。对于想要尝试的同行我的建议是从小处着手不要第一个项目就用于你最重要的核心产品。找一个业余小项目或一个功能点子来试水熟悉它的节奏和局限。把它当思考伙伴而非秘书主动向它提问挑战它的建议而不仅仅是被动接受输出。例如当它生成MVP范围后你可以问“你基于什么逻辑排除了‘社交分享’功能如果加入对核心价值主张是增强还是稀释”定制化你的流程花点时间根据你团队的实际工作流修改规则文件。让它真正为你服务而不是你去适应它。比如加入你们特有的“合规性检查清单”或“安全隐私评估”环节。管理好你的数字资产定期整理pm_project_docs里的文件。将已完结项目的文档归档将反复验证有效的用户故事或问题描述提炼成可复用的片段存入你的“记忆库”中让AI在未来项目中变得更聪明。技术的最终目的是赋能于人。pm-workflow-copilot-ide提供了一种全新的可能性让我们在追求开发效率的同时也能以更严谨、更轻松的方式对待产品思考本身。它或许还不完美但这条探索之路无疑指向了一个更流畅、更人性化的工具未来。