游戏行业AI人事系统项目奖金核算方案

去年底，我参与了一家 200 人规模游戏公司的薪酬体系重构，核心矛盾就发生在项目奖金分配上。一个 SLG 项目组做了八个月，上线首月流水破了两千万，但奖金核算持续了三周还没落地，不是差钱，是分不清楚。程序组说策划反复改需求拖了进度，策划组说美术资源没到位，美术组说程序给的技术评估从一开始就有问题。最后老板拍了一个大家都不满意的数，两个核心主程次月离职。这事让我反复想一个问题：不是游戏行业做不好奖金核算，是我们一直在用“管理体力活”去应对一个“规则复杂+数据分散+信任缺失”的系统性问题。而 AI 人事系统真正能改变的，不是算得快，是算得让人服气。

下面这篇文章，是我从实际项目里走出来的一整套认知框架、判断逻辑和落地经验，讲的是游戏行业 AI 人事系统项目奖金核算方案的完整构建方法。我不会给你一个“万能模板”，因为游戏行业从研发到发行、从单项目到多项目并行、从独立工作室到集团化运作，场景差异极大，任何承诺“一键适配”的方案都是在回避真正的复杂度。但我会把核心逻辑、关键取舍、常见误区和可以复用的判断标准讲清楚，让你在面对具体问题时知道该往哪个方向走。

一、先讲最核心的结论

我在跟至少六家游戏公司（其中四家使用 I人事 系统）做过项目奖金核算方案后发现，成功落地的方案都有一个共同特征：团队花在“规则设计”上的精力远远超过花在“数据计算”上的精力。这句话听起来有点反常识，因为很多老板最初买系统是冲着“自动化算钱”去的，但真正跑顺了的公司，无一例外都在启动期投入了至少两到三轮的规则讨论会。

更具体的结论有三条：

第一，AI 人事系统在项目奖金核算中的核心价值不是“算得快”，而是“建规则”。传统核算的瓶颈从来不在计算本身（Excel 也能算），而在于：数据碎片化分布在飞书/钉钉、Jira、Git、工时系统、成绩系统里，根本没人能完整拼出来；规则透明度低，每次核算都需要大量沟通解释成本；核算周期长到发奖金时大家的热乎劲早过了。AI 系统解决的是这三个问题。

第二，公平性＞效率。我见过太多方案一上来就强调“效率提升 80%”，但上线三个月后员工满意度反而下降，因为算得越快，越像“拍脑袋”。员工不在乎你到底用了多少人力去核算，他们在乎的是：为什么他拿得比我多？这个数据的来源是什么？规则是谁定的？如果一个 AI 方案不能把“为什么”解释清楚，算得再快也是负分。

第三，核算方案必须适配游戏行业的项目生命周期，而不是套用传统行业的“月薪×系数”逻辑。游戏项目在立项期、研发期、测试期、上线期、长线运营期的考核维度完全不同。一套方案要能动态切换权重，否则就会出现“上线期还在用研发期的功能完成率算奖金”这种荒唐事。

下面这张图可以帮你快速理解，不同规模游戏公司在引入 AI 人事系统前后，项目奖金核算的核心变化点集中在哪些维度：

二、为什么传统核算方式在游戏行业尤其行不通

我服务过的几家公司，在改用 AI 系统之前，都经历过至少一次“奖金核算引发团队动荡”的事件。这不是巧合，是结构性问题。

1. 数据分散在至少五个不同系统里，人工拼凑是常态

我拿一家做二次元卡牌游戏的中型公司举例。他们的项目奖金核算需要从以下系统取数：Jira 看研发任务完成情况，Git 看代码提交量和质量，飞书审批记录看各种跨部门协同确认，Excel 工时表看每人投入天数，运营后台看上线后的留存和付费数据。核算一次，HR 和项目助理要花两周时间，先把数据分别导出，再做数据清洗（因为各系统的用户 ID 命名规则都不一样），然后在一个巨大的 Excel 里跑公式。

这还不是最大的问题。最大的问题是：每个数据源都只有“一部分真相”，拼在一起也拼不出完整的贡献画像。比如一个策划在 Jira 上只有 3 个完成的任务，看起来产出很低，但他花了大量时间在音乐外包对接和声优沟通上，这些工作在任何一个系统里都没有痕迹。传统人工核算完全依赖项目经理的主观判断来补这些“盲区”，而主观判断一多，公平性就无从谈起。

