同事.skill，让我重新想了一遍运维交接这件事

引言
这两天，《同事.skill》挺火，我也去看了它的GitHub仓库。

先说结论：这个项目值得聊，不是因为把同事做成AI有多抓眼球，而是因为它碰到了一个很实际的问题——团队里那些最有用的经验，到底怎么留下来。

https://github.com/titanwings/colleague-skill/blob/main/README_ZH.md

先看项目
《同事.skill》不是那种靠几句描述去模拟一个人的项目。

从仓库介绍看，它更像是在收集一个人真实留下来的工作痕迹，包括聊天记录、文档、邮件、截图、Markdown、PDF，以及飞书、钉钉、Slack、微信聊天记录导出这类材料。它想做的，是基于这些材料，把一个人的工作方式和表达习惯整理成一个可以调用的skill。

数据源真实
项目的数据来源于：飞书、钉钉、Slack、微信聊天记录导出、邮件、Markdown、PDF、截图，还有直接粘贴文本。也就是说，它是在收集一个人真实留下来的工作痕迹，而不是先立个人设，再往下演。

这点挺重要。因为一个人的经验，本来就不会整整齐齐长在一份交接文档里。很多真正有用的东西，平时都散在群消息、批注、邮件回复、复盘说明里，甚至就藏在截图旁边那几句随手备注里。你真让一个老同事临走前靠一份文档把这些东西全写出来，基本不现实。

不只模仿语气
项目不是只模仿语气，而是在仓库里把内容拆成了两部分：一部分偏工作能力，一部分偏表达风格。

偏工作能力的部分，主要是这个人平时怎么做事、用什么标准、遇到问题怎么判断。偏风格的部分，才是他说话习惯、决策方式、互动感觉这些。

这个拆法是有价值的。因为真正难留下来的，往往不是语气，而是做事的方法。很多类似项目，最后容易做成语气很像、内容很空的东西，看着像那么回事，真拿去工作里用，没什么实际价值。《同事.skill》至少不是只盯着像不像，它更在意的是：这个人平时到底是怎么做事的。

支持持续修正
仓库里还提到支持追加材料、纠偏、版本归档和回滚。

这说明它不是把skill当成一次性生成的产物，而是当成一个可以持续补充、持续修正的东西。这比生成一版完事的思路更像真实工作里的经验沉淀。

因为很多经验本来就不是一次整理就能收完整的，而是后面边补边修，慢慢才更像。

先说边界
这个项目有想法，但也别想得太万能。

第一，输入材料的质量，基本决定最后效果。材料越薄，最后越容易只剩一个有点像的壳。

第二，它更像经验提取，不是真人复活。它可以保留一部分工作方式和表达习惯，但很难等于这个人还在。

第三，材料越真实，隐私、合规和安全问题就越绕不过去。聊天记录、邮件、截图、内部文档，不是说拿来就能直接用。

第四，它能整理历史经验，但很难天然拥有现场上下文。一个人之所以判断准，不只是因为他知道过去发生过什么，还因为他知道现在发生了什么。

为什么会想到运维
因为运维团队最难交接的，本来就不是文档，而是判断。

文档当然重要，SOP也重要，值班手册、架构图、复盘也都重要。但做运维的人都知道，很多时候真正让人心里有底的，不是文档有多少，而是遇到问题的时候，你知道先看哪、先别动哪、先怀疑哪一层。这部分东西，恰恰最难写进文档。

很多老运维留下来的经验，平时就散在各种材料里：群里回过的话、事故复盘里的判断、邮件里的拍板、截图上的标注、文档角落里那几句真正关键的备注。这些东西单看都很碎，但合起来，才更像这个人真实的工作方式。

而《同事.skill》有意思的地方就在这里。它不是只认正式文档，它试图把这些零散材料也纳进来，然后从里面提取一个人平时到底是怎么判断、怎么处理问题的。

这一下，就和运维交接接上了。

真正有价值的地方
如果只看传播，《同事.skill》最容易被记住的，是那个很抓眼球的名字。

但放到运维这里，真正值得讨论的，不是它像不像某个人，而是它有没有机会帮团队把那些最容易跟着人一起流失的东西留下来一点。因为运维里最值钱的经验，很多都不是标准答案。

为什么这个告警不要一上来就重启，为什么这个问题先查依赖比先查本服务更快，为什么某个现象看着很严重但其实先别被带偏，为什么某个动作平时能做、故障时却不能碰——这些东西，往往不是看一遍交接文档就能真正接住的。

它更像是一个人值班值久了、故障见多了、坑踩够了以后，慢慢形成的一套判断顺序。

所以《同事.skill》放到运维里，最现实的想象空间，不是做一个数字老同事，而是做一个经验接口。它不替你拍板，不替你承担结果，但它有可能帮你更快把过去那些散落在群消息、复盘、邮件和碎片记录里的经验调出来。

最后
所以我看《同事.skill》，最有感觉的不是它火不火，而是它确实碰到了一个运维里一直存在的问题：人走之后，那些最值钱的经验，能不能别每次都跟着一起断掉。

从数据源、功能设计到边界，你会发现这个项目真正有意思的地方，不只是“同事”这两个字，而是它在认真试一件更难的事：把一个人的工作方式，从碎片化材料里整理出来，变成一个可以沉淀、可以调用、可以继续修正的东西。

这件事放在运维这里，会显得尤其现实。

因为运维最怕的，从来不是少一份文档，而是那个最懂系统的人走了以后，真正顶用的那部分经验也跟着断掉了。

添加好友，邀你入群，运维人的圈子，每日精彩分享，更有小伙伴们的热议！