最近折腾 AI Agent 的时候，我越来越明显地感觉到一件事：

真正浪费 token 的地方，很多时候不是模型回答得太长，而是我们每次都让它从零开始理解同一件事。

比如你让 AI 帮你排查一个问题。

第一次，你要告诉它环境在哪里，配置文件在哪里，哪些命令能用，哪些命令不能用，哪些 IP 是测试环境，哪些 IP 才是真的生产环境，数据应该从 Prometheus 查，还是从 SLS 查，最后结果要写成什么格式。

第二次，还是这些。

第三次，还是这些。

看起来每次都是一个新任务，但底层其实有很大一部分是重复的。AI 每次都像一个临时拉来的同事，能力很强，但刚坐下来，什么都不知道。你要先给它讲一遍办公室在哪，文档在哪，生产环境不能乱碰，历史坑在哪里，然后它才能开始干活。

这当然也能用。

但用久了以后，会觉得有点累。

Prompt 解决的是当下，Skill 解决的是下次

很多人使用 AI 的第一反应，是写一个更长、更详细的 prompt。

这没有问题。对于一次性任务，prompt 就够了。比如写一段代码、解释一个报错、整理一份文档、生成一份脚本。只要上下文给够，AI 通常都能做得不错。

但如果一件事会反复出现，只靠 prompt 就会开始变笨。

不是 AI 变笨，而是协作方式变笨。

因为你每次都在重复灌输同一套背景。你以为自己是在“告诉 AI 需求”，其实有很大一部分时间是在“重新培训一个新人”。

这时候就应该把它沉淀成 skill。

我理解的 skill，不是一个更长的 prompt。它更像是某类任务的工作习惯：

  • 这个场景下应该先看什么；
  • 哪些信息是可信的；
  • 哪些命令不要乱跑；
  • 哪些环境变量要用；
  • 什么叫完成；
  • 输出应该长什么样；
  • 以前踩过的坑有哪些。

它不是让 AI 变得更聪明，而是让 AI 不用每次都重新变聪明一次。

如果要让 AI 帮你把一个重复任务沉淀下来，一个比较好的提问方式可以是这样：

我有一个会反复执行的任务，想把它沉淀成一个可重复使用的 skill。

我的工作目录是：/path/to/project
这个任务通常是：……
我每次都会提供的输入是：……
我希望最终输出是：……

请你先阅读相关文件和现有流程，判断哪些步骤是固定的、哪些步骤需要每次根据输入变化。

如果你觉得我的描述里有模糊的地方，不要急着写 skill。
可以先和我进行最多两轮澄清对话，直到你确定：
1. 这个 skill 什么时候应该被触发；
2. 它应该遵守哪些边界；
3. 哪些步骤适合写成脚本；
4. 最终怎样验证任务完成。

确认后，请把它沉淀成一个结构清晰、以后可以直接复用的 skill。

这类 prompt 的重点不是“让 AI 马上干活”，而是先让 AI 识别：哪些东西值得被保存下来。

真正省 token 的地方，是把确定性流程拿出去

我之前有一个很典型的例子：yq-k8s-alert-analysis。

这个 skill 是用来分析 K8s / Prometheus 告警的。它里面不只是写了“你要认真分析告警”这种空话，而是沉淀了一整套可以复用的流程：

  • 告警时间怎么作为锚点；
  • Prometheus 怎么查；
  • SLS 怎么查；
  • 哪些 IP 段属于测试环境；
  • 哪些信息不能写进 Obsidian 或聊天记录；
  • 最终报告应该怎么组织；
  • 以及一些可以直接复用的 Python 脚本。

这里面最关键的不是“prompt 写得多详细”。

而是把那些确定性的、机械性的、每次都一样的部分，交给脚本和固定流程去做。

AI 不需要每次临场想：我要怎么拼 PromQL？我要怎么拉时间窗口？我要怎么把这些数据整理成结构？这些事情如果已经有脚本，就让脚本做。

AI 更应该负责的是：

  • 判断现在该调用哪一步；
  • 看懂脚本输出；
  • 把不同来源的证据串起来；
  • 区分异常和噪音；
  • 最后写成人能看懂的结论。

这样 token 才花在真正需要判断的地方，而不是花在重复搬砖上。

这也是我最近觉得很重要的一点：

不要把 AI 当成所有事情都要亲手做一遍的执行器。

它更适合当一个会调度工具、会理解上下文、会总结判断的人。至于那些稳定、重复、确定的动作，应该尽量工程化。

一个简单的分层

我现在会大概这样区分 AI 任务：

一次性问题：直接问

比如解释一个概念，写一个临时脚本，帮我看一段报错。

这种没必要沉淀。直接问就好。

重复但简单：写成简易 skill

比如固定格式的周报、固定风格的邮件、固定结构的总结。

这种以前我会把它叫做 prompt 模板。每次替换变量即可。

但现在我更愿意把它也归到 skill 的区间里，只不过它是最轻量的那一层。

因为模板本质上也在描述一件事的工作习惯：输入是什么，输出长什么样，哪些语气不要用，哪些结构要保留。它和复杂 skill 的区别，不是类型不同，而是沉淀程度不同。

