1. 为什么需求获取是AI最该先动刀的地方

做产品或者做项目的人应该都有过这种体验：需求文档看着写了两页纸，真正开会讨论的时候才发现，每个人脑子里想的根本不是一回事。业务方嘴里说的是“我想让用户更活跃”，研发理解成“要做签到功能”，设计理解成“改首页视觉”，运营理解成“提高推送频次”，最后出来的东西四不像。这种偏差的根源在于需求获取这个环节几乎完全依赖人的表达能力和理解能力，而人的表达天然是模糊、跳跃、带预设的。

我接触AI驱动需求获取这件事，起因是某次内部工具改造。当时要做一个跨部门的业务系统，业务规则散落在七八个老同事脑子里，文档只有一份三年前的框架性说明。我们试过组织三轮访谈，录音十几个小时，最后整理出来的需求清单依然漏洞百出——漏了异常分支、漏了权限边界、漏了数据口径。后来我从那堆录音和文档里抽了几段喂给大模型，让它按“用户故事+验收标准+边界条件”的格式输出，结果让人吃了一惊：模型不仅把散落的规则串起来了，还主动提出好几个我们完全没问到的异常场景。

这件事让我意识到一个关键问题：需求获取的本质不是“记录”，而是“翻译”和“补全”。AI真正擅长的事情恰好是这两件——把模糊的自然语言翻译成结构化的表达，再根据已有的信息推断缺失的部分。本文想聊的就是我在这条路上摸索出来的方法论、系统架构思考，以及工程落地过程中踩过的坑。整个过程没有玄学，全是可以用在你自己项目里的具体做法。

需要说明的是，我这里讨论的“AI驱动需求获取”不是指拿ChatGPT帮你写一份需求文档就完事，而是指从原始素材（访谈记录、历史文档、工单、用户反馈、竞品说明）到结构化需求规格说明书的一个半自动化流水线。它解决的不是“写文档”的问题，而是“需求到底应该长什么样”的问题。

2. 需求获取这件事为什么这么难：三层失真模型

2.1 第一层失真：表达层——业务方自己也没想清楚

业务方表达需求和用户实际需求之间，天然存在一层损耗。最典型的情况是“解决方案型表达”和“目标型表达”的混淆。业务方说“我想要一个报表看每天的订单量”，这其实不是需求，是他自己想的解决方案。真实的需求可能是“我想知道哪些渠道的订单在下降，以便决定投放策略”。如果只按字面意思去实现报表，你只是做出来一个没有什么用的数据界面。

这种现象可以概括为三层失真模型：第一层是业务方脑中的真实需求（Need），第二层是他说出来的话（Wanted），第三层是我们理解后写下来的文档（Documented）。Need到Wanted的失真主要源于认知盲区、表达能力和沟通成本，Wanted到Documented的失真主要源于上下文缺失和专业术语的翻译偏差。

有意思的是，大语言模型在处理这种失真的时候反而有天然优势。训练语料里包含了海量的“直觉表达—结构化表达”对应关系，它能够在相当程度上把“我想要一个报表”拆解成“需要支持按渠道、按日期粒度筛选，需要突出异常波动，需要对接权限体系”——也就是从Wanted回推可能的Need，再向上映射成可验证的Documented。这一点在实践里比大多数刚入门的人预想的要可靠得多。

2.2 第二层失真：结构层——碎片化信息之间的隐含关联

需求获取的第二个难点是信息碎片化。一段访谈录音里聊到的某个业务规则，可能要到另一份工单里才能找到对应的异常场景，而连接二者的线索往往只是一句“上次那个情况处理得不对”。人在整理需求时主要依赖记忆力来建立这种关联，一旦信息量超过一定规模（我个人的经验值是超过20条独立素材），遗漏几乎是必然的。

