hyb-oa/docs/product-design-rules.md

产品设计规则基线

本文件是 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 审查并写清回滚路径。