最近带团队搞了一套需求追溯系统底层用的是LLM。做下来之后发现这事儿既没那么神也没那么难。写篇东西记录一下。一、我们为什么想做追溯先说说背景。我们团队以前做需求管理基本就是靠人肉维护。需求文档、设计文档、测试用例全在不同地方追溯关系靠Excel或者VP手动填。一开始人少还行后来项目复杂了问题就多了。最头疼的三个问题一是追溯断了。需求改了一版对应的测试用例没跟上上线后才发现漏测了。有一次一个接口参数改了类型测试用例还是旧的差点造成线上事故。二是维护成本太高。一个中等规模项目需求大概两三百条维护完整的追溯关系要一个资深工程师花两三周。而且这只是开始——需求一改又要重新理一遍。三是追溯质量参差不齐。不同的人写追溯关系有的写得很细有的就填个ID了事。最后追溯矩阵看着好看实际用处有限。传统的办法是用关键词匹配找追溯关系。技术上不难但效果差。用户登录和身份认证匹配不上但实际说的是同一个东西。LLM出现之后我们想着能不能让它来干这个二、先搞清楚追溯到底是什么很多人做追溯系统第一步就搞错了——直接上技术。其实做之前得先想清楚我们要追溯什么追溯到什么粒度我们画了个表把追溯分成了五层层级追溯什么谁来维护更新频率L1 战略层业务目标 → 项目高管/PM月度L2 需求层PRD → 用户故事需求工程师每周L3 设计层设计 → 模块架构师每发布L4 实现层代码 → 类/方法开发每次提交L5 验证层测试 → 需求QA每天不是所有层都要做到1:1。L1和L5可以粗一点L2到L4才是核心。这个分层很重要。因为LLM不是万能的你得告诉它重点在哪里。三、系统长什么样我们做的系统分三层输入层接了PRD存在VP里、需求管理VP、代码Git、测试VP。VP既管需求也管测试这是我们内部统一用的系统。处理层这是核心。LLM负责把文档解析成结构化的东西然后推断追溯关系。推断出来之后给个置信度分数。分数高的自动采纳分数低的让人确认。输出层追溯矩阵、影响分析图、缺口报告。这些是给不同人看的——PM要看覆盖率架构师要看断裂点QA要看测试覆盖。四、核心逻辑LLM怎么找追溯关系很多人以为LLM直接输出REQ-003 对应 TC-102就行了。其实不是。我们用的是多维度综合评估。简单说就是看四个东西语义相似度。这是LLM的强项。“用户身份验证流程和OAuth2.0实现方案”传统方法匹配不上但LLM能看出来是相关的。实体重叠度。两个文档里出现的人、系统、接口、数据如果高度重合很可能有关联。上下文一致性。时序对不对版本对不对依赖关系合理不合理这些规则层面的东西LLM不太擅长需要用传统方法校验。历史模式匹配。如果这个项目之前登录类需求平均对应3个测试用例那新的登录需求也应该有这个量级。最后综合起来给一个置信度分数。我们定了几档0.9以上直接采纳不用人管0.75到0.9批量确认一下0.6到0.75人工审核0.6以下丢弃或者当候选五、从PRD到测试用例全流程怎么走完整流程有六步每步LLM都能帮上忙第一步PRD解析。把自然语言的需求文档变成结构化的需求项标上优先级提取验收标准。这一步LLM能完成85%的工作剩下的是歧义项让人确认。第二步用户故事转化。PRD通常是功能描述要转成作为XX用户我希望XX以便XX的格式。LLM写得不错但故事点估算还得人来做。第三步设计分解。用户故事拆成模块和接口。这一步LLM能帮点忙但架构决策还是人说了算。第四步代码关联。把设计和代码连起来。Git提交记录本身就有这个信息LLM主要是做语义层面的关联。第五步测试用例生成。根据需求生成测试场景正向、反向、边界都要覆盖。VP里本来就有测试用例模块LLM生成初稿之后直接导入边界条件需要人补充。第六步追溯固化。把所有关系连起来结果直接回写VP生成矩阵和报告。这一步自动化程度最高大概90%。整体下来LLM处理那些重复、可模板化的工作人专注在做决策和判断的地方。六、一个真实的案例我们有个科管平台项目叫智能推荐系统用来给内部用户推荐相关文档。项目启动的时候问题挺多。PRD和测试用例不同步需求变更了测试没跟上。验收标准也不清楚开发完了产品说不是这个意思。返工率一度到25%。我们引入了这套追溯系统。具体做法是先只做了L2到L4就是需求层、设计层、实现层。L1战略层和L5验证层先不碰。置信度阈值一开始设得高一点0.85后来慢慢降到0.75。还做了一件事建立了反馈闭环。LLM推荐的追溯关系人工确认或者拒绝之后会反馈给模型让它学得越来越好。效果怎么样指标实施前实施后需求覆盖率72%94%追溯链完整性68%91%变更影响分析准确率65%92%需求返工率25%8%追溯维护工时/人月40小时12小时变化最明显的是返工率和工时。覆盖率也不是拍脑袋吹的——是实际统计出来的。七、踩过的那些坑坑一LLM会幻觉这是最头疼的问题。LLM有时候会编造不存在的追溯关系而且编得很像那么回事。我们的办法是多源验证。LLM推断完之后用规则引擎再查一遍——版本对不对、依赖关系合不合理。再用另一个模型独立推断一次两个结果对比。如果一致可信度就高。坑二文档太长上下文装不下PRD有时候几百页LLM的上下文窗口不够用。我们的解法是分块处理。按章节或者需求项切分一块一块处理同时维护一个上下文状态窗口。处理完之后再做全局关系修复确保跨块的追溯关系不会丢。坑三通用LLM不懂业务让GPT写通用需求没问题但碰到金融、电力这些行业它就懵了。解决办法有两个一是领域微调用行业数据重新训练二是RAG把企业的知识库和历史项目喂给它。我们用的是后者成本更低见效更快。坑四追溯关系说不清楚为什么LLM给个置信度分数但用户想知道为什么这条需求和那个测试用例有关。我们强制要求每个追溯链接附带推理依据语义相似度多少、实体匹配了什么、历史模式是什么。这样用户能看到逻辑也更容易信任系统。八、几点心得做完了这个项目有几个体会第一粒度分层是基础。不要一上来就做全链路追溯先搞清楚哪些层是核心哪些可以粗一点。我们踩过的坑就是刚开始什么都想做结果投入太大效果一般。第二人机协作比全自动更重要。LLM不是替代人是辅助人。它处理重复工作人做决策判断。这个定位搞清楚了系统就好用了。第三反馈闭环是关键。系统用一段时间之后准确率会越来越高。但前提是有人工确认的环节让模型知道哪里对了、哪里错了。没有反馈的系统用久了就僵化了。第四工具链集成不能省。VP本身数据管理就挺强但还得和Git、Jenkins打通不然追溯闭环做不完整。九、接下来会怎样我们内部在讨论几个方向多Agent协同追溯。现在是一个LLM干所有事未来可能是多个Agent分工——一个管需求解析一个管链接推断一个管质量评估。各司其职互相校验。因果推理。现在的追溯主要是相关性未来能不能做因果性比如因为这个需求变更导致那个测试用例失效而不只是这两个文档有关联。动态更新。需求一改追溯链自动跟着变。现在我们是手动触发更新未来希望能实时同步。十、写在最后LLM做需求追溯这事儿我们跑通了一个闭环。效果确实比人肉维护好但也不是什么颠覆性的突破。说到底它就是一个工具。能帮你省时间、提质量但前提是你得用对地方。如果你也在考虑做类似的事我的建议是先从小规模试点开始50到100个需求的项目最合适。别一上来就想搞全公司推广会死的很惨。还有别迷信LLM。它现在能做的事有限幻觉、上下文限制、领域知识缺乏这些问题都得正视。工具再好也得和人配合——VP里数据管得好LLM才能发挥。需求追溯本质上是知识管理。完整的追溯链不是负担是企业沉淀下来的资产。这一点想通了系统就好做了。以上是我们团队的实践记录有类似问题欢迎交流。