导读

很多人已经开始用 AI 处理工作，但大多数时候，还是“想到什么问什么”。今天让它整理会议纪要，明天让它分析报错，后天又重新解释一遍需求。

但如果一类事情你总在重复做、重复说，其实就值得再往前走一步：把它做成一个 Skill。

这篇文章不讲复杂技术，只讲一个问题：

一个完全没写过 Skill 的人，怎么开始做自己的第一个 Skill。

Skill 到底是什么？

先别把它想得太复杂。

你可以把 Skill 理解成：把你经常做的一类事，整理成一套固定规则，然后交给 AI 去执行。

比如这些都可以做成 Skill：

• 把会议录音整理成纪要

• 把周报按固定格式输出

• 根据报错日志给出排查思路

• 把 Git 改动整理成规范的 commit message

• 把接口说明整理成标准文档

它不是一个很玄的概念，本质上就是一句话：

把重复的工作，变成一个可以复用的流程。

Prompt 和 Skill 的区别：一个是临时提需求，一个是把需求固定成可复用能力

为什么值得做一个 Skill？

因为很多人现在用 AI，还是“想到什么问什么”。

比如开完会，把录音转写丢给 AI，说一句：

• 帮我整理个纪要

下次又要补一句：

• 结论、待办、责任人分开写

• 风险项单独列出来

• 不要写得太啰嗦

再下一次，还是得重新说一遍。

写代码也是一样。今天你把一段报错贴给 AI，说：

• 帮我看看哪里有问题

明天可能又要补：

• 先说最可能的原因

• 再给排查顺序

• 最后告诉我优先查哪一步

如果一类事情你总在重复做，总在重复解释，那它就很适合做成 Skill。

Prompt 更像一次性的沟通，Skill 更像把这类沟通固定下来。

以后再遇到同样的事，不用每次从头说一遍。

什么样的事适合做成 Skill？

我觉得先抓三个标准就够了。

1. 你经常做

比如每周都要写周报、整理会议纪要、分析报错、补接口文档。

2. 输入和输出比较固定

比如输入是一段会议转写，输出是一份纪要；输入是一段报错日志，输出是一份排查建议。

3. 你对结果有明确要求

比如：

• 要分点输出

• 要标清责任人

• 要按固定模板整理

• 要先给结论，再给步骤

满足这三条，就可以考虑做成 Skill 了。

适合做成 Skill 的任务，通常同时满足 3 个条件：高频、固定、标准清晰

第一个 Skill，建议从小事开始

别一上来就想做那种很大的东西，比如“自动分析需求、写代码、测 bug、出文档”一条龙。第一个 Skill 最好小一点、具体一点，最好做完马上就能用。

办公场景可以从这些开始：

• 会议纪要 Skill：输入会议转写，输出结论、待办、责任人、风险点

• 周报整理 Skill：输入零散事项，输出标准周报

• Excel 数据说明 Skill：输入一张表，输出异常项和结论摘要

开发场景可以从这些开始：

• 报错排查 Skill：输入报错日志，输出可能原因、排查步骤、优先级

• Git Commit Skill：输入改动内容，输出规范 commit message

• 接口文档整理 Skill：输入接口信息，输出标准接口文档

如果让我选一个最适合入门的，我会推荐：

报错排查 Skill

因为它很具体，也很容易看出有没有用。

第一个 Skill 怎么写？其实就 4 步

下面我就拿“报错排查 Skill”举个例子。

第一步：先把任务说具体

不要只写：

帮我看看报错

这种说法太宽了，AI 很难知道你到底想要什么。

你可以把它写成：

输入一段报错日志或报错现象，先总结可能原因，再给出排查步骤，最后标出最值得优先检查的方向。

这一步看起来简单，但其实很重要。因为你后面写的所有规则，都是围绕这句话展开的。

第二步：把输入和输出写清楚

比如这个 Skill：

输入

• 报错日志

• 报错截图里的文字

• 问题现象描述

输出

• 可能原因列表

• 建议排查步骤

• 优先排查项

• 如果信息不够，要明确说还缺什么

到这里，它已经不像一句临时提问了，而更像一个小工具说明书。

第三步：把你的要求写成规则

这是最关键的一步。

很多人平时只会说一句：

帮我分析这个报错

但如果你想把它做成 Skill，就得把“分析”拆开。

比如这个报错排查 Skill，可以先写 5 条规则：

1）先用一句话总结问题

别一上来就甩一堆术语，先说这看起来像什么问题。

2）优先给 3～5 个最可能的原因

不要一口气列二十种可能，先把最值得查的放前面。

3）排查步骤要有顺序

先查最容易验证的，再查复杂的。不要一上来就让人去大改代码。

4）如果信息不够，就明确说缺什么

比如缺调用栈、缺上下文代码、缺环境信息，而不是硬猜。

5）最后给一个“建议先查哪里”

这样拿到结果的人，知道下一步该先做什么。

第四步：先跑起来，再慢慢补规则

第一个 Skill 不用一开始就做得很完整。

你先让它跑一次，然后看问题出在哪：

• 是不是原因列得太散？

• 是不是步骤没有优先级？

• 是不是太喜欢瞎猜？

• 是不是输出太长，看着费劲？

如果有问题，就继续补规则。

比如补一句：

• 输出尽量控制在 5 条以内，先说重点

• 不确定的内容要明确标“推测”

• 如果是常见报错，优先给最快验证的方法

你可以把这个过程理解成：

不是一次写对，而是像带新人一样，一点点把标准教给它。

写第一个 Skill，不需要一步到位。先把任务说具体，再把输入、输出和规则慢慢补齐。

如果你不是程序员，也完全可以从办公 Skill 开始

比如一个 会议纪要 Skill，写法其实也是一样的。

任务定义

输入会议转写，输出结构化纪要。

输入

• 会议转写文本

• 可选：会议主题

输出

• 会议结论

• 待办事项

• 责任人

• 风险点 / 待确认问题

规则示例

• 不要照抄原文，要先提炼结论

• 待办事项单独列出

• 能识别责任人的就标责任人，识别不了就标“待确认”

• 决策和讨论分开，不要混在一起

• 输出尽量简洁，方便直接转发给同事

你会发现，办公 Skill 和开发 Skill 的思路其实差不多：

先定义任务，再写清输入输出，最后把你的要求变成规则。

小白做第一个 Skill，记住这 4 句话就够了

1）先找一个你每周都在重复做的事

别做太大，先做小事。

2）把任务说具体

不是“帮我看看报错”，而是“根据日志给出可能原因、排查步骤和优先级”。

3）把要求写成规则

把“我想要什么结果”变成 5～10 条明确要求。

4）先跑，再迭代

别追求一步到位，先做出能用的第一版。

最后想说的

我觉得普通人写 Skill，最重要的收获不一定是“学会了一个新技术”，而是开始把自己的工作方法沉淀下来。

以前我们用 AI，更像是临时找人帮忙。但当你开始写 Skill，你就在做另一件事：

把自己经常重复做的一类工作，变成一个可以反复调用的小工具。

它不一定复杂。甚至可以很小。

比如一个会议纪要 Skill。比如一个报错排查 Skill。比如一个 Git commit 整理 Skill。

但从那一刻开始，你已经不只是“在用 AI”，而是在慢慢搭自己的 AI 工具箱了。