17 员工为什么愿意贡献业务上下文
图
R10-F12|经验交出去,回应要回得来。上方追踪贡献如何进入使用,下方核查组织如何回应贡献者。记录认可、参与条件和变化规则要结合实际检查;箭头表示应核对的反馈关系,不保证员工一定继续贡献。
一家公司做知识库,请了一个干了十二年的老销售来讲他怎么谈客户。他讲了两个小时,讲得很配合,会议记录整整齐齐。项目组很满意。
但那份记录里,没有一句是他真正在用的东西。哪个客户嘴上说着急其实不急,哪个采购主任必须绕开正面沟通,哪张订单他压了三天等对方先松口——一条都没有。
老板以为 AI 转型烧的是预算。其实先烧的是信任。
预算烧完了,还能再批。信任烧穿了,员工就不肯再交真东西。
这里的真东西,不是员工在培训课上写的几个 prompt,也不是知识库里那些漂亮的流程说明。真正值钱的是这些:员工每天怎么绕过流程卡点。怎么判断一个客户是不是麻烦。怎么知道一个候选人看起来好但不合适。怎么在系统没有记录的地方把事情推进下去。
这些东西,是员工脑子里、手上、聊天里、经验里那套真实工作上下文。我把它叫真实工作 context。
AI 要进入组织,最缺的不是工具说明书,是这些真实业务上下文。没有它,AI 只能学到表层流程。看起来上线了,实际上跑的是纸面组织,不是真实组织。
所以这一章要回答一个很硬的问题:员工为什么愿意把这些东西交给组织?不是因为他爱公司,也不是因为他上完培训以后觉悟提高了。是因为他相信一件事:我贡献给组织 AI,不是为了替代我,是为了放大我。
这句话立不住,后面所有知识沉淀、流程重写、人机协同,都会变成表演。
信任资产不是软话
“信任”这个词很容易被讲软。一讲信任,很多人就滑到价值观、文化、温情沟通。那些东西不是没用,但不够。
在 AI 转型里,信任不是软问题,是生产条件。因为 AI 要吃业务上下文,而业务上下文只在员工嘴里。
员工愿不愿意把真实流程讲出来。愿不愿意暴露流程里的坑。愿不愿意把自己的判断逻辑沉淀下来。愿不愿意参与真实试点。这四件事,决定了组织 AI 能不能学到真东西。
这就是信任资产。
它不是员工满意度调查里的一个分数。它是员工在关键时刻愿不愿意给组织交真货。
一个组织有没有信任资产,看五个信号。
员工还愿不愿意讲真实流程,而不是只交标准流程图。还愿不愿意暴露问题,而不是只说“目前运行正常”。还愿不愿意贡献判断逻辑,而不是只交几个安全模板。还愿不愿意参加真实试点,而不是只在演示会上配合一下。还相不相信,公司不是拿 AI 来偷袭自己。
最后这一条最要命。
如果员工相信 AI 是一次组织偷袭,他就不会再贡献真实业务上下文。
他不会公开反对,他会配合,但交出来的是安全答案。
安全答案对组织最危险。它看起来像知识,实际上不是知识。它看起来像流程,实际上不是流程。它能让项目顺利过会,却不能让 AI 在真实业务里跑起来。
所以你先别问团队信不信公司。拿最近那份知识库访谈记录,看看有没有具体任务、例外处理和判断依据。只有标准流程,就继续追问:是这次任务确实没有例外,是没问到、没记下来,还是员工有所顾虑?记录薄,说明还要查,不能直接拿它证明员工不肯说。
信任怎么被烧掉
信任通常不是被一次大裁员烧掉的。它更常见的烧法,是一连串看起来很正常的管理动作。
第一种,是提取 know-how,却不说清楚用途。公司要做知识库,要把经验存下来,要让老员工把方法写出来。这件事从管理层看,是沉淀组织资产。
但员工那边会问另一组问题:
这些东西放到哪里?谁能看?会不会用来训练系统?会不会反过来证明我没那么重要?如果我的经验被系统学走了,我的位置会发生什么变化?
这些问题没人回答,员工就自己回答,而人通常会按最坏版本回答。
第二种,是 AI 接走了一部分判断,但游戏规则没说清楚。系统开始给建议了,模型开始打分了,agent 开始生成方案了。员工看着这些输出,会马上遇到一个现实问题:我到底是参考它,还是听它的?
如果按 AI 建议做,结果错了,谁负责?
如果我不同意 AI 建议,会不会被认为不拥抱变化?
如果 AI 的判断越来越有说服力,人只是点确认,那人到底还在判断,还是变成橡皮图章?
规则不清楚的时候,员工会选择最安全的打法:按系统说的做,出事再说。这已经不是人机协同,是责任让渡。
第三种,是变化已经发生了,员工才知道。岗位要求变了,权限变了,流程变了,一部分工作被系统接走了。员工是在邮件、系统通知、交接会上才知道。
我见过最伤人的一种版本:一个人周一来上班,发现自己的审批权限没了,问主管,主管说上周系统调整过。
他不是不能接受少一个权限,他不能接受的是全公司都知道了只有他不知道。
变化不是不能发生,问题出在发生的方式上。一个成年人最难接受的,不是组织要变,是组织把他当成一个等待被处置的对象。
这三种动作叠在一起,员工心里会形成一个判断:
组织不是在带我升级。组织是在盘点我还能被替掉多少。
这样的判断一旦形成,信任就可能受损。回看最近的变化,哪些提前说明了,哪些意见被回应了,哪些问题一直悬着。不要用“提前说过”代替“对方听懂且有机会参与”,也别拿几次沟通的数量直接给信任打分。
贡献必须有回报
员工把自己的经验贡献给组织,不应该是一次无偿抽取。很多 AI 知识库项目,设计时只问一个问题:怎么把经验提取出来?
但真正该先问的是:员工凭什么愿意交出来?这是个机制问题,不是道德问题。
如果交出来与不交出来在制度上没有区别,还要多花整理和解释的时间,员工就可能有所保留。但少贡献不只有这一种解释,回报不能代替对能力和工作条件的检查。
我认为,员工贡献真实业务上下文,至少要有三类回报。
第一,贡献要被看见。员工整理出一个判断模板,改出了一套更好的流程,发现了 AI 输出里的风险,修复了一个系统规则,这些东西不能被匿名吞掉。
组织可以不把每一条贡献都做成勋章墙,但至少要有记录:谁贡献了什么,进入了哪个流程,影响了哪个结果。没有记录,就没有资产。
第二,贡献要被认可。发个小奖品就完了不算认可,要进入绩效讨论和人才判断才算。
AI 时代,很多真正有价值的贡献,不一定体现在“我今天多做了多少件事”。它可能体现在别的地方。我让一个流程少返工了。我把一个判断标准写成模板了。我发现了 AI 结果里的系统性偏差。我把自己的经验变成了别人可以复用的工作方法。
这些贡献如果绩效里看不见,员工就会明白:
组织嘴上说沉淀知识,制度上还是奖励旧工作量。
制度长期看不见贡献,就不能只靠动员要求员工持续贡献。
第三,贡献要通向更稳定的组织预期。这里的稳定,不是保证岗位永远不变。
AI 时代,这种承诺说了也没人信。
真正有价值的稳定,是变化有规则。岗位会变,但方向提前说;职责会变,但规则摆在台面上;某些任务会被 AI 接走,但人下一步往哪里走,有路径、有沟通、有再配置。
员工要相信:只要我能跟上变化,我在组织里就还有位置。
我们帮一家制造企业做过一件事,可以用来对一下上面这三条。
这不是前面那个八人专职办公室的案子。那一件讲的是 CEO 那一侧怎么决定人往哪里去,这一件在另一头——员工那一侧为什么肯把东西交出来。
这家公司的总裁办有几个人,每天的活是打开政府部门的网站,把里面的信息一条条抠出来。抠完填进公司的系统和表格,总裁再拿这些信息去读、去做决策。之所以只能靠人,是因为有的数据就发布在文章里,不是那种可以直接接进来的结构化数据接口。公司为这件事是花过钱的,对应的网站都买了会员。这活按前面的说法,是典型的切黄油。
这里没有一个「员工被劝服」的时刻。我们跟他们聊的时候,他们其实想得很清楚:这种事换一个人来做,只要更认真一点也能做完,自己做着并没有什么获得感。这些员工在那家公司里学历算不错的,也都是 00 后,让他们把时间花在这种重复又乏味的动作上,本来就换不来成就感。
于是我们去问他们的,不是「你愿不愿意配合」,是「你们平时看哪些内容、有什么注意事项」。这两个问题问出来的东西,就是他们脑子里那套判断——哪个网站的哪一栏要看、什么样的措辞意味着口径变了、哪些信息看着相关其实没用。这些东西就是往规则库里加规则,给 AI 提供可以学的样本。经验被系统学走之后自己的位置会怎么变,这就是那个没人回答、员工只好自己回答的问题;而在这家公司,这个问题有人答过。
系统大概花了一个月做出来。做完没有立刻放手:又用了大概一个月,人跟 AI 并行跑,AI 有时候踩得不对,人接着往里提建议,直到那些判断确实长进系统里为止。到第三个月,这几个人转了岗,去做信息分析、预测和判断的活,有的去了财务部,有的去了业务分析部。
这段经历里,员工起初就觉得重复采集缺少获得感,后来又有了具体去向。我没有材料证明,究竟是哪一个因素让他们愿意交经验;更不能把转岗写成培训、激励和参与三方面都已经验证成功。
第六章讲的AMO,到这里可以落在“机会”这两个字上。省出的时间是否真从旧任务中释放出来?接着安排了什么工作,所需信息和权限有没有给到,学习与过渡由谁支持?员工提出的建议有没有进入规则,进入以后有没有反馈?这些是我建议下一次项目继续核对的问题,不是这家企业已经交齐的验收记录。
贡献有没有记录、有没有得到认可、变化有没有规则,都值得查。但少一项,不等于员工就在说假话。先看条件,再谈意愿。
CEO 不能把这件事外包给 HR
信任资产不能只交给 HR 做。HR 可以做机制,可以做沟通,可以把绩效和知识贡献接起来,但有些话,HR 没资格替 CEO 说。
AI 转型到底是为了什么?
是为了让组织接住更大的业务,还是为了先找人头成本?
组织会怎么处理被 AI 改写的岗位?
哪些变化会提前沟通,哪些底线不能碰?
这些问题,最终是组织意图问题。组织意图,只能由一号位定调。
CEO 不需要天天讲信任。但 CEO 必须把三件事说清楚。
第一,AI 转型的真实目的。
不要只说“提效”。提效以后干什么?增产,降本,提质量,还是释放人去做更高价值的事?目的不说清楚,员工会默认最坏目的。
第二,岗位变化的规则。
不是承诺永远不变,是说明变化怎么发生。什么情况下会调整,谁参与判断,员工有什么反馈路径,组织会不会给转岗和再配置机会。
第三,业务上下文贡献的边界。
员工贡献的经验会怎么用,谁能用,是否会被记录,是否会影响评价,是否会被用来反向处理员工。
这些问题越模糊,员工越防御。
老板以为自己没说错话。可组织里真正伤信任的,很多时候不是说错,是不说。这三件事你自己先写下来,一件一段,写不满三段就别急着开动员会——你还没想清楚,员工听得出来。
CHO 要把承诺变成制度
CEO 定调以后,CHO 要接住。接不住,承诺就会掉到地上。
CHO 要做的不是一场“拥抱 AI”的培训,也不是把 AI 使用频率塞进能力模型里。这类动作很容易热闹。热闹完了,核心问题还在那儿没人答:人和 AI 结合以后,组织到底拿到了什么新能力?
CHO 在这里真正要做的是三件事。
第一,建立业务上下文贡献记录。
员工贡献了什么经验,留下了什么模板,修复了什么流程,识别了什么风险,这些要能被记录、被复盘、被看见。
第二,把贡献接进绩效和人才判断。
不是简单考“用了多少次 AI”,是看结果:产出是否更稳定,返工是否更少,流程是否可复用,组织知识是否变厚。
第三,让 HRBP 和业务政委成为信任信号的早期预警系统。
信任不是先坏在报表里,它先坏在一线对话里。
员工还愿不愿意讲真问题?还愿不愿意暴露流程卡点?还愿不愿意说“这个 AI 输出不靠谱”?还是只说“挺好的,可以试试”?
这些信号,HRBP 离得最近。
但如果 HRBP 的工作只是传达政策、执行流程,他就接不住这些信号。CHO 必须把“捕捉一线信任信号”写进这个系统,让真实信号能传到决策层。
信任资产检查表
这一章可以直接变成一张会上用的检查表。
不要先问员工“你信不信公司”。这个问题太虚,也太容易得到正确废话。
要反过来问:在这个 AI 项目里,员工有没有把真东西交出来?
这张表按行找缺口,不按勾选数给员工判态度。中间那列没有记录,右边列的是要继续查的问题。
| 检查对象 | 要看的信号 | 没看到时继续查什么 |
|---|---|---|
| 真实流程 | 具体任务、卡点和例外的处理记录 | 任务有没有例外,是否问到、记全 |
| 真实问题 | 补救、返工和人工兜底的具体说明 | 信息是否可及,报告问题有何成本 |
| 判断逻辑 | 判断依据及适用条件 | 员工能否表达,有没有整理和示范的时间 |
| 风险反馈 | 对AI输出提出异议及处理结果 | 反馈入口是否可用,是否获得回应 |
| 贡献记录 | 来源、版本和使用去向 | 记录缺失还是贡献没有发生 |
| 回报机制 | 认可、评价、角色安排的具体记录 | 回报是否可理解、公平,贡献成本由谁承担 |
| 变化规则 | 提前说明的原则、路径和参与机会 | 员工是否知情,能否提问并影响安排 |
勾选结果只是检查入口,不是经过验证的信任量表。要听员工怎么说,也要看工作怎么安排、意见怎么处理;不能先用缺了几项判定他在防御,再拿这张表证明自己的判断。
业务上下文贡献回报表
有些老板会觉得,员工把经验交给组织,是理所当然的。这个想法在 AI 时代会出问题。
以前员工交经验,可能是带徒弟、写 SOP、做复盘。经验还留在人的关系里,留在团队的口传心授里。现在不一样。
经验一旦进入知识库、agent、工作流和模型调用链,它就可能脱离原来的个人,变成组织系统的一部分。这个动作本身没有错,但它改变了经验的归属感。
所以组织要设计回报。
这张表左边是员工交出来的东西,中间是组织必须还回去的东西。左边有、中间空着的那几行,就是你欠着的账。
| 员工贡献了什么 | 组织应该给什么回报 | 对组织的价值 |
|---|---|---|
| 真实流程和卡点 | 记录来源,允许贡献者参与流程重写 | 流程不再只停留在制度文本 |
| 判断逻辑和例外经验 | 在绩效讨论中认可“判断沉淀” | 经验从个人能力变成组织能力 |
| AI 输出风险反馈 | 认可风险发现和系统修复贡献 | 防止组织被漂亮输出带偏 |
| 可复用模板和方法 | 署名、版本记录、跨团队复用反馈 | 让方法扩散,而不是只在一个人手里 |
| 试点中的失败经验 | 保护反馈者,不把问题暴露当成扣分项 | 组织能迭代,而不是只报喜 |
这张表背后的逻辑很简单。
组织不能一边说“请你把经验交出来”,一边在制度上假装这件事没有发生。
贡献的来源、使用和维护要有记录,认可要有依据,岗位变化要有可讨论的规则。这些是组织应该提供的条件,不能保证每个人都作出同一种选择。
今天就能做的检查
这章不用一个宏大的框架收尾,只要一个检查动作。
先挑出公司现在正在推进的一个 AI 项目——知识库、流程梳理、agent 试点、经验沉淀,哪个都行,挑离一线最近的那个。然后当着项目负责人的面,问六个问题。
员工知不知道自己贡献的东西会被怎么用?知不知道谁能访问这些东西?贡献以后,有没有署名、记录或归属?
这些贡献会不会进入绩效讨论或人才判断?如果贡献让岗位要求发生变化,员工会不会提前知道规则?如果员工对 AI 的使用方式有不同意见,有没有一条不会被惩罚的反馈路径?
答不上来的先记下,不按“六题缺三题”给项目定性。涉及用途、访问边界或岗位变化的关键空白,要由负责的人补清;再看员工有没有能力、时间和安全的渠道参与,不能先把记录不足都归成防御。
所以先挑那个离一线最近的项目,把这六个问题当着负责人的面问一遍,答不上来的当场记下来。
前面那家制造企业留下的是一段具体过程:做系统、并行提建议、再转岗。它值得参考,但不能据此给所有项目规定一样的过渡期,也不能说系统质量不重要。下一次要查的,仍是工作是否真的移交,人的新任务和支持是否真的接上。
信任资产从来不是让员工相信公司永远不变,是让他相信三件事。变化会发生,但组织会把规则说清楚。AI 会进入工作,但不是来偷袭我。我贡献给组织的真实业务上下文,会让组织变强,也会让我变强。
员工贡献给组织 AI,不应该是为了替代自己,应该是为了放大自己。
这句话如果组织做不到,就别怪员工不交真东西。