摘要

传统前端研发流程中,PRD 定稿后需产品、前端多轮人工转译,普遍存在交付周期长、沟通成本高、返工率高、代码标准化不足等痛点。本文基于真实业务落地场景,完整拆解一套可直接复用的 PRD→页面→源码全链路自动化方案,依托「样板间平台 + 可视化 GUI + AI 转译 + 插件生态」四大核心能力,明确可量化核心指标、全角色产品设计、全栈技术实现、标准化协议规范及落地避坑细节,最终实现 PRD→页面生成 100% 成功率、PRD→代码生成 ≥ 90% 成功率,平均需求交付周期缩短 30%,从根源解决人工转译核心痛点,助力研发团队快速提效。

一、方案总览

1.1 方案定位

面向产品经理、前端开发、平台管理员,覆盖PRD 解析→原型配置→代码生成→二次开发全流程,以「标准化、自动化、轻量化」为核心,无需重构现有研发流程,可快速嵌入团队工作流;聚焦 90% 通用页面场景(表单/表格/详情页/日志页等),同时兼容定制化场景的二次开发需求。

1.2 核心目标

  • 消除人工转译:实现 PRD→页面→源码全链路自动化,降低沟通成本与转译误差;
  • 提升交付效率:通用页面支持「产品配置即生成代码」,大幅缩短 PRD 到上线周期;
  • 统一研发标准:规范原型、PRD、代码格式,降低返工率,提升团队协作一致性;
  • 降低操作门槛:产品无编码配置原型,前端免写基础页面代码,聚焦核心业务逻辑。

1.3 可量化核心指标

  • PRD→页面生成成功率:100%
  • PRD→代码生成成功率:≥ 90%
  • 需求交付周期:平均缩短 30%
  • 需求返工率:降低 50% 以上

1.4 全角色核心收益

用户角色 核心收益 具体场景
产品经理 无编码配置原型,一键导出标准化 PRD 快速完成表格/表单页配置 + PRD 导出
前端开发 免写基础页面,输入任务 ID 直接下载代码 聚焦业务逻辑、接口联调与定制化开发
平台管理员 统一模板管理,保障页面&代码标准化 新增/更新业务模板,全团队快速复用
研发团队 缩短交付周期,降低跨角色沟通成本 减少需求迭代内耗,提升整体研发效率

二、产品方案设计

围绕「提效、降本、标准化」设计 5 大核心功能模块,无缝衔接现有工作流,无额外学习成本。

2.1 样板间平台(全流程中枢)

系统核心入口,负责模板、原型全生命周期管理,保障页面与代码标准化:

  • 模板中心:提供表单、表格查询页、详情页、日志页等标准化模板,内置预设字段、组件及基础交互;
  • 模板管理:支持模板增删改查、版本控制、业务线权限隔离,定期迭代更新模板;
  • 我的原型管理:产品可按任务 ID/创建时间/页面名称检索原型,支持编辑、删除与版本回溯。

2.2 原型配置 GUI(产品无编码工具)

可视化「所见即所得」配置工具,全程零代码操作:

  • 模板编辑:可视化调整字段、组件、布局、交互逻辑,支持必填项/校验规则配置;
  • 原型保存:自动生成低代码引擎标准 Schema,支持二次编辑与版本回溯;
  • 实时预览:配置过程实时查看页面效果,避免预期偏差;
  • PRD 导出:一键生成含原型 URL、截图、字段说明、交互规则的标准化 PRD,直接粘贴至文档平台。

2.3 AI 服务(自动化核心引擎)

实现 PRD↔Schema 双向互转、Schema→源码智能转译,替代人工转译:

  1. PRD↔Schema 互转
    • PRD 转 Schema:解析文档平台结构化/非结构化 PRD,智能识别页面元素、功能需求,生成可渲染 Schema;
    • Schema 转 PRD:解析配置好的 Schema,自动生成规范 PRD 文档,同步更新字段与交互规则。
  2. Schema 转源码
    将 Schema 转换为 React/Vue 标准化源码,代码满足高可读、可维护、统一规范,适配团队 ESLint 规则,便于二次开发。

2.4 浏览器插件(文档平台无缝对接)

打通文档平台与样板间平台,简化产品操作:

  • PRD 智能转换:文档平台内选中 PRD 内容,一键转换为 Schema 格式;
  • 自动跳转渲染:转换后自动跳转原型 GUI 界面,免除复制粘贴繁琐操作。

2.5 开发工具插件(前端专属提效)