AI 人事系统的价值首先体现在这里：它不是简单地搬运数据，而是通过 API 和数据中台把散落在各处的行为数据做统一归集，然后在同一个平台内完成清洗、对齐和比对。比如 I人事 的做法是把打卡、审批、项目管理系统、代码仓库等数据源全部接入，形成一个统一的“员工行为数据底座”。这个底座解决的不是计算问题，是“数据可信度”问题，当你把所有数据拉到一起之后，至少不用再花一周时间去怀疑数据的完整性。

2. 项目周期短、并行多、人员频繁流动，静态规则根本跟不上

游戏行业的一个典型特征是多项目并行。我见过一个小型工作室，不到 40 个人，同时跑着三个项目：一个自研的放置类游戏，两个对外接的美术外包。有人在三个项目里都有工时投入，有些人这周在这个组下周调到另一个组。如果你的奖金核算规则是按“本月在 A 项目的工时占比”来算，那规则本身就变成了一个易碎品，只要有一次人员调整没及时录入，核算结果就全错了。

更棘手的是项目阶段切换。同一个游戏在研发期的核心指标是“功能完成度”和“版本交付准时率”，到了上线期就变成“首日留存”“付费率”“Bug 修复速度”。如果核算规则不跟着变，就会出现一种荒谬的情况：研发期拼死拼活把版本赶出来的团队拿得少，上线后坐享其成的运营拿得多。

传统方案的处理方式是每个季度/半年修订一次规则，但游戏行业的节奏太快了。我见过一个项目从立项到测试只用了三个月，核算规则如果是按半年度修订，规则刚定完项目已经进入下一阶段了。

用一张表来对比会很清楚：

3. 不同工种的贡献量难以用单一维度衡量

这是游戏行业奖金核算最核心的矛盾。一个程序员写了一万行代码，一个美术画了 20 张原画，一个策划写了 50 页策划案，谁的贡献更大？没有办法用同一个度量衡来比较。

我踩过的坑是，早期尝试过用“统一折算系数”，比如把程序的工作折算成“标准人天”，美术的工作也折算成“标准人天”，然后按人天占比分奖金。结果美术组炸了，因为程序觉得自己的技术含量更高，折算系数应该更高；美术觉得自己的创意不可量化，折算本身就是侮辱。最后谁也说服不了谁。

后来我意识到，不同工种的贡献不应该被“统一换算”，而是应该在各自的专业维度内做独立评价，最后通过权重和规则引擎在系统层面完成综合排序。这才是 AI 人事系统能做的事：不是去定义一个“万能公式”，而是允许每个工种拥有独立的考核模型。

以 I人事 在服务的一家游戏公司为例，他们在系统里配置了四套并行的考核模型：

• 程序：代码质量分（来自 SonarQube 等工具）+ Bug 修复时效 + 关键节点交付情况 + 技术评审贡献
• 策划：功能设计通过率 + 上线后核心数据指标（留存/付费）+ 跨部门协同评价
• 美术：资源通过率 + 修改次数上限达成率 + 外包管理成果（如适用）+ 版本适配完成度
• QA：Bug 检出率 + 回归测试效率 + 线上事故预警次数

四套模型各自独立跑分，最终在奖金分配时按工种权重和项目贡献度做综合排序。这个方案的关键在于：没有人被要求在“跨工种”层面做比较，所有比较都在同工种内部完成，跨工种的平衡由系统规则预设好的权重来处理。

三、关于 AI 人事系统项目奖金核算，最常见的三个误区

在跟不同游戏公司沟通方案的过程中，有三个误区几乎每次都会出现。它们会让一个本可以跑通的方案从一开始就走偏。

1. “AI 能自动搞清楚谁做了多少贡献”

这是最大的误解。AI 人事系统不会像侦探一样自动发现员工的贡献，它只能基于你告诉它的数据来源和规则来计算。换句话说，如果你的数据源本身无法反映真实贡献，AI 只会高效地算出错误的结果。

我遇到过一家公司，他们把 Jira 的任务完成数作为程序考核的唯一数据源，结果上线三个月后发现，那些热衷于抢简单任务、把复杂任务推给别人的程序员拿的奖金反而最高。系统没有错，系统忠实地执行了“任务完成数=贡献”的逻辑；错的是规则设计。

