04 · Coding

把品牌体验做成可持续运行的数字系统。

公开界面、原型证据与交付结构共同说明每个项目如何被设计、实现、验证与持续运营。

上线状态与原型状态明确区分。登录后的私有界面不会被推断或补造。

01

AII 数字品牌与运营系统

一个连接品牌内容、服务、预约、咨询与商业准备能力的多语言官网及独立运营后台。

真实上线项目

范围
品牌官网 · 运营后台 · 数据与业务服务
技术
Next.js · React · TypeScript · Cloudflare Workers · D1
状态
已上线并支持持续运营
访问 AII 网站

公开端 Live Reel

从真实公开界面开始。

REEL录屏 · 1440 × 900待用户提供

REEL · AII 公开网站

完整录制的公开网站,是这个案例的第一份证据。

界面证据

同一入口,在两种屏幕上的样子。

F01桌面截图 · 1440 × 900待用户提供

F01 · AII 公开网站桌面首屏

公开入口将品牌导航与语言选择放在同一清晰界面。

F02手机截图 · 390 × 844待用户提供

F02 · AII 公开网站移动端导航

响应式层级让窄屏上的核心路径保持清晰。

F03细节截图 · 1440 × 810待用户提供

F03 · AII 公开网站品牌内容区

编辑内容是可运营的公开界面,而非一次性的静态活动页。

F04细节截图 · 1440 × 810待用户提供

F04 · AII 公开网站服务入口

服务发现将内容阅读连接到明确的行动路径。

系统图

后台与业务系统如何搭建

公开站与运营后台作为独立界面部署。前台动作通过受保护的服务接口进入系统;内容、预约、沟通与商业数据按领域拆分,并设置清晰的访问边界。

  • 界面
  • 服务
  • 数据

01界面 · 访客

公开品牌站

承载多语言品牌内容、服务、产品、预约与联系路径。

公开提交

02服务

受保护的服务层

通过来源校验、验证码、请求体限制与速率控制保护公开提交。

领域数据记录

04数据

D1 数据领域

拆分运营、内容与商业记录,并以迁移、审计轨迹和恢复路径保障可维护性。

03界面 · 运营人员

独立运营后台

以角色权限保护仪表盘及内容、媒体、服务、日历、邮件、SEO 与订单工作流。

迁移与审计轨迹

交付轨迹

完成的工作,与可核对的证据绑定。

01

品牌体验

以 Next.js 与 TypeScript 构建可复用页面,覆盖首页、品牌理念、服务、商店、内容、联系与法律页面,并统一中英路由与响应式规则。

02

运营后台

搭建独立运营应用,覆盖仪表盘、内容发布、媒体、服务、日历可用时段、预约、邮件模板、SEO、订单与设置。

03

业务工作流

将公开接口与预约可用时段、联系与订阅、内容发布、通知、支付及订单相关服务连接成可执行流程。

04

数据与权限

规划数据库迁移、内容与订单模型、角色边界、审计记录与恢复路径,让日常运营可追溯、可管理。

05

发布质量

待补充

建立代码、类型、页面结构与国际化检查,并通过预览/生产环境治理和回滚验证支撑持续迭代。

Web Coding 主导——前端体验与后端业务落地

公开证据与运营系统这些画面证明公开体验。下方的发布、预约、商业与审计流程属于交付系统结构说明,不将其伪装为公开后台画面。

证据图 01-04 + 系统图

02

司南造物三端 Web 全栈交付

已上线的三端数字服务系统:会员端承接品牌与服务体验,员工端支持一线工作,管理端集中处理经营与治理。

真实上线项目

服务入口
会员端 · 员工工作端 · 管理端
核心业务
商品交易 · 会员关系 · 运营管理 · 权限治理
状态
已上线三端 Web 项目
访问会员端网站

公开端 Live Reel

从会员真正会打开的那一屏开始。

REEL录屏 · 1440 × 900待用户提供

REEL · 公开会员端

录屏停留在公开会员端,并在触发真实验证请求前结束。

F01手机截图 · 390 × 844待用户提供

