新产品快速验证 从业务构想到交付研发
交付清单
新产品快速验证｜全流程方法报告

新产品快速验证：从业务构想到交付研发

以体育赛事直播平台为例，展示 Codex 如何完成需求补全、Figma 映射、全栈开发、本地验收，并将成果交付研发。

本次验证路径 01业务提出想法与输入材料 02Codex 补全、开发与验收 03研发接手源码与上线改造
日期2026-08-28
测试案例体育赛事直播平台
当前状态本地 MVP 已跑通
报告依据实际操作与截图证据
1.1

背景与框架定位

这套方法形成的背景是：新业务立项较多，需要更快形成可运行版本，先验证方向，再决定是否投入正式研发。

一句话说明：这是一套以 Codex 为主要执行工具的新业务快速开发框架。业务人员将业务想法、PRD、Figma 和开发规则提供给 Codex；Codex 负责补全、开发、启动、检查和打包，最终将可运行项目及配套材料交付研发继续完善。

为什么需要这套流程

立项数量多

每个想法都直接进入正式研发，时间和人力成本太高。

先验证再投入

先做本地 MVP，确认业务方向、页面和闭环是否成立。

统一输入标准

业务想法、PRD、Figma 和开发规则按同一顺序提交给 Codex。

降低重复工作

Codex 复用通用工程、接口结构、数据库配置和开发规范，不必每次从零搭建。

全栈快速模板具体干什么

组成作用不等于什么
后端底座提供Django＋DRF工程、接口组织、数据库配置、迁移和开发规范。不等于已经包含所有新业务接口。
前端底座提供UniApp/Vue 3基础工程、目录、启动方式和兼容规则。不等于已经生成完整产品页面。
统一开发规则告诉 Codex 先读哪些文档、怎么拆模块、怎么检查和交付。不等于输入一句话就能自动完成正式上线。
快速验证能力减少搭建基础工程的时间，让 Codex 把工作集中在本次业务功能和闭环上。不等于替代研发完成生产级改造与上线。

四个关键角色与环节

业务人员

向 Codex 提供业务想法、目标用户、范围、PRD、Figma 和重要规则。

Codex

读取输入，补齐需求，生成前端、后台接口、数据库、测试和交付材料。

本地 MVP

作为立项验证结果，回答业务闭环是否成立、是否值得继续投入。

研发团队

接手源码与文档，完成生产级服务改造、真实账号接入、安全与运维保障，并推动正式上线。

1.2

从业务构想到交付研发的完整六步

标准方法和本次实际操作合并在这一套流程中：每一步同时说明谁来做、Codex 做什么、产出什么。

第 1 步｜业务人员把新业务想法交给 Codex讲清楚项目、目标用户、核心功能、范围和交付要求。
第 2 步｜Codex补全需求并生成 PRD补齐角色、流程、页面、权限、数据、状态、异常和验收标准。
第 3 步｜Codex读取 PRD、Figma 和开发规则把需求与真实设计页面对应，并识别缺失、冲突和排除项。
第 4 步｜Codex生成前端、接口和数据库基于全栈模板完成页面、组件、接口、数据模型和前后端联调。
第 5 步｜Codex＋业务本地预览并检查完成度Codex 启动服务并逐页检查，业务人员对照目标确认结果。
第 6 步｜Codex→研发打包代码和文档交研发交付源码、接口、数据库、启动说明、测试结果和上线边界。
最终目的不是让 Codex 直接替代研发上线，而是在大量立项中快速做出可运行版本；方向通过后，再把验证结果和完整交付包交给研发。
2.1

输入材料一：全栈快速模板

先确认模板真实有什么，再决定怎么用；不能把设想中的自动化能力当作模板已经具备的功能。

全栈快速模板压缩包
本次输入文件：全栈快速模板.zip，提供基础工程与开发规范。
ZIP全栈快速模板.zip已嵌入单文件 HTML，接收方可直接下载

为什么要用这个模板

核心原因：立项多的时候，如果每次都让 Codex 从空目录重新决定技术栈、文件结构、接口规范和启动方式，不仅慢，而且每个项目的结构都不一样，后续很难检查、复用和交给研发。模板先把这些共性问题固定下来，让 Codex 只集中处理本次新业务。

更快做出首版

基础工程、依赖、目录、数据库连接和启动命令已经有统一底座，减少重复搭建时间。

输出更加稳定

Codex 按同一套开发规则工作，避免不同项目随意换技术栈、目录和接口写法。

更容易检查

