hyb-oa/docs/trialrun/移动信息架构视觉流程审查.md

MIA7 移动 OA 信息架构、视觉与流程审查

审查日期：2026-05-12 代码基线：9da0ca9 审查范围：专用 /mobile 路由的首页、审批/进度、通知、报销详情、请假详情、采购详情、财务/审批人首页角色差异。 本轮性质：审查、规约和整改合同，不改业务代码，不部署，不关闭 ME6-3 真机门禁。

参考原则

公开资料只能抽象为本项目原则，不复制竞品页面：

• 钉钉审批强调假勤、财务等高频审批场景和手机端处理能力，适合作为“移动端服务高频轻任务”的方向参考：https://page.dingtalk.com/wow/dingtalk/act/approval-web
• 飞书审批强调统一入口聚合人事、财务、采购等流程、消息主动触达和移动端处理，适合作为“一个审批/进度入口 + 通知直达”的方向参考：https://www.feishu.cn/content/article/7584390246654037188
• 飞书催办说明发起人从“我发起的”任务详情发起催办，处理人收到消息通知，适合作为 AP6 催办语义的产品参考：https://www.feishu.cn/content/134344362384
• Ant Design Mini 的 TabBar、List、Tabs、SafeArea 分别对应底部主导航、列表槽位、分组切换和安全区语义：https://0x-mini.ant.design/components/tab-bar/ ，https://0x-mini.ant.design/components/list/ ，https://0x-mini.ant.design/components/tabs/ ，https://0x-mini.ant.design/components/safe-area/
• 企业微信应用消息适合作为 OA deeplink 通知通道，正式审批和业务状态仍以 OA 内部权限和状态机为准：https://s.apifox.cn/apidoc/docs-site/406014/api-10061693

落到 hyb-oa 的设计基线：移动端是消息驱动的轻工作台；首页只回答今天最该处理什么；审批/进度承载待我审批和我发起的进度；通知是事件收件箱；详情页是业务事实源。

当前标准

后续 MIF7 整改按 docs/产品设计规则.md 的 MIA7 标准执行：

• 底部导航只承载一级模块，首页常用只放快捷动作，不重复底部 Tab。
• 首页待处理最多一张轻摘要，不同时堆总数、三宫格、列表、状态标签和入口按钮。
• 员工进度使用草稿、审批中、已通过、退回驳回分组；审批人使用待我审批、已处理分组。
• 通知中心是事件收件箱，卡片展示事件、时间和已读状态，点击直达业务详情，不展示审批动作。
• 移动深层详情统一详情壳：左侧返回、标题/副标题、右侧状态、隐藏底部 Tab，内容按摘要、关键字段、材料、审批流、下一步动作排列。
• 返回优先回来源；无来源时回对应业务列表或进度标签，不回新建表单顶部。

视觉与源码证据

已核对的自动化截图：

• output/playwright/r6-wecom-mobile-rendering-hardening/w390-iphone12-wecom-mobile-home.png：390 x 844。
• output/playwright/r6-wecom-mobile-rendering-hardening/w414-iphone-wecom-mobile-home.png：414 x 896。
• output/playwright/mobile-oa-information-dedupe-governance/employee-progress-w390.png：390 x 844。
• output/playwright/mobile-oa-information-dedupe-governance/employee-progress-w414.png：414 x 844。
• output/playwright/mobile-oa-information-dedupe-governance/manager-approval-push-detail.png。
• output/playwright/mobile-oa-information-dedupe-governance/notification-direct-leave-detail.png。

关键源码证据：

• 首页常用入口与底部导航重复：client/src/pages/MobilePortalPage.tsx:223，client/src/features/mobile/navigation.ts:30。
• 审批人首页待处理摘要重复层级：client/src/pages/MobilePortalPage.tsx:276。
• 员工进度页未按状态分标签：client/src/pages/MobileApprovalsPage.tsx:915。
• 通知中心仍使用业务列表卡片语义：client/src/pages/MobileNotificationsPage.tsx:126。
• 报销详情自定义左返回：client/src/pages/MobileReimbursementDetailPage.tsx:798。
• 请假详情使用右侧返回且回到新建表单页：client/src/pages/MobileLeavePage.tsx:279、client/src/pages/MobileLeavePage.tsx:308。
• 采购详情使用右侧返回且固定回审批/进度：client/src/pages/MobilePurchaseRequestDetailPage.tsx:53。
• 通用 PageHeader 把 actions 放右侧，不适合作为移动深层详情返回壳：client/src/components/common/PageHeader.tsx:14。
• 首页图标宫格和 iPhone 12 间距相关 CSS：client/src/styles/mobile-touch.css:55，390px 宽度不会触发 max-width: 359px 的小屏特化。

问题分级

严重

1. 首页常用入口重复底部导航。员工常用里仍可能出现报销、进度、我的；审批人也会看到审批/报销/我的重复。问题根因是 primaryActions 直接复用了底部一级入口语义。建议常用只保留新建报销、传票据、请假、资产扫码、发起采购等动作。

2. 审批人首页待处理摘要过度重复。当前同一张卡内同时有 1 待批、待办/超时/类型三项数字、待办摘要卡、摘要卡 待处理 和 进入审批。这会让用户觉得首页有多块相同信息。建议压缩为一张轻摘要：标题、一个主数字、最紧急一条、一个“查看全部待办”入口。

