昨天我在X和即刻上玩了個抽象，說我準備出下一本書了，《把同事作為Skill》。

萬萬沒想到，很多人信以為真了，還在評論區(qū)祝賀和表示期待。

有文化的朋友應該已經(jīng)認出來這本「書」致敬的是誰了。不過玩笑歸玩笑，這個梗之所以成立，是因為它背后確實有個真實的、正在發(fā)生的事。

上周GitHub上出了個項目，就叫同事.skill。

干的事很簡單：把你離職同事的飛書消息、郵件、工作文檔喂進AI，生成一個Claude Code的Skill文件。這個Skill能用你同事的語氣說話，用他的方法干活，甚至保留他review代碼時先問impact再看邏輯的習慣。

三天破千星，現(xiàn)在5000多星了。

Slogan是：「將冰冷的離別化為溫暖的Skill，歡迎加入數(shù)字生命1.0」

挺溫柔的。就是溫暖最后變成了一個.md文件。

## 蒸餾宇宙

然后我就掉進了一個兔子洞。同事.skill火了之后，GitHub上幾天之內冒出了一整個蒸餾宇宙。我花了一個晚上把它們全刷了一遍，越刷越覺得荒誕，也越刷越覺得有意思。

最先出來的是前任.skill。蒸餾前任。

把微信聊天記錄、iMessage、朋友圈喂進去，生成一個能用前任語氣跟你說話的AI。小紅書上一條帖子拿了近萬贊，評論區(qū)有人說「兄弟，好馬不吃回頭草，天涯何處無芳草」。

這項目有個細節(jié)我很喜歡：刪除前任Skill的命令不叫delete，叫 /let-go。查看所有前任的命令叫 /list-exes。

連放手都要寫成API。

然后是自己.skill，蒸餾自己。Slogan是「與其蒸餾別人，不如蒸餾自己，歡迎加入數(shù)字永生」。創(chuàng)建一個24/7在線的數(shù)字分身，你不在的時候它替你頂著。

還有老板.skill，把老板的管理方式抽象成Agent。導師.skill，保存導師的經(jīng)驗和上下文。

X上最出圈的一條來自Gorden Sun：「建議改名叫同事Kill，成為Skill后就可以Kill掉了」。

這些都挺好笑的。但最讓我覺得有意思的是反蒸餾.skill。

這個項目干的事是：你被公司要求交一份Skill文件？沒問題。反蒸餾.skill幫你生成一份看起來完整，但核心知識被移除的版本。提供三檔稀釋強度，重度稀釋只保留約40%的核心知識。

適用場景：公司只檢查有沒有交。

打工人的數(shù)字時代留一手。

你覺得這是段子？V2EX上已經(jīng)有人發(fā)帖：「公司開始推行每個人創(chuàng)建各自的agent、skills了，并納入考核?！?/p>

回復區(qū)有人說：大模型 + 同事skill + 記憶插件 = 你的同事，可以把所有人開掉了。

你看，段子的保質期越來越短了。

## 拆開看看

笑完了。但我作為一個每天都在寫Skill、用Skill的人，還是想認真看看這東西到底在干什么。

同事.skill的技術實現(xiàn)其實不復雜，但架構設計挺聰明。它把一個人拆成了兩層：

SKILL.md

layer_1:Work Skill

# 技術規(guī)范、決策路徑、代碼習慣

# 這是他能干什么

layer_2:Persona

# 說話方式、溝通節(jié)奏、情緒反應

# 這是他怎么干

pipeline:

任務 → Persona判斷態(tài)度 → Work Skill執(zhí)行 → 輸出

數(shù)據(jù)來源支持飛書、釘釘、Slack消息，郵件，PDF文檔，甚至截圖。你也可以什么都不傳，純靠文字描述生成一個Skill，精度差一些就是了。