F01 · 公开会员端390 宽移动端入口

会员路径在触控尺度下仍然可用。

公开流程

验证入口、操作状态与公开浏览是同一条路径。

  1. F02状态截图 · 1440 × 1080待用户提供

    F02 · 公开会员端桌面验证入口

    面向会员的公开入口提供受控的首要操作。

  2. F03状态截图 · 1440 × 1080待用户提供

    F03 · 公开会员端操作状态

    界面明确呈现下一步公开操作。

  3. F04状态截图 · 1440 × 1080待用户提供

    F04 · 公开会员端公开浏览路径

    在不触发真实验证请求的情况下,访客仍可进入公开浏览路径。

F05细节截图 · 1440 × 810待用户提供

F05 · 公开会员端公开界面细节

说明待补充:这一帧承载哪一处公开细节,尚未由项目方确认。

系统图

同一业务系统,三种角色界面

系统没有把同一套后台直接交给所有人,而是围绕角色拆分:会员完成验证与服务访问,员工处理日常业务,运营人员集中治理商品、订单、会员及系统规则。

  • 界面
  • 服务
  • 数据

01界面 · 会员

会员端

以移动端为主,承载品牌内容、手串验证、商城访问与会员服务。

实体关系

02界面 · 员工

员工端

登录后围绕查询、录入、处理与业务协作组织低学习成本的工作界面。

状态流转

03界面 · 运营人员

管理端

集中管理商品、订单、会员、积分、员工、批次、租户、风控、审计与系统配置。

校验与操作反馈

04数据

共享业务状态

以稳定的实体关系、状态流转、表单校验与操作反馈连接前端、服务接口和数据库。

交付轨迹

完成的工作,与可核对的证据绑定。

01

会员端体验

将品牌调性落实为可读的内容层级、明确行动入口与连贯的移动端节奏,承接浏览、商品内容与会员服务。

02

员工工作端

围绕登录后的真实任务组织工作流,以可预期反馈支持查询、处理与协作,降低一线使用的理解成本。

03

运营管理端

实现可扩展的信息架构与高频管理界面,覆盖商品、订单、会员、积分、员工与配置等模块。

04

治理流程

通过列表、详情、筛选、批量操作、状态标签与审批路径,让业务状态、规则与异常处理可读、可执行。

05

数据协同

围绕会员、商品、订单、积分、员工、批次、租户、风控与审计日志组织数据呈现,支持前后端及数据库稳定衔接。

Web Coding——三端前端交付、后台业务流程与数据协同

公开证据与私有边界这些画面仅展示公开会员端。下方员工端与管理端为依据项目文件的交付结构说明,不展示或暗示登录后的私有界面。

证据图 01-05 + 系统图

03

艺人私域会员四端基础设施

连接会员身份、官方内容、艺人活动、资格抽签、第三方票务、现场核验与异常治理的四端高保真产品原型。

高保真原型

范围
4 端 · 726 项页面与状态记录
技术
React 19 · TypeScript · Vite · Playwright
状态
高保真原型 · 未声称正式上线

原型总览

把 726 项页面与状态记录组织成一个可导航原型

把 726 项页面与状态记录组织成一个可导航原型

--静帧原型总览

OVERVIEW · v3.2 本地高保真原型

目录数字代表需求与状态覆盖,不是 726 张逐一设计的独立视觉稿。

界面证据

同一入口,在两种屏幕上的样子。

会员状态驱动的首页
F01 · 用户小程序原型会员状态驱动的首页

会员身份、官方内容、近期活动与抽签状态在首页汇合,但抽签没有被错误提升为一级导航。

艺人活动与行程时间线
F02 · 用户小程序原型艺人活动与行程时间线

演唱会、签售、线上活动与公开行程脱离内容流,按真实参与状态组织。

先解释资格,再给出行动
F03 · 用户小程序原型先解释资格,再给出行动

活动详情先说明谁能参加、中签获得什么、又不承诺什么,再呈现下一步行动。

两类抽签,共用可审计能力
F04 · 用户小程序原型两类抽签,共用可审计能力

