Hi，你好，我是Carl，一個(gè)本科進(jìn)大廠做了2年+AI研發(fā)后，裸辭的AI創(chuàng)業(yè)者。

給飛書(shū)群造機(jī)器人這件事，我半年重復(fù)了十幾次。每一次都得讓AI重新翻飛書(shū)官方文檔，然后反復(fù)搏斗好一陣子才能完全搞好。

最后我受不了了，做了這樣一個(gè)開(kāi)源Skill，現(xiàn)在說(shuō)幾句話(huà)就能交付一個(gè)完整的飛書(shū)機(jī)器人項(xiàng)目，并且把我實(shí)踐中踩過(guò)的坑、各個(gè)需求的實(shí)現(xiàn)流程等都集成了進(jìn)去，即使產(chǎn)物與預(yù)期有出入，迭代修改的效率也要遠(yuǎn)高于前。

這篇文章，我會(huì)告訴你它是什么、怎么用，以及背后一個(gè)可以遷移到任何領(lǐng)域的思路。

半年造了十幾個(gè)飛書(shū)機(jī)器人，我受夠了每次從0開(kāi)始

說(shuō)實(shí)話(huà)，給飛書(shū)群搞個(gè)機(jī)器人這事，需求一點(diǎn)都不復(fù)雜。每天早上發(fā)條熱點(diǎn)匯總，或者做個(gè)能對(duì)話(huà)的群助手，或者集成OpenClaw之類(lèi)的，場(chǎng)景很日常。

但問(wèn)題是，每次構(gòu)建總會(huì)有千奇百怪的問(wèn)題，而且隨著創(chuàng)業(yè)的事情越來(lái)越多，我要構(gòu)建的頻率越來(lái)越高。

第一次，我讓Claude幫我寫(xiě)飛書(shū)Webhook機(jī)器人。代碼給得很快，但簽名校驗(yàn)邏輯寫(xiě)錯(cuò)了，時(shí)間戳和簽名拼接順序搞反，調(diào)了好一陣子。

第二次，需要自建應(yīng)用機(jī)器人。Claude又去"理解"飛書(shū)的事件訂閱機(jī)制，結(jié)果把Flask路由和SDK適配器搞混了，搞得我中午沒(méi)睡覺(jué)一直在調(diào)。

每一次都是同樣的循環(huán)：AI先查文檔→編代碼→跑不通→查文檔→理解一半→改→又出新問(wèn)題。十幾次。

不是AI不夠聰明。問(wèn)題在于飛書(shū)開(kāi)放平臺(tái)有自己的規(guī)矩——SDK的builder模式、事件驗(yàn)簽邏輯、卡片JSON嵌套結(jié)構(gòu)、兩種機(jī)器人完全不同的鑒權(quán)方式——散落在幾十頁(yè)文檔里，每次都要從頭學(xué)。

但是，讓AI在最開(kāi)始的時(shí)候直接吞下這些內(nèi)容也不現(xiàn)實(shí)，而且它也并不清楚哪些是重點(diǎn)。

一句話(huà)造一個(gè)完整的飛書(shū)機(jī)器人

后來(lái)我把所有經(jīng)驗(yàn)、所有坑、所有標(biāo)準(zhǔn)做法，打包成了一份Skill。

包括我實(shí)踐里總結(jié)的SOP、各種坑，以及需求挖掘的流程，還有必要的參考資料。

Skill說(shuō)白了就是AI的結(jié)構(gòu)化知識(shí)包。裝上它，AI就知道該怎么一步步構(gòu)建飛書(shū)機(jī)器人，什么該問(wèn)、什么該做、什么地方容易翻車(chē)。

說(shuō)了這么多，演示一下吧。首先，把 Skill 下載到對(duì)應(yīng)位置：

Copilot 放到 ~/.copilot/skills/，Claude Code 放到 ~/.claude/skills/；

Cursor 沒(méi)有同名 Skill 目錄，通常用規(guī)則替代，把規(guī)則放到 .cursor/rules/。

比如，我懶得思考了，就跟AI說(shuō)一句話(huà)：

