花3小时写了个Skill只用了一次：到底什么值得写成Skill？

先讲个真事。

上次我们团队一个同事，花了一整个下午写了个Skill，专门用来“把Excel表格转成PDF格式”。精雕细琢，加流程、加约束、配脚本，看着挺像那么回事。

结果上线以后，一共用了一次。

再也没有第二次了。

问他为啥，他说：“后来我发现直接点‘另存为PDF’就行，10秒钟的事。”

我问他花3小时写个只用一次的东西图啥，他说：“我以为还会用。”

他犯了一个典型错误：把“偶尔做一次”当成“高频任务”。

三条硬标准，全满足才动手

在决定写一个Skill之前，先过这三关：

①这件事我会做10次以上吗？

如果只做一次，直接Prompt硬啃，别浪费时间去建Skill。写Skill本身也是有成本的。

②我能一句话说清“什么时候用它”吗？

如果触发场景模糊不清——“有空的时候帮我分析一下”——这种话连你自己都说不准，AI更不知道什么时候该加载它。

③产出有明确、可预期的结构吗？

每次生成的格式都不一样，那你怎么验证对错？怎么复用？没法测试的东西，就别做成Skill。

三个都是“是”→建Skill。有一个“否”→先别建，继续用Prompt。两个“否”→千万别建，这是一次性或探索性任务。

核心心法：判断标准不是“难不难”，是“会不会再来”

这是最容易让人想歪的一点。

很多人觉得“这件事好难、好复杂，我得写成Skill，下次就不用动脑子了”。然后花半天建了个Skill，用了一次就再也没碰过。

正确的判断逻辑是：

· 这件事很难，但只做一次→用Prompt硬啃就行
· 这件事很简单，但每天都要做→值得写成Skill

难但只做一次，硬啃。简单但天天做，值得自动。

我每天都要写代码提交信息（commit message），流程固定、天天重复。花一小时写成Skill，以后每天省5分钟，一年下来能省出好几天。

不该写的四个信号

①一次性任务

“帮我把这份文档转成PDF”“帮我分析一下这个Excel”——做过一次就不会再有第二次。

②没有固定流程，每次都不一样

“帮我分析一下这个行业”——每个行业都不一样，怎么固定流程？写死了反而束缚。

③简单问答、即时信息

“这个API怎么用”“今天天气怎么样”——查一下就知道了，不需要沉淀。

④边界模糊、无法测试

“帮我判断这个想法好不好”——什么叫好？标准不统一，输出无法验证。

一页决策清单

开始前问自己三个问题：

问题 回答
这件事我会重复做吗？ ≥10次才考虑
流程是固定的吗？ 先做什么、后做什么是确定的
产出有标准吗？ 能说清楚“做对”长什么样

三个都是“是”→建Skill。有一个“否”→先别建。两个“否”→千万别建。

最后说句大实话

你不是在写代码，你是在给自己省时间。写Skill本身也是时间成本，你得算这笔账值不值。

判断标准从来不是“这件事难不难”，而是“这件事会不会再来”。

难但只做一次的事，用Prompt硬啃就行了。简单但天天做的事，才值得花时间做成Skill。
skill开发 skill工具 Skill教程 skill学习 skill技能 skill使用 skill技巧