VS Code 插件优化代码获取链路,开箱即用:

  • 智能任务关联:输入任务 ID 自动关联原型 Schema;
  • 即时代码获取:前端一键下载至本地(产品保存原型时,AI 已经自动生成了代码并保存到数据库中);
  • 开箱即用开发:基于标准化代码直接开展接口联调、交互定制;
  • 未来演进:计划整合浏览器插件,实现一站式工具集成。

2.6 全角色核心操作流程

用户角色 操作模块 核心操作流程
产品经理 模板中心/GUI/原型管理 选模板→创建原型→可视化配置→保存生成 Schema→导出 PRD→粘贴至文档平台
前端开发 开发工具插件 输入任务 ID→预览原型→一键下载代码→本地二次开发→上线发布

三、技术方案(可直接落地复用)

3.1 核心业务流程

3.1.1 全链路自动化流程

覆盖 PRD↔Schema 双向互转 + Schema 转源码,正向产品配置生成 Schema/PRD/代码,反向 PRD 解析生成 Schema 回显,全流程闭环无人工干预。

1. 选择标准化模板
2. 可视化配置原型
3. 保存配置,生成 Schema
4. AI 转译:Schema→PRD

反向能力:PRD→Schema

5. AI 转译:Schema→源码
6. 输入任务 ID 关联原型
7. 查询源码
8. 一键下载源码
9. 二次开发&上线

产品经理

样板间平台

原型配置 GUI

spc_page_schema_tab

文档平台

spc_page_code_tab

前端开发

开发工具插件

本地项目

上线发布

3.1.2 产品正向配置流程
文档平台 数据库 AI服务 后端服务 原型GUI 模板中心 PM 文档平台 数据库 AI服务 后端服务 原型GUI 模板中心 PM 选择模板(点击【使用】) 携带template_id跳转 请求模板Schema 查询模板数据 返回完整Schema 返回模板Schema 显示可编辑原型 修改字段并点击【保存】 提交prototype_schema 存储Schema(status=draft) 存储成功 保存完成 显示"保存成功" 点击【生成PRD】 请求生成PRD(含最新Schema) 发送Schema→PRD转换请求 返回结构化PRD文本 生成页面截图+预览URL 更新Schema(status=published) 更新确认 返回PRD文本+截图+URL 展示生成结果 手动复制粘贴PRD
3.1.3 前端代码获取流程

前端通过样板间 VSCode 插件,基于 Jira ID 一键获取标准化代码,支持二次开发与模型迭代反馈。

本地IDE 数据库 AI服务 后端服务 样板间VSCode插件 FE 本地IDE 数据库 AI服务 后端服务 样板间VSCode插件 FE loop [[可选反馈]] 输入Jira ID 请求Schema数据(jira_id) 查询published状态原型 返回原型Schema 返回Schema+页面元数据 展示页面列表 选择页面并确认下载 请求生成代码 发送Schema 返回标准代码结构 存储代码使用记录 存储成功 返回代码 下载至本地工程目录 二次开发 提交代码优化建议 上传代码差异片段 加入训练数据集

3.2 AI 代码生成核心输入

AI 代码转译依赖三类标准输入,协同完成「代码骨架 + 字段数据 + 转译逻辑」匹配,所有规范关联 3.3 协议体系。

3.2.1 样板间代码(JSON 格式)

根据样板间代码生成的基础结构模板,提供标准工程目录与业务代码。

  • 格式:JSON 对象,包含页面路径、文件结构、核心源码;
  • 作用:固定代码框架、引入规范、布局结构,保证生成代码风格统一;
  • 核心:内置映射注释供 AI 识别(遵循 3.3.1 代码注释规范协议),通过 @schema- 注释与 Schema 建立映射。
{
  "title": "spc-form-demo",
  "key": 1001,
  "path": "src/pages/spc-ui-demo/form-page",
  "children": [
    {
      "title": "index.tsx",
      "key": 1002,
      "type": "file",
      "isLeaf": true,
      "code": "import React from 'react';\nimport { ProForm } from 'react-pro-components';\nimport { Form, message } from 'spc-ui-react';\n\nconst FormPage: React.FC = () => {\n  return (\n    <div style={{ padding: 24 }}>\n      <ProForm.CardForm\n        formProps={{\n          initialValues: { username: 'admin', input: 'default' },\n          layout: 'horizontal'\n        }}\n        fields={[\n          [\n            { type: 'input', name: 'username', label: 'Username', required: true },\n            { type: 'password', name: 'password', label: 'Password' }\n          ]\n        ]}\n        onSubmit={async (form) => {\n          message.success(JSON.stringify(form.getFieldsValue()));\n        }}\n      />\n    </div>\n  );\n};\nexport default FormPage;"
    }
  ]
}
3.2.2 Schema 数据(低代码标准)

