一句话已经能让模型做出视频，还需要安装一套剪辑 Skill 吗？如果要求只是有画面、有声音，也许很快就能得到一个结果。但想沿用自己的字幕、素材、节奏和发布规格，问题就具体得多。
一次 AI 早报制作的分享，呈现了另一种复杂度：用户给出一段提示词，让 Bot 安装四五个已有 Skill，再调用它们完成任务。原本为了省去重复说明而建立的封装，逐渐又需要一层说明才能被使用。Prompt 和 Skill 的边界变得模糊，但用户希望保留下来的东西未必相同。
模型会做，和知道你要什么，隔着一层信息
可以把一套剪辑 Skill 想象成几个不同部分。如何切换镜头、如何生成字幕，属于完成任务的方法；片头文件在哪里、字体用哪一款、横屏和竖屏分别怎样输出，属于项目资料和偏好；哪些片段不能删、成片交给谁确认，则属于具体工作要求。
模型升级可能改变第一部分。过去需要逐步讲解的方法，后来一句话就能可靠完成，旧的长说明便值得重新检查。后面几部分却不会仅因模型更强而自动获得答案。通用模型无法从一般知识中得知某个团队刚确认的片头版本。
因此，判断一个 Skill 是否过时，不能只看模型能否完成同类演示。更有用的比较是：去掉它之后，用户关心的哪些结果会发生变化？若变化只在过时的操作步骤，删减可能让流程更简单；若丢失的是项目规范，仍然需要一个可靠的保存位置。
Skill 可以保存程序和资源
Anthropic 对 Agent Skills 的介绍把它定义为组织在目录中的指令、脚本和资源，并通过逐步加载减少无关内容进入上下文。这个设计说明，Skill 的载体比一段提示词更宽：它也可以把确定的计算交给脚本，把只有部分任务需要的资料放在单独文件里。
例如，假设每次输出都要遵守同一组文件命名规则，并生成几个固定尺寸的封面。把这些要求封装在可重复执行的程序中，就不必每次让模型重新发明处理方法。模型负责理解这次内容，程序负责执行已经明确的变换。
但打包在一起并不意味着一切都该自动运行。资源是否适用于当前项目、脚本依赖是否齐全、生成结果是否满足需求，仍需要检查。一个内容丰富的 Skill，也可能带着错误假设或已经失效的操作路径。
层层封装，容易藏住决定
当一个提示词要求安装多个 Skill，每个 Skill 又引用其他提示词时，最难找的往往不是入口，而是某条决定究竟来自哪里。
设想两套内容 Skill 都规定标题风格，一套要求克制，一套要求强烈吸引点击。单独使用时各有用途，一起加载却可能互相覆盖。再增加一层总提示词，未必能消除冲突，反而可能让使用者更难判断改哪份文件。
拆解这种复杂度，可以从所有权入手：通用制作方法保存在可复用能力里，项目偏好由项目资料管理，这次任务的例外写在任务要求中。每一层负责不同的信息，就不必把同一个字体、同一句标题规则复制到所有文件。
这是一种组织建议，并不是某种格式自带的保证。实际效果还取决于 Agent 能否找到正确资料，以及它如何处理相互矛盾的要求。
清理时，用旧任务做比较
模型更新之后，直接把所有 Skill 删除，或者永久保留所有历史补丁，都缺少依据。更稳妥的做法是挑几个经常发生的任务，在同一组输入上比较：完整 Skill、删掉通用步骤的精简版，以及不使用 Skill 的版本。
需要观察的结果也可以很具体：是否沿用正确素材，是否满足输出规格，哪里需要人重新提醒，完成后是否出现额外返工。这样的比较不能只看一次漂亮的样例；尤其是旧 Skill 曾经修复的失败，要重新放进去验证。
最终留下来的内容，可能越来越少讲模型本来就知道的常识，越来越多记录这项工作特有的事实和约束。Skill 是否值得保留，由它能否稳定传递这些信息来决定。文件叫 Prompt 还是 Skill，远没有其中保存了什么重要。