前端开发规范手册

01 / Audience

用户与任务场景

本平台不是单一后台，而是正式公共服务气质、企业级效率工具与普通市民低门槛体验的混合系统。设计必须同时照顾监管、经办与学习三类核心角色。

🏢 政府单位 / 监管

正式、可信、可汇报

重点关注状态、流程、结果和归档截图的可读性。
标题层级、数据摘要、风险动作必须非常明确。
不能娱乐化，也不能做成老式厚重政务页面。

🏭 国企 / 事业单位经办人

高频操作、低认知负担

高频使用搜索、筛选、导入导出、审核和批量操作。
表格、表单、历史记录和状态反馈必须稳定高效。
减少无意义跳转，尽量保留当前上下文。

👨‍🎓 市民 / 学员

任务明确、手机友好

更关注我下一步做什么，而不是复杂系统结构。
移动端必须优先保证进度、提醒、提交和学习路径。
错误提示要能理解，恢复路径要明确。

🧩 设计结论

平台必须在三种气质之间取得平衡

正式可信现代克制效率优先移动端可用 AI 可执行

不能做成老式政务系统，也不能做成过度互联网化产品，更不能做成只有专业人员看得懂的复杂内网工具。这是整个设计系统最重要的判断前提。

02 / Foundation

基础系统与多端基线

规范不只定义长什么样，还定义如何在桌面端与手机端保持一致。这部分是所有页面模板和组件设计的共同骨架。

🧭 设计价值观

清晰、克制、一致、系统化

内容高于容器，信息主次必须一眼可辨。
局部可区分，但默认整体必须统一。
页面服从系统，不允许每页自创视觉规则。

🖥️ 桌面端

高密度、高效率

12 列栅格，左右边距默认 32px。
适合列表、审核、数据分析和批量操作。
结构优先采用导航 + 主内容 + 辅助信息。

📱 手机端

单手操作、单任务流

4 列栅格，左右边距默认 16px。
不是桌面缩小版，必须重新组织层级。
复杂表格需转化为卡片列表或分步结构。

响应式断点

断点	设备	设计重点
`360 - 767px`	手机端	单列布局、单手操作、表单与列表优先
`768 - 1023px`	平板 / 小横屏	保留桌面骨架，但降低信息密度
`1024px+`	桌面端	适合完整后台、数据分析与复杂审核流

核心 Token 基线

类别	规则	长期用途
Spacing	8pt 系统	统一页面、组件、模板密度
Radius	6 / 8 / 12 / 16 / 20	规范按钮、卡片、弹层形态
Shadow	xs / sm / md / lg	建立空间层级而非炫技
Motion	80ms - 360ms	控制反馈速度与系统质感

桌面显示器适配层级

视窗范围	常见设备	建议主内容宽度	设计重点
`1366 - 1599px`	普通办公本 / 小尺寸显示器	`1200 - 1280px`	优先稳住信息层级，不压缩基础留白与表格可读性
`1600 - 1919px`	1080p 主流桌面显示器	`1280 - 1440px`	作为默认桌面基线，适合后台、列表、详情、统计混合场景
`1920 - 2559px`	2K / 宽屏办公显示器	`1440 - 1600px`	可增加摘要区与并列面板，但正文行宽仍需受控
`2560px+`	4K / 大尺寸专业显示器	`1600 - 1760px`	优先扩展工作区与辅助面板，不要整页无边界铺满

大屏适配原则

以浏览器有效内容区为准，不以物理分辨率硬性拉伸版心。
升级到 2K / 4K 时，优先增加容器宽度、边距和并列模块，不要等比放大字号和按钮。
表格、工作台、分析页可以随屏幕变宽，但表单、详情正文、说明文档必须控制阅读宽度。
4K 页面应优先增加辅助信息面板、筛选侧栏和概览区，而不是把主内容摊成一整块大白板。
任何屏幕下都不允许通过减少留白、压缩行高来“塞下更多内容”。

1080p Baseline

主流办公显示器

默认按这一档做桌面基线，优先保证常见办公屏的稳定性。
适合 12 列布局、主内容区加辅助摘要区的常规后台结构。

2K Expanded

更宽工作区，不是更大的字