页面结构化数据源,连接配置平台与代码的核心载体,严格遵循 3.3.2 配置平台 Schema 协议

  • 格式:标准 JSON,核心模块:version/componentsMap/componentsTree/meta
  • 内容:描述组件、字段、布局、事件等 UI 配置。
{
  "version": "1.0.0",
  "componentsMap": [
    {
      "componentName": "ProForm",
      "package": "react-pro-components",
      "version": "1.0.0",
      "destructuring": true
    },
    {
      "componentName": "Form",
      "package": "spc-ui-react",
      "version": "1.0.0"
    }
  ],
  "componentsTree": [
    {
      "id": "form-page",
      "componentName": "Page",
      "children": [
        {
          "componentName": "ProForm.CardForm",
          "props": {
            "formProps": {
              "initialValues": { "username": "admin", "input": "default" }
            },
            "fields": [
              [{ "type": "input", "name": "username", "label": "Username", "required": true }]
            ]
          }
        }
      ]
    }
  ],
  "meta": {
    "name": "SPC Form Demo",
    "projectName": "spc-admin",
    "creator": "System"
  }
}
3.2.3 映射规则提示词

AI 转译执行准则,定义代码与 Schema 的匹配逻辑,严格遵循 3.3.3 代码转译规则协议

  • 作用:消除转译歧义,保证代码符合团队研发规范;
  • 核心:注释识别、区块分类、保留/删除策略、属性覆盖规则。

3.3 标准化协议约定

三大核心协议,规范代码注释、Schema 结构、AI 转译逻辑,与 3.2 输入一一对应。

3.3.1 样板间代码注释规范协议

协议目标

  • 为可与 Schema 映射的代码块添加统一格式注释,供 AI 精准识别
  • 注释中明确携带Schema 节点路径、业务绑定字段,建立一一对应关系

语法规范
支持单字段与代码区块两种注释格式,语法简洁统一:

// 单个字段映射
// @schema-mapping:<路径描述> | <绑定字段>

// 代码区块映射
// @schema-block-begin:<路径描述> | <绑定字段>
// 业务代码块
// @schema-block-end:<路径描述>

区块类型(这里选取两个高频业务场景举例)

区块类型 用途说明 典型挂载位置
table-filters 表格搜索筛选项区块 searchConfig.items
table-fields 表格列配置区块 columns

注释关键字段说明

字段名 说明
路径描述 基于 componentsTree 的节点路径,支持 dotPath 写法
绑定字段 对应组件 props.name/label 等业务标识字段

典型示例

// 表格搜索筛选项区块示例
// @schema-block-begin:componentsTree[0].children[0].props.searchConfig.items | product_name
{ label: '商品名称', name: 'product_name', type: 'input' }
// @schema-block-end:componentsTree[0].children[0].props.searchConfig.items

// 表格列配置区块
// @schema-block-begin:componentsTree[0].children[0].props.columns | product_name
{ title: '商品名称', dataIndex: 'product_name' }
// @schema-block-end:componentsTree[0].children[0].props.columns
3.3.2 配置平台 Schema 协议

低代码应用标准数据结构,是 Schema 数据的解析基础,这里举例两种结构。

ProjectSchema(应用根协议,定义了低代码应用的完整结构)

属性名 类型 必填 说明
version string 协议版本号(默认 1.0.0)
componentsMap Component[] 组件依赖映射表
componentsTree PageSchema[] 页面组件树
meta object 应用元数据

ComponentSchema(组件协议,单个组件树节点描述)

属性名 类型 必填 说明
id string 节点唯一标识
componentName string 组件名称
props object 组件属性
children array 子节点
3.3.3 代码转译规则协议
协议目标
  1. 保留样板间代码标准结构,保证团队代码风格统一
  2. 自动删除 Schema 中未定义的冗余 UI 结构
  3. 保留字段初始值、业务函数等自定义逻辑
核心转译规则

规则1:注释识别与区块匹配
AI 仅通过标准注释建立代码与 Schema 的映射关系,识别格式:

// 单字段映射
// @schema-mapping:<字段路径> | <字段名>

// 代码区块映射
// @schema-block-begin:<字段路径> | <字段名>
// 代码块内容
// @schema-block-end:<字段路径>

