开源AI产品经理Vibe-PM：三阶段对话生成PRD，重塑产品工作流

1. 项目概述：用AI对话重塑产品经理工作流

如果你是一名创业者或者产品经理，面对一个模糊的产品创意，从想法到一份能让开发者直接开工的详细产品规格说明书（PRD），这个过程通常需要数周时间。你需要进行用户访谈、竞品分析、功能优先级排序、撰写文档……而现在，有一个开源项目试图用一次对话来替代这一切。Vibe-PM，一个纯粹由开源模型驱动的AI产品经理智能体，正是为此而生。它通过一个精心设计的三阶段对话管道，引导你从“我有一个想法”开始，最终产出一份分阶段、排好优先级、甚至包含了RICE评分和竞品分析的Markdown规格文档。

这个项目的核心价值在于其“务实”和“去平台化”。它不依赖任何闭源的GPT-4或Claude模型，完全基于Llama等开源模型构建，这意味着没有供应商锁定风险，成本极低（单次对话成本仅几分钱）。更关键的是，它的架构设计充满了工程智慧：没有使用流行的LangChain或LangGraph框架，而是用大约80行清晰的if/else逻辑作为流程编排器；采用了“专家混合”模型路由策略，为对话、写作、分类等不同任务匹配合适的模型。这不仅仅是一个工具演示，更像是一位资深技术产品经理分享的一套可复现、可调试、可评估的AI智能体系统设计蓝图。接下来，我将带你深入拆解这套系统的设计哲学、实现细节以及我在复现和实验过程中的实操心得。

2. 核心架构与设计哲学拆解

Vibe-PM的成功并非源于使用了多么前沿的模型，而在于其清晰、务实且高度解耦的架构设计。它摒弃了当下AI应用开发中常见的“一个超级提示词解决所有问题”或“过度依赖重型框架”的路径，选择了一条更符合软件工程原则的道路。

2.1 分而治之的智能体设计：三个专家，而非一个通才

项目最核心的设计决策是采用了三个独立的智能体，分别负责发现、定界和撰写三个阶段。这听起来简单，但背后是对LLM能力局限性的深刻理解。

• 发现智能体：它的唯一任务是进行高质量的产品探索访谈。其提示词被设计成模仿顶尖产品经理的访谈风格，覆盖目标用户、核心问题、现有替代方案、时机、功能愿望清单、成功指标、收入模型和约束条件这八个维度。关键在于，它的提示词里明确禁止生成表格或PRD，强制其专注于“提问-聆听-追问”的对话循环。这避免了LLM常见的“急于求成”的幻觉，即跳过深度探索直接给出解决方案。
• 定界智能体：当发现阶段收集到足够信息后，此智能体接管。它的核心工作是“做减法”。它会自动进行DuckDuckGo搜索寻找可比产品，然后运用RICE框架（Reach影响范围， Impact影响强度， Confidence信心度， Effort投入精力）对功能进行评分和优先级排序。其设计目标是提出一个“一名开发者能在2-4周内完成的核心MVP”。它被预设了强硬的裁剪原则：社交功能、分析仪表盘、管理后台永远不属于P0阶段。如果用户（模拟的创始人）对裁剪提出异议，它还会进入一个“辩论”循环，基于论点强度、影响力和核心性进行评估，最多三轮后要么坚持立场，要么妥协并标记风险。
• 规格撰写智能体：前两个智能体的工作成果是结构化的数据（Pydantic模型）。撰写智能体只在最后被调用一次，其任务是将这些数据填充到一个详尽的Markdown模板中，生成最终的分阶段实施规格。它使用能力最强的70B模型，确保长文档的结构清晰、内容准确、无幻觉。

设计启示：这种设计模式将复杂的任务分解为离散的、可评估的子任务，每个子任务使用针对性的提示词和合适的模型。这不仅提高了每一步的输出质量，还使得整个系统的调试和优化变得异常简单——你可以单独测试发现智能体的访谈能力，而无需运行整个流程。

2.2 确定性的代码编排器：if/else的优雅

与许多使用LLM或LangGraph来管理状态和流程转移的智能体系统不同，Vibe-PM的流程编排器（orchestrator.py）是用纯Python的if/else逻辑实现的，大约只有80行代码。流程转移完全基于确定性的规则：例如，当发现智能体报告其“完整性分数”达到阈值（8个字段中已填充6个，且包含目标用户和核心问题这两个必填字段），并且用户确认了阶段总结后，编排器就会将状态切换到定界阶段。

为什么这很重要？

