用大模型智能体打通 MRD、PRD、系统分析与代码骨架生成

产品研发链路里，最容易消耗时间的环节往往不是写代码本身，而是把业务诉求翻译成研发能执行的材料。

一个需求从提出到落地，通常会经历几层转换：

flowchart LR
    A[业务诉求] --> B[MRD 市场需求文档]
    B --> C[PRD 产品需求文档]
    C --> D[系统分析文档]
    D --> E[接口设计 / 数据模型 / 模块拆分]
    E --> F[代码骨架]

MRD（Market Requirements Document，市场需求文档）偏业务和市场视角，描述为什么要做、目标用户是谁、业务价值在哪里。PRD（Product Requirements Document，产品需求文档）需要进一步落到产品功能、页面交互、流程规则和验收标准。系统分析文档则继续把 PRD 拆成研发视角的模块、接口、数据表、状态流转和异常处理。

传统方式下，这些转换大量依赖人工理解和人工整理，常见问题包括：

大模型适合介入的不是“替人拍板需求”，而是把大量结构化、半结构化的分析工作自动化：提取重点、补全文档结构、检索历史知识、生成流程图、拆分模块、产出接口和代码骨架。人仍然负责判断业务目标、确认边界和审核结果，但不必把时间都花在模板填充和重复整理上。

端到端目标：从业务诉求直接推进到研发材料

一个可落地的智能化研发链路，需要覆盖“业务诉求 → 需求 → 研发”三个阶段，而不是只做一个孤立的文档生成器。

这条链路的关键目标是：让业务输入能够被逐层加工成研发可执行材料。业务侧可以输入自然语言描述、MRD、流程说明、截图或其他附件；需求侧生成 PRD、流程图、功能清单和验收规则；研发侧继续生成系统分析文档、接口草案、数据结构和后端代码骨架。

抽象后可以分成四类能力：

这里的重点不是让大模型一次性输出最终答案，而是通过多个 Agent 分工协作，把复杂任务拆成可检查、可迭代的小任务。

整体架构：RAG、PRD Agent 和系分 Agent 协同工作

完整方案可以分成三层：知识增强层、需求生成层、研发转化层。

图中的流程可以理解为一个流水线：用户输入进入系统后，先通过 RAG（Retrieval-Augmented Generation，检索增强生成）补充业务上下文，再由多个 PRD Agent 生成产品需求文档，随后交给系统分析 Agent 拆解成研发侧材料，最终进入代码骨架生成环节。

用 mermaid 表达这个架构会更清楚：

flowchart TD
    A[用户输入<br/>自然语言 / MRD / 附件] --> B[RAG 检索业务知识]
    B --> C[需求大纲分析]
    C --> D[PRD 多 Agent 生成]
    D --> E[PRD 总结与优化]
    E --> F[系统分析 Agent]
    F --> G[模块拆分]
    F --> H[接口设计]
    F --> I[数据结构设计]
    G --> J[代码骨架生成]
    H --> J
    I --> J
    J --> K[研发交付材料]

    L[历史 PRD / 产品介绍 / 知识百科] --> B
    M[文档测评] --> E
    M --> F

每一层都承担不同职责：

这种架构的好处在于，每个 Agent 的目标都比较明确。与其让一个大模型同时完成“理解业务、写 PRD、画流程图、做系统设计、生成代码”，不如把任务拆成多个节点，并在关键节点加入检索、测评和人工校正。

MRD 到 PRD：把业务描述变成产品需求文档

MRD 到 PRD 的转换，本质上是把偏业务目标的材料转成偏产品执行的材料。PRD 不只描述“要做什么”，还要解释功能范围、用户路径、业务规则、异常情况、验收口径和相关模块关系。

图中的 PRD 生成流程可以拆成五个阶段。

1. 用户输入阶段

输入可以来自两类信息：

自然语言适合描述新增诉求，附件适合提供上下文。如果只有一句简单描述，大模型容易生成泛化内容；如果能同时读取历史文档、业务规则和页面截图，输出的 PRD 会更贴近真实业务。

2. 需求大纲分析阶段

需求大纲分析负责先搭建 PRD 的骨架，而不是直接生成长文档。常见结构包括：

1. 需求背景
2. 目标与价值
3. 用户角色
4. 使用场景
5. 功能范围
6. 功能流程
7. 业务规则
8. 异常处理
9. 数据口径
10. 验收标准

这一阶段可以安排多个 Agent 分工：

先生成大纲有两个好处：一是便于人快速检查方向是否正确，二是能约束后续生成结果，避免内容散乱。

3. PRD 智能生成阶段

大纲确认后，再进入正文生成。此时不应让模型自由发挥，而要给它明确的输入、输出格式和边界条件。

一个 PRD 生成 Agent 的输入可以设计成类似结构：

