需求变更率直降40%：我让LLM参与用户故事拆分的180天实录

每次需求变更都像在代码库上动大手术，根子其实在一开始就没说清楚

去年秋天我们团队接手了一个内部采购系统的重构项目，头两周就崩了。产品经理给我扔过来一份“需求文档”——其实就是三页PPT加上六封邮件里的截图。最离谱的一句是：“管理员应该能方便地处理审批。”我当时盯着屏幕愣了好一会儿，什么叫“方便地处理”？是批量通过还是单条操作？超时自动驳回算不算方便？要不要邮件提醒？我把这些问题抛回去，产品经理自己也说不清楚，只是重复“就是让用户觉得好用”。

没办法，我们按自己的理解拆分用户故事，估了点，画了原型。第一轮评审，业务方说“你们理解偏了，我们不是这个流程”。第二轮，他们发现漏掉了财务审批的特殊逻辑。第三轮，法务跳出来说某些操作必须有留痕并且不可篡改。每次变更都像在代码库上做开胸手术——实体模型要改，API契约要调，前端表单得重新排版，连数据库迁移脚本都得回滚重跑。三个月下来，我统计了最初的27个用户故事，有16个在中途被修改过核心验收条件，最严重的一个故事“审批流程配置”前后改了5次，最后一次直接推翻了前四次的数据库设计。

说实话我不是没反思过。我们一直以为需求变更是业务方善变的锅，但数据告诉我，超过一半的变更根源是初始需求本身就模糊、矛盾或者缺失边界条件。业务方描述需求用的是自然语言，自然语言天生就带着歧义。“系统应该快速响应”中的“快速”到底指200毫秒还是2秒？“权限应该灵活配置”里的“灵活”到底允不允许一个用户同时属于多个角色？这些词在需求评审会上经常被一带而过，双方都觉得“到时候再说”，而这个“到时候”就变成了开发中段、测试阶段甚至上线前夜的灾难。

更让我头疼的是，作为开发，我们往往没有足够的时间去逐条逼问业务细节。产品经理夹在中间，一方面要应付业务的催促，另一方面又害怕对技术承诺过度。于是我们接到的永远是一个“看起来合理”但一经推敲就千疮百孔的故事列表。我记得最清楚的一次，一个用户故事叫“导出报表”，验收条件只写了“能够导出最近三个月的数据”，但没有指定格式、没有说明是否包含已删除的记录、没有提性能要求。结果我们做了一个CSV导出，上线后业务方拍桌子说他们要的是带格式的Excel，且必须包含审批历史，数据量一上来导出耗时两分钟，他们又投诉“太慢”。这个故事前后补了三个补丁，代码里塞满了if导出类型判断，最后连我自己都不想维护。

我私下和几个资深同事聊，大家普遍觉得需求分析是整个开发生命周期里最被低估的环节。我们花大量精力在编码规范、自动化测试、CI/CD流水线上，但需求那块基本还是靠“人传人”和会议记录。有人提议引入DDD的事件风暴，但我们团队只有八个人，业务领域也不算深奥，搞一整套领域建模反而容易过度设计。也有人想用形式化方法写需求规约，但业务方根本看不懂，沟通成本只会更高。那个时候我就开始琢磨：有没有一种方法，能利用我们已经很熟悉的LLM能力，在不大幅改变现有流程的情况下，把需求里面的模糊点提前揪出来？

我给需求分析加了两层AI：一层翻译官，一层杠精

我的核心思路其实很简单。大语言模型在处理自然语言方面本来就有优势，它不怕读长文本，也不会遗漏隐含矛盾。我想让它做两件事：第一，把乱七八糟的原始需求转化成结构化的、可测试的场景描述；第二，像挑刺的评审一样，逐条检查这些场景里有没有歧义、遗漏或逻辑冲突。这就像给每个用户故事配了一个永不疲倦的翻译官和一个专门抬杠的质量门卫。

