先说结论：大模型做需求工程，现阶段是"强力助手"，不是"自动化的需求工程师"。 这句话不是我说的，是德国布伦瑞克工业大学2026年3月发在Elsevier《Digital Engineering》上的一篇论文用实验数据验证出来的。

我为什么突然聊这个话题？因为过去大半年，团队在VP系统里持续地让大模型参与需求管理的各个链路——写用户故事、提取需求、做变更影响分析。有些环节确实舒服了，有些环节翻车翻得相当难看。看到这篇论文的时候，感觉里面测出来的数字和我们体感特别对得上，就决定认真读一遍，然后结合自己的实践写点东西。

这论文到底测了什么

作者Armin Stein团队设计了一套五阶段方法，核心思路是横向对比：同一个任务、同一份输入，跑五个不同的模型，再套上不同的提示策略，看谁行谁不行。

五个模型：ChatGPT-4o、Claude Sonnet 4、Gemini 2.5 Pro、DeepSeek V3、LLaMA Scout。

三个任务，分别代表需求工程里三种典型能力：

任务	考察能力	对应我们日常里的什么
需求提取与公式化	分析型——从一段话里把需求捞出来、归类、规范化	开完会整理需求条目
用户故事生成	创造型——把散乱的信息变成结构化的故事	在VP里写User Story
BDD建模	结构推理型——把需求变成SysML的块定义图	建追溯关系、画模块图

输入材料是一段虚构的利益相关方对话，里面埋了35条需求（15条功能性、20条非功能性），故意写得含糊——有隐性需求、有矛盾、有模糊表述。这个设计我觉得很真实，实际工作中谁的需求是排列整齐给你用的？

提示策略方面测了：零样本、少样本、扩展上下文三个阶段；思维链、自我精炼（Self-Refine）、验证链（Chain-of-Verification）三种技巧；还加了一个简化版的多Agent配置（三个角色：提取员、故事写手、建模师）。

评估指标：需求提取和BDD建模用精确率/召回率/F1分数对标人工制作的Ground Truth；用户故事用INVEST六维模型打分（独立性、可协商性、价值、可估算、短小、可测试），满分12分。

结果说实话有点意外

用户故事：全员高分，最让人放心的一项

这个任务上几乎所有组合都拿到了归一化0.8+的分，最高的到了0.92。意思是：不管用哪个模型、不管提示写得多粗糙，生成的用户故事在结构和语言质量上基本都过关。

我们的体感： 确实。让模型帮写用户故事是目前最稳的用法。在VP里把一段会议记录或者邮件丢进去，让它按"角色-任务-收益"的格式拆故事，出来的东西格式没问题，语言通顺，验收条件也能写。

但有一个小坑我踩过：AI写出来的故事偏长。INVEST里的S（短小）这一项，它经常只拿1分（满分2分）。故事本身没问题，但粒度太粗，后面拆任务的时候还得人工切。所以我们的习惯是AI生成后，需求负责人要做一道"粒度检查"，把过长的故事拆开。

需求提取：一半对一半错，隐性需求基本靠边站

35条需求，模型平均只能正确识别并公式化大约50%。最扎心的是：

• 零样本提示下（就是不给任何例子直接问），GPT-4o识别出了26条，但只有15条是对的——剩下11条是它自己"脑补"出来的。精确率0.57，召回率0.43。
• 到第三级提示（给了完整上下文加结构化示例），精确率才跳到0.85，公式化精度到0.81。F1从0.35拉到0.62。

隐性需求是共同的盲区。 论文反复强调：除非需求在原文里用了"系统应该……""必须支持……“这类显式措辞，否则不管什么模型、什么提示策略，都抓不住。那些"言外之意”、“业务常识”、“行业惯例”——AI看不见。

我们的体感： 完全一致。实际让AI提取需求的时候，最靠谱的是"显式需求"——就是白纸黑字写出来的那些。"领导说了一句’这个功能好像不太方便’“这种，AI基本无法从中提取出可操作的需求条目。所以需求获取阶段的核心工作——跟业务方反复确认"你刚才说的是不是还意味着……”——AI替代不了，人不能退。

另外一个坑：AI提取出来的需求必须逐条跟原文核对，不能直接导入VP。那些"脑补"出来的11条需求如果混进去，后续追溯链就被污染了。我们的做法是AI提取后标"待确认"状态，人工逐条过，确认的才进入正式需求池。

BDD建模：基本不能用，别想了

这是最让人清醒的一项。任务要求模型根据文字描述生成SysML的块定义图（BDD）——子系统、模块、它们之间的组合关系、聚合关系、属性定义。

结果：

• 识别顶层"块"（子系统/模块名）还行，某些组合精确率到1.0
• 但识别块与块之间的关系全面崩溃——大部分组合的关系F1在0.14左右，有的直接是0
• 提示阶段从Stage 1到Stage 3，几乎没有提升，说明你给再多上下文也救不了它

