hyb-oa/docs/产品设计规则.md

产品设计规则基线

本文件是 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 和企业微信/手机端都遵循同一品牌色和控件语义，只根据屏幕密度调整布局。

主 UI/布局参考层级

DG8 之后，hyb-oa 的唯一主 UI/布局参考是飞书工作台/飞书审批。主参考只用于统一布局密度、信息层级、交互克制度和 PC/移动一致性；Hyinda 官网品牌气质、OA 工作台定位和本文件规则优先于任何竞品。不得复制飞书页面文案、视觉细节、IM、云文档、多维表格、开放平台生态、登录、审批、通知或项目能力。

参考层级固定如下：

• 主参考：飞书工作台/飞书审批。PC 工作台、审批列表、审批/进度分组、消息直达详情、催办语义和移动轻任务优先按这一层抽象。
• 品牌修正：Hyinda 官网的品牌蓝、浅色背景、清晰边界、克制字号和工作台气质是最终视觉裁剪标准。
• 功能流程参考：钉钉只参考审批场景覆盖和高频申请模板；泛微 e-office 只参考 OA 信息架构和台账结构，不指导视觉风格；每刻/合思只参考报销、票据、OCR、财务复核和付款导出流程，不指导整体 UI。
• 控件语义参考：Ant Design 只参考 PC 表格、筛选、表单和导航的中后台语义；WeUI/Ant Design Mobile 只参考移动控件、安全区、TabBar、List、Tabs 和动作反馈语义。
• 实际基础设施：企业微信只做入口、绑定、免登录、个人应用消息和 deeplink，不替代 OA 正式审批页，也不指导 OA 主视觉。

落到 hyb-oa 的统一布局原则：

• PC 工作台是高密度办公面板，首屏优先待处理、我发起的进度、退回待补、财务待复核/待付款和异常提醒；列表保留筛选、批量查看、审批、财务复核、导出和管理配置。
• 移动端首页是消息驱动的轻入口，服务提交、补材料、查状态、处理待办和从企业微信消息回流；不得把 PC 表格和批量管理能力搬到手机端。
• 审批/进度入口承载两类视角：审批人处理待我审批，员工查看我发起的进度；通知仍是事件流，点击应直达业务详情或审批详情。
• 详情页是业务事实源，PC 按摘要、关键字段、附件/发票、审批流和日志分区；移动深层 Push 页隐藏底部 Tab，使用顶部返回、状态和吸底操作。
• 竞品资料只用于抽象原则；不得复制飞书、钉钉、企业微信、泛微、每刻、合思、WeUI 或 Ant Design 的页面文案、视觉细节和专有交互。

DG9 页面分层与样板

DG9 之后，页面整改以“共享样板先行、核心流程优先、低频配置后置”为执行口径。DG9 只承接 UI/布局统一，不替代 WF8 审批通知验收、不替代 UX8 真实反馈池、不替代 BIZ8 财务/OCR/项目业务验收，也不代表已启动部署。

页面分层如下：

• A 类核心流程：审批中心、审批/进度移动页、报销列表、报销详情、移动报销详情、首页、通知中心。这些页面优先使用 DG9 工作台骨架和移动槽位，是后续页面整改的样板。
• B 类业务运营：票据池、AP 台账、付款批次、请假、采购、资产、项目、项目详情等。按 A 类样板迁移，但不新增移动采购创建、不恢复冻结差旅主线、不改变 OCR、付款、导出或项目关联接口。
• C 类管理配置：用户、组织、主数据、审批规则、工作流定义、系统设置、Feature Flag、审计等。保持中后台高密度布局，允许在授权管理场景展示必要内部编号或审计字段，但不改变权限模型、审批规则语义或路由。

DG9 样板规则：

• PC 列表页使用统一工作台骨架：WorkspaceHeader、指标条、FilterBar、主表格、分页和批量/导出操作区。
• PC 详情页使用统一事实源骨架：顶部摘要、关键字段、材料/附件/发票、审批流、日志和主操作区；同一状态或业务编号不得在同一区域重复展示。
• 移动页使用统一移动槽位：mobile-card、mobile-list-card、固定状态槽、mobile-field-row、安全区和吸底操作，不把桌面 card-std p-4/p-5/p-6 主容器回流到专用 /mobile 页面。
• 通知仍是事件流，首页只保留一处待办或进度摘要；企业微信继续只承担入口、免登录、个人应用消息和 deeplink。
• 后续页面任务必须先判断页面属于 A/B/C 哪一层，再选择 DG9 样板，不再临时混用多个竞品视觉风格。

参考资料：

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