这就是为什么我一再强调：引入 AI 系统的第一步不是技术对接，而是把“贡献”的定义在团队内达成共识。哪些行为值得奖励？哪些结果应该加权？哪些隐性贡献需要单独标记？这些问题不讨论清楚，AI 就没法帮你。

一个实际可行的做法是：先在 Excel 里把规则逻辑跑通，用三个历史项目的数据做回溯验证，看看结果是否符合团队的主观判断。如果回溯结果让你觉得“这明显不合理”，那就说明规则本身有问题，而不是数据不够多。

2. “越复杂的规则越公平”

跟上一个误区相反，还有一种倾向是把规则设计得极其复杂，恨不得把每个可能变量都纳入计算。我见过一份奖金核算方案文档，光计算公式就写了三页，包含十几个系数和四个层级的嵌套条件。

这种方案在实际执行中会遇到两个致命问题：第一，太复杂的规则员工根本看不懂，看不懂就不信任；第二，太复杂的规则维护成本极高，每次调整都要改一堆参数，而且很容易产生意外的连锁反应。

我曾经接手过一个“翻车”案例：某公司设计了包含“个人绩效分×项目绩效分×公司绩效分×时间系数×角色系数”的五因子模型。第一版算出来，有一个表现一般的员工因为刚好赶上了公司绩效好的月份，加上他所在的项目组最小、角色系数最高，拿的钱比核心项目组的技术骨干还多。算法没问题，但结果让所有人觉得荒谬。

我的建议是：规则要简洁到每个员工都能用一句话讲清楚“我的奖金是怎么算出来的”。比如：“我的奖金=项目总奖金池×我的贡献占比，贡献占比由交付质量（40%）、关键节点达成（30%）、团队协同评价（30%）三项加权决定。”这就够了。如果一句话讲不清楚，规则就太复杂了。

3. “系统上线了就等于方案落地了”

系统上线只是完成了“数据能跑了”这一步，离真正落地还差着几个关键动作：规则宣讲、试运行、过渡期处理、第一次正式核算后的复盘调整。

我见过最失败的一次案例是：公司花三个月对接完系统，HR 觉得万事大吉，直接把核算结果生成出来发给各项目组确认。结果项目组负责人看到数字整个人是懵的，因为没人提前告诉过他这套规则是怎么设置的。他一周内提出了 30 多条质疑，最后不得不重新回到人工核算，系统白上了。

AI 人事系统在奖金核算中的落地，本质是一次管理变革，不是一次软件安装。它的成功至少需要这四个动作：

1. 上线前至少做两次全员宣讲，把规则、数据来源、计算逻辑用非技术语言讲清楚
2. 设置 1-2 个月的过渡期，过渡期内新旧方案并行，以旧方案为准发钱，新方案作为参考让全员适应
3. 过渡期结束后收集反馈，做一轮规则微调，微调后的规则至少在两个核算周期内不再变动
4. 每次正式核算结束后，系统自动生成个人核算明细页，标明每项数据的来源和计算过程

四、构建可落地的核算方案：六个关键决策点

这一节进入最实操的部分。结合我在多个项目中的经验，构建一套可以在游戏公司真正落地的 AI 人事系统项目奖金核算方案，需要依次做对六个关键决策。

1. 奖金池的切分逻辑：按项目、按团队还是按个人？

这是方案设计的起点。游戏行业的通行做法是三层结构：公司→项目→个人。先确定公司级的年度/季度总奖金包，然后切分到各个项目，最后在项目内分配到个人。

但这个结构在遇到以下情况时会出问题：

• 中台部门（技术中台、美术中台）：他们同时支持多个项目，不能简单归属到某一个项目的奖金池
• 孵化期项目：还没上线没收入，但团队一直在投入，这部分人怎么激励？
• 职能支撑部门（HR、财务、行政）：他们的贡献跟具体项目无关，但要跟公司整体业绩挂钩

我推荐的一个分层模型是：

• 纯项目组人员（策划、程序、美术、QA）：80% 的收入来自所属项目奖金池，20% 与公司整体业绩挂钩
• 中台复用人员：60% 来自其参与的各项目奖金池（按工时占比加权），40% 与公司整体挂钩
• 孵化项目人员：设“里程碑奖金”而非依赖收入分成，每达成一个关键节点（如完成技术验证、通过内部评审、拿到版号），解锁对应奖金
• 职能人员：100% 与公司整体业绩挂钩，但设一个部门级 KPI 调节系数

