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

产品设计规则基线

本文件是 R100 之后 PC 网页和企业微信/手机网页统一优化的事实源。目标用户是 10 人以下的国内科技公司：使用频次高、角色重叠、审批链短，系统应当像工作台，不像宣传站，也不应像重型 ERP。

设计目标

• 首屏只放今天最该处理的事，避免解释系统功能。
• PC 端服务批量查看、对账、审批和管理；手机端服务提交、补资料、查状态和处理待办。
• 页面文案使用国内 OA 常见表达：待处理、草稿、审批中、已通过、已支付、已驳回、提交、保存、删除、撤回。
• 所有业务对象使用业务编号或摘要展示，不把 UUID 当作主编号展示给用户。
• 颜色以浅色工作台为主，黑色只用于正文或弱边框，不作为移动主按钮、底部导航、首屏卡片背景。

品牌视觉参考

OA 页面应参考公司主页 www.hyinda.com 的视觉气质，但不能做成营销页。R111 起以 2026-05-08 对官网首页“海音达 Hyinda”的实际视觉抓取作为基线，截图和颜色摘要保存在 output/playwright/r111-hyinda-design/：

• 品牌识别：使用“海音达 Hyinda”的稳重科技感，页面干净、留白充足、边界清晰。
• 主色倾向：官网核心蓝约为 rgb(0,57,138)，用于主按钮、选中态、重点链接和关键状态。
• 中性色：白色、浅灰蓝、浅边框和深 slate 文本为主，避免大面积黑色块。
• 圆角与卡片：控制在工作台风格，卡片边界清晰，不使用营销式大面积渐变、装饰光斑或夸张大圆角。
• 字体气质：官网使用偏现代无衬线风格；OA 继续使用系统无衬线字体，但字号、行距和按钮高度要克制。
• 双端一致：PC 和企业微信/手机端都遵循同一品牌色和控件语义，只根据屏幕密度调整布局。

国内同类系统体验基线

R6 之后的 PC、移动和审批体验参考国内主流协同/OA 产品的共性，而不是复制任何单一产品。公开资料显示，钉钉审批强调模板化审批、假勤/财务场景和移动处理，飞书审批强调一站式入口、即时消息通知、移动端处理、流程配置和催办，企业微信自建应用适合作为工作台入口、身份和个人消息 deeplink。PC 端的工作台、表格、表单和导航可参考 Ant Design 的信息密度和后台系统模式，移动端参考微信生态常见的 WeUI/Ant Design Mobile 控件语义。

落到 hyb-oa 的原则：

• PC 是高密度工作台，服务筛选、批量查看、审批、财务复核、导出和管理配置。
• 移动端是消息驱动的轻入口，服务提交、补材料、查状态、处理待办和从企业微信消息回流。
• PC 高密度、移动轻任务是双端分工底线；不得把桌面表格和批量管理能力原样搬到手机端。
• 企业微信只做入口、绑定、免登录、个人应用消息和 deeplink，不替代 OA 正式审批页。
• 审批体验以“待办聚合、清晰状态、明确下一步、可催办和可追溯”为目标；催办、超时提醒和效率统计属于 R6 后续优化，不混入 R6 首轮试运行门禁。
• 竞品资料只用于抽象原则；不得复制钉钉、飞书、企业微信、WeUI 或 Ant Design 的页面文案、视觉细节和专有交互。

参考资料：

• 钉钉审批：https://page.dingtalk.com/wow/dingtalk/act/approval-web
• 飞书审批：https://www.feishu.cn/content/article/7584390246654037188
• 飞书审批催办：https://www.feishu.cn/content/134344362384
• 企业微信应用消息：https://s.apifox.cn/apidoc/docs-site/406014/api-10061693
• Ant Design 表单页：https://4x.ant.design/docs/spec/research-form-cn
• Ant Design 表格：https://012x.ant.design/docs/pattern/table
• Ant Design 导航：https://ant.design/docs/spec/navigation/
• Ant Design Mobile/Mini TabBar：https://0x-mini.ant.design/components/tab-bar
• Ant Design Mobile/Mini SafeArea：https://0x-mini.ant.design/components/safe-area
• WeUI：https://github.com/Tencent/weui

文案规则

禁止：

• 口语化标题，例如“先处理这几件事”。
• 内部评价词，例如“清爽”。
• 对用户解释设计意图，例如“低频模块放在这里，避免干扰移动首页”。
• 路由式标题，例如直接显示 /invoice-pool。
• 长段功能说明占据表单、弹窗、列表首屏。

推荐：

• 首页模块标题用“待处理”“常用”“我的申请”“通知”。
• 操作按钮用“新建报销”“继续编辑”“提交审批”“删除草稿”“上传发票”。
• 空状态只说明现状和下一步，例如“暂无草稿”“暂无待处理审批”。
• 表单说明放在字段错误、帮助文本或 hover/折叠信息里，不放在首屏大段文案。

色彩规则

• 主色：品牌蓝/青色系，用于主按钮、选中态、链接和轻量提示。
• 中性色：白色、浅灰、浅蓝灰用于背景、卡片和分隔。
• 状态色：红色表示危险或失败，橙色表示待处理，绿色表示完成。
• 禁止移动端主卡、底部导航选中态和核心 CTA 使用黑色大块背景。
• 卡片圆角保持 8px 左右；移动端可使用 12px 到 16px，但不做营销式大圆角堆叠。

PC 页面模式

列表页：