1. 可调试性：流程是透明的。如果对话卡住了，你可以直接查看ConversationState对象中的字段，立刻知道是哪个条件未满足，而不是去猜测一个黑盒的“图”状态机出了什么问题。
2. 可靠性：避免了由LLM来决定“下一步该做什么”可能带来的不可预测性和幻觉。阶段转移是稳定和可靠的。
3. 简洁性：无需引入复杂框架的学习和维护成本。整个控制流一目了然。

这体现了作者的一个强烈理念：能用简单代码清晰表达的逻辑，绝不引入不必要的抽象和框架。这对于项目的可维护性和贡献者友好度是极大的提升。

2.3 专家混合模型路由：成本与性能的平衡术

Vibe-PM没有为所有任务使用同一个大模型，而是根据任务特性精心选择了三个不同的开源模型，通过LiteLLM进行统一调用。这套“专家混合”策略是其低成本、高性能的关键。

实操心得：这种分层模型策略是构建可持续AI应用的关键。在复现时，你可以通过修改config.py中的一行配置，轻松地将提供商从Groq切换到Together AI或OpenAI等任何LiteLLM支持的平台。这真正实现了“零供应商锁定”。我实测过，使用Groq的免费额度就足以进行多次完整的对话测试，这对于个人开发者和小团队验证想法非常友好。

3. 从零到一：环境搭建与核心模块实操

要真正理解一个系统，最好的方式就是把它跑起来。下面我将带你一步步搭建Vibe-PM的环境，并深入几个核心模块，看看它们是如何具体工作的。

3.1 本地开发环境配置详解

首先，你需要一个Python环境。项目要求Python 3.9+，我推荐使用3.10或3.11以获得最佳的包兼容性。

# 1. 克隆仓库 git clone https://github.com/vinayak1998/Vibe-PM.git cd Vibe-PM # 2. 创建并激活虚拟环境（强烈推荐，避免包冲突） python -m venv .venv # macOS/Linux: source .venv/bin/activate # Windows: # .venv\Scripts\activate # 3. 安装依赖 pip install -r requirements.txt

requirements.txt文件定义了所有依赖，核心包括chainlit（Web UI）、litellm（模型抽象层）、pydantic（数据验证）、duckduckgo-search（网络搜索）等。安装过程通常很顺利。

接下来是获取API密钥。项目默认使用Groq，你需要去Groq控制台免费注册并创建一个API Key。

# 4. 配置环境变量 cp .env.example .env # 使用你喜欢的编辑器打开 .env 文件，例如： # nano .env # 将内容修改为：GROQ_API_KEY=你的实际密钥

注意：.env文件包含敏感信息，务必将其添加到你的.gitignore文件中，切勿提交到版本库。

3.2 深入智能体内部：发现阶段的运作机制

启动应用后，当你输入一个模糊的产品想法时，发现智能体就开始工作了。它的核心在agents/discovery.py中。让我们拆解它的循环：

1. 初始化：智能体加载一个高度结构化的“系统提示词”（在prompts/discovery.py中）。这个提示词定义了产品经理的“人设”、访谈的八个领域，以及最重要的行为约束：禁止生成列表、表格或规格，必须一次只问一个问题，必须对模糊答案进行追问。
2. 对话轮次：每轮用户回复后，智能体做两件事：
   • 意图分类：调用小模型（Llama 3.1 8B）判断用户是想“确认”当前信息还是“修订”之前的内容。这决定了后续处理逻辑。
   • 信息提取：同样调用小模型，尝试从最新的对话历史中提取信息，并填充到一个名为DiscoverySummary的Pydantic模型中。这个模型严格定义了八个字段的数据结构。
3. 完整性检查：在tools/completeness.py中，有一个简单的评分函数。它会检查DiscoverySummary模型中哪些字段非空。当非空字段数达到阈值（默认为6），且“目标用户”和“核心问题”这两个关键字段已填充时，就认为发现阶段“基本完成”。
4. 生成总结与确认：此时，智能体会生成一个阶段总结，并明确询问用户“以上总结是否准确？我们可以进入下一阶段了吗？”。只有得到用户的明确确认，流程才会推进。

踩坑记录：在早期测试中，我发现如果用户过早地给出非常结构化的答案（例如直接列出功能列表），智能体有时会“忘记”自己的约束，开始顺着讨论功能细节。解决方案是在提示词中强化了“角色纪律”，并确保在每次调用LLM时，系统提示词都被完整地传递。这提醒我们，对于对话式智能体，维持其角色和行为的一致性需要在整个对话历史中反复强化上下文。