这个模型在 I人事 系统里的落地方式是：为不同类别的人员打上“归属标签”，系统在核算时自动识别标签并调用对应的分配规则。不再需要 HR 每次手动区分这个人属于哪个团队。

2. 核算周期的设定：按月、按版本还是按里程碑？

这是游戏行业跟传统行业差异最大的地方之一。传统制造业/服务业按月核算奖金是合理的，但游戏项目的节奏完全不同：一个版本可能开发了两个月，期间加班无数，但上线那个月的产出才真正转化为成果。

我在实践中总结了一个判断框架：

• 研发期：按里程碑核算（技术验证完成、Alpha 版本交付、Beta 版本交付、上线）。如果研发周期较长（超过 6 个月），可以在两个里程碑之间插入季度回顾，发放小额预支奖金以维持士气
• 上线初期（首月-首季）：按月核算，高频反馈，因为数据变化剧烈，团队需要快速知道自己的努力跟结果的关系
• 稳定运营期：按月或按季度核算均可，按季度可以减少核算成本，但要配合月度数据看板

这里有一个我反复强调的点：核算周期和反馈周期是两回事。即使你按季度发奖金，也要给员工提供月度甚至周度的数据反馈。AI 人事系统在这方面的价值是：你可以实时看到自己在各项指标上的得分和排名变化，而不是等到发钱那天才知道结果。I人事 的个人数据仪表盘功能在这类场景里用得比较多，员工登录就能看到自己的“贡献画像”实时更新，这对维持动力的作用比奖金本身还大。

3. 考核指标的选择：既要“结果”也要“过程”

游戏项目奖金核算最容易出现的一种偏差是“唯结果论”，只看上线后的数据，不看研发过程中的付出。这会导致两个后果：一是研发期没有人愿意加入（因为回报不确定），二是所有人都想往“能出数据”的项目挤，没人做铺垫性的技术升级或工具链建设。

我的建议是：任何项目的考核指标都必须同时包含“过程指标”和“结果指标”，两者的权重根据项目阶段动态调整。

这个表不是固定的，但它给出了一个清晰的逻辑：越早期的阶段，过程指标的权重应该越高，因为那时候还没有“结果”可以衡量。很多公司在这个问题上犯的错误是，对研发期项目也用“预计收入”来倒推奖金，而“预计收入”本身就是一个极其主观的数字。

4. 个人贡献的量化方法：不同工种的差异化方案

这个前面已经部分涉及，这里做系统性的展开。在 AI 人事系统中，个人贡献的量化通常有三种方式，不同工种可以选择不同的组合：

（1）直接产出量化

适用工种：程序、美术等产出可计数的岗位。但要注意，数量指标必须配合质量指标使用，否则会鼓励刷量。比如程序不能只看代码行数，必须同时看 Code Review 通过率和 Bug 密度；美术不能只看原画数量，必须同时看资源通过率和返工次数。

（2）关键节点达成评价

适用工种：策划等产出难以直接量化的岗位。把项目拆成 8-12 个关键节点，每个节点设定一个交付标准，按节点达成情况评价。这个方法的优势是让策划不用纠结于“写了多少页文档”，而是关注“这个节点的设计是否让下游团队可以顺利进入执行”。

（3）多维 360 度评价（慎用）

适用场景：管理岗、跨部门协同频繁的岗位。但我不推荐在 AI 系统中大规模使用纯主观的 360 度打分来核算奖金，因为太容易受到人际关系影响。可以把它作为一个微调系数，比如占比不超过 10%，作用是在客观数据无法覆盖的“软贡献”上做一个补充。

5. 系统数据源的接入与清洗：真正的门槛在这里

很多公司以为 AI 人事系统对接一下数据库就能用了，实际上最耗时的是数据清洗和对齐。下面是我经历过的一个真实流程：

• 第一周：盘点所有相关系统的数据结构和字段定义。常见问题是同一员工在 Jira 里用的是英文名，在飞书里是中文名，在 Git 里是邮箱前缀。必须先建立一个统一的“员工标识映射表”
• 第二周：逐一确认每个数据字段的业务含义。比如 Jira 里的“已解决”状态，在部分项目组指的是“开发完成”，在另一组指的是“经 QA 验证通过”。如果不统一口径，跨组比较就失去意义
• 第三周：跑三个历史项目的回溯测试。用旧数据在新规则下跑一遍，结果跟历史人工核算结果做对比，标记出差异超过 20% 的个案，逐一分析原因
• 第四周：根据回溯结果调整规则并确认最终版本