最初我想用一个超长的prompt一把梭：把所有相关需求文档、历史聊天记录、已知的约束条件一股脑儿扔进去，然后让LLM直接给出Gherkin格式的验收场景。结果当然翻车了。GPT-4虽然能理解意图，但给出的场景经常过于“完美”——它会替我脑补我根本没提到的业务规则，比如自动假设“审批驳回后必须通知申请人”，但我们的业务里某些场景下驳回是静默的。这比模糊需求更危险：一个看起来完整、实则包含假知识的场景列表，直接误导开发，等测试阶段才发现，成本更大。

所以我后来把流程拆成了几个明确的阶段，每个阶段用不同的prompt，组成了一条提示链。第一个阶段叫“需求提取”，我只让LLM做信息梳理，不准它发挥。我给它输入的是原始需求文本、会议纪要还有业务方在群里发的零散要求，要求它输出一个结构化的“需求要素清单”，每一项都必须标注来源句子和出处。如果遇到模糊的表述，它不是直接消歧，而是用一个特殊标记【待澄清】列出所有可能的解释。比如遇到“方便处理审批”，它会输出：“操作效率：支持批量审批？还是单条快速审批？【待澄清，来源：原始需求第三段】”。这个阶段绝不生成最终内容，就是忠实抽取并标记模糊点。

第二阶段我称之为“场景展开”。这步我才会让LLM基于经过产品经理确认澄清后的需求要素清单，生成Gherkin格式的场景。但这里的prompt我塞进去了几十条我们团队过去踩过的坑作为few-shot示例。比如我告诉它：“When ‘选择批量审批’场景，一定要包含When用户选中0条数据的边界”，“When导出报表，如果时间范围跨越了数据库归档的分区点，系统应该提示数据可能不完整而不是直接报错”。这些例子全部来自真实的生产事故，LLM学习之后，生成的场景会天然带上一股“吃过亏”的味道，主动补充那些业务方可能想不到的边界情况。

第二阶段的输出还不是终点。关键在第三阶段，我加了一个“AI评委”。这不是什么复杂的多智能体系统，就是另一个独立的LLM调用，我给它设定了严格的人设：你是一个以挑刺为荣的需求分析师，不允许有半点恭维，你的唯一目标是找出逻辑漏洞和矛盾。我把第二阶段的Gherkin场景和原始需求清单一起交给这个评委，要求它逐条审查，必须指出至少一处潜在问题，哪怕没有问题也得找个可能的歧义。审查结果会生成一个报告，分成三类：致命矛盾（同一个概念前后定义不一致）、边界缺失（缺少空值、超时、并发等场景）、歧义风险（一个描述可以被两种合理方式解读）。报告里的每一项都会标记对应的Gherkin场景行号，方便我们追溯。

这个流程落地之后，产品经理的角色发生了变化。她不再需要自己凭空想测试场景，而是拿着LLM生成的场景和我们开发一起逐条过，AI评委提出的质疑反而成了双方沟通的起点。举个例子，有一次“审批超时自动驳回”这个场景，评委指出原始需求里只说“超过24小时未处理视为自动驳回”，但没定义24小时是从哪个时间点开始算——是提交时间还是分配审批人的时间？如果中间包含了法定节假日怎么办？产品经理看到后立刻去找业务确认，结果是节假日要顺延，起算时间是任务被第一个审批人接收的时间。如果这个问题留到开发阶段，我们大概率会实现成“提交后24小时”，然后在上线后接到一堆投诉，再紧急修数据，再改代码。现在它提前三周暴露了，代价只是一场十五分钟的对齐会。

提示链从“能跑”到“能用”，我调了47版prompt才知道什么叫边界注入

我最开始把提示链设计得特别“干净”——每个prompt只包含最少必要指令，因为担心指令太长会分散LLM注意力。但运行了一周后发现，干净的prompt产出的场景也特别“干净”，干净到脱离实际。比如“用户登录”场景，它只会写“Given 用户已注册， When 用户输入正确用户名和密码， Then 登录成功”，根本不考虑登录失败次数限制、验证码失效、账户被锁定这些我们系统实际存在的约束。这些约束其实写在另一份安全需求文档里，但LLM在第一轮信息提取时，如果不明确告诉它需要关注跨文档的约束关联，它就会漏掉。

