简介：很多开发者在使用 Agent 时都会遇到同一个问题：为什么每次都要重新解释任务要求？本文对比“临时指令”与“Skill 沉淀”两种工作方式，从触发机制、可复用性、维护成本、适用场景等维度展开分析，帮助读者理解何时应把经验写成结构化 Skill，何时继续使用一次性提示即可，并给出从临时指令迁移到 Skill 的实操建议。
如果你最近开始频繁与 Agent 协作处理开发任务，大概率会遇到一种微妙的挫败感：它不是完全不会做，而是每次都像第一次做。你刚刚纠正过的代码风格、提醒过的风险检查顺序、跑通过的工具调用流程，换个任务又要重新解释一遍。
这种重复不是抽象问题，它通常落在非常具体的工作细节里。同样是整理接口文档，今天要重新告诉它字段排序规则；同样是代码审查，明天还要提醒它先看变更范围、再看测试覆盖、最后列潜在风险；同样是调用内部工具链，换一次任务就可能把参数顺序写错。
问题的本质不在于模型“不聪明”，而在于任务中的经验没有被沉淀下来。人类同事做熟一类工作后，会形成习惯、检查表和处理路径；Agent 也需要类似的东西——只不过给它用的不是口头经验，而是结构化的能力包。
这篇文章要对比的，就是两种让 Agent 工作的方式：临时指令与Skill 沉淀。前者是每次任务现场描述要求，后者是把一类任务的做法提前写成可复用流程。两者目标一致，都是为了指挥 Agent 正确完成任务，但在触发方式、可维护性、协作效率和适用边界上差异显著。
临时指令指的是用户在单次对话或单次任务中，现场向 Agent 输入的要求说明。它可以很短，比如“帮我整理这份日志，按时间排序”；也可以很长，比如贴出一大段格式规范、处理步骤和注意事项，让 Agent 本次照做。
临时指令的核心特征是：它的生命周期只存在于当前会话或当前任务中。任务结束，这段指令的使命就结束了。下次遇到同类任务，用户需要重新输入，或者从历史记录里复制一段再修改。
Skill 则是给 Agent 使用的可复用工作能力包。它把一类任务的触发条件、操作流程、参考资料、工具脚本和验收标准放在一起，让 Agent 遇到同类问题时可以按既定方法执行，而不是每次重新猜用户要求。
从技术形态上看，Skill 通常是一个目录。目录里最核心的是 SKILL.md 文件，它告诉 Agent：这个 Skill 适用于什么任务、开始前要读什么、应该按什么顺序做、哪些情况必须停下来确认。目录里还可以放脚本、模板、参考资料和示例。
Skill 不是把知识灌进模型里，也不是让模型“永久学会”某个技能。它更像一个可被 Agent 打开的工作手册：平时只暴露简短描述，真正触发后才把详细流程读入上下文。
尽管临时指令和 Skill 在形态和生命周期上差异明显，但它们共享一些基础目标：
第一，两者都是对 Agent 行为的约束和引导。 无论是一次性说清楚，还是提前写成文件，目的都是让 Agent 减少猜测、少漏步骤、少问重复问题。
第二，两者的内容要素高度重叠。 一个好的临时指令和一个好的 Skill，往往都会包含：任务范围界定、操作流程、输入输出格式、注意事项和验收标准。区别不在于“说什么”，而在于“说一次还是说多次”。
第三，两者都依赖上下文窗口来传递信息。 Skill 并不是模型权重层面的改变，它仍然是一个被读入上下文的文本或文件集合。临时指令更是直接存在于上下文中。因此两者都受上下文长度限制，都需要考虑信息密度和优先级排序。
临时指令的触发是用户手工触发的。每次任务开始，用户需要主动描述要求。这意味着用户必须记住：这类任务需要说哪些要点。忘说一条，Agent 就可能做错。
Skill 的触发是描述匹配触发的。SKILL.md 中通常包含一个 description 字段，用于和用户当前请求做匹配。当用户的说法命中了某个 Skill 的触发条件，Agent 就会主动加载该 Skill 的详细内容。这个过程不需要用户记住所有细节，只需要说出大致需求。
临时指令的复用成本随使用次数线性增长。用十次，就要写十次。虽然可以复制粘贴，但每次仍需要根据具体任务微调，而且历史记录里的指令版本可能已经过时。
Skill 的复用成本是一次写入，多次调用。维护工作集中在 Skill 文件本身，而不是每次对话中。当团队里多个成员都使用同一类 Agent 任务时，Skill 的优势更加明显：一份能力包被多人共享，避免了每个人各自维护一套口述经验。
临时指令高度依赖用户当场的表述完整性和准确性。用户今天说得详细一点，Agent 就做得好一点；明天着急了少说两条，Agent 就可能出错。这种波动性在临时指令模式下很难消除。
Skill 通过结构化文件将关键步骤、风险点和验收标准固定下来。只要触发正确，Agent 每次读到的都是同一份完整流程。一致性显著提升，遗漏风险显著降低。
临时指令的“维护”实际上是散落在每次对话中的微调。这些微调很难回溯，也很难系统化。你可能会发现自己在不同对话里反复修正同一个问题，但修正结果没有被记录下来。
Skill 则天然支持版本化维护。当一类任务的做法发生变化——比如工具升级了、流程调整了、发现了新的坑——只需要更新 Skill 目录中的对应文件。下次触发时，Agent 自动使用更新后的流程。这种可演进性使 Skill 成为团队知识沉淀的载体，而不只是个人使用习惯。
临时指令通常是一次性全部塞入上下文。如果指令很长，可能挤占任务数据本身的空间，尤其在处理大文件或多文件任务时问题更突出。
Skill 采用分层加载策略。SKILL.md 中的 description 非常简短，只用于匹配判断；真正的详细流程在触发后才加载。目录中的参考资料、脚本和示例可以按需读取，不必全部进入上下文。这种设计在保持信息完整的同时，降低了对上下文窗口的消耗。
临时指令更适合简单、一次性、变化大的任务。如果任务只需要一句话描述，或者每次要求都不同，写一个 Skill 反而多余。
Skill 更适合复杂、重复、需要多步骤协调的任务。特别是当任务涉及以下特征时，Skill 的价值最明显：步骤多且有顺序依赖、有明确的格式或规范要求、需要调用脚本或工具、有容易遗漏的风险点、需要团队统一执行标准。
| 对比维度 | 临时指令 | Skill 沉淀 |
|---|---|---|
| 触发方式 | 用户每次手动输入 | 基于描述自动匹配触发 |
| 生命周期 | 单次会话/任务 | 持久存在，可跨会话复用 |
| 复用成本 | 随使用次数线性增长 | 一次写入，多次调用 |
| 一致性 | 依赖用户表述的完整性，波动大 | 结构化固定流程，一致性强 |
| 维护方式 | 散落在历史对话中，难以回溯 | 集中在 Skill 目录中，可版本管理 |
| 上下文占用 | 一次性全量占用 | 分层加载，按需读取 |
| 团队共享 | 需要各自维护或手动分发 | 一份文件多人共享 |
| 适合任务 | 简单、一次性、变化大 | 复杂、重复、多步骤、有规范 |
| 编写成本 | 极低，随说随用 | 需要前期投入整理时间 |
| 演进能力 | 弱，经验难以积累 | 强，可持续迭代优化 |
探索性任务。 当你还不确定最终要什么结果，需要和 Agent 多轮试探时，临时指令更灵活。比如“先帮我看看这个项目结构，然后想想怎么优化”，这类任务还在发散阶段，不适合提前固化流程。
高度个性化的一次性需求。 如果某个任务只做一次，且要求非常具体、不太可能重复，写 Skill 的投入产出比很低。比如“帮我把这 20 个文件名改成驼峰格式”。
快速验证类任务。 当你想测试 Agent 对某个新工具或新流程的理解程度，临时指令可以先跑一遍看看效果，再决定是否值得沉淀为 Skill。
高频重复的开发流程。 比如每次提交代码前的自检清单、每次发布时的回归检查步骤、每次生成接口文档时的字段规范。这些任务做了三次以上，就值得考虑写成 Skill。
团队协作中的统一规范。 当多个开发者需要让 Agent 以统一方式处理代码风格、日志格式、错误处理模式时，把规范写成 Skill 可以避免每个人各自描述、标准不一致。
需要编排多个工具的任务。 如果任务涉及多个工具链的调用顺序、参数传递和结果校验，Skill 可以把这些操作固化下来，减少每次的试错成本。
有明确风险点的任务。 某些任务在某些步骤上特别容易出错，比如生产环境操作需要二次确认、数据清理操作需要先备份。把这些风险点写入 Skill 的必停确认环节，比每次口头提醒更可靠。
判断标准不是“任务重要不重要”，而是重复率和复杂度。
一个实用的经验法则是：如果一个任务你已经向 Agent 解释过三次以上，或者你在同一次任务中反复纠正过两次以上，就应该考虑把它沉淀为 Skill。
具体决策路径可以这样走：
不要一上来就把所有经验都写成 Skill。Skill 库过度膨胀会带来新的问题：触发匹配变难、维护成本上升、Agent 加载时选择困难。保持克制，只沉淀那些真正值得复用的能力。
一个 Skill 最小可以只有 SKILL.md 文件，不需要一开始就追求完整目录结构。先把最核心的三件事写清楚：触发条件、操作步骤、验收标准。等使用过程中发现需要补充时，再逐步加入脚本、模板和参考资料。
description 是 Agent 做第一眼匹配的关键。它需要说清楚：用户说什么样的话时应该触发这个 Skill。写得太宽泛会导致误触发，写得太狭窄会导致该触发时不触发。建议在 description 中同时包含适用场景的正面描述和不适用场景的排除说明。
迁移过程中最容易丢失的是那些“你心里知道但没说出口”的风险判断。比如某些操作前需要确认环境、某些步骤完成后需要人工校验。把这些内容显式写入 Skill 的流程中，标记为“必须停下来向用户确认”的节点。
新写好的 Skill 不要立刻完全取代临时指令。建议先用真实任务对比测试：同样的任务，用临时指令和用 Skill 分别跑一遍，比较输出质量和流程完整度。验证通过后再逐步切换到 Skill 模式。
Skill 不是一成不变的。当工具升级、流程调整或发现新的坑时，需要同步更新 Skill 文件。可以建立定期回顾机制，比如每月检查一次高频 Skill 是否仍然符合当前实践。
临时指令和 Skill 沉淀不是对立关系，而是同一工作流中不同成熟度的两种形态。临时指令是探索和验证的手段，Skill 是验证成功后的固化成果。核心区别在于：临时指令管理的是“这次怎么说”，Skill 管理的是“以后怎么做”。
对于刚开始与 Agent 协作的开发者，不必急于沉淀大量 Skill。先从观察重复解释开始，识别真正高频且复杂的任务，逐步把验证过的经验转化为结构化能力包。这样的路径既不会过度工程化，又能让 Agent 在反复协作中真正做到“少猜、少漏、少返工”。