重复且有流程：写成 skill

比如某类排查、某类发布、某类代码审查、某类文档整理。

只要它有固定步骤、有注意事项、有验证标准，就适合变成 skill。

重复且有确定性操作：skill + scripts

这是我觉得最舒服的一层。

skill 负责告诉 AI 工作方法，scripts 负责执行那些稳定动作。比如拉数据、格式化、查询 API、生成中间结果。

这样 AI 不用每次写一遍临时代码，也不用每次把一大堆原始数据读进上下文。

这里的提问方式也可以更直接一点：

这个任务以后会经常重复执行。

请你不要只给我一次性的解决方案，而是帮我判断：
哪些步骤应该写进 skill，哪些步骤应该做成 scripts。

对于 scripts，请优先选择确定性强、输入输出清晰、不需要模型推理的部分，例如：
- 读取固定目录下的文件；
- 调用固定 API 或 CLI；
- 清洗和格式化数据；
- 生成中间 JSON / Markdown；
- 做基础校验。

AI 只负责调度脚本、理解结果、串联证据和写最终结论。
请按这个原则给我一个 skill + scripts 的沉淀方案。

这个思路一旦想通，很多事情就会变得很自然：能被程序稳定完成的，就不要反复消耗模型注意力。

高频、定时、无人值守：自动化

如果一件事不需要人每次触发，那就更进一步：cronjob、watchdog、定时脚本、告警机器人。

AI 甚至不一定每次都要参与。只有当结果需要解释、判断、归纳的时候，再让 AI 介入。

少让 AI 临场发挥

这句话听起来有点反直觉。

很多人喜欢 AI，正是因为它临场发挥能力很强。你给它一个模糊需求，它也能凑出一个看起来不错的结果。它能写代码，能查问题，能整理文档，能把一个乱七八糟的想法变成一篇文章。

但越是长期使用，越会发现：真正稳定的工作流，不能总靠临场发挥。

临场发挥适合探索。

沉淀适合复用。

如果一件事只做一次，那就让 AI 自由发挥。如果一件事会做十次、二十次、一百次，那就应该逐渐把它从“对话”里拿出来，变成不同层级的 skill、脚本、检查清单。

这不是为了限制 AI。

恰恰相反，是为了让 AI 把注意力留给更重要的部分。

就像一个熟悉你的同事，不需要每次都问你代码仓库在哪、命名规范是什么、上线前要不要跑测试。他已经知道这些，于是你们的对话可以直接进入问题本身。

好的 skill 也是这种感觉。

它让 AI 带着一点过去的工作痕迹回来。

不是私人记忆那种痕迹，而是协作习惯里的痕迹。

不要沉淀所有东西

当然，也不是所有东西都应该变成 skill。

我觉得有几个判断标准：

第一，这件事是不是会重复出现。

如果只做一次，就不用急着沉淀。沉淀本身也是成本。

第二，这件事是不是有稳定流程。

如果每次都完全不一样，那 skill 可能只会变成一堆空泛原则。

第三，这件事里面有没有确定性步骤。

有的话，就很适合配 scripts。因为脚本比自然语言更稳定，也更省上下文。

第四，这件事有没有容易踩坑的边界。

比如不能动生产、不能泄露密钥、不能提交某些文件、不能用某个错误的数据源。这些尤其适合写进 skill，因为它们不是“聪明”能解决的问题，而是“记得”才能避免的问题。

所以我现在如果想让 AI 帮我做沉淀，通常会把边界也写进 prompt 里：

请帮我把这类任务沉淀成 skill，但不要急着执行实际修改。

需要注意的边界：
- 不要修改生产环境；
- 不要把密钥、AK、token 写进 skill 或文档；
- 不要提交无关文件；
- 不要把一次性的任务进度写进长期记忆；
- 如果某一步有破坏性，请先停下来问我。

如果你发现这个任务不值得沉淀成 skill，也请直接说原因。
如果值得，请告诉我它应该是：
1. 简易 skill；
2. 普通流程 skill；
3. skill + scripts；
4. 自动化任务。

很多时候，好的提问不是把需求说得更“宏大”，而是把边界说清楚。边界清楚以后，AI 才知道哪些地方可以主动，哪些地方必须克制。

省 token 只是结果，不是目的

最后我反而觉得，省 token 不是这件事最重要的部分。

它当然会省 token。

因为你不需要每次重复输入背景，AI 也不需要每次读一堆无关上下文。确定性流程被脚本吃掉以后，模型只处理更干净的结果。

但比 token 更重要的是：稳定感。

你会开始感觉 AI 不再是每次随机召唤出来的一个聪明陌生人，而是一个已经知道这类事情该怎么做的协作者。

它知道先看哪里，知道哪些坑不能踩，知道什么叫“做完了”，也知道哪些东西不该多碰。

这种感觉很微妙。

不是让 AI 更像人，而是让协作不再每次都从零开始。

我觉得这可能是长期使用 AI Agent 时，一个很重要的分水岭：

前期，我们追求的是“AI 能不能做”。

后来，我们更在意的是“AI 能不能稳定地重复做好”。

而从 prompt 到 skill，从临场执行到流程沉淀，大概就是这个变化的开始。