最近带团队搞了一套需求追溯系统，底层用的是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才能发挥。
需求追溯本质上是知识管理。完整的追溯链不是负担，是企业沉淀下来的资产。这一点想通了，系统就好做了。
以上是我们团队的实践记录，有类似问题欢迎交流。