AI在这里扮演的角色可以理解成一个“跨文本检索+关联推断”的引擎。它不是简单地做全文搜索，而是能够理解两条表面上不相干的记录描述的是同一件事——比如工单里说“有用户反馈退款后优惠券没退回”，访谈里说“退款流程需要支持券的返还”，AI能把这两条信息识别为同一需求的“触发场景”和“业务规则”两个侧面，合并进同一条需求条目里。这种跨来源的实体对齐能力是传统关键词检索完全做不到的。

2.3 第三层失真：验证层——没有人检查需求是否完整

如果说前两层失真还能靠经验弥补，第三层失真才是最隐蔽的陷阱：需求文档写完之后，没有人系统地检查它是否完整。通常的做法是发给业务方看，“您看这样对不对”。业务方扫一眼，说“差不多”，然后就进入开发——直到上线前才发现少了某个关键角色或状态。

AI驱动需求获取要真正发挥作用，核心就在这第三层：利用大模型的领域知识对生成的需求规格做“完整性审计”。比如一个订单退款流程，标准做法里至少涉及用户、订单状态、支付渠道、优惠券、库存、风控这几个维度的交叉。如果生成的文档里完全没有提到优惠券如何返还，审计模块就应该标记“疑似缺失”并主动提出问题。这不是靠灵感，是靠结构化的检查清单。

3. 方法论的四层拆解：信息蒸馏、追问生成、冲突识别、完整性审计

3.1 信息蒸馏：从原始素材到原子化语义条目

方法论的第一步是把原始素材蒸馏成原子化的语义条目。我在实践里定义了一个统一的中间格式，每条记录包含五个字段：主体（谁）、行为（做什么/发生了什么）、条件（在什么情况下）、约束（不能做什么）、来源（出自哪段素材）。

举个例子，一段访谈说“如果用户超过三个月没有登录，我们就觉得他可能已经流失了，但是也不能直接删掉他的数据，因为后面可能还会回来”。蒸馏出来的条目是：

• 主体：用户
• 行为：被标记为疑似流失
• 条件：超过90天未登录
• 约束：不得删除账号数据
• 来源：访谈记录-第3段

这一步看起来简单，但它是整个流水线的地基。蒸馏质量直接决定后续所有环节的上限。实操的时候，我建议不要一次性把一大段素材丢给模型让它“总结”，而是逐段处理，并严格要求按上述五字段结构输出。每段素材产生的条目数量没有限制，哪怕一段只有一条，保留原始来源引用也可以。我试过用传统LLM直接总结全文再抽取字段的方式，效果远不如逐段蒸馏，原因是长文本里的信息密度不均，模型容易把次要信息丢掉。

逐段蒸馏的Prompt我调整了很多版，最后稳定在这一版（示意）：

你是需求分析师。请从以下访谈片段中抽取所有业务规则和需求信息。 输出要求： 1. 每个独立的信息点输出一条记录 2. 每条记录包含：主体、行为、条件、约束、来源 3. 不要遗漏异常分支、边界条件和反例 4. 如果片段中含有情绪化表达、评价性语言，忽略即可 片段： {segment}

这里面最关键的一句是“不要遗漏异常分支、边界条件和反例”——大部分业务规则都藏在“但是”“如果……就”“除非……”这类句式里。我不确定是不是所有场景都适用这个五字段模型，但在我的项目里，这几个字段已经能覆盖绝大部分业务规则的表达需求。后续如果需要扩充，可以在“数据对象”和“状态流转”两个方向上加维度。

3.2 追问生成：识别信息黑洞并自动提出澄清问题

第二步是自动生成追问。这是整套方法论里最体现“AI驱动”价值、也是最容易被忽视的环节。传统的需求访谈里，分析师是靠临场经验来追问的——听到一个不熟悉的领域，第一反应往往是“这个地方我不懂，先记下来，后面再问”，一旦后面忘了就变成需求隐患。

AI的追问机制建立在第一步的信息蒸馏结果之上。具体的做法是把所有原子化条目打包，让模型以“需求评审人”的身份逐条检查，寻找信息盲区，输出澄清问题。我总结过比较有效的追问模板：

