Hi，你好，我是Carl，一个本科进大厂做了2年+AI研发后，裸辞的AI创业者。
给飞书群造机器人这件事，我半年重复了十几次。每一次都得让AI重新翻飞书官方文档，然后反复搏斗好一阵子才能完全搞好。
最后我受不了了，做了这样一个开源Skill，现在说几句话就能交付一个完整的飞书机器人项目，并且把我实践中踩过的坑、各个需求的实现流程等都集成了进去，即使产物与预期有出入，迭代修改的效率也要远高于前。
这篇文章，我会告诉你它是什么、怎么用，以及背后一个可以迁移到任何领域的思路。
说实话，给飞书群搞个机器人这事，需求一点都不复杂。每天早上发条热点汇总，或者做个能对话的群助手，或者集成OpenClaw之类的，场景很日常。
但问题是，每次构建总会有千奇百怪的问题，而且随着创业的事情越来越多，我要构建的频率越来越高。
第一次，我让Claude帮我写飞书Webhook机器人。代码给得很快，但签名校验逻辑写错了，时间戳和签名拼接顺序搞反，调了好一阵子。
第二次，需要自建应用机器人。Claude又去"理解"飞书的事件订阅机制，结果把Flask路由和SDK适配器搞混了，搞得我中午没睡觉一直在调。
每一次都是同样的循环：AI先查文档→编代码→跑不通→查文档→理解一半→改→又出新问题。十几次。
不是AI不够聪明。问题在于飞书开放平台有自己的规矩——SDK的builder模式、事件验签逻辑、卡片JSON嵌套结构、两种机器人完全不同的鉴权方式——散落在几十页文档里，每次都要从头学。
但是，让AI在最开始的时候直接吞下这些内容也不现实，而且它也并不清楚哪些是重点。
后来我把所有经验、所有坑、所有标准做法，打包成了一份Skill。
包括我实践里总结的SOP、各种坑，以及需求挖掘的流程，还有必要的参考资料。
Skill说白了就是AI的结构化知识包。装上它，AI就知道该怎么一步步构建飞书机器人，什么该问、什么该做、什么地方容易翻车。
说了这么多，演示一下吧。首先，把 Skill 下载到对应位置：
Copilot 放到 ~/.copilot/skills/，Claude Code 放到 ~/.claude/skills/；
Cursor 没有同名 Skill 目录，通常用规则替代，把规则放到 .cursor/rules/。
比如，我懒得思考了，就跟AI说一句话：
| 「帮我做一个飞书机器人」 |
|---|
可有看到，它已经读取到了这个Skill的内容。下一步，它没有直接写代码。先反问了2个关键问题：
逐一回答后，它进行第二轮需求澄清：
第二轮是更细粒度的确认，用来确认具体是什么样的业务场景。如果有定时需求等，这里也会确认具体几点发送等等的信息，帮助使用者讲清楚自己的需求，来让AI执行的更加精确。
最后，它给了这样一份完整的需求确认。如果有遗漏处，这里是最后一次在构建前的补充，比如我们还需要能在群里@它对话之类的。
等到需求确认无误，才开始按步骤生成代码。
几分钟后，这样一个完整项目出来了：
src/ 核心业务代码，按职责拆分
config/ 配置管理，统一读取环境变量
.env.example 列出所有需填配置
QUICKSTART.md 五步跑起来
README.md 架构说明、命令列表、部署指南
配置上所需的App ID和App Secret，以及群聊的Chat ID等信息，启动服务，机器人就在飞书群里活了。
整个过程，不过5分钟。
做这个项目的过程中我愈发觉得：模型能力够强之后，Skill在中小型任务上远强于工作流。
用个比喻的话，工作流是流水线，Skill是岗前培训手册。
工作流预先定义好每一步，并且更加重量级一些，往往用于企业级固定SOP的工作。
数据从A到B到C，节点固定。适合重复执行、流程不变的任务——定时拉数据→生成报表→发邮件，跑得很好。
但飞书机器人构建不是这样。每次需求都不一样：Webhook通知、双向交互、接AI模型、定时消息、各种卡片样式。你没法画一条流水线覆盖所有情况。
Skill的逻辑不同。它不是告诉AI"第一步做A，第二步做B"，而是告诉AI：你是飞书机器人构建专家，这是你的知识体系和工作规范，用户来了你自己判断。
工作流是给新员工一本操作手册，写死了每种情况。Skill是做一周岗前培训，让他理解业务逻辑，之后什么情况都能自己判断。前者僵硬，后者灵活。而现在的大模型，底层能力已经够强了。
AI编程工具的生态里这个趋势已经很明显。各个编程IDE都支持了Skills，无论是rules还是其他特殊定义，本质上都是给AI一份结构化上下文知识，让它在特定领域更强。
如果你对实现思路感兴趣，这三个设计决策可以直接迁移到任何领域。
大多数人用AI写代码，是需求一股脑扔过去。但这个Skill规定了四个阶段：需求澄清→确认→开发→验证。没搞清楚你要什么之前，禁止写一行代码。
比如用户说"我要定时发消息"，AI不能直接写定时器。它得追问：发什么内容？从哪来？发到哪个群？什么频率？异常了怎么办？每轮最多4个问题，问完还要复述完整需求让你确认。
看起来慢了，实际省掉了80%的返工。
Skill里我直接写好了两种机器人的完整参考实现。Webhook怎么发消息、签名怎么算、自建应用怎么初始化客户端、事件服务器怎么搭——全基于官方 lark-oapi。
AI不需要去"理解"文档了。有现成模板，根据需求做适配就行。就像你不用教厨师什么是"炒"——给菜谱，他照着调配料就行。
Skill规定了项目该长什么样：src/ 放业务代码，config/ 放配置，根目录放入口。每个项目必须有 .env.example、QUICKSTART.md（50行以内）、README.md。
AI最容易出的问题不是代码逻辑写错，而是交付不完整——少配置文件、没写环境变量说明、入口找不到。这些小问题加起来能额外花一两个小时。Skill把这些全标准化了，拿到手就能跑。
做这个Skill让我想明白了一件事：AI时代大家都在聊自动化，但自动化只是起点，标准化才是真正拉开差距的东西。
自动化解决"能不能用AI替代人工"。标准化解决"AI每次都能稳定交付高质量结果"。
没有标准化的自动化，就是把一个不靠谱的流程跑得更快而已。
Skill不是让AI更聪明，而是让AI更稳定、更可预期。我之前聊过，好的上下文工程体系就像船，模型能力就像水，随着水涨，船也会高。Skill，就是上下文工程很朴素但很有效的一种形态。
项目级Skill机制正在成为AI编程标配，而这个思路完全可以延伸到任何需要AI反复执行的任务。
如果你现在还在每次从零跟AI沟通，试试把经验打包成一份Skill。一份Markdown，写清规则、贴上参考实现、定义交付标准，以及需要的工具和脚本。
也许，会给你带来想不到的效率提升。
既然看到这了，如果觉得不错，随手点个赞、收藏、转发三连吧～
我是Carl，大厂研发裸辞的AI创业者，只讲能落地的AI干货。
关注我，更多AI趋势与实战，我们下期再见！
