做了这么多年产品我越来越觉得一个扎心的事实AI时代真正拉开产品经理差距的不是谁更会写PRD而是谁先搭好了自己的 Agent 工作台。现在几乎每个产品经理都在用AI但大部分人的用法是这样的打开一个聊天窗口输入“帮我写一份XX产品的PRD”AI噼里啪啦输出几千字复制粘贴到文档里然后……就没有然后了。下一次写PRD又从零开始问一遍。需求变了重新问一遍。评审发现一堆问题再重新问一遍。这不是AI不行而是我们把它用成了“一个更聪明的搜索引擎”。产品经理真正需要的不是聊天气泡而是一个能承接完整工作流的 Agent 工作台——需求进来经过分析、画像、竞品、PRD、评审模拟一系列节点产出被组织好的、可用的、可追踪的结果。这篇文章我就用实际经验聊一聊AI怎么做产品设计以及一个真正可落地的 Agent 工作台该怎么搭、怎么用、会踩哪些坑。1. 产品经理用AI做产品设计的真实困境从“问一句答一句”说起不少产品经理找我聊AI落地开场往往是那句“我试过让AI写PRD写完没法用”。我问怎么写的回答基本是同一个模式把需求背景丢给聊天窗口让它直接输出PRD。结果通常是两种要么是结构化有余、真实信息不足——格式挺漂亮但里面全是AI脑补的需求要么是前后逻辑对不上目标、客群、功能列表之间没有因果关系。1.1 四个典型现象几乎每个团队都能对上号第一个现象是描述与判断脱节。聊天窗口只对“当前这句话”负责不会自己去翻你以前写过的PRD不会去查用户反馈原文更不会核对竞品信息。你让它写目标用户它就写“年轻白领”你让它列竞品它就给你列几个“可能的”产品。敢编是真敢编但产品经理要的不是创意写作而是有依据的判断。第二个现象是流程无法沉淀。写PRD只是产品设计的一个节点。前面要梳理需求来源、用户反馈、历史版本后面要准备评审、拆解排期。单点AI只能帮你写中间那一段前后环节仍然靠人肉搬运。搬一次两次还能忍项目一多信息就大量丢失。第三个现象是结果不可追踪。聊天窗口里生成的内容不会自动进知识库也不会标明依据来源。评审时别人问“这句话的依据是什么”你没法回答。产品设计是一个需要反复对齐、所有决策都要留痕的工作聊天窗口天然满足不了这个要求。第四个现象是上下文一多就不稳定。产品设计涉及的信息量很大需求背景、用户反馈、历史版本、竞品资料、战略目标一份长PRD的上下文字数轻松破万。一条聊天窗口根本塞不下强行把所有资料贴进去模型就开始糊涂输出质量直线下降。1.2 问题根源聊天窗口和产品设计是两种不匹配的形态很多人把这些问题归因于“模型不够聪明”但模型能力其实早就不差。问题的根源在于交互形态错位聊天窗口是“问答式”的产品设计是“工作流式”的。问答式的特点是“你问什么我答什么”答完就结束没有状态、没有记忆、没有环节流转。而产品设计本质上是一个多环节、多角色、多轮迭代的流程先收集需求再分析用户然后对比竞品接着撰写方案最后还要模拟评审、根据反馈修订。环环相扣每个环节的输出都会影响下一个环节的质量。这两种形态凑到一起产品经理就只能在“让AI单点帮忙”和“自己从头包办”之间反复横跳。真正需要的其实是一个把“问答”升级为“流水线生产”的中间层——这就是 Agent 工作台出现的理由。2. 为什么偏偏是Agent工作台它怎么把“写PRD”变成“跑流程”2.1 先给Agent工作台下个定义“Agent工作台”这个词最近被说烂了但大多数人对它的理解还停留在“能调用工具的AI”。我理解的Agent 工作台是把多个AI Agent、知识库、工作流编排和人工审核节点整合在一起的生产环境。它跟聊天窗口最大的区别在于不只有一个“大脑”而是把一个复杂任务拆分给多个各司其职的Agent去跑同时让数据在Agent之间有序流动。举个例子。同样做一个新版本的产品方案聊天窗口模式你输入需求AI直接吐一堆内容。生成质量完全取决于你一次性把背景资料描述得有多全。漏一句它就给你脑补一大段。Agent工作台模式你把原始需求、用户反馈文档、历史版本链接、竞品信息扔进工作台。需求解析Agent先整理需求清单画像Agent基于用户反馈生成用户画像竞品Agent输出对比矩阵PRD Agent基于前面所有输出生成文档结构最后评审模拟Agent挑刺把潜在风险列出来。每个环节都有独立的提示词、独立的知识库引用、独立的输出格式产品经理只在关键节点做确认和修改。我一开始也觉得这只是概念包装但实际用下来两种模式的差距是代际性的。聊天窗口像请了个什么都会但不记得前因后果的实习生Agent工作台像把一个产品设计流程拆成了五个各管一段、交接清晰的“虚拟员工”。2.2 产品设计流程中哪些环节适合交给Agent不是所有环节都要自动化。我梳理下来产品设计流程里有七个环节非常适合 Agent 化因为它们都有三个共同特征规则相对明确、需要大量背景资料阅读、输出格式相对固定。环节核心工作适合Agent化的原因需求收集与清洗从群聊、工单、访谈记录中提取需求原始素材量大且杂乱适合机器先粗筛用户研究与画像整理访谈记录识别痛点和场景需要通读全文再归纳AI擅长提取竞品分析功能对比、逻辑拆解信息拼凑和结构化输出是强项PRD编写背景、目标、功能需求、边界、埋点格式高度固定且有前置输入流程图/结构图描述从PRD生成页面结构和流程描述规则清晰输出可复用评审模拟找漏洞预判评审问题需要多角色视角Agent可以扮演排期拆解与验收标准拆任务写验收清单基于需求列表做规则映射这里要强调一个观点“适合Agent化”不等于“完全不用人管”。产品设计里最值钱的是商业判断和用户理解这部分一定要留在人手里。Agent负责的是“信息处理和初稿生成”人负责的是“方向把控和关键决策”。这样分工效率和质量才能同时保住。3. 真正实用的四类Agent节点从需求清洗到评审模拟3.1 需求解析节点先把“垃圾输入”洗成“结构化需求”需求来源特别杂微信群里随口一提、客服工单、用户访谈录音转写、问卷开放题。这些东西直接喂给大模型输出质量会非常差。我的工作台里第一个节点就是“需求解析Agent”它负责把原始素材读一遍输出一份规范的需求清单包含来源、原始表述、需求意图、影响用户、预期价值、优先级建议。这个节点的提示词里我会强制两个约束一是不要合并相似需求因为AI特别喜欢把两件事当成一件事二是保留原始表述每条需求后面必须带来源摘录方便后续追溯。这一步做好了后面的节点才能吃到干净数据。我用的是国内大模型API效果已经足够不需要追求超大参数模型来处理这种分类任务。具体做法是把原始素材按文档形式传进去要求Agent逐条输出。输出用JSON结构方便下一个节点直接读取。JSON长什么样不关键关键是字段固定比如source、raw_text、intent、user_segment、suggestion。字段固定了下游节点才不会“漏看信息”。3.2 用户画像与场景还原节点不允许没有依据的结论画像Agent的输入是用户反馈记录和访谈文本输出是一组用户画像和典型使用场景。这里最容易翻车的地方是“凭空捏造用户”——AI会基于自己的刻板印象生成一个看起来无懈可击的画像实际上跟你的真实用户毫无关系。我的解法是在提示词里加一条铁律每条画像结论必须附带至少一条原文依据。比如“用户对导出功能不满”这个结论后面必须跟着一条用户原话或工单原文。这条约束一加输出质量立刻不一样。模型会老老实实去语料里找依据找不到的结论它就不敢写或者明确标注“推测”。这个机制很像产品团队做用户访谈时的要求每个洞察都要有出处不能拍脑袋。3.3 PRD生成节点锁定边界比生成内容更重要PRD生成Agent是整个工作台里最核心的节点。它的输入是前面几个Agent的输出需求清单、用户画像、竞品对比输出是一份包含背景、目标、范围、用户故事、功能需求、边界条件、数据埋点、验收标准的完整PRD。写这个节点的提示词时我发现一个反直觉的经验约束比指令更重要。模型生成内容的能力已经过剩真正难的是让它“别乱写”。所以我在提示词里重点强调三件事不得新增输入中未出现的需求所有功能描述必须能追溯到需求清单必须明确“本期不做”的范围边界防止后续脑补所有用户故事必须关联到画像和场景没有场景支撑的故事直接删除。一个典型的PRD节点提示词模板是这样的# 角色 你是一名有8年经验的资深产品经理擅长写结构严谨、边界清晰的需求文档。 # 输入 以下是需求清单、用户画像和竞品分析结果全部来自前期分析不需要你重新推断。 输入数据 {结构化JSON} /输入数据 # 任务 基于输入生成一份PRD必须包含以下章节 1. 背景与目标 2. 产品范围含本期不做 3. 用户故事与使用场景 4. 功能需求清单带优先级 5. 边界条件与异常场景 6. 数据埋点需求 7. 验收标准 # 约束 1. 不得新增输入中未出现的需求 2. 每条功能需求必须标注来源编号 3. 必须包含至少三条“本期不做”的边界说明 4. 用户故事必须关联画像编号 5. 全文使用Markdown格式输出你会发现这个提示词里没有任何“请写得精彩一点”“请深入思考”之类的话。因为对生成式模型来说自由就是风险约束才是质量。3.4 评审模拟节点让AI扮演最挑剔的评审官我工作台里最有价值的一个节点其实是评审模拟Agent。产品经理每次评审最怕什么最怕被问到没想过的问题。以前这些盲区只能靠经验和运气现在可以让Agent先“自问自答”一轮。评审模拟Agent的输入是PRD全文输出是一份“评审提问清单”包含每个问题对应的文档章节、问题描述、可能的影响、建议的修改方向。它扮演的是一个刻意挑刺的评审官专门找需求的漏洞优先级依据是什么异常场景考虑了吗数据指标怎么衡量权限边界有没有定义老用户迁移方案是什么更关键的是这个环节可以“闭环”。我把评审模拟Agent的输出反馈给PRD Agent让它基于问题清单修订文档修订完再跑一轮评审模拟直到问题数降到阈值以下。这个多轮迭代在聊天窗口里几乎没法实现——因为每次都要手动搬运上下文而Agent工作台天然支持这种循环。4. 亲手搭一个Agent工作台我的选型、配置与人工卡点设计4.1 选型别一上来就自己写Agent框架很多产品经理跟我聊的时候第一句话是“要不要学LangChain”。我的建议很直接第一步别碰框架。市面上主流的工作台工具已经把这些东西封装成了可视化拖拉拽产品经理完全可以自己搭建。方案A开源低代码平台如Dify。适合想把数据留在内部的团队也可以私有化部署有工作流编排、知识库、日志追踪功能。方案B云厂商的Agent平台如阿里云百炼、火山引擎等。适合本来就深度使用云服务的团队集成方便运维成本低。方案C无代码的Agent搭建工具如Coze扣子等。上手最快适合个人或小团队快速验证产品经理可以完全自助搞定。方案D自己用LangChain/LangGraph写。适合公司要把它做成内部平台、多团队复用的场景。但这是最后一步不是第一步。我实际用的是先方案C/方案A快速搭Demo验证流程有价值之后再让工程团队用方案D做正式化。这样既避免了从一开始就陷进技术细节也不会在流程还没验证时浪费太多资源。4.2 把流程拆成可执行的节点第一次搭建时我犯过一个典型错误想直接做一个“PRD生成器”把所有的信息一股脑塞给一个Agent。做了两版后发现输出质量非常不稳。后来我才想明白真正提升质量的关键不是PRD生成提示词写得多么华丽而是前面有几个Agent先把信息处理好。我把工作流拆成了五个节点需求清洗Agent输入原始需求素材输出结构化需求清单用户画像Agent输入反馈语料输出画像和场景竞品拆解Agent输入竞品资料输出功能对比矩阵PRD生成Agent综合前三者输出生成PRD初稿评审模拟Agent对PRD提问输出问题清单。每个节点的输入输出我都定义了固定的JSON结构前一个节点生成的数据直接传给下一个节点。这样做的最大好处是每个Agent只需要关注自己这一段事不需要把整条链路的信息全都装进上下文。这大大降低了模型的“记忆压力”输出稳定性明显提升。4.3 知识库配置工作台的“记忆力”要从源头抓起知识库是Agent工作台区别于聊天窗口的重要部分。它是工作台的“长期记忆”决定了大模型能不能基于你团队的真实资料工作。我把三类资料放进了知识库历史PRD清洗过的、用户反馈原文脱敏处理、竞品公开信息。有两点必须提醒。第一历史PRD一定要清洗后再入库。我一开始直接导入了所有历史文档结果模型经常把旧版本已经废弃的功能当成当前功能在生成PRD时“复活”了一堆不该存在的需求。清洗的核心是去掉过期信息、统一格式、标记版本状态。第二检索策略要调。默认的关键词检索经常把不相关的旧文档搜出来语义检索又有时候找不准精确术语。我实测下来用“语义检索关键词混合”的方式效果最好既能理解语义也能精准匹配产品专属术语。这些配置在主流工作台里都有可视化开关不需要写代码。4.4 人工介入点全自动不等于好用搭建工台的时候我一度追求全自动从需求扔进去到PRD出来中间不用任何人确认。结果用了三周就发现了问题——全自动流程跑出来的结果真的没人看。大家都默认“AI都做完了”等评审时才发现一堆方向性错误。后来我在工作流里设置了三个强制人工确认节点需求清洗结果确认AI把乱七八糟的需求整理成清单后产品经理要过目确认避免错误合并或漏掉关键需求PRD生成前范围确认需求清单和边界范围必须先给产品经理确认防止范围蔓延评审模拟后的处置决策评审模拟Agent会列出一堆问题但哪些真改、哪些忽略需要人来判断。人工介入点不是越多越好每多一个卡点效率就降一截。我最终只保留最重要的两三个。现在的节奏是AI负责打磨初稿人负责把关方向。这个协作方式跑下来比全自动和全手动都靠谱。5. 实测半年后的踩坑清单上下文、幻觉、版本和数据5.1 最常出问题的不是模型是上下文传递用了半年之后我总结出最大的坑Agent之间的上下文传递。之前让PRD Agent同时读取需求、画像和竞品三份长文本模型开始“记忆混淆”——把竞品的功能写进自己产品的PRD里或者把需求清单里已经删掉的内容又加回来。排查后发现问题不是模型能力而是输入格式不对。我改成了“JSON全量摘要前置”的双轨输入给Agent提供完整的JSON数据用于结构化读取同时在提示词开头放一段不超过100字的摘要告诉它这次任务的三个重点。这样改了之后错误率下降得非常明显。5.2 幻觉问题竞品数据会被“合理编造”有一次竞品分析节点输出的内容里出现了竞争对手一个实际不存在的功能差点进了评审材料。后来查出来原因很简单知识库里关于该竞品的信息本来就不完整模型就“合理推测”了。我的解决方案是在所有信息类节点的提示词里加了一条硬性约束未在资料中明确出现的信息一律标注“信息缺失待人工确认”不允许模型自行补全。这个约束看起来简单但对输出质量的影响非常大。从那以后所有Agent生成的内容都有了“事实与推测”的界线人工判断的成本大幅下降。5.3 多人协作后的版本管理问题当团队里多个产品经理共用一个工作台后新的问题来了有人改了某个节点的提示词其他人不知道。你辛辛苦苦优化的PRD节点效果同事可能为了一个临时需求把它改成了“自由创作模式”之后所有PRD都开始“发挥”。我后来把提示词也当作正经文档来管理。每个节点的提示词必须有版本记录、变更说明和当前生效版本号。这不是开发思维而是产品设计逻辑的表达——提示词本质上就是把你的产品判断固化成了模板团队一起维护、一起升级才能越用越好。5.4 成本与响应速度的平衡Agent工作台跑一次完整流程相当于调用了好几次大模型API。如果每次都让最强的模型干所有活成本会很感人。我的做法是分级调度中间过程节点需求清洗、画像用便宜快速的小模型只有最终PRD生成和评审模拟用高性能大模型。另外对历史相似需求直接命中模板复用不重复跑全流程。响应速度从几分钟降到几十秒成本也降了一半以上。6. 给产品经理的落地路径从最小工作流开始6.1 第一步选一个高频场景先跑通两个节点我的建议是不要从“全流程自动化”开始先找一个你每周都会做的场景比如“把需求评审会纪要整理成结构化需求”或者“把用户反馈归类并提炼痛点”。用工作台把两个节点跑通一个负责输入清洗一个负责结构化输出。这个最小实验三两天就能完成跑通之后的成就感会驱动你继续扩展。产品经理在这个阶段要学的不是写代码而是任务拆解和提示词设计。拆解能力本来就是产品经理的强项你只需要把“用户故事拆成功能点”的思维迁移到“大任务拆成Agent节点”上。6.2 第二步把提示词模板变成团队资产工作台搭好之后最该沉淀的是提示词模板和工作流模板。我的习惯是每做完一次完整流程就复盘一次哪个节点的输出最不满意为什么然后针对性改提示词。改完的效果如果好就固化成团队模板。团队里应该建立一个小小的“模板库”按节点分类存放需求解析提示词、画像提示词、PRD提示词、评审模拟提示词。新同事加入时不看文档直接让他跑一遍工作台比看十页SOP都管用。6.3 第三步记住一个底线最后说一个底线AI的输出永远只是候选方案产品决策权必须留在人手里。用Agent工作台不意味着你可以从评审会里消失恰恰相反它把重复劳动吸走之后你会有更多时间去做那些AI做不了的事——判断什么值得做、什么叫做好、怎么平衡各方利益。我自己用下来的体会是Agent工作台真正改变的不是“写文档的速度”而是产品设计的思考方式。以前写PRD习惯性地从空白页开始想到哪写到哪现在我会先把信息变成结构化输入让Agent去处理归纳我则把省下来的时间花在判断和决策上。这个转变需要一点时间适应但一旦习惯就回不去了。如果你也想试试我建议今天就开始做一个最小实验把你最近一次需求评审会的纪要和需求列表整理出来先跑通“需求解析”和“PRD骨架”这两个节点。你会发现AI产品设计的真正门槛从来不是模型参数而是你愿不愿意把自己的工作流认真拆一遍。 AI时代产品经理如何搭建Agent工作台：从PRD到评审模拟的全流程实战
做了这么多年产品我越来越觉得一个扎心的事实AI时代真正拉开产品经理差距的不是谁更会写PRD而是谁先搭好了自己的 Agent 工作台。现在几乎每个产品经理都在用AI但大部分人的用法是这样的打开一个聊天窗口输入“帮我写一份XX产品的PRD”AI噼里啪啦输出几千字复制粘贴到文档里然后……就没有然后了。下一次写PRD又从零开始问一遍。需求变了重新问一遍。评审发现一堆问题再重新问一遍。这不是AI不行而是我们把它用成了“一个更聪明的搜索引擎”。产品经理真正需要的不是聊天气泡而是一个能承接完整工作流的 Agent 工作台——需求进来经过分析、画像、竞品、PRD、评审模拟一系列节点产出被组织好的、可用的、可追踪的结果。这篇文章我就用实际经验聊一聊AI怎么做产品设计以及一个真正可落地的 Agent 工作台该怎么搭、怎么用、会踩哪些坑。1. 产品经理用AI做产品设计的真实困境从“问一句答一句”说起不少产品经理找我聊AI落地开场往往是那句“我试过让AI写PRD写完没法用”。我问怎么写的回答基本是同一个模式把需求背景丢给聊天窗口让它直接输出PRD。结果通常是两种要么是结构化有余、真实信息不足——格式挺漂亮但里面全是AI脑补的需求要么是前后逻辑对不上目标、客群、功能列表之间没有因果关系。1.1 四个典型现象几乎每个团队都能对上号第一个现象是描述与判断脱节。聊天窗口只对“当前这句话”负责不会自己去翻你以前写过的PRD不会去查用户反馈原文更不会核对竞品信息。你让它写目标用户它就写“年轻白领”你让它列竞品它就给你列几个“可能的”产品。敢编是真敢编但产品经理要的不是创意写作而是有依据的判断。第二个现象是流程无法沉淀。写PRD只是产品设计的一个节点。前面要梳理需求来源、用户反馈、历史版本后面要准备评审、拆解排期。单点AI只能帮你写中间那一段前后环节仍然靠人肉搬运。搬一次两次还能忍项目一多信息就大量丢失。第三个现象是结果不可追踪。聊天窗口里生成的内容不会自动进知识库也不会标明依据来源。评审时别人问“这句话的依据是什么”你没法回答。产品设计是一个需要反复对齐、所有决策都要留痕的工作聊天窗口天然满足不了这个要求。第四个现象是上下文一多就不稳定。产品设计涉及的信息量很大需求背景、用户反馈、历史版本、竞品资料、战略目标一份长PRD的上下文字数轻松破万。一条聊天窗口根本塞不下强行把所有资料贴进去模型就开始糊涂输出质量直线下降。1.2 问题根源聊天窗口和产品设计是两种不匹配的形态很多人把这些问题归因于“模型不够聪明”但模型能力其实早就不差。问题的根源在于交互形态错位聊天窗口是“问答式”的产品设计是“工作流式”的。问答式的特点是“你问什么我答什么”答完就结束没有状态、没有记忆、没有环节流转。而产品设计本质上是一个多环节、多角色、多轮迭代的流程先收集需求再分析用户然后对比竞品接着撰写方案最后还要模拟评审、根据反馈修订。环环相扣每个环节的输出都会影响下一个环节的质量。这两种形态凑到一起产品经理就只能在“让AI单点帮忙”和“自己从头包办”之间反复横跳。真正需要的其实是一个把“问答”升级为“流水线生产”的中间层——这就是 Agent 工作台出现的理由。2. 为什么偏偏是Agent工作台它怎么把“写PRD”变成“跑流程”2.1 先给Agent工作台下个定义“Agent工作台”这个词最近被说烂了但大多数人对它的理解还停留在“能调用工具的AI”。我理解的Agent 工作台是把多个AI Agent、知识库、工作流编排和人工审核节点整合在一起的生产环境。它跟聊天窗口最大的区别在于不只有一个“大脑”而是把一个复杂任务拆分给多个各司其职的Agent去跑同时让数据在Agent之间有序流动。举个例子。同样做一个新版本的产品方案聊天窗口模式你输入需求AI直接吐一堆内容。生成质量完全取决于你一次性把背景资料描述得有多全。漏一句它就给你脑补一大段。Agent工作台模式你把原始需求、用户反馈文档、历史版本链接、竞品信息扔进工作台。需求解析Agent先整理需求清单画像Agent基于用户反馈生成用户画像竞品Agent输出对比矩阵PRD Agent基于前面所有输出生成文档结构最后评审模拟Agent挑刺把潜在风险列出来。每个环节都有独立的提示词、独立的知识库引用、独立的输出格式产品经理只在关键节点做确认和修改。我一开始也觉得这只是概念包装但实际用下来两种模式的差距是代际性的。聊天窗口像请了个什么都会但不记得前因后果的实习生Agent工作台像把一个产品设计流程拆成了五个各管一段、交接清晰的“虚拟员工”。2.2 产品设计流程中哪些环节适合交给Agent不是所有环节都要自动化。我梳理下来产品设计流程里有七个环节非常适合 Agent 化因为它们都有三个共同特征规则相对明确、需要大量背景资料阅读、输出格式相对固定。环节核心工作适合Agent化的原因需求收集与清洗从群聊、工单、访谈记录中提取需求原始素材量大且杂乱适合机器先粗筛用户研究与画像整理访谈记录识别痛点和场景需要通读全文再归纳AI擅长提取竞品分析功能对比、逻辑拆解信息拼凑和结构化输出是强项PRD编写背景、目标、功能需求、边界、埋点格式高度固定且有前置输入流程图/结构图描述从PRD生成页面结构和流程描述规则清晰输出可复用评审模拟找漏洞预判评审问题需要多角色视角Agent可以扮演排期拆解与验收标准拆任务写验收清单基于需求列表做规则映射这里要强调一个观点“适合Agent化”不等于“完全不用人管”。产品设计里最值钱的是商业判断和用户理解这部分一定要留在人手里。Agent负责的是“信息处理和初稿生成”人负责的是“方向把控和关键决策”。这样分工效率和质量才能同时保住。3. 真正实用的四类Agent节点从需求清洗到评审模拟3.1 需求解析节点先把“垃圾输入”洗成“结构化需求”需求来源特别杂微信群里随口一提、客服工单、用户访谈录音转写、问卷开放题。这些东西直接喂给大模型输出质量会非常差。我的工作台里第一个节点就是“需求解析Agent”它负责把原始素材读一遍输出一份规范的需求清单包含来源、原始表述、需求意图、影响用户、预期价值、优先级建议。这个节点的提示词里我会强制两个约束一是不要合并相似需求因为AI特别喜欢把两件事当成一件事二是保留原始表述每条需求后面必须带来源摘录方便后续追溯。这一步做好了后面的节点才能吃到干净数据。我用的是国内大模型API效果已经足够不需要追求超大参数模型来处理这种分类任务。具体做法是把原始素材按文档形式传进去要求Agent逐条输出。输出用JSON结构方便下一个节点直接读取。JSON长什么样不关键关键是字段固定比如source、raw_text、intent、user_segment、suggestion。字段固定了下游节点才不会“漏看信息”。3.2 用户画像与场景还原节点不允许没有依据的结论画像Agent的输入是用户反馈记录和访谈文本输出是一组用户画像和典型使用场景。这里最容易翻车的地方是“凭空捏造用户”——AI会基于自己的刻板印象生成一个看起来无懈可击的画像实际上跟你的真实用户毫无关系。我的解法是在提示词里加一条铁律每条画像结论必须附带至少一条原文依据。比如“用户对导出功能不满”这个结论后面必须跟着一条用户原话或工单原文。这条约束一加输出质量立刻不一样。模型会老老实实去语料里找依据找不到的结论它就不敢写或者明确标注“推测”。这个机制很像产品团队做用户访谈时的要求每个洞察都要有出处不能拍脑袋。3.3 PRD生成节点锁定边界比生成内容更重要PRD生成Agent是整个工作台里最核心的节点。它的输入是前面几个Agent的输出需求清单、用户画像、竞品对比输出是一份包含背景、目标、范围、用户故事、功能需求、边界条件、数据埋点、验收标准的完整PRD。写这个节点的提示词时我发现一个反直觉的经验约束比指令更重要。模型生成内容的能力已经过剩真正难的是让它“别乱写”。所以我在提示词里重点强调三件事不得新增输入中未出现的需求所有功能描述必须能追溯到需求清单必须明确“本期不做”的范围边界防止后续脑补所有用户故事必须关联到画像和场景没有场景支撑的故事直接删除。一个典型的PRD节点提示词模板是这样的# 角色 你是一名有8年经验的资深产品经理擅长写结构严谨、边界清晰的需求文档。 # 输入 以下是需求清单、用户画像和竞品分析结果全部来自前期分析不需要你重新推断。 输入数据 {结构化JSON} /输入数据 # 任务 基于输入生成一份PRD必须包含以下章节 1. 背景与目标 2. 产品范围含本期不做 3. 用户故事与使用场景 4. 功能需求清单带优先级 5. 边界条件与异常场景 6. 数据埋点需求 7. 验收标准 # 约束 1. 不得新增输入中未出现的需求 2. 每条功能需求必须标注来源编号 3. 必须包含至少三条“本期不做”的边界说明 4. 用户故事必须关联画像编号 5. 全文使用Markdown格式输出你会发现这个提示词里没有任何“请写得精彩一点”“请深入思考”之类的话。因为对生成式模型来说自由就是风险约束才是质量。3.4 评审模拟节点让AI扮演最挑剔的评审官我工作台里最有价值的一个节点其实是评审模拟Agent。产品经理每次评审最怕什么最怕被问到没想过的问题。以前这些盲区只能靠经验和运气现在可以让Agent先“自问自答”一轮。评审模拟Agent的输入是PRD全文输出是一份“评审提问清单”包含每个问题对应的文档章节、问题描述、可能的影响、建议的修改方向。它扮演的是一个刻意挑刺的评审官专门找需求的漏洞优先级依据是什么异常场景考虑了吗数据指标怎么衡量权限边界有没有定义老用户迁移方案是什么更关键的是这个环节可以“闭环”。我把评审模拟Agent的输出反馈给PRD Agent让它基于问题清单修订文档修订完再跑一轮评审模拟直到问题数降到阈值以下。这个多轮迭代在聊天窗口里几乎没法实现——因为每次都要手动搬运上下文而Agent工作台天然支持这种循环。4. 亲手搭一个Agent工作台我的选型、配置与人工卡点设计4.1 选型别一上来就自己写Agent框架很多产品经理跟我聊的时候第一句话是“要不要学LangChain”。我的建议很直接第一步别碰框架。市面上主流的工作台工具已经把这些东西封装成了可视化拖拉拽产品经理完全可以自己搭建。方案A开源低代码平台如Dify。适合想把数据留在内部的团队也可以私有化部署有工作流编排、知识库、日志追踪功能。方案B云厂商的Agent平台如阿里云百炼、火山引擎等。适合本来就深度使用云服务的团队集成方便运维成本低。方案C无代码的Agent搭建工具如Coze扣子等。上手最快适合个人或小团队快速验证产品经理可以完全自助搞定。方案D自己用LangChain/LangGraph写。适合公司要把它做成内部平台、多团队复用的场景。但这是最后一步不是第一步。我实际用的是先方案C/方案A快速搭Demo验证流程有价值之后再让工程团队用方案D做正式化。这样既避免了从一开始就陷进技术细节也不会在流程还没验证时浪费太多资源。4.2 把流程拆成可执行的节点第一次搭建时我犯过一个典型错误想直接做一个“PRD生成器”把所有的信息一股脑塞给一个Agent。做了两版后发现输出质量非常不稳。后来我才想明白真正提升质量的关键不是PRD生成提示词写得多么华丽而是前面有几个Agent先把信息处理好。我把工作流拆成了五个节点需求清洗Agent输入原始需求素材输出结构化需求清单用户画像Agent输入反馈语料输出画像和场景竞品拆解Agent输入竞品资料输出功能对比矩阵PRD生成Agent综合前三者输出生成PRD初稿评审模拟Agent对PRD提问输出问题清单。每个节点的输入输出我都定义了固定的JSON结构前一个节点生成的数据直接传给下一个节点。这样做的最大好处是每个Agent只需要关注自己这一段事不需要把整条链路的信息全都装进上下文。这大大降低了模型的“记忆压力”输出稳定性明显提升。4.3 知识库配置工作台的“记忆力”要从源头抓起知识库是Agent工作台区别于聊天窗口的重要部分。它是工作台的“长期记忆”决定了大模型能不能基于你团队的真实资料工作。我把三类资料放进了知识库历史PRD清洗过的、用户反馈原文脱敏处理、竞品公开信息。有两点必须提醒。第一历史PRD一定要清洗后再入库。我一开始直接导入了所有历史文档结果模型经常把旧版本已经废弃的功能当成当前功能在生成PRD时“复活”了一堆不该存在的需求。清洗的核心是去掉过期信息、统一格式、标记版本状态。第二检索策略要调。默认的关键词检索经常把不相关的旧文档搜出来语义检索又有时候找不准精确术语。我实测下来用“语义检索关键词混合”的方式效果最好既能理解语义也能精准匹配产品专属术语。这些配置在主流工作台里都有可视化开关不需要写代码。4.4 人工介入点全自动不等于好用搭建工台的时候我一度追求全自动从需求扔进去到PRD出来中间不用任何人确认。结果用了三周就发现了问题——全自动流程跑出来的结果真的没人看。大家都默认“AI都做完了”等评审时才发现一堆方向性错误。后来我在工作流里设置了三个强制人工确认节点需求清洗结果确认AI把乱七八糟的需求整理成清单后产品经理要过目确认避免错误合并或漏掉关键需求PRD生成前范围确认需求清单和边界范围必须先给产品经理确认防止范围蔓延评审模拟后的处置决策评审模拟Agent会列出一堆问题但哪些真改、哪些忽略需要人来判断。人工介入点不是越多越好每多一个卡点效率就降一截。我最终只保留最重要的两三个。现在的节奏是AI负责打磨初稿人负责把关方向。这个协作方式跑下来比全自动和全手动都靠谱。5. 实测半年后的踩坑清单上下文、幻觉、版本和数据5.1 最常出问题的不是模型是上下文传递用了半年之后我总结出最大的坑Agent之间的上下文传递。之前让PRD Agent同时读取需求、画像和竞品三份长文本模型开始“记忆混淆”——把竞品的功能写进自己产品的PRD里或者把需求清单里已经删掉的内容又加回来。排查后发现问题不是模型能力而是输入格式不对。我改成了“JSON全量摘要前置”的双轨输入给Agent提供完整的JSON数据用于结构化读取同时在提示词开头放一段不超过100字的摘要告诉它这次任务的三个重点。这样改了之后错误率下降得非常明显。5.2 幻觉问题竞品数据会被“合理编造”有一次竞品分析节点输出的内容里出现了竞争对手一个实际不存在的功能差点进了评审材料。后来查出来原因很简单知识库里关于该竞品的信息本来就不完整模型就“合理推测”了。我的解决方案是在所有信息类节点的提示词里加了一条硬性约束未在资料中明确出现的信息一律标注“信息缺失待人工确认”不允许模型自行补全。这个约束看起来简单但对输出质量的影响非常大。从那以后所有Agent生成的内容都有了“事实与推测”的界线人工判断的成本大幅下降。5.3 多人协作后的版本管理问题当团队里多个产品经理共用一个工作台后新的问题来了有人改了某个节点的提示词其他人不知道。你辛辛苦苦优化的PRD节点效果同事可能为了一个临时需求把它改成了“自由创作模式”之后所有PRD都开始“发挥”。我后来把提示词也当作正经文档来管理。每个节点的提示词必须有版本记录、变更说明和当前生效版本号。这不是开发思维而是产品设计逻辑的表达——提示词本质上就是把你的产品判断固化成了模板团队一起维护、一起升级才能越用越好。5.4 成本与响应速度的平衡Agent工作台跑一次完整流程相当于调用了好几次大模型API。如果每次都让最强的模型干所有活成本会很感人。我的做法是分级调度中间过程节点需求清洗、画像用便宜快速的小模型只有最终PRD生成和评审模拟用高性能大模型。另外对历史相似需求直接命中模板复用不重复跑全流程。响应速度从几分钟降到几十秒成本也降了一半以上。6. 给产品经理的落地路径从最小工作流开始6.1 第一步选一个高频场景先跑通两个节点我的建议是不要从“全流程自动化”开始先找一个你每周都会做的场景比如“把需求评审会纪要整理成结构化需求”或者“把用户反馈归类并提炼痛点”。用工作台把两个节点跑通一个负责输入清洗一个负责结构化输出。这个最小实验三两天就能完成跑通之后的成就感会驱动你继续扩展。产品经理在这个阶段要学的不是写代码而是任务拆解和提示词设计。拆解能力本来就是产品经理的强项你只需要把“用户故事拆成功能点”的思维迁移到“大任务拆成Agent节点”上。6.2 第二步把提示词模板变成团队资产工作台搭好之后最该沉淀的是提示词模板和工作流模板。我的习惯是每做完一次完整流程就复盘一次哪个节点的输出最不满意为什么然后针对性改提示词。改完的效果如果好就固化成团队模板。团队里应该建立一个小小的“模板库”按节点分类存放需求解析提示词、画像提示词、PRD提示词、评审模拟提示词。新同事加入时不看文档直接让他跑一遍工作台比看十页SOP都管用。6.3 第三步记住一个底线最后说一个底线AI的输出永远只是候选方案产品决策权必须留在人手里。用Agent工作台不意味着你可以从评审会里消失恰恰相反它把重复劳动吸走之后你会有更多时间去做那些AI做不了的事——判断什么值得做、什么叫做好、怎么平衡各方利益。我自己用下来的体会是Agent工作台真正改变的不是“写文档的速度”而是产品设计的思考方式。以前写PRD习惯性地从空白页开始想到哪写到哪现在我会先把信息变成结构化输入让Agent去处理归纳我则把省下来的时间花在判断和决策上。这个转变需要一点时间适应但一旦习惯就回不去了。如果你也想试试我建议今天就开始做一个最小实验把你最近一次需求评审会的纪要和需求列表整理出来先跑通“需求解析”和“PRD骨架”这两个节点。你会发现AI产品设计的真正门槛从来不是模型参数而是你愿不愿意把自己的工作流认真拆一遍。