以下是当前整理出的需求条目。请以资深业务分析师的身份，检查这些条目中存在哪些信息盲区。 检查维度： 1. 条件是否完整（什么时间、什么角色、什么状态触发） 2. 异常路径（失败时怎么办） 3. 权限边界（谁能操作、谁能看到） 4. 数据来源（依赖哪些数据、口径是什么） 5. 与其他条目的关系（是否存在依赖或被依赖） 对每个盲区，输出一个具体问题。格式： 【相关条目】条目编号 【缺失信息】具体缺什么 【追问描述】你会怎么向业务方提问

实际效果相当惊艳。一次模拟项目里，我们对一份电商订单系统的访谈素材做了蒸馏和追问，模型生成了3个我们这些人类分析师完全没想过的问题：一个是关于黑名单用户在退款时是否适用同一流程，一个是关于订单拆单后部分退款如何分配运费，一个是关于客服人工干预订单状态后是否重新触发风控校验。这三个问题全部在后续的真实业务确认中得到了“需要明确规则”的答复——换句话说，任何一个被漏掉都会成为上线后的bug。

有一点值得提醒：追问生成环节产生的输出里，混着大量“凑数”的问题，比如“系统是否需要支持多语言”这种任何系统都需要的东西。所以在工程实现上不能只跑一遍就完事，要做过滤和去重，见后面的冲突识别章节。

3.3 冲突识别：让互相矛盾的需求显形

需求获取中的另一个高频问题是冲突：两个干系人对同一个需求给出了不同的反馈。比如运营说“用户注册后7天内要发满3条推送”，安全合规说“未经用户授权不允许发送任何推送”。真人处理冲突往往是开个会对齐，但对模型来说，识别冲突比生成内容更有技术含量。

冲突识别的做法是把蒸馏后的条目两两配对，用模型判断是否存在语义矛盾或约束冲突。这个判断不能只靠关键词匹配，因为冲突常常是隐含的。比如“7天内发满3条推送”和“未经授权不允许推送”这两个句子没有任何重叠词，但业务上是完全对立的。

我实现冲突检测的思路是两步走。第一步用embedding做粗筛，把语义相近的条目对挑出来（因为真正冲突的条目必然在某个维度上相近，否则连冲突的对象都没有）。第二步只对粗筛出来的条目对做精确判定，Prompt大致是：

请判断以下两条需求规则是否存在矛盾或冲突。 规则1：{rule1} 规则2：{rule2} 输出：冲突/不冲突/部分冲突 如冲突，请指出冲突的具体维度和建议的解决方向。

粗筛+细判的组合能极大压缩token消耗。一次处理300条规则，需要精确判定的组合从几万对降到几百对，成本和延迟都降了一个量级。

3.4 完整性审计：用领域检查清单补上“没人想到的那部分”

完整性盘点是我个人认为最接近“知识蒸馏”价值的环节。它的思路是让模型扮演一个熟悉该业务领域的架构师，结合领域常识对需求规格做系统性扫描，标记出缺失维度。

所谓领域检查清单，一个订单系统至少包括：用户生命周期、订单状态机、支付渠道矩阵、库存联动、退款逆向、优惠/促销、风控规则、异步通知失败处理、数据权限、审计日志。模型输出的需求规格如果只覆盖了订单状态和支付渠道，没有碰风控和审计，完整性审计就会提示疑似缺失。

它和追问生成的区别在于：追问是在蒸馏阶段对单条素材的进一步挖掘，完整性审计是在集成阶段对整份需求规格的体系化扫描。追问回答的是“这件事还有哪些没问清”，完整性审计回答的是“这一类系统通常涉及哪些维度，其中哪些维度完全没被涉及”。

这个环节我用下来最大的体会是：大模型在“系统性”和“体系化”方面的表现，远超普通人类需求分析师的直觉。一个新人分析师可能因为经验不足漏掉风控维度，模型基于训练语料中的领域知识几乎不会漏，除非这个业务领域本身太冷门。当然，冷门领域的情况后面还会展开讲。