原价优先购与签售入场抽签各自保持活动、结果与凭证独立,只共享准入与审计逻辑。

把“我的”设计成状态台
F05 · 用户小程序原型把“我的”设计成状态台

会员身份、报名、开奖结果与三类凭证分别显示状态和下一步,不互相替代。

运营与审计工作台
F06 · 员工 Web 原型运营与审计工作台

桌面端把会员、活动、内容、抽签与异常状态转化为可复核的运营任务。

面向弱网的现场核验入口
F07 · 员工 H5 原型面向弱网的现场核验入口

员工 H5 将扫码、短码输入、离线核验与核验记录放在同一现场工作流里。

即时且可审计的核验反馈
F08 · 员工 H5 原型即时且可审计的核验反馈

核验成功后明确显示本人、场次、分区与座位,再由员工确认并继续。

项目分析

把复杂规则变成可理解、可执行、可审计的系统。

01

背景与挑战

会员、内容、活动、票务与现场执行容易彼此割裂,最大的体验风险是把会员权益误写成购票承诺。

设计判断把每项承诺拆成明确的状态转换,并写出边界。

02

产品策略

用户主线围绕官方内容、艺人活动与会员互动;会员身份、两类抽签、票务适配和现场核验作为业务底座。

设计判断核心业务流程优先,商城、NFC 收藏和桌宠后置。

03

信息架构

首页、内容、活动、商城、我的构成五个一级入口;抽签只出现在相关活动详情、首页重点模块与“我的”记录中。

设计判断活动是一级,抽签是活动里的会员动作。

04

状态建模

游客、L0、L1 在期、到期、暂停,与报名、开奖、确认、过期、作废、重复核验和申诉状态组合。

设计判断只有在期 L1 可报名两类核心抽签;消费与互动不增加权重。

05

迭代过程

第二轮评审把抽签移出一级导航,分离活动卡与内容卡,并重写准入和结果文案。

设计判断报名成功只代表进入抽签池;演唱会中签是原价购票资格,不是赠票。

06

结果与反思

v3.2 目录覆盖 726 项页面与状态记录:用户端 343、员工 Web 304、员工 H5 54、公共状态 25。

设计判断准确表达覆盖范围,不把目录数量夸大成 726 张独立视觉稿。

系统图

四端共用一套凭证与状态语言

用户端、运营工作台、现场 H5 与公共状态页承担不同任务,但共同指向同一套资格、活动、凭证与审计记录。

  • 界面
  • 服务
  • 数据

01界面 · 会员

用户小程序

承载官方内容、艺人活动、会员状态、抽签动作、凭证与账户记录。

会员动作

02服务

资格与凭证规则

严格区分会员身份、报名、中签、购票资格、入场凭证与核验。

状态与凭证记录

04数据

共享审计台账

活动、会员、抽签、凭证、核验、异常与恢复记录跨端可追溯。

03界面 · 员工

员工 Web、H5 与公共反馈

支持运营、复核、离线核验、冲突处理与可恢复的公共异常反馈。

核验与审计反馈

交付轨迹

完成的工作,与可核对的证据绑定。

01

规则澄清

F03F04

将会员在期、报名资格、中签结果、外部购票资格与签售入场凭证拆成不同承诺和状态。

02

信息架构

F01F02

建立五项一级导航,把抽签动作放回对应活动和账户记录。

03

多端状态系统

让用户、运营、现场和公共反馈围绕统一资格、凭证与审计语言协同。

04

高保真原型

OVERVIEWF05F06

以 React 与 TypeScript 构建可运行原型,让代表页面、会员状态、跳转与异常恢复可直接评审。

05

现场核验

F07F08

为现场峰值设计扫码、短码、离线与重复核验处理,并与直播容量口径明确分开。

具体角色、项目时间与团队边界待项目方补充

原型证据与公开边界全部画面均从当前 v3.2 源码重新拍摄。本案例只表述为高保真原型与文档交付;是否上线、真实客户身份及公开展示授权均不作推断。

OVERVIEW + F01-F08 + 产品真源文档