← 返回目录

人事云 · 产品设计方案

版本：v2.0（按现行范围决策重写） 日期：2026-11-03 执行依据：docs/shared/范围决策-2026-11-03.md、docs/shared/中台与应用边界.md、docs/product/需求与流程总纲-v0.md 阶段约束：本文只做产品与交互设计，不编写业务代码。 替代关系：替代旧版“仅签约存证 MVP、假勤薪酬后置”的口径；旧版竞品定位、报价和路线数字不再作为本期承诺。

一、产品定义与范围决策

1.1 一句话定位

人事云是企业 AI 应用中台之上的一体化人事垂直应用：HR 在 Web 端管理多签约组织下的人员、假勤、薪酬（含社保公积金）、合同与可信确认，员工在微信小程序完成查看、申请、确认、异议和签署。

本期要求“模块完整可见、关键路径可用、导入数据可追溯”，不要求第一版即完成复杂排班、自动算薪或社保公积金申报的完整闭环。合同签署、工资条签收与存证是跨模块复用的“可信动作层”，不是产品的唯一卖点。

1.2 九项硬约束的产品落点

1.3 产品目标

1. 统一业务底座：在中台组织身份之上建立签约组织、用工关系、参保城市、合同主体等人事业务语义。
2. 先打通月度结果链：将外部系统或 Excel 中的排班、考勤、计薪、社保公积金结果导入人事云，完成校验、查看、确认、异议和追溯。
3. 跑通可信动作：合同签署、工资条签收、假勤结果确认共用身份、内容版本、动作时间、原文与存证凭证。
4. 支持多主体风控：让真实的多法人、多签约/发薪主体、多城市参保关系可维护、可授权、可审计。
5. 为后续闭环留好接口：规则版本、期间、导入批次和结果对象可继续接入打卡采集、排班引擎、自动算薪与申报连接，但不提前承诺交付。

1.4 非目标与明确边界

本期不做：

• 独立账号体系、应用内登录注册、企业开通、组织开通、计费、订单、储值或账单；
• 全量 HRIS，以及招聘、测评、绩效、培训、人才盘点、继任等完整人才管理线；
• 自研通用 OA 审批中心、完整薪酬财务系统或财务总账；
• 自研电子签、CA、可信时间戳或区块链底层设施，优先对接合规供应商；
• 第一版即覆盖全国全部城市的政策自动更新、自动核算、社保公积金网上申报或代缴；
• 第一版即覆盖复杂排班、全量打卡设备、完整假期规则、自动加班费核算与全场景算薪；
• 用多主体、工资拆分、补造记录等方式虚构用工关系或规避法定义务；
• 以“存证”承诺源数据真实、司法必然采信或仲裁结果。

二、用户、角色与使用场景

2.1 目标客户

几十人到 2000 人的制造业、连锁零售、物流及服务业企业，优先验证以下特征：

• 100–500 人、多门店或多法人，HR 团队精简；
• 假勤、薪酬已有 Excel、钉钉/企微、考勤机或第三方系统结果，不愿一次性替换全部系统；
• 存在多签约/发薪主体、多城市参保、多合同模板管理需求；
• 需要提升员工确认覆盖率，并减少合同、考勤和工资异议材料分散的问题。

2.2 角色与端

2.3 高频场景

1. 集团内 A、B 两家公司分别与员工签约、发薪，HR 在同一企业上下文按主体处理合同和期间数据。
2. HR 从现有考勤系统导出月度结果，导入后由员工在小程序确认或提出异议。
3. 薪酬专员导入应发应扣、社保和公积金明细，引用对应城市规则版本，生成工资条并签收。
4. HR 按签约组织、全日制/非全日制等用工类型和入职/续签场景选择模板，员工在小程序完成核验与签署。
5. 员工对考勤或工资金额有异议，HR 回复、补证或更正；原版本、处理过程与新版本完整保留。

三、总体产品架构

3.1 三层分工

3.2 双端形态