这个四周流程是不可压缩的。我见过有公司为了赶时间，跳过回溯测试直接上线，结果第一次核算结果跟预期差了 30% 以上，引发了严重的信任危机。

6. 透明度与解释性的设计：让每个人都能“看懂自己的钱”

这是把 AI 人事系统的价值从“计算工具”提升到“信任基础设施”的关键一步。我在 I人事 的实施案例中学到一个很重要的设计原则：每个员工在系统里看到的不是“你这个月奖金是多少”，而是“你的各项得分和排名是多少，对应的奖金是这个数”。

具体来说，个人奖金核算明细页应该至少包含以下信息：

• 你所在项目的总奖金池是多少
• 你在同工种中的综合评分排位（比如“在同项目 12 名程序人员中排第 3”）
• 各项考核指标的得分明细和原始数据来源（点击可穿透查看）
• 你的贡献占比和对应的奖金金额
• 如果有特殊加减分项，注明原因和审批人

这一页的设计逻辑是：不给员工质疑的空间，而是提前把质疑的答案都摆出来。当一个人看到自己的每一项得分都有明确的数据来源，同组其他人的相对位置也一目了然时，他对分配结果的接受度会大幅提升，即使他不完全满意自己的奖金金额。

下面这张图展示的是员工在系统中查看奖金构成时最常关注的信息优先级分布，这对页面设计有直接参考意义：

五、不同类型游戏公司的方案差异化配置

前面的内容侧重通用框架，这一节聚焦不同类型的游戏公司应该如何根据自己的特点做方案调整。我根据服务经验，把游戏公司分为四类来讨论。

1. 独立工作室（20-50 人，单项目为主）

这类公司的特点是：团队小、决策链短、老板通常就是制作人，对每个人的贡献心里大概有数。但他们面临的问题是，项目成败高度依赖几个核心人员，奖金分配一旦让核心人员不满，损失巨大。

对于独立工作室，我的建议是：不要过度依赖系统自动化，而是用 AI 系统做数据归集和规则透明化，保留老板的最终调整权。具体做法：

• 考核指标不超过 3 个核心维度（如：关键节点达成 + 团队满意度互评 + 老板综合评价）
• AI 系统负责把每个维度的数据客观呈现出来，形成初步排名
• 老板在看到系统生成的初步结果后，有权在 10%-15% 的范围内做手动微调，但必须写明微调理由并在系统内留痕

这种“系统做主框架+管理者做微调”的模式，既保留了小型团队的灵活性，又避免了纯粹拍脑袋的随意性。

2. 中型研发/发行公司（100-500 人，多项目并行）

这是我服务最多的类型，也是 AI 人事系统价值最明显的区间。这个规模的公司，老板已经不可能对每个人的贡献都心里有数了，项目之间的资源争夺和人才竞争也开始出现。

对于这个类型，核心挑战是跨项目的资源分配和奖金平衡。我建议在系统中建立三层平衡机制：

• 第一层：项目间的奖金池分配，由公司管委会计分卡决定（参考指标：项目流水、利润率、战略价值分）
• 第二层：项目内不同工种的奖金池分配，由预设的工种权重系数自动切分
• 第三层：项目内同工种人员的个人分配，由个人贡献评分在工种内部排名决定

以使用 I人事 系统的一家 200 人游戏公司为例，他们在系统里跑通这套三层分配后，跨项目的人员调动变得顺畅了很多，因为大家都知道，不管被调到哪个项目，自己的个人贡献评分体系是不变的，只是奖金池大小会有变化。这种“个人能力账户”的概念，对多项目并行运营的公司特别重要。

3. 大型游戏集团（500 人以上，多工作室/子公司）

这个规模的公司面临的最大问题是：不同工作室的业务形态差异巨大。有的在做重度 MMO，有的在做休闲小游戏，有的在做海外发行，它们的利润空间、团队规模和考核逻辑完全不一样。一套统一的核算方案几乎不可能同时适配所有工作室。

我的建议是：集团层面只定“框架性原则”，具体核算规则由各工作室在框架内自行设计。集团层面的框架性原则通常包括：