适合增加概览卡、并列筛选区、双栏详情或图表与表格联动。
正文、说明文本和长表单不要跟着无限加宽。

4K Workspace

扩展面板，不做全屏白板

适合监控台、复杂工作台、分析页、多面板协同场景。
应增加侧栏、摘要区、日志区，不要让主表格或正文无边界横向延展。

03 / Color

色彩系统

品牌色负责系统识别与主任务，语义色只负责状态表达，中性色负责高级感、阅读稳定性与长期可维护性。三层逻辑必须严格分离。

🌐 门户网站

Primary
#1A73E8 Deep
#175FCC Sky
#0EA5E9 Teal
#14B8A6 Soft
#F0F4FF Page
#F8FBFF

对外信息表达与服务入口

关键词：清晰、公开、可信、友好。适合首页、新闻公告、政策解读、服务导航、办事入口、搜索与内容聚合页。

推荐主题气质：轻盈、清爽、开放。
适合较多留白、较强品牌露出和信息分发。
点击当前色块可直接切换本页面主题。
推荐辅色组合：蓝色为主，青色与青绿用于功能高亮与信息层分区。

🛡️ 管理后台

Primary
#10B981 Deep
#059669 Teal
#0F766E Support
#2563EB Soft
#ECFDF5 Page
#F7FAFC

高频业务处理与流程管理

关键词：稳健、可控、可信。适合工作台、列表、审核、批量处理、台账、统计概览、配置管理等正式后台场景。

推荐主题气质：效率优先、层级稳定、噪音更少。
适合表格、筛选、状态说明和流程确认类界面。
点击当前色块可直接切换本页面主题。
推荐辅色组合：绿色负责主行为，深青绿负责状态沉淀，蓝色用于链接和数据高亮。

📱 移动 H5 / 小程序

Primary
#F59E0B Deep
#D97706 Coral
#F97316 Blue
#2563EB Soft
#FFF7E8 Page
#FFFBF5

轻任务、短路径、触控优先

关键词：明确、温和、可达、连续。适合报名、查询、进度、学习、消息提醒、确认提交和单任务流程页。

推荐主题气质：亲和、明确、触控反馈清晰。
适合单列布局、卡片列表、底部操作栏和任务导向界面。
点击当前色块可直接切换本页面主题。
推荐辅色组合：暖色提升行动感，蓝色承担链接、步骤与信息引导。

🎨 动态配色生成器

输入一个主色，自动推导一套完整主题

这部分用于补足“只有三套固定色板”的限制。生成逻辑遵循 design.md 中新增的动态主题规则，自动给出 Hover、Active、两组辅色、浅背景和页面背景，并保留正式、克制、可读的基线。

主色种子 HEX 值

生成层级	默认策略	使用目的
Hover / Active	保持同色相并逐级压深	保证按钮、链接、选中态层级清楚
辅色 A	优先取近邻色	用于模块强调、图表层次、信息高亮
辅色 B	引入一组功能支持色	用于链接、步骤、标签或差异化分区
浅背景 / 页面背景	与白色和中性底色混合	保证整页气质克制，不把品牌色铺满

推荐先选“主色种子”，再观察系统自动生成的 Hover、Active 和两组辅色是否符合业务气质。
如果主色偏红、偏紫或过饱和，算法会给出可用结果，但仍建议人工判断是否适合作为长期主品牌色。
“应用到当前页面”会把整套页面主题切到自定义模式，便于直接观察真实落地效果。

🧪 自定义主题预览

Primary
#2F6DF6 Hover
#2459D2 Active
#1C47AF Accent A
#1884E7 Accent B
#12A594 Page
#F3F7FF

自动推导主题层级

默认以正式、清晰、可维护为目标。你只需要选一个主色，页面会自动补齐状态深浅和支持色。

Accent Pair 辅色建议会在近邻色与支持色之间保持分工。
Soft / Page 浅背景和页面背景会自动压低饱和度，避免大面积染色。
Contrast 按钮文本会自动选择更合理的浅色或深色，以保证对比度。

适用建议

适合需要新业务色但又不希望脱离现有规范的场景。先用它做初稿，再结合业务属性决定是否进入正式 token。

参考系统 A

信息蓝灰

