R100/A1-A6 建立产品设计规则基线
这个提交包含在：
@@ -0,0 +1,130 @@
|
||||
# 产品设计规则基线
|
||||
|
||||
本文件是 R100 之后 PC 网页和企业微信/手机网页统一优化的事实源。目标用户是 10 人以下的国内科技公司：使用频次高、角色重叠、审批链短，系统应当像工作台，不像宣传站，也不应像重型 ERP。
|
||||
|
||||
## 设计目标
|
||||
|
||||
- 首屏只放今天最该处理的事，避免解释系统功能。
|
||||
- PC 端服务批量查看、对账、审批和管理；手机端服务提交、补资料、查状态和处理待办。
|
||||
- 页面文案使用国内 OA 常见表达：待处理、草稿、审批中、已通过、已支付、已驳回、提交、保存、删除、撤回。
|
||||
- 所有业务对象使用业务编号或摘要展示，不把 UUID 当作主编号展示给用户。
|
||||
- 颜色以浅色工作台为主，黑色只用于正文或弱边框，不作为移动主按钮、底部导航、首屏卡片背景。
|
||||
|
||||
## 文案规则
|
||||
|
||||
禁止：
|
||||
|
||||
- 口语化标题，例如“先处理这几件事”。
|
||||
- 内部评价词，例如“清爽”。
|
||||
- 对用户解释设计意图，例如“低频模块放在这里，避免干扰移动首页”。
|
||||
- 路由式标题，例如直接显示 `/invoice-pool`。
|
||||
- 长段功能说明占据表单、弹窗、列表首屏。
|
||||
|
||||
推荐：
|
||||
|
||||
- 首页模块标题用“待处理”“常用”“我的申请”“通知”。
|
||||
- 操作按钮用“新建报销”“继续编辑”“提交审批”“删除草稿”“上传发票”。
|
||||
- 空状态只说明现状和下一步，例如“暂无草稿”“暂无待处理审批”。
|
||||
- 表单说明放在字段错误、帮助文本或 hover/折叠信息里，不放在首屏大段文案。
|
||||
|
||||
## 色彩规则
|
||||
|
||||
- 主色：品牌蓝/青色系，用于主按钮、选中态、链接和轻量提示。
|
||||
- 中性色：白色、浅灰、浅蓝灰用于背景、卡片和分隔。
|
||||
- 状态色：红色表示危险或失败，橙色表示待处理，绿色表示完成。
|
||||
- 禁止移动端主卡、底部导航选中态和核心 CTA 使用黑色大块背景。
|
||||
- 卡片圆角保持 8px 左右；移动端可使用 12px 到 16px，但不做营销式大圆角堆叠。
|
||||
|
||||
## PC 页面模式
|
||||
|
||||
列表页：
|
||||
|
||||
- 顶部只保留标题、核心筛选、主操作。
|
||||
- 表格列优先显示业务编号、申请人、金额/天数、状态、更新时间、操作。
|
||||
- 操作列至少区分“查看/编辑”和状态允许时的“删除草稿”。
|
||||
- 长 ID、调试字段、路径字段默认不进入主列。
|
||||
|
||||
明细页：
|
||||
|
||||
- 标题显示业务编号或摘要，例如“报销单 BX20260506001”。
|
||||
- 状态、金额、申请人、更新时间作为摘要条。
|
||||
- 主流程操作固定在页头或底部操作区，危险操作靠右或二次确认。
|
||||
- 审批流、附件、发票和日志分区展示，避免混在一个长表单里。
|
||||
|
||||
表单和弹窗：
|
||||
|
||||
- 表单先收集必要字段，非必要字段折叠或后置。
|
||||
- 发票、附件上传使用自定义中文控件，不暴露浏览器原生 `Choose File` 文案。
|
||||
- 弹窗只承担单一任务，不在弹窗里解释整个业务流程。
|
||||
|
||||
## 手机和企业微信页面模式
|
||||
|
||||
- 手机端默认隐藏 PC 侧边栏和顶栏，使用移动首页、底部导航和轻量卡片。
|
||||
- 菜单不应占用大量空间；常用入口放底部导航，更多入口放“我的”。
|
||||
- 列表使用卡片，不直接显示桌面表格。
|
||||
- 表单字段纵向排列，按钮宽度稳定，首屏优先完成“新建/继续编辑/提交”。
|
||||
- 企业微信入口应尽量免登录；绑定失败或权限不足时显示明确下一步，而不是让用户反复登录。
|
||||
|
||||
## 报销专项规则
|
||||
|
||||
报销是下一批 R101 的主流程，不在 R100 直接改数据模型。R101 必须单独处理：
|
||||
|
||||
- 后端生成业务编号，例如 `BX20260506001`，前端不再用 UUID 作为主展示。
|
||||
- 草稿允许删除；审批中使用撤回；已通过和已支付不提供删除。
|
||||
- 报销明细存在且只有一条时，上传发票默认绑定该明细。
|
||||
- 多条明细时优先按金额匹配；无法匹配时允许用户选择明细或绑定整单。
|
||||
- 发票上传支持批量，OCR 显示明确状态和可重试入口，不长期停留在“上传中/处理中”。
|
||||
- PC 端适合完整明细和对账；手机端适合拍照上传、补充说明、继续编辑草稿和查状态。
|
||||
|
||||
## 请假、票据、采购、差旅规则
|
||||
|
||||
- 请假手机端应提供新建、编辑草稿、提交和查看记录，不显示桌面表格。
|
||||
- 票据中心应显示票据号码、销售方、金额、OCR 状态和绑定状态，不把内部 ID 放在主位置。
|
||||
- 采购和差旅页使用和报销一致的列表、状态、操作区和移动卡片规则。
|
||||
- 所有上传控件都使用中文按钮和文件名回显。
|
||||
|
||||
## R99 WIP 处置
|
||||
|
||||
当前工作区存在 R99 企业微信移动端整改 WIP，涉及：
|
||||
|
||||
- `client/src/pages/MobilePortalPage.tsx`
|
||||
- `client/src/pages/MobileMePage.tsx`
|
||||
- `client/src/components/mobile/MobileBottomNav.tsx`
|
||||
- `client/src/layouts/AppShellLayout.tsx`
|
||||
- `client/src/pages/MobileReimbursementsPage.tsx`
|
||||
- `client/src/pages/MobileLeavePage.tsx`
|
||||
- `client/src/router/index.tsx`
|
||||
- `client/src/router/lazy/index.ts`
|
||||
|
||||
这些改动方向与本设计基线基本一致，但仍需要在 R103 中统一吸收或经批准清理。本 R100 批次不把这些 WIP 当作完成项提交，避免和设计规则、报销重构混在一起。
|
||||
|
||||
## 后续批次
|
||||
|
||||
R101 报销主流程重构：
|
||||
|
||||
- 后端业务编号、权限和删除规则。
|
||||
- 报销列表、明细页、发票绑定和草稿编辑体验。
|
||||
- PC 与手机报销流程的自动化回归。
|
||||
- 需要 reviewer 检查权限、状态机和回滚策略。
|
||||
|
||||
R102 跨页面一致性：
|
||||
|
||||
- 票据、请假、采购、差旅页面统一列表、表单、上传和状态文案。
|
||||
- 清理路径式标题、原生上传控件和 UUID 主展示。
|
||||
- 补齐页面级 Playwright 视觉诊断。
|
||||
|
||||
R103 企业微信/手机端统一清理：
|
||||
|
||||
- 吸收或清理 R99 WIP。
|
||||
- 固定移动首页、我的、报销、请假、审批、票据上传的移动页面。
|
||||
- 手机端不再复用桌面表格作为主要体验。
|
||||
|
||||
## 验收规则
|
||||
|
||||
每个后续批次至少满足：
|
||||
|
||||
- Issue CSV 中明确业务流程级 `Test_Method`。
|
||||
- `node scripts/qa/check-ui-design-rules.mjs` 可运行并记录问题。
|
||||
- 前端改动执行 `cd client && npm run typecheck` 和 `cd client && npm run build`。
|
||||
- 涉及移动端或视觉问题时，补充 Playwright 截图或视觉诊断。
|
||||
- 涉及状态机、权限、数据迁移时，单独 reviewer 审查并写清回滚路径。
|
||||
在新工单中引用
屏蔽一个用户