• 奖金总额度与工作室利润的挂钩比例区间（如 10%-20%，各工作室在此区间内自主决定）
• 个人贡献评分的核心维度数上限（如不超过 5 个维度，避免规则过度复杂化）
• 最低透明度标准（如员工必须能看到自己的得分明细和同组排名）
• 核算频率的上限和下限（如最多按月、最少按半年）

在集团层面部署一套 AI 人事系统时，技术架构上需要支持“多租户”模式，不同工作室可以在同一套系统里使用各自独立的规则引擎和数据源，但集团可以统一监控和分析。

4. 发行/运营为主的公司

这类公司没有研发团队，或者研发团队占比很小，核心业务是代理发行和产品运营。他们的项目奖金核算跟研发公司有本质区别。

发行公司的考核指标更偏向商务和市场端：产品引入成功率、签约毛利率、首发渠道铺量完成率、投放 ROI、流水达成率等。AI 人事系统在这里的价值是：把分散在各个渠道后台（巨量、腾讯、快手、TapTap 等）的投放和运营数据自动汇总，然后跟内部的人效数据做关联分析。

一个在发行公司做过的真实案例：他们发现优化师的奖金核算总是扯皮，因为同一款产品在不同渠道的投放效果差异很大，分渠道核算人力成本太高。最后在 AI 系统里设了一个“标准化效率分”，把每个优化师的消耗、ROI、素材点击率等数据综合成一个 0-100 的分数，然后在同项目同渠道条件下做横向排名。这个方法把以前需要核算人员花两周处理的数据量和争论，压缩到了两天。

六、实施过程中的风险点与应对策略

一套方案设计得再好，实施过程中也可能翻车。下面这些风险是我在实际项目中遇到过的，提前知道可以省下大量返工机会。

1. 数据质量风险：垃圾进，垃圾出

AI 系统的输出质量完全取决于输入数据的质量。我在一个项目中发现，Jira 里标记为“已完成”的任务中，约有 15% 实际上只是开发人员自己点的完成，未经 QA 验证。用这个数据去核算奖金，等于奖励了“会点按钮的人”。

应对策略：

• 在上线前做一个“数据质量审计”，抽样检查每个数据源的有效性
• 在系统里设置数据校验规则，比如“已完成”状态必须关联 QA 验证记录才视为有效
• 把数据质量本身纳入考核，比如项目助理的职责之一就是确保系统数据的准确性，如果数据错误率超过一定阈值，影响其自身的绩效评分

2. 员工抵触风险：规则再好，不接受就白搭

我见过最严重的抵触情况是：一个美术组长公开在全员群里说“这个系统就是用来扣钱的”，导致整个美术部对系统产生了负面印象，后续推行极其困难。

应对策略：

• 选择一两个对系统接受度高的项目组做试点，跑出正向案例后在全公司推广
• 从设计上避免“惩罚感”，比如不用“扣分”这种表述，改为“基础分+加分项”的逻辑，让员工觉得系统是在帮他们记录额外贡献，而不是在找茬
• 设置过渡期，期间即使系统显示某个人的分数偏低，也不直接跟钱挂钩，给适应时间

3. 长期维护风险：规则僵化，三年后还在用第一版的逻辑

游戏行业变化快，一套去年好用的考核规则，今年可能已经严重偏离业务现实。但很多公司在系统上线后就把规则忘在一边，三年没动过。

应对策略：

• 设置固定的规则回顾机制，至少每半年一次，由 HR 牵头，各项目组负责人参与
• 在系统里记录规则修改的完整历史，每次修改都标明原因和审批人
• 把“规则适配度”本身作为一个评价维度：每年做一次员工对核算规则满意度的匿名调研，低于 70% 触发强制规则修订

4. 法律合规风险：奖金分配跟劳动法、个税的关系

这部分容易被技术团队忽略，但出问题的后果很严重。项目奖金在劳动法框架下属于“工资”的一部分，涉及加班费计算基数、离职结算、个税申报等问题。

应对策略：

• 确保 AI 系统生成的奖金数据能直接导出为标准薪酬报表格式，与发薪系统和个税申报系统无缝对接
• 离职人员的奖金核算规则必须在员工手册中明确，避免产生劳动仲裁风险。常规原则是：离职时已完成里程碑对应的奖金按比例结算，未完成里程碑的不结算
• 使用系统记录每一次核算的完整审计轨迹，包括数据来源、计算过程、审批记录，以应对可能的劳动仲裁需要

