基于大模型的需求分析技术及应用

一、项目背景与职责

该医保智能监管平台的目标是打通省级医保结算数据与定点机构诊疗数据，实现事前提醒、事中审核、事后追溯的闭环监管。项目启动时面临的核心业务痛点是：需求来源高度碎片化——医保局的政策文件以规范性语言表述，医疗机构的业务流程以操作惯例呈现，第三方审核服务商的接口约束又以技术契约形式存在，三者之间缺乏统一的语义基准。上一期类似项目中，需求评审阶段发现的术语冲突和逻辑矛盾约有四成是在开发中后期才暴露的，修复成本极高。

我在项目中担任需求分析负责人，职责包括：制定需求获取与分析的总体技术方案，主导大模型辅助需求分析流程的设计与工具选型，组织冲突仲裁与人工确认环节，并对最终需求规格说明的质量负总责。项目组另有4名需求分析师和2名领域专家，领域专家不直接操作大模型，而是承担“语义裁决者”的角色。

二、基于大模型开展需求分析的主流技术路线

从2023年以来的研究和工业实践看，大模型进入需求分析领域并非单一方法的替代，而是形成了若干条在“控制力—知识注入—推理深度”之间做不同权衡的技术路线。以下四种路线在当前的工程实践中具有代表性。

第一条是提示工程路线，以任务分解和推理引导为核心。 其基本原理是将需求分析任务拆解为抽取、归类、改写、检查等子任务，通过零样本、少样本、思维链、角色扮演、提示链等策略引导模型在每一步聚焦于一个受控的输出目标。零样本适用于边界清晰的简单抽取；少样本在领域术语密集时能显著提升格式遵循度；思维链适合需要显式推理的需求冲突初筛；提示链则将多步任务串联，使前一步的输出成为后一步的约束条件。这条路线的主要优势是部署成本低、迭代快，分析师可以直接调整提示来响应需求变化。局限在于，提示对输出质量的影响极为敏感，措辞的细微变化可能导致抽取结果的粒度或口径发生偏移，且模型缺乏项目专属知识的持久记忆，复杂领域中的鲁棒性不足。

第二条是检索增强生成路线，将外部知识注入生成过程。 原理是在模型生成之前，从需求模板库、领域术语表、历史项目规格说明或政策文件中检索相关片段，拼接为上下文后再执行分析任务。在需求工程场景中，RAG特别适用于需要遵循组织既定规范（如EARS模板、功能设计规格书格式）或需要引用领域约束条件的任务。其优势在于以较低成本缓解了模型对项目专有知识“不知道”的问题，并降低了凭空编造术语的风险。局限在于检索质量直接决定生成质量：如果检索到的上下文与当前需求片段语义不匹配，模型会基于错误的知识锚点进行推理，反而放大偏差；此外，分块策略和嵌入模型的选择也需要针对需求文本的特性进行调优。

第三条是有监督微调路线，在领域数据上调整模型参数。 当项目积累了一定数量的高质量“需求输入—分析输出”配对数据后，可以在开源基座模型上进行指令微调，使模型内化特定组织的需求表述习惯和领域推理模式。这条路线在需要高格式一致性和领域术语稳定性的场景中效果突出，例如从会议纪要或工单文本中批量抽取符合特定模板的用户故事。但其门槛显著高于前两条路线：需要足量且标注质量可靠的训练数据，微调后的模型更新成本较高，且在需求边界快速变化时灵活性下降。

第四条是多智能体协作路线，通过角色分工和协商机制提升分析深度。 其基本思路是为模型赋予不同的专业角色（如业务分析师、系统架构师、安全评审员），各自独立生成或评审需求片段，再通过结构化协商（提议—批评—综合）暴露单一视角难以发现的跨质量属性冲突。QUARE框架在这一方向上提供了较为完整的参考：它将需求质量分析建模为五个质量专精智能体之间的辩证协商，使“效率”与“安全”、“可操作性”与“合规性”之间的张力在协商过程中被显式地暴露出来。多智能体路线在冲突检测和权衡分析上具有明显优势，但计算开销大，协商过程可能陷入循环或收敛到表面折衷，需要精心设计终止条件和仲裁规则。

这四条路线并非互斥。在工程实践中，更务实的做法是以提示工程为基线，在需要项目知识注入的环节嵌入RAG，在格式一致性要求最高的子任务上考虑微调，在冲突密度高的分析阶段引入受限的多智能体评审。

三、项目实践：流程落地、校验与冲突处理

3.1 落地流程设计

我们采用的流程以“人在环路中”为基本约束，大模型承担初筛和草稿生成，领域专家和需求分析师保留最终裁决权。流程分为四个阶段。

第一阶段：多源输入的结构化抽取。 医保政策文件、机构业务流程说明和接口约束文档分别进入三条并行的抽取管线。我们为每一类输入设计了独立的少样本提示模板，以EARS句式结构作为输出格式的统一约束。例如，对政策文件中“应在X个工作日内完成Y”类条款，提示要求模型输出为“当[触发条件]时，系统应[响应行为]，以满足[约束条件]”的EARS格式。这一阶段使用RAG将领域术语表检索注入，以压低术语漂移。抽取结果不直接作为需求条目，而是作为“候选需求片段”进入下一阶段。

第二阶段：一致性聚类与初筛。 将候选片段按照业务域（参保管理、待遇结算、审核监控、基金监管）和需求类型进行聚类，聚类采用传统相似度计算与模型语义判断相结合的方式。这一步的目的不是让模型直接判定冲突，而是将可能相关的片段聚合到同一局部上下文中，降低后续冲突检测的搜索空间。相关研究也表明，将传统聚类技术与LLM检测相结合，可以同时提升冲突识别的精确率和召回率。