• HR Web：中台应用中心进入人事云后的业务内页；包含完整 IA、批量操作、配置、导入和审计。
• 员工微信小程序：统一待办 + 假勤 + 薪酬 + 合同 + 我的；支持业务所需的微信授权与中台身份绑定，不形成另一套企业账号体系。
• 原型与最终交付区分：静态 Web 原型只能用于评审布局和主路径，不替代微信小程序工程验收。

3.3 可信动作层

合同签署、假勤结果确认、工资条签收共用以下要素：

• 任务与参与人；
• 身份核验方式及结果；
• 文件或结果内容版本；
• 展示、阅读、确认、异议、签署等动作及时间；
• 原始文件、结果快照、附件和供应商回执；
• 拒签、撤回、过期、更正、重发与再次确认记录；
• 存证凭证、验真方式及导出记录。

过程记录只能增强可追溯性，不直接证明员工理解、自愿或司法采信。

四、信息架构与导航

4.1 HR Web 一级导航

人事云（中台 SSO 后应用内页）
├── 工作台
│   ├── 我的待办 / 异常事项 / 合同到期
│   ├── 假勤与薪酬期间状态
│   └── 导入任务与失败报告
├── 签约组织
│   ├── 签约/发薪主体列表
│   ├── 主体档案与适用城市
│   └── 员工用工关系与业务授权
├── 人员
│   ├── 员工业务档案
│   ├── 用工关系 / 入转调离记录
│   └── 合同、假勤、薪酬、文件时间线
├── 假勤
│   ├── 排班结果
│   ├── 考勤期间结果
│   ├── 请假/加班结果与待办
│   └── 员工确认与异议
├── 薪酬
│   ├── 计薪期间
│   ├── 薪酬结果与应发应扣
│   ├── 社保公积金
│   └── 薪酬导入与异常
├── 工资条
│   ├── 生成与预览 / 发放
│   ├── 签收与异议
│   └── 更正版本与再次确认
├── 合同
│   ├── 合同列表 / 签署任务
│   ├── 模板库
│   ├── 到期与续签提醒
│   └── 归档与存证
├── 导入中心
│   ├── 文件导入 / 接口任务（P1）
│   ├── 字段映射与数据预览
│   └── 校验报告与批次追溯
├── 规则与模板
│   ├── 城市社保公积金规则包
│   ├── 薪酬项目与导入映射
│   └── 合同模板适用范围
├── 证据与报表
│   ├── 签署/签收/确认记录
│   ├── 证据包导出
│   └── 期间运营报表
└── 应用设置
    ├── 业务角色与组织数据范围
    ├── 第三方服务配置
    └── 操作审计 / 返回中台

导航验收要求：“假勤”“薪酬”“社保公积金”均为可见、可进入、可导入和可查询的真实业务页面，不是远期占位菜单。“应用设置”不包含企业开通、订阅、账单或计费页。

4.2 员工微信小程序结构

微信小程序
├── 首页/待办
│   ├── 待签署合同、待签收工资条、待确认假勤
│   ├── 请假/加班相关待办（按本期配置）
│   └── 异常、驳回、过期与办理提醒
├── 假勤
│   ├── 排班与考勤期间结果
│   ├── 请假/加班记录与进度
│   └── 确认或提出异议
├── 薪酬
│   ├── 工资条列表与明细
│   ├── 社保公积金个人项目展示
│   └── 签收、异议与更正版本
├── 合同
│   ├── 待签 / 签署中 / 已完成 / 异常
│   ├── 身份核验与签署
│   └── 已签合同查看与下载
└── 我的
    ├── 当前及历史用工主体（按权限展示）
    ├── 我的文件与办理进度
    └── 身份绑定、隐私授权与帮助

小程序首屏优先呈现“需要我做什么”，再提供模块入口；员工无需理解 HR 的完整后台结构。

4.3 关键页面