{
  "requirement_name": "订单批量导出",
  "business_background": "运营人员需要定期导出订单明细，用于对账和分析",
  "target_users": ["运营人员", "财务人员"],
  "related_docs": [
    "历史订单查询 PRD",
    "订单状态说明",
    "导出权限规范"
  ],
  "constraints": [
    "只允许导出本人权限范围内的数据",
    "单次导出最多 5 万条",
    "导出任务需要异步处理"
  ],
  "output_sections": [
    "需求背景",
    "功能说明",
    "业务流程",
    "权限规则",
    "异常处理",
    "验收标准"
  ]
}

输出时可以要求模型使用固定结构：

{
  "background": "...",
  "goals": ["..."],
  "user_roles": ["..."],
  "feature_list": [
    {
      "name": "创建导出任务",
      "description": "...",
      "rules": ["...", "..."],
      "exceptions": ["...", "..."]
    }
  ],
  "flowchart": "mermaid flowchart ...",
  "acceptance_criteria": ["...", "..."]
}

结构化输出便于后续系统分析 Agent 继续消费。如果只输出一段自然语言，后面的接口设计、数据表设计和代码骨架生成都会更难稳定。

4. 需求总结与优化阶段

PRD 初稿生成后，需要进行合并、去重、补漏和润色。这里可以设置一个总结优化 Agent，专门处理以下问题：

这一阶段非常适合引入人工反馈。产品经理可以直接指出“这里不符合业务规则”“这个流程缺少审批节点”，系统再根据反馈进行多轮修订。

5. 在线编辑与最终输出

PRD 生成系统不能只给一个静态结果，还需要支持在线编辑。原因很简单：产品文档最终要服务协作，必须允许人修改、批注、补充和确认。

比较合理的交互方式是：

sequenceDiagram
    participant U as 产品人员
    participant A as PRD Agent
    participant R as RAG 服务
    participant E as 编辑器

    U->>A: 输入需求描述和附件
    A->>R: 检索历史资料和业务知识
    R-->>A: 返回相关文档片段
    A-->>E: 生成 PRD 初稿
    U->>E: 修改、批注、补充规则
    E->>A: 提交优化指令
    A-->>E: 返回修订版本
    U->>E: 确认终稿

最终输出的 PRD 应该具备三个特点：结构统一、规则明确、能被研发继续拆解。

PRD 到系统分析：把产品语言转成研发语言

PRD 描述的是产品功能，系统分析文档描述的是软件实现方式。两者关注点不同。

图中的流程从研发人员输入 PRD 开始，系统通过问答 Agent、系分生成 Agent、总结 Agent 和内容优化 Agent，逐步生成系统分析文档，并进一步产出代码骨架。

问答 Agent：解析 PRD 和附件

问答 Agent 的职责是把 PRD 中的自然语言内容转成可处理的信息单元。它需要识别：

• 需求背景
• 功能列表
• 业务规则
• 用户角色
• 权限要求
• 数据字段
• 外部系统依赖
• 附件中的补充信息

例如 PRD 中有一句话：

运营人员可以按订单状态和下单时间筛选订单，并异步导出符合条件的数据。

问答 Agent 应该提取出：

{
  "actor": "运营人员",
  "operation": "异步导出订单",
  "filters": ["订单状态", "下单时间"],
  "data_scope": "符合筛选条件的数据",
  "process_type": "异步任务"
}

这些结构化信息会进入后续系统分析环节。

系分生成 Agent：拆模块、定接口、建数据模型

系统分析 Agent 要把产品需求拆成技术设计。以“订单批量导出”为例，可能得到这样的模块划分：

对应的接口草案可以这样设计：

POST /api/order-export/tasks
GET  /api/order-export/tasks/{taskId}
GET  /api/order-export/tasks/{taskId}/download
POST /api/order-export/tasks/{taskId}/cancel

数据表草案可以这样描述：

系统分析 Agent 不一定要直接给出最终设计，但应该提供一个足够完整的初稿，让研发评审时有明确讨论对象。

总结 Agent：把分析结果整理成规范文档

系统分析过程会产生很多碎片信息，例如模块说明、接口列表、数据字段、异常情况和流程图。总结 Agent 负责把这些内容整理成统一格式。

一个系统分析文档可以采用这样的结构：

1. 需求概述
2. 业务流程
3. 系统边界
4. 模块设计
5. 接口设计
6. 数据库设计
7. 状态机设计
8. 异常处理
9. 日志与监控
10. 安全与权限
11. 风险点与待确认事项

其中“待确认事项”很重要。大模型无法确定的信息不应该被伪装成确定结论，而应该显式列出，例如：

内容优化 Agent：补图、补表、补约束

内容优化 Agent 不负责重新理解需求，而是提升文档的可读性和完整性。常见工作包括：