规则2:有效代码段保留

满足以下条件,保留代码结构,仅覆盖属性值

  1. 包含有效 @schema- 注释且路径与 Schema 匹配;
  2. 组件类型、字段 name 与 Schema 一致。

规则3:无效结构删除

满足任一条件,自动删除代码段:

  1. @schema- 注释,无任何映射关系;
  2. 字段 name 在 Schema 中不存在;
  3. 组件类型、注释路径与 Schema 不匹配。

规则4:属性值覆盖

  • 结构一致的代码段,以 Schema 配置为准覆盖核心属性:label/required/rules/initialValues/onSubmit
  • Schema 未定义的属性,保留样板代码原始值。

规则5:样板结构优先

以样板间代码结构为基准,不重构、不调整代码层级、分组与字段顺序,仅替换属性值。

规则6:业务逻辑保留
完整保留工程基础结构(import / export default、组件定义、页面布局容器)。

3.4 核心表结构设计(MySQL)

3.4.1 核心表总览
表名 中文名称 核心作用
spc_page_template 页面模板表 存储页面模板基础配置信息
spc_page_schema 页面 Schema 表 存储 GUI 配置后的页面 Schema 结构化数据
spc_page_code 页面代码表 存储 AI 生成的标准化前端代码
spc_operation_log 操作日志表 记录全流程操作,生成日志
3.4.2 分表详细设计

1. spc_page_template(页面模板表)
存储系统内置/自定义的页面样板模板,是代码生成的基础骨架来源

字段名 类型 约束 说明
id bigint 主键 自增 ID
template_name varchar(255) NOT NULL 模板名称
template_schema text NOT NULL 模板默认 Schema 结构
template_code text NOT NULL 模板样板代码(带注释)
create_time datetime NOT NULL 创建时间
update_time datetime NOT NULL 更新时间

2. spc_page_schema(页面 Schema 表)
存储用户在配置平台生成的页面 Schema 数据,关联模板与业务标识

字段名 类型 约束 说明
id bigint 主键 自增 ID
template_id bigint 外键 关联模板 ID
jira_id varchar(100) - 业务关联 Jira ID
page_name varchar(255) NOT NULL 页面名称
schema_json text NOT NULL 页面 Schema 结构化数据
operator_name varchar(100) NOT NULL 操作人名称
create_time datetime NOT NULL 创建时间
update_time datetime NOT NULL 更新时间

3. spc_page_code(页面代码表)
存储 AI 根据 Schema 生成的前端源码,支持多版本管理

字段名 类型 约束 说明
id bigint 主键 自增 ID
schema_id bigint 外键 关联 Schema ID
code_content text NOT NULL 生成的前端源码
version varchar(50) - 代码版本号
create_time datetime NOT NULL 创建时间

4. spc_operation_log(操作日志表)
记录 Schema 保存、代码生成、导出等全链路操作日志,用于审计排查

字段名 类型 约束 说明
id bigint 主键 自增 ID
schema_id bigint 外键 关联 Schema ID
operate_type varchar(50) NOT NULL 操作类型(生成/保存/导出)
request_json text - 请求参数数据
response_json text - 响应结果数据
operate_status tinyint NOT NULL 状态:0 失败;1 成功
cost_time double - 执行耗时(秒)
operator_name varchar(100) NOT NULL 操作人名称
create_time datetime NOT NULL 日志生成时间
3.3.3 表关联关系
  1. 一对多spc_page_template.idspc_page_schema.template_id(一个模板对应多个 Schema)
  2. 一对多spc_page_schema.idspc_page_code.schema_id(一个 Schema 生成多版代码)
  3. 一对多spc_page_schema.idspc_operation_log.schema_id(一个 Schema 对应多条操作日志)

3.5 核心接口设计

适配页面模板、Schema、代码生成、文件上传全场景业务,接口语义清晰、易维护。