工作台 - 顶部显示中台下发的企业名称和当前业务身份；签约组织筛选不影响中台企业上下文。 - 展示待办、失败导入、合同到期、假勤确认率、工资条签收率和未处理异议。 - 指标必须可下钻到明细，不用单一“合规健康分”掩盖业务缺口。

员工业务档案 - 基础身份来自中台，只读引用；人事云维护签约组织、发薪主体、用工类型、参保城市、用工状态与生效日期。 - 页签包括用工关系、合同、假勤、薪酬、社保公积金、文件与审计；敏感页签按业务角色显示。

期间作业页 - 假勤和薪酬均按“签约组织 + 期间”组织数据。 - 固定展示来源批次、规则版本、导入人、导入时间、校验状态、确认进度和更正状态。

五、核心领域对象与状态

5.1 关键对象

5.2 通用期间状态

假勤与薪酬期间统一采用：

草稿 → 导入校验中 → 待确认 → 已入账 → 已发放/已归档 → 已更正

• 校验失败不进入“已入账”；部分成功是否允许由业务类型配置，失败行必须单独报告。
• 已发工资条或已发起合同后不得通过删除导入批次抹除历史，只能走更正、撤回或新版本流程。
• 期间关闭后再次导入必须产生新批次，并明确是补充、替换未发布数据还是更正已发布数据。

5.3 业务状态解耦

• 合同“已签署”不自动等于入职、续签、调岗或离职已生效；需按合同类型和生效条件更新用工关系。
• 员工“已查看”不等于“已确认”，“已确认”不等于放弃异议权利。
• 工资条“已签收”不等于企业免除工资支付义务，异议处理不得阻断正常发薪。
• 存证“已回执”不等于证据必然被采信。

六、功能设计

6.1 中台接入与业务授权（P0）

本期能力 - 接收中台 SSO 上下文：企业、人员、部门、基础角色、应用访问资格和会话信息。 - 无权限、会话失效、企业上下文缺失时返回中台处理，不提供本地登录兜底。 - 在人事云内配置薪酬专员、假勤专员、合同管理员等业务角色和组织数据范围。 - 薪酬、身份证、银行卡、签署文件等敏感数据按角色、组织和用途控制展示与导出。

不做 - 本地注册登录、企业开通、通用组织管理、通用角色中心、应用购买和账单。

6.2 多签约组织与用工关系（P0）

签约组织档案 - 维护法人主体名称、统一社会信用代码、主体类型、签约/发薪属性、联系人、地址、适用城市和状态。 - 支持至少两个主体并行使用；列表、工作台、人员、假勤、薪酬、工资条、合同和报表均可按主体筛选。 - 停用主体前检查未完成合同、未关闭期间和有效用工关系；历史数据不可随停用删除。

员工用工关系 - 引用中台人员身份，补充签约主体、发薪主体、社保参保主体、公积金缴存主体、用工类型、工作城市、参保城市、公积金城市、岗位、用工状态和生效日期。 - 社保参保主体、公积金缴存主体可与签约组织/发薪主体不同，须显式记录并在详情、薪酬批次与工资条追溯中展示；不一致时生成核对项，不得为提高导入通过率自动改主体或城市；归属不清的记录不进入正式确认（合规 XC-04）。 - 发薪主体与签约主体不一致时展示关系并进入授权/审计范围，不提供规避法定义务的引导。 - 员工换主体采用“旧关系终止 + 新关系生效”，保留历史合同、工资条和确认记录。 - 数据访问按“企业 + 签约组织 + 用工关系有效期”控制，避免员工或 HR 越权查看其他主体敏感信息。

6.3 假勤：本期导入、查看、确认优先（P0/P1）

本期 P0 - 按签约组织和期间导入排班、考勤汇总、请假/加班结果；支持标准 Excel 模板和字段映射。 - 校验员工锚点、组织、期间、日期、工时/时长格式、重复记录和必填字段。 - Web 查看结果、来源、异常和员工确认状态；小程序按期间查看排班/考勤或导入结果。 - 员工可确认或提出异议，填写类型、说明和附件；HR 回复、补充材料或更正后再次确认。 - 页面明确“外部导入结果”，不将结果行描述为系统已采集的原始打卡。