我们的体感： 让大模型画个简单的架构图，它能给你生成一个"看起来像"的图。但你仔细一看，模块之间的连线关系是错的。它知道"这块包含那块"，但搞不清楚"是组成关系还是引用关系还是依赖关系"。

所以如果你团队在用基于模型的工程方法（MBSE），想靠AI自动建追溯模型、自动生成SysML——现阶段不现实。需求到测试用例的追溯，在VP里还是得靠人手动建立或者用规则引擎辅助。

提示策略：一个很实际的建议

三种提示技巧的效果排序很明确：

策略	效果	大白话
验证链（Chain-of-Verification）	最稳，提升精确性和一致性	给模型一套"检查清单"让它自检
自我精炼（Self-Refine）	迭代反馈后质量上升，ChatGPT效果最好	让模型自己挑错再改，两三轮比较合适
思维链（Chain-of-Thought）	没有上下文支撑时基本没用	"一步步想"这个指令本身不带来额外信息

但比技巧更重要的是提示的阶段：零样本→少样本→扩展上下文，这个升级带来的提升幅度远大于在同级别内切换技巧。

翻译成日常操作：别花太多时间研究prompt技巧，先把输入信息给全了。 你在VP里写需求的时候把背景、约束、关联文档都挂上，再让AI去处理，效果远好于在一个信息稀薄的输入上玩花活。模糊的输入只会产出模糊的结果。

哪个模型最稳？

论文里ChatGPT-4o在几乎所有任务上都是表现最一致的。不是说它单项最强——某些任务上Claude或Gemini可能更突出——但它是唯一一个在三种任务、多种提示策略下都没有"翻车"的模型。

其他几个的特征：

• DeepSeek V3：精确度不错但语言流畅性稍弱，生成的故事有时候"像翻译腔"
• Gemini 2.5 Pro：多模态能力有优势，但在层次结构识别任务上反而下降了（额外示例干扰了它）
• LLaMA Scout：整体中等偏下

注意： 大模型更新太快，今天的最优配置明天可能就变了。而且论文只测了五个模型的Web API版本，没做微调。这个结论是"2026年3月的快照"，不是永恒真理。

几点个人思考

结合我们自己在VP里用AI辅助需求管理的实际经验，我总结几句可能不太"正确"但很真实的话：

1. AI最该干的活是"初稿生成"，不是"最终定稿"。 用户故事生成得分最高，说明让AI帮你起个草稿是靠谱的。但草稿要过人工关。我们的习惯是：AI生成的故事直接进VP的"草稿"状态，不会自动流转到"已确认"，必须需求负责人review通过才算数。

2. 需求提取要做好"漏"的心理准备。 50%的正确率意味着你扔进去35条需求，它可能只帮你找到17-18条，还会混进几条不存在的。AI提取的需求必须逐条跟原文核对，不能直接导入系统。

3. 追溯建模现阶段别交给AI。 BDD的结果说明结构化关系抽取远没成熟。需求到测试用例的追溯，在VP里还是得靠人手动建立。

4. 模型的价值在于"省打字时间"，不在于"替你思考"。 它帮你把一段会议纪要变成结构化的需求条目，省的是格式化的功夫。但"这个需求到底要不要"“优先级怎么排”“跟那个需求有没有冲突”——这些判断还是人的活。

5. 团队比工具重要。 论文的方法论本身是好的——五阶段、可对比、可复现。但方法论的价值取决于团队愿不愿意按它执行。如果团队里没人认真做需求评审、没人跟踪追溯完整性，你上什么AI工具都是白搭。

最后说句冷静的话

这篇论文用的是虚构的足球App场景，35条需求，规模不算大。作者自己也承认：没有做独立第三方验证，Ground Truth是作者自己做的，INVEST评分也是一个人打的。

但它的价值在于方法本身——你完全可以拿同样的框架，换成你们项目里的真实需求跑一遍。不需要五六个模型都测，挑你们团队实际在用的那两三个就够了。关键是建立"这个模型在这个任务上到底行不行"的量化认知，而不是凭感觉。

AI做需求工程，工具越来越强是事实。但需求质量的根本保障，始终在"对业务的理解"和"跟人的沟通"上。这两样，大模型暂时替代不了，短期内也替代不了。

---

参考论文：Stein A., Mirzai A., Axmann J., Vietor T. “Integrating the capabilities offered by large language models into the requirements engineering process.” Digital Engineering, Vol.10, 2026. DOI: 10.1016/j.dte.2026.100098. CC BY-NC-ND 4.0许可。

本文中的实验数据均来自该论文原文；"我们的体感"部分为基于一般需求管理实践的个人观察，非特定项目经验。