需求、接口、数据库、测试和交付物都有固定位置，可以快速判断缺了什么、做到哪一步。

研发更容易接手

项目结构、启动方式和文档口径统一，研发不用先花大量时间重新理解一个临时工程。

模板解决的是共性问题，业务内容仍要重新做

已经验证

Django＋DRF 后端底座、UniApp 前端基础工程、API/数据库配置、README 与开发规范。

需要项目补充

正式 PRD、Figma 页面映射、业务模型、手机端实际页面、管理后台、测试与交付材料。

不能直接宣称

模板自带需求 Agent、自动读取全部 Figma、自动完成度检查、自动正式上线。

怎么操作

  1. 把模板 ZIP 提交给 Codex，并要求保留原包，在独立项目目录中工作。
  2. Codex 依次读取根 README、后端 README、提示词/API 文档和移动端 README。
  3. Codex 提取固定技术栈、目录规则、启动方式、禁止项和交付要求。
  4. Codex 建立新的业务工程目录，本轮为 sports-live-platform。
使用结论模板的价值不是“替业务做需求”，而是把重复的工程准备工作标准化。这样 Codex 能更快完成新业务验证，研发也更容易在同一底座上继续开发。
2.2

输入材料二：新业务想法

本次把“体育赛事直播与运营管理平台”的业务目标、使用角色、核心闭环和测试范围直接交给 Codex。

提交给Codex的体育直播平台业务想法
你提供的业务想法截图：先把项目名称、项目目标、目标用户和核心功能交给 Codex。此时不需要先写成完整 PRD，Codex 会在下一步继续追问并补齐。

手机观众端

查找赛事、查看赛程与详情、观看模拟直播、收藏、预约、查看观看记录。

电脑运营后台

创建和编辑赛事、配置球队与分类、安排直播场次、发布/下架、查看运营数据。

给 Codex 的第一轮输入应该写什么

字段本轮确定内容
项目名称体育赛事直播与运营管理平台
产品关系同一个平台的手机观众端＋电脑管理后台＋统一后端数据库
核心目标验证从需求、Figma、全栈开发到本地验收，并将成果交付研发的完整流程
本期范围本地浏览器可运行的 MVP；使用演示身份、演示赛事数据和测试视频
非本期真实赛事版权、支付、商业直播链路、正式登录和生产部署
通过门禁Codex 已确认手机端和后台是同一个体育直播业务的两个端；业务范围、角色边界和本期排除项全部明确。
2.3

输入材料三：正式 PRD

Codex 先补齐需求并生成正式 PRD；“本地测试”只写在本期范围和验收环境中，不写进产品名称。

PRD体育赛事直播与运营管理平台_PRD_V1.1_评审稿.docx已嵌入单文件 HTML，可直接下载的正式需求文档
PRD封面与目录
真实文档截图：最终 PRD V1.1 封面、评审摘要和文档导航。
PRD用户角色和业务流程
真实文档截图：用户角色、核心使用场景与后台创建发布赛事流程。

补全顺序

  1. 业务人员把初始想法交给 Codex，Codex 先补齐项目目标、成功指标、假设和范围边界。
  2. Codex 继续整理用户角色、端到端流程、页面清单与状态流转。
  3. Codex 把功能拆成 FR，把接口拆成 API-01—API-18，把验收拆成 AC-001—AC-020。
  4. Codex 补齐数据模型、权限、审计、错误结构、非功能要求和面向研发的交接清单。
  5. Codex 生成并渲染 Word，逐页检查中文字体、跨页表格、页脚、留白和编号，形成最终 V1.1。

产品

目标、角色、场景、范围、页面

业务

规则、状态、异常、权限、审计

技术

数据模型、18个接口、错误结构

验收

20项AC、追踪矩阵、交付清单

通过门禁PRD 已经可以直接用于页面映射、开发拆分和验收，且没有把研究说明或工具介绍混入正式产品定位。
2.4

输入材料四：两套 Figma 设计

把两个 Figma 链接和目标页面交给 Codex：Figma 负责视觉与交互基线，PRD 决定本期业务范围。

