把知识从脑子里搬出去

多年前写过一篇团队内部分享，后来放到了知乎专栏上，当时的标题是《团队内的信息分享效率优化》。想法其实挺简单：团队里的沟通，大多数不是在谈判，也不是在吵架，就是在分享信息。信息搁哪儿，效率就高到哪儿。

这些年远程工作成了日常，AI 助手也进了工作流。回头看，那篇文章的骨架还在，第四种在今天可以再写清楚一点。所以我按原来的思路扩写了一遍，也把海外一些靠得住的说法补了进来。

团队内部的沟通，大多数其实是信息的分享。按效率来分，我还是看成四层。

第一种：直接问人

这是效率最低的一种，至少花了两个人的时间。哪怕传递得百分之百，信息最后还是固化在另一个人的脑子里。别的同事再碰到同样的问题，还得再问一遍，继续浪费时间。

这对团队的风险其实很大。脑子里装着这个信息的人一旦走了，团队就失去了它，一切要从头来。软件圈子里有个不太吉利的说法，叫 bus factor（公交车因子）：一个项目里，最少要有几个人突然消失，这件事才会卡住。[1] 如果这个数字是 1，意思就是关键本事只在一个人脑子里。这人请假、换工作，甚至只是手头忙，别人就得干等着。

美国人力资源管理协会（SHRM）2023 年有篇文章，开头就讲这个常识：员工离开时，带走的不只是人，还有怎么做那份关键报表、怎么伺候那个难缠客户这类本事。[2] 德勤 2021 年的全球人力资本趋势调研更扎心：受访组织里，75% 认为在变化的劳动力中创造并保存知识，对未来 12 到 18 个月的成功很重要，但只有 9% 觉得自己已经准备得很好。[3]

不是说人与人不要直接沟通。面对面聊、一起想问题，这些很重要。只是如果把「分享信息」这件事，长期压在口头上，成本最高，远程工作时更高——电话会议本来就不如当面聊顺畅，问完还是只进了另一颗脑子。

第二种：写成文档

这已经大大迈进了一步。人走了，至少还能留下一部分，能留多少，要看文档写得怎样。可问题也明显：从脑子到文档会有损耗，写本身就花时间，用的人还得找、还得读，投入不少时间才能发挥作用。

更麻烦的是，光写成了文档，躺在硬盘上，那还是个死文档，价值很有限。得让大家方便检索查阅，还能参与讨论、补充修改，文档变成活的，才真正有用。

GitLab 把这套想法做到了公开手册里。他们讲究 handbook-first（手册优先）：先把方案写进大家都找得到的手册，再在 Slack 或邮件里通知。不是为了写而写，是为了先有一个公认的单一事实来源。他们也说得很坦白，手册永远写不完，是不断演化的活东西，可能要好几个月甚至好几年，才觉得稍微像那么回事。[4]

反过来，若只是堆一个没人维护的 wiki，内容过时了，大家就不敢信，不敢信就还得再问一遍人——文档白写了，又退回第一种。GitLab 自己也提醒过：wiki 常常只有少数人能改，一过时，全公司都会默认「先找人确认一下」。[4] 德勤同一项调研里还有个对照：29% 的受访者觉得，从知识库里抽出日常工作需要的知识很困难，甚至几乎不可能；觉得向同事打听同样困难的，是 19%。[3] 也就是说，文档如果不好找、不可信，大家还是会认怂，回头去问人。

亚马逊那套 six-pager（六页备忘录）也被讲得很多。贝佐斯在 2017 年致股东信里写过：他们不用 PowerPoint 这类幻灯片，而是写叙事结构的六页备忘录，开会先静静读一遍，像自习课。[5] 我倒不觉得每个团队都得照搬六页纸。真正值得琢磨的是后面那层意思：好的叙述会逼着你把思路理清，什么重要、什么次要，写的时候就得想明白。文档不只是存档，首先是把思考做扎实。

第三种：工作过程中自然产生并固化

比如把任务放进 Trello、Linear，或者 GitHub Issues、Notion 这类系统里。用得好的话，能看清每个人正在做什么、要做什么、已经完成了什么。过去某一天完成了什么，讨论过程怎么样，有了什么产出，在任务卡里一目了然。关于任务的信息，不用专门问，也不用另做一份文档，搜一下关键词，或者点开标签，相关记录就能找出来。好的任务卡本身就是大家不知不觉中形成的、信息保真度很高的文档。