• 把长段文字改成表格；
• 生成数据流图、模块关系图、状态机图；
• 对接口参数补充说明；
• 对异常场景补充处理方式；
• 检查文档章节是否缺失。

例如导出任务状态可以用状态机表达：

stateDiagram-v2
    [*] --> CREATED: 创建任务
    CREATED --> RUNNING: 开始执行
    RUNNING --> SUCCESS: 文件生成成功
    RUNNING --> FAILED: 执行失败
    CREATED --> CANCELED: 用户取消
    RUNNING --> CANCELED: 用户取消
    SUCCESS --> EXPIRED: 文件过期

这种图比文字更容易帮助研发、测试和产品对齐边界。

从系统分析到代码骨架

系统分析结果足够结构化后，就可以进一步生成代码骨架。这里的“代码骨架”不是完整业务代码，而是项目结构、类、接口、方法、数据对象和基础注释。

以典型后端分层为例，可以生成：

order-export/
├── controller/
│   └── OrderExportController.java
├── service/
│   ├── OrderExportService.java
│   └── impl/
│       └── OrderExportServiceImpl.java
├── repository/
│   └── OrderExportTaskRepository.java
├── domain/
│   └── OrderExportTask.java
├── dto/
│   ├── CreateExportTaskRequest.java
│   ├── ExportTaskResponse.java
│   └── ExportTaskQuery.java
└── enum/
    └── ExportTaskStatus.java

Controller 层可以先生成接口骨架：

@RestController
@RequestMapping("/api/order-export/tasks")
public class OrderExportController {

    private final OrderExportService orderExportService;

    public OrderExportController(OrderExportService orderExportService) {
        this.orderExportService = orderExportService;
    }

    @PostMapping
    public ExportTaskResponse createTask(@RequestBody CreateExportTaskRequest request) {
        return orderExportService.createTask(request);
    }

    @GetMapping("/{taskId}")
    public ExportTaskResponse getTask(@PathVariable Long taskId) {
        return orderExportService.getTask(taskId);
    }

    @GetMapping("/{taskId}/download")
    public String getDownloadUrl(@PathVariable Long taskId) {
        return orderExportService.getDownloadUrl(taskId);
    }

    @PostMapping("/{taskId}/cancel")
    public void cancelTask(@PathVariable Long taskId) {
        orderExportService.cancelTask(taskId);
    }
}

Service 层可以保留待实现逻辑：

public interface OrderExportService {

    ExportTaskResponse createTask(CreateExportTaskRequest request);

    ExportTaskResponse getTask(Long taskId);

    String getDownloadUrl(Long taskId);

    void cancelTask(Long taskId);
}

DTO 可以根据系统分析中的字段自动生成：

public class CreateExportTaskRequest {

    private List<String> orderStatusList;

    private LocalDateTime startTime;

    private LocalDateTime endTime;

    private Map<String, Object> extraFilters;

    // getter/setter
}

生成代码骨架的价值在于减少“从空项目开始搭结构”的时间。业务逻辑、边界条件、事务一致性、性能优化和安全校验仍然需要研发人员审核和实现。

细节创作能力：让文档支持局部改写

除了完整生成 PRD 或系统分析文档，大模型还适合做局部创作。常见能力有四类：

例如原始需求点是：

支持订单导出。

扩写后可以变成：

系统支持运营人员在订单列表中按照订单状态、下单时间等条件筛选订单，并创建异步导出任务。导出任务创建后，用户可以查看任务状态；任务完成后，系统提供文件下载入口。若用户无导出权限、筛选结果为空或任务执行失败，系统需要给出明确提示。

局部创作能力看似简单，但在日常协作中很实用。它能把零散表达快速整理成可评审的需求描述。

RAG：给大模型补充业务上下文

大模型本身不掌握企业内部的历史 PRD、产品规则、接口规范和业务百科。直接让它生成需求文档，容易出现泛化表达，甚至把不存在的规则写进去。RAG 的作用就是在生成前先检索相关业务知识，把检索结果作为上下文交给模型。

图中的支撑模块主要包含两部分：一是 RAG 检索业务知识，二是 LLM（Large Language Model，大语言模型）微调与文档测评。RAG 负责解决上下文不足的问题，微调和测评负责持续改善模型在特定业务场景下的输出质量。

RAG 辅助智能体的流程

RAG 链路可以拆成六步：

flowchart TD
    A[用户输入需求] --> B[选择或匹配知识库]
    B --> C{数据集是否为空}
    C -- 是 --> D[使用默认知识库全部文档]
    C -- 否 --> E[使用指定数据集文档]
    D --> F[文档切块与向量检索]
    E --> F
    F --> G[稠密向量召回 BGE]
    F --> H[稀疏向量召回 SPLADE]
    G --> I[综合排序]
    H --> I
    I --> J[返回相关文档片段]
    J --> K[交给 Agent 生成或优化文档]