UISportify｜手机观众端赛事、赛程、详情、直播和个人页面的视觉参考figma.com/community/file/1243177564322785730 CMSCMS｜电脑管理后台侧栏、看板、列表、筛选和表单的视觉参考figma.com/community/file/1428714896006523104
Sportify手机端Figma工作区截图
你提供的手机端 Figma 截图：Codex 从 Sportify 工作区识别 Dashboard、Login、Football、Cricket、Basketball、News 等页面组，以及导航、搜索和组件层级。
CMS电脑管理后台Figma工作区截图
你提供的后台 Figma 截图：Codex 从 CMS 工作区识别登录、Dashboard、内容列表、表单、用户管理、权限和工具类页面，作为电脑管理后台的结构参考。
Figma映射总览
真实映射表截图：目标页面、PRD功能数量、可复用设计系统、当前结论与来源地址。
移动端逐页映射
移动端12项映射：每页对应 PRD、需求FR、接口、数据实体、Figma证据、状态、验收AC和开发建议。
后台逐页映射
后台8项映射：识别哪些页面可以复用，哪些需要业务改造或新增画板。

映射时逐项记录

检查项怎么判断本轮处理
PRD有，Figma也有结构与业务目标一致复用视觉系统并替换业务数据
PRD有，Figma没有收藏、预约、历史、异常、球队管理等沿用同一设计体系补页
Figma有，PRD不需要新闻、投票、电纸报、联系人等明确排除，不擅自扩大本期范围
两者有冲突字段、状态或角色不一致以PRD业务规则为准，记录差异
通过门禁Codex 已把页面目标、业务字段、接口、数据实体、状态和验收标准逐项对应；缺失、冲突和排除项均有记录。
3.1

Codex 评估可行性并拆分开发

Codex 先判断“能不能开发、缺什么、按什么顺序做”，通过门禁后再开始写代码。

手机观众端
  • UniApp＋Vue 3
  • 首页、发现、详情、直播
  • 收藏、预约、历史
  • 演示身份 demo-viewer
统一后端与数据库
  • Django＋DRF
  • API-01—API-18
  • SQLite 演示数据
  • 统一错误、审计、版本
电脑管理后台
  • Vue 3＋Vite
  • 赛事、排期、资料管理
  • 发布/下架、数据概览
  • 演示管理员门禁

五个开发批次

  1. 模型与接口：分离发布状态和直播状态，补版本、审计、异常状态。
  2. 手机端主路径：首页 → 发现 → 详情 → 直播。
  3. 后台主路径：概览 → 赛事列表 → 编辑 → 直播排期 → 基础资料。
  4. 个人数据与全局状态：收藏、预约、历史、加载/空/错/下架。
  5. 联调与验收：双端数据一致性、权限、构建、浏览器检查、交付材料。
通过门禁技术栈不需要推翻；PRD、Figma和模板能够组合开发，主要风险已转化为明确的补页、接口和上线边界。
3.2

Codex 开发后端、数据库与接口

Codex 先在后端固化业务规则，再让两套前端接同一份数据，避免手机端和后台各自维护假数据。

核心模型

Event、LiveSession、Team、SportCategory、Favorite、Reservation、WatchHistory、AuditLog。

核心规则

发布/直播状态分离、主场次唯一、版本冲突、引用保护、预约与观看阈值。

工程保障

迁移、演示数据、统一错误、request_id、OpenAPI 3.1、16项自动测试。

实际操作顺序

  1. 创建模型和迁移，先解决 PRD 与模板旧模型的结构差异。
  2. 按 API-01—API-18 建 serializer、view、URL 与权限。
  3. 加入演示身份、管理员请求头、统一错误和操作审计。
  4. 编写 seed_demo，生成3场赛事、球队、分类、直播场次和个人数据。
  5. 生成并校验 OpenAPI，再运行迁移一致性、系统检查和测试。
$ python manage.py makemigrations --check --dry-run No changes detected $ python manage.py test models ................ Ran 16 tests · OK $ python manage.py spectacular --file schema.yml --validate OpenAPI 3.1 校验通过
通过门禁迁移无遗漏、16项测试通过、系统检查通过、OpenAPI校验通过；手机端和后台可以从同一后端读取一致数据。
3.3

Codex 开发手机观众端

Codex 沿用 Sportify 的视觉骨架，把赛事数据、中文业务和 PRD 要求接入真实接口。

移动端首页
M01 首页
直播、即将开始、分类入口
赛事发现
M02 赛事发现
项目、状态与赛程列表
赛事详情
M03 赛事详情
比分、球队、内容与状态
直播页面
M04 直播播放
测试媒体、播放与异常
个人中心
M05–M06 个人数据
收藏、预约、观看记录

实现重点

页面还原

390×844 基线、卡片、字体、导航、状态颜色。

真实接口

赛事列表、详情、直播、收藏、预约、历史。

状态完整