这就逼着我重新设计第一阶段的prompt。我加了一条铁令：“当提取需求要素时，必须同时审查所有已知的技术约束文档和非功能需求列表，如果某个功能与安全、性能、审计等约束有交集，必须在要素清单中以【关联约束】字段显式列出。”同时我给它塞了几个反例：不要像上次那样，把“导出报表”的性能要求漏掉，因为性能要求文档里明确写了“所有导出操作必须在15秒内完成”。这些反例比正例效果还好，LLM看到自己之前犯过的错，后续输出就警惕了很多。

第二阶段场景展开的prompt修改是最痛苦的。最初的版本我要求它“生成详尽的Gherkin场景”，结果它真的生成了一大堆，但60%都是废话场景，比如“用户打开页面，页面正常显示”这种不带来任何测试价值的“健康检查”场景。我后来在prompt里加了优先级定义：P0场景是核心业务路径和异常路径，P1场景是边界值和权限交叉场景，P2场景才是UI展示细节。并且要求每个场景必须回答“如果失败会有什么后果”这个问题，否则场景无效。这个约束让场景数量从平均每个用户故事15条降到了6-8条，但条条都能触发真实BUG。

最关键的prompt改动是关于“领域知识注入”。我们团队维护着一份架构决策记录（ADR）和一份领域术语表，里面定义了像“待处理”“处理中”“已关闭”这些状态的生命周期规则。早期LLM完全不理解“已关闭的任务不允许任何修改”这条铁律，生成场景时经常会写出“When 用户修改已关闭的审批单”这样的场景，AI评委也会认真审查，反而浪费算力。我后来在prompt里直接嵌入了一种半结构化格式：

【领域规则】
1. 审批单状态机：DRAFT -> PENDING -> APPROVED/REJECTED -> CLOSED.
2. CLOSED状态下禁止任何修改操作，包括评论和附件上传。
3. 所有删除为逻辑删除，必须在数据库记录操作人、时间和原值。

这些规则不是让LLM去理解，而是作为硬性前置条件，要求它在生成任何场景时都必须与这些规则做交叉验证。这个做法让第二阶段生成的场景准确率从最开始的55%（我自己人工抽查50个故事得出的）提升到了约85%。剩下的15%主要是业务方自己都说不清楚的特殊场景，那需要人介入也合理。

AI评委的prompt我也迭代了不少轮。最开始我只让它“找出矛盾和歧义”，它经常给我返回一大段散文式的评论，很难直接对应到具体代码修改。后来我把它输出结构强制为JSON，并要求每个问题必须包含“问题类型”“关联Gherkin场景行号”“违反的具体规则或矛盾描述”“建议澄清方向”四个字段。我还给它加了“举证责任倒置”的压力：如果它没有发现任何问题，必须输出一个字段“confidence_score”并附上理由。压力之下，评委变得更敏锐，有几次它甚至发现了一个我自己都没注意到的矛盾：同一份文档里，关于“用户角色”，前面说是基于RBAC模型，后面举的例子却暗示了ABAC属性权限，两种模型在实现上完全不同。如果等做到授权模块才发现这个问题，架构都得推倒重来。

整个提示链我们前前后后改了47版，大部分改动不是大结构，而是针对我们特定业务场景的微调。最难的不是写prompt本身，是持续维护那些“领域知识片段”，并确保所有团队成员都在用同一套最新的prompt模板。后来我把这套提示链做成了内部CLI工具，产品经理用命令就能跑，生成的场景自动归档到Confluence，AI评委报告直接发到Slack对应频道。这个工具化过程也是对抗“prompt腐败”的关键——口头传承的prompt一定会走样。

需求缺陷密度从3.2降到0.8，但评审会时间反而多了30%，我为什么觉得值

