10|Skill:把重复  固化成自己的 AI 工作流

10|Skill:把重复 固化成自己的 AI 工作流

2026-10-15 16:59:18 0点赞 3收藏 0评论

本篇是《从头重新学 AI 编程》系列第 10 篇。

上一篇聊了 Git worktree,怎么让多个 Agent 并行干活但互不打架。这一篇接着下半场,聊一个在网上比较火,但是很多人还是不太清楚自己该怎么用的东西。

Skill。

先说一个你大概率干过的事。

你让 AI 帮你 review 代码,每次都得说一遍,

帮我 review 这段代码。重点看,有没有潜在的 bug,命名是否合理, 有没有可以简化的逻辑,有没有安全风险。 如果有问题,给出具体修改建议。

然后第二天你又想 review 了,于是这段话你又打了一遍。或者你偷个懒,从昨天的对话里翻出来复制粘贴过去。

第三天开发完成,你又来了。

我说的是不是你?

而且不只是 review。你让 AI 加一个 API endpoint,每次都要交代一遍目录结构、命名规范、测试要求。你让 AI 整理需求文档,每次都要重复一遍你想要的格式、必填字段、验收标准。你让 AI 复盘一个 bug,每次都要它先看日志、再看代码、再分析原因、再给修复方案。

这些事你都做过不止三遍了。每次说的话都差不多。但你就是没把它们存下来。

Skill 就是来干这个的。

一句话,Skill 就是把你反复对 AI 说的那套话,变成一个可以一键触发的工作流模板。你把那些重复的指令写成一个文件,下次需要的时候,不用再从头讲一遍,直接告诉 AI「用这个 Skill」,它就知道该怎么做了。

打个比方你就懂了。你去一家常去的餐厅点菜,每次都得跟服务员念叨,不要辣、少油、米饭换粗粮、加一个荷包蛋。念多了你自己都嫌烦。后来你发现这家店有个老顾客的备注功能,你把那一套偏好存进去,下次直接报个名字就行。

Skill 就是那个老顾客备注。

10|Skill:把重复  固化成自己的 AI 工作流

你可能会问,这跟我在 AGENTS.md 里写规则有啥区别?

区别在范围。AGENTS.md 是项目级的,每次对话都自动读,里面装的是项目身份、目录、风格、命令、红线,是这个项目怎么运转。Skill 是任务级的,按需触发,里面装的是某一类重复任务该怎么一步步走。再加上第 2 篇讲的 Spec,是单个功能这一次具体要做什么。

我自己的理解是,AGENTS.md 像员工手册,Skill 像 SOP(标准作业流程),Spec 像今天的工单。员工手册告诉你这家公司怎么运转,SOP 告诉你遇到这类事按这几步走,工单告诉你今天具体干哪一单。三个东西各管各的,不打架。

那什么任务适合做成 Skill 呢?

判断标准特别简单。这件事你让 AI 做过三次以上,而且每次都得给它讲一遍差不多的话。符合这个的,基本都能做。

比如加一个新的 API endpoint,改路由、加处理函数、写测试、更新文档,一套流程固定的。比如代码 review,检查 bug、命名、复杂度、安全,关注的维度每次都那几个。比如写周报或者需求文档,格式固定、字段固定。比如复盘 bug,看日志、定位、给方案、总结教训。比如新建数据库迁移,写 up 和 down、起名、跑 dry run。再比如补测试用例,找没覆盖的分支、写测试、跑通。

这些都是典型的可以固化的活。

反过来,有几类就别硬做成 Skill。一次性的探索任务,做完就完了,不会有第二次。高度依赖具体上下文、根本模板化不了的活,每次情况都不一样。还有简单到一句话能说清的事,做成 Skill 反而是给自己增加负担。

说到 Skill 长什么样,其实不管你用 Claude Code 还是 Cursor,一个 Skill 说到底就是一个 markdown 文件,里面写清楚三件事,什么时候用、怎么用、做完什么样。

10|Skill:把重复  固化成自己的 AI 工作流