3.3 定界阶段的核心：RICE评分与辩论逻辑

定界智能体（agents/scoping.py）是项目的“刀刃”，它负责将天马行空的想法拉回现实的执行层面。

1. 竞品搜索：它首先使用tools/web_search.py中的工具，以产品核心概念为关键词进行DuckDuckGo搜索，寻找类似产品。这为后续的RICE评分和功能裁剪提供了市场上下文。
2. 生成MVP提案：智能体基于发现阶段的信息和竞品分析，生成一个初步的、分阶段的MVP范围。这里强制应用了多条裁剪规则：
   • P0（核心MVP）：必须聚焦于解决核心问题的单一用户流程。通常只包含最核心的3-5个功能。
   • 社交功能（如评论、分享、关注）永远推迟。
   • 分析仪表盘和管理后台在验证核心价值之前不予考虑。
   • 每个阶段都应是独立可交付的。
3. RICE评分：它为每个提议的功能计算RICE分数。RICE是一个优先级框架：
   • R (Reach)：一段时间内受影响的用户数。
   • I (Impact)：对每个用户的影响程度（通常用0.25， 0.5， 1， 2， 3倍量化）。
   • C (Confidence)：对上述估计的信心百分比（%）。
   • E (Effort)：团队“人月”工作量。
   • 分数公式：(Reach * Impact * Confidence) / Effort。分数越高，优先级越高。 智能体会在提案中展示这个评分，让裁剪决策有据可依。
4. 辩论循环：如果用户对裁剪提出异议（例如，“我认为用户档案是必须的”），智能体会进入一个评估流程：
   • 分析用户论点的强度、对核心问题的影响程度、以及该功能是否真的“核心”。
   • 基于评估，它可能坚持原方案（并解释原因），也可能妥协并将该功能加入MVP，但同时会标记为“范围蔓延风险”。
   • 这个循环最多进行三轮，之后智能体会“优雅让步”，以避免陷入无休止的争论。

实操要点：定界阶段的提示词工程非常精妙。它不仅仅要求模型输出一个列表，而是要求其扮演一个“经验丰富、敢于说不的产品负责人”角色。在复现或调整时，你可以修改prompts/scoping.py中的裁剪规则和辩论逻辑，以适应你所在团队或行业的产品开发文化。

4. 评估框架：如何衡量一个AI产品经理的“工作质量”？

一个无法评估的AI系统是不可信的。Vibe-PM设计了一个三层评估框架，这可能是整个项目中最具借鉴价值的部分之一。它没有依赖主观感受，而是构建了一套可重复、可量化的测试体系。

4.1 第一层：模拟用户测试

在eval/simulated_user.py中，项目定义了五个不同的模拟创始人角色，用于进行端到端的自动化测试：

• 模糊型创始人：回答简短，需要不断追问。
• 过度规划型创始人：一开始就列出15个以上的功能，测试系统的裁剪能力。
• 清晰思考型创始人：想法明确，合作顺畅，用于测试流程效率。
• 争论型创始人：对任何功能裁剪都强烈反对，测试辩论逻辑。
• 善变型创始人：在对话中途改变核心想法，测试系统的鲁棒性和上下文管理能力。

这些模拟用户本身也是由LLM驱动的，它们根据预设的“策略”来生成回复。这使得大规模、自动化的回归测试成为可能。

4.2 第二层：确定性断言

在eval/assertions.py中，定义了27条确定性的通过/失败检查。这些检查不依赖LLM判断，而是基于对话和输出的结构化数据。例如：

• “发现阶段必须询问‘目标用户’和‘核心问题’。”
• “定界阶段输出的MVP必须包含RICE评分。”
• “最终规格文档必须包含‘可比产品’部分。”
• “如果用户是‘争论型’，系统必须进行至少一轮辩论。”

运行python eval/runner.py（不加--judge参数）就会执行这27条断言。这是一种快速、免费、可靠的冒烟测试，能确保系统的基本功能正常。

4.3 第三层：LLM即评委

这是更深入、更主观的质量评估。运行python eval/runner.py --judge会额外启动一个“评委”LLM（使用70B模型），根据五个维度对每次对话的输出进行1-5分评分：

1. 发现深度：访谈是否深入、有洞察力？
2. 对话自然度：对话流程是否流畅、像真人？
3. 定界合理性：MVP范围是否合理、裁剪是否果断？
4. 规格文档质量：最终文档是否清晰、结构化、可操作？
5. 辩论质量（如适用）：反驳是否合理、有说服力？