本期 P1 - 轻量请假/加班申请与办理进度，或接收外部审批结果形成员工待办；具体采用哪种方式由 UX 与集成验证确定。 - 按部门、异常类型、确认状态汇总，不扩展为完整通用审批平台。

后续迭代 - 原始打卡采集、复杂排班、班次与假期规则、加班自动判定、考勤重算、设备与多平台实时同步、完整考勤到算薪联动。

6.4 薪酬：结果导入 + 城市规则版本（P0）

计薪期间与结果 - 按签约组织、发薪主体和计薪期间建立批次，导入薪酬项目、应发应扣、实发及必要计薪基础数据。 - 支持薪酬项目映射、显示顺序、员工可见性和敏感字段权限。 - 关联可用的假勤期间结果，但本期不承诺根据原始考勤自动计算工资。 - 对实发、应发应扣合计等执行可配置的勾稽校验；无法确认时显示异常，不静默修正金额。

社保与公积金 - 员工业务档案维护参保城市、公积金城市、参保方案和生效日期。 - 导入社保/公积金基数、单位与个人缴纳额、缴纳期间和缴纳结果；支持补缴、补扣等项目作为独立明细，不与当月常规项混写。 - 工资条可配置展示个人承担项目及金额；单位缴纳明细是否向员工展示由模板配置，HR 端完整保留。 - 导入记录必须关联城市规则版本；若只是历史结果迁移，可标记“历史导入、未参与核算”，不得假装已完成规则计算。

本期不做 - 完整自动算薪、个税全链路、银企直联、财务过账、社保公积金网上申报和代缴。

6.5 城市社保公积金规则包（P0 配置与引用，后续自动核算）

规则内容 - 国家/省/市层级标识、城市、适用险种、公积金项目、缴费基数上下限、单位/个人比例、取整规则、生效与失效日期、政策来源、备注。 - 可扩展城市特有项目、特殊人员适用条件和补充参数；不得用一条全国规则覆盖所有城市。

版本机制 - 草稿可编辑，发布后只读；政策变化创建新版本，不覆盖历史版本。 - 同一城市、同一项目、同一生效期不得存在冲突的已发布版本；发布前执行完整性与重叠检查。 - 薪酬期间创建时选择或按生效日期匹配规则版本，入账后固定快照；后续规则变化不得静默改变历史结果。 - 规则变更可生成“受影响组织/员工/期间”清单，但本期不要求自动重算。

政策维护 - 本期允许人工配置或批量导入，记录政策来源、维护人和复核人；至少验收两个城市及一个跨生效日版本变化。 - “政策自动监测、自动更新、自动申报”为后续能力，未经核验不得写成现状。

6.6 工资条签收、异议与更正（P0）

1. 从已校验薪酬期间结果生成工资条预览，HR 核对员工范围、可见项目、金额和主体。
2. 定向发放至员工微信小程序；记录发放时间、查看、签收和逾期状态。
3. 员工查看明细后签收或提出异议；可配置合理核验方式，但不以过度采集生物信息替代必要核验。
4. HR 处理异议：说明无需更正，或发起更正；处理过程、附件和回复留痕。
5. 更正生成工资条新版本并再次发放，原版本保留且可对比；员工始终可查看依法应提供的本人工资信息。
6. 不以员工未签收、未签合同或存在异议为由阻断工资发放或限制法定权益。

6.7 多合同模板与电子签约（P0）

模板库 - 支持劳动合同、保密/竞限制约、续签、变更、实习/退休返聘等多类模板；具体法律文本由合规角色审定。 - 每个模板配置适用签约组织、用工类型、业务场景、合同期限规则、变量、附件、签署方、核验等级和生效状态。 - 模板编辑产生草稿版本，发布后只读；合同实例固定引用模板版本和最终正文快照。