核心细节有三个。

1. 数据集选择

知识库不一定只有一个。不同产品线、业务域、系统模块可能有各自的数据集。用户输入需求后，系统可以自动匹配知识库，也可以让用户手动选择。

例如：

如果知识库选择错误，后面的检索结果再准确也没有意义。

2. 混合检索

单一检索方式很难覆盖所有场景。稠密向量适合语义相近的内容，稀疏向量适合关键词匹配强的内容。

例如用户输入“批量导出订单明细”，稠密向量可能召回“订单报表下载”，稀疏向量可能召回包含“导出”“订单明细”的规则文档。两类结果融合后，召回质量通常更稳。

3. 综合排序

检索出的文档片段需要重新排序，否则模型可能拿到大量弱相关上下文。排序可以综合考虑：

• 语义相似度；
• 关键词命中；
• 文档类型；
• 更新时间；
• 所属业务域；
• 用户选择的数据集权重；
• 历史对话中的意图。

一个简化的打分方式可以写成：

def rank_score(dense_score, sparse_score, doc_type_weight, freshness_weight):
    return (
        0.45 * dense_score +
        0.35 * sparse_score +
        0.10 * doc_type_weight +
        0.10 * freshness_weight
    )

真实场景里，权重不一定固定，可以根据业务域和测评结果不断调整。

文档测评与模型微调

只搭建生成链路还不够，还需要判断输出质量。否则系统看起来能生成很多内容，但无法确定哪些内容可靠。

文档测评

PRD 和系统分析文档可以从几个维度评估：

测评可以结合人工和模型自动评估。人工适合判断业务正确性，模型适合检查格式、缺漏、重复和一致性问题。

模型微调

当业务有稳定模板、固定表达和大量领域术语时，可以考虑对模型做轻量微调。LoRA（Low-Rank Adaptation，低秩适配）是一种常见方式，它不需要全量更新模型参数，而是在较小参数规模上适配特定任务。

适合微调的数据包括：

微调不能替代 RAG。RAG 解决“拿到最新知识”的问题，微调解决“更像目标任务、更符合格式和表达习惯”的问题。两者配合使用更合理。

关键挑战与优化方向

RAG 链路需要更懂用户意图

用户输入往往不是标准查询语句，而是模糊诉求。例如：

想优化一下退款流程，减少客服介入。

如果直接检索，系统可能同时召回退款规则、客服工单、售后流程、支付渠道说明等大量资料。更合理的做法是在调用 RAG 前先做意图拆解：

{
  "main_intent": "优化退款流程",
  "sub_questions": [
    "当前退款流程包含哪些节点？",
    "哪些节点需要客服介入？",
    "是否存在自动审核规则？",
    "退款失败或超时如何处理？"
  ],
  "target_docs": [
    "退款 PRD",
    "售后流程",
    "客服工单规则",
    "支付渠道退款说明"
  ]
}

拆解后再检索，召回会更聚焦。检索完成后，还需要结合历史对话进行总结，避免把多个文档片段简单拼接给生成 Agent。

高质量领域数据需要持续沉淀

模型微调和自动测评都依赖高质量数据。真正有价值的数据不是随便收集的文档，而是经过业务确认、研发落地、线上验证的材料。尤其是以下数据非常关键：

• 评审通过的 PRD；
• 实际研发采用的系统分析文档；
• 需求变更记录；
• 评审意见和修改原因；
• 线上问题对应的需求遗漏点；
• 标准模板和格式规范。

这些数据可以帮助系统知道“什么样的输出才算好”，而不只是生成看起来完整的文档。

复杂业务仍然需要多轮灰度

复杂业务里，需求经常涉及多个系统、多个角色和多套历史规则。大模型一次生成的结果很难直接作为最终设计，需要通过灰度方式逐步验证：

flowchart LR
    A[小范围试用] --> B[人工评审]
    B --> C[收集错误类型]
    C --> D[优化 Prompt / RAG / 模型]
    D --> E[扩大业务范围]
    E --> B

错误类型要被结构化记录，例如：

通过这种方式，智能体系统会逐步从“能生成”走向“可稳定协作”。

落地时的边界

大模型智能体适合承担需求分析和设计中的结构化辅助工作，包括检索上下文、整理文档、生成初稿、补充图表、拆分模块和产出代码骨架。它不适合替代产品决策、架构决策和最终代码审核。

更可靠的定位是：

当输入足够完整、知识库质量较高、输出格式有约束、测评机制能持续反馈时，大模型智能体可以把大量需求分析和设计工作前移并自动化。产品和研发的主要工作会从“从零编写材料”变成“审核、修订和确认关键决策”，协作成本也会随之降低。