#2F6DF6 #1D4ED8 #0EA5E9 #EAF1FF

适合公开服务、内容门户、知识中心

蓝色负责可信感，湖蓝负责信息层次，浅背景保持清爽。适合首屏信息密度不高、品牌感偏公开透明的系统。

参考系统 B

青绿治理

#198F74 #0F766E #2563EB #EDFDF8

适合后台、审批、经营分析与流程管理

绿色负责主行为和完成感，深青承接稳定气质，蓝色只做链接和辅助数据高亮，整体更偏效率工具。

参考系统 C

深海墨蓝

#285A7A #1E40AF #14B8A6 #F0F7FA

适合数据平台、驾驶舱、偏专业的工具中台

主色更沉稳，适合信息密度较高的工作台。比纯亮蓝更克制，但仍保留现代感和技术感。

参考系统 D

杏橙行动

#D88A1E #C2410C #2563EB #FFF7EC

适合移动任务流、运营触达、提交反馈

暖色更有行动感，但必须控制面积。推荐让橙色负责 CTA，让蓝色承担链接、步骤和说明信息。

参考系统 E

石墨紫蓝

#5B5BD6 #4338CA #0EA5E9 #F2F3FF

适合平台能力、创新模块、轻技术品牌

可以做差异化，但不建议整站大面积使用。更适合作为局部产品线主题，而不是政务或传统后台长期主色。

参考系统 F

枣红点睛

#B54758 #C2410C #2563EB #FFF1F3

适合活动专区、提醒场景、运营板块

红系更容易抢主视觉，不建议作为长期主品牌色。更适合短周期专题、活动页或高辨识运营模块。

语义色组合

语义	主色	浅背景	说明
✅ Success	`#16A34A`	`#F0FDF4`	成功、完成、通过
⚠️ Warning	`#D97706`	`#FFFBEB`	待处理、提醒、风险说明
❌ Error	`#DC2626`	`#FEF2F2`	错误、驳回、失败
ℹ️ Info	`#2563EB`	`#EFF6FF`	引导、信息提示、说明

中性色与使用规则

变量	色值	用途
`--color-text-1`	`#111827`	一级文字、标题、强说明
`--color-text-3`	`#6B7280`	辅助信息、副标题、弱说明
`--color-bg-page`	`#F3F4F6`	页面背景
`--color-border`	`#E5E7EB`	边框、分割线、输入框轮廓

禁止使用纯黑作为正文主色。
禁止用多个高饱和色同时争夺主视觉。
状态表达必须依赖颜色 + 文本 + 图标。

主题色使用策略

层级	推荐比例	典型用途
主色	5% - 10%	主按钮、当前状态、核心导航、一级强调
辅色	3% - 6%	信息标签、模块强调、图表区分、页内功能说明
浅背景	10% - 20%	选中态、筛选容器、信息提示区、轻状态块
中性色	70%+	正文、背景、边框、卡片、长内容阅读区

交互规范与动效示例

交互规范不能只停留在“Hover 要轻一点”这种描述上，而必须落实为按钮层级、表单校验、搜索筛选、危险操作、状态反馈和返回路径的统一标准。这里展示的是团队可直接执行的交互基线。

Typography 16/24 正文优先 Spacing 使用 8pt 系统 Radius 6 / 8 / 12 / 16 / 20 Motion 80ms - 360ms Focus Visible 必须保留主 CTA 同屏通常只允许 1 个

🅰️ 字体与排版

正文优先稳定阅读

桌面正文优先 `16/24`，正文最小不低于 `14px`。
标题与正文必须有明确层级差。
英文副标题的视觉权重必须低于中文主标题。

🎛️ 主次操作

先让用户知道该点哪里

同一视区通常只允许 1 个 Primary CTA。
危险操作不与提交按钮并列抢主视觉。
行内操作超过 3 个时，收纳为更多菜单。

📐 间距与圆角

任何布局都不得脱离 token

8 / 12 / 16组件内节奏

24 / 32模块间节奏

6 / 8 / 12 / 16 / 20圆角层级

禁止页面里出现随机 15px、18px、22px 这类无体系数值。

🎞️ 动效与状态

默认状态集必须完整