• 顶部只保留标题、核心筛选、主操作。
• 表格列优先显示业务编号、申请人、金额/天数、状态、更新时间、操作。
• 筛选区默认收敛为关键字段：状态、申请人、时间、业务编号或关键词；高级筛选折叠，不压缩列表首屏。
• 分页、空状态、批量操作和导出入口必须清楚区分；员工页少配置，财务和管理员页可更高密度。
• 操作列至少区分“查看/编辑”和状态允许时的“删除草稿”。
• 长 ID、调试字段、路径字段默认不进入主列。

明细页：

• 标题显示业务编号或摘要，例如“报销单 BX20260506001”。
• 状态、金额、申请人、更新时间作为摘要条。
• 主流程操作固定在页头或底部操作区，危险操作靠右或二次确认。
• 审批流、附件、发票和日志分区展示，避免混在一个长表单里。
• 审批、财务和管理员视角可以展示更多审计信息，但普通员工主视角只展示与下一步动作有关的信息。

表单和弹窗：

• 表单先收集必要字段，非必要字段折叠或后置。
• 发票、附件上传使用自定义中文控件，不暴露浏览器原生 Choose File 文案。
• 弹窗只承担单一任务，不在弹窗里解释整个业务流程。

移动统一页面范式

• 所有 /mobile 页面默认复用同一套移动 Shell、响应式 token、底部导航、安全区和视觉矩阵；不允许单页自造布局体系解决局部拥挤。
• 手机端默认隐藏 PC 侧边栏和顶栏，使用移动首页、底部导航和轻量卡片。
• 菜单不应占用大量空间；常用入口放底部导航，更多入口放“我的”。
• 移动底部导航固定为“首页、审批、报销、我的”；票据上传作为首页快捷入口和报销页内操作，不作为底部一级 Tab。
• 移动端必须按响应式规则自动适配，不按单个机型写补丁；验收至少覆盖 320、360、375、390、393、414、430px 宽度。
• 移动首页一级快捷入口使用图标宫格：图标在上、短标题在下，4 项等宽，辅助说明不在小屏常驻展示，避免图标和文字挤压；标题单行省略，不允许逐字换行。
• 移动端页面边距、卡片间距、底部导航高度和吸底操作高度使用统一 token；不通过 viewport 缩放字体解决拥挤问题。
• 次级入口和信息字段可按最小宽度自动从两列变一列；核心操作按钮必须保持明确可点，不得被内容、安全区或底部栏遮挡。
• 报销详情、审批详情等深层 Push 页隐藏底部导航，使用顶部返回和上下文吸底操作，避免底部 Tab 在深层页面假选中。
• 企业微信个人应用消息 deeplink 应直达移动待办或业务详情；首次进入如需点击进入工作台，应保持后续可直接回到目标页。
• 移动列表使用卡片和状态标签，首屏优先展示“谁提交、什么事项、金额/天数、当前状态和下一步”。
• 列表使用卡片，不直接显示桌面表格。
• 详情页按摘要、业务字段、发票/附件、审批流、日志分区展示；普通员工移动端不默认展示后台审计细节。
• 表单单列优先，字段纵向排列，按钮宽度稳定，首屏优先完成“新建/继续编辑/提交”。
• toast、dialog、actionsheet、tabbar、cell、button 等语义参考微信生态习惯；样式必须回到 hyb-oa 自身品牌和组件规则。
• 企业微信入口应尽量免登录；绑定失败或权限不足时显示明确下一步，而不是让用户反复登录。
• 头像 fallback 遵循国内中文习惯：中文/CJK 姓名默认取首个可见字符，英文或拼音姓名保留两段首字母。
• 移动角色差异采用“同框架、按角色裁剪内容和动作”：员工、审批人、财务、管理员、负责人看到不同入口、摘要、动作和敏感信息，但不做多套角色专属移动 UI。
• 移动验收必须包含跨视口自动化和代表性真机确认；若真机验证暂缓，只能记为 PAUSED，不能把相关移动阻断标为完成。

报销专项规则

报销是下一批 R101 的主流程，不在 R100 直接改数据模型。R101 必须单独处理：

• 后端生成业务编号，例如 BX20260506001，前端不再用 UUID 作为主展示。
• 草稿允许删除；审批中使用撤回；已通过和已支付不提供删除。
• 报销明细存在且只有一条时，上传发票默认绑定该明细。
• 多条明细时优先按金额匹配；无法匹配时自动生成新明细，不向普通用户暴露“绑定整单”。
• 发票上传支持批量 PDF，OCR 显示明确状态和可重试入口，不长期停留在“上传中/处理中”。
• PC 端适合完整明细和对账；手机端适合上传 PDF 发票、补充说明、继续编辑草稿和查状态。
• 报销详情等深层页的底部主操作在 iPhone 11 等小屏上仍保持同行双按钮，不因适配降级为单列。

请假、票据、采购、差旅规则

• 请假手机端应提供新建、编辑草稿、提交和查看记录，不显示桌面表格。
• 票据中心应显示票据号码、销售方、金额、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 当作完成项提交，避免和设计规则、报销重构混在一起。

后续批次

R6 小范围试运行准备：

• 先新建独立 R6 合同，固定 2-3 个内部用户、角色、时间窗口、回滚联系人、问题登记表和每日收口节奏。
• R6 范围限定为报销、请假、采购、审批、企业微信入口/通知、财务付款/导出。
• R6 不扩预算、ERP、AI、完整差旅、复杂 BPM；发现需求只登记为新 Issue。
• 试运行反馈按“阻断、严重、一般、体验建议”分级，不能现场扩大实现范围。

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