可有看到，它已經(jīng)讀取到了這個(gè)Skill的內(nèi)容。下一步，它沒(méi)有直接寫(xiě)代碼。先反問(wèn)了2個(gè)關(guān)鍵問(wèn)題：

逐一回答后，它進(jìn)行第二輪需求澄清：

第二輪是更細(xì)粒度的確認(rèn)，用來(lái)確認(rèn)具體是什么樣的業(yè)務(wù)場(chǎng)景。如果有定時(shí)需求等，這里也會(huì)確認(rèn)具體幾點(diǎn)發(fā)送等等的信息，幫助使用者講清楚自己的需求，來(lái)讓AI執(zhí)行的更加精確。

最后，它給了這樣一份完整的需求確認(rèn)。如果有遺漏處，這里是最后一次在構(gòu)建前的補(bǔ)充，比如我們還需要能在群里@它對(duì)話(huà)之類(lèi)的。

等到需求確認(rèn)無(wú)誤，才開(kāi)始按步驟生成代碼。

幾分鐘后，這樣一個(gè)完整項(xiàng)目出來(lái)了：

src/ 核心業(yè)務(wù)代碼，按職責(zé)拆分

config/ 配置管理，統(tǒng)一讀取環(huán)境變量

.env.example 列出所有需填配置

QUICKSTART.md 五步跑起來(lái)

README.md 架構(gòu)說(shuō)明、命令列表、部署指南

配置上所需的App ID和App Secret，以及群聊的Chat ID等信息，啟動(dòng)服務(wù)，機(jī)器人就在飛書(shū)群里活了。

整個(gè)過(guò)程，不過(guò)5分鐘。

補(bǔ)充：Skill是什么？為什么它比工作流更適合這件事

做這個(gè)項(xiàng)目的過(guò)程中我愈發(fā)覺(jué)得：模型能力夠強(qiáng)之后，Skill在中小型任務(wù)上遠(yuǎn)強(qiáng)于工作流。

用個(gè)比喻的話(huà)，工作流是流水線，Skill是崗前培訓(xùn)手冊(cè)。

工作流預(yù)先定義好每一步，并且更加重量級(jí)一些，往往用于企業(yè)級(jí)固定SOP的工作。

數(shù)據(jù)從A到B到C，節(jié)點(diǎn)固定。適合重復(fù)執(zhí)行、流程不變的任務(wù)——定時(shí)拉數(shù)據(jù)→生成報(bào)表→發(fā)郵件，跑得很好。

但飛書(shū)機(jī)器人構(gòu)建不是這樣。每次需求都不一樣：Webhook通知、雙向交互、接AI模型、定時(shí)消息、各種卡片樣式。你沒(méi)法畫(huà)一條流水線覆蓋所有情況。

Skill的邏輯不同。它不是告訴AI"第一步做A，第二步做B"，而是告訴AI：你是飛書(shū)機(jī)器人構(gòu)建專(zhuān)家，這是你的知識(shí)體系和工作規(guī)范，用戶(hù)來(lái)了你自己判斷。

工作流是給新員工一本操作手冊(cè)，寫(xiě)死了每種情況。Skill是做一周崗前培訓(xùn)，讓他理解業(yè)務(wù)邏輯，之后什么情況都能自己判斷。前者僵硬，后者靈活。而現(xiàn)在的大模型，底層能力已經(jīng)夠強(qiáng)了。

AI編程工具的生態(tài)里這個(gè)趨勢(shì)已經(jīng)很明顯。各個(gè)編程IDE都支持了Skills，無(wú)論是rules還是其他特殊定義，本質(zhì)上都是給AI一份結(jié)構(gòu)化上下文知識(shí)，讓它在特定領(lǐng)域更強(qiáng)。

這個(gè)Skill是怎么做的？3個(gè)關(guān)鍵設(shè)計(jì)決策

如果你對(duì)實(shí)現(xiàn)思路感興趣，這三個(gè)設(shè)計(jì)決策可以直接遷移到任何領(lǐng)域。

決策一：需求挖掘前置——不許上來(lái)就寫(xiě)代碼

