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

产品体验事实源

2026-05-27 治理口径：前端视觉、布局审美、组件观感、字体、颜色、动效、间距和交互细节的最终裁决统一交给 frontend-design skill。本文件不再作为设计规则手册，只保留 hyb-oa 的产品体验事实、业务信息架构、页面职责和验收边界。

权威边界

• frontend-design：决定页面视觉方向、布局表达、审美质量、控件组合、交互动效、响应式呈现和前端设计一致性。
• 本文件：记录 hyb-oa 特有的用户场景、角色优先级、模块职责、信息展示语义、企微/OA 边界和验证要求。
• 业务模块规约：报销、审批、采购、合同、项目、资产、企业微信、OCR、附件等领域细则以对应 docs/需求-*.md、docs/报销发票附件规则.md 和当前 Trellis task 为准。
• Trellis spec：沉淀稳定工程规则和实现约束；当前任务的范围、验收和测试计划以 .trellis/tasks/<task>/prd.md 为准。
• 历史 Issue CSV 和历史截图只用于追溯，不作为新页面设计裁决。

不得再把竞品页面、旧批次样板、颜色值、圆角、卡片样式、字体、官网视觉截图或历史视觉规则追加到本文。需要前端设计判断时，直接使用 frontend-design。

用户与使用事实

• 目标用户是 10 人以下的国内科技公司，角色重叠、审批链短、使用频次高。
• PC 端主要服务批量查看、对账、审批、财务复核、导出和管理配置。
• 手机/企业微信端主要服务提交、补材料、查状态、处理待办和从消息直达业务详情。
• 系统应优先支持真实工作流，不做营销站式介绍页，也不把低频配置入口放到高频员工路径里。
• 页面可见内容应使用国内 OA 常见表达，例如待处理、草稿、审批中、已通过、已支付、已驳回、提交、保存、删除、撤回。

页面职责分层

页面分层只用于判断优先级、业务信息量和验证范围，不规定具体视觉样式。

• A 类核心流程：登录/找回密码、首页、审批中心、审批/进度移动页、报销列表、报销详情、移动报销详情、通知中心。
• B 类业务运营：票据池、AP 台账、付款批次、请假、采购、资产、项目、项目详情、合同台账。
• C 类管理配置：用户、组织、主数据、审批规则、工作流定义、系统设置、Feature Flag、审计日志。

A 类页面优先保证真实试运行路径顺畅；B 类页面优先保证台账、复核和导出不误导；C 类页面允许展示更多审计和排障信息，但不得泄露无权限数据。

OA 与企业微信边界

• OA 主办：报销、采购、费用、合同、项目、付款、AP、代账和高敏附件仍在 OA 内提交、审批、查看和导出；企业微信只发送脱敏消息和 OA deeplink。
• 企微镜像：HR/考勤员工日常审批、打卡、人事助手和假期余额优先由企业微信主办；OA 展示同步镜像、规则快照、审计状态和失败重试。
• OA 应急接管：仅管理员人工开启应急模式后，OA 才临时开放请假、补卡、外出、加班提交和审批；页面必须说明应急原因、范围和预计结束时间。
• 企业微信消息只承载标题、类型、编号、状态和入口；点击后通过免登录或账号绑定进入 OA 目标页，附件查看和审批动作仍按 OA 服务端权限执行。

信息语义

• 普通用户主展示使用业务编号或业务摘要，不把 UUID、taskId、entityId、内部状态码或调试字段作为主编号。
• 审计页、管理员排障页和打印留痕页可在权限允许范围内展示必要内部编号。
• 同一业务对象在同一区域只展示一次主标识；同一状态在同一区域只展示一次。
• 通知中心是事件收件箱，不是待办列表或进度页副本；通知点击应直达业务详情、审批任务或可解释的失败提示。
• 首页只做工作台摘要，不重复完整待办列表、通知列表和进度列表。
• 审批入口同时服务审批人和发起人：审批人处理待我审批，员工查看我发起的进度。
• 普通员工不应看到不可点或无权限的审批入口；审批、财务、负责人和管理员只能看到服务端允许的动作。

业务体验事实

• 报销主展示使用后端业务编号，例如 BX20260506001；UUID 不作为普通用户主编号。
• 报销草稿允许编辑和删除；审批中按审批状态提供可解释下一步；已通过、已支付不提供删除。
• 普通员工发票入口在报销详情补充材料，不恢复员工侧“票据中心/发票池”主导航。
• 发票状态文案面向用户表达，例如识别中、识别失败、可添加、已添加、重复票据、已归档/已报销；不暴露 OCR provider、绑定整单、不绑定明细等内部术语。
• 请假、补卡、外出、加班的员工日常主路径优先走企业微信；OA 负责镜像、审计、异常和应急接管。
• 采购、合同、项目、财务附件和高敏资料不迁移到企业微信原生审批或企业微信附件。
• 差旅仍不进入当前主线扩展；如恢复差旅能力，必须先新建独立 Trellis task。

验收边界

• 前端页面改动必须先使用 frontend-design 做设计判断，再按影响范围执行 cd client && npm run typecheck、cd client && npm run build 和必要 Playwright/视觉验证。
• 涉及移动或企业微信 WebView 的改动，应覆盖代表性视口；真机验证暂缓时只能记为 PAUSED，不能用自动化通过替代人工确认。
• 涉及权限、状态机、审批规则、数据迁移、生产配置、企业微信写入或真实数据写入时，必须按当前 Trellis task 和对应业务规约补充验证与回滚说明。
• 面向用户可测试的页面改动，只有部署和公网检查通过后，才可告知用户可以测试。
• 本文件自身不代表页面已经整改、不代表已经部署、不替代真实试运行 Go/No-Go。