25 KiB
25 KiB
海音达 OA 系统 - MVP 需求规格说明书
版本：2.0 日期：2026-05-09 范围：10 人以下科技公司试运行 MVP 需求基线 状态：当前 PRD 主事实源
相关文档：
- 文档索引：人工审查入口和文档阅读顺序。
- 产品口径文档：关键产品决策与边界。
- 功能状态矩阵：历史实现状态、覆盖证据和完成追踪，不作为 PRD 扩写入口。
- 管理员手册：试运行配置、企业微信入口和上线操作。
- 员工快速开始：员工侧使用说明。
- 报销与发票规则：报销、发票、OCR、附件的细则。
- 需求 - 统一审批中心规约：审批中心模块级开发规约。
- 需求 - 报销发票 OCR 规约：报销、发票、OCR、附件模块级开发规约。
- 需求 - 企业微信基础设施规约：企业微信入口、免登、绑定、通知、deeplink 和打卡采集边界规约。
- 需求 - 请假考勤修正规约：请假、补卡、外出、加班与考勤修正模块级开发规约。
- 需求 - 采购费用审批规约：采购申请、费用申请、审批、附件和业务关联模块级开发规约。
- 需求 - 合同附件归档规约：合同台账、编号、非涉密附件、归档、权限和审计模块级开发规约。
- 需求 - 项目轻管理规约：项目基础信息、成员、里程碑、任务、风险、交付和业务关联模块级开发规约。
issues/*.csv：每轮开发执行合同；需求确认后必须拆 Issue CSV 再开发。
1. 项目目标与当前路线
1.1 背景
海音达需要一套适合 10 人以下科技公司的轻量 OA，用来把报销、请假、采购、费用、合同、项目资料、审批和基础行政动作集中到一个可审计、可回归、可持续迭代的系统中。系统不追求一次性替代所有办公平台，而是先解决公司内部最容易割裂、最需要留痕的业务流程。
1.2 总目标
hyb-oa是唯一业务主系统和唯一正式审批中心。- 所有正式审批在 OA 内提交、审批、留痕、归档。
- 企业微信只作为基础设施：手机工作台入口、免登/绑定、通讯录身份、消息通知、打卡原始采集。
- PC 用户可直接访问 OA；手机端优先从企业微信工作台进入 OA 移动端。
- 后续开发必须先有需求事实源和 Issue CSV 执行合同，避免边想边做。
1.3 当前平台边界
| 平台 | 定位 | 首批使用方式 | 不承担 |
|---|---|---|---|
hyb-oa |
唯一业务主系统和审批中心 | 审批、报销、发票、OCR、请假、采购、合同台账、项目资料、审计归档 | 聊天、会议、在线文档协作 |
| 企业微信 | 基础设施 | 手机入口、免登/绑定、通知 deeplink、通讯录身份、打卡原始采集 | 正式审批流、财务附件主库、业务单据主库 |
| 飞书 | 已废弃路线 | 不进入首批实现 | 不接入身份、审批、通知、文档或项目主线 |
2. 软件开发项目流程
后续所有非微小改动按标准软件开发流程推进。流程目标不是增加仪式感，而是保证每轮都有清晰需求、可执行方案、可验证结果、可回滚边界和可追溯记录。
| 阶段 | 目标 | 输入 | 输出 | 门禁 |
|---|---|---|---|---|
| 1. 需求收集与边界确认 | 明确为什么做、谁使用、解决什么流程问题 | 用户反馈、试运行问题、业务制度、当前 PRD 和模块规约 | 需求描述、目标角色、主流程、必须做、暂不做、验收口径 | 需求不清不得进入开发；高风险歧义必须先澄清 |
| 2. 需求文档冻结 | 形成产品、开发、测试共同事实源 | 主 PRD、模块规约、产品口径文档、历史 Issue | 更新后的 PRD 或模块规约 | 没有事实源更新，不拆开发 Issue |
| 3. Issue CSV 执行合同拆分 | 把需求拆成可独立验收的任务 | 已确认需求文档 | issues/YYYY-MM-DD_HH-mm-ss-<slug>.csv |
CSV 必须校验通过；每个 Issue 写清范围、验收、测试、依赖 |
| 4. 技术方案设计 | 明确怎么实现和怎么回滚 | Issue CSV、现有代码、数据模型、接口和权限规则 | 实现方案、接口/数据变更说明、风险和回滚策略 | 涉及权限、状态机、迁移、审批规则时必须写回滚策略 |
| 5. 开发实现 | 按 Issue 实现后端、前端、脚本或文档 | 已批准方案和 Issue CSV | 代码或文档变更、必要测试用例、变更说明 | 不顺手改无关问题；跨端任务先稳定后端契约再接前端 |
| 6. 代码审查与自查 | 发现行为回归、权限泄漏、状态非法跳转和漏测 | 完整 diff、Issue CSV、测试结果 | Review 意见、修复记录或确认无阻断问题 | 涉及权限模型、workflow、数据迁移、审批规则时必须重点审查 |
| 7. 测试与回归 | 证明单点和业务链路都可用 | 变更内容、Test_Method、回归脚本、手工验收步骤 | 命令结果、业务流程验证结果、失败项和修复记录 | 后端、前端、PC、移动、企业微信入口按影响范围验证；不能假通过 |
| 8. 部署与发布准备 | 确认环境、配置、资源和回滚路径可用 | 已验证变更、部署脚本、配置清单、回滚策略 | 部署记录、/ready 检查、资源版本、配置复核 |
未部署不得告知用户可去公网或企业微信真机测试 |
| 9. 业务验收 | 让目标角色按真实路径确认结果 | 已部署环境、验收账号、样例数据、验收清单 | 验收结论、遗留问题、是否进入试运行 | 用户或指定验收人未确认前，不把体验问题视为关闭 |
| 10. 复盘与下一轮规划 | 把反馈转成下一轮可执行任务 | 验收反馈、线上问题、回归缺口、试运行记录 | 新需求、缺陷清单、下一轮 Issue CSV 草案 | 不直接把反馈插入开发；先回到需求和 Issue CSV |
2.1 本项目执行约束
详细测试、视觉验证、SKIP、状态回填和回归门禁以 测试规约与回归门禁 为准；Issue 生命周期、review、commit、工作区和交付输出以 开发交付与变更管理规约 为准。
- 所有非微小改动必须先有需求事实源和 Issue CSV 执行合同。
- 开发前必须说明实现方案；需求或方案不清时先澄清，不靠代码试错。
Dev_Status、Review1_Status、Regression_Status只能在对应验证通过后更新为DONE。- 后端变更至少执行 Prisma 校验、语法检查和相关业务回归；前端变更至少执行 typecheck、build，并按影响范围补 Playwright 或人工视觉验证。
- 涉及 PC、手机、企业微信入口的改动，必须验证入口、布局、deeplink 和移动端体验。
- 涉及生产、公网、企业微信真机或真实 OCR 的结论，必须以部署后 live smoke 为准；未配置真实条件时必须明确
SKIP和原因。 - 提交应按清晰主题小批次完成，commit message 使用中文并引用 Issue ID。
2.2 REQ8 当前需求状态表
| 分类 | 当前口径 |
|---|---|
| 当前已实现 / 已收口 | R6 小范围试运行主链路；PC6/PA6/FL6/AP6/RI6/LP6；ME6 自动化、公网和代表性真机门禁；MIF7/MIF7T 移动信息架构与真机反馈整改；MIF7TD 公网部署、匿名复检和带凭据 live smoke/OCR。 |
| R7 必需 | 用户确认参与人、角色、时间窗口、回滚联系人、问题登记负责人和每日收口节奏；R7E 公网健康、public bundle、带凭据 live readiness、公网移动矩阵、核心业务流和账号角色只读门禁通过；阻断问题为 0。 |
| R7 后优化 | UX8 真实反馈池、iPhone 12 间距观察项、详情字段扫读性二次优化、移动采购创建能力评估、组织账号主数据治理、图片 OCR 能力、转审扩展和邮件通道完整验收。 |
| 明确不做 / 当前冻结 | ERP 实时集成、AI 自动处理、完整差旅、复杂 BPM、审批设计器、预算重型控制、企业微信原生审批；任何一项启动都必须另建里程碑和 Issue CSV。 |
3. 用户角色与典型场景
| 角色 | 主要目标 | 高频动作 | 关键要求 |
|---|---|---|---|
| 老板/总经理 | 看清公司待办、费用、项目风险和审批瓶颈 | 审批大额事项、看项目和费用摘要、处理关键待办 | 少打扰、信息集中、审批记录可信 |
| 管理员/HR | 维护人员、入口、制度、请假和基础行政 | 员工管理、请假/补卡审核、公告、入离职、权限配置 | 配置清晰、可回退、有审计 |
| 部门主管/项目负责人 | 管团队交付和日常审批 | 审批报销/请假/采购、查看团队状态、跟进项目事项 | 待办清楚、移动端可处理 |
| 普通员工 | 快速提交申请和查状态 | 报销、上传发票、请假、补卡、外出、加班、采购申请、周报 | 手机好用、字段少、失败提示明确 |
| 财务 | 管报销、发票、付款和导出 | 发票查重、OCR 修正、付款标记、财务导出 | 数据完整、附件可追溯、重复票据可控 |
| 系统管理员 | 保障系统可用和可维护 | 部署、备份、恢复、日志、功能开关、企业微信配置 | 不泄露密钥、可定位问题、可回滚 |
4. MVP 模块优先级
| 优先级 | 模块 | 目标 | 主入口 | 验收口径 |
|---|---|---|---|---|
| P0 | 统一审批中心 | 所有正式审批在 OA 内处理 | PC 审批待办、移动审批 | 能提交、审批、驳回、退回、转审、留痕 |
| P0 | 企业微信基础设施 | 手机入口、免登、通知、打卡原始采集 | 企业微信自建应用 海音达工作台 |
手机进入 /mobile，通知 deeplink 回 OA |
| P0 | 报销/发票/OCR | 员工自助报销，财务可查重和导出 | 报销、移动报销、票据中心 | 上传、OCR、查重、绑定、审批、付款闭环 |
| P0 | 请假与考勤修正审批 | 请假、补卡、外出、加班等修正都在 OA 内审批 | 请假、移动审批、团队状态 | 审批后团队状态和考勤口径不破坏 |
| P1 | 采购/费用审批 | 小团队采购和费用事项留痕 | 采购、审批待办 | 申请、附件、审批、状态更新可用 |
| P1 | 合同与附件归档 | 管合同编号、责任人、归档位置和非涉密附件 | 合同/项目资料或项目页 | 能登记、查询、关联项目和审批记录 |
| P1 | 项目轻管理 | 把费用、采购、差旅、周报挂到项目 | 项目、Portal、周报 | 能看项目事项、风险、费用摘要，不做重型排产 |
| P2 | 预算/支付/ERP/AI | 在试运行稳定后增强运营能力 | 管理员备用入口 | 另立 Issue CSV，不进入首批验收 |
5. 统一审批中心需求
本章保留总纲口径。审批中心的角色、入口、状态、动作、权限、异常、留痕、审批规则配置矩阵、权限数据范围和验收细节，以 需求 - 统一审批中心规约 作为后续开发拆分依据。
5.1 范围
OA 是公司唯一正式审批中心。以下审批必须在 OA 内提交、审批、留痕、归档：
- 报销、费用、采购。
- 合同相关审批和合同台账维护。
- 请假、补卡、外出、加班、出差。
- 资产领用、归还、调拨、盘点中的需要留痕动作。
- 后续新增业务审批，默认也进入 OA 审批中心。
企业微信原生审批不作为公司正式审批入口，不允许形成“一部分审批在企业微信、一部分审批在 OA”的双轨口径。
5.2 审批能力
- 支持草稿、提交、审批中、通过、驳回、退回、撤回、转审、完成等状态语义。
- 审批链优先采用串行多节点；当前阶段不做并行会签。
- 大额或高风险单据通过审批规则配置多级审批，不通过硬编码角色分叉。
- 当前审批人只能处理分配给自己的待办，或者处理分配给自己角色且权限匹配的待办。
- 转审必须记录原因，转给具备对应审批权限的人，并保留转审历史。
- 单据编号由 OA 生成和保存；报销单、采购单、合同编号等应使用统一编号规则或对应业务编号规则。
5.3 数据与留痕
- 所有审批动作写入工作流历史。
- 关键例外动作写入审计日志，包括重复发票例外、付款标记、权限变更、附件下载、通知重试。
- 企业微信消息只包含脱敏标题、业务编号、状态和 deeplink，不包含涉密正文、完整发票、合同正文或敏感报价。
5.4 验收
- 审批人可在 PC 和移动端看到待办。
- 审批动作完成后，业务单据状态、审批历史、通知和审计记录一致。
- 企业微信提醒点击后回到 OA 页面处理，不能在企业微信原生审批里完成正式审批。
6. 报销、发票、OCR、附件与财务导出
本章保留总纲口径。报销、发票、OCR、附件、查重、财务复核、付款、导出、费用类型矩阵、人工验真和验收数据集，以 需求 - 报销发票 OCR 规约 作为后续开发拆分依据；历史细则继续参考 报销与发票规则。
6.1 用户流程
- 员工在 PC 或手机端创建报销草稿。
- 当前试运行上传 PDF 发票进入 OCR；图片可作为普通附件材料，图片 OCR 属后续能力。
- 系统执行 OCR，识别发票代码、号码、金额、日期、销方、购方等关键字段。
- 员工确认或修正识别结果，补充费用明细和说明。
- 系统做发票查重和基础校验。
- 员工提交报销，进入 OA 审批流。
- 审批通过后，财务复核并标记付款。
- 财务按期间、状态、项目、人员导出报销和发票数据。
6.2 发票与附件管理
- 发票和附件原始文件以 OA/对象存储为主，不依赖企业微信长期保存。
- 同一发票不得被重复报销；如确需例外，必须由授权财务角色填写原单号和原因。
- OCR 失败时允许重试和人工修正，但必须保留失败原因和修正痕迹。
- 报销完成后，相关发票进入已使用或归档状态，不能被普通员工再次绑定到新单据。
- 普通员工只看到“添加发票、上传附件、提交审批、查看状态”等业务语言，不暴露内部发票池概念。
6.3 财务导出
- 财务可按报销状态、付款状态、员工、部门、项目、期间筛选导出。
- 导出数据应包含业务编号、申请人、实际报销人、金额、费用类型、发票摘要、审批状态和付款状态。
- 导出不得包含未授权敏感字段明文。
6.4 验收
- 手机上上传 PDF 发票后，能完成 OCR、查重、绑定、提交。
- 报销审批通过后，财务能付款标记并导出。
- 重复发票、OCR 失败、附件缺失、金额不一致等异常有明确提示。
7. 请假、补卡、外出、加班与考勤口径
本章保留总纲口径。请假、补卡、外出、加班的角色、字段、状态、审批规则、团队状态、日历和考勤解释细节，以 需求 - 请假考勤修正规约 作为后续开发拆分依据。
7.1 边界
- 企业微信打卡用于原始采集，保留其定位、人脸、Wi-Fi、排班和设备能力。
- OA 不在首批重造打卡规则、定位、人脸识别或排班引擎。
- 请假、补卡、外出、加班等考勤修正申请在 OA 内提交和审批。
- 后续可同步企业微信打卡原始记录，再结合 OA 审批形成正式考勤口径。
7.2 用户流程
- 员工在 OA 提交请假、补卡、外出或加班申请。
- 主管或 HR 在 OA 审批。
- 审批通过后，团队状态、日历和后续考勤统计使用 OA 的审批结果。
- 企业微信打卡异常不直接等于最终考勤异常，最终口径以 OA 汇总为准。
7.3 验收
- 请假提交、审批、撤回、驳回后状态正确。
- 已批准请假能影响团队状态或日历展示。
- 文档和界面不引导员工去企业微信原生审批提交请假或补卡。
8. 采购、费用、合同与项目资料
本章保留 P1 总纲口径。采购/费用、合同归档、项目轻管理的字段、状态、权限、异常、验收场景和后续开发拆分建议，分别以 需求 - 采购费用审批规约、需求 - 合同附件归档规约、需求 - 项目轻管理规约 作为后续开发依据；审批动作、状态机、权限和留痕仍以 需求 - 统一审批中心规约 为总依据。
8.1 采购和费用审批
- 员工可提交采购或费用申请，填写用途、金额、项目、供应商、附件和期望时间。
- 主管、财务或老板按规则审批。
- 审批通过后形成可追溯记录，可关联预算、项目、付款和合同资料。
- 首批优先支持轻量申请和审批，不做复杂招采流程。
8.2 合同与附件归档
- 合同管理首批以台账为主：合同编号、名称、客户或供应商、项目、金额、负责人、状态、归档位置。
- 非涉密附件可进入 OA；涉密合同正文、敏感报价、成本细节和客户敏感资料不得进入公网 OA。
- 合同编号应由 OA 统一生成或由管理员登记后校验唯一性。
- 合同相关审批和变更记录应回到 OA 留痕。
8.3 项目轻管理
- 项目页只做轻量管理：成员、里程碑、任务、风险、交付记录、费用/采购/差旅关联。
- 不做重型甘特图、资源排产、CRM 或完整项目组合管理。
- 员工的报销、采购、差旅、周报和待办应尽量关联项目，减少另建表格。
8.4 验收
- 采购申请可提交、审批和查看状态。
- 合同台账能记录编号、责任人、归档位置和项目关联。
- 项目视图能汇总关键事项，不要求替代专业项目管理工具。
9. 企业微信基础设施需求
本章保留总纲口径。企业微信入口、免登/绑定、通讯录身份、消息通知、deeplink 和打卡原始采集边界，以 需求 - 企业微信基础设施规约 作为后续开发拆分依据。
9.1 自建应用
- 公司只维护一个企业微信自建应用，建议命名为
海音达工作台。 - 手机端默认入口进入
/mobile。 - PC 浏览器和普通账号密码登录默认进入
/portal。 - 企业微信入口失败时必须保留账号密码登录回退路径。
9.2 免登与绑定
- 支持企业微信 OAuth 或免登后识别员工身份。
- 首次未绑定时，员工可使用账号密码登录后在个人设置中完成绑定。
- 一个企业微信身份不得绑定多个员工。
- 员工离职或账号停用后，企业微信入口也不得继续进入业务系统。
9.3 消息通知
- 企业微信消息只做提醒，审批动作必须回到 OA 页面完成。
- 消息内容最小化：标题、业务编号、状态、处理入口。
- 发送失败应可重试，不阻断主业务提交或审批。
- 不在消息中发送合同正文、完整发票、敏感报价、银行卡、身份证等敏感内容。
9.4 打卡原始采集
- 企业微信打卡数据可作为后续同步来源。
- 首批不新增企业微信打卡 API 同步实现。
- 正式考勤统计必须结合 OA 的请假、补卡、外出、加班审批结果。
10. 权限、审计、数据安全与非功能要求
10.1 权限原则
- 后端是权限单一事实源；前端按钮显隐不等于授权。
- 普通员工只能看和处理自己的单据。
- 审批人只能处理分配给自己的待办或自己角色范围内的待办。
- 财务可处理发票、付款和导出，但不默认拥有系统管理权限。
- HR/管理员可维护人员、组织和基础配置，但敏感操作必须审计。
- 老板/总经理可查看公司级摘要和处理关键审批，但仍应保留操作留痕。
10.2 审计要求
以下动作必须可追溯：
- 登录、退出、绑定、解绑、账号停用。
- 单据提交、审批、驳回、退回、撤回、转审。
- 发票上传、OCR 重试、人工修正、重复例外、附件下载。
- 付款标记、财务导出、合同归档、权限变更。
- 企业微信通知发送失败、重试和配置异常。
10.3 数据安全
- 密码、密钥、令牌不得写入文档、日志或前端包。
- 银行卡、身份证、手机号等敏感字段对外响应应脱敏。
- 附件下载应有鉴权和有效期控制。
- 涉密合同正文、详细报价、成本细节、敏感客户资料不进入公网 OA。
- 生产环境必须有数据库和文件存储备份，并定期做恢复演练。
10.4 非功能要求
- PC 和移动端都应覆盖高频流程。
- 10 人以下团队的常用列表和表单应保持快速响应。
- 关键错误需要给出可操作提示，例如未绑定、权限不足、审批人缺失、OCR 失败、重复发票。
- 部署后必须能通过
/ready检查服务状态。 - 新功能应有可复现测试步骤，无法自动化时写清人工验收步骤。
11. 暂不做范围
首批 MVP 不做以下事项：
- 不接入飞书，不保留飞书登录、通知、审批、文档或项目管理路线。
- 不使用企业微信原生审批作为正式审批流。
- 不开发复杂 BPM 流程设计器，不做并行会签建模。
- 不依赖付费低代码平台、付费第三方应用或付费项目管理套件。
- 不重造企业微信打卡的定位、人脸识别、Wi-Fi、排班规则。
- 不做完整 CRM、ERP、PLM、甘特排产或项目组合管理。
- 不把聊天记录、会议纪要、涉密合同正文或敏感报价长期保存在 OA。
12. MVP 验收标准
12.1 产品验收
- 老板能在 OA 中看到审批待办、项目/费用摘要和关键风险。
- 员工能在 PC 或手机端完成报销、请假、采购等核心申请。
- 审批人能在 PC 和移动端处理待办。
- 财务能完成发票查重、付款标记和导出。
- 管理员能维护人员、权限、企业微信入口和基础配置。
- 企业微信只作为入口和提醒，不产生正式审批分叉。
12.2 流程验收
| 场景 | 验收步骤 |
|---|---|
| 报销主流程 | 上传发票 -> OCR -> 绑定明细 -> 提交 -> 审批 -> 付款 -> 导出 |
| 重复发票 | 上传已使用发票 -> 系统阻断 -> 财务授权例外需原因和原单号 |
| 请假流程 | 员工提交请假 -> 主管审批 -> 团队状态或日历更新 |
| 采购流程 | 员工提交采购 -> 审批通过或驳回 -> 状态和附件可追溯 |
| 企业微信入口 | 手机企业微信进入 /mobile -> 账号已绑定则直达，未绑定可回退账号密码 |
| 企业微信通知 | 收到审批提醒 -> 点击 deeplink -> 回到 OA 审批页处理 |
| 文档门禁 | 新需求先更新 PRD 或规则文档，再拆 Issue CSV，不直接开发 |
12.3 工程验收
- Issue CSV 校验通过。
- 文档 diff 检查通过。
- 涉及后端时执行 Prisma、语法和相关回归脚本。
- 涉及前端时执行 typecheck、build 和相关 Playwright。
- 涉及公网或企业微信真机时，必须部署后检查
/ready、前端资源和真实入口。 - 测试和提交证据必须符合 测试规约与回归门禁 与 开发交付与变更管理规约。
13. 后续 Backlog
后续事项必须另立 Issue CSV，不直接进入当前 MVP：
- 企业微信打卡 API 同步和考勤汇总报表。
- 补卡、外出、加班的完整移动端体验强化。
- 合同台账、合同编号、合同审批和离线档案号的细化。
- 预算控制、支付批次、AP 运营和 ERP 出站凭证增强。
- 项目轻管理与周报、待办、费用、采购、差旅的进一步联动。
- 全量 E2E 稳定性清理和移动视觉回归。
- 生产备份恢复演练、并发试运行和正式上线复核。
14. 文档维护规则
- 本文件回答“要做什么、为什么做、先做什么、不做什么、如何验收”。
docs/产品口径.md记录已经拍板的产品口径。docs/历史功能状态矩阵.md记录已经实现了什么和证据在哪里。issues/*.csv是每轮开发执行合同。- 需求变化必须先更新本文件或对应规则文档，再创建新的 Issue CSV。
- 不批量回改旧 Issue CSV 来伪造一致性；历史计划保留为历史快照。