K3什么时候该用 Skill：同一件事说到第二遍

为了写一篇关于线下活动定价的文章，我让 AI 抓取了活动行上的 3,839 个活动，前后跑了四轮。每一轮的失败，都变成了下一轮的配置改动，没有哪一轮从头再来。我管这叫回路。有没有回路，看这一句就知道：

写 Skill 也看这一条。你发现自己在重复交代的那一部分，就该写进文件。

四个信号

1. 01同一件事，你第二次向 AI 解释。背景、材料、上次踩过的坑，又交代了一遍。
2. 02结果写得出完成标准。比如“生成周报-日期.md，每个项目三行，用户读完不需要再改结构”。
3. 03你说得清自己通常怎样完成它。这是唯一的门槛，不需要会编程。
4. 04AI 每次都在重写同样的代码。格式转换、压缩图片这类步骤结果是确定的，写成脚本放进 Skill，比每次让模型重写更快、更稳，执行时也不用把代码读进上下文。

第一条出现，就值得动手；第二、三条决定你写不写得出来、能不能验收；第四条决定 Skill 里要不要带脚本。

配置、Skill，还是程序

Skill 不是唯一的容器。把能力留在文件里有三种形式，门槛从低到高：

三种情况，我不急着写 Skill

• —只做一次的探索。头脑风暴、第一次试一个新工具，直接在对话里做。
• —还没跑通的流程。没跑通就写进文件，等于把混乱固定了下来。我的顺序是先在真实任务里完成一次，再把跑通的做法写下来。
• —每次都要生效的底线规则。这类规矩写进配置文件，比如 Claude Code 的 CLAUDE.md、Codex 的 AGENTS.md，不必等某个 Skill 被触发。

谁来按开关

Skill 有两种用法：Agent 按描述自己判断要不要用，或者你手动调用。选哪种，看这件事做错了收不收得回来。

这是我那 1,852 次 Skill 调用里的两组数字。提交意味着授权：这一版我认了，可以存档、可以发布。补充证据，则适合让系统自己去找。

落到 Skill 上，就是给有副作用的 Skill 收回开关。在 Claude Code 里，SKILL.md 的元数据加一行 disable-model-invocation: true，Agent 就不会自己调用它，只有你输入斜杠加名字时才会运行。部署、发布、对外发消息这类 Skill，我建议都这样设。

我留给自己的是决定权，不是每个动作。发布上线是我调用第二多的 Skill，执行可以交给 AI，这一版发不发，只能由我来定。

五个场景，先猜再翻

回家后的第一个 Skill，怎么挑

第一个 Skill 别挑最难的事。我的建议是，从这一周你已经和 AI 做过两次的事里挑一件，按下面的顺序问一遍：

1. 01这件事以后还会做吗？只做这一次，就留在对话里。
2. 02它是不是每次对话都要遵守的规矩？是，就写进配置文件。
3. 03你说得清怎么做、写得出什么算完成吗？说不清，先在对话里再跑通一次。
4. 04它会不会发送、发布、付款、删除？会，就写成 Skill，但只许手动触发。
5. 05里面有没有每次都一样的步骤？有，就把这一步写成脚本，放进 Skill 的 scripts/。

问完还留下来的，就是你的第一个 Skill。写完之后的检验很简单：关掉电脑，第二天重新打开，它还能用，而且你不用再解释一遍背景。

常见误区

• —什么都写成 Skill。Skill 越多，描述越容易互相重叠，Agent 反而容易选错。
• —让 AI 自动触发发布、付款、删除。做错了收不回来的事，开关留在自己手里。
• —把一次性的细节写进 Skill。只对这一次有用的要求，在对话里说就够了，写进去反而会干扰下一次。