4. 系统架构设计：把方法论变成可复用流水线

4.1 整体架构的五层划分与数据流向

方法论跑通之后，自然要思考怎么把它固化成一个系统。我搭建的参考架构分为五层：输入层、加工层、推理层、校验层、呈现层。每一层解决一类问题，层与层之间通过标准化的JSON结构通信，不搞“一步到底”的端到端黑盒。

输入层负责接入多源素材。访谈录音先用ASR转写成文本，历史文档做格式归一化（PDF、Word、Markdown都转成纯文本加段落切分），工单系统直接导出JSON。所有素材进入统一存储，并附带来源元数据。这一步最容易被忽略的问题是文本质量清理——ASR转写出来的文字满是重复词和语气词，不清理会严重污染蒸馏效果。我加了简单的规则过滤和长度截断，实际效果比什么都不做提升非常明显。

加工层负责把原始文本切成适合模型处理的段落。切分策略需要考虑语义完整性，不能简单按字符数硬切。我的做法是用段落边界+最大长度预算做动态切分，一段文本里如果超过窗口长度就从最近的句号附近断开。这个切分器大概300行代码就能搞定，但它决定了蒸馏的粒度，一定要提前想清楚。

推理层是核心，部署了一套可配置的DAG任务流。每个任务节点对应一个模型调用（蒸馏、追问、冲突检测、审计），节点之间通过共享的“需求工作台”数据存储交换信息。DAG的好处是两个：一是可以断点重跑——如果某一步Prompt出了问题，只重跑子图而不是整个流程；二是可以并行执行——比如多个段落独立蒸馏是天然并行的，用异步任务池调度就行。

校验层负责把模型的输出拉回到“可被人工编辑”的现实世界。包括结构校验（字段是否齐全）、去重合并（两条条目是否说的是同一件事）、用户确认（提供一段简洁的变更摘要让人点头或修改）。没有这层，AI输出的纯文本需求文档根本没法直接进入需求管理工具。

呈现层面向最终使用的人。我自己用的是“需求条目列表+差异对比视图+追问工单”三个界面。条目列表对应完整的需求规格库；差异对比视图用来做增量更新——同一份素材重新跑一遍流水线后，只显示新增和修改的条目；追问工单则是把模型生成的问题转成可分配的任务，由分析师逐条确认后发给业务方。

4.2 关键选择：为什么是DAG任务流而不是端到端Agent

第一次做架构选型时，一个很自然的诱惑是直接上Agent方案——把蒸馏、追问、审计全交给一个带工具的Agent自主完成。我一开始也尝试了这种方式，实际测下来发现三个问题眼前一黑：

一是不可控的成本。Agent会自己决定调用多少次模型，一次全量文档处理下来token消耗比我预期的贵了7倍，因为它在几个环节之间反复倒腾上下文。二是不可调试。某一步输出质量不行的时候，根本定位不了是哪个工具调用出了问题。三是输出格式漂移。Agent在不同任务之间切换时，偶尔会把输出格式搞混，导致下游解析崩溃。

DAG任务流的好处是每一步的输入输出都有明确的schema定义，每个节点独立部署、独立监控、独立回滚。这和工程上“显示优于隐式”的原则是一致的——可观测性比智能的灵活性重要得多。而且DAG本身不禁止智能，每个节点内部依然可以用“self-consistency”等技术提高单点质量，只是节点之间不搞黑盒调用。

4.3 数据模型设计：一张表装下所有需求状态

系统能否落地，很大程度取决于数据模型设计。我最后用的是“需求工作台”模型，核心表结构分三张：

• items表：原子化需求条目，字段包括id、来源素材id、主体、行为、条件、约束、状态（草稿/待确认/已确认/已废弃）、版本号。
• questions表：追问问题，字段包括id、关联条目id、检查维度、问题描述、状态（待提问/已提问/已回复）、回答内容。
• audit_results表：完整性审计结果，字段包括id、维度名称、状态（通过/缺失/疑似缺失）、说明、处置人。