还是用我们这个待办事项应用举例。假设你要做一个加 API endpoint 的 Skill,大概长这样,

--- name: add-api-endpoint description: 添加一个新的 REST API endpoint。触发条件,用户说 「加一个 API」「新建 endpoint」「添加路由」。 --- # Add API Endpoint ## 何时使用 当用户要求添加新的 HTTP endpoint 时使用本 Skill。 不要用于, - 修改已有 endpoint(用 modify-api-endpoint) - 前端页面路由(用 add-page) ## 输入 - HTTP 方法(GET/POST/PUT/DELETE) - 路径(如 /todos/:id) - 请求/响应 schema ## 步骤 1. 在 server/routes/ 加路由注册 2. 在 server/routes/ 创建处理函数 3. 如果涉及新数据访问,在 server/db/ 加查询方法 4. 写测试,覆盖, - 正常请求 - 参数校验失败 - 无权限(如适用) 5. 跑 npm test 确认全绿 ## 项目特定约定 - 错误返回统一用 { error: string } 格式 - 时间字段统一用 ISO 8601 - 所有路由都要有对应的测试 ## 完成标准 - [ ] 测试全绿 - [ ] 路由文件更新 - [ ] 至少手动调用一次验证

你把这段话存成一个文件,比如 .skills/add-api-endpoint/SKILL.md。下次要加 API 的时候,跟 AI 说一句「用 add-api-endpoint 这个 Skill」,它就照着这个流程走。

你再也不用每次都念叨「记得写测试、记得更新路由、记得错误格式用 error 包一层」了。

说到这个,我讲一个我自己沉淀 Skill 的真实过程,你可能更有体感。

我之前有段时间反复让 AI 帮我整理产品需求。每次我都得说,

帮我把这段需求描述整理成结构化文档。要有, 功能名称、背景、目标、非目标、用户故事、验收标准、技术约束。

然后 AI 给出来的东西,格式倒是有了,但每次都有点小毛病。取值逻辑的边界条件没覆盖。验收标准写得太虚,没法直接拿去测。有些字段漏了,比如异常情况怎么处理。命名还不统一,一会儿叫功能名称,一会儿叫模块名。

于是我每次都得再补一句,把异常情况也写上,验收标准要具体到能测,字段名统一一下。

这么补了大概四五次,我是真的有点烦了。

然后我就把这些每次都要补的东西,全整理出来,沉淀成了一个 Skill。里面我写了几条死规矩。

第一,必填字段清单,每个字段都不能漏,漏了就主动提醒我。
第二,验收标准必须可测试,不能写「用户体验良好」这种话,要写「输入为空时显示提示文案」。
第三,枚举值必须列全,有下拉选择就把所有选项列出来,不许用「等等」糊弄。
第四,边界条件必须检查,空值、最大长度、特殊字符、并发情况。
第五,接口变更必须标注,改了哪个字段、影响哪些下游。

沉淀完之后,我再让 AI 整理需求,只要说一句「用产品需求整理的 Skill」,出来的文档质量直接上了一个台阶。以前要来回改三轮的东西,现在基本一轮就能定。

这个过程我自己最大的体会是,关键根本不是 Skill 文件写得多漂亮。关键是你在反复用的过程里,发现的那些问题。那些「每次都得补一句」的话,才是 Skill 里最值钱的东西。

所以你别想着一上来就憋一个完美的 Skill 出来。你写不出来的,因为你还没踩够坑。

10|Skill:把重复  固化成自己的 AI 工作流

那 Skill 要怎么写呢?我的建议是,别自己从零写,让 AI 帮你写。

你可以这么跟它说,

过去这周我让你做了 5 次代码 review 的任务,每次我都要讲一遍我关注的维度。 帮我把这件事做成一个 Skill。参考我们之前的对话,提炼出, - 标准步骤 - 我反复强调的检查维度 - 容易踩的坑 先给我看草稿,我审完你再建文件。

AI 会基于你们之前的对话历史,帮你整理一份初稿。你审一审、改一改,两轮基本就成型了。