选用规则 - 发起时按“签约组织 + 用工类型 + 场景”筛选可用模板；默认推荐必须展示命中依据。 - 多个模板同时命中时由有权限的 HR 明确选择；手动改用其他适用模板需填写原因并留审计。 - 不允许选择与当前主体或用工类型明确不匹配的已发布模板；特殊例外须由模板管理员调整适用范围，而非绕过控制。

签署与归档 - HR 选择主体、员工、模板和合同要素，预览正文后发起；支持批量发起但每份合同独立记录版本与结果。 - 员工在小程序查看文件、完成必要身份核验、逐份签署；支持拒签、过期、核验失败和供应商异常状态。 - 完成后归档原文、签署回执、时间信息和存证/验真信息；员工可查看、下载本人合同。 - 支持合同到期提醒、续签任务与历史合同关联。

6.8 导入中心（P0 文件优先，P1 接口）

统一流程

选择签约组织与业务类型 → 选择城市/规则版本 → 选择期间 → 系统记录操作者/时间 → 下载模板 → 上传 → 字段映射 → 数据预览 → 锚点与业务校验 → 错误报告 → 确认入账 → 批次追溯

四组强制批次锚点 - 所有 Excel、文件或 API 导入必须同时带有：签约组织（签约组）+ 城市/规则版本 + 期间 + 操作者/操作时间，缺一不可；任一缺失、无效、冲突或无权限均不得入账。 - 操作者与操作时间取自中台 SSO 和系统时间，不允许上传文件冒填；城市与规则版本须匹配，规则已发布且覆盖业务期间。 - 非薪酬业务使用对应业务导入校验规则集版本，不允许空值或“无规则”绕过；多主体、多城市、多规则版本、多期间必须拆批。 - 员工类数据另用中台人员 ID/员工编号 + 用工关系 ID 作为行级键，不能替代四组批次锚点。

校验层级 1. 文件：格式、大小、表头、必填 sheet、编码和恶意内容检查。 2. 映射：来源列与目标字段、字典、日期和金额格式转换。 3. 批次锚点：签约组织 + 城市/规则版本 + 期间 + 操作者/操作时间；无法唯一确认或项间冲突时阻断入账。 4. 人员行级键：中台人员 ID/员工编号 + 用工关系；无法唯一匹配时阻断该员工数据入账。 5. 业务：重复行、跨组织、跨城市、跨期间、金额勾稽、规则覆盖、员工有效期和必填项目。 6. 权限：导入人必须拥有目标组织与业务域权限，薪酬数据不得由仅具假勤权限者导入。

错误与追溯 - 错误报告可下载，定位到批次锚点、文件行、字段、原值、原因和修复建议；敏感值在报告中按权限脱敏。 - 支持整批阻断或“成功行入账、失败行隔离”，业务模板必须明确采用哪种策略。 - 已入账批次及后续结果、工资条、确认、异议、更正和导出均保留四组锚点快照；另存源文件、映射、校验摘要和影响对象。未发布数据可撤销，已发布数据走更正流程。 - 以“四组锚点 + 来源记录主键”执行幂等校验，重复导入须提示冲突，不生成重复工资条、考勤结果或合同。

6.9 证据、报表与审计（P0 基础，P1 扩展）

• 按员工、签约组织、期间查询合同、假勤确认、工资条签收、异议和更正记录。
• 导出业务原文、版本、动作日志、供应商回执与目录清单；导出行为本身留审计。
• 报表至少包括导入成功率、失败原因、合同签署率、假勤确认率、工资条签收率、未结异议和到期合同。
• 证据包只陈述系统实际记录的内容，不将阅读埋点包装成“理解证明”，不宣称“上链即采信”。
• 保留期限、归档、删除和诉讼保全按合规规则另行确定，本期不得提供可绕过审批的批量物理删除入口。

七、关键用户流程

7.1 HR：建立多主体用工档案

前置：企业已在中台开通并授权人事云，HR 已通过 SSO 进入。

