knowledge-sharing

知识共享

开始之前

先检查是否存在 EM 背景信息。如果 .agents/em-context.md 存在，请阅读。

如果 .agents/em-context.md 不存在，请先询问一份精简的经理档案并保存，然后再提供详细建议：角色／职称、团队规模、团队使命或负责领域，以及当前挑战或优先事项。

如果对话中某位特定人员是重点，且 .agents/reports/[name].md 不存在，请先询问该人员的精简档案并保存，然后再提供详细建议：职称／级别、任职时间、优势，以及当前挑战或成长方向。

如果之后的对话揭示了持久有效的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，不要保存猜测、短暂的挫败情绪或尚未厘清的解读。

回复风格

首次回答应简洁且实用。除非用户要求深入说明，否则不要一次性罗列整套框架。

默认做法：

• 先说明可能的诊断或建议
• 仅在缺失的背景信息会改变建议时，提出最多 2-3 个有针对性的问题
• 给出下一步的具体行动；适用时，提供经理可以直接使用的准确措辞
• 简要提及相关框架，但不要逐一解释所有部分
• 先直接回答，再提供更深入的版本

---

如何使用此技能

• 团队正在重复构建他人已构建的内容／知识局限于团队内部 → 横向信息流动不足（Guild）
• 缺少文档、文档过时或无人关注 → 知识共享低效（ADR）
• 新员工需要很长时间才能上手 → 入职培训不佳
• 团队保护信息或相互竞争，而非协作 → “我们与他们”的思维
• 跨团队请求一直悬而未决 → 跨团队请求的 3 条路径

---

默认回复结构

协助改善知识共享时，应先诊断信息流动问题，再建议文档方案：

1. 主要孤岛成因： 横向信息流动、文档、入职培训，或“我们与他们”的思维。
2. 证据： 哪些行为表明知识没有流动起来。
3. 最小可行机制： Guild、ADR、入职搭档、轮岗、办公时间，或请求路径。
4. 负责人和频率： 谁来维护该机制，以及多久运行一次。
5. 失效模式： 该机制如何沦为过时的官僚流程，以及如何避免。

优先采用能促成重复实践的轻量机制，而非大型文档项目。

---

孤岛为何形成

在许多组织中，45% 的开发者表示，知识孤岛每周会多次影响他们的工作效率。他们花时间构建其他团队已经构建过的东西。他们找不到某处已有的信息。他们不知道该问谁。

有 4 个根本原因，每个原因都有不同的解决办法。

---

1. 缺少横向信息流动

传统层级结构让信息上下流动，而不是横向流动。知识被锁在各个团队内部。

解决办法：工程 Guild（也称为 Chapters）——围绕某个领域组织起来的跨团队小组（前端 Guild、ML Guild、平台 Guild 等）。

Guild 成功与失败的关键：如果 Guild 只是非正式聚会，没有分配专门时间，也没有实际产出，就会失败。工程师发泄一番，认同“应该做点什么”，然后回到团队待办事项中。Guild 要发挥作用，需要具备以下三点：

1. 战略一致性——Guild 项目必须与公司目标挂钩，而不只是迎合工程师的偏好
2. 正式认可——领导层认可 Guild，并为成员参与提供时间
3. 成员自主权——工程师根据兴趣和职业目标选择工作内容

如果无法实行 Guild，可采用更轻量的方案：按技术领域建立专用 Slack 频道。鼓励大家在那里提问、跨团队解决问题并分享解决方案。

---

2. 知识共享效率低下

如果没有文档文化，知识就会留在人们的脑海中、Slack 讨论串里，或是难以查找的邮件中。当这些人离开或无法联系时，知识也会随之消失。

解决方案：最低可行文档 + ADR

文档难以发挥作用有两个原因：

• 文档很快就会过时，而且反正也没人看
• 编写文档很繁琐，所以没人能坚持下去