七、方案选型：自建还是采购？如何评估不同的 AI 人事系统？

这是每个公司都会面临的实际决策。我根据服务经验总结了一个评估框架。

1. 自建还是采购的决策矩阵

我的实际建议是：除非你有超过 1000 人的规模且业务逻辑高度特殊，否则不要自建。自建的问题不只是成本高，而是你很难招到同时懂游戏行业和薪酬核算的开发人员，大概率做出来的系统还不如市面上成熟产品的 60%。

2. 评估不同系统的关键指标

如果你决定采购，在评估不同 AI 人事系统时，我建议重点关注以下五个维度：

（1）数据接入能力：系统能否轻松对接你现有的工具链？飞书/钉钉/企微的组织架构、Jira/禅道的项目数据、Git 的代码数据、财务系统的薪资数据，至少这四项要有成熟的对接方案，否则实施周期会翻倍。

（2）规则引擎的灵活度：能否支持多套规则并行？能否按项目阶段自动切换权重？能否支持不同工种使用不同的考核模型？这三个“能否”是判断一个系统是否真正适配游戏行业的核心标准。

（3）透明度与解释性：员工端能否看到自己的得分明细和数据来源？能否查看同组的排名分布？系统有没有审计日志记录每一次核算的完整过程？这不是“锦上添花”的功能，是保障方案长期运转的基础设施。

（4）薪酬发放的闭环能力：系统算出来的奖金数据能否直接推送到发薪流程？是否支持个税计算和申报对接？如果系统算完了还需要人工导入导出，那 AI 系统的效率优势就大打折扣。

（5）行业服务经验：系统服务商是否真的做过游戏公司的项目奖金核算？可以让对方提供脱敏后的实施案例做参考。一个给零售行业做排班系统起家的 HR SaaS 厂商，跟一个服务过游戏公司的厂商，在理解你需求上的差距是巨大的。

以 I人事 为例，它在游戏行业的落地经验使其在规则引擎设计上更适配多项目、多工种、动态权重的场景，而不是简单地套用“固定月薪×绩效系数”的传统逻辑。这一点在评估系统时可以作为参照标尺。

八、总结：从“分钱工具”到“信任基础设施”

回到文章开头那个问题：为什么那么多游戏公司明明不缺钱，项目奖金核算却总是出问题？

我的答案经过这几年反复验证，越来越确定：因为奖金核算的本质不是“算钱”，而是“分配信任”。 员工在乎的不是那几千块的差额，而是“我有没有被公平对待”。传统的核算方式因为数据不透明、规则不公开、过程不可追溯，天然就不可能建立起这种信任。

AI 人事系统的真正价值，不是把核算效率从两周压缩到两天，当然它确实能做到，而是把一套多年积累在管理者脑子里的“隐性规则”，变成所有人都能看见、能理解、能检验的“显性规则”。当规则公开的时候，不公平感才会真正消解。因为即使有人不满意自己的奖金，他也知道问题出在规则上，而不是出在某个人的主观判断上。他可以主张修改下一版的规则，但不需要怀疑这一轮有人动了手脚。

这就是我说的“信任基础设施”。

如果你正在考虑在游戏公司落地 AI 人事系统项目奖金核算方案，我建议你按以下顺序行动：

1. 先用两周时间，把目前各个系统里的数据源盘点清楚。不是看“有没有数据”，而是看“数据能不能用”。能用的标准是：同一个人的标识在各系统里能统一对齐，关键字段的业务含义在各项目组里口径一致。
2. 找一个接受度高的项目组做试点。不要一上来就全公司推广。选一个人际关系相对简单、项目经理本人对数据化管理有兴趣的项目组，先跑一个完整周期。
3. 把试点结果向全员公开。不只是公开成功的地方，也公开遇到的问题和做的调整。透明度从推行阶段就要建立。
4. 规则至少半年回顾一次。游戏行业的节奏决定了考核规则不能“一次定终身”。把规则回顾变成固定机制，而不是等到出了问题才被动调整。

最后说一句我个人的判断：未来三年内，项目奖金核算能力会成为游戏公司人才竞争的一个隐性战场。那些能解决“分钱公平”问题的公司，在招聘和保留核心人才上会有结构性的优势。而能解决这个问题的，不是更有钱的老板，而是更早把核算规则“系统化、透明化”的团队。