Default / Hover / Active / Focus Visible / Disabled / Loading / Error
桌面 Hover 只做轻微变化，手机端主要依赖按压态反馈。
默认只对 transform、opacity、轻微 background-color 做动画。

按钮层级示意

推荐：一个主按钮负责推进主任务，次级按钮承接保存、返回、查看。
禁止：同屏出现两个视觉权重相同的主按钮。
危险操作默认不应排在第一个视觉焦点位。

表单校验示意

身份证号

3702 11** **** 2456

请输入与证件一致的号码，提交前自动校验格式。

手机号

12345

手机号长度不正确，请输入 11 位中国大陆手机号。

错误必须紧邻字段出现，不能只在顶部 Toast 提醒。
首次进入页面不默认全表单报错，应在操作后或提交后提示。
长表单建议增加错误摘要，并支持跳转到对应字段。

搜索与筛选示意

高频条件前置，低频条件折叠到高级筛选。
已生效筛选应可见，避免用户忘记当前过滤状态。
重置必须明确是恢复默认，还是清空全部。

反馈时机矩阵

阶段	推荐反馈	禁止做法
输入中	格式提示、联想建议、轻提示	一输入就整页飘红
失焦后	单字段即时校验	只提示“输入有误”
提交中	锁定按钮、显示加载状态	允许重复点击提交
提交后	Toast + 状态卡 / 结果页	只闪过一条无法追溯的提示

🧭 列表与返回路径

用户不应该在列表和详情之间迷路

从列表进入详情再返回时，优先保留原滚动位置、筛选条件和分页状态。
行点击和行内按钮必须清晰区分，避免误触跳转。
批量操作进入后，要有稳定的状态条和退出方式。

⚠️ 危险操作

删除、驳回、禁用必须明确影响范围

高风险操作必须说明影响对象、影响范围、是否可恢复。
驳回和退回补充若需要填写原因，应先说明目的再让用户输入。
危险按钮默认不放在主按钮位置，也不放在最易误触的位置。

状态反馈示意

Toast 保存成功，已自动同步最新资料。

Banner 当前资料待补充附件，请在 3 个工作日内完成提交。

Empty State 当前暂无学习记录，建议从“年度课程计划”开始。

Result Card 提交成功，下一步请等待单位管理员审核。

交互禁止项

不要只做颜色变化，不补状态模型和反馈闭环。
不要用 placeholder 代替 label。
不要把所有操作都做成主按钮。
不要让删除、驳回、禁用和提交使用同样视觉权重。
不要让列表返回后丢失上下文，迫使用户重新筛选。

05 / Mobile

手机端规范

手机端不是桌面的缩略图，而是更强调单手操作、单任务流和连续阅读的独立场景。学习、报名、查询、提交类功能必须优先保证手机可用。

📱 Mobile Preview

学习 / 任务页示意

9:415G 100%

继续教育学习计划 当前进度 68%，下一步为课程学习与在线测验。

今日任务 学习 2 个课时 · 查看待办提醒 · 提交补充材料

立即继续学习 主操作必须清晰、连续、无遮挡。

📋 移动端硬规则

手机端设计必须满足

点击区域不低于 `44 x 44px`，重要按钮不低于 `48px` 高度。
底部固定栏、提交栏必须考虑 Safe Area 与 Home Indicator。
复杂表格不可原样下沉到手机端，应转化为卡片列表或分步展开。
标签与输入框优先垂直排列，错误提示必须紧贴控件。
不依赖 Hover，主要使用按压态、选中态与结构反馈。

手机端与桌面端的核心差异

维度	桌面端	手机端
导航	顶部 / 左侧主导航 + 页内导航	顶部导航、底部导航、页内分段 Tabs
数据密度	适合高密度列表与表格	优先摘要信息与单列阅读
表单	可多列布局	优先单列布局与分组提交
反馈	Hover + Focus + Active	Pressed + Selected + Clear CTA

移动端导航与操作栏策略

模块	推荐做法
顶部导航	承担标题、返回、少量一级操作，避免塞入太多图标按钮
底部导航	不超过 5 项，优先承载高频频道切换
底部操作栏	固定主 CTA，结合 Safe Area，主次操作最多 1 + 2
更多操作	收纳进底部弹层或详情页，不在首屏堆叠过多入口