接口说明 请求方法 接口路径 入参 返回值 备注
根据模板 ID 查询页面模板 GET /spc/template/template/{id} 模板 ID 模板基础信息+样板代码 路径传参
根据 Jira ID 查询 Schema GET /spc/template/schema/jira/{jiraId} Jira ID Schema 结构化数据 业务关联查询
根据 Schema ID 查询 Schema GET /spc/template/schema/{schemaId} Schema ID 完整 Schema 配置 详情查询
新增/更新 Schema POST /spc/template/schema Schema 结构化数据 操作结果+ID 传ID=更新,不传=新增
根据 Schema ID 删除 Schema DELETE /spc/template/schema/{id} Schema ID 操作结果 逻辑删除/物理删除
Schema 列表分页搜索 GET /spc/template/schema/list 分页参数/搜索关键词 Schema 列表+分页信息 支持名称、Jira ID 筛选
Schema 转前端代码 POST /spc/template/schema-to-codes Schema 结构化数据 生成的代码实体 核心AI代码生成接口
根据 Schema ID 查询前端代码 GET /spc/template/code/{schemaId} Schema ID 代码内容+版本信息 一对一关联查询
图片上传至 CDN POST /spc/template/upload/cdn form-data(文件) 文件 CDN 地址 支持图片/附件上传

3.6 模板 ID 编码规范(8 位数字)

模板 ID 采用 8 位数字分层编码,按「端类型+业务属性+模板类型+细分变种」四级定义,用于唯一标识、分类管理所有页面模板。

3.6.1 编码结构

[端类型(2位)][业务属性(2位)][模板类型(2位)][细分变种(2位)]

位数 名称 说明
1-2 端类型 设备端标识(PC/移动端)
3-4 业务属性 通用/各业务线专属
5-6 模板类型 页面类型(表格/表单/详情/日志)
7-8 细分变种 模板细分类型 + 版本序号
3.6.2 字段取值规范

1. 端类型(1-2位)

编码 类型
01 PC 端
02 移动端(预留)
03 小程序(预留)

2. 业务属性(3-4位)

编码 类型
01 通用
02 业务线 A
03 业务线 B
04 业务线 C
05 业务线 D

3. 模板类型(5-6位)

编码 类型
01 表格查询页
02 表单页
03 详情页
04 日志页

4. 细分变种(7-8位)

  • 固定规则:从 01 开始自增编号
  • 代表同类型下的不同页面形态(基础版、带 Tab 版、高级版等)
3.6.3 核心编码映射表
端类型 业务属性 模板类型 细分变种 模板ID 模板名称
01 PC 01 通用 01 表格查询页 01 基础表格 01010101 基础表格查询页
02 带Tab表格 01010102 带 Tab 表格查询页
03 高级表格 01010103 高级表格查询页
02 表单页 01 基础表单 01010201 基础表单页
02 高级表单 01010202 高级表单页
03 分步表单 01010203 分步表单页
03 详情页 01 基础详情 01010301 基础详情页
04 日志页 01 基础日志 01010401 基础日志页
3.6.4 设计优势
  • 唯一性:8 位编码全局唯一,无冲突
  • 可读性:层级清晰,一眼识别模板属性
  • 扩展性:预留编码位,支持后续业务扩展
  • 易管理:按规则自动生成,便于检索维护

四、总结与展望

4.1 方案总结

本方案通过样板间管理、可视化配置、AI 智能转译、插件化集成的技术架构,建立了从原型配置到代码产出的标准化、自动化链路,完整补齐了前端通用页面从配置到研发的提效短板。
整套体系以协议规范、表结构、接口设计为落地基石,兼顾通用性与扩展性,既保证页面与代码风格统一,又支持业务定制化开发,可平稳融入现有研发协作模式。

4.2 落地实施建议

4.2.1 快速启动阶段
  • 依托成熟低代码引擎快速搭建可视化配置界面,优先上线表格、表单等高频通用模板;
  • 采用“通用大模型+团队代码微调”的方式快速实现 AI 转译能力,缩短建设周期;
  • 先落地 VS Code 插件,打通前端“任务 ID 取码”核心流程。
4.2.2 迭代优化阶段
  • 持续扩充业务专属模板,完善模板版本与权限管控,提升自动化覆盖场景;
  • 基于操作日志与开发反馈,迭代 AI 转译规则,进一步提高生成代码可用性;
  • 集成浏览器插件,实现 PRD 与原型平台的无缝衔接。
4.2.3 长期扩展方向
  • 延伸移动端、小程序等多端模板体系,复用现有编码与协议规范;
  • 构建源码反向生成 Schema 的能力,实现配置与代码双向同步;
  • 打通 Jira、CI/CD 等研发工具,形成更完整的自动化研发闭环。

4.3 价值与意义

该方案在实现通用页面高效产出的同时,沉淀了可复用的模板、协议与代码资产,有效降低团队协作与新人上手成本。长期来看,可持续释放研发人力,让前端聚焦复杂业务与体验创新,逐步构建标准化、自动化、可规模化复制的前端研发能力体系。

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