供应链产研交付提效:AI 驱动“PRD→页面→源码”全流程自动化方案
摘要
传统前端研发流程中,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→源码智能转译,替代人工转译:
- PRD↔Schema 互转
- PRD 转 Schema:解析文档平台结构化/非结构化 PRD,智能识别页面元素、功能需求,生成可渲染 Schema;
- Schema 转 PRD:解析配置好的 Schema,自动生成规范 PRD 文档,同步更新字段与交互规则。
- 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 回显,全流程闭环无人工干预。
3.1.2 产品正向配置流程
3.1.3 前端代码获取流程
前端通过样板间 VSCode 插件,基于 Jira ID 一键获取标准化代码,支持二次开发与模型迭代反馈。
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 代码转译规则协议
协议目标
- 保留样板间代码标准结构,保证团队代码风格统一
- 自动删除 Schema 中未定义的冗余 UI 结构
- 保留字段初始值、业务函数等自定义逻辑
核心转译规则
规则1:注释识别与区块匹配
AI 仅通过标准注释建立代码与 Schema 的映射关系,识别格式:
// 单字段映射
// @schema-mapping:<字段路径> | <字段名>
// 代码区块映射
// @schema-block-begin:<字段路径> | <字段名>
// 代码块内容
// @schema-block-end:<字段路径>
规则2:有效代码段保留
满足以下条件,保留代码结构,仅覆盖属性值:
- 包含有效
@schema-注释且路径与 Schema 匹配; - 组件类型、字段
name与 Schema 一致。
规则3:无效结构删除
满足任一条件,自动删除代码段:
- 无
@schema-注释,无任何映射关系; - 字段
name在 Schema 中不存在; - 组件类型、注释路径与 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 表关联关系
- 一对多:
spc_page_template.id→spc_page_schema.template_id(一个模板对应多个 Schema) - 一对多:
spc_page_schema.id→spc_page_code.schema_id(一个 Schema 生成多版代码) - 一对多:
spc_page_schema.id→spc_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 价值与意义
该方案在实现通用页面高效产出的同时,沉淀了可复用的模板、协议与代码资产,有效降低团队协作与新人上手成本。长期来看,可持续释放研发人力,让前端聚焦复杂业务与体验创新,逐步构建标准化、自动化、可规模化复制的前端研发能力体系。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐


所有评论(0)