把一张工资表，发成每个人都看得明白的工资条
HR 上传原本那张 Excel，不改格式、不先配规则：系统自动认表头、剔合计行、对上标准字段， 三条恒等式逐行校验，再按人推送到员工微信。员工收到的不只是一串数字， 还有「这个月和上个月差在哪」。
为还在用 Excel 发工资的中小企业而做 —— 尤其是骑手、计件这类工资条目多、月月变动、 员工最容易看不明白的行业。
为 30–200 人规模设计 · 上线前已在生产环境跑通全链路
演示数据：企业与人名均为虚构
「这个月怎么少了？」——把答案写在工资条上
工资条的疑问大多不是「算错了」，而是「看不懂变化从哪来」。系统对同一个人做上下两期逐项对比， 把差异项按金额排出来，再用一段中文说清楚。所有算术由确定性代码完成，模型只负责措辞。
本月实发 9,843.22 元，较上月减少 620.00 元。 主要差异项：绩效奖金减少 800.00 元、加班费增加 150.00 元； 应发下降带动个人所得税少扣 30.00 元。社保与住房公积金个人部分与上月一致。
| 项目 | 上月 | 本月 | 差异 |
|---|---|---|---|
| 绩效奖金 | 4,000.00 | 3,200.00 | −800.00 |
| 加班费 | 336.21 | 486.21 | +150.00 |
| 个人所得税 | 472.99 | 442.99 | −30.00 |
| 其余各项 | — | — | 无变化 |
| 实发工资 | 10,463.22 | 9,843.22 | −620.00 |
个税随应发下降而少扣 30.00 元，对实发是正向；两者相抵，实发净减 620.00 元。
陈述差异，不替员工下判断
「加班费较上月增加 150.00 元」可以说，「你的加班费算少了」不会出现——这类措辞在服务端强制拦截。工资金额以企业实际核算为准。
有疑问，当场问得出去
员工对某一项有疑问，在工资条上直接提交工单，自动带上是哪一期、哪一项；HR 在后台看到、回复、关单，全程有状态、有留痕。
签收生成回执，双方各留一份
员工确认时看到的内容会被快照并计算哈希一并存档，作为「已送达且已查看」的凭证，不是一句「已读」了事。
一张表进来，四步发出去
下面每一步的数字，都来自上线前在生产环境跑通的那一次真实发放：一张带标题行、两级合并表头、 末尾还有一行「没写合计二字的合计行」的骑手工资表。
上传：不用改你的表，也不用先配规则
xlsx / xls / csv 直接传。标题行自动跳过，两级合并表头还原成层级， 末尾的合计行靠算术关系认出来——不靠「合计」两个字做文本匹配， 所以那些只有数字、没有标签的汇总行同样能被剔除，并留作后续校验的基准。
映射：17 列全部自动对上标准字段
列名先过内置的字段别名字典，再过企业自己的历史模板，然后才是模糊匹配。
上线验证的这张表 17/17 全部自动命中，零次大模型调用。
只有真正拿不准的列才会停下来问人，问的时候会给出这一列的统计画像与合成样例，
让人一眼判断——而不是让人从头配一遍。
校验与核对：数据不对，当场就知道
三条恒等式逐行验算，任何一行不平都会指出来；同时把人按状态分桶， 异常的那几个人默认不发送，不必因为几个人卡住整批。
发放与对账：三个数对不上，批次不算完成
按人推送到员工微信；未绑定小程序或订阅消息额度不足时转短信兜底，未读的人留在名单里可继续跟进。 批次收尾要过一道对账门：导入有效行数 = 生成条数 = 应发人数，三个数不一致就不算完成—— 这是防漏发的最后一道闸。发错了可以撤销，签收记录随时导出。
名册跟着工资表长
不需要单独导入员工——传工资表就是在建名册。谁绑定了小程序、谁离职了、谁没有手机号，一眼看到；离职的人不删数据，最后一期工资条照样发得出去。
员工的疑问，落在一个地方
员工提交的疑问按批次归集，HR 逐条回复、关单。AI 可以起草回复初稿，但只草不发，发出去的永远是 HR 确认过的那一版。
把一条对不上的等式丢给它
后台助手能带批次上下文提问：这一批发得怎么样、哪一列没识别、哪条等式不平。回答里的数字同样只能来自系统事实清单。
工资数据只有一次机会，所以讲机制，不讲口号
下面四条都是能在系统里指出具体位置的做法，不是「银行级安全」这类没有对应物的说法。
加密每租户独立密钥的信封加密
工资条内容、身份证号、银行账号一律密文落库，AES-256-GCM，每个企业一把独立的数据密钥， 密钥与数据分离存放。
关键在于 AAD：加密时把租户、雇佣关系、期间、版本一并绑进认证数据。
即使有人能直接写数据库，把别人的密文复制到自己那一行，也解不开——校验失败并触发告警。
隔离跨租户读取在数据库层就不成立
PostgreSQL 行级安全（RLS），并且是 FORCE ROW LEVEL SECURITY：
表的属主也绕不过策略。每个请求在事务内 SET LOCAL 当前租户上下文，
策略据此过滤。
这意味着「A 公司的 HR 读到 B 公司的工资表」不是靠应用层记得加 where 条件来防， 而是在数据库这一层就不可能发生。
AI 边界模型看不到姓名、手机号和你的金额
解析环节发给大模型的只有：脱敏后的列名结构、不含个人标识的统计画像（P5/P50/P95）与合成样例。 姓名、手机号、证件号、银行账号、以及任何一个人的具体金额都不出域； 出网前有一道强制终审，检出疑似个人信息即中止并转人工——系统里不存在「检查不通过就照常发送」的开关。
解读环节更进一步：模型正文里只能写占位符，真实数字由服务器回填， 回填后再逐个数字比对事实来源，出现对不上的数字就整段作废、降级为固定模板。 模型在物理上没有机会写错数字。
留痕仅追加的审计链
敏感操作写入只可追加的审计日志，每条记录携带前一条的哈希构成链条。 事后插入、修改、删除任何一条都会导致断链，整链可校验。
签收也走同一套思路：员工确认时所见内容的快照与其哈希一并存证，凭证经得起回看。
工资结构越复杂，越用得上
首批面向骑手、配送、计件这类行业：收入项拆得细、月月都在变、员工看不懂的比例最高， HR 每个月要回答一堆同样的问题。
同样适用于任何还在用 Excel 发工资的中小企业。30–200 人是主力场景—— 这个规模通常没有专职薪酬系统，工资表在财务和 HR 之间来回传，工资条靠截图或纸条发。
- 不代发工资：不碰资金，不做支付结算。
- 不做算薪引擎：工资由你原来的方式算好，我们只做校验与送达。
- 不做 HR 全家桶：不碰招聘、考勤、社保、绩效。
- 不自行改动数据：员工看到的内容与企业提交的内容一致。
- 不用你的工资数据训练模型。
先拿你自己的工资表试一次
留下联系方式，我们会在 1 个工作日内联系你，约一次 20 分钟的演示： 用你自己的一张真实工资表（可以脱敏）跑一遍解析与校验，看看识别成什么样、有没有对不上的地方。
- 不用先改表格格式，也不用先配规则
- 演示用的数据不会进入生产环境，随时可要求删除
- 企业主体：合肥朴晴网络技术有限公司
已收到
我们会在 1 个工作日内联系你。
急的话也可以直接发邮件到 support@foboor.com。