这三张表之间通过关联id连通，配合简单的状态机就能支撑整个流水线的流转。

为什么强调状态和版本？因为在工程落地的真实场景里，素材总是源源不断地进来——今天加一份新的用户反馈，明天补一段业务访谈，后天改了一条促销规则。如果需求条目没有版本概念，增量更新就会变成噩梦。我在items表上加了version字段和变更日志表，每次流水线重跑只对比新增条目和变更条目，人工确认后写入新版本，老的版本留档可回溯。

4.4 模型选型与成本优化：不是越贵越好

这个架构跑起来的首要成本是LLM调用，优化空间也在这里。我的选型策略很简单：信息蒸馏这种重活、需要较强推理能力，用能力更强的商用大模型（一次处理约5000字素材，蒸馏出30～50条规则）；追问生成和完整性审计属于对领域知识有要求但对推理深度要求稍低的任务，用次一级的模型或同模型的低温度版本都过得去；冲突识别的粗筛阶段直接用本地embedding模型，完全不走大模型调用。

这是一个很典型的“分层算力”策略。全部用最强模型跑，单份需求文档的处理成本会高到没有工程可行性；全部用弱模型，蒸馏阶段的质量又上不去。测试数据对比如下：

这个表格是我在某个模拟项目上的实测数据，场景是电商订单域。不同领域的数据会有波动，但趋势是稳定的：旗舰模型的价值集中在“从非结构化文本中抽取语义”这一步，后期的判定类任务用经济档模型搭配良好Prompt设计就够了。

成本控制的另一个关键是缓存。同样的素材段落如果不做任何改动，蒸馏结果应该完全一致，所以我在加工层做了内容哈希，哈希命中直接返回缓存结果，跳过模型调用。在一次全量重跑实验中，缓存命中率一度达到61%，成本直接砍了接近三分之二。

5. 工程落地：从跑通Demo到上生产环境的六个坑

5.1 坑一：幻觉被无意识放大了

大模型生成的任何内容理论上都有幻觉风险，需求文档场景的幻觉后果尤其严重——有别于闲聊或文案，需求文档里的幻觉会直接变成开发的功能。我遇到的一个具体案例：模型在蒸馏二手车交易系统的访谈时，凭空生成了一条“过户手续费在300到800元之间”，而访谈原文里完全没提过金额。人类分析师一眼就能看出这是想当然的常识补全，但如果流程全自动化，这条就进了需求库。

应对方案是给每个原子化条目强制绑定“来源引用”。任何模型生成的内容如果无法从输入素材中找到对应支撑，就标记为“推断内容”，需要人工复核。这个要求必须在Prompt里写死，并且在校验层用大模型做“支撑性检查”——把条目内容放回去，问模型“以下内容能否从给定的素材片段中找到直接依据”，能力不够的模型做不准这一步，所以这块我用的也是旗舰档模型，但只对低置信度条目做检查，成本可控。

5.2 坑二：Prompt的“小版本更新”摧毁了下游兼容性

系统上了生产之后，一定会遇到优化Prompt的情况——也许是为了提高某类信息的召回率，改了一句引导语，蒸馏输出的格式多了一个额外的字段。听起来人畜无害，实际上整个下游解析器全部要跟着改。

踩过这个坑之后，我定了一条规矩：Prompt的输出格式必须用JSON Schema固定，并且任何Prompt变更必须做回归测试。回归测试的语料是固定在测试集里的20段标注过的素材，每次Prompt变更后跑一遍全集，凡是字段数量、字段类型、格式错误的输出都视为失败。这套测试方法不花多少成本，但能拦住绝大多数“改一句Prompt炸掉整个流水线”的问题。

5.3 坑三：领域冷启动的幻觉浓度飙升

通用大模型对热门业务领域的知识覆盖是相当好的，比如电商、内容社区、企业办公，蒸馏质量稳定。但如果碰到冷门领域——比如某种极其细分的工业设备维修流程——模型的领域知识就开始靠不住了，它会把其他领域的常识硬套过来。