手机端表单细则

单屏字段建议控制在 3 - 6 个核心输入项。
超过 8 个字段必须分组，超过 16 个字段建议拆分步骤。
字段说明、格式限制、必填规则应在输入前明确，而不是提交后才暴露。
手机号、数字、邮箱、验证码等字段应匹配对应输入键盘。
复杂选择器优先使用日期、地区、人员专用控件。

手机端列表与详情细则

默认使用卡片列表或分组列表，摘要信息必须前置。
列表项只展示决策所需的最小关键信息，其他内容进入详情页。
详情页优先呈现状态、进度、时间、责任人和下一步动作。
从列表进入详情再返回时，尽量保留原滚动位置和筛选状态。
复杂批量操作应转为任务面板，不应直接沿用桌面端模式。

🔁 中断恢复

移动端更容易被打断

表单填写过程应支持草稿保留。
网络波动时需要有重新提交或继续填写入口。
切后台、来电、跳转其他 App 返回后应尽量恢复上下文。
关键结果不只依赖 Toast，应提供结果页或状态页。

⚡ 性能与视觉约束

移动端不能照搬桌面视觉负载

避免多层毛玻璃、大量大图和过重阴影叠加。
骨架屏只用于结构稳定内容，短加载无需复杂骨架。
长文本必须拆段、摘要化，避免移动端阅读疲劳。
滚动过程中不得出现明显布局抖动与跳变。

📲 移动首页模板

一屏一个主任务

状态摘要身份、进度、待办、提醒

主任务卡最重要的下一步动作

常用服务不超过 6 个入口

近期记录学习、审批、消息历史

🧾 移动提交流程模板

步骤、错误、提交都要稳定

步骤标题当前任务 + 进度可见

当前表单单列输入、就近提示

错误说明说明问题与修复动作

固定操作栏上一步 / 下一步 / 提交

06 / Templates

页面模板与信息架构

规范真正能落地，必须收敛到少量标准模板。页面不是自由拼装，而是围绕固定任务类型组织内容和操作流，并能直接给设计、前端与 AI 执行使用。

📰 门户型首页

先告诉用户我是谁、该做什么

顶部品牌区系统名、身份、当前状态

任务入口区不超过 3 个主任务

公告 / 通知高优先级信息明确前置

学习 / 工作摘要进度、待办、结果可见

📋 列表 / 检索页

搜索、筛选、结果必须稳定分层

标题区说明当前对象与结果范围

筛选区高频项前置，低频项折叠

数据区摘要、表格、分页、批量操作

状态区加载、空状态、无权限都完整

🗂️ 详情页

状态前置，摘要先行，详情分组展开

头部标题对象名称、状态、所属范围一次说清

摘要信息时间、责任人、结果、下一步前置

详情分组资料、流程、附件按稳定模块展开

历史轨迹时间线、操作人、意见与附件可追溯

📝 表单录入页

字段分组、错误就近、操作固定

标题与说明清楚说明当前任务目的

表单分组超过 8 个字段必须分组

辅助说明提示条件、限制、格式规则

固定操作栏提交、保存、暂存位置稳定

✅ 审核处理页

先看对象与风险，再做处理动作

对象摘要申请人、事项、风险等级、当前状态

材料区原始信息、附件、证据按组展开

处理意见通过、驳回、补正必须主次明确

历史记录前序处理动作、时间与责任可回看

🎓 学习流程页

步骤可见、状态可懂、下一步始终明确

课程摘要课程名、计划周期、完成率、结果状态

当前步骤正在学习、待考试、待提交一眼可见

学习资源课程、资料、作业、提醒分层展示

行动按钮继续学习、开始考试、补交材料固定出现

📊 统计分析页

先结论，后趋势，再细节

指标摘要关键数字、同比环比、风险信号前置

趋势图表图表用于解释，不替代核心结论

维度切换地区、部门、时间范围要稳定可回看

明细联动图表、表格、导出路径彼此对应

🎯 结果反馈页

结果说清楚，后续动作不要让用户猜

结果标题成功、失败、待补充要直接命名

结果摘要对象、编号、时间、处理状态完整展示

下一步动作返回列表、继续办理、下载回执必须明确