步骤：进入签约组织 → 新增/校验主体 → 配置签约/发薪属性与适用城市 → 从中台人员选择员工 → 补充用工类型、参保城市与有效期 → 分配业务数据权限 → 保存并进入档案。

异常：主体标识重复、员工锚点不唯一、用工关系日期重叠、无目标组织权限时不得静默保存；历史关系不能因新关系建立而删除。

7.2 HR：月度假勤导入与员工确认

步骤：选择签约组织、工作城市/假勤导入校验规则版本与假勤期间 → 系统记录操作者/时间 → 导入排班/考勤/请假加班结果 → 映射与预览 → 四组锚点/人员行级键/重复校验 → 成功入账并生成失败报告 → 发起员工确认 → 处理异议 → 必要时更正并再次确认 → 关闭期间。

失败分支：四组锚点任一缺失、无效、冲突或无权限均阻断；人员行级键不唯一则按模板隔离或整批失败；部分失败不允许以“导入成功”笼统提示；已发起确认后的数据更正必须保留原版本。

7.3 HR：薪酬与社保公积金导入、工资条发放

步骤：选择发薪主体、城市规则版本和计薪期间 → 系统记录操作者/时间 → 导入计薪与社保公积金结果 → 校验四组锚点、人员行级键、城市、期间和金额勾稽 → 预览 → 入账 → 生成工资条 → 指定范围发放 → 签收/异议 → 更正重发或说明办结。

失败分支：城市规则缺失或冲突时不得标记为“规则校验通过”；历史迁移可明确标记“未参与核算”；金额异常不得由系统自动改数；发放失败支持重试且不得重复发放。

7.4 HR：按主体、用工类型和场景发合同

步骤：选择签约组织 → 选择员工和签署场景 → 系统筛选适用模板 → 确认模板版本与正文变量 → 预览并发起 → 员工小程序签署 → 跟踪进度/催办 → 完成归档与到期提醒。

失败分支：无适用模板则停止发起并引导配置；核验失败按供应商与合规规则重试或转人工；拒签、过期、撤回均保留原因；签署完成后原文不可直接覆盖修改。

7.5 员工小程序：统一待办主路径

身份前置：微信授权后与中台人员身份绑定；无法唯一匹配、已离职无有效关系或授权失效时展示处理指引，不建立独立本地账号绕过企业授权。

主路径：进入小程序 → 查看待办 → 选择合同/工资条/假勤任务 → 查看内容与来源 → 确认、签收、签署或提出异议 → 获得办理结果 → 在“我的文件/进度”回查。

完成标准：三类核心任务（合同、工资条、假勤）均有完整成功与异常分支；员工无需跳转 HR Web，也不以静态 H5 作为最终验收端。

7.6 员工：异议与更正

员工在假勤结果或工资条详情提出异议 → 选择问题类型、填写说明并上传附件 → HR 收到任务 → 回复或更正 → 员工收到结果 → 对新版本再次确认 → 原版本、回复与新版本形成时间线。

异议未办结不得被自动显示为“员工无异议”；超时未操作是否自动确认必须由合规评审决定并清晰提示，MVP 默认不将沉默等同于认可。

八、权限、隐私与合规设计

8.1 权限模型

• 中台决定“谁能进入企业和应用”；人事云决定“进入后能管理哪些组织、业务域和敏感字段”。
• 采用企业隔离 + 签约组织数据范围 + 业务角色 + 字段级权限 + 操作审计。
• 薪酬、身份证明、银行卡、人脸/实名结果、合同附件和证据包导出采用最小授权。
• 批量导出、规则发布、模板发布、正式发放、合同发起等高风险动作要求明确确认并记录操作者。

8.2 数据与员工权益

• 告知员工数据处理目的、范围和必要授权；核验等级按场景风险选择，避免日常操作过度采集生物信息。
• 员工可查看、下载依法应获取的本人合同、工资信息等文件，不因未付费、离职或模块计费被不当限制。
• 不向劳动者转嫁电子签、存证、核验等企业经营成本，不设置“付费下载合同/工资条”。
• 不以未签合同、未签收或提出异议为由扣减、延迟或限制法定劳动权益。
• 多主体配置必须基于真实用工事实，不提供规避社保、工资支付或劳动义务的默认方案。