解决靠“领域词典+示例注入”。我给系统加了一个域词典配置接口，每个项目启动时先让业务方提供30到50个术语定义和典型的规则示例，作为少样本示例拼进Prompt里。效果非常显著：在一个工业自动化设备维保项目上，接入域词典后蒸馏的准确率从71%提升到了86.7%。这个操作的原理不复杂，本质上是给模型提供了“落地锚点”，压制它的自由联想空间。

5.4 坑四：人工审核环节变成了新增瓶颈

AI跑得快，人在后边追不上。蒸馏一个小时的录音大概只要十分钟，但人工逐条审核产出的80条需求条目可能要花两个小时。整个链路的效率瓶颈从“需求梳理”转移到了“需求审核”。

这个问题的解法不是砍掉人工审核——那等于放弃质量底线——而是给审核员做好辅助工具。我在校验层加了一个“相似条目分组”的功能：模型输出的条目先做语义聚类，审核员按组看，一组条目往往共享同一个业务规则，确认一条就等于确认了一组。另外还把追问问题和对应条目做一对一的关联展示，审核员在检查问答时可以直接看到上下文，不用来回切换界面。这两招让单次审核耗时下降了约40%。

5.5 坑五：需求变更的追溯难度被低估了

系统上线时最爽的部分是跑通流程，但那只是开始。真正的考验在一个月之后：业务方提了一条新需求，说要改某个规则，你得能说清楚这条规则从哪里来的、影响哪些条目、之前为什么这么定。没有完整的溯源链路，需求管理就会退化成“又开了一场会，又改了版文档”。

我的做法是在每次流水线执行的开始打印一个Manifest文件，里面包含输入素材清单、模型版本、Prompt版本、生成时间、输出条目id列表。这条Manifest做两件事：一是作为审计日志，保证需求库的每个条目都能追溯到某次具体的执行；二是作为增量更新的基础，重跑后只对比同一个Manifest下的diff。这里面的“模型版本”和“Prompt版本”要做严格的版本管理，我用的就是简单的git tag，每次上线变更必打tag。

5.6 坑六：误把AI输出当需求基准

最后一个坑比较微妙——团队用顺了之后，会越来越依赖AI生成的条目，甚至把AI的判断当作业务权威。这是最危险的心理状态。AI生成的完整性审计报告里说“风控维度疑似缺失”，业务方看到后说“那加上吧”，其实业务方当时的想法是“加上AI说的总没错”——但AI的判断只是“基于常见模型推演”，不是对真实业务流程的确认。

所以我在系统里给所有非直接引用的内容加了明确的“置信度”和“证据强度”标识。蒸馏条目的置信度分为“素材直接支持”“素材隐含推断”“模型常识补全”三档。凡是第三档的内容在界面上用醒目颜色标注，当批次生成的三档内容占比过高时，系统还会自动给出预警：“本批次推断内容占比超过30%，建议人工复核后再进入需求评审流程。” 这套机制确保AI永远是辅助角色，它帮你看到盲区，但决策永远由人来做。

6. 一个端到端的模拟推演：从访谈录音到需求清单

为了便于理解，我完整走一遍某模拟项目X的例子。项目背景是给一家二手乐器交易平台做“卖家入驻”模块升级。素材包括：两段访谈录音（约40分钟）、一份旧的入驻规则说明、六个客服工单。

第一步，ASR转写后清洗，得到约8000字的文本，按段落边界切成23段。

第二步，逐段蒸馏。旗舰档模型产出了64条原子化条目，人工复核后保留了59条，合并掉重复的，最终52条。这52条里清晰地勾画出了核心链路：注册申请、资质审核、乐器信息录入、押金缴纳、上架规则、订单处理、售后责任。

第三步，追问生成。问题集落下来一批盲区问题，其中比较关键的有：“二手乐器交易中，如果买家收到货后认为成色与描述不符，是平台客服介入还是卖家自行协商？”“乐器在物流过程中造成损坏，责任怎样划定？”“卖家关闭店铺后，已发布的商品和待处理订单如何处置？”这三个问题看似基础，但原来的素材里真的没有现成答案，属于“理所当然地以为已经有规则了，实际上没有”的盲区。