评估结果会生成一份带时间戳的报告，保存在eval/reports/目录下，并更新根目录的results.md文件，方便对比历次改进的效果。

经验分享：在构建自己的AI应用时，这套评估思路极具参考价值。从确定性的代码断言开始，确保核心逻辑正确；再用模拟用户进行集成测试；最后用更强大的模型进行主观质量评分。这比单纯说“感觉不错”要可靠得多。

5. 项目复现与深度定制指南

Vibe-PM的代码结构清晰，非常适合作为学习模板或进行二次开发。以下是一些关键的定制点和扩展思路。

5.1 代码结构导航与核心文件解读

项目的模块化程度很高，每个文件职责单一：

• app.py：Chainlit应用的入口。管理用户会话、消息路由和最终的规格文档下载。如果你想换掉Chainlit（例如用Gradio或自定义前端），主要修改这里。
• orchestrator.py：流程控制中枢。理解这里的ConversationState状态机和阶段转移条件，是定制流程的关键。
• config.py：所有配置的单一入口。模型名称、API端点、完整性阈值、辩论轮次上限等都在这。调整系统行为首先看这里。
• agents/：三个智能体的具体实现。如果你想改变某个智能体的行为（例如让发现智能体多问几个问题），就修改对应的文件。
• prompts/：所有系统提示词。这是系统的“大脑”。定制产品方法论、访谈风格、裁剪规则，主要在这里进行。
• tools/：各种工具函数。例如，如果你想换用Google搜索或SerpAPI，就修改web_search.py；如果想调整信息提取的格式，就修改extraction.py。
• models/schemas.py：定义了所有Pydantic数据模型。这是智能体之间传递数据的“合同”。增加或修改字段需要同步更新相关的提示词和工具函数。

5.2 如何替换模型提供商或调整模型策略

项目通过LiteLLM实现了模型无关。假设你想从Groq切换到OpenAI的API，只需修改config.py：

# 原配置（Groq） LLM_PROVIDER = "groq" MODEL_FOR_CONVERSATION = "gpt-oss-20b-chat" MODEL_FOR_SPEC = "llama-3.3-70b-versatile" MODEL_FOR_EXTRACTION = "llama-3.1-8b-instant" # 修改为OpenAI配置 LLM_PROVIDER = "openai" # LiteLLM识别的提供商名称 MODEL_FOR_CONVERSATION = "gpt-3.5-turbo" # 或 "gpt-4" MODEL_FOR_SPEC = "gpt-4" MODEL_FOR_EXTRACTION = "gpt-3.5-turbo"

同时，确保你的.env文件中的API密钥变量名从GROQ_API_KEY改为OPENAI_API_KEY。LiteLLM会自动处理剩下的兼容性问题。

如果你想尝试不同的模型组合，比如用Claude进行对话，用GPT-4写文档，也只需在config.py中相应调整模型名称字符串即可。LiteLLM支持混用不同提供商的模型。

5.3 扩展功能与个性化定制思路

Vibe-PM是一个优秀的起点，你可以基于它进行多种扩展：

1. 集成更多数据源：定界阶段的竞品搜索目前仅使用DuckDuckGo。你可以集成更专业的数据库，如Crunchbase（公司信息）、SimilarWeb（流量数据）、甚至学术论文库，让市场分析更扎实。
2. 细化产品方法论：当前使用的是通用的RICE和MVP框架。你可以修改提示词，融入你所在公司或行业特定的产品开发框架，如Google的HEART框架、JTBD（Jobs to be Done）理论等。
3. 输出更多格式：除了Markdown规格，可以扩展spec_writer.py，使其能生成用户故事地图、线框图描述（供AI文生图工具使用）、甚至初步的API接口定义。
4. 增加持续学习：目前每次对话都是独立的。可以设计一个机制，将每次对话的发现总结和最终规格存储到向量数据库中。当新用户提出类似想法时，系统可以先进行相似度搜索，提供历史案例作为参考，让对话起点更高。
5. 连接下游工具：将最终生成的Markdown规格与项目管理工具（如Jira、Linear）或代码生成工具（如Claude Code、Cursor）打通，实现从想法到任务拆解甚至代码草稿的半自动化流水线。

6. 常见问题与实战排错记录

在部署和测试Vibe-PM的过程中，你可能会遇到一些典型问题。以下是我遇到的一些情况及其解决方法。

6.1 环境与依赖问题

• 问题：运行chainlit run app.py时，提示端口被占用。
  • 解决：Chainlit默认使用8000端口。你可以通过指定端口来运行：chainlit run app.py --port 8001。或者，检查并关闭占用8000端口的其他进程。
