Back to Details

knowledge-sharing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Knowledge Sharing

知识共享

Before Starting

开始之前

Check for EM context first. If 
.agents/em-context.md
exists, read it.
If 
.agents/em-context.md
does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.
If a specific person is central to the conversation and 
.agents/reports/[name].md
does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update 
.agents/em-context.md
or 
.agents/reports/[name].md
automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

首先确认是否有工程经理（EM）相关背景信息。如果
.agents/em-context.md
文件存在，请先阅读该文件。
如果
.agents/em-context.md
文件不存在，请先询问并保存一份基础的经理资料，再给出详细建议：职位/头衔、团队规模、团队使命或负责领域，以及当前面临的挑战或优先级。
如果对话核心涉及特定人员，且
.agents/reports/[name].md
文件不存在，请先询问并保存该人员的基础资料，再给出详细建议：职位/级别、任职时长、优势，以及当前面临的挑战或成长方向。

若后续对话中出现可长期留存的新信息，请自动更新
.agents/em-context.md
或
.agents/reports/[name].md
文件。仅保存稳定的事实和模式，不保存猜测内容、暂时的情绪或未明确的解读。

Response Style

回复风格

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.
Default to:
  • State the likely diagnosis or recommendation first
  • Ask at most 2-3 targeted questions only if the missing context changes the advice
  • Give the next concrete action and, when useful, exact wording the manager can use
  • Mention the relevant framework briefly, but do not explain every part of it
  • Offer a deeper version only after the direct answer
首次回复需简洁实用。除非用户要求深入讲解，否则不要直接输出完整框架内容。
默认遵循以下原则：
  • 先说明可能的诊断结果或建议
  • 仅在缺失的背景信息会影响建议时，提出最多2-3个针对性问题
  • 给出具体的下一步行动，必要时提供经理可直接使用的话术
  • 简要提及相关框架，但无需解释框架的每个部分
  • 在给出直接回复后，再提供深入版本的选项

How to Use This Skill

本技能的使用场景

  • Teams are building things others already built / knowledge stays within teams → No Horizontal Information Flow (Guilds)
  • Documentation is absent, stale, or ignored → Ineffective Knowledge Sharing (ADRs)
  • New hires take too long to ramp up → Poor Onboarding
  • Teams protect information or compete rather than collaborate → "Us vs. Them" Thinking
  • Cross-team request is sitting in limbo → The 3 Paths for Cross-Team Requests
  • 团队在开发其他团队已完成的功能 / 知识仅在团队内部留存 → 横向信息流通缺失（适用Guilds框架）
  • 文档缺失、过时或无人查阅 → 知识共享机制失效（适用ADRs方法）
  • 新员工上手耗时过长 → 入职流程不完善
  • 团队刻意保护信息或相互竞争而非协作 → “我们vs他们”的对立思维
  • 跨团队请求处于停滞状态 → 跨团队请求的三种处理路径

Default Response Shape

默认回复结构

When helping with knowledge sharing, diagnose the flow problem before prescribing documentation:
  1. Primary silo cause: horizontal flow, documentation, onboarding, or us-vs-them.
  2. Evidence: what behavior shows the knowledge is not moving.
  3. Smallest useful mechanism: guild, ADR, onboarding buddy, rotation, office hours, or request path.
  4. Owner and cadence: who maintains the mechanism and how often it runs.
  5. Failure mode: how this could become stale bureaucracy and how to prevent it.
Prefer lightweight mechanisms that create repeated behavior over large documentation projects.
在协助解决知识共享问题时，需先诊断信息流通问题，再提出文档相关方案：
  1. 知识壁垒的主要原因：横向流通不畅、文档问题、入职问题或对立思维。
  2. 证据：哪些行为表明知识无法正常流转。
  3. 最小可行机制：Guilds、ADR、入职伙伴、岗位轮换、办公答疑时间或请求处理路径。
  4. 负责人与频次：谁维护该机制，以及机制的运行频次。
  5. 失效风险：该机制可能如何演变为僵化的官僚流程，以及如何预防。
优先选择能形成重复行为的轻量机制，而非大型文档项目。

Why Silos Form

知识壁垒形成的原因

In many organizations, 45% of developers report that knowledge silos negatively impact their productivity multiple times a week. They spend time building something that another team already built. They can't find information that exists somewhere. They don't know who to ask.
There are 4 root causes — and each has a different fix.
在许多组织中，45%的开发人员表示知识壁垒每周都会多次对他们的生产力产生负面影响。他们会花费时间开发其他团队已完成的功能，找不到已存在的信息，也不知道该向谁求助。
知识壁垒存在四大根本原因——每个原因对应不同的解决方案。

1. No Horizontal Information Flow

1. 横向信息流通缺失