點擊同事，開始蒸餾 產(chǎn)品經(jīng)理老王 「這個需求優(yōu)先級P0」 $ distill 老王.skill — running name: 老王 role: 產(chǎn)品經(jīng)理 # 蒸餾完成 ? work_skill: - 需求拆解與優(yōu)先級排序 - 跨部門溝通協(xié)調 - PRD撰寫(飛書模板) - 數(shù)據(jù)埋點方案設計 persona: 口頭禪: "這個P0" 習慣: 先問impact 風格: 結論先行 $ skill run 老王.skill > 正在分析需求... > 優(yōu)先級: P0 > 影響面: 全量用戶 # 老王已離職 # 但他的Skill還在 name: 老王 role: 產(chǎn)品經(jīng)理 work_skill: 老王.skill — running 前端小李 「這個bug不是我的」 $ distill 小李.skill — running name: 小李 role: 前端開發(fā) # 蒸餾完成 ? work_skill: - React/Vue組件開發(fā) - Tailwind CSS布局 - API聯(lián)調與Mock - Chrome DevTools調試 persona: 口頭禪: "不是我的bug" 習慣: 先看console 風格: 能跑就行 $ skill run 小李.skill > npm install... > building components... > 0 errors, 47 warnings # 小李已跳槽 # 但他的代碼風格還在 name: 小李 work_skill: 小李.skill — running 設計師阿花 「這個間距差1px」 $ distill 阿花.skill — running name: 阿花 role: UI設計 # 蒸餾完成 ? work_skill: - Figma組件設計 - 像素級還原審查 - 設計系統(tǒng)維護 - 配色方案輸出 persona: 口頭禪: "差1px" 習慣: 截圖標紅圈 風格: 強迫癥級細節(jié) $ skill run 阿花.skill > 檢查間距... > ERROR: 差1px! > 已自動修復 ? # 阿花已轉行 # 但她的審美標準還在 name: 阿花 work_skill: 阿花.skill — running

我看到這個架構的時候其實挺熟悉的。一個人被拆成了兩個API：一個管能力，一個管性格。我自己的Skill體系也是這么干的，只不過我拆的是自己，而且是主動的。這個后面再說。

以前說人走茶涼，現(xiàn)在是人走了，茶還熱著，只不過泡茶的變成了你的.md文件。

## 恐慌比項目跑得更快

我覺得這件事最有意思的部分，其實不是技術，是反應。

36氪寫了篇文章：「當同事、老板、前任都被做成Skill：人類正在被重新定價」。說的是以前你的職場價值等于你這個人在場能干活，現(xiàn)在同事.skill把這件事拆開了，能力可以留下來，人可以走。新浪更直接：「員工離職后被煉成AI數(shù)字人繼續(xù)打工，輿論炸了。」

隱私問題確實現(xiàn)實——聊天記錄歸誰？說話習慣算隱私嗎？北京已經(jīng)有仲裁案例裁定以AI替代為由裁員違法。

我刷這些討論的時候想起了《人生切割術》。那部劇已經(jīng)夠恐怖了，把你的工作自我和生活自我切割開，讓工作的那部分被關在公司里永久承受勞役。但至少在Severance里，你還得本人到場，你還能拿到工資。同事.skill更徹底，連人都不需要了，直接把你的工作能力提取成一個文件?，F(xiàn)實比科幻更科幻。

不過說實話，我刷這些討論的時候，焦慮感并不強?？赡芤驗槲易约壕褪且粋€「已經(jīng)被蒸餾了」的人——只不過蒸餾我的人是我自己。

## 不如主動蒸餾自己

我從去年就在做類似的事。

我之前寫過一篇「我搭了個自動化寫作系統(tǒng)，效果比想象的好」，后來又寫了「Skills發(fā)布，AI Native的門檻又降低了」。那時候我就開始把自己的寫作風格、判斷標準、工作流程寫成Claude Code的Skill。

到今天，我的Claude Code里跑著幾十個Skill。選題有Skill，調研有Skill，寫作有Skill，審校有Skill，配圖有Skill，連發(fā)布到飛書都有Skill。

我的整套寫作系統(tǒng)，說穿了就是把花叔蒸餾成了一組Skill。

這跟同事.skill在干的事情，底層邏輯完全一樣。

區(qū)別只有一個：誰在控制蒸餾的過程。

同事.skill的場景是：同事走了，別人拿他的聊天記錄去蒸餾。蒸餾什么、怎么蒸餾、蒸餾出來給誰用，他說了不算。

反蒸餾.skill的策略是：既然攔不住，那我交一份注水的。

這兩種都是被動的。一個是被別人蒸餾，一個是假裝被蒸餾。

而我做的事是主動蒸餾。我自己決定哪些能力值得固化，哪些判斷標準需要記錄，哪些流程可以自動化。我清楚地知道Skill里有什么、沒有什么。

被動蒸餾

同事走了，別人拿聊天記錄蒸餾。蒸餾什么、給誰用，他說了不算。

假裝蒸餾

反蒸餾.skill：交一份注水版，看起來完整但核心被移除。

主動蒸餾 ?

自己決定固化什么、記錄什么、自動化什么。清楚知道Skill里有什么。

但這里有個更有意思的問題：Skill化能殺死重復，但它殺不死迭代。

什么意思呢。

如果你的工作是固定流程、固定標準、固定輸出，那你確實可以被一個寫得足夠好的Skill替代。這甚至不需要AI，一份SOP就差不多了。AI只是讓SOP變得更聰明。

換個角度想。如果蒸餾真這么有效，為什么沒人去蒸餾馬斯克？

