智能PRD生成系统：从模板到动态结构化的进化

1. 项目概述：从模板PRD到智能PRD的进化之路

在传统前端开发流程中，产品需求文档（PRD）的撰写往往是个耗时且容易出错的环节。作为经历过数十个中后台系统开发的老手，我深刻体会过这样的场景：产品经理用Word写了50页需求文档，开发时却发现交互细节描述模糊；或是PRD中的组件说明与实际页面DSL存在偏差，导致返工。更棘手的是，当企业采用低代码平台后，原有的PRD模板完全跟不上组件自由组合的灵活度——这正是我们团队开发PRD2CODE系统的初衷。

这个系统的核心价值在于：将PRD生成从"静态模板填空"转变为"动态结构化生成+智能审阅"的双向流程。举个例子，当你在低代码平台上拖拽出一个包含动态表单、分步向导和条件显隐的复杂页面时，系统能自动生成：

• 完整的组件级技术描述（字段类型、校验规则等）
• 交互状态机示意图
• 边界条件检查清单
• 可交互修改的PRD草稿

实测数据显示，这种方案使PRD与最终实现的匹配度从传统模板的68%提升到92%，产品经理的文档修改工作量减少40%。下面我将从技术实现角度，详解这个系统如何做到既灵活又可靠。

2. 核心架构设计：双物料系统如何运作

2.1 组件物料库的构建实践

组件物料库（Component Materials）是整个系统的基石，它的核心使命是建立"DSL组件→PRD片段"的准确映射。我们在实践中发现，要做好这个映射，必须解决三个关键问题：

问题1：组件变体的描述覆盖
以最常见的表单组件为例，其变体包括：

• 基础表单（字段+提交按钮）
• 分步表单（带步骤导航）
• 动态表单（字段间联动）
• 抽屉表单（在侧边栏呈现）

我们的解决方案是为每个组件定义"核心属性+扩展接口"：

typescript复制interface FormComponent {
  // 核心属性
  fields: Array<{
    name: string
    type: 'text'|'number'|'select'...
    validations: ValidationRule[]
  }>
  
  // 扩展接口
  variants?: {
    isWizard?: boolean  // 分步表单
    isDynamic?: boolean // 动态字段
    containerType?: 'modal'|'drawer' // 容器类型
  }
}

问题2：PRD映射规则的颗粒度
过早绑定到具体文案会导致灵活性不足。我们采用三级描述体系：

1. 技术描述（必选）：字段类型、校验规则等硬性约束
2. 交互描述（可选）：如"当字段A选择选项X时，字段B应显示"
3. 业务描述（生成建议）：根据业务语义自动生成的文案建议

问题3：物料更新机制
我们建立了组件版本化机制，当低代码平台新增组件时：

1. 自动提取组件DSL定义
2. 生成初始物料模板
3. 通过历史PRD相似片段推荐业务描述
4. 经产品负责人审核后入库

2.2 PRD物料库的智能分层

PRD物料库（PRD Materials）负责承载业务语义，其设计必须兼顾结构化与灵活性。我们的分层策略如下：

L0通用骨架示例

markdown复制## 1. 需求背景
{{auto_generated}}  // 自动从对话摘要提取
## 2. 功能范围
{{inferred_from_DSL}} 
## 3. 权限要求
{{from_standard_clip}}

L1高频场景模板
对于"列表页+详情页"这种经典组合，我们预置了包含以下要素的模板：

• 列表筛选条件映射表
• 分页参数说明
• 详情页字段权限矩阵

L2团队规范检查点
通过分析历史代码审查记录，我们提炼出最高频的规范问题：

• 埋点事件命名规则（动作_对象_位置）
• 敏感字段加密要求
• 列表页默认排序规则

L3历史片段重用
采用向量检索技术，当系统检测到类似业务场景时（如"订单售后流程"），会自动推荐历史PRD中的优质描述段落，并标注相似度分数供参考。

关键经验：物料库初期建议采用"人工审核+自动扩展"模式，我们设置了物料置信度评分，只有评分>80%的片段才允许自动复用，避免低质量内容污染库。

3. 生成引擎的实现细节

3.1 两段式生成的技术实现

第一阶段：PRD-IR生成
这个中间表示（Intermediate Representation）的核心结构如下：

json复制{
  "sections": [
    {
      "type": "component_spec",
      "source": "dsl",  // 来源标记
      "component_type": "advanced_form",
      "fields": [
        {
          "name": "user_name",
          "validations": ["required", "max_length:32"],
          "pending_confirm": false 
        }
      ],
      "pending_issues": [
        {
          "type": "default_value",
          "component": "user_type_selector",
          "description": "需要产品确认默认选中项" 
        }
      ]
    }
  ]
}

