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

1. 项目概述：在IDE里嵌入一个产品经理副驾驶

如果你和我一样，既是开发者，又时不时要客串产品经理的角色，那你肯定对下面这个场景不陌生：脑子里蹦出一个绝妙的产品点子，兴奋地打开代码编辑器准备大干一场，结果在“先写代码”还是“先写文档”之间反复横跳。直接写代码吧，写着写着就发现功能越加越多，最初的简单想法变得面目全非；停下来写文档吧，又觉得打断了心流，而且那些传统的文档工具（Confluence、Notion）离你的开发环境太远，切换起来极其割裂。

pm-workflow-copilot-ide这个项目，就是为了解决这个痛点而生的。它不是一个独立的应用，而是一个专门为Cursor和Cline这类AI驱动的现代IDE设计的“规则包”。它的核心思想是：将一套轻量级、强引导的产品管理流程，直接嵌入到你每天都在用的编辑器聊天框里。让你在跟AI助手讨论代码的同时，就能被它引导着，一步步把一个模糊的想法，结构化地梳理成清晰的产品文档，比如产品章程、机会简报、MVP范围文档和PRD。

简单来说，它让你的AI编程助手，同时兼任你的产品管理副驾驶。你不用离开编码环境，就能完成从想法探索到需求定义的全过程，而且所有产出的文档（Markdown格式）就放在你的项目代码旁边，实现真正的“文档即代码”。

2. 核心设计理念与工作原理解析

2.1 为什么是“IDE内嵌式”工作流？

传统的产品管理工具和开发环境是分离的。这种分离导致了几个问题：

1. 上下文切换成本高：开发者需要从IDE跳到浏览器，打开另一个工具，心智模式完全被打断。
2. 文档与代码脱节：产品文档更新了，但代码可能没同步；功能实现了，文档却忘了补。两者版本不同步是常态。
3. 流程僵化，阻碍创新：重型流程工具为了满足大团队的复杂协作，往往设计得极其繁琐，对于小团队或独立开发者来说，光是填完那些表单就足以扼杀创作热情。

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 环境准备与前置依赖

在开始之前，你需要确保本地环境满足以下条件：

1. Python 3.8+：Rulebook-AI的CLI工具基于Python。打开终端，输入python3 --version检查。
2. Git：用于克隆仓库。
3. 一个AI驱动的IDE：Cursor(推荐) 或Cline。确保你已经安装并能正常使用其AI聊天功能。
4. 包管理工具 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-copilot

rulebook-ai packs add命令会读取包内的manifest.yaml文件，注册这个包。project sync命令则是将这个包的规则和记忆文件，链接或复制到你的IDE助手能读取的位置。

步骤3：在Cursor中验证与启动

1. 打开或重启你的Cursor。
2. 新建或打开一个任意项目（比如一个空的代码目录）。
3. 打开Cursor的AI聊天面板（通常是Cmd/Ctrl + K）。
4. 现在，尝试输入触发语。根据规则包的设定，你可以直接说：“我们来做一个天气应用吧。”或者“我想开始一个新的产品想法，关于一个帮助自由职业者追踪计费时间的工具。”

如果一切配置正确，你应该会立刻收到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。

1. 打开Cursor的AI聊天面板。
2. 在开始对话前，使用Cursor的“附加文件”或“提供上下文”功能（具体名称因版本而异），将memory_starters/docs/product_management_workflow_startup.md文件作为上下文附加给AI。
3. 同样地，你也可以附加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工作流集成

1. 为每个产品功能或史诗（Epic）创建一个新的Git分支，例如feat/spark-capture。
2. 在该分支上，使用副驾驶生成或更新相关的产品文档（如prd.md中关于“快速捕获”的详细需求）。
3. 在实现代码之前，先发起一个“文档PR”。邀请团队成员（开发者、设计师、其他PM）评审pm_project_docs/下的相关Markdown文件。
4. 评审通过后，合并文档分支。然后，基于这份已达成共识的文档，再开始编码。这样，代码PR的目标就非常明确。

模式二：在代码评审中关联文档在提交代码PR时，在描述中可以直接引用相关的产品文档：

## 功能描述 实现 `prd.md` 中定义的“浏览器插件一键捕获”功能（章节3.1）。 ## 变更内容 - 新增了 `background.js` 监听快捷键... - 修改了 `popup.html` 增加标签选择... **相关文档**：`pm_project_docs/knowledge_spark/prd.md`