大多數(shù)人用AI寫(xiě)代碼，是需求一股腦扔過(guò)去。但這個(gè)Skill規(guī)定了四個(gè)階段：需求澄清→確認(rèn)→開(kāi)發(fā)→驗(yàn)證。沒(méi)搞清楚你要什么之前，禁止寫(xiě)一行代碼。

比如用戶(hù)說(shuō)"我要定時(shí)發(fā)消息"，AI不能直接寫(xiě)定時(shí)器。它得追問(wèn)：發(fā)什么內(nèi)容？從哪來(lái)？發(fā)到哪個(gè)群？什么頻率？異常了怎么辦？每輪最多4個(gè)問(wèn)題，問(wèn)完還要復(fù)述完整需求讓你確認(rèn)。

看起來(lái)慢了，實(shí)際省掉了80%的返工。

決策二：給AI標(biāo)準(zhǔn)答案，而非讓它自己編

Skill里我直接寫(xiě)好了兩種機(jī)器人的完整參考實(shí)現(xiàn)。Webhook怎么發(fā)消息、簽名怎么算、自建應(yīng)用怎么初始化客戶(hù)端、事件服務(wù)器怎么搭——全基于官方 lark-oapi。

AI不需要去"理解"文檔了。有現(xiàn)成模板，根據(jù)需求做適配就行。就像你不用教廚師什么是"炒"——給菜譜，他照著調(diào)配料就行。

決策三：完整給出交付標(biāo)準(zhǔn)——不只是代碼，是可運(yùn)行的項(xiàng)目

Skill規(guī)定了項(xiàng)目該長(zhǎng)什么樣：src/ 放業(yè)務(wù)代碼，config/ 放配置，根目錄放入口。每個(gè)項(xiàng)目必須有 .env.example、QUICKSTART.md（50行以?xún)?nèi)）、README.md。

AI最容易出的問(wèn)題不是代碼邏輯寫(xiě)錯(cuò)，而是交付不完整——少配置文件、沒(méi)寫(xiě)環(huán)境變量說(shuō)明、入口找不到。這些小問(wèn)題加起來(lái)能額外花一兩個(gè)小時(shí)。Skill把這些全標(biāo)準(zhǔn)化了，拿到手就能跑。

寫(xiě)在最后：自動(dòng)化是起點(diǎn)，標(biāo)準(zhǔn)化才是終點(diǎn)

做這個(gè)Skill讓我想明白了一件事：AI時(shí)代大家都在聊自動(dòng)化，但自動(dòng)化只是起點(diǎn)，標(biāo)準(zhǔn)化才是真正拉開(kāi)差距的東西。

自動(dòng)化解決"能不能用AI替代人工"。標(biāo)準(zhǔn)化解決"AI每次都能穩(wěn)定交付高質(zhì)量結(jié)果"。

沒(méi)有標(biāo)準(zhǔn)化的自動(dòng)化，就是把一個(gè)不靠譜的流程跑得更快而已。

Skill不是讓AI更聰明，而是讓AI更穩(wěn)定、更可預(yù)期。我之前聊過(guò)，好的上下文工程體系就像船，模型能力就像水，隨著水漲，船也會(huì)高。Skill，就是上下文工程很樸素但很有效的一種形態(tài)。

項(xiàng)目級(jí)Skill機(jī)制正在成為AI編程標(biāo)配，而這個(gè)思路完全可以延伸到任何需要AI反復(fù)執(zhí)行的任務(wù)。

如果你現(xiàn)在還在每次從零跟AI溝通，試試把經(jīng)驗(yàn)打包成一份Skill。一份Markdown，寫(xiě)清規(guī)則、貼上參考實(shí)現(xiàn)、定義交付標(biāo)準(zhǔn)，以及需要的工具和腳本。

也許，會(huì)給你帶來(lái)想不到的效率提升。

既然看到這了，如果覺(jué)得不錯(cuò)，隨手點(diǎn)個(gè)贊、收藏、轉(zhuǎn)發(fā)三連吧～

我是Carl，大廠研發(fā)裸辭的AI創(chuàng)業(yè)者，只講能落地的AI干貨。

關(guān)注我，更多AI趨勢(shì)與實(shí)戰(zhàn)，我們下期再見(jiàn)！