好的聊天工具，比如 Slack，也有类似能力：搜索、按频道组织主题、给一个问题开独立 thread（讨论串），把重要内容 star、pin 起来。这些功能让它不只是即时通讯，也能固化知识、产生知识。这些都不是微信或 QQ 能比的。

不过也别把聊天工具神话了。37signals（Basecamp 背后的公司）有句很狠的话：Writing solidifies, chat dissolves.——写作让想法凝固，聊天让想法散掉。重要的、关键的、根本性的事，要写成完整的思考，而不是一行一行地顶来顶去。[6] GitLab 更绝，Slack 消息只保留 90 天，故意不让聊天记录变成项目档案，逼着大家把正经事写到 Issue、Merge Request 和手册里。[4] Automattic（WordPress.com 背后那家公司）有句口头禅：P2 or it didn’t happen.——没写到他们内部的 P2 上，就等于没发生。Slack 适合立刻聊聊，但涉及决定和进展的讨论，还得写回那个能留下来、大家都能看到的地方。[7]

所以，远程工作有很多好工具，但这些工具不只是把原先的办公室搬到网上。背后有不一样的思想：让信息在干活的时候自然留下痕迹，而不是干完了再补一份文档。用的时候可以好好琢磨下。聊天工具只有被好好用，才能成为知识库，否则一样水过。

有人把「一边干活，一边把过程公开」叫做 Working Out Loud（公开地工作）。[8] 我觉得和这一层是通的：别等事情结束了再写总结，干活本身就该留下别人找得到的痕迹。

第四种：固化在工具和流程里

不知大家有没有尝试自己在家做炸鸡。做过的人应该知道，想在家做出美味的炸鸡是相当不容易的。但在肯德基，炸鸡就是好吃。那肯德基是不是要雇精通炸鸡的大厨呢？不需要。他们雇的很多是小时工，经过简单培训就可以操作定制的炸鸡工具，炸出好吃的炸鸡。再观察下店里，动线都是经过精心设计的，保证员工能比较高效地提供服务。这就是把「炸出好吃的炸鸡、服务好客户」的知识，固化在了工具和流程里，让每个员工轻而易举成了擅长炸鸡的人。肯德基能成为遍布世界的快餐帝国，这是工具与流程的力量。

类似的故事，美国这边讲得最多的是麦当劳。麦当劳早期运营负责人 Fred Turner，1958 年前后写下第一本《运营与培训手册》。据后来的讣告记载，手册里对食品准备有非常具体的规定，比如薯条要切到 0.28 英寸厚，烤架上一次最多只放六个汉堡。[9] 我引这些细节，不是为了把快餐店神化成管理圣经，只是想说明一件很朴素的事：他们不是指望每个门店都碰巧雇到天才厨师，而是把「怎样稳定地做出同一份东西」写进了系统和动作里。

外科医生 Atul Gawande 在《清单革命》（The Checklist Manifesto）里讲过一类更接近我们工作的问题。书里常被提起的一个区分是：有的错，是因为我们不知道（errors of ignorance）；有的错，是因为我们已经知道，却没能把已经知道的东西用对（errors of ineptitude）。现代复杂工作里，后面这种错更多。[10] 一份短的、设计得好的检查清单（checklist），不是为了把专家变成机器人，而是帮专家在压力下别漏掉关键步骤。再展开一点，就成了 SOP（Standard Operating Procedure，标准作业程序）：把做法写清楚，让后来的人按同一套来。

到这一层，不只是提高信息分享效率。这些工具和流程能成为团队的核心竞争力。把工具和流程教给团队成员，就是简单又高效的赋能过程。

AI 进来之后，这一层又多了一种很自然的做法：把团队已经稳定的做法，写成 AI 助手能直接执行的 skill（技能规程）。这不是另起一层，只是把「固化在工具和流程里」这件事，做到了助手身上。

这里说的 skill，不是广告词，也不是「我们上了大模型」这种空话。按 Anthropic、Cursor、OpenAI 现在的公开定义，一个 skill 通常就是一个文件夹，里面至少有一份 SKILL.md：把这件事该怎么做、什么时候该用这套做法、有哪些约定、示例和检查清单写清楚；需要的话，再配上脚本、参考材料和模板。助手碰到同类任务，就按这套来，而不用每次从头问人，也不用每次把全套背景再讲一遍。[11][12][13]