评审者可以轻松点击链接查看原始需求，确保实现与设计初衷一致。

注意事项：虽然副驾驶能生成结构良好的文档初稿，但它不能替代深度的用户研究和战略思考。它更像一个“思考的记录员和框架的提醒者”。最终的产品决策、对用户痛点的深刻洞察，仍然需要你——产品的负责人——来把握和输入。切勿陷入“AI生成即真理”的陷阱，所有生成内容都必须经过你的严格审视和修正。

5. 常见问题、故障排查与进阶配置

在实际使用中，你可能会遇到一些问题。这里我整理了一份从入门到进阶的排错指南。

5.1 安装与基础使用问题

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 当前局限性

1. 强依赖IDE生态：目前深度绑定Cursor/Cline。如果你使用VS Code with Continue、JetBrains AI Assistant等其他AI编码工具，需要等待Rulebook-AI生态扩展支持，或自行移植规则。
2. AI的不确定性：生成文档的质量受限于底层大语言模型的能力和当前对话的上下文。有时它可能遗漏重点或产生需要你反复纠正的“车轱辘话”。
3. 复杂协作支持有限：它擅长引导个人或小团队梳理思路。但对于需要复杂权限管理、多人在线实时编辑、复杂工作流审批的大型企业级产品管理场景，它无法替代Jira、Productboard等专业工具。
4. 实验性状态：正如项目自身声明，它可能被重构、合并或API发生变化，不适合用于极其稳定、长期的核心生产流程。

6.2 生态展望与替代工具

该项目指向了一个未来趋势：AI原生的工作流工具将深度嵌入到我们的生产环境中，成为无形的“副驾驶”。Rulebook-AI的愿景正是管理无数个这样的“技能包”。

如果你喜欢这个理念，但需要更成熟或不同形态的工具，可以考虑：

• Claude for Desktop / ChatGPT with Advanced Data Analysis：你可以手动上传一套产品管理框架提示词和模板，在聊天中类似地引导它们生成文档。缺点是需要手动管理上下文和文件。
• Windsurf / Bloop：这些是另一类AI优先的代码编辑器，它们通常有强大的代码库理解和操作能力，未来也可能发展出类似的内置工作流功能。
• 传统工具的AI插件：许多现有的产品管理工具（如Notion、Coda）正在积极集成AI功能，用于辅助生成用户故事、整理反馈等，但它们可能不具备这种从零开始的、对话式的全流程引导能力。

6.3 我的使用体会与建议

经过一段时间的深度使用，我个人最大的体会是：这个工具最大的价值不在于“自动化生成文档”，而在于“结构化思考过程”。

在以前，当我有一个新想法时，思维是发散的，很容易跳过关键问题直接陷入细节。而这个副驾驶，就像一个耐心的教练，每次对话都强制我按顺序回答：“用户是谁？”“痛点是什么？”“怎么做才算成功？”。这个过程本身，比最后产出的那几份Markdown文件更有价值。

对于想要尝试的同行，我的建议是：

1. 从小处着手：不要第一个项目就用于你最重要的核心产品。找一个业余小项目或一个功能点子来试水，熟悉它的节奏和局限。
2. 把它当思考伙伴，而非秘书：主动向它提问，挑战它的建议，而不仅仅是被动接受输出。例如，当它生成MVP范围后，你可以问：“你基于什么逻辑排除了‘社交分享’功能？如果加入，对核心价值主张是增强还是稀释？”
3. 定制化你的流程：花点时间根据你团队的实际工作流，修改规则文件。让它真正为你服务，而不是你去适应它。比如，加入你们特有的“合规性检查清单”或“安全隐私评估”环节。
4. 管理好你的数字资产：定期整理pm_project_docs里的文件。将已完结项目的文档归档，将反复验证有效的用户故事或问题描述，提炼成可复用的片段，存入你的“记忆库”中，让AI在未来项目中变得更聪明。

技术的最终目的是赋能于人。pm-workflow-copilot-ide提供了一种全新的可能性，让我们在追求开发效率的同时，也能以更严谨、更轻松的方式对待产品思考本身。它或许还不完美，但这条探索之路，无疑指向了一个更流畅、更人性化的工具未来。