这个法子特别适合那些你已经做过很多次、但从来没想过要整理的活。让 AI 从历史对话里去提取模式,比你自己干坐着回忆要全面得多。你自己回忆,多半只想得起最近两次,前面那些早忘了。

Skill 写好了之后,也不是写完就扔那儿不管了。它跟 AGENTS.md 一样,是个活的文档,要跟着项目一起长。

每次用完一个 Skill,你留意一下。AI 是不是漏了某一步,漏了就补进去。AI 是不是误解了某个约定,那就在 Skill 里写得更明确。是不是冒出了新的边界情况,补到 Skill 里。

我自己的习惯是每个月翻一遍自己的 Skill 库。过时的删掉,相似的合并,项目结构变了但 Skill 还在引用旧路径的,更新一下。十个高质量的 Skill,远比一百个平庸又没人维护的 Skill 有用。

顺着这个,我再说几个我自己踩过的坑,你可以绕着走。

一个是写得太啰嗦。Skill 不是给人看的文档,是给 Agent 执行的指令。你写一千行,Agent 反而抓不住重点。编号步骤加明确的文件路径加具体命令,比一大段抒情的说明管用得多。

一个是 Skill 之间触发条件打架。你做了一个代码 review 的 Skill,又做了一个安全审查的 Skill,俩描述长得还差不多,AI 每次都拿不准该用哪个。触发条件得写得互斥,或者干脆在描述里写明「不要用于 X 场景」。

一个是把该留活口的地方写死了。Skill 里写「在 server/routes/todos.js 加路由」,下次你要给用户模块加路由,这 Skill 就废了。路径得用变量,或者写成「在 server/routes/ 下对应模块的文件里」。

还有一个就是前面说的,不维护。项目重构了,目录变了,Skill 还在指着旧路径。AI 按 Skill 去找文件,找半天找不到,那还不如不用。

讲到这你可能会想到第 3 篇的 AGENTS.md,跟 Skill 到底怎么配合。

其实它俩是互补的。AGENTS.md 告诉 AI 这个项目怎么运转,目录结构、常用命令、编码规范、红线。Skill 告诉 AI 遇到这类事按这几步走,是具体某类任务的操作流程。一个 AI 接到活,先读 AGENTS.md 了解项目全貌,再判断这个任务匹不匹配某个 Skill,匹配就套模板干。这个流程第 8 篇那套八步链路里其实已经讲过了,Skill 就是让那条链路跑得更顺的一环。

10|Skill:把重复  固化成自己的 AI 工作流

我有时候觉得,Skill 这个东西最妙的地方,不在于它帮你省了多少打字的时间。而在于它逼着你把「我到底想要什么」想清楚、写下来。

你平时让 AI 干活,那些要求其实是散在脑子里的,每次临时想起来一点说一点。做 Skill 这个动作,等于强迫你把脑子里那套隐性的标准显性化、固定下来。这套标准一旦写出来,不光 AI 能用,你自己回头看也会更清楚自己到底在追求什么。

从这个角度看,你攒下的那些 Skill,慢慢就变成了你这个人做事方法的一份说明书。

给你一个小练习。

回想一下你最近让 AI 做过的那些重复任务,有没有哪件事你做了三次以上,而且每次都得说差不多的话。

如果有,把它写成一个 Skill。别搞太复杂,就写三样东西,什么时候用、步骤是什么、做完怎么验收。先用起来,后面慢慢迭代。

下一篇我们聊一个让 AI 写出来的代码更靠得住的东西,CI、Hooks 和测试,怎么别光听 AI 嘴上说「应该没问题」。

作者声明本文无利益相关,欢迎值友理性交流,和谐讨论~

展开 收起
0评论

当前文章无评论,是时候发表评论了
提示信息

取消
确认
评论举报

相关文章推荐

更多精彩文章
更多精彩文章
京东京享红包
距结束::
领京东现金红包 天天领3次 最高26888元
红包按钮
最新文章 热门文章
3
扫一下,分享更方便,购买更轻松