3. 移动详情壳不统一。报销详情、请假详情、采购详情的返回位置、标题大小、状态位置和内容顺序不同；请假/采购返回按钮在右侧，报销返回在左侧。建议抽出统一 MobileDetailShell 或同等组件，所有深层详情复用。

4. 返回语义不稳定。报销回报销列表，请假回 /mobile/leave 但首屏是新建表单，采购固定回 /mobile/approvals。用户从通知或进度进入详情后，返回应优先回来源；无来源时回对应业务列表或进度标签。

一般

5. 员工进度缺少状态标签。草稿、审批中、已通过、退回驳回混在“我发起的”列表，和通知中心的事件列表观感接近。建议用标签或分段，默认显示“审批中”，草稿和已通过可切换。

6. 通知中心和进度页视觉语义过近。通知卡片仍像业务卡片，缺少事件流特征。建议通知卡片增加事件类型图标、未读主导、时间和来源，弱化金额/节点等业务详情字段，不展示审批动作。

7. 请假移动页把新建表单和记录列表放在同一长页。用户从已批准请假返回时容易落到新建请假语境。建议拆成“新建请假”和“请假记录”两个入口或在同页使用分段标签，详情返回记录标签。

8. 采购缺少清晰移动列表入口。已有详情页，但没有明确“我的采购”移动列表承接返回和历史查看，导致采购详情只能回审批/进度。建议在进度页保留来源参数，或补轻量我的采购列表入口。

9. 财务和经理首页差异不够。当前移动首页主要围绕审批能力判断，财务角色缺少待复核、待付款、台账/导出优先摘要。建议财务首页独立摘要卡显示待复核、待付款、风险/异常、进入台账。

10. 进入审批 文案不精确。点击待办摘要进详情，点击按钮进列表，这个行为可以保留，但按钮应改成“查看全部待办”或“进入待办列表”，避免误解。

11. iPhone 12 图文间距仍需用用户真机截图复核。现有 Chromium 截图没有完整复现真实 iOS 14 企业微信差异；CSS 在 390px 宽度下使用默认图标宫格间距，可能受 iOS 14 WebView 字体渲染或企业微信内核影响。建议后续把用户 iPhone12 和 iPhone14 截图作为 MIF7 视觉样本，不按机型硬编码。

体验建议

12. 首页中“待办、超时、类型”三项指标适合审批效率页或管理统计，不适合移动首页首屏。移动首页应优先行动，不优先统计。

13. 通知中心的作用需要在产品模型中固定为“事件收件箱”：看发生了什么、快速进入详情、批量已读。审批进度才负责看状态，不要两边都承担状态追踪。

14. 深层详情内容应统一信息顺序，但字段按业务差异裁剪：报销突出金额、发票、附件、审批、付款；请假突出日期、天数、假别、原因、审批；采购突出金额、供应商、明细、附件、审批。

角色流程审查

角色	当前可用	主要问题	建议目标
普通员工	底部进入“进度”；通知可直达报销/请假/采购详情；采购和请假不再跳首页	常用入口重复底部 Tab；进度未分状态；请假返回落到新建表单；通知与进度视觉接近	首页只放快捷动作和进度摘要；进度按状态标签；详情返回记录或来源标签
审批人/经理	首页有待处理摘要；底部审批角标正常；待办摘要可进入详情，按钮进入列表	首页待处理重复层级过多；按钮文案不精确；详情壳和返回不统一	首页只保留一个待办摘要；按钮改“查看全部待办”；审批详情统一 Push 壳
财务	底部红色角标可接受；财务可使用已实现台账和付款能力	财务首页和经理首页差异不明显，缺少待复核/待付款/导出摘要	财务首页优先财务待办、付款、风险异常、台账/导出入口

自动化规则建议

后续 MIF7 或 QG7 可以落地以下断言：

1. 首页常用入口与底部导航重复数不得超过 0；如保留一级入口，必须有明确白名单和理由。
2. 首页待处理摘要同一卡片内数量表达层级不得超过 2 个，例如主数字加一条待办，不再出现三宫格统计。
3. 普通员工 /mobile/approvals 必须存在状态标签或分段：草稿、审批中、已通过、退回驳回。
4. 通知中心卡片不得包含审批动作按钮；点击有目标的通知必须进入业务详情或审批详情。
5. 所有 /mobile/*/:id 深层详情必须隐藏底部 Tab，并存在统一左侧返回控件。
6. 请假详情返回不得落到新建表单顶部；采购详情不得无条件返回审批首页。
7. 财务账号移动首页必须出现财务摘要或财务入口，且不与经理首页完全同构。
8. 移动视觉矩阵继续覆盖 320、360、375、390、393、414、430px；真实 iPhone12/iOS14 企业微信截图作为单独人工样本，不用自动化替代。

后续整改顺序

建议后续执行 MIF7，而不是继续逐个按钮修：

1. 首页去重和常用动作重排。
2. 进度/审批分标签。
3. 通知中心事件化。
4. 统一移动详情壳和返回语义。
5. 财务首页角色化摘要。
6. 自动化断言和真机截图复核入口。

本报告只登记问题和标准，不代表上述问题已修复。