8.3 规则与法律边界

• 城市规则包保留来源、适用日期和维护记录；政策参数不等于个案法律意见。
• 合同模板由合规人员审定后发布；系统校验不能替代必要的专业审查。
• AI 如后续用于字段映射、异常提示或政策摘要，只能提供建议，最终金额、模板发布、合同发送由有权限人员确认。

九、MVP 范围与验收

9.1 本期优先级定义

• P0：8–12 周 MVP 上线验收必须完成，缺失即主路径不成立。
• P1：本期应尽量完成；如资源不足可降级到紧随 MVP 的迭代，但不得影响 P0 主路径验收，也不得被描述为已交付。

详细用户故事、验收标准和依赖见 docs/product/MVP-backlog.md。

9.2 P0 范围

9.3 P1 范围

• 历史合同与历史签署结果批量迁移；
• 轻量请假/加班申请或外部审批结果待办；
• API 导入任务与失败重试；
• 更丰富的期间报表、催办和证据包组合导出；
• 规则变更影响清单、导入模板自定义保存。

9.4 后续迭代，不计入本期验收

• 原始打卡、复杂排班、完整假期和加班规则引擎；
• 假勤到薪酬自动取数、完整自动算薪、并行算薪、冲正补差与财务过账；
• 全国政策自动更新、自动核算、社保公积金申报与缴纳连接；
• 完整招聘、绩效、培训、人才管理和通用 OA；
• 多租户服务商独立运营后台、独立计费或中台能力复建。

9.5 端到端验收用例

1. 多主体：建立 A、B 两个签约组织，两名员工分别归属；HR 只能按授权范围查看，分别发起合同和工资条且主体不串。
2. 假勤导入：同一期间分别导入一份正确文件和一份含未知员工、跨期间、重复行文件；正确数据可入账，错误报告可定位，重复提交不重复入账。
3. 薪酬导入：导入应发应扣、社保和公积金明细，完成预览与工资条生成；异常金额或缺失规则有明确状态，不静默修正。
4. 城市规则：至少配置两个城市，每个城市有可追踪来源；至少一个城市存在两个不同生效期版本，历史期间引用不被新版本覆盖。
5. 合同模板：同一企业配置不同组织、用工类型或场景的至少三个适用范围；发起时命中正确模板，合同实例保存模板版本。
6. 员工主路径：员工在微信小程序完成假勤确认、工资条签收和合同签署，并能查看办理进度与本人文件。
7. 异议更正：员工对工资条或假勤结果提出异议，HR 更正后生成新版本；旧版本、处理记录和新版本均可回查。
8. 中台边界：全流程无应用内登录注册、企业开通、组织开通、订阅、订单、储值或账单页面。
9. 品牌与形态：页面与文案统一使用“人事云”；员工功能以微信小程序验收，HR 功能以 SSO 后 Web 内页验收。

9.6 成功指标

十、版本路线图

路线图不将后续闭环倒置为本期既有能力，也不以“全量 HRIS”为最终目标。

十一、依赖、风险与待验证项

十二、文档协作要求

• 可审功能条目见 docs/product/需求功能定义.md，可画流程、状态与异常见 docs/product/流程定义.md；三份文档使用同一四组强制导入锚点。
• 本文是人事云产品范围与主路径基线；UX、合规和工程扩写不得恢复“本期不假勤/薪酬”或“员工端仅 H5”的旧口径。
• UX 需将 HR Web 与微信小程序分别出主路径、状态和异常，不用桌面原型替代小程序验收。
• 合规需细化城市规则维护、合同模板审定、员工权益、费用承担、证据表述和数据留存。
• 后续工程排期以 docs/product/MVP-backlog.md 为拆解输入；当前阶段禁止编写业务代码。

来源：docs/product/产品设计方案.md