补充说明常见问题、时限提醒、客服入口就近提供

Example / Portal

门户专题页结构示意

品牌头图 + 当前任务 一句话说明身份、进度和最重要入口

快捷服务高频入口不超过 6 个

公告通知政策、提醒、时效信息

专题内容服务说明

常见问题FAQ

办事入口下一步动作

底部补充说明联系方式、下载、帮助与版权

适合门户首页、服务专区、政策解读、活动专题。
首屏必须优先解决“我是谁、我该去哪、我现在该做什么”。

Example / Admin

后台工作台结构示意

待办摘要待审核、超时、风险项

KPI 区今日、本周、累计

主列表 / 工单队列 支持搜索、筛选、批量操作、状态列与更新时间

流程提醒异常、补件、逾期提示

操作日志最近处理记录

底部详情入口进入对象详情、审批详情或统计明细

适合审核台、运营台账、统计工作台、配置后台。
摘要区先于图表，图表先于长表格说明。

Example / Mobile

移动流程页结构示意

步骤头部 + 进度 当前步骤、总步骤、返回路径清楚

单任务表单区 字段纵向排布，就近提示，错误直接贴近控件

补充说明规则、格式、示例

结果预览提交前确认

底部固定操作栏 上一步 / 保存草稿 / 下一步或提交

适合报名、申请、补件、考试、实名校验等连续流程。
移动端优先保证单任务推进，不要把桌面复杂结构直接下放。

IA Flow

信息架构优先级路径

无论是首页、列表还是流程页，都应先回答身份与状态，再给主任务，再补支持信息，最后才是扩展说明。

01 身份 / 当前状态 用户是谁，当前进度在哪，系统正在处理什么。

02 主任务 / 下一步动作 最重要的 CTA、待办入口、提交动作必须稳定前置。

03 核心内容 / 数据区 表格、表单、详情、图表等主要工作区在第二层展开。

04 支持说明 / 历史记录 规则、帮助、附件、日志、FAQ 放在可继续查看的位置。

IA Board

页面模块拆分判断示意

做信息架构时，不是把所有内容堆到一个页面，而是按“首屏必须看到”“进入后展开”“辅助支撑信息”三层拆分。

首屏必须看到

页面标题、身份、状态、主任务、关键结果

高风险提醒、高优先级通知、当前步骤

一屏内不要并列两个同权重主操作

进入后展开

详情分组、筛选项、统计趋势、分步表单

列表明细、附件列表、审核意见、批量操作

复杂结构必须通过分组、标签页或步骤拆开

辅助支撑信息

FAQ、规则说明、历史日志、下载说明、联系方式

默认不抢首屏，但要保持可预期的查找路径

帮助信息服务主任务，不应喧宾夺主

07 / AI Usage

AI 使用规范

AI 在这套体系里不只是“帮忙改样式”，而是长期参与新开发页面、旧页面重构、规范巡检与 token 提炼的执行伙伴。任务必须写清楚边界，输出必须能被团队直接落地和验收。

🤖 AI 的硬规则

不允许突破的边界

不得私自创造新的主题色体系。
不得使用随机字号、随机圆角、随机阴影。
不得为了现代感破坏正式、可信、可汇报气质。
不得把复杂桌面表格原样塞进手机端。
不得移除焦点态、错误态、禁用态、加载态。

🧭 任务类型

先分清到底在做什么

新开发页面：从 0 到 1 建立结构、状态、端别差异和组件规则。
页面重构：保留业务逻辑前提下修复结构、留白、主题和反馈闭环。
规范巡检：按 design.md 审查 token、层级、状态和多端适配。
Token 提炼：把页面经验沉淀为变量、状态模型和模块标准。

新开发页面

先明确页面属于门户网站、管理后台还是移动 H5/小程序。
先产出信息架构、模块拆分、主次操作和完整状态，再谈视觉细节。
必须说明桌面端与移动端差异，不能默认只做单端。
输出里要包含 token 使用方式，而不是临时写一套样式。

页面重构

优先修复结构问题、留白失衡、卡片粘连、按钮主次混乱等老问题。
不得为了“更现代”删除关键信息层级和用户熟悉的操作路径。
必须补齐焦点态、错误态、禁用态、空状态、加载态和手机端结构。
输出中要明确保留了哪些业务逻辑，修复了哪些设计债务。

