hyb-oa/.trellis/tasks/archive/2026-05/05-29-frontend-simplification-refactor/prd.md

前端页面降噪重构需求讨论

Goal

围绕 hyb-oa 当前前端页面“信息啰嗦、操作入口过多、用户理解和完成任务成本高”的问题，先明确重构目标、优先页面、保留能力和验收口径，再决定是否进入实现。

Status: 第一轮 PC Web 样板实现已完成并通过本地验证。

Scope

• 第一轮只重构 PC Web 的工作台首页和报销列表：PortalHomePage.tsx 任务入口化，ReimbursementsPage.tsx 员工进度视图化。
• 同步更新受影响的 Playwright/E2E 断言，保证现有 PC 核心路径仍按新信息架构验证。
• 将稳定的页面降噪规则沉淀到 .trellis/spec/hyb-oa/frontend-react-vite-design.md。
• 不修改后端 API、数据库、权限模型、审批/报销状态机、移动端/企业微信页面或生产配置。

What I already know

• 用户反馈的核心问题是：页面感觉啰嗦，需要操作的内容太多，对用户而言体验复杂。
• 用户已确认首批治理路径为：工作台/首页 → 待办/审批 → 报销列表/报销详情。
• 用户已确认本次核心目标是先把“我现在该点什么”变清楚。
• 用户已确认首批角色视角优先服务普通员工和审批人：员工提交/查状态，审批人处理待办；财务/管理员先只做“不挡路”。
• 项目是面向 10 人以下国内科技公司的 OA，角色重叠、审批链短、使用频次高。
• PC 端主要承担批量查看、对账、审批、财务复核、导出和管理配置。
• 手机/企业微信端主要承担提交、补材料、查状态、处理待办和从消息直达业务详情。
• 产品事实源将页面分为 A/B/C 类：A 类核心流程包括首页、审批中心、报销列表/详情、移动报销详情、通知中心等。
• 前端已有共享模式：PageScaffold、ListWorkspace、WorkspaceHeader、WorkbenchHero、EntityOverviewHero、PrimaryTable、StatStrip 等。
• 前端规约要求 PC 页面保持“密集但有序”的 OA 操作布局，不做营销式页面；移动页面复用统一 mobile shell、卡片/列表行、安全区和粘性操作模式。

Assumptions

• 本轮讨论先做需求收敛，不直接修改代码。
• “降噪”不等于砍掉业务能力，而是重新分层：高频主动作前置，低频/高风险/排障动作后置或折叠。
• 优先重构 A 类核心流程比全面铺开更可能产生可感知收益。
• 需要区分普通员工、审批人、财务/管理员，不同角色看到的入口密度应不同。
• 本次优先治理同屏操作入口过多、层级不清，而不是优先删除业务数据字段。
• 本轮先做前端层降噪，不改后端流程、接口、权限模型、状态机或审批/报销业务规则。
• 首批实现限定为 PC Web；移动端/企业微信页面本轮不做重构，只做必要回归确认。
• 实现节奏采用“先样板、再扩展”：第一轮先做工作台和报销列表，第二轮再扩展到审批中心和报销详情。
• 第一轮样板采用硬性首屏动作预算：每个页面首屏只允许 1 个主按钮、最多 2 个次级入口，其余动作进入“更多/高级/详情”。
• 页面说明文案采用预算规则：只服务风险、异常、空态；常规流程说明不作为默认可见内容。
• 低频能力本轮采用“隐藏/后置，不删除”原则，不破坏现有功能能力。

Open Questions

• 当前无阻塞问题；后续若实现发现现有接口无法支撑目标视图，先回到 PRD 讨论，不直接改后端。

Requirements (evolving)

• 首批治理路径锁定为：工作台/首页 → 待办/审批 → 报销列表/报销详情。
• 首批主任务按“员工提交/查状态、审批人处理待办”定义。
• 工作台首页从“综合仪表盘”调整为“今日任务入口”，首屏只回答：我现在要处理什么、我能发起什么、我最近的单据到哪了。
• 审批中心默认视图调整为“待我处理优先”，首屏只显示审批人当前可处理的任务。
• 审批中心的“我发起的”“已处理”“全部/历史”放到次级 Tab 或筛选；批量审批、统计摘要、流程解释、历史记录不压在第一层。
• 审批中心行内主动作保留“处理/查看”，避免一行出现多个同级操作。
• 报销列表默认从“全功能台账”调整为“员工进度视图”，首屏突出新建报销、草稿待补、审批中/被驳回需处理、最近已通过/已支付状态。
• 报销列表中的模板创建、关联差旅、导出 CSV/Excel、批量审批、复杂筛选、删除说明后置；财务/管理员可通过角色入口或高级视图进入台账模式。
• 报销详情从“所有信息平铺页面”调整为“状态驱动页面”，顶部只回答当前状态、下一步、谁要处理。
• 报销详情按状态展示主动作：草稿为补明细/补发票/提交；审批中为看进度/催办；被驳回为看原因/修改后重提；已通过/已支付为查看结果/下载或留档。
• 报销详情中的明细、发票、附件、预算、审批记录、财务导出继续保留，但按当前状态相关性排序或折叠，不在首屏全部平铺。
• 实现范围限定为前端信息架构和交互层重排：默认视图、操作显隐、排序、折叠、文案和布局。
• 不在本轮修改后端 API、数据库、权限、状态机、审批动作、报销数据结构或业务规则。
• 首批实现限定 PC Web 的工作台、审批中心、报销列表和报销详情；移动端保持现状，不纳入本轮重构。
• 第一轮实现样板限定为 PC Web 的工作台和报销列表，用于验证入口降噪、默认视图重排和主动作体系。
• 审批中心和报销详情暂作为第二轮扩展对象，第一轮不直接修改。
• 工作台首屏主按钮根据当前用户上下文确定：有审批待办时优先“处理待办”，否则优先“新建报销”或当前最相关发起动作。
• 报销列表首屏主按钮固定为“新建报销”，次级入口限定为“查看需要我处理的单据”和“高级筛选/台账”。
• 删除、提交、驳回、预算超限、OCR 失败、权限不足、空列表等场景可以保留解释文案；普通状态下删除“先看状态再处理”“进入详情查看附件审批历史”等重复操作说明。
• 模板创建、差旅关联、导出、批量处理、高级筛选、删除草稿等能力不删除，后置到“更多”“高级筛选/台账”“详情页动作区”或特定状态下再出现。
• 每个目标页面需要明确 1 个主任务和 1-2 个主动作，让用户能立即判断下一步。
• 导出、批量、删除、催办、模板、差旅关联、调试/错误详情等低频或高风险动作应后置到更多菜单、详情页、权限场景或二次确认中。
• 财务导出、批量审批、系统管理、排障信息可以存在，但不应抢占普通员工和审批人的第一屏注意力。
• 首页中的团队状态、近期动态、公告、项目、组织、系统摘要、采用率等内容保留为次级区或折叠区，不与待办、报销、审批抢首屏注意力。
• 降低目标页面首屏信息和操作负担。
• 保留真实业务流程必须动作，不隐藏用户完成任务所必需的入口。
• 不把低频配置入口放到高频员工路径里。
• 普通用户界面不暴露 UUID、内部状态码、调试字段或服务端实现术语。
• A 类核心流程优先保证试运行路径顺畅。