加载、空、错误、下架、媒体失败和重试。

本地验收

电脑浏览器模拟手机尺寸即可，不强制测试机。

通过门禁M01—M07 均有可运行页面，主路径已在浏览器逐页检查，H5发布构建检查通过。
3.4

Codex 开发电脑管理后台

Codex 保留 CMS 的侧栏、表格和表单语言，把通用“内容管理”改造成赛事运营业务。

管理后台概览
A01 运营概览：全部赛事、正在直播、即将开始、用户预约与最新赛事。
赛事管理
A02 赛事管理：列表、筛选、状态、编辑、发布与下线。
新建赛事
A03 赛事编辑：名称、标识、项目、主客队、时间、场馆、封面和简介。
后台Figma参考
视觉对照：沿用原 CMS 的侧栏、数据卡片、表格、筛选和表单体系。

A01—A08 覆盖

页面本轮实现关键校验
A01 运营概览赛事、直播、预约、最新赛事与手机端统计一致
A02–A03 赛事管理/编辑新增、编辑、发布、下线必填、时间、版本冲突、发布完整性
A04 直播排期场次、媒体地址、直播状态主场次唯一、合法状态流转
A05 基础资料项目分类、球队、启停引用保护与重复校验
A06–A08内容状态、数据详情、通用状态权限、错误、空状态、重试
通过门禁A01—A08 均有可运行页面，后台五个P0模块已经浏览器实测，发布构建检查通过。
4.1

Codex 联调、测试并整理验收证据

Codex 不只检查“页面能打开”，还要核对业务规则、接口、数据库、双端一致性、异常状态和发布构建检查。

后端

16项测试全部通过；迁移、系统检查、OpenAPI通过。

移动端

H5发布构建检查通过；首页、发现、详情、直播、个人中心实测。

管理后台

Vue 3发布构建检查通过；五个P0模块实测。

双端闭环

赛事、比分、状态、排期、收藏与预约数据一致。

20项验收结果

范围验收项结论
观众主路径AC-001 首页、002搜索筛选、003详情、004模拟直播、005播放异常通过
个人数据AC-006收藏、007预约、008观看历史通过
后台业务AC-009新建、010编辑、011发布下架、012排期、013分类球队通过
系统质量AC-014双端一致、015权限、016异常、017接口文档、019启动、020交付包通过
设计还原AC-018 页面结构、设计体系和浏览器视觉检查结构级通过；像素Token待复核
覆盖矩阵截图
覆盖矩阵截图：把 PRD 页面、需求、接口、验收和 Figma 证据放进同一张表，防止只验页面、不验规则。
通过门禁自动测试、发布构建检查和浏览器主路径全部通过；20项AC有明确证据和边界，不能用“看起来差不多”代替验收。
4.2

Codex 启动三个服务并打开页面

开发完成后，Codex 同时启动后端、手机端和管理后台，进行真实联调和逐页检查。

三个服务启动并打开截图
真实完成截图：后端、移动端和管理后台服务都已启动，浏览器已打开移动端和管理后台两个标签页。

终端 1｜后端

cd /Users/tom/Documents/ChatGPT/agent/sports-live-platform/backend
./.venv/bin/python manage.py runserver 127.0.0.1:8000

终端 2｜移动端

cd /Users/tom/Documents/ChatGPT/agent/sports-live-platform
pnpm dev:mobile

终端 3｜管理后台

cd /Users/tom/Documents/ChatGPT/agent/sports-live-platform
pnpm dev:admin
入口地址怎么看
移动端http://127.0.0.1:5173/电脑浏览器使用约390×844手机尺寸查看
管理后台http://127.0.0.1:5174/电脑浏览器正常宽屏查看
接口文档http://127.0.0.1:8000/api/docs/查看并调试 OpenAPI 接口
状态说明：截图证明三个服务已经完整启动并打开过；服务进程停止后端口不会继续监听。以后说“全部跑完”是指本地 MVP已跑通并验收，不代表它永远在后台运行。
4.3

给研发的交付包与正式上线边界

Codex 的工作在“可运行、可验证、可接手”处完成；研发从这套交付包开始生产级改造，而不是把本地 MVP 直接发布上线。

⇩
单文件转发说明下面 9 份文件已经真正嵌入本 HTML。你只要把“单文件版 HTML”发给别人，对方打开后即可点击下载，不依赖你电脑上的原路径；两个 Figma 链接需要联网访问。

A. 研发收到什么