第四步，冲突识别。发现了一条冲突：旧规则文档里写“卖家需在用户下单后48小时内发货”，但访谈里运营提到“部分高价乐器需要买家确认运输方式后再发货”。模型标记为“部分冲突”，建议的解决方向是“按商品价格阈值区分发货时效”，这个建议被业务方采纳后收编为新规则。

第五步，完整性审计。审计结果列出了一堆缺失维度，包括“卖家黑名单机制”“重复上架检测”“隐私数据脱敏（买家收货地址仅对卖家部分可见）”“争议订单的资金冻结规则”等。其中“资金冻结”这个缺失点后来在业务确认时被认为是真实存在的流程漏洞——之前做人工调研的时候完全没人想到。

整个流程从原始素材到可评审的需求规格，耗时约4个小时（包括人工审核），而纯粹人工做同样的事情大概需要两天，还不包括思考盲区的时间。这个差距不是“快了三倍”的量变，而是“让人有时间去思考那些深层次问题”的质变——人工审核者不再疲劳地抄写和整理，而是把精力全部投入到判断和决策上。

7. 提示工程之外的工程经验：我如何评估整条流水线的质量

7.1 离线评估集的构建方式

前面提到了回归测试，这里展开说一下离线评估集的搭建方法。我为这个系统做一个专门的评估集，包含8份模拟素材，覆盖电商、教育、企业服务、工业设备等不同领域。每份素材都有人工标注的“标准需求条目”，作为ground truth。

离线评估的核心指标是三个：蒸馏精确率（模型产出的条目里有多少与人工标准条目匹配）、召回率（人工标准条目里有多少被模型找到）、追问有效性（模型提出的问题里有多少在真实场景中被确认具有业务价值）。

这三个指标的评估不能全靠自动比对，因为语义等价的标准难以自动化。我的做法是先让模型自动打分（assistant-as-judge），再由人工抽检20%的结果做二次确认。最终跑下来蒸馏的精确率通常在78%-92%之间，在接入领域词典和少量样本之后，能够稳定到85%以上，这个水平已经能够支撑高效的人工审核。

7.2 一个你没想过的问题：温度参数的重要性

大模型输出有个微妙的参数叫temperature，大多数人在做内容生成时都习惯性调成0.7或更高，觉得这样更有创意。但需求获取这个场景，我强烈建议把temperature设为0或接近0。

原因是需求文档场景追求的是“确定性和可复现性”——同一段素材今天跑和明天跑，产出应完全一致。高温度下模型的输出会漂移，在蒸馏环节体现为条目措辞的微变，在冲突识别环节体现为对“冲突/部分冲突”的判定摇摆不定，这对后续的人工审核是巨大的折磨。

我在系统中把蒸馏和冲突细判的温度都固定为0.1，只要Prompt不变，输出基本稳定。完整性审计这个环节可以适当放宽到0.3，因为它的输出是给人提供思路的“盲区提示”，不是强规则判定，一点随机性反而有助于生成更多样化的思考角度。

7.3 细粒度版本管理与发布节奏

系统里所有的模型Prompt都纳入版本管理，文件命名遵循语义化规则：distill_v2.3.0.json、expanding_questions_v1.2.0.json。每次变更都要求附带change log。

另外一个务实建议是给“Prompt是否已应用”加一个运行时的开关。我在系统里维护了一份当前的Prompt版本清单，DAG的每个节点执行前先查自己的版本是否和全局一致，不一致时打印警告。这个机制防止了一种很尴尬的线上事故：修改了Prompt但在配置中心忘了推送。

7.4 一个方向：把历史评审意见做成“经验回放”

