在软件项目里,有一个公认的“地狱开局”:需求调研。
客户说“我想要个质量审批系统”,但说不清审批流怎么走;销售说“功能清单已经给全了”,开发一看,图纸变更、不合格处置全没写;产品经理抱着录音笔连开三天会,整理出的纪要连自己都觉得像“阅读理解”。
结果就是——需求在口头传递中失真,在文档转译中遗漏,在反复确认中变形。 项目团队陷入“边猜边做、边做边改、边改边吵”的死循环。等到原型终于画出来,客户却一脸茫然:“这不是我要的。” 于是,推倒重来,预算超支,交付延期。
究其根源,传统调研有三大“致命伤”:
信息碎片化:需求散落在会议录音、邮件、Excel表格和微信聊天里,无法形成结构化资产;
反馈滞后化:客户要等原型完成才能“看见”需求,而原型制作本身耗时数天,试错成本极高;
认知差异化:客户用业务语言,技术用系统语言,双方在“想象”中博弈,而不是在“画面”上对齐。
AI时代,一切有了新的解法。
需求调研智能体面向软件项目的前期调研与设计阶段,是SWE Agent软件工程智能体的首个应用环节,把“功能清单、会议录音、业务文档”作为输入,把“可交互的原型、结构化的用例、规范的需求文档”作为输出——让需求在沟通的同时,就完成沉淀与转化。
它的逻辑很简单:先让客户“看见”再沟通,边沟通边生成,边生成边确认。 一次完整的需求调研分为四个连续阶段: 下面以MES系统需求调研为例,具体说明各阶段如何开展。 在正式调研前,项目人员先整理客户已经明确的基础需求,录入功能清单。 除了功能清单,项目人员还可以上传客户已有的项目物料,例如业务文档、表格、制度规范、历史系统资料和补充需求说明。上传时可以填写材料说明,标注该文件对应的业务模块和主要用途。 材料上传完成后,AI自动解析其中的功能模块、页面结构、字段要求和基础业务描述,并生成初版原型。 项目人员可以直接预览生成结果,检查左侧功能菜单是否与清单一致,页面中是否包含对应的列表、表单、详情和数据看板。 初步原型中的菜单与功能清单对比 对于功能清单中已经明确的字段,系统会按照字段语义生成相应组件。例如,订单编号生成文本输入框,签订日期生成日期组件,客户类型生成下拉选项;如果订单表单包含多个明细项,则可以生成相应的子表结构。 初步原型中的字段与功能清单对比 按照现有应用流程,原本需要约两天完成的demo原型,可以缩短至约3分钟生成。项目团队不必先投入大量时间制作完整原型,即可带着初步效果进入调研。 需求调研开始后,项目团队可基于初版原型,与客户逐个模块确认需求,并补充调研更多业务需求。调研人员可以在需求调研智能体中创建调研任务,并按销售管理、工程管理、计划管理等不同主题分别记录。 会议开始后,系统实时录音并自动转写;如果已有录音文件,也可以直接上传。项目人员还可以补充会议笔记,或者导入客户现场提供的业务资料。 录音内容可编辑 录音完成后,需求调研智能体结合会议转写内容、调研笔记和相关材料,生成对应的业务场景与业务用例。例如,在客户信息录入场景中,业务用例会包含销售人员录入客户信息、客户名称唯一性校验等要求;在订单审批场景中,则会记录订单提交、销售主管审批,以及审批完成后进入后续工程环节等内容 调研会议录音、内容转写 通过这一过程,会议中的业务要求可以在调研结束后即时形成结构化记录,减少人工整理时间和信息遗漏。 企业软件的需求通常分散在不同部门和多轮会议中。一场会议可能只讨论销售管理,另一场讨论工程管理和计划管理,后续还会继续补充仓库管理、数据看板等内容。 各模块调研完成后,项目人员可以选择需要合并的历史调研任务,汇总业务场景和用例,同时关联调研前上传的功能清单与项目物料。 多次调研内容汇合 生成需求规格说明书前,项目人员可以先检查文档大纲,可以直接修改目录结构。例如,原功能清单中没有图纸变更模块,但客户在工程管理调研中提出了相关需求,即可在需规大纲中新增“图纸变更”;如果项目物料中补充了仓库管理要求,也可以增加库存管理和出入库管理等内容。 需求规格大纲修改 大纲确认后,需求调研智能体生成需求规格说明书。文档中包含项目说明、功能结构、业务场景、功能需求、页面字段和相关规则。 生成完成后,项目人员可以检查各模块内容,并继续补充或修改。例如,在订单管理表单中增加产品明细和物料明细两个子表;在计划编排中增加计划工序定额;在数据看板中调整指标名称、图表类型及横纵坐标口径。 根据调研会议生成需求规格说明书图 确认后的文档可以直接保存和下载。按照现有应用流程,需求规格说明书的编制可由约两天缩短至约5分钟,文档规范完整率达到98%。 需求规格说明书完成后,可以继续作为应用生成的直接输入。 项目人员上传确认后的需规文档,需求调研智能体按照文档中的功能结构逐步生成应用。生成内容包括系统菜单、业务页面、字段、表单组件、主子表和数据看板。 以MES系统为例,如果需求规格中新增了图纸变更、库存管理和出入库管理,新的应用中会同步生成相应模块。 新生成的需规文档中新增模块 如果订单管理要求包含产品明细和物料明细,系统会生成对应子表,并按照文档要求生成相关字段;如果计划编排中增加了工序定额,页面中也会形成相应内容。 对于数据看板,系统可以按照需求规格中的指标名称、图表类型和横纵坐标生成页面。例如,生成订单总数、计划达成率等指标卡,以及订单金额趋势、生产数量趋势、订单状态分布等图表。 应用生成后,项目人员可以将页面与需规文档逐项对照,检查功能模块是否完整、字段是否匹配、组件类型是否正确、图表是否符合要求。 生产页面与需规文档指标对比 如果发现需求遗漏,可以继续修改需规文档,再根据更新后的文档重新生成,使原型与最终确认的需求保持一致。 需求调研智能体并没有改变需求调研必须与客户充分沟通的基本原则,改变的是调研的工作方式。 在整个过程中,功能清单、初版原型、调研记录、业务用例、需求规格说明书和精准原型保持连续关联。新增了什么需求、调整了哪些字段、补充了哪些业务模块,都可以在后续文档和应用中继续体现。 这让需求调研从“先讨论、再整理、后设计”,转向“先看到、再沟通、同步沉淀、直接生成”,实现需求快速共识与设计一步到位。 完成需求确认和精准原型生成后,需求调研智能体还可以进一步衔接应用配置、功能修改、测试、发布和运维等环节。关于应用生成之后如何继续完成配置开发与上线运行,将在后续文章中进一步展开。场景一:调研准备--上传功能清单,生成初版原型
场景二:调研启动--基于原型沟通,自动形成业务用例
场景三:需规生成--合并多轮调研,形成完整需求文档
场景四:精准生成--根据需规重新生成应用
从“先调研、后出图”,变成“边看、边调、边确认”