应对混乱的遗留系统 PRD：我是如何用 Claude Opus 4.8 搭建需求拆解与架构反推工作流的

文章摘要：本文分享了利用 Claude Opus 4.8 应对混乱遗留 PRD、辅助电商系统重构的实战工作流。核心分为三步：一是长文档脱敏，让 AI 审查业务逻辑漏洞与边界缺失；二是结合 DDD 反推领域模型，生成 UML 类图辅助架构设计；三是自动输出 BDD 验收测试用例，为代码重构提供安全网。该方案能高效将模糊的长文本转化为标准工程产物，大幅缩短排期。但实际落地中，非功能性架构设计与代码防幻觉仍需依赖人工把控。

接手历史包袱沉重的核心系统，往往是从面对一堆残缺不全、前后矛盾的 PRD（产品需求文档）开始的。

上个月，团队决定对一套运行了四年的电商促销计费引擎进行底层重构。这套系统历经了六七任产品经理的迭代，业务规则散落在几十个 Confluence 页面、历史钉钉聊天记录以及代码的硬编码里。面对这种局面，如果纯靠后端开发人工去梳理“跨店满减”、“单品直降”和“品类券”的叠加互斥逻辑，不仅极易遗漏边界条件，而且排期至少需要两周起步。

为了加速这一过程，我决定引入大模型来辅助做长文档的语义提炼和逻辑纠错。在梳理初期，为了减少来回切工具的成本，我把 ChatGPT、Gemini、Claude、Grok 的输出放在同一个多模型环境里看，测试环境是https://ouai.me，方便把同一套长篇的促销规则文本交给不同模型复跑对比。经过几轮控制变量的测试，我发现面对包含大量业务术语和嵌套条件的长文本时，Claude Opus 4.8 在逻辑一致性、遗漏率以及对矛盾点的敏锐度上表现最为扎实。

基于这次实践，我沉淀了一套“长文档脱敏 -> 矛盾点审查 -> 领域模型反推 -> BDD 验收用例生成”的工程化分析工作流。今天就和大家复盘一下这套能在真实业务中落地的操作流程。

核心前提：建立物理隔离的“脱敏层”

在把任何公司内部文档喂给 AI 之前，脱敏是不可逾越的红线。很多开发者习惯直接把 Confluence 导出的 PDF 拖进对话框，这存在极大的合规风险。

在我的工作流中，我写了一个简单的 Python 脚本，通过正则和字典替换，将文档中的敏感信息进行了清洗：

1. 真实接口域名和库表名：统一替换为api_gateway_placeholder、table_promo_rule等泛称。
2. 特定的商业数据：比如真实的 GMV 阈值、大促活动代号，替换为[活动 A]、[阈值 X]。
3. 员工与商家信息：全部替换为User1、Merchant_A。

清洗后的文本虽然失去了具体的商业上下文，但核心的条件分支和计算逻辑依然完整，这就足够模型进行推理了。

第一阶段：用 Claude 充当“杠精 QA”，找出逻辑漏洞

遗留文档最大的问题不是“没写清楚”，而是“前后矛盾”。比如 2021 年的文档写着“全场券不与单品券叠加”，而 2023 年追加的补丁说明里又出现了“特定白名单单品可无视全场券互斥”。

我利用 Claude Opus 4.8 强大的长上下文窗口，把清洗后的 3 万字需求文档全部扔了进去，并使用了带有特定身份预设的 Prompt。

我的指令设计（结合了 XML 标签规范）：

你现在是一位拥有 10 年经验的电商底层架构师兼资深 QA。我将为你提供一份历史遗留的促销系统需求文档。

你的核心任务不是总结这篇文档，而是找出其中的逻辑漏洞。请仔细交叉比对文档中的每一条规则，输出一份《业务规则冲突与边界缺失报告》。 1. 重点排查：优惠券叠加顺序、互斥条件、退款时的资产逆向回滚逻辑。 2. 寻找边界：列出文档中未明确说明的极端场景（如订单金额抵扣为负数、并发超卖、分布式事务一致性失败时的补偿机制）。 3. 请引用原文片段来佐证你发现的矛盾点。

Claude 的输出非常犀利。它不仅抓出了我刚才提到的白名单互斥冲突，还敏锐地指出了一个藏在很深处的漏洞：“文档在第 4.2 节规定了退款时按均摊比例退回优惠，但在 7.1 节的‘阶梯满减’场景中，未定义如果部分退款导致订单总金额跌下阶梯门槛时，是否需要追回已使用的优惠差额。”

拿着这份报告去和现任产品经理对齐，我们仅用了一个下午就拍板了十几个历史遗留的模糊地带，效率远超传统的“拉群扯皮”。

第二阶段：从业务规则到领域模型（Domain Model）的反推