系统用了一段时间后，我发现一个潜在的数据金矿：人工审核员的每一次修改操作其实都在“矫正”模型的输出。比如审核员把“发货时效”从“24小时”改成了“48小时”，这代表模型原来的推断有误或者素材本身发生了变更。把这些修正样本收集起来，可以作为下一轮Prompt迭代的few-shot例子，也可以用来评估“流水线是否存在系统性偏差”。

我做了个很朴素的实验：把同一份旧素材用新版本的Prompt重新跑一遍，对比审核员上次修改过的条目和这次模型的输出，统计“模型是否自动修正了上次犯过的错”。结果发现，在加入历史修正样本后，同一类型的错误重现率有下降，但也有个别错误反复出现——这说明模型并不是每次都能“记住”教训，还需要在Prompt里更强力地强调特定约束。这个方向我还在摸索，目前看来是可行的，但需要足够多的标注积累，不是一朝一夕能见效的事。

8. 适合哪些团队跟进以及几条落地路线建议

8.1 团队规模与技术门槛

可能有人会担心这套体系需要多牛逼的工程团队。我的判断是：初级版完全可以由一个懂Prompt工程的全栈工程师独立搞定，DAG用现成的调度框架（比如Airflow或自建简单任务队列），模型调用封装成两层，存储直接用PostgreSQL，界面用低代码工具也能应付。

真正需要更团队化投入的是数据治理环节——领域词典维护、评估集标注、历史修正样本收集。这些不是一次性的活，需要持续投入人力，但工作量并不大，适合业务分析师或者QA团队兼顾。如果你所在的公司本身有“需求管理岗”，这些人恰好就是AI驱动需求获取系统的天然维护者。

8.2 落地节奏的三阶段建议

我建议不要一上来就追求全自动化流程。可以分三个阶段渐进：

第一阶段，人机协同的“辅助生成”模式。模型产出初稿，人工全部过一遍并修改。这一步跑1到2个真实项目，重点目标是让团队建立对模型输出的信任边界——知道AI擅长什么、在哪里会出错。

第二阶段，“结构化工单”模式。在人工确认环节加上前面的“相似条目分组”辅助工具，审核效率上来了，流水线可以开始承接更多并发项目。此时可以开始积累修正样本，进行小范围的Prompt迭代实验。

第三阶段，进入“增量审计”模式。流水线跑过的历史项目越来越多，可以考虑对历史需求清单做周期性重跑——把新版本Prompt应用在老素材上，看能否发现之前遗漏的需求点。这是我目前觉得最有想象力、但在真实运营中还比较少见的方向。

8.3 一个底线原则

无论系统怎么演进，请坚持一个底线：所有最终进入需求规格书的内容，必须经过真人确认。AI可以极大地帮助我们发现盲区、压缩整理时间、提升一致性，但不应该拥有“最终决策权”。需求获取终究是业务问题，技术只是让你把有限的人力放在真正有价值的事情上。

9. 写在最后的操作心得

从第一次拿起录音素材做实验到现在把这套东西跑成可复用的流程，最大的感受是：AI驱动需求获取真正解决的，不是“多快写出文档”的问题，而是“让完整性和一致性变得可以被系统性地保证”。以前靠人的记忆和经验来对抗模糊性，现在可以用结构化的方法把模糊性显性化、把盲区逐个标记出来。

最后分享一个很实用的小技巧：如果你的业务方和产研团队暂时接受不了太复杂的系统，可以直接用最简单的方式体验这套方法论的价值——找一段历史的项目录音或旧需求文档，丢给一个现成的大模型，只加两句话的指令：“以需求分析师的身份提取业务规则，注意异常分支和边界条件，输出条目标明来源”。跑一遍，你会立刻看到平时开会漏掉的东西到底有多少。

这个方向上还有大量可以深化的事情，比如把需求条目直接映射成测试用例、从历史工单里挖掘质量事件反推需求缺陷、甚至利用需求库里沉淀的领域知识反向训练一个项目专用的小模型。路还很长，但第一步——把需求获取从“脑内加工”变成“可追溯的信息流水线”——已经值得每个团队尽早迈出去了。