AI 输入建议

页面截图、原型图或旧系统截图
原始 HTML / CSS 或组件结构
业务目标、页面类型与主要用户角色
使用端别：桌面 / 手机 / 双端
主要操作路径、高频任务与异常场景
当前已知问题和不可改动边界

AI 输出要求

设计判断说明
页面结构或模块重组方案
Token 使用说明
桌面端与手机端差异说明
关键状态与反馈说明
风险点、假设项与最终 HTML / CSS 或模块化实现结果

AI Prompt 标准结构

部分	必须说明什么
任务身份	让 AI 明确扮演资深前端 / 设计系统 / 规范评审角色
任务类型	是新开发页面、页面重构、补移动端、提炼 token，还是做评审
上下文对象	页面类型、业务角色、目标用户、使用端别
设计约束	必须严格遵守 design.md，不得私自发明规则
边界限制	说明不能删除什么、不能新增什么、哪些结构必须保留
输出格式	说明、清单、结构图、代码、验收项

团队标准 Prompt 类型

新页面设计 Prompt
旧页面重构 Prompt
移动端适配 Prompt
设计系统 / Token 提炼 Prompt
设计巡检 / 评审 Prompt
静态规范展示页 Prompt

避免使用“做得大厂一点”“改得现代一点”这类模糊描述。
避免不说明页面类型、任务类型、用户类型、端别与边界条件。

📦 AI 输出合同

输出必须同时满足

信息不足时必须明确假设。
无法判断移动端行为时必须明确声明。
涉及高风险改动时必须标注风险点。
如果是新开发页面，必须说明为什么这样分层和排序。
如果是页面重构，必须说明保留了哪些核心业务结构。
设计说明、结构说明和代码输出必须彼此一致。

🧪 AI 评审维度

不是只看代码，更要看规范符合度

信息层级是否清晰
是否完全使用统一 token
是否存在随机颜色、字号、圆角、阴影
状态是否完整
卡片与区块之间是否有明确间距和层级
手机端是否只是桌面端缩小版

你现在的任务是为一个新的业务页面建立前端设计与实现方案。

请严格遵守以下约束：
1. 只能使用 design.md 中定义的设计原则、色彩、字体、间距、圆角、阴影和动效规则。
2. 页面必须服务于明确任务，不允许只做表层视觉包装。
3. 需要同时说明桌面端与移动端的结构差异，若仅做单端必须明确声明。
4. 页面风格需体现正式、专业、现代、克制、高可用，适用于门户网站、管理后台、移动 H5/小程序等典型业务形态。
5. 输出内容必须包含：信息架构、模块结构、主次操作、关键状态、token 使用说明与最终实现方案。

请重点判断以下问题：
- 页面属于门户网站、管理后台还是移动 H5 / 小程序
- 用户的主任务是什么
- 页面是否需要搜索、筛选、步骤、表单、审核、结果反馈
- 状态与异常流程是否完整

你正在重构一个旧前端系统页面。

请严格遵守以下约束：
1. 只能使用 design.md 中定义的设计原则、色彩、字体、间距、圆角、阴影和动效规则。
2. 不得引入新的主题色体系。
3. 必须保留原页面的核心业务逻辑、字段关系和关键操作路径。
4. 优先修复信息层级、布局节奏、卡片留白、主次按钮、状态反馈和多端适配问题。
5. 输出内容必须包含：问题诊断、结构重组方案、桌面端方案、手机端方案、关键交互状态和最终实现结果。

如果原页面存在老旧问题，请默认修复以下问题：
- 过重边框
- 过密信息堆叠
- 颜色混乱
- 卡片之间没有明确缝隙
- 按钮主次不清
- 缺少焦点态 / 错误态 / 空状态 / 加载态
- 手机端只是桌面端缩小版

你现在的任务不是设计页面，而是审查页面是否符合 design.md。

请从以下维度逐项评审：
1. 信息层级是否清晰
2. 是否使用统一 token
3. 是否存在随机颜色、字号、圆角、阴影
4. 主操作是否明确
5. 状态是否完整
6. 手机端是否只是桌面端缩小版
7. 卡片与区块之间是否有明确间距与层级
8. 是否符合正式、专业、克制、高可用的产品气质