Traditional hierarchies move information up and down, not sideways. Knowledge stays locked within teams.
The fix: Engineering Guilds (also called Chapters) — cross-team groups organized around a domain (frontend guild, ML guild, platform guild, etc.).
What makes guilds work vs. fail: guilds fail when they're informal gatherings with no allocated time and no real output. Engineers vent, agree "something should be done," then return to their team backlogs. To work, guilds need three things:
  1. Strategic alignment — guild projects must tie to company goals, not just engineering preferences
  2. Official recognition — leadership acknowledges the guild and gives members time to participate
  3. Member freedom — engineers choose what to work on based on their interests and career goals
A lighter version if guilds aren't feasible: dedicated Slack channels by tech domain. Encourage questions, cross-team problem-solving, and sharing solutions there.
传统层级结构中，信息仅上下传递，而非横向流通。知识被锁定在团队内部。
解决方案：Engineering Guilds（也称为Chapters）——围绕特定技术领域组建的跨团队小组（如前端Guild、机器学习Guild、平台Guild等）。
Guilds成功与失败的关键区别：如果Guilds只是无固定时间、无实际产出的非正式聚会，那么必然会失败。工程师们只会吐槽，达成“应该做点什么”的共识，然后回到各自团队的工作任务中。要让Guilds发挥作用，需要满足三个条件：
  1. 战略对齐——Guilds的项目必须与公司目标挂钩，而非仅基于工程师的个人偏好
  2. 官方认可——领导层认可Guilds的价值，并为成员分配参与时间
  3. 成员自主性——工程师可根据自身兴趣和职业目标选择工作内容
如果Guilds暂不可行，可采用更轻量的方式：按技术领域创建专门的Slack频道。鼓励在频道内提问、跨团队解决问题和分享解决方案。

2. Ineffective Knowledge Sharing

2. 知识共享机制失效

Without a documentation culture, knowledge lives in people's heads, in Slack threads, in undiscoverable emails. When those people leave or are unavailable, the knowledge disappears.
The fix: Minimum Viable Documentation + ADRs
Documentation fails for two reasons:
  • It becomes obsolete quickly and nobody reads it anyway
  • Writing it is tedious, so nobody does it consistently
The principle: don't document everything — document what people actually need to do their jobs. Focus on:
  • The reasoning behind critical decisions (why, not just what)
  • Fundamental architectural principles and protocols
  • Agreed-upon patterns and approved third-party packages
Architecture Decision Records (ADRs) are the best practical implementation. Stored directly in the codebase, with a shared template, they capture: the decision, the context, the alternatives considered, and who to contact. Developers always know where to look and why things are the way they are.
Standardized templates are the key to documentation actually getting written — engineers don't have to think about format, just fill in the blanks.
缺乏文档文化时，知识仅存在于员工的脑海中、Slack对话线程里或难以查找的邮件中。当这些员工离职或不在岗时，知识也随之消失。
解决方案：最小可行文档 + ADRs
文档失效通常有两个原因：
  • 内容很快过时，无人愿意查阅
  • 撰写过程繁琐，没人能持续坚持
核心原则：不要事无巨细地记录一切——只记录员工完成工作真正需要的信息。重点关注：
  • 关键决策背后的理由（为什么，而非只是做了什么）
  • 核心架构原则与协议
  • 已达成共识的模式和经批准的第三方包
**架构决策记录（ADRs）**是最佳的实践方案。直接存储在代码库中，使用统一模板，记录：决策内容、背景信息、备选方案，以及联系人。开发人员总能知道在哪里查找信息，也能理解事物的现状及其原因。
标准化模板是确保文档被持续撰写的关键——工程师无需考虑格式，只需填写内容即可。

3. Poor Onboarding

3. 入职流程不完善

Onboarding is when new hires form their first knowledge map of the organization. When that's chaotic, knowledge silos form from day one.
The fix: Structured onboarding buddies
A buddy guides new joiners through:
  • Pair programming — the fastest way to learn codebase, workflows, and unspoken context (historically taken decisions, tech debt, testing practices)
  • Product and architecture overviews — what the team builds, why it matters, how the system fits together
  • Domain deep dives — tools and processes specific to the team
Equally important: introductions outside the team. Have new hires attend other teams' product overviews. Introduce them to people across the company. This creates the cross-team relationships that make knowledge flow naturally later.
入职阶段是新员工构建对组织的第一份知识图谱的时期。如果入职流程混乱，知识壁垒从第一天就开始形成。
解决方案：结构化入职伙伴制度
入职伙伴需引导新员工完成以下内容：
  • 结对编程——快速了解代码库、工作流程和隐性背景信息（过往决策、技术债务、测试实践）的最快方式
  • 产品与架构概述——团队的业务内容、重要性，以及系统的整体架构
  • 领域深度讲解——团队特有的工具和流程
同样重要的是：介绍团队外部的人员。安排新员工参加其他团队的产品概述会议，将他们介绍给公司内的其他同事。这能建立跨团队关系，为后续知识的自然流通奠定基础。

4. "Us vs. Them" Thinking

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

