ARTICLE · 1075012
一线笔记|组织内的AI Battle:让两边都武装起来(下)
本文改编自作者在飞书企业 AI 架构师训练营（首期）的结营报告。
上篇说了一件事：AI 太快，把组织里的吵架删了。吵架没有消失，只是攒着，变成一场迟到的会。
这篇说我怎么把它装回去。
交出去，比跑通难。
半年前，我一个人把一套人力资源排布系统跑通了。
那时候的故事，是把它跑通。
半年过去，我最近在做另一件事：把它交出去。
先说一句。排布只是载体。下面这个故事的两个角色，是「用规则干活的业务单元」和「想横向看的职能部门」。门店和总部，事业部和集团财务，项目组和 PMO，都是这一对。
跑通是我一个人的事。交出去，要回答一个我之前没认真想过的问题：这套东西，除了我，谁来管？管什么？管到哪一步？
01
交接，最自然的想法是找一个接手的人。把东西打包，交给他。他接住，就算交完了。
后来我发现，这个想法漏掉了一半。
排布系统跑一个月，有四件事要有人管。会改：业务单元说夜班后要休一天，谁把它变成规则。验得动：系统排出一版，谁看过、谁点头。审得明：公平权重被谁动过，动的是细节还是原则。说得清：一线员工连上三个夜班，她去问，谁讲得出为什么。
这四件事，半年来，会改、审得明、说得清，基本是我。验，理论上在业务单元，站得稳不稳，看人。
这四件事，塞给任何一个接手的人，他都会变成下一个我。
02
那怎么办？
我最后的做法是：不交给一个人，交给两个。而且给两边的东西，不一样。
吵架是 AI 删掉的。那就用 AI 把它装回去。给两边各配一个会替他们 Battle 的 agent。用魔法打败魔法。
先说业务单元。
我把整个代码包，在内部的云盘上完全公开。任何一个想用这套系统跑排布的业务单元，自己去下载。配一套给他们的 agent 手册。业务单元让自己的 agent 读这份手册，基本就能自助跑下来。
手册里写的不只是按钮在哪。比如某个人这个月班次明显偏少。手册会让 agent 按顺序查：有没有请假。院区权限。夜班配额、资质、允许的班次。最后才核工时目标。排查的顺序和依据都在里面。业务单元不需要懂代码，也不需要来问我。
这个包的设计原则只有一条：业务单元有最高的自主性。
你可以跑出排布结果以后，不告诉人力部门你用的是什么规则。你可以不让他们看到那张能被统计的排布结果。你甚至可以自己另搭一个应用，完全独立。agent 都支持。
再说人力部门。
人力部门也拿到一个包。一样的代码，一样有一套 agent 手册。但他们那份手册的方向不同。
它是帮人力部门去引导各业务单元，尽量用统一的应用，走可以横向比较的统计。哪个业务单元夜班配额高，哪个业务单元工时超了，哪个业务单元的公平规则跟别人不一样。这些，人力部门要看得见。
你看出来了。这两个包，是冲突的。
业务单元的包，帮业务单元守住自己的规则。人力部门的包，帮人力部门看清全局。
03
我为什么要故意设计一对让他们 Battle 的工具？
因为这个冲突本来就在。
业务单元要的是：我的班我自己排，规则我自己定，别人别管。人力部门要的是：全组织一盘棋，口径统一，能比较，能管。
这两个诉求，在系统出现以前就存在。只是以前，规则藏在排布操作岗的脑子里，没人拿出来比。每个业务单元怎么理解公平，怎么理解效率，不是一个公共话题。
规则一旦写进系统，变成算法能认的东西，它就摆到了明面上。每个人都可以站出来问一句：凭什么？
冲突不是我造的。但确实是系统，把它端上了桌。
一个组织，本来就是在很多角色的角力里往前走的。角力形成了某种平衡，组织才能平稳地运转。当一个这么强的智能突然冲进来，而不同的人用它的能力又差那么多，这个平衡会被很快冲乱。重新找到平衡点，是有成本的。甚至有风险。
端上桌以后，如果我只给一边工具，另一边就输了。
只给业务单元，人力部门彻底看不见，全组织变成十几个黑箱。只给人力部门，业务单元变成填表的，规则被统一，例外没地方放。
两种结局我都不想要。
所以我的原则是：谁的孩子谁抱。每个角色，都要能追求自己角色利益的最大化。与此同时，双方在博弈的时候，都得有趁手的工具。
系统的责任不是替他们决定平衡点在哪。是让两边都有筹码，然后让他们自己去谈。
04
按这个设计，四件事的归属就清楚了。
业务单元会接走会改和说得清。规则是他们的，他们改。一线员工来问，他们答。这两件事本来就该在业务发生的地方。
人力部门会接走验得动和审得明。横向看结果，对不对。纵向看规则，有没有人动过原则。这两件事需要跨单元的视角，一个业务单元看不见自己在全组织里的位置。
业务单元自己那一版排布结果，发布前还是业务单元点头。人力部门看的，是这张表放进全组织里，合不合理。
换到别的行业，这个分法长这样：规则怎么定、被问起来怎么解释，归离业务最近的那个人。横向对不对、有没有人偷偷动了原则，归看得见全局的那个部门。谁是那个人、哪个部门，行业不同，答案不同。位置不变。
这个分法，我不敢说是标准答案。它是我在三个项目里，被四件事反复压过之后，能想到的最不坏的分法。
它有一个前提：四件事最好不要放在一个人身上。
我在别的场合说过一句话：谁用 AI 用得好，谁就默默占住了一部分本来不属于他的权力。这半年，那个人是我。
交接，某种意义上，是把这些权力还回去。
我一个人做了半年，做得下来。但我做得下来，不等于组织拥有了这个能力。一个人身上的四件事，是一个人的事。分到两个角色身上的四件事，才开始变成组织的事。
05
交接现在还在路上。两个包都放上云盘了，两份手册都写完了。人力部门那边的交接会，还没开。试点这段时间，人力部门那个位置，还是我自己兼着。
真正的检验还没到。
检验是什么？
是某个月，某个业务单元排出来的排布结果，人力部门看到了，觉得不对。业务单元说，这是我们的规则。人力部门说，这跟别的业务单元不一样。
那一刻，两边有没有工具坐下来谈。谈完以后，规则有没有地方记下来。下次再遇到，是不是不用再谈一遍。
如果这些发生了，交接就算成了。如果没发生，说明我只是把代码搬了个地方。
我现在也不知道会是哪一种。
但至少这一次，我是照着「不站在中间」去设计的。
吵架我没法替他们省掉。我能做的，是让他们吵得起来，而且吵完，有地方记下来。
AI 拿走的，用 AI 还回去。这大概是我今年学到的，最不像 AI 赋能的一件事。