SRC研发接手源码包 ZIP后端、移动端、管理后台、数据库与项目文档 PRDPRD V1.1 评审稿17 页需求、范围、接口与验收定义 XLSXFigma 逐页面映射表页面、接口、数据与验收对照 DOC项目启动说明技术栈、依赖、运行地址和启动方式 AC20 项验收矩阵需求、证据、测试结果和发布判断 UIFigma 结构映射文档手机端 M01–M07、后台 A01–A08 !已知问题与上线边界生产部署前必须替换和补齐的能力 APIOpenAPI 3.1前后端接口契约与联调依据 BASE本次输入的全栈快速模板研发可核对原始底座与本次业务改造

B. 研发接手后按什么顺序做

  1. 下载源码包，按 README 安装依赖，补齐本机环境变量。
  2. 恢复数据库并启动后端、移动端和管理后台，先复现本报告中的本地 MVP。
  3. 重新运行 16 项后端测试、双端发布构建检查和 AC-001—AC-020，确认交付基线没有丢失。
  4. 把演示身份、测试视频、远程演示图片和 SQLite 逐项替换为正式基础设施。
  5. 完成安全、权限、监控、备份、发布流水线和生产环境部署。
  6. 由产品、设计、测试和研发共同完成 UAT 与上线评审后再发布。

C. 当前完成与正式上线的分界

能力Codex 已交付的本地 MVP研发上线前必须补齐
业务闭环赛事发现、详情、测试直播、收藏预约、观看历史、赛事管理、排期和基础资料已跑通业务侧确认真实运营流程、角色与上线规则，完成 UAT
账号与权限演示观众身份和演示管理员门禁真实登录、账号体系、RBAC、会话安全、密码与审计策略
直播能力公开测试视频用于播放和异常状态验证合法版权、商业直播供应商、推流/转码、CDN、DRM 和容灾
数据与存储SQLite 演示库、演示赛事和远程测试图片PostgreSQL、对象存储、缓存、备份恢复、数据迁移与访问控制
通知与外部服务页面内预约结果和状态反馈短信、邮件或 App Push，正式供应商、模板、限流和失败补偿
安全与运维本地 HTTP、开发环境配置、自动测试与发布构建检查HTTPS、密钥管理、WAF/限流、日志监控、告警、CI/CD、灰度和回滚
设计还原真实页面读取、结构映射、资产引用和设计体系还原设计师用 Dev Mode 复核精确 Token、组件属性、导出资产和像素级细节

D. 谁对什么负责

Codex 交付责任

源码能运行，接口和数据库能联调，测试能复现，文档与已知边界齐全。

产品责任

确认真实业务规则、运营流程、本期范围和 AC，组织最终 UAT。

研发责任

完成生产架构、正式服务、安全性能、部署运维和上线后的技术保障。

设计与测试责任

复核视觉 Token、终端兼容、回归测试、非功能测试和上线质量。

准确结论：这套交付物可以作为研发接手和继续开发的基线，但不能直接当作生产系统上线。正式上线必须经过生产级替换、联合验收和上线评审。
5.1

这套方法以后怎么复用

下一次换成别的产品时，保留流程和门禁，替换业务想法、PRD、Figma和业务代码。

可复用每个新项目必须重新做
十步流程、PRD结构、Figma映射字段、开发批次、验收矩阵、交付清单项目目标、用户角色、业务规则、页面清单、接口、数据模型、Figma节点和上线边界
Django/DRF＋UniApp/Vue 3 基础工程和启动方式业务模型、权限、状态、演示数据、页面内容和视觉资源
加载/空/错/权限/下架等通用状态方法本项目实际需要哪些状态，以及每种状态的业务文案和处理方式

复制执行检查表

  1. 一句话确定是什么产品、给谁用、解决什么问题。
  2. 确认端、角色、核心闭环和本期不做什么。
  3. 生成正式PRD，至少包含页面、FR、API、数据、状态和AC。
  4. 读取真实Figma页面与Frame，不用封面截图冒充完整设计。
  5. 建立逐页映射，记录复用、补页、冲突和排除项。
  6. 先解决数据模型和接口，再做前端主路径。
  7. 每个批次都运行测试并查看实际页面。
  8. 最终同时启动所有服务，做双端数据一致性检查。
  9. 按AC逐条验收，不用“基本完成”代替证据。
  10. 交付源码、启动说明、接口、数据库、测试结果和上线边界。
最终门禁只有“能运行、能操作、数据能保存、双端能对应、测试能通过、边界写清楚”，才算这一轮测试真正跑完。