Anthropic 有个比喻挺准：给助手写 skill，很像给新同事写一份入职指南。[11] 它不是把所有文档一次性塞进对话里，而是需要的时候再加载相应的说明和工具。Cursor 也把 skill 写成可移植、可进版本库的文件包，强调它不只是一段提示词，还可以带上脚本和模板，让助手真的去执行。[12] OpenAI 的说法差不多：用 skill 把公司的文风、多步骤流程这类约定编码进去。[13]

这和把一堆文档丢给大语言模型（LLM，Large Language Model），再靠检索增强生成（RAG，Retrieval-Augmented Generation）去搜，不是一回事。文档检索能帮助手「找到相关材料」，可找到之后，它还得自己猜你们团队到底怎么干活。Skill 是把「我们就是这么干的」写成可复用的规程，必要时还能跑脚本，减少每次临场发挥。知识库仍然有用，但它更像书柜；skill 更像岗位手册，告诉你拿到书柜里的东西之后，按什么步骤做完。

当然，skill 也不是写一次就完了。做法变了，规程也得改，不然助手会一本正经地按过时的规矩干活。这点和活文档是一样的。

还是那几句口诀

第一种人与人直接沟通，成本最高。所以虽然直接沟通很重要，但在信息分享上，我们要减少第一种，尽量多用第三、第四种，适当结合第二种。

工作中如果一个问题被别人问了超过两次，就要考虑把答案写成文档。这不是我一个人的体会。2010 年就有产品经理写过类似的话：尽量不要回答同一道题两遍；第一次先解决眼前的问题，紧接着想办法让这题以后不用再问你——写进 FAQ（Frequently Asked Questions，常见问题解答），下次直接给人一个链接。[14]

如果一个项目里会生成很多以后要查询的信息，就要想想能否通过选择合适的工具，或改造当前的工具，让这些信息随着项目进行，自然而然被记录下来。

如果一件事反复做了三遍，就要考虑是否做成工具，自动化起来。海外也常有类似的经验，说法不太统一，有的说做两遍就记下来，做三遍就自动化。编程里更早就有 Don’t Repeat Yourself（DRY，不要重复自己）这类原则，原来多指代码里的知识只该有一份权威来源；用到流程上也通：别让同一套做法只活在口口相传里。

现在还可以补一句：如果这件事已经有了稳定的做法，就写成 skill，让 AI 助手按团队的方式去干。这仍然是第四种，只是这回用的工具，换成了助手。

其实团队内部管理的优化，很大程度上是优化信息流通的效率。一个好的管理者，就应该不停推动团队往后面这几层迈进。知识搁在哪儿，往往比你开会开得勤不勤，更能决定这个团队能走多远。

参考资料

1. Bus factor，Wikipedia；另见 Adam Hansrod，Breaking free from the bus factor，Equal Experts，2022。
2. Jennifer Thomas，Capture What Employees Know Before They Leave the Company，SHRM，2023。
3. Sandy Becker、Faris Behme，The new organizational knowledge management，Deloitte Insights，2021。文中 75% / 9% 出自 Deloitte Global Human Capital Trends；29% / 19% 出自文中引用的 European Workforce Survey。
4. The importance of a handbook-first approach to communication，GitLab Handbook。
5. Jeff Bezos，2017 Letter to Shareholders，Amazon.com, Inc.，2018 年发布。
6. The 37signals Guide to Internal Communication，Basecamp / 37signals。
7. What to Expect During a Trial，Automattic；另见 Erin Casali，Build effective remote design teams with the right communication model，Automattic Design，2020。
8. John Stepper，The 5 elements of Working Out Loud，2014。
9. Martin Childs，Fred Turner: Executive who transformed McDonald’s into a global empire，The Independent，2013。
10. Atul Gawande，《The Checklist Manifesto》；此处采用 Gawande 官网所载 Malcolm Gladwell 书评中的概括，见 The Checklist Manifesto。相关最早论述亦见于 Gawande，The Checklist，The New Yorker，2007。
11. Anthropic，Equipping agents for the real world with Agent Skills，2025；以及 Agent Skills 官方文档。
12. Cursor，Agent Skills。
13. OpenAI，Skills。
14. Never answer the same question twice，PCM，2010。