• 问题：安装依赖时，某些包（如pydantic）版本冲突。
  • 解决：项目锁定了主要依赖的版本以确保兼容性。首先确保你使用了全新的虚拟环境。如果仍有冲突，可以尝试单独安装有冲突的包到指定版本，例如：pip install pydantic==2.5.3。最坏的情况是，可以注释掉requirements.txt中导致冲突的包，然后手动安装一个兼容的版本。
• 问题：在中国大陆地区，访问Groq API可能不稳定或缓慢。
  • 解决：这是网络环境问题。考虑以下方案：
    1. 切换到其他也被LiteLLM支持的、访问更稳定的海外API提供商，如Together AI或OpenAI。
    2. 如果必须使用Groq，确保你的网络连接可靠。运行评估脚本时，可能会因为超时导致失败，可以适当在config.py或LiteLLM的初始化中增加超时设置。

6.2 模型调用与API相关问题

• 问题：对话过程中，LLM返回了无关内容或格式错误，导致JSON解析失败。
  • 解决：这是LLM应用中的常见问题。Vibe-PM在models/llm.py的_llm_conversation方法中已经实现了重试逻辑。如果解析失败，它会自动重试最多3次。如果频繁失败，可能需要：
    1. 检查对应智能体的提示词是否清晰，是否严格限定了输出格式。
    2. 尝试换用更稳定的模型（例如，将对话模型从20B升级到70B，虽然成本更高）。
    3. 在提取结构化数据时，可以尝试使用LLM的“JSON模式”或“函数调用”功能（如果提供商支持），这比依赖文本解析更可靠。
• 问题：DuckDuckGo搜索没有返回结果，或返回了无关结果。
  • 解决：修改tools/web_search.py中的搜索关键词生成逻辑。目前它可能只是简单使用了产品名称。你可以尝试让其生成更具体、带修饰词的搜索查询（例如，“最佳 [产品类型] 软件 2024”）。也可以考虑增加重试次数，或引入结果过滤逻辑（例如，只保留包含特定关键词的链接）。

6.3 流程与逻辑问题

• 问题：发现阶段似乎永远无法完成，一直在问问题。
  • 排查：首先检查config.py中的DISCOVERY_COMPLETENESS_THRESHOLD（默认6）和DISCOVERY_MANDATORY_FIELDS（默认[“target_user”, “core_problem”]）。然后，在对话界面中，尝试给出更明确、更完整的答案。你也可以查看后台日志，观察DiscoverySummary模型的填充进度。有时用户过于模糊的回答会导致提取失败，字段始终无法被填充。
• 问题：定界阶段提出的MVP范围感觉不合理，裁剪过于激进或保守。
  • 调整：这是产品策略问题，而非技术问题。你需要修改prompts/scoping.py中定界智能体的系统提示词。仔细阅读其中关于“裁剪规则”和“MVP定义”的部分，根据你的团队速度（是2-4周还是更长？）和产品领域进行调整。例如，对于某些工具类产品，一个简单的管理后台可能确实是P0核心。
• 问题：最终生成的Markdown规格文档格式混乱或缺少部分。
  • 排查：检查tools/templates.py中的Markdown模板。所有占位符（如{phase1_features}）都必须与spec_writer.py中生成的数据结构匹配。确保SpecWriter智能体正确接收并处理了来自前两个阶段的所有数据。

6.4 评估脚本运行问题

• 问题：运行python eval/runner.py --judge时，评估过程非常慢或消耗大量API额度。
  • 注意：--judge标志会使用70B大模型对每次对话进行评分，成本较高且速度慢。建议在平时开发时，只运行python eval/runner.py进行快速的确定性断言测试。仅在需要全面评估模型质量改进时，才使用--judge选项。
• 问题：模拟用户的回答看起来不自然或脱离场景。
  • 调整：模拟用户的行为由eval/scenarios/目录下的YAML文件定义。你可以修改这些文件中的“政策”描述，来改变模拟用户的言行风格。例如，让“争论型创始人”的论点更具逻辑性，或者让“模糊型创始人”的答案更简短。

这个项目给我最大的启发是，构建有用的AI应用，精妙的设计和工程实现往往比追求最庞大的模型更重要。它展示了一条路径：用清晰的模块化架构、确定性的流程控制、针对性的模型选择以及严谨的评估体系，可以打造出稳定、可靠且成本可控的AI智能体。无论是想直接使用它来梳理产品思路，还是将其作为学习AI智能体设计的范本，Vibe-PM都提供了极其宝贵的实践参考。