理清了业务规则，下一步是技术架构设计。面向对象开发中，划分清晰的领域实体（Entity）和值对象（Value Object）是重构的核心。

由于 Claude Opus 4.8 对技术规范的理解非常深刻，我顺势让它基于上一步纠正后的规则，帮我草拟初版的领域模型，并直接输出 PlantUML 代码。

分析指令：

现在的业务规则已经清晰。请作为 Java 领域驱动设计（DDD）专家，帮我反推这个促销引擎的核心领域模型。

要求：

1. 识别出核心聚合根（Aggregate Root）、实体（Entity）和值对象（VO）。
2. 重点关注“促销规则（Rule）”、“计算上下文（CalculateContext）”和“计费明细（BillingItem）”的结构。
3. 请直接输出符合 PlantUML 语法的类图代码，包含关键的属性和方法说明。

将它生成的 PlantUML 代码贴进 IDE 的插件里，一张结构清晰的 UML 类图直接渲染了出来。虽然它给出的设计偏向于理想化，比如把优惠金额的计算拆分得过于细碎，但这为我和架构组的其他同事提供了一个极具参考价值的讨论底稿。我们在它的基础上，微调了几个实体的聚合关系，就敲定了最终的表结构设计。

第三阶段：BDD 验收测试用例生成

重构最怕的就是把原本能跑的业务改挂了。为了确保新旧系统逻辑一致，我们需要海量的测试用例。在这一步，AI 的优势被发挥到了极致。

我要求 Claude Opus 4.8 基于前面的业务规则，直接生成符合 Cucumber 框架语法的 Gherkin 测试用例（Given-When-Then 格式）。

生成指令示例：

请针对“跨店满减与无门槛红包叠加计算”这一核心链路，生成 10 个 BDD 测试用例。
必须包含以下场景：

1. 正常满足条件的叠加。
2. 扣减后订单支付金额为 0 的边界处理。
3. 跨店满减按比例均摊时，出现三分之一无法整除（如 100/3）的精度兜底逻辑。

请直接输出.feature文件的标准格式。

看着屏幕上快速刷出的结构化用例，作为开发者的幸福感是很强的。特别是关于“金额精度无法整除”的那个用例，它精准地写出了Then 拆单后的子订单优惠金额之和必须绝对等于总优惠金额，最后一笔子订单承担余数这个核心断言逻辑。我们将这些文本化的用例直接转交给了测试团队，作为他们编写自动化测试脚本的依据。

工作流复盘：为什么不选其他模型？

在这个特定的“长文档复杂逻辑拆解”任务中，我也观察了其他模型的表现，这也是为什么我最终在这个环节锁定 Claude Opus 4.8 的原因：

• 上下文遗忘问题：部分模型在对话进行到第三轮（生成用例阶段）时，会忘记第一轮中我们已经纠正过的“特定白名单”规则，又退回到了文档最初的错误逻辑。而 Opus 4.8 在长对话中的状态保持相当稳定。
• 过度发散 vs 严谨克制：在反推领域模型时，有些模型喜欢“炫技”，擅自引入了复杂的规则引擎（如 Drools）或引入过多的设计模式，导致类图极其臃肿；Opus 4.8 的输出则更加务实，紧扣我提供的业务本身。

警惕 AI 辅助开发的边界

尽管这套工作流极大地加速了前期的系统分析，但在实际落地中，有几个坑依然需要人工去填：

1. AI 无法替代架构师对“非功能性需求”的决策。
   Claude 能把业务逻辑理得很顺，但它不知道你们公司的数据库能扛多少 QPS，也不知道 Redis 集群目前的内存水位。诸如“促销规则在应用启动时全量缓存还是懒加载”、“分布式锁的粒度应该多细”这类关乎系统稳定性的决策，绝对不能盲从 AI 的建议。

2. 伪造 API 和依赖库（幻觉）。
   在生成具体的 Java 伪代码时，偶尔会发现它调用了某些并不存在的第三方库方法（尤其是涉及到 BigDecimal 复杂运算的某些特定语法糖）。代码落地前，必须经过严格的 IDE 静态检查。

3. 责任链的归属。
   用 AI 找漏洞、写用例，最终对这些逻辑负责的依然是敲下 git commit 的工程师。任何由 AI 生成的规则确认报告，都必须经过技术与产品双方的人工 Review 签字，千万别把“AI 是这么总结的”当成甩锅的理由。

结语

面对令人头皮发麻的遗留系统，用硬核的工程思维去驾驭大模型，往往能事半功倍。

把 AI 当作一个“记忆力超群但缺乏真实业务体感”的结对编程助手，先通过脱敏文档建立上下文，再用严苛的 Prompt 逼它去寻找漏洞，最后让它生成可验证的结构化产物（UML、BDD 用例）。当你把非标准化的文本输入转化为标准化的工程输出时，重构这件高风险的脏活，也就变得清晰可控了。