第三阶段：多智能体评审与冲突标注。 对每个聚类簇，启动三个受限角色进行评审：业务规则评审员、数据一致性评审员和接口可行性评审员。每个角色基于同一簇的需求片段独立输出“冲突假设”，格式为（冲突类型、涉及片段、理由）。我们刻意限制了协商轮次为两轮，第一轮各自标注，第二轮仅对相互矛盾的标注进行交叉质询。质询记录作为冲突工单的附件保存，供领域专家裁决时参考。这一设计借鉴了多智能体辩证协商的思路，但将输出限定为“标注冲突”而非“解决冲突”，把解决权留给人工流程。

第四阶段：仲裁协商与需求基线化。 冲突工单进入领域专家主持的仲裁会。专家依据医保政策优先级和业务影响做出裁决，需求分析师据此修改或拆分需求条目。裁决结果和理由被结构化记录，作为下一轮RAG检索的知识源。基线化后的需求条目进入正式规格说明。

3.2 需求校验机制

校验不是单一检查点，而是贯穿上述流程的三层机制。第一层是格式校验，由确定性规则完成，检查抽取输出是否满足EARS句式模板和必填字段完整性，不通过者直接退回重抽，不消耗人工评审资源。第二层是语义一致性校验，由RAG增强下的模型对同一聚类簇内的片段做两两或成组比对，输出“一致/潜在冲突/信息不足”三分类，并附推理依据。这一层不追求高精确率，而是以较高召回率为目标，将疑似问题送入下一层。第三层是约束可满足性校验，针对涉及时间窗口、数值阈值和权限矩阵的需求，将自然语言条件转化为结构化约束，检查是否存在逻辑上的不可满足组合。对于字符串约束的可满足性，已有研究探索了LLM生成检查器数据与形式化方法结合的方式，我们在项目中采用了类似的思路，将模型生成的约束表达式交由规则引擎执行最终判定，避免模型在逻辑判定上产生幻觉。

3.3 需求冲突处理

冲突处理的核心原则是“暴露优先于消解，消解必须可追溯”。项目中的冲突被划分为三类，对应不同的处理策略。术语型冲突（同一业务概念在不同来源中的名称或口径不一致）由模型在抽取阶段标注，经领域专家确认后统一写入术语映射表，后续RAG检索强制引用该映射表。逻辑型冲突（两条需求在触发条件或响应行为上互斥）通过多智能体评审和第二层校验发现，进入仲裁流程，由专家依据政策依据和业务优先级裁决，裁决结果形成“冲突—裁决”对存入知识库。约束型冲突（数值阈值、时间窗口或权限范围不可同时满足）主要由第三层可满足性校验捕获，由需求分析师与干系人协商调整约束边界。仲裁协商中有争议的条目不被强行“多数决”，而是保留备选方案并在规格说明中标注决策依据，供后续设计阶段追溯。

3.4 实际效果

项目需求规格说明的初稿产出周期从立项时预计的14周缩短至8周。在需求评审阶段，冲突的早期发现率（在开发启动前被识别并处理的比例）从上一期项目的约62%提升至89%。因需求歧义或遗漏导致的开发阶段返工减少了约35%。这些改善的主要来源并非模型替代了分析师，而是模型将分析师从跨文档的逐条比对中释放出来，使其时间集中在裁决和协商上。需要指出的是，工时节约的度量受到项目范围和干系人配合节奏的干扰，上述数字应视为项目情境下的观测值，而非可泛化的效应量。

四、存在不足与改进思路

项目落地后暴露出的不足集中在三个方面。第一，幻觉残留并未消除，只是转移了形态。 模型在抽取阶段较少凭空编造整条需求，但在语义一致性校验中会“合理化”不存在的因果关系，即生成看似合理的冲突解释，而实际片段之间并无逻辑关联。当前的应对是要求每条冲突假设必须指向具体的片段标识和原文定位，无法定位的假设自动降权。更根本的改进方向是引入可追溯性约束：让模型在生成任何判定时强制引用检索到的知识片段或原文行号，并将引用有效性纳入校验规则。

第二，上下文漂移在长文档场景中仍然明显。 当同一业务域的需求片段超过一定数量后，模型对早期片段的注意力衰减导致漏检跨簇冲突。我们尝试了分段加摘要回注的方式，但摘要本身可能丢失关键的约束条件。后续计划将需求片段与业务实体之间的关系图作为检索结构，用图结构引导模型在相关实体邻域内做局部推理，而非依赖扁平的长上下文。

第三，多智能体评审的成本与收益在低冲突密度场景中不划算。 对于术语统一、来源单一的模块，三角色评审的额外计算开销和协调成本超过了其带来的冲突发现增量。改进思路是根据聚类簇的“异质性分数”（来源多样性、术语分歧度、约束密度）动态决定是否启动多智能体评审，将资源集中在真正需要多视角交锋的片段上。

结语

基于大模型的需求分析，其工程价值不在于让模型“写出”需求，而在于将需求分析中可分解的比对、标注和初筛工作前置，使人的判断力集中在冲突裁决和语义协商上。技术路线的选择应服务于这一分工逻辑：提示工程提供基础控制力，RAG注入项目知识，多智能体在需要多视角张力时补充推理深度，而形式化校验守住逻辑底线。项目的经验也表明，校验和冲突处理机制的设计质量，比模型本身的能力更能决定大模型在需求工程中的实际效用。