杀死知识分享的，正是KPI本身
约 9 分钟驭光者首发于微信公众号「羲和Lab」
企业级AI协同实践 · 第02篇 / 共07篇 激励错位之下，不分享才是理性选择
写在前面
上一期我们聊过一个尴尬的事实：你花几十万建的知识库，可能已是"数字废墟"——系统在跑，内容死了。成因有三堵墙：IT建库不管人愿不愿意填、冷启动死亡螺旋、HR全程缺席。
今天来拆第二堵墙背后更根本的问题：为什么没人愿意分享？
如果你是技术负责人，第三部分的GitLab案例你应该很熟悉——Handbook-first文化、MR流程里的知识沉淀。但值得你想的是：这些做法在你的团队里能不能跑通？障碍可能不在工具，在激励。
如果你是HR或管理者，第二部分直接回应一个你可能天天见却说不清的问题——为什么越资深的员工越不愿意做知识传承。这不是"格局小"，这是一个可以用理论解释的理性选择。
一、KPI的沉默：当分享在绩效表上"不存在"
上一篇结尾问过：为什么没人愿意往里填东西？IT常被归咎——"系统不好用""搜索太慢""权限太复杂"。这些都对，但都不是根因。
设想一个常见的绩效考核：季度OKR绑定了项目交付节点、客户满意度、代码质量，唯独没有"知识沉淀"。工程师花两小时写了一份复盘文档，Scrum Master的汇报里可能会提一句"团队分享氛围不错"——但到了HR的绩效评估表上，它不产生任何分数。
相比之下，他如果把这两小时用来赶一个需求，进度条会往前挪一格。你猜他下次怎么做？
这不是员工的觉悟问题。当一个行为在正式激励体系中没有回报、甚至挤占了有回报行为的时间时，选择不做这个行为，是理性的。杀死知识分享的，不是员工的冷漠，是激励体系的沉默。
这里有一个制度性的落差。软考高项——国内IT行业最主流的项目管理认证——在知识管理域中，把"知识分享与转移"列为衡量项目管理成功的核心过程。连考试大纲都承认这是必要环节，可到了实操层面，大多数企业的绩效考核表上根本找不到"知识贡献"这一行。
理论说它是核心，考核说它不存在——这道裂缝，就是分享困境的起点。
但如果仅仅是"激励不够"，那加一条考核指标不就解决了？事情没那么简单。
二、知识的权力属性：你要求他交出知识，给了什么对价？
即使公司明确把"知识贡献"写进考核，甚至给予物质奖励，分享率常常还是上不去。为什么？
因为知识在组织里，不只是一个可以传递的资源。它同时承载着身份和权力。
Lave和Wenger在1991年的《情境学习》（Situated Learning: Legitimate Peripheral Participation）中提出"实践社群"概念——一个人在社群中的地位，很大程度上取决于他"知道别人不知道的东西"。这不是职场厚黑学，而是知识本来就附着在人的社会关系上，从不是中性信息。
设想一个团队。最资深的那个人，是所有疑难问题的第一求助对象——线上故障找他、客户投诉找他、方案评审找他。这种"被需要"构成了他的独特价值。现在公司推行知识分享计划，要求他把经验写成文档。写完之后，任何人都能搜到答案，不需要再找他——他的不可替代性被稀释了。
当你要求一个人交出知识，你同时也在要求他交出部分权力。这个交易，你给了什么作为对价？
但还没完。
设想一个更具体的情境。这个资深员工见过这样的人：从不自己花时间沉淀知识，却勤快地浏览别人的分享成果，改头换面包装成自己的KPI展示。当这种人再站在道德高地上，指责贡献者"没有格局""不愿意分享"，这伤害的已不只是分享意愿，是团队内的基本信任。
分享的受益者和分享的贡献者，根本不在同一群人里。
这不是分享机制的问题。这是分享的代价由贡献者承担，收益却流向了搭便车的人。而现有的激励工具——不管是加钱还是加分——面对这种结构性的错位，基本无能为力。
三、GitLab的另一种可能：当"写文档"就是工作本身
讲到这里，该给出另一种可能性了。
GitLab是全球最大的全远程公司之一（截至2024年超过2000名员工），核心工作方式是"Handbook-first"：几乎所有决策、流程、知识都写在公开的Handbook里，而不是藏在邮件、私聊或会议中。以下事实都能在 handbook.gitlab.com 公开查阅：
- "如果一件事没有写在Handbook里，它就不存在。" 这是GitLab价值观"transparency"（透明）具象化出的硬规则：会议必须记录，决策必须文档化，连CEO的1-on-1议程模板都是公开的。
- Merge Request既是代码审查，也是知识传递。 每个MR的讨论线程——为什么这样设计、试过哪些失败方案、最终怎么取舍——都是公开的、可搜索的、永久留存的。新人入职不用拉着老员工"传授经验"，搜MR历史就能看到这个团队过去几年的全部决策过程。
- "写文档"不是"做完工作之后顺便做的事"，而是完成工作的必要环节。 不写，工作就不算完成。
这些做法为什么在很多公司搬不动？不是因为缺少文档系统，而是因为GitLab把"写文档"嵌进了工作的完成标准——写完代码只是工作的一半，写好文档才算做完。而大多数公司，写文档是"加分项"，不写也能交差。同样的工具，两种不同的工作定义，人的行为自然不同。
知识迁移：对非数字原生企业，可借鉴的3条底层原则
- "写下来"不是分享的终点，是工作的起点。 如果一件事没有被记录，它在组织意义上就不算发生过。试试把"有没有留下记录"纳入项目验收标准——不是单独设立一个"知识分享"考核项，而是把文档作为交付物的一部分。
- 透明度是默认值，保密是例外。 大多数公司的知识默认藏在部门墙后面。可以从小处试起：把团队周会纪要从"仅组内可见"改为"全员可见"，观察一个月。你会发现阻力往往不在"信息安全"，在"不想让别人看到我们内部有分歧"。
- 讨论过程比结论更有价值。 GitLab的MR讨论线程之所以是知识宝库，不是因为它记录了"最终决定是什么"，而是因为它记录了"为什么做这个决定"——包括了被否决的方案、当时的争论、权衡的过程。把决策过程中的犹豫和取舍记录下来，比只留一份最终报告有用得多。
四、激励的陷阱：不是"加钱"，是重新定义"工作"
GitLab的做法提示了一个反直觉的结论：真正持久的分享，往往不靠"分享奖金"。
很多公司想到的方案是"加激励"——写一篇文档奖励200块，知识贡献纳入年终考核加分。这些方案短期内可能有点效果，但通常会迅速退潮。
为什么？因为物质激励改变的是行为的经济计算，而不是行为的性质。当分享变成一种"被购买的行为"时，员工会问一个很自然的问题："不给钱我还要不要写？"一旦奖励取消，行为就停止了——它从未内化为工作的一部分。
但还有一种更隐蔽的变形。当"知识贡献"被量化为考核指标——比如每人每月提交三篇经验文档——有些人会直接打开AI，输入一句"帮我写一篇关于项目管理的经验总结"，生成一篇看起来像模像样的文档，复制粘贴进知识库。分享量达标了，领导看报表满意了，但知识库里塞满的是AI生成的、从未发生过的"经验"。真正的知识没有被沉淀，反而被这些虚构内容稀释了——将来有人按这些文档去操作，出的问题比没有文档更严重。
分享的受益者和知识的贡献者，还是不在同一群人里。只不过这一次，贡献者连真东西都没交出来。
一个更深层的问题：当分享被单独定价，它反而被排除在工作之外了。一件有价值的事，一旦明码标价"额外奖励"，就等于宣告"这件事原本不属于你的工作"。
GitLab不是靠奖金让人写文档的。它把文档写作变成了完成工作的必要环节。这背后的转变是根本性的：不是"做好工作之后顺便分享"，而是"分享本身就是工作的一部分"。
当一个团队的项目交付标准里写着"交付物必须包含：代码、测试、文档"时，写文档就不再是"额外工作"——它就是这个工作的定义。
五、AI的边界：能降低成本，但不解决意愿
上一篇讲过，AI在知识管理中最直接的价值是降低"外化"的摩擦成本——员工对着AI把经验讲一遍，AI帮忙整理成结构化文档。写一篇经验总结，从过去的两小时，可能缩短到二十分钟。
但注意：这解决的是分享的成本问题，丝毫没碰分享的意愿问题。如果这二十分钟在绩效表上依然是"查无此项"，员工依然没有动力去做。成本再低，也是成本。而一个在正式评价体系里没有回报的成本，理性的人会选择规避。
AI是加速器，不是发动机。 它能让一个已经想分享的人更快地把知识外化，但它不能让一个不想分享的人突然想分享。动机的问题，还是得回到激励和文化上。
六、五个值得想清楚的变量
如果你读到这里，可能会问："那到底该怎么设计激励？"
我们不给答案。激励设计高度依赖组织语境——一家10人的创业公司和一家10000人的制造企业，面临的约束完全不同。照搬别人的方案，大概率是亲手再制造一片新的废墟。
下面是五个变量。它们不是方案，是你做任何决策之前，值得花时间想清楚的问题。
变量一：你公司的KPI，奖励什么，惩罚什么？
拿出你公司的绩效考核表，数一数——有多少指标直接或间接与"知识沉淀"相关？
如果答案是"零"，那知识库荒废，不是员工的问题。是你的考核体系在传递一个明确的信号：这件事不重要。人们不听你说什么，人们看你怎么打分。
这个问题的反向也值得想：如果突然加了"知识贡献"考核，会不会催生一堆为了凑数量而写的低质量文档？一件有价值的事，被KPI量化之后，往往就变成了另一件完全不同的事。
变量二：在你们组织里，"知道别人不知道的事"是优势还是负担？
如果是优势——那么分享就等于让渡优势。你打算用什么来补偿这种让渡？靠"团队精神"不够，靠"额外奖励"不够持久。这是激励设计里最难回答的问题，但绕不过去。
如果是负担——比如老员工被反复求助到无法正常工作——那分享反而是对他有利的。这种情况下，你的激励设计逻辑和前一种完全不同。同一个"不愿意分享"的行为，背后的动机可能截然相反，对应的解法自然也不同。
变量三：你们的工作流程，是否默认产生文档？
一个关键测试：一个项目从立项到交付，过程中产生的知识——方案取舍、踩过的坑、客户反馈——是自然地沉淀在某个地方，还是完全依赖个人记忆？
如果是后者，说明"知识沉淀"没有被嵌入工作流程。它是一个需要额外意志力的动作。而任何需要额外意志力的事情，大规模推广都会失败。不是员工不努力，是流程没有替他们记住。
变量四：当AI进入知识管理，员工怎么看待它？
当你引入AI辅助知识管理时，员工会把它看作"帮我省事的工具"，还是"监控我写了多少的探头"？
如果是后者——那AI非但不会促进分享，反而会彻底堵死分享的通道。员工会用沉默来保护自己。这个话题，我们会在04篇（知识治理）和06篇（信任文化）里深入讨论。
变量五：你的组织，能接受多大程度的"透明"？
GitLab能做到Handbook-first，前提是组织文化对透明度有高度共识。在很多企业里，"信息公开"本身就触碰了部门利益和权力边界。
你可以问自己一个更尖锐的问题：如果明天要求所有会议纪要全员可见，阻力最大的会是谁？这个阻力背后想保护的东西，到底是"商业机密"，还是"部门权力"？前者的答案是安全策略问题，后者的答案是权力结构问题——两者需要完全不同的解法。
七、自检清单
如果下面三个问题中任何一个让你停了一下，那这篇讨论跟你的组织有关。
- 你公司的绩效考核里，"知识贡献"是一个有实际权重的指标，还是一个装饰性的占位符？ 如果年终奖计算公式里完全没有这一项，那它在员工心里就是"不存在"的——无论海报上印了多大的"鼓励分享"。
- 团队里最资深的那几个人，他们的经验文档化程度如何？ 如果答案是他们脑子里最值钱的东西从来没被写过下来，那你面对的不仅是知识流失风险，更是激励设计的根本性缺失。
- 过去一年，有人因为"不愿意分享知识"被影响过考核吗？ 如果从来没有——那"鼓励分享"这三个字，到目前为止，只是一句口号，不是一个制度。
下期预告
知识分享的意愿问题拆完了。
假设你已经解决了"人愿意写"这个问题——那接下来就面临一个更技术的挑战：写下来的东西，AI能不能读懂？
企业知识的形式五花八门——Word、PDF、聊天记录、邮件、Wiki——散落在不同系统里，没有统一结构。如何让AI从这些碎片中提取出有用的知识？
这不只是技术问题——谁来定义知识结构、谁来负责清洗和维护，同样值得提前想清楚。下一期，我们聊"知识资产化"。
关于本文的案例 本文描述的绩效考核场景和团队互动现象，是基于行业共性观察的类型化提炼，不特指任何单一企业的未公开内部数据。GitLab案例所引事实均可通过 handbook.gitlab.com 公开查阅。文中引用的理论（Lave & Wenger 1991）可溯源至公开出版物。
本文由AI辅助创作，经人工审核编辑后发布。所述管理观察仅供参考，具体决策请结合企业实际情况。
企业级AI协同实践 · 02/07 · 羲和Lab
本文首发于微信公众号「羲和Lab」，公众号内可留言交流
阅读公众号原文