# 产品设计规则基线 本文件是 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 正式审批页。 - 审批体验以“待办聚合、清晰状态、明确下一步、可催办和可追溯”为目标；AP6 v1 已完成催办、超时提醒和审批效率摘要，后续只在独立 Issue 中增强配置治理、升级处理或更复杂的节点 SLA。 - 移动信息分层必须清楚：`待办` 是需要我处理的任务，`进度` 是我发起的单据状态，`通知` 是事件消息，`详情` 是业务事实源；首页、审批中心、通知中心不得把同一批待办重复铺开。 - 竞品资料只用于抽象原则；不得复制钉钉、飞书、企业微信、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/折叠信息里，不放在首屏大段文案。 ## 信息层级与去重规则 - 首页只做工作台摘要：同一页面最多出现一处待办或进度列表；底部 Tab 红点只表达全局数量，通知列表只表达事件，不作为待办列表副本。 - 审批入口承载两类视角：审批人看“待我审批/已处理”，员工看“我发起的/审批进度”；普通员工不能看到不可点或无权限的审批入口。 - 通知卡片表达“发生了什么”，点击应直达审批任务或业务详情；目标不存在、已删除或无权限时显示可理解提示，不跳回首页。 - 同一卡片或同一表格行只展示一次主标识。标题为“报销单 BX20260512001”时，正文不再出现“业务单号：BX20260512001”。 - 状态只展示一次，优先使用右侧状态标签；不要在标题、副标题和正文里重复写“已通过/业务状态：已通过/状态：已通过”。 - 卡片固定槽位：第一行左侧为业务类型加业务编号或摘要，第一行右侧为状态；第二行放申请人、金额/天数、日期；第三行可选当前节点或更新时间。 - PC 高密度表格允许保留独立“单号/编号”列，但同一行的标题或摘要不得再拼接同一编号；确需复制编号时放在单号列或详情页摘要区。 - UUID、taskId、entityId、内部状态码和调试字段不进入用户主展示；审计页、管理员排障页和打印留痕页按权限例外处理。 ### MIA7 移动工作台、进度、通知和详情标准 MIA7 之后，移动 OA 的信息架构以“一级入口少、任务摘要轻、详情事实源清楚”为基线。后续移动页面整改必须先判断内容属于哪一层，再决定展示位置： - `底部导航` 只承载一级模块，不承载具体动作。默认语义为首页、审批/进度、报销、我的；底部红点只表达数量，不展示待办内容。 - `首页常用` 只能放快捷动作，不重复底部 Tab。推荐动作是新建报销、上传票据、请假、资产扫码、发起采购等；报销、审批/进度、我的这类一级入口不应再次出现在常用宫格。 - `首页待处理` 只保留一张轻摘要。审批人可以看到待批数量和 1 条最紧急待办，员工可以看到我发起的进度摘要；不得同时出现总数、三宫格指标、待办列表、卡片状态和进入按钮五层重复。 - `审批/进度页` 按角色分流：员工使用草稿、审批中、已通过、退回驳回等状态标签查看我发起的事项；审批人使用待我审批、已处理标签查看任务；两者不得混成同一个无分组流水列表。 - `通知中心` 是事件收件箱，不是待办列表或进度页副本。通知卡片优先展示事件类型、标题、时间和已读状态，点击先标记已读再直达业务详情；通知页不展示审批动作按钮。 - `详情页` 是业务事实源。所有移动深层详情统一使用同一详情壳：左侧返回，标题和副标题居中或左侧主内容区，右侧状态；隐藏底部 Tab；内容顺序为摘要、关键字段、材料/附件/发票、审批流、下一步动作。 - `返回语义` 优先回到来源页或来源标签；没有来源时回到对应业务列表或进度标签。不得从已批准记录详情返回到新建表单顶部，也不得把采购详情无条件返回审批首页。 - `角色首页` 必须体现角色优先级。员工优先我的申请和快捷动作，审批人优先待批，财务优先待复核、待付款、台账和导出；不同角色可共用框架，但摘要、入口和动作必须裁剪。 - `真机差异` 不按单机型写补丁。iPhone 12/iOS 14 企业微信等真实 WebView 间距问题应先纳入截图样本和移动 token 复核，再通过统一槽位、间距 token 或安全区规则修正。 ## 色彩规则 - 主色：品牌蓝/青色系，用于主按钮、选中态、链接和轻量提示。 - 中性色：白色、浅灰、浅蓝灰用于背景、卡片和分隔。 - 状态色：红色表示危险或失败，橙色表示待处理，绿色表示完成。 - 禁止移动端主卡、底部导航选中态和核心 CTA 使用黑色大块背景。 - 卡片圆角保持 8px 左右；移动端可使用 12px 到 16px，但不做营销式大圆角堆叠。 ## PC 页面模式 列表页： - 顶部只保留标题、核心筛选、主操作。 - 表格列优先显示业务编号、申请人、金额/天数、状态、更新时间、操作。 - 筛选区默认收敛为关键字段：状态、申请人、时间、业务编号或关键词；高级筛选折叠，不压缩列表首屏。 - 分页、空状态、批量操作和导出入口必须清楚区分；员工页少配置，财务和管理员页可更高密度。 - 操作列至少区分“查看/编辑”和状态允许时的“删除草稿”。 - 长 ID、调试字段、路径字段默认不进入主列。 明细页： - 标题显示业务编号或摘要，例如“报销单 BX20260506001”。 - 状态、金额、申请人、更新时间作为摘要条。 - 主流程操作固定在页头或底部操作区，危险操作靠右或二次确认。 - 审批流、附件、发票和日志分区展示，避免混在一个长表单里。 - 审批、财务和管理员视角可以展示更多审计信息，但普通员工主视角只展示与下一步动作有关的信息。 表单和弹窗： - 表单先收集必要字段，非必要字段折叠或后置。 - 发票、附件上传使用自定义中文控件，不暴露浏览器原生 `Choose File` 文案。 - 弹窗只承担单一任务，不在弹窗里解释整个业务流程。 ## 移动统一页面范式 - 所有 `/mobile` 页面默认复用同一套移动 Shell、响应式 token、底部导航、安全区和视觉矩阵；不允许单页自造布局体系解决局部拥挤。 - 专用 `/mobile` 页面包括移动首页、审批、报销列表、报销详情、我的、个人设置、通知、票据上传、请假和资产扫码；这些页面必须先使用统一移动组件和样式，再按业务差异裁剪内容。 - 手机端默认隐藏 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 姓名默认取首个可见字符，英文或拼音姓名保留两段首字母。 - “我的”页和更多入口使用组件级自适应槽位：头像/图标槽固定，文字槽使用 `minmax(0, 1fr)` 可收缩，间距使用移动 token 或 `clamp()`；不按具体 iPhone/Android 机型写补丁，不通过放大字号、放大卡片或改成单列来规避图文拥挤。 - 所有专用 `/mobile` 页面统一使用移动槽位和移动卡片：图标/头像/状态槽固定，文字槽可收缩，列表项使用移动列表卡片，提示、空状态和表单分组使用移动 token；不得把桌面 `card-std p-4` 当作移动主容器重新引入。 - 移动卡片保持白底、浅边框、轻阴影，不显示 PC 端 `SectionPanel` 的蓝青色顶边装饰线。 - 移动角色差异采用“同框架、按角色裁剪内容和动作”：员工、审批人、财务、管理员、负责人看到不同入口、摘要、动作和敏感信息，但不做多套角色专属移动 UI。 - 移动验收必须包含跨视口自动化和代表性真机确认；若真机验证暂缓，只能记为 `PAUSED`，不能把相关移动阻断标为完成。 ## 报销专项规则 RI6 之后，报销和票据体验以“员工从报销详情补材料、财务从台账复核、移动端轻任务”为当前事实源： - 后端业务编号是用户主展示，例如 `BX20260506001`；UUID 不作为普通用户主编号。 - 草稿允许编辑和删除；审批中按审批状态提供可解释下一步；已通过、已支付不提供删除。 - 普通员工发票入口仍在报销详情“添加发票”，不恢复员工侧“票据中心/发票池”主导航。 - 发票状态文案使用“识别中、识别失败、可添加、已添加、重复票据、已归档/已报销”等用户可理解表达，不暴露 OCR provider、发票池、绑定整单、不绑定明细等内部术语。 - 报销详情按摘要、明细、发票、附件、审批流、付款状态和下一步动作分区；PC 保持高密度，移动保持轻任务。 - PC 端适合完整明细、对账和财务复核；手机端适合上传 PDF 发票、补充说明、继续编辑草稿和查状态。 - 报销详情等深层页使用统一移动详情壳和吸底操作，不把底部 Tab 留在深层事实页。 ## 请假、票据、采购、差旅规则 - 请假手机端应提供新建、编辑草稿、提交和查看记录，不显示桌面表格。 - 票据中心应显示票据号码、销售方、金额、OCR 状态和绑定状态，不把内部 ID 放在主位置。 - 采购和差旅页使用和报销一致的列表、状态、操作区和移动卡片规则。 - 所有上传控件都使用中文按钮和文件名回显。 LP6 之后，请假和采购体验以“状态清楚、审批历史一致、缺配置不 500”为当前事实源： - 请假详情展示日期、天数、假别、原因、当前状态、当前节点、审批历史和退回/驳回说明；从已批准记录返回时不得落到新建表单语境。 - 采购详情展示业务编号或标题、金额、状态、附件说明、审批历史和预算 warning。缺预算池时使用用户可理解提示，不暴露后端技术结果或返回 500。 - 报销、请假、采购三类单据的详情页和卡片遵循同一主标识、状态、关键指标、审批流和下一步动作槽位。 - 差旅仍不进入当前主线扩展；如恢复差旅能力，必须先新建独立 Issue CSV。 ## 当前移动批次状态 已完成的当前事实链为：R6、PC6、PA6、FL6、AP6、RI6、LP6、ME6 自动化与真机门禁、QG6、DG7/MRF7、MIA7、MIF7、MIF7T 和 MIF7TD。`ME6-3` 已关闭；后续移动体验问题进入 UX8 或单独 Issue，不重新打开 MIF7/MIF7T。 MIF7/MIF7T 已落地的移动规则包括： - 首页去重：常用入口改成不重复底部 Tab 的快捷动作，待处理摘要压缩为一张轻摘要。 - 进度页分标签：员工按草稿、审批中、已通过、退回驳回分组；审批人按待我审批、已处理分组。 - 通知中心事件化：通知不展示审批动作按钮，点击直达目标详情。 - 详情页统一壳：返回位置、标题、状态、内容顺序和底部动作一致。 - 返回语义统一：优先回来源页或来源标签；无来源时回业务列表或进度标签。 - 角色首页裁剪：普通员工、审批人和财务保留同一移动框架，但入口、摘要和动作按角色区分。 - 采购移动列表：移动端可查看采购列表和详情；移动发起采购属于后续需求，不默认纳入 R7。 历史阶段说明：早期文档中的 R99、R100、R101、R102、R103 是移动与页面治理的历史批次代号，不再作为 2026-05-12 之后的当前排期或待办事实源。需要追溯当时决策时，可阅读历史 Issue CSV 和 `docs/文档事实源状态矩阵.md`。 ## 验收规则 每个后续批次至少满足： - Issue CSV 中明确业务流程级 `Test_Method`。 - `node scripts/qa/check-ui-design-rules.mjs` 可运行并记录问题。 - 前端改动执行 `cd client && npm run typecheck` 和 `cd client && npm run build`。 - 涉及移动端或视觉问题时，补充 Playwright 截图或视觉诊断。 - 涉及状态机、权限、数据迁移时，单独 reviewer 审查并写清回滚路径。