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个且包含目标用户和核心问题这两个必填字段并且用户确认了阶段总结后编排器就会将状态切换到定界阶段。为什么这很重要可调试性流程是透明的。如果对话卡住了你可以直接查看ConversationState对象中的字段立刻知道是哪个条件未满足而不是去猜测一个黑盒的“图”状态机出了什么问题。可靠性避免了由LLM来决定“下一步该做什么”可能带来的不可预测性和幻觉。阶段转移是稳定和可靠的。简洁性无需引入复杂框架的学习和维护成本。整个控制流一目了然。这体现了作者的一个强烈理念能用简单代码清晰表达的逻辑绝不引入不必要的抽象和框架。这对于项目的可维护性和贡献者友好度是极大的提升。2.3 专家混合模型路由成本与性能的平衡术Vibe-PM没有为所有任务使用同一个大模型而是根据任务特性精心选择了三个不同的开源模型通过LiteLLM进行统一调用。这套“专家混合”策略是其低成本、高性能的关键。任务类型选用模型理由与实操考量对话GPT-OSS 20B (Groq)对话需要较强的推理和上下文理解能力来保持连贯性并进行追问和辩论。20B参数模型在Groq的LPU上推理速度极快成本极低且思维链能力足以胜任此类交互任务。规格生成Llama 3.3 70B生成最终的长篇、结构化Markdown文档需要最强的语言生成和指令遵循能力。70B模型在这方面表现最佳。由于每个会话只调用一次虽然单次成本较高但摊薄到整个对话中仍可接受。提取与分类Llama 3.1 8B从对话历史中提取结构化信息如填充DiscoverySummary、对用户意图进行分类确认/修订、同意/反驳/提问这类任务对推理深度要求不高但要求快速、准确。8B模型在速度和成本上具有绝对优势且完全够用。实操心得这种分层模型策略是构建可持续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.txtrequirements.txt文件定义了所有依赖核心包括chainlitWeb 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中。让我们拆解它的循环初始化智能体加载一个高度结构化的“系统提示词”在prompts/discovery.py中。这个提示词定义了产品经理的“人设”、访谈的八个领域以及最重要的行为约束禁止生成列表、表格或规格必须一次只问一个问题必须对模糊答案进行追问。对话轮次每轮用户回复后智能体做两件事意图分类调用小模型Llama 3.1 8B判断用户是想“确认”当前信息还是“修订”之前的内容。这决定了后续处理逻辑。信息提取同样调用小模型尝试从最新的对话历史中提取信息并填充到一个名为DiscoverySummary的Pydantic模型中。这个模型严格定义了八个字段的数据结构。完整性检查在tools/completeness.py中有一个简单的评分函数。它会检查DiscoverySummary模型中哪些字段非空。当非空字段数达到阈值默认为6且“目标用户”和“核心问题”这两个关键字段已填充时就认为发现阶段“基本完成”。生成总结与确认此时智能体会生成一个阶段总结并明确询问用户“以上总结是否准确我们可以进入下一阶段了吗”。只有得到用户的明确确认流程才会推进。踩坑记录在早期测试中我发现如果用户过早地给出非常结构化的答案例如直接列出功能列表智能体有时会“忘记”自己的约束开始顺着讨论功能细节。解决方案是在提示词中强化了“角色纪律”并确保在每次调用LLM时系统提示词都被完整地传递。这提醒我们对于对话式智能体维持其角色和行为的一致性需要在整个对话历史中反复强化上下文。3.3 定界阶段的核心RICE评分与辩论逻辑定界智能体agents/scoping.py是项目的“刀刃”它负责将天马行空的想法拉回现实的执行层面。竞品搜索它首先使用tools/web_search.py中的工具以产品核心概念为关键词进行DuckDuckGo搜索寻找类似产品。这为后续的RICE评分和功能裁剪提供了市场上下文。生成MVP提案智能体基于发现阶段的信息和竞品分析生成一个初步的、分阶段的MVP范围。这里强制应用了多条裁剪规则P0核心MVP必须聚焦于解决核心问题的单一用户流程。通常只包含最核心的3-5个功能。社交功能如评论、分享、关注永远推迟。分析仪表盘和管理后台在验证核心价值之前不予考虑。每个阶段都应是独立可交付的。RICE评分它为每个提议的功能计算RICE分数。RICE是一个优先级框架R (Reach)一段时间内受影响的用户数。I (Impact)对每个用户的影响程度通常用0.25 0.5 1 2 3倍量化。C (Confidence)对上述估计的信心百分比%。E (Effort)团队“人月”工作量。分数公式(Reach * Impact * Confidence) / Effort。分数越高优先级越高。 智能体会在提案中展示这个评分让裁剪决策有据可依。辩论循环如果用户对裁剪提出异议例如“我认为用户档案是必须的”智能体会进入一个评估流程分析用户论点的强度、对核心问题的影响程度、以及该功能是否真的“核心”。基于评估它可能坚持原方案并解释原因也可能妥协并将该功能加入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分评分发现深度访谈是否深入、有洞察力对话自然度对话流程是否流畅、像真人定界合理性MVP范围是否合理、裁剪是否果断规格文档质量最终文档是否清晰、结构化、可操作辩论质量如适用反驳是否合理、有说服力评估结果会生成一份带时间戳的报告保存在eval/reports/目录下并更新根目录的results.md文件方便对比历次改进的效果。经验分享在构建自己的AI应用时这套评估思路极具参考价值。从确定性的代码断言开始确保核心逻辑正确再用模拟用户进行集成测试最后用更强大的模型进行主观质量评分。这比单纯说“感觉不错”要可靠得多。5. 项目复现与深度定制指南Vibe-PM的代码结构清晰非常适合作为学习模板或进行二次开发。以下是一些关键的定制点和扩展思路。5.1 代码结构导航与核心文件解读项目的模块化程度很高每个文件职责单一app.pyChainlit应用的入口。管理用户会话、消息路由和最终的规格文档下载。如果你想换掉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是一个优秀的起点你可以基于它进行多种扩展集成更多数据源定界阶段的竞品搜索目前仅使用DuckDuckGo。你可以集成更专业的数据库如Crunchbase公司信息、SimilarWeb流量数据、甚至学术论文库让市场分析更扎实。细化产品方法论当前使用的是通用的RICE和MVP框架。你可以修改提示词融入你所在公司或行业特定的产品开发框架如Google的HEART框架、JTBDJobs to be Done理论等。输出更多格式除了Markdown规格可以扩展spec_writer.py使其能生成用户故事地图、线框图描述供AI文生图工具使用、甚至初步的API接口定义。增加持续学习目前每次对话都是独立的。可以设计一个机制将每次对话的发现总结和最终规格存储到向量数据库中。当新用户提出类似想法时系统可以先进行相似度搜索提供历史案例作为参考让对话起点更高。连接下游工具将最终生成的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 pydantic2.5.3。最坏的情况是可以注释掉requirements.txt中导致冲突的包然后手动安装一个兼容的版本。问题在中国大陆地区访问Groq API可能不稳定或缓慢。解决这是网络环境问题。考虑以下方案切换到其他也被LiteLLM支持的、访问更稳定的海外API提供商如Together AI或OpenAI。如果必须使用Groq确保你的网络连接可靠。运行评估脚本时可能会因为超时导致失败可以适当在config.py或LiteLLM的初始化中增加超时设置。6.2 模型调用与API相关问题问题对话过程中LLM返回了无关内容或格式错误导致JSON解析失败。解决这是LLM应用中的常见问题。Vibe-PM在models/llm.py的_llm_conversation方法中已经实现了重试逻辑。如果解析失败它会自动重试最多3次。如果频繁失败可能需要检查对应智能体的提示词是否清晰是否严格限定了输出格式。尝试换用更稳定的模型例如将对话模型从20B升级到70B虽然成本更高。在提取结构化数据时可以尝试使用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都提供了极其宝贵的实践参考。