生成过程中有几个关键校验点：

1. DSL一致性检查：确保每个字段都能追溯到DSL定义
2. 必填项验证：如权限控制、空状态等关键要素
3. 模糊项标记：对无法确定的内容打上TBD标签

第二阶段：HTML渲染
我们开发了基于AST的转换引擎，其工作流程：

1. 解析PRD-IR的JSON结构
2. 匹配预定义的模板规则（如表格型数据用<table>渲染）
3. 注入交互元素（如可点击跳转的组件引用）
4. 生成带版本水印的HTML

实测中发现，直接生成Markdown再转HTML会导致交互元素丢失，因此我们最终选择了专用HTML生成器。

3.2 RAG检索的工程优化

在物料检索环节，我们遇到了两个典型问题：

1. 相似但不匹配的片段被召回（如把"用户注册表单"的物料误用于"用户编辑表单"）
2. 多组件组合场景检索不全

解决方案1：结构化过滤
在向量检索前增加规则过滤层：

python复制def pre_filter(query):
    # 从DSL提取关键特征
    page_type = extract_page_type(query.dsl)
    primary_component = detect_main_component(query.dsl)
    
    # 应用过滤规则
    if page_type == "dashboard" and primary_component == "data_table":
        add_filter("material_type", ["dashboard_metrics", "table_config"])

解决方案2：组合式检索
对于包含多个组件的复杂页面，采用分治策略：

1. 拆分DSL为原子组件
2. 并行检索每个组件的物料
3. 通过组合规则生成整体页面的描述框架

4. 审阅系统的交互设计

4.1 双模编辑的实际体验

系统提供两种并行的修改方式，其适用场景对比如下：

在实际使用中，我们发现约65%的修改来自自然语言指令，但复杂结构调整仍需依赖直接编辑。为此我们开发了"指令转编辑建议"功能——当用户输入"把这个字段校验规则移到表格里"时，系统会生成具体的拖拽操作建议，用户确认后执行。

4.2 检查清单的智能生成

系统自动生成的检查清单包含三类内容：

1. 必须确认项（红色标记）

   • 权限控制矩阵是否完整
   • 敏感字段是否标注加密要求
   • 空状态是否全部定义

2. 建议确认项（黄色标记）

   • 默认排序规则
   • 表单提交防重机制
   • 长列表性能优化提示

3. 边界问题（蓝色标记）

   • 未明确的阈值（如"长时间"的具体定义）
   • 多端一致性要求
   • 灰度发布策略

我们为每个检查项设计了快速定位功能，点击可直接跳转到PRD相关段落进行编辑。

5. 落地实践中的经验教训

5.1 性能优化关键点

在初期版本中，生成一个包含20个组件的页面PRD需要近30秒，经过以下优化后降至3秒内：

1. 物料预加载：根据用户操作习惯，在点击"生成"按钮前就开始后台加载可能需要的物料
2. 生成过程分块：将PRD按章节拆分为独立生成任务，支持渐进式呈现
3. 缓存策略：对稳定的组件描述片段（如基础表单规范）建立哈希缓存

5.2 质量保障机制

我们建立了三重质量关卡：

1. 自动校验：DSL字段覆盖率检查、必填项验证
2. 同伴评审：随机抽取10%的生成结果进行人工审核
3. 线上监控：跟踪PRD修改频率与最终实现的一致性

5.3 团队协作流程

新的PRD生成方式需要调整团队协作节奏：

1. 产品经理先通过对话定义核心流程
2. 交互设计师完善DSL细节
3. 系统生成PRD初稿
4. 三方（产品、设计、开发）协同审阅
5. 锁定版本后自动同步至Jira等管理工具

这种模式下，PRD不再是一锤子买卖，而是贯穿整个迭代周期的动态文档。

6. 未来演进方向

当前系统已在内部低代码平台稳定运行6个月，接下来的重点优化方向包括：

1. 实时协作能力：支持多人同时审阅修改，解决冲突合并问题
2. 逆向工程支持：从已有代码库提取PRD要素，补充物料库
3. 智能diff工具：当DSL变更时，自动高亮PRD中需要更新的段落
4. 多模态输出：生成包含序列图、状态机的交互式文档

这个项目的核心启示在于：当AI参与文档生成时，关键不是追求完全自动化，而是构建"可验证、可修改"的智能协作流程。正如我们团队常说的——PRD2CODE不是要取代产品经理，而是让他们从格式调整中解放出来，专注于真正的需求逻辑。