Acceptance Criteria (evolving)

• 明确本次重构的首批目标页面或用户路径。
• 明确第一轮样板页面：工作台和报销列表。
• 明确第一轮样板首屏动作预算。
• 明确说明文案预算。
• 明确低频能力隐藏/后置、不删除。
• 明确每个目标页面的主任务、主动作、次级动作和隐藏/延后动作。
• 明确不做范围，避免把降噪扩大成全站重写。
• 明确前端实现前需要遵守的设计与验证口径。
• 第一轮实现后，员工路径“打开首页 → 新建报销/查看报销进度”可通过可视化检查确认更清楚。
• 第一轮实现后，审批人路径“打开首页 → 处理待办/进入审批中心”可通过可视化检查确认更清楚。
• 第一轮实现后，保留前后截图对比，并检查首屏满足 1 个主按钮、最多 2 个次级入口。
• 第一轮实现后，说明文案只服务风险、异常、空态，普通流程解释不作为默认可见内容。

Definition of Done

• PRD 记录用户确认后的范围和验收标准。
• 若进入实现，先按 Trellis workflow 激活任务并读取前端规约。
• 前端改动需执行 cd client && npm run typecheck && npm run build。
• 涉及核心页面时补充必要 Playwright/视觉验证。
• 面向用户可测试的页面改动，部署和公网检查通过后再通知用户测试。

Out of Scope

• 本轮讨论阶段不直接改代码。
• 不重构移动端/企业微信页面；仅在 PC 改动可能影响共享逻辑时做必要回归。
• 不处理差旅能力恢复。
• 不调整权限模型、真实数据、生产配置或企业微信写入。
• 不修改后端 API、数据库、审批流程、报销状态机或权限判定。
• 不做全站一次性重写，除非后续明确批准。

Technical Notes

• 当前任务：.trellis/tasks/05-29-frontend-simplification-refactor/
• 体验事实源：docs/产品设计规则.md
• 前端规约入口：.trellis/spec/frontend/index.md
• hyb-oa 前端规则：.trellis/spec/hyb-oa/frontend-react-vite-design.md
• 路由入口：client/src/router/index.tsx
• 首批目标页面当前体量：PortalHomePage.tsx 1260 行、WorkflowTasksPage.tsx 460 行、ReimbursementsPage.tsx 992 行、ReimbursementDetailPage.tsx 1923 行。
• 初步代码观察：工作台、报销列表和报销详情都同时承载状态摘要、说明文本、筛选、批量、导出、附件/票据、审批记录等内容，复杂感更像“同层级内容过多”而不是单纯视觉样式问题。
• 视觉和交互设计裁决后续应使用 frontend-design skill；本轮先按 grill-me 做需求拷问。

Verification

• cd client && npm run typecheck：通过。
• cd client && npm run build：通过。
• cd client && npx playwright test tests/e2e/visual-shell.spec.ts --grep "PC 首页与报销列表" --workers=1 --reporter=list：1 passed。
• cd client && npx playwright test tests/e2e/login-portal-ux.spec.ts --grep "Portal (员工视角|管理视角|bootstrap|域管理)" --workers=1 --reporter=list：4 passed。
• python3 ./.trellis/scripts/task.py validate .trellis/tasks/05-29-frontend-simplification-refactor：通过。
• node scripts/qa/check-trellis-governance.mjs：通过。
• git diff --check：通过。

Test Plan

• cd client && npm run typecheck
• cd client && npm run build
• cd client && npx playwright test tests/e2e/visual-shell.spec.ts --grep "PC 首页与报销列表" --workers=1 --reporter=list
• cd client && npx playwright test tests/e2e/login-portal-ux.spec.ts --grep "Portal (员工视角|管理视角|bootstrap|域管理)" --workers=1 --reporter=list
• python3 ./.trellis/scripts/task.py validate .trellis/tasks/05-29-frontend-simplification-refactor
• node scripts/qa/check-trellis-governance.mjs
• git diff --check