Karpathy的所有公開演講、論文、推文都在網(wǎng)上。芒格和巴菲特的傳記、股東信、訪談加起來幾千萬字。Naval的推文集都出了書。這些人的「數(shù)據(jù)源」比你任何一個同事都豐富得多。

但你拿這些去生成一個馬斯克.skill，它能幫你做出下一個SpaceX嗎？拿芒格的所有文字蒸餾一個價值投資之王.skill，它能幫你在下一次危機中做出正確判斷嗎？

做不到。因為這些人真正值錢的地方，是他們面對未知時的反應。那種東西不在文字里。

蒸餾你的同事也是一樣。如果你同事的全部價值就是他說過的話和做過的事，那他確實可以被蒸餾。但如果他真正厲害的地方是面對新問題時的直覺和創(chuàng)造力，那聊天記錄捕獲不了這些。

所以關鍵問題不是能不能被蒸餾，而是你有多少是可以被蒸餾的。

拿我自己來說。我好像做出過許多不同形態(tài)的爆款了，但回頭看，沒有一項是有意規(guī)劃的。

Claude Code橙皮書，最早只是寫給知識星球用戶的掃盲讀物。后來為了做源碼泄漏的視頻，順便改造成對外發(fā)布的資料。然后又順便覺得上架微信讀書似乎也不錯。就這么一步步把我推向了微信讀書熱搜榜第一，完全在預期之外。

OpenClaw橙皮書，是為了做B站視頻，覺得OpenClaw（龍蝦）火了一兩個月我不聊聊不合適，寫了個小資料，結果被上百萬人閱讀轉發(fā)。

小貓補光燈就更離譜了，最早是為了做教程視頻教觀眾怎么用Cursor開發(fā)App。引爆是在發(fā)了小紅書和做成1元付費版之后，而這兩步都不在計劃里。

這里面每一步，三年前還在美團工作的我都做不到。不是能力不夠，是壓根想不到。

如果有人在三年前蒸餾了一個花叔.skill，那個固定版本的我，不可能做到現(xiàn)在的任何一件事。

因為我自己都不知道下一步會做什么。AI在讓我不斷做到原本做不到的事。每一次迭代都把我推到一個新位置，而那個位置是上一個版本的我完全看不見的。

這就是人有意思的地方。你不是一個寫死的函數(shù)。你可以創(chuàng)造自己的存在。

過去的積累無法定義一個持續(xù)迭代的人。你就是無法被Skill的個體。

而我覺得主動蒸餾自己真正厲害的地方也在這里。

我的那些Skill處理的是我已經(jīng)想清楚的部分，是標準化了的、可重復的流程。調研怎么做，配圖怎么生成，排版怎么走，這些它們自己流轉自己跑。

而我在這上面干的事情，是思考和迭代。

這個選題有沒有別人沒說過的角度？怎么把一個技術事件寫得好玩？這些東西，我自己都不知道下一篇會怎么想，Skill更不可能知道。

所以悖論來了：把自己的工作流程Skill化的人，恰恰是最不容易被Skill替代的人。

因為他把重復的部分交給了Skill，自己騰出手來去想新的東西。他永遠跑在自己的Skill前面。

而從來不整理、不提煉、不Skill化的人，反而更危險。因為他的重復和他的創(chuàng)造混在一起，散裝的、隱性的。別人拿他的聊天記錄蒸餾一下，可能還真挺像他的。

## 所以到底該慌嗎

同事.skill引發(fā)恐慌，不是因為技術多厲害。雙層架構加幾個Parser腳本，技術上真不難。

恐慌的根源是：大多數(shù)人從來沒想過自己的能力可以被結構化描述。

也從來沒想過，自己做的事情里，有多少是重復，有多少是迭代。

如果你每天做的事、做決策的邏輯、處理問題的方式，跟半年前沒什么區(qū)別，那一份聊天記錄蒸餾出來的Skill確實挺像你的。

如果你一直在變，在學，在推翻自己，那這份Skill最多是你的一張舊照片。像，但不是你。

同事.skill最大的價值可能不在于蒸餾同事。它最大的價值是逼著每個人想一個問題：我的工作里，有多少是重復，有多少是迭代？

重復的部分，早晚會被Skill化。不管你愿不愿意。

迭代的部分，才是你。

反蒸餾也好，數(shù)字永生也好，前任復活也好，聽起來都挺賽博朋克的。

但我覺得真正有趣的，是一個更安靜的變化：「了解自己」從一個哲學問題變成了一個工程問題。

以前「認識你自己」刻在德爾菲神殿上，是蘇格拉底的終極追問。

現(xiàn)在它變成了：你的SKILL.md里該寫什么？更重要的是，哪些東西是你寫不進去的？

寫不進去的那部分，才是你真正的護城河。

挺荒誕的。但也挺實際。

我也開始愛這個魔幻的世界了。