遗留系统需求梳理指南：Claude Opus 4.8 先做这三件事
上个月接手了一个运行近十年的支付网关项目，文档状况堪称灾难——唯一一份PRD还是五年前写的，里面充斥着已废弃的逻辑和从未落地的功能描述。新来的产品经理对着这份文档直挠头，问我能不能帮忙理出一条清晰的功能基线。接手后第一反应是：试试让模型把这几十页文档吃进去，看看能否自动提取出核心需求。
结果比预想的折腾得多——第一次跑出来的结果很漂亮，逻辑通顺、格式工整，可复查时发现一个关键的验签流程被偷偷“优化”掉了。这不是模型在胡说八道，而是它把两段不同时期的描述当成了冗余，自作主张合并了。这个教训说明：长上下文理解能力强，不代表交付给模型的任务就要一步到位。
顺带一提，做这类多模型对比测试时，来回切换平台确实费时间。不过工具终究只是工具，重点还是怎么把输入规范和验证流程建立起来。
第一件事：先让模型提取“事实清单”，而不是直接要结论
最初的Prompt很简单：“请阅读以下需求文档，列出所有功能点。”结果Claude Opus 4.8输出的列表读起来很舒服，但问题就出在“读起来舒服”上——它把一些模糊的描述自动补全成了明确的逻辑，比如把“支持异常情况下的回滚处理”展开成了“需支持网络超时和余额不足两类异常回滚”，而原文其实没提这层细节。
后来把第一步改成了纯粹的“事实提取”，Prompt变成这样：
你是一个系统分析师。请阅读以下遗留系统需求文档片段，提取所有明确提及的功能约束、业务规则和数据流转逻辑。每一条必须标注原文出处（段落和句子），不得推断、补充或合并。如果原文存在前后矛盾的描述，请单独列出，不要尝试调和。
这个Prompt的效果立竿见影。模型不再是“写一篇文章”，而是像在做摘抄批注，每条提取都带着原文锚点。矛盾点也被标出来了，比如第三章说“订单超时自动取消”，第八章又说“订单超时后进入人工审核队列”——这种不一致在原始文档里藏得很深，人工阅读时很容易一带而过。
第二件事：让模型标注每条需求的可信度
光是提取还不够，还需要知道哪些描述是“铁板钉钉”的，哪些是“建议性的”，哪些根本就是废弃的草稿。所以加了一个第二步，把第一步的输出再喂回去，让模型做可信度分类。
Prompt如下：
以下是从遗留系统文档中提取的需求陈述。请对每一条标注可信度等级：
- 高：原文使用“必须”“应当”等强制性措辞，或描述了具体的输入输出、接口字段；
- 中：原文使用“建议”“可考虑”等建议性措辞，或未给出具体实现细节；
- 低：原文含糊其辞，或与该文档其他部分存在明显矛盾。
对于低可信度的条目，请说明降低其可信度的具体原因。
这一步跑完后，原本密密麻麻的需求清单被分成了三层，低可信度的条目占到了近两成。拿着这份结果和产品经理过了一遍，发现那些低可信度条目大部分确实对应着文档里早已过时的设计思路，在现有系统里根本没有落地。如果没有这一层筛选，团队可能会花大量时间去讨论一些根本不存在的需求。
第三件事：用多模型交叉验证识别幻觉
Claude Opus 4.8的长上下文理解确实比其他模型好，至少不会读到后面忘了前面。但这不代表它不会“脑补”。为了验证输出中的那些看起来很合理的字段定义是否真实，用同样的第一步Prompt跑了一遍ChatGPT和Gemini，把它们各自提取的“事实清单”放在一起对比。
结果很有意思。三个模型在核心流程上的提取基本一致，但在一些边缘细节上出现了分歧。比如关于退款接口的幂等性设计，Claude提取出了一套完整的重试机制描述，但ChatGPT和Gemini都只提取到“需要支持幂等”这句简单的话。回头一翻原文，发现那段关于重试机制的详细描述根本不在文档里，Claude把“需要支持幂等”和另一段关于支付的描述嫁接到了一起。
这个发现很关键。它说明了一个原则：当一个模型给出了特别“完备”的输出，而其他模型在同一处都保持克制时，多半是前者在做过度推断。这种交叉验证不是要选一个“更准”的模型，而是用多个模型的输出差异来反向定位原文中真正模糊的地方。
验证闭环长什么样
整个工作流跑下来，最终交付给产品经理的不是一份“AI总结”，而是一套三层结构：
- 事实清单（带原文锚点），由Claude生成，人工抽检；
- 可信度标注，同样由Claude生成，产品经理逐条确认；
- 多模型差异报告，只列出三个模型提取结果不一致的条目，作为需要进一步澄清的待办项。
这个流程最耗时的是第三步的人工确认，但总量已经从原来通读几十页文档缩减到了只关注不一致和低可信度的条目。实际统计下来，原始文档47页，最终需要人工判断的条目只有21条。
顺便说一句：别拿模型做合规终判
做支付相关的需求分析，绕不开合规问题。文档里有一些涉及费率计算、资金流转的描述，这类内容完全没有让模型参与解读。原因很简单：模型的解读没有任何法律效力，而且它可能会把“建议”说成“必须”，反过来也可能把强制约束轻描淡写。涉及合规、合同、金融条款的内容，模型只适合做格式整理和原文摘录，不能做任何形式的解读或判断。这个边界必须守死。
几条可复用的经验
回过头看，这套“事实提取→可信度标注→多模型验证”的三步工作流，其实不限于需求文档。处理接口文档、旧系统运维手册、甚至离职同事留下的交接文档，都可以套用类似思路。
关键不是选了哪个模型，而是以下几点：
- 别让模型一步出结果，把提取和判断拆开；
- 对长文档始终要求原文锚点，没有出处的输出一律当可疑处理；
- 多模型输出不一致的地方，往往是原文信息缺失或矛盾的地方，反而是最有价值的人工介入点。
Claude Opus 4.8在长文档处理上的表现确实可圈可点，但好用的工具更容易让人放松警惕。说到底，模型帮你省掉的是“初读”的时间，不是“判断”的责任。