When teams are isolated or compete for resources, knowledge becomes a source of power. Sharing it feels risky — it exposes weaknesses or reduces competitive advantage.
The fix: Radical transparency and shared problem framing
When teams understand each other's constraints and trade-offs, "us vs. them" shifts to "us together vs. the problem." Two structural approaches that work:
Architecture Review Sessions — open design decisions to the whole organization. Anyone can attend to learn or to influence. This guarantees visibility and creates a shared sense of ownership over technical direction.
Meetups and lightning talks — formal or informal, these give teams opportunities to share expertise and build personal connections. Presenters improve their communication skills; attendees gain broader context.
The critical addition: incentivize knowledge sharing in your career framework. Embed it in how performance is evaluated. Reward people who unblock others and contribute to cross-team collaboration — not just people who ship their own work.
当团队孤立存在或为资源竞争时，知识成为权力的来源。分享知识会带来风险——暴露自身弱点或降低竞争优势。
解决方案：彻底透明化与共同问题框架
当团队理解彼此的约束条件和权衡取舍时，“我们vs他们”的思维会转变为“我们共同面对问题”。以下两种结构化方法有效：
架构评审会议——将设计决策开放给整个组织。任何人都可以参加学习或提出意见。这确保了透明度，并建立了对技术方向的共同责任感。
聚会与闪电演讲——无论是正式还是非正式形式，都能为团队提供分享专业知识和建立个人联系的机会。演讲者能提升沟通技巧；听众能获得更广泛的背景信息。
关键补充：在职业发展框架中激励知识共享。将其纳入绩效评估标准。奖励那些帮助他人解决问题、参与跨团队协作的员工——而不仅仅是完成自身工作的员工。

The 3 Paths for Cross-Team Requests

跨团队请求的三种处理路径

When your team gets a request from another team — a feature, an integration, access to a system — there are three ways it gets handled in practice:
  1. No attention: The request is noted, deprioritized, and never addressed.
  2. Delayed attention: The team acknowledges it but puts it in the backlog. "We'll get to it next quarter."
  3. Prioritize: The team commits real time to it.
The counterintuitive finding: delayed attention is often worse than no attention.
When you say "we'll get to it next quarter," the requesting team builds around the assumption that the request will be fulfilled. They design their system expecting that integration. They commit to their stakeholders. When "next quarter" arrives and nothing happens, the cost is much higher than if you had said "no" at the start and let them find another path.
What to do with cross-team requests:
  • Decide quickly. Even "not this quarter, not next quarter" is more useful than "we'll see."
  • If the answer is delayed: be specific about timeline and set a real calendar reminder to follow up.
  • If the answer is no: say so clearly, and help them understand why. They can make better decisions with that information.
The cost of a delayed "no" compounds. The sooner you're honest about capacity, the less damage accumulates.
当你的团队收到其他团队的请求（如功能开发、集成、系统访问权限等）时，实际处理方式通常有三种：
  1. 无响应：请求被记录后被低优先级处理，从未得到解决。
  2. 延迟响应：团队确认请求，但将其放入待办事项列表。“我们下个季度再处理。”
  3. 优先处理：团队投入实际时间处理请求。
反直觉的发现：延迟响应往往比无响应更糟糕。
当你说“我们下个季度再处理”时，提出请求的团队会基于“请求将被满足”的假设开展工作。他们会设计系统以适配该集成，并向利益相关者做出承诺。当“下个季度”到来而请求未被处理时，造成的损失远大于一开始就说“不行”并让他们寻找其他方案的情况。
跨团队请求的处理建议：
  • 快速决策。即使是“今明两个季度都无法处理”也比“我们看看再说”更有用。
  • 如果决定延迟处理：明确具体时间，并设置真实的日历提醒跟进。
  • 如果决定拒绝：清晰说明，并帮助对方理解原因。这些信息能帮助他们做出更好的决策。
延迟的“拒绝”造成的损失会不断累积。越早坦诚告知团队的能力情况，造成的损害就越小。

Dive Deeper

深入了解

If the user asks where a framework came from, wants to read the original article, or wants more context on any topic in this skill — read 
references/sources.md
.
如果用户询问框架的来源、想要阅读原文或了解本技能中任何主题的更多背景信息，请查阅
references/sources.md
。

Related Skills

相关技能

  • team-health
    — Team Focus Days are a structural support for cross-team connection
  • working-with-architects
    — Architects are often central to Architecture Review Sessions
  • management-transitions
    — New hires benefit most from immediate knowledge-sharing investment
  • shadow-work
    — Glue work (undocumented coordination and mentoring) is a related hidden capacity problem
  • team-health
    —— 团队聚焦日是支持跨团队联系的结构化机制
  • working-with-architects
    —— 架构师通常是架构评审会议的核心角色
  • management-transitions
    —— 新员工能从即时的知识共享投入中获得最大收益
  • shadow-work
    —— 粘合工作（未记录的协调与指导）是相关的隐性能力问题