★ FEATURED ARTICLE 1. 先搞清楚边界需求分析Agent能自动化的其实是“搬砖”1.1 需求分析里哪些是真思考哪些是重复劳动我在某团队负责产品工作的时候每天最消耗精力的并不是“拍板做哪个功能”而是处理那一堆从四面八方涌进来的原始需求。用户群里有人丢一句“这个页面的加载太慢了”销售转述客户希望“能批量操作”运营在表格里填了“导出数据不方便”老板在周会上提了一句“我看竞品最近上了个什么功能”。这些信息全部是碎片化的、口语化的、甚至互相矛盾的距离能交给研发的需求文档中间隔着大量整理工作。很多人误以为需求分析全是高价值的思考判断实际上拆开看需求分析里至少有七成是重复劳动。信息归纳整理、字段补全、场景补全、竞品对照、文档结构生成、验收标准起草这些环节的特点是规则明确、重复度高、有模板可依只是信息量大导致极其耗时。真正需要产品经理动脑子的是对业务价值的判断、对取舍的权衡、对不确定风险的决策。把两件事分清楚以后需求分析Agent的定位就变得很清晰了——它不可能替你做判断但它完全可以替你做那七成搬砖工作而且搬得比你快。我当时的想法很简单能不能做一个只处理“搬砖”环节的小系统把原始需求丢进去出来一份结构基本完整、字段齐全、甚至带着候选场景和验收标准初稿的需求说明书产品经理只需要在上面做修改和确认而不是从零开始写。这就是我搭建需求分析Agent的起点。1.2 人与Agent的分工线应该画在哪里想清楚这个边界比选什么技术实现重要得多。我给自己定了一条硬性规则只要是“有标准答案”的信息处理环节就交给Agent只要是“没有唯一正确解”的判断环节就留在人手里。按这个规则我画了一张简单的分工表这成为后面所有Prompt设计和工作流拆分的基础。环节交给Agent的程度留下的理由需求来源收集与频道分类全程自动化分类规则清晰出错可控口语转结构化字段全程自动化字段模板固定人工只做抽查用户故事和场景补全自动化生成人工审核场景推演依赖LLM想象力但要防止编造竞品功能对照自动化检索整理只基于项目管理的历史资料不依赖网络随机信息优先级排序建议Agent出建议人定最终值优先级包含商业策略不能交给概率模型商业取舍和范围砍削不做这是产品经理的核心职责最终PRD评审不做必须由人逐条确认这条分工线带来一个直接影响Agent所有输出都标注了置信度和信息来源凡是没有出处的内容一律放进“待澄清”列表。后面遇到幻觉问题的时候这条规则救了我很多次。2. 工作流设计四段式管线比超大Prompt靠谱在哪2.1 我把一个需求从原始输入到PRD切成了四个环节最开始我也尝试过最直观的做法——把原始需求直接粘贴给大模型让它一口气输出一份完整PRD。结果是第一版看起来还行第二版开始漏字段第三版直接开始自己编功能越复杂的输入越不稳定。折腾了一个星期之后我意识到问题不在模型能力而在使用方式。单次对话让Agent同时完成“理解原始需求、补全信息、推演场景、写作结构化文档”多件事它对每件事的处理质量都会被稀释。于是我把整条链路切成了四个独立环节输入采集、信息结构化、场景推理、文档生成。每个环节是一个独立的Agent任务有自己的Prompt和输出格式下一环节只接收上一环节的结构化产物不直接接触原始对话。这就像工厂流水线每道工序只做一件事产物可检查、可返工、可替换。四个环节的输入输出关系如下环节输入输出需求采集聊天记录、语音转写、表格片段一条原始需求记录信息结构化原始需求记录 项目术语表字段完整的结构化需求说明书场景推理结构化说明书 历史知识库用户故事、场景表、价值假设、优先级建议文档生成推理结果 PRD模板可直接进入人工评审的PRD草稿2.2 为什么顺序不能乱每步的输入输出是硬约束这四个环节的顺序不是随便定的每相邻两步之间有强依赖关系。信息结构化必须在最前面因为后面所有推理都建立在“字段是干净、完整、统一”的基础上。如果场景推理Agent拿到的是原始对话文本它就无法稳定地识别用户角色和业务场景输出质量会大幅波动。我先让结构化Agent把口语转成一条条字段清楚的需求记录等于给整个系统建立了一个可靠的地基。场景推理放在文档生成前面是因为PRD里最怕出现“功能堆砌”。很多需求文档写不好的原因是直接列了一堆功能点却没有说明这些功能服务谁、解决什么场景下的什么问题。所以我在写PRD之前强制加了一步让Agent输出用户故事卡片、触发场景、预期收益和价值假设。这些内容成为PRD“需求背景”和“功能详述”的直接素材而不是靠Agent现场决定写什么。文档生成放在最后意味着它只负责“把已确认的信息按照模板排布成文”而不再负责“理解和创造”。这个分工让输出的评审难度大幅下降因为文档里每一项内容都能往前回溯到某个结构化字段评审人只需要问“这个字段是否符合实际”而不需要问“这句话是哪来的”。2.3 搭建方式用LLM API自己编排还是直接上Agent平台工具选型上当时摆在我面前有两条路。一条是用现成的Agent编排平台图形化拖拽节点配置Prompt模板发布成对话应用门槛很低另一条是直接用大模型API加脚本自己编排自由度最高所有流程完全可控。我最后选了第二条路用一个简单的Python脚本串起各环节Prompt模板放在独立配置文件里输出格式用JSON约束。选择自己编排的核心原因是因为需求分析流程里的中间产物我不想丢。如果用现成平台每步的输出藏在系统内部我要审查中间结果、要回传人工修订样例、要把历史修订沉淀回知识库都很不方便。自己编排之后每个环节的中间JSON都会落盘形成一份可追踪的操作记录。碰到输出质量下降的时候我可以回放每个环节的输入输出精准定位是哪个Prompt、哪个上下文出了问题。对大多数个人或小团队来说我建议先从一个轻量脚本起步跑通再扩展不要一开始就上完整的智能体平台。平台能加速Demo却会限制你对流程本身的掌控。3. 上线前必准备的三样东西模板、知识库和Prompt版本管理3.1 一张能让业务方配合的输入模板需求分析Agent的输入端质量直接决定了整条流水线的上限。如果业务方提交的是“我想做得更好”这种不可解析的需求再好的Prompt也无济于事。所以我在正式跑通之前先做了一张尽量简单的需求采集模板挂在团队的需求收集表里。模板字段不多一共八项提出人、需求来源、用户角色、使用场景、当前痛点、期望方案、影响范围、预期时间。每一项都给了填写的例子。为了让业务方愿意填我在表格里加了“如果不好描述直接贴聊天记录也行”这一栏。这种混合设计很关键——模板是引导不是门槛。老老实实按模板填的Agent直接完全处理只贴聊天记录的Agent也能解析只是会多输出几个“待澄清”字段后续由产品经理再确认一遍。实测下来运营和销售同事的配合度比预想中高因为他们也烦透了“说完需求还要被追着问五遍”。有了模板之后很多模糊信息在第一道入口就被补上了Agent的中途追问次数大幅减少。3.2 知识库不贪大先解决“有”再解决“全”需求分析Agent如果要准确理解业务术语和产品逻辑不能只靠模型训练时那点通用知识。以我们团队背景为例项目里大量存在“流量包”“额度池”“结算周期”这类业务词汇通用语言模型并不知道它们在具体场景下的准确含义硬让它写需求文档自然会写出似是而非的内容。解决办法是引入了一个小规模知识库把历史PRD、产品术语表、业务规则说明、常见问题FAQ整理成纯文本文档通过RAG方式在场景推理和文档生成环节做补充检索。我的经验是知识库不要想着一步到位做全。我当时只整理了约一百份历史文档覆盖了主要业务模块和术语就看到了明显的输出质量提升。关键是目录要干净、文档彼此不重叠否则检索结果会把不同模块的规则混在一起反而让Agent混乱。先解决“有”再慢慢扩到“全”这是成本最低的路径。3.3 把Prompt当代码管理抢救回滚才有路很多人对Prompt的印象是“一段提示词”改几个字无所谓。实际跑了两周以后你会明白Prompt是这个系统里变更最频繁、影响最大、最需要版本管理的部分。我对比过两次只差一个词把“输出”改成“只输出”的Prompt生成质量差距大得离谱。所以从第一天开始我就把Prompt模板当代码管理用Git保存每一版模板并在提交信息里写清改动意图比如“v2.3验收标准改为3条强制加2条可选减少文档篇幅”。这套版本管理在后期帮了大忙。有一版Prompt调整后Agent突然在验收标准里大量输出“保证系统稳定”“确保用户体验良好”这类废话我没法接受需要回滚到上一版。如果当时没有在Git里留记录我可能要对着几十个改动的Prompt文件手工找回那会是一个非常痛苦的下午。4. 核心模块拆解三类Agent的实际分工与Prompt设计4.1 第一棒结构化Agent把口语转成字段结构化Agent的目标是接收一段原始需求文本转成一条结构化需求记录。它的Prompt核心是给出一套明确的输出格式和禁止事项。我实际使用的一个简化版指令如下供参考你是需求分析助理。请将用户提交的原始需求整理为JSON格式的结构化需求记录。 必须包含以下字段 - user_role: 用户角色 - scenario: 使用场景 - pain_point: 当前痛点 - expectation: 期望方案 - impact: 影响范围 - missing_fields: 无法确定的信息字段名列表 规则 1. 只能基于输入内容整理字段禁止补充输入中不存在的信息。 2. 某项信息无法判断时字段值写null并将字段名加入missing_fields。 3. 保持原意不要润色和扩写。 4. 直接输出JSON不要输出其他解释。这个设计最关键的是第2条。因为在结构化阶段模型最大的风险是“脑补”。比如用户只说了“导出太麻烦”模型很有可能把“当前导出流程涉及三个系统”这种没提到的细节也填进去。一旦在源头污染了数据后面的推理和文档生成都会在此基础上越编越离谱。跑起来之后结构化Agent还要处理一些非典型输入比如语音转写里带着口误和重复词或者一段长聊天记录里同时有三个人在说话。我的处理方式是先把完整文本按发言者做切分再逐人提取需求最后对同一条需求的多段描述做合并去重。整个流程最初是人工在中间踩坑踩出来的后来固化成了一段预处理脚本。4.2 第二棒场景推理Agent生成用户故事与价值假设场景推理Agent拿到结构化需求记录后要做三件事生成用户故事、补全触发场景、给出价值假设和优先级建议。这三件事都带有一定推测成分所以Prompt里反复强调“这是假设不是事实”。用户故事部分我强制用“作为角色我希望能够动作以便目标”的句式这套句式能有效阻止Agent写出一堆没有主语的功能描述。场景部分则要求包含触发条件、操作路径和现状描述。举个实际输出例子针对“运营人员每周导出活动数据耗时太长”这条需求Agent生成的场景是“每周一上午9点活动运营需要在后台逐一点开五个渠道的数据报表手动复制到Excel里汇总整个过程约40分钟”。这个场景描述虽然不完全是用户原话但它零件全部来自结构化字段没有凭空捏造产品经理很容易验证和修正。价值假设部分我允许Agent估算“节省时间百分比”或“减少错误率”但所有数字必须标注“假设待验证”。优先级建议则用一个简单加权公式影响范围、使用频率、业务严重度每项1到5分三项乘积越大优先级越高。这个模型很朴素但它让Agent输出的优先级不再是玄学而是一个可解释的分数产品经理只需要复核分数并基于商业策略做出最终调整。4.3 第三棒PRD生成Agent产出带验收标准的文档草稿最后一个环节是PRD生成Agent它的输入是场景推理结果加PRD模板。我设计的PRD模板固定包含几个区块需求背景与目标、目标用户与使用场景、功能需求详述、非目标、验收标准、风险与开放问题。写到这里我需要特别说明验收标准的写法。我要求Agent用“Given-When-Then”格式输出验收标准即“在某个前置条件下当执行某操作时应得到某结果”。比如“Given 用户已登录并拥有数据导出权限When 点击批量导出按钮Then 系统在10秒内生成下载链接”。这种格式的好处是测试和研发可以直接拿去用不需要再翻译一遍业务语言。Agent在第一版里经常写成“系统应能高效导出数据”后来我把它当成负面示例直接写在Prompt里让Agent参考“这是错误写法不要模仿”输出质量才有了明显改善。PRD生成Agent还会强制输出“开发联调注意点”和“风险点”这两项起初是模板外的内容后来我发现草稿如果没有这两个区块评审会上研发一定会追问。与其等人来问再补不如让Agent先把可能的实施风险和跨系统依赖列出来哪怕只有50%的准确率对评审的组织效率也有显著提升。5. 从孤本Demo到团队入口接入协作流后的真实变化5.1 发布入口从“自己贴代码”到“团队对话式使用”第一版Agent只存在于我的本地脚本里只有我自己能用。真正让它产生价值是把它发布成了一个团队可访问的对话应用之后。当时我没有做复杂的界面只是挂了一个简单的输入框业务方把原始需求贴进去点提交几分钟后收到一条结构化需求记录。这个入口看着简陋但它把Agent从“产品经理自己的工具”变成了“团队需求协作的一环”。团队使用的第一个月里最明显的变化是需求文档的平均产出时间从几个小时降到了几十分钟。但比速度更重要的变化是需求和需求之间的表达方式开始统一了。以前每个业务方描述需求有自己的习惯有人给截图有人发语音有人只写一句话。现在经过Agent的结构化处理所有需求都变成同一套字段、同一种结构产品经理在对比优先级、梳理迭代计划时省了大量脑力。5.2 “二道门”评审机制Agent只准出草稿不准出结论Agent接入团队协作之后我特意定了一条规矩Agent输出的所有文档都是草稿必须经过两轮人工确认才能进入真正的需求评审。第一道门是产品经理确认结构化需求记录重点是核实“用户角色、场景、痛点”是否真实还原了原意第二道门是在PRD草稿评审时由研发和测试逐条确认验收标准是否可执行。这条机制看起来慢了一些但实际运行起来并没有拖慢整体节奏反而减少了无效返工。因为绝大多数修正都发生在第一道门——信息结构化阶段如果那里有偏差直接改字段就行不用等PRD写完了再推翻。到了第二道门评审会上的争论焦点从“这个功能该不该做”变成了“这个验收标准写得好不好”会议的决策质量明显变高了。5.3 修改回流让每次人工修订都变成下一次的示例我在跑了两周后发现一个现象同样的错误会在不同需求上反复出现。比如Agent经常把“影响范围”写太窄只写“运营团队”但实际上这个功能会影响到销售团队的数据报表。每次人工修改都要重新改一遍效率很低。后来我增加了一个回流机制每周把人工修订最多的五条需求整理成“修正记录”内容包括Agent原始输出、人工修改后的最终版本、以及修改原因。这些记录被放回知识库作为后续Agent生成时的正反示例。这个机制的本质是让Agent越用越懂你这个团队。大语言模型本身不会因为你用得多就变聪明但你的知识库和Prompt会不断积累你所在团队的修正偏好。比如某个团队特别看重数据埋点那就可以在回流记录里反复强调“验收标准必须包含埋点事件设计”Agent在后续生成中就会慢慢把这个偏好内化进去。这是我这个项目里收益最慢但最持续的一项投入。6. 质量是把关出来的幻觉治理与“待澄清”机制6.1 三个典型的“一本正经胡说”现场用大模型做需求分析遇到幻觉几乎是必然的关键在于怎么拦截。我整理了这段时间最常踩的三类翻车现场可以给打算自己动手的人一个参考。第一类叫功能编造。原需求是“希望详情页能推荐相似商品”Agent输出的PRD里竟然出现“支持用户自定义推荐算法参数”这种原需求完全没提过的能力。原因很简单模型看到“推荐”两个字就联想到了算法配置然后用合理的语言把它写了出来。第二类叫数字编造。Agent在价值假设里写“预计提升效率50%”这个数字拍脑袋来的没有对应的事实依据。第三类是结构幻觉。原需求是导出优化Agent在开放问题里却开始讨论权限管理的缺陷说白了是上下文里的历史信息串味了。幻觉类型具体表现拦截手段功能编造出现原需求之外的附加功能强制每条功能点标注信息出处数字编造出现无法验证的效率提升比例所有指标加“待验证”标签结构幻觉输出字段偏离约定格式用JSON Schema做严格校验针对这三类问题我的处理手段也各不相同。功能编造靠“出处标注”解决在Prompt里要求每条功能详述都要写明来自哪个原始字段或知识库文档写不出来就进“待澄清”。数字编造靠“待验证标签”解决所有量化指标必须跟着一句“此数值为假设需产品经理确认后生效”。结构幻觉靠程序校验解决每个环节的输出先跑JSON Schema不符合就直接丢弃重新生成不让坏数据往下游传递。6.2 让Agent学会说“我不确定”比让它说“我能做”更重要这是整个项目里我学到最重要的一句话一个合格的需求分析Agent应该知道自己在哪个时刻信息不足。大语言模型的默认行为是“尽量把话说圆”哪怕它并不知道答案也会用流畅的语句把缺口填上。做需求分析这种“圆谎”是致命的因为需求分析的价值恰恰在于暴露不确定性而不是掩盖它。所以我在所有Agent环节的Prompt里都写了一条统一原则“当输入信息不足以支撑输出时输出a待澄清问题清单并停止继续生成后续内容。”举个例子有一版我故意输入一条没有任何场景描述的需求——“导出功能做一下优化”结构化Agent直接输出了一张待澄清清单“希望优化哪个导出入口导出格式从几列增加到几列当前耗时是多少优化后是否有预期目标”拿着这张清单产品经理可以直接去找业务方逐条问不用再自己冥思苦想还漏了什么信息。“待澄清”机制让Agent在信息不足时主动停下来而不是硬凑一份看似完整的文档。从产品经理的角度看一份带疑问清单的短回复价值远高于一篇强行编出来的长PRD。这也是我把这个机制看得比所有Prompt技巧都重要的原因。6.3 一份适合人类复查的输出质量检查表最后无论Agent系统做得多完善最终输出还是要人来审。我给自己和团队成员整理了一份检查表每次评审PRD草稿之前按它过一遍基本能做到不让有问题的内容流出。用户故事里是否明确了角色、场景、目标还是只有一句模糊描述。每个功能点是否能回溯到原始需求有没有“凭空长出来”的功能。量化指标是否都有“待验证”标注还是直接写了一堆漂亮数字。验收标准能不能让测试同事直接转成用例而不是需要二次转译。风险点和开放问题是否覆盖了跨系统依赖、外部接口变更等实施层面事项。待澄清清单是否为空。如果还有悬而未决的字段就不能进入正式排期。这份检查表同时承担了人机协作的“关卡”功能。Agent把需求信息补得再齐也只是一个高质量起点人对业务的理解和判断才是把需求从“看起来不错”变成“真正可落地”的关键。跑了一段时间之后我最大的体会是需求分析Agent真正改变的不是写文档的速度而是产品经理把时间花在哪了。以前大部分时间消耗在归纳、整理、追问、起草上现在这些琐碎的搬砖工作被Agent接了过去人可以专心做优先级判断和业务取舍。换句话说好的工具不是替你思考而是帮你把时间还给真正的思考。如果你也想试我的建议是先拿一个频率最高、信息最零碎的需求类型做试点配上简单的输入模板和知识库跑一两周看效果是否达到预期再决定要不要扩大范围。
阅读完成 · 觉得有帮助？