输出格式要求：
- 先列出问题清单，按严重程度排序
- 再给出修复建议
- 最后给出整体结论：合格 / 基本合格 / 不合格

08 / Git Workflow

Git 协作规范

Git 规范不是“代码提交礼仪”，而是前端团队长期协作、版本回溯、发布审计和紧急修复的基础设施。分支、commit、PR、release 和 hotfix 都必须可追溯、可复盘、可执行。

🌿 分支模型

标准职责必须清晰

`main`：生产可发布代码，只接受稳定合并。
`develop`：日常集成分支，是当前迭代的默认协作主线。
`feature/*`：新功能开发，按模块或任务拆分。
`fix/*`、`refactor/*`：分别用于修 Bug 和非功能性重构。
`release/*`、`hotfix/*`：用于发布冻结与线上紧急修复。

🚫 共享分支禁令

这些行为默认不允许

禁止直接向 `main` 提交代码。
原则上也不允许直接推送 `develop`，必须走 PR / MR。
禁止对共享分支无说明 `force push`。
禁止在一个分支里混入多个不相关需求。
禁止把格式化、大重构和业务修复混成一次提交。

分支命名标准

类型	推荐格式	说明
Feature	`feature/module-short-desc`	新功能，按页面或模块拆分
Fix	`fix/module-issue-desc`	常规缺陷修复
Refactor	`refactor/module-goal`	结构重组、token 归一、组件抽象
Release	`release/v1.4.0`	版本冻结、回归测试、发布整理
Hotfix	`hotfix/login-timeout`	线上紧急问题修复

Commit 标准

类型	用途	示例
`feat`	新功能	`feat(portal): add quick entry cards`
`fix`	缺陷修复	`fix(form): correct validation order`
`refactor`	重构	`refactor(token): unify spacing variables`
`style`	纯样式调整	`style(table): reduce visual noise`
`docs`	文档变更	`docs(standards): add git workflow section`

PR / MR 要求

标题建议与 squash 后主 commit 保持一致。
描述至少写明：背景、范围、截图、风险、验证方式、是否影响移动端。
常规页面至少 1 人评审；公共组件、token、导航系统建议 2 人评审。
发版相关 PR 必须附回归结果和风险说明。

Release / Hotfix

发布前切 `release/*` 分支，冻结功能，只做验收与修正。
版本号建议遵循 `major / minor / patch`。
hotfix 必须从 `main` 切出，只修线上问题，不夹带重构。
hotfix 合并回 `main` 后必须同步回 `develop`，避免问题复发。

推荐的 commit 写法：

feat(portal-home): add service entry cards
fix(user-form): correct validation feedback order
refactor(layout): unify section and card spacing
docs(standards): add git workflow section

不要使用：
- update
- fix bugs
- 调整一下
- 最终版
- test

09 / Governance

验收清单与治理机制

长期设计规范的核心不是写得多，而是每次新增页面和旧页面改造时都能有一致的验收方法和治理机制。

✅ 视觉一致性

先查是否脱离系统

是否完全使用既有 token
是否存在随机颜色、圆角、字号
是否符合当前端别主题逻辑

🧱 结构清晰度

再查是否真的好理解

信息主次是否清晰
主操作是否唯一明确
是否存在无意义容器堆叠

🧭 交互完整性

状态必须完整闭环

是否具备焦点态、错误态、禁用态、加载态
是否存在无反馈操作
是否提供成功、错误、空状态的明确说明

📱 多端适配

不能只完成桌面端

手机端是否重组结构而非简单缩放
触控目标是否满足最小点击标准
底部栏与键盘弹起场景是否考虑完整

禁止项总表

随意新增一套页面专属颜色体系
使用高饱和渐变做大面积主背景
用 placeholder 代替 label
删除焦点态
手机端直接缩放桌面表格

长期治理建议

以 design.md + token 作为单一事实源。
新增全局规则前先判断是否值得系统化。
建议按 major / minor / patch 管理规范版本。
每季度复盘规范执行情况与高频争议点。

内部前端设计规范站