流程跑了三个月后，我拉了一组数据，自己也吃了一惊。我们统计了每个用户故事在开发完成、进入测试阶段后发现的“需求相关缺陷”（也就是如果一开始需求写清楚就能避免的问题）。改造前，平均每个故事在测试阶段会触发3.2个需求缺陷；改造后的三个月，这个数字掉到了0.8。需求变更率方面，我们把“任何导致故事验收条件修改、新场景增加或原场景删除的改动”都算作变更，对比去年同期，变更率从45%降到了27%，降了18个百分点，说40%其实是“需求变更次数减少了40%”的简化说法（从每迭代12次降到7次左右）。

但是有一组数据让我当时有点犹豫——用户故事评审会议的平均时长从45分钟增加到了70分钟。产品经理甚至私下找我，说“现在故事卡片上东西太多，业务方看着眼花，讨论得更久”。我差点被这个数据带偏，差点要简化LLM输出。但多看了几周数据后我发现，虽然评审时间变长了，但整个迭代的总缺陷修复时间从人均每周8小时降到了3.5小时，而且上线后的紧急补丁数量从6个降到了1个。评审阶段多花的30%时间，换来的是编码和测试阶段成倍的时间节省，这笔账完全划算。更重要的是，之前那种“开发到最后一天才发现需求理解有误”的窒息体验几乎消失了，团队焦虑感明显下降，大家不再害怕周五下午接到产品经理的“需求微调”电话。

我还专门做了一个定性分析，抽查了30个被AI评委标记为“致命矛盾”的故事。如果这些矛盾没发现，按照我们团队的平均修复成本计算：在需求阶段修复只需要30分钟讨论澄清；编码阶段发现需要改动模型和接口，大概2人-日；测试阶段发现不仅要改代码还要重跑回归，3-4人-日；如果流到生产环境，那修复加上数据修复和道歉邮件，起码10人-日起跳。这30个故事如果在测试阶段才暴露，总成本至少90人-日，实际上我们只多花了大约15小时的额外评审时间。这个ROI数据我后来拿给CTO看，他当场批了把AI需求分析工具从我的自研项目转成正式的技术中台服务。

当然，这套方案不是银弹。它极度依赖初始输入的上下文完整性，如果业务方给的原始材料太少，LLM编出来的东西会很危险。所以我们硬性要求产品经理在启动AI分析前，必须完成一个简短的“需求上下文检查单”，至少填写功能目标、用户角色、核心业务流程步骤、已知约束四个字段，否则工具会拒绝执行。另外，LLM对数字和时效的推理依然不靠谱，有一次AI评委坚持认为“超过30天自动归档”与数据保留政策“保留180天”矛盾，但实际上归档不等于删除，只是标记加移到冷存储，产品经理不得不手动驳回这条“误报”。我们后来给评委加了“误报反馈”机制，定期用它纠正自己的判断倾向。

现在这套做法已经在公司内另外两个项目组试点，有个做移动端应用的组长跟我反馈，他们最大的收获反而不是需求澄清本身，而是LLM生成的Gherkin场景可以直接导入自动化测试框架Behave，做BDD。以前他们最头疼的就是写.feature文件，现在从需求分析到可执行测试用例的链路几乎可以一键打通，测试同事参与得更早了。这倒是意外的收获，我一开始根本没往测试自动化那个方向想，只是一心想治需求变更的顽疾。

回想这半年，我最深的体会是：AI在需求分析阶段的价值不是替代人类的判断，而是把“隐性知识”和“潜在矛盾”用足够高的信噪比逼到台面上来。以前我们依赖个别资深工程师的经验来嗅探需求里的坑，现在相当于把这个能力给制度化、可复制化了。当然，代价就是你需要投入精力维护提示链和领域规则库，这本质上是一种新的“需求知识资产”管理方式，没有捷径。但比起在凌晨三点被生产事故电话吵醒，我还是宁愿多花些时间打磨那些prompt。