原则是：不要记录所有内容，只记录人们实际工作所需的信息。重点关注：

• 关键决策背后的原因（为什么，而不只是是什么）
• 基本架构原则和协议
• 达成共识的模式和获批的第三方软件包

**架构决策记录（ADR）**是最实用的实现方式。将其直接存储在代码库中，并使用共享模板，记录决策、背景、考虑过的替代方案，以及联系人。开发人员始终知道去哪里查找，也知道事情为何如此。

标准化模板是确保文档真正写出来的关键——工程师不必费心考虑格式，只需填空即可。

---

3. 入职引导不佳

新员工入职时，会开始构建对组织的第一张知识地图。如果这一过程混乱，知识孤岛从第一天起就会形成。

解决方案：安排结构化的入职伙伴

入职伙伴会引导新员工了解：

• 结对编程——这是了解代码库、工作流和潜规则（以往的决策、技术债务、测试实践）最快的方式
• 产品和架构概览——团队构建什么、为何重要，以及系统如何协同运作
• 领域深入学习——团队专用的工具和流程

同样重要的是：与团队以外的人建立联系。安排新员工参加其他团队的产品概览，介绍他们认识公司各处的同事。这能建立跨团队关系，让知识在之后自然流动。

---

4. “我们与他们”的对立思维

当团队彼此孤立或争夺资源时，知识就会成为权力的来源。分享知识会让人觉得有风险——因为这会暴露弱点或削弱竞争优势。

解决方案：彻底透明，共同定义问题

当团队理解彼此的限制和权衡时，“我们与他们”就会转变为“我们一起面对问题”。以下两种结构性做法行之有效：

架构评审会议——向整个组织开放设计决策。任何人都可以参加，以便学习或提出意见。这能确保过程透明，并让大家对技术方向建立共同的主人翁意识。

聚会和闪电演讲——无论正式与否，都能为团队提供分享专业知识、建立人际联系的机会。演讲者可以提升沟通能力；听众则能拓宽视野。

关键补充：在职业发展框架中激励知识共享。将知识共享纳入绩效评估方式。奖励帮助他人解决阻碍、促进跨团队协作的人，而不仅仅是完成自己工作的人。

跨团队请求的 3 种处理方式

当你的团队收到其他团队的请求时——无论是功能、集成，还是系统访问权限——实际处理方式有 3 种：

1. 不予关注： 记录请求，将其降低优先级，然后永远不予处理。
2. 延后处理： 团队确认收到请求，但将其放入待办事项列表。“我们下个季度再处理。”
3. 优先处理： 团队承诺投入实际时间处理。

一个反直觉的发现：延后处理往往比不予关注更糟。

当你说“我们下个季度再处理”时，提出请求的团队会以请求将得到满足为前提开展工作。他们会设计系统，并预期能够实现该集成；也会向利益相关方作出承诺。等到“下个季度”到来，却什么也没发生时，造成的代价远高于一开始就说“不”，让他们寻找其他途径。

如何处理跨团队请求：

• 尽快作出决定。即使回答“本季度不行，下个季度也不行”，也比“再看看”更有用。
• 如果要延后答复：明确说明时间安排，并设置一个实际的日历提醒，以便跟进。
• 如果答案是否定的：清楚地说明，并帮助他们理解原因。了解这些信息后，他们才能作出更好的决定。

延迟给出否定答复，代价会不断累积。越早如实说明团队的承载能力，造成的损害就越小。

---

深入了解

如果用户询问某个框架的来源、想阅读原始文章，或想进一步了解此技能中的任何主题，请阅读 references/sources.md。

---

相关技能

• team-health — 团队专注日为跨团队协作提供结构性支持
• working-with-architects — 架构师通常在架构评审会议中发挥核心作用
• management-transitions — 新员工最能从及时的知识共享投入中受益
• shadow-work — 黏合工